Con archinstall ha mejorado mucho, la verdad, pero vas a tener que configurar manualmente snapper, firewall, apparmor y secureboot si quieres seguir teniendo esos servicios.
Con lo vago que estoy últimamente y el calor que hace por aquí, me duele la cabeza solo de pensar en instalar arch.
Y eso sin hablar de su liberación de paquetes, que te hace sentir en el Salvaje Oeste
1 Like
openQA lo aplica Debian y Fedora creo recordar, asi que no depende de Suse la herramienta, pero si pueden depender de Suse los equipos de testeo.
Yast va a ser sustituido por Agama, al menos en cuanto a la instalacion se refiere. Y zypper es un gestor de paquetes, codigo abierto, asi que se podria seguir usando este o dnf por ejemplo.
Saludos
Hombre, no sé, hace eones que no la pruebo, pero diría que ahora como entonces eso no está entre sus intenciones.
No hay ninguna razón general para que cambie nada. La cuestión con openSUSE no es de propiedad, ya que todo es software libre, sino de medios o recursos.
Veamos. Todo es software libre. YaST era privativo, y fue Novell quien lo liberó como software libre cuando compró SUSE y estableció openSUSE. Zypper se desarrolló en esa época.
La relación de SUSE y openSUSE siempre ha sido tal que buena parte de los desarrolladores de openSUSE eran empleados de SUSE. Entonces la pregunta ¿quién mantiene YaST o Zypper? tiene una respuesta rara: los desarrolladores de openSUSE, sean o no empleados de SUSE.
Una oportunidad en este proceso no sólo de cambio de marca sino también de reorganización es conocer también cómo están organizados los recursos de openSUSE. Hay más sponsors que SUSE, y por lo visto la gente del proyecto cree que incluso en el peor escenario se las podrían apañar, incluso cuando nadie ha planteado tal cosa.
1 Like
de hecho, si instalas Arch vía scripts o por derivadas, no dan soporte en el foro de Arch… 
Seguiremos en openSUSE a ver cómo se desenvuelven los hechos…
PD: Mira mejor el video de mas abajo.
Mirando este video de instalación de Arch Linux hecho hace 3 semanas, parece que no ha mejorado mucho, leer los comentarios 
Este es mas didáctico, especial para novatos:
1 Like
Es lo que decíamos, eso no está entre sus objetivos siquiera, ya no digo entre sus prioridades.
El principal problema de Arch para mi no es su instalacion, pues ahora con el script archinstall es un proceso mas sencillo, sino la configuracion y activacion de servicios. En openSUSE tenemos configurados por defecto, firewall, apparmor, snapper,…pero en Arch hay que instalarlo y configurarlo todo manualmente, asi que en mi caso y con mi nivel de conocimientos, prefiero delegar esas configuraciones en personas expertas que saben mucho mas que yo, sobre todo en lo relativo a la seguridad del sistema.
Mucha gente que instala Arch tiene un sistema mas expuesto en internet si despues de la instalacion no hacen “bricolaje” con el sistema para configurar los servicios de seguridad, pero lo bien que queda presumir en RRSS de usar Arch, no tiene precio
Saludos
2 Likes
Me he visto el 2º vídeo entero y me ha recordado a las antiguas instalaciones de SuSE de los 90s (SuSE 6.4).
Arch es como retroceder 25 años atrás en cuanto al sistema de instalación.
Luego, por ahí leo que hay que evitar todo lo posible los paquetes AUR (Arch User Repositories). Parece ser que se usan mucho. En openSuSE sólo usamos algún “AUR” (los home) cuando es necesario.
Saludos
1 Like
Puedes probar alguna de las derivadas de Arch Linux, del listado de abajo, te puedo recomendar una que probé en su día: Manjaro Linux y se hablo de ella en el antiguo ForoSuSE donde se hacia reviews de otras distros.
1 Like
Yo uso un repositorio personal (home) para Autofirma, es lo que hay.
Me refiero a que parece ser que en Arch es muy habitual usar montones de AUR no sólo poner un Autofirma, por ejemplo.
Saludos
Quicir, la razón aquí y allí para usar esos repos es por la disponibilidad de determinados paquetes o versiones concretas de los mismos.
Y claro, aquí como allí el soporte a hacer eso es el que es (recuerda que openSUSE no da soporte ni siquiera a los repositorios comunitarios).
Ya tiempos del oto foro, me gustaba, esta distro, por la cantidad de documentación, tanto en español como en ingles.
Me habéis comentado que no la tuviese en cuenta, ya que los ejemplos pueden diferir de OpenSUSE ( que no sean iguales) .
Aún así no me imaginaba , que fuese algo complicado su instalación -
De todas formas su archi wiki y documentos, al menos la definen y por ella me entero de muchas cosas.
Ahora bien las expectativas con yast, han hecho que me decantaran ante cualquier versión de otro S.O.
Yast se mantiene con OpenSUSE y lo mismo hago yo por años. espero que sea así o mejor.
Saludos
Esta mañana estaba leyendo el openSUSE Factory Mailing List y me encuentro conque entre Septiembre y finales de año, en las nuevas instalaciones de TW cambiarán de AppArmor a SELinux por defecto (se podrá seguir eligiendo AppArmor).
Si estamos con el jaleo del nombre, posibles divorcios, etc, ¿cómo encaja este movimiento en todo?
SELinux (por el nombre) parece una propiedad de SuSE y tras hacer un cambio de nombre a la distro sería muy chocante que la seguridad la llevara un sistema llamado SELinux.
Saludos
No es complicada, solamente que no es intuitiva. Por ejemplo, si no instalas alfo no lo instala, si no arrancas un servicio no lo arranca, etc. Pero basta seguir la guía de instalación.
¿A que sí? XD
En realidad es de Red Hat, algo así como Security Enhanced Linux.
Siempre hubo discusión. SUSE y openSUSE apostaron por apparmor desde los tiempos de Novell, mientras que otras distros fueron con SELinux. Una va por servicios y otra por ficheros.
Aeon/Kalpa ya iban con SELinux.
2 Likes
Es razonable que existan sospechas debido a los derroteros de SUSE con openELA, pero me parece que los tiros no van por ahí sino por el abaratamiento de la marca que está produciendo a SUSE la proliferación descontrolada de proyectos derivados de openSUSE, que llevan consecuentemente el nombre de SUSE: antes estaban Tumbleweed y Leap, y la marca quedaba ordenada y con una exposición medida, pero ahora están Tumbleweed, Leap, MicroOS, Aeon, Kalpa, Slowroll, Leap Micro y no sé si me dejo alguna más, lo que supone una clara devaluación de la marca SUSE, ya solo por su uso reiterado, pero con el agravante añadido de que, además, algunos de esos proyectos que abaratan la marca tienen muy pocos visos de fructificar (como Kalpa y Slowroll). A SUSE no le interesa que haya una docena de proyectos random con su nombre y, mucho menos, cuando algunos son proyectos meramente experimentales.
@DiabloRojo , Arch se instala muy fácilmente hoy en día con el nuevo script pero, además, tienes proyectos que funcionan casi como meros instaladores gráfico de Arch, como EndeavourOS.
1 Like
Totalmente de acuerdo, demasiada morralla.
Slowroll nació como posible paso intermedio entre Leap y TW pero no parece que tenga futuro. Sería mejor dejarlo caer.
Lo de Kalpa y Aeon, no lo veo. Lo veo más para usuarios que puedan requerir los servicios de un SLE de pago. Y en caso de existir, que les quiten el openSuSE de delante (y a cualquier paquete/aplicación) y que no consuman recurso alguno de SuSE.
Con esos 3 menos igual SuSE se contentaba algo. No sé.
Saludos
Bueno, pero
No es exactamente lo mismo.
Es posible, pero lo poco que he podido leer no parece ir por ahí. Aluden a la confusión entre los proyectos SUSE y openSUSE y que en el futuro podría incluso llevar a problemas legales, pero no veo referencias al uso de la marca.
Slowroll nace como un projecto para incorporar parte de una de las bondades de Leap (la estabilidad a largo plazo) con las de Tumbleweed (versiones nuevas de las cosas). O dicho de otra forma: disminuir el número y ritmo de las actualizaciones. Es la idea.
Ahora que lleva un tiempo lo estoy probando en un equipo para incorporarlo a al menos un servidor y muy probablemente a unos equipos de escritorio de una oficina. Y eso que con Plasma 5 y packagekit estaba funcionando guay.
Además, con el OBS desarrollar para Slowroll es prácticamente trivial.
Pero antes hay que hablar de MicroOS.
Y MicroOS sí es relevante para SUSE. Precisamente lo que van a hacer es generalizar esa tecnología: SLE va a ser inmutable. Ya veremos qué hacen cuando saquen una versión con escritorio.
Y MicroOS con escritorio, Aeon y Kalpa, no dejan de ser versiones de ChromeOS basados en Tumbleweed. Y si bien Kalpa no está despertando tanto entusiasmo, Aeon sí parece tener una base sólida de gente para desarrollarlo.
Y aunque sean cosas muy experimentales, yo diría incluso que SUSE aprecia es esa vertiente experimental. La única forma de desarrollar tecnologías es experimentando. Por eso se insistió en btrfs, por ejemplo, cuando Red Hat se retiró. Y hoy un pilar es la inmutabilidad basada en las instantáneas que si bien pueden basarse en LVM (y por tanto en cualqueir sistema de ficheros), en la práctica dependen de btrfs.
Espero que te refieras a que se parecen a ChromeOS y no a que son forks de Google…
Saludos
Claro, no es que “se parezcan” sino que siguen ideas y criterios similares, aunque lo que haya debajo sea Tumbleweed. Por ejemplo, el sistema de actualizaciones, el sistema de instalación de paquetes, el rollo monousuario…
1 Like