Portada
mis comunidades
otras secciones
#6:
#5 Supongo que depende de la aplicación. Para mis máquinas prefiero el estilo Debian: quizá no tenga lás últimas features, pero es estable a prueba de bomba. Una vez instalado, no se toca casi nunca. En mi (escasa, lo admito) experiencia con Arch, las actualizaciones a menudo rompen cosas y hay que estar toqueteando la configuración continuamente solo para que siga funcionando. En un escritorio te puede valer, sobre todo si experimentas con cosas nuevas. En un servidor o una máquina de trabajo, no.
#2:
Es lo normal si el sistema operativo que lleva la Steam Deck se basa en Arch
Comentarios
Es lo normal si el sistema operativo que lleva la Steam Deck se basa en Arch
#2 Y porque vas recibiendo siempre lo último al ser una rolling release. Así que tienes los últimos drivers, kernels, etc.
#3 Y también los últimos bugs.
#4 Y los corregidos tb.
#5 Supongo que depende de la aplicación. Para mis máquinas prefiero el estilo Debian: quizá no tenga lás últimas features, pero es estable a prueba de bomba. Una vez instalado, no se toca casi nunca. En mi (escasa, lo admito) experiencia con Arch, las actualizaciones a menudo rompen cosas y hay que estar toqueteando la configuración continuamente solo para que siga funcionando. En un escritorio te puede valer, sobre todo si experimentas con cosas nuevas. En un servidor o una máquina de trabajo, no.
#6 Faltaria mas, yo opino igual que tu, para los servidores hay q tirar de estabilidad mas que de novedad. Por eso en la raspberry o en cualquier cosa que sirva de servidor prefiero tb Debian desde siempre. Pero como dices, para desktop prefiero Arch, si es verdad que puede romper con tanta actualización, ubuntu me ha roto más con los dist upgrade que Arch, p`or eso me cansé de Ubuntu, aparte de por Snap.
#7 #6 para evitar esos problemas, usad ZFS en las maquinas corriendo Arch, sacas un snapshot antes, actualizas, y al cabo de unos días lo borras/haces rollback. Pero vaya, a mi raramente me ha roto nada...
#6 me podría arriesgar y decir esto: Manjaro es más estable que Ubuntu. Para una servidor debian y no debian 11 por cierto (tienen sin documentar cosas gordas del anillo de seguridad que me quedé alucinando como podían lanzar eso así) pero para juegos obviamente va mejor una distrofia de base arch. Yo no me atrevería con arch propiamente por eso que tú dices.
#8 Distrofia
#10 jajajajajaja
#8 Me he quedado con la duda. Lo del anillo de seguridad ¿te refieres a la obsolescencia de apt-key?
#12 seguro que me he confundido de nombre. Ahora lo miro.
#12 una actualización rompía el módulo de pam (Pluggable Authentication Modules for Linux), lo que se usa para fortalecer los inicios de sesión frente ataques. El sustituto es el mismo que el de redhat por lo que apenas hay tutoriales que no hagan referencia solo a redhat. Y en redhat esos ficheros se actualizan de manera no manual, por un programa. En Debian hay que actualizarlo manualmente y, aunque seguí absolutamente todos los pasos, fui incapaz de hacerlo funcionar. De hecho el manual en mi opinión no lo habían actualizado o comprobado. Tuve que tocar cosas que la propia política de debian dice que no hay que tocar. Quizás el resumen es que soy demasiado patoso con debian pero en mi opinión no es eso. Hay cosas complicadas de debian que puedo haber no entendido pero no he tenido nunca la sensación de que estuvieran rotas o mal hechas, como en este caso.
Te pego un trozo de un trabajo que hice:
Según el reporte de bug #982530 de Debian, los módulos pam_tally2 y pam_tally fueron eliminados en la versión 1.4.0 de libpam-modules (en diciembre de 2020). En este reporte se pone de manifiesto que muchas guías de reforzamiento de seguridad y de rendimiento recomiendan este módulo, por lo que una actualización silenciosa dejaría a los usuarios sin acceso (NOTA: les pasó a algunos compañeros en clase, así que esas máquinas virtuales se fueron a la mierda). Se llegó a la conclusión de que antes de actualizar el paquete el sistema debe buscar cualquier mención a pam_tally2 y pam_tally en /etc/pam.d/common-auth y realizar los avisos necesarios. Sin embargo, esto no tiene efecto en instalaciones nuevas y al intentar utilizar pam_tally2 o pam_tally irremediablemente fallará. El sustituto es pam_faillock. En Red Hat Enterprise Linux (RHEL) la configuración no se hace manualmente sino que otro programa, llamado authselect, es el que modifica los archivos de manera automatizada. En RHEL no está recomendado modificarlos manualmente, puesto que las entradas siguen un orden preciso y alterarlas podría provocar que ningún usuario pudiera volver a autentificarse. En Debian tampoco está recomendado editar las opciones fuera de /etc/security/faillock.conf.
[...]
5) Las consecuencias de un error no son menores: el usuario puede quedarse fuera de su propio sistema, cosa que se ha evidenciado tanto en el reporte de bug en el registro de Debian como en clase. La mayoría se quedó sin acceso al usar pam_tally.so pero un error al configurar pam_faillock tendría el mismo efecto.
6) Al igual que en el manual se especifica un caso en el que una configuración concreta puede llevar a que se pueda filtrar fuera del sistema qué cuentas existen y cuáles no, aplicar una configuración a algo tan importante como la autenticación requiere una mayor certeza, quizás la repetición de la información en dos ficheros genere una vulnerabilidad no conocida por el usuario o un problema en la autentificación que sólo sale a la luz en determinadas circunstancias.
Intenté seguir el manual de debian sobre faillock.conf y no hubo manera de que funcionase. Me funcionó exclusivamente el manual de linux.org que no seguía las directrices de no poner las opciones fuera de faillock. Creo que todo eso lo debería gestionar un programa externo, igual que se usa visudo para editar sudoers. Si hicieron ese cambio tendrían que haber documentado mejor el manual, introducido una herramienta para gestionarlo automáticamente y/o eliminar dependencias/referencias obsoletas de la configuración.
Pero quizás soy yo que soy raro...
#14 No me he encontrado con ese problema en Debian 11, al menos todavía
#6 GNU/Linux Debian tiene una versión estable muy segura, que más bien está enfocada a usar en servidores, pero puedes usar la versión testing que tiene el software mucho más actualizado y sigue siendo muy estable comparándola con Windows.
Yo uso GNU/Linux Debian testing todo el tiempo y nunca he tenido un problema que no haya podido solucionar en un rato.
Las distribuciones, cuanto más fáciles de usar por defecto son más inseguras son ya que la seguridad está siempre reñida con la facilidad de uso. No es lo mismo configurar una cosa desde una interfaz gráfica dándole a los botones que teniendo un conocimiento profundo de lo que estás haciendo y configurando las cosas a pelo, a mano.
user@debian:~$ cat /etc/debian_version
bookworm/sid
#9 en mi servidor empecé con debian stable, pero al cabo de poco ya ví que a) tenía que empezar a tirar seriamente de backports, y b) generar mis propios paquetes de las apps que no estaban en backports. Al final hice lo que no se deberia hacer: tengo un mix stable/testing (95/5), pero me quito dolores de cabeza.
#9 en mi servidor empecé con debian stable, pero al cabo de poco ya ví que a) tenía que empezar a tirar seriamente de backports, y b) generar mis propios paquetes de las apps que no estaban en backports. Al final hice lo que no se deberia hacer: tengo un mix stable/testing (95/5), pero me quito dolores de cabeza.
#6 Hay también una Debian sin Systemd, https://devuan.org
#6 ¿te importa compartir qué se te rompió con Arch? Porque en ~12 años que la llevo usando, tuve que hacer 2 apaños tras actualizar. Y esos apaños estaban publicados en la web de Arch a modo de "mira, para actualizar tienes que hacer esto también". Eso de "escasa expieriencia" y "a menudo se rompen las cosas" suena a triple
En algún servidor lo tengo puesto y 0 problemas.
#21 Pues no recuerdo mucho los detalles, apenas el programa que fallaba. En una ocasión una actualización de Mono rompió todo lo que estaba basado en ello (Sonarr, Radarr, etc. - esto fué antes del cambio a .NET). Creo que tenía que ver con un componente que se había separado del paquete principal y no se instalaba automáticamente. En otra una actualización de OpenSSH rompió el acceso remoto hasta que modifique las opciones que tenía puestas en el servidor.
Luego ya podemos hablar del dolor de cabeza del AUR, al que te ves obligado a acudir más de lo debido porque el repositorio oficial es realmente pequeño y tiene pocas cosas (al menos comparado con una Debian o similar).
#2 Steam deck supone como un 5% de las instalaciones de steam en linux según la última encuesta mensual de valve; no es mala cifra teniendo en cuenta que acaba de llegar y la disponibilidad de chips en un momento bastante complicado y tal, pero no tanto como para justificar un sorpaso. Por otro lado, el SO de steam deck se contabiliza por separado, así que son instalaciones de arch genuinas.
Otra cosa es que los desarrolladores que estén programando para deck al no tener acceso aún a steam os, usen arch como distro de desarrollo...
PD: veo que si están agrupando por ecosistemas, más que por distros. Me callo entonces...
#24 el cambio es que Arch sube un 0.53% en cambio Ubuntu (en general) sube un 5.51%
Así que.... Arch Linux no supera a Ubuntu ni de lejos.
Arch sin version = 12,85%
Ubuntu sin version = 11,75% + 8,04% = 19,79%
De hecho Ubuntu a subido en porcentaje. Y es normal que Ubuntu 20.04 baje cuando acaban de sacar una nueva versión de soporte extendido (LTS).
No sé si votar errónea o sensacionalista
#23 Creo que la lectura es más bien: "mira cómo va subiendo arch linux"
Además arch linux está muy bien para escritorio, pero no tiene nada que hacer en servidores, al menos de momento.
Yo la probé hace años y ya estaba bien. supongo que habrá evolucionado. A lo mejor la pruebo de nuevo.
Pero solamente este mes. Pasado mañana los distrohoppers estos se habrán cambiado a QuteOS, BSD, Elive o cualquier otra cosa que no sea mainstream