Opinión

¿Debe Debian cambiar? (Debate)

Creo que sí, al menos en algunos aspectos.

La filosofía debianita es muy férrea y a menudo infranqueable, pues posee unos estándares a los que se les pueden denominar como tradicionales.

Por todos sabemos que Debian tiene tres ramas: La estable, testing y la inestable, conocida también como Sid. La estable se basa en la filosofía de la estabilidad del software y el sistema en general, y es por ello por lo cual sus programas y bibliotecas son antiguos. Estas aplicaciones han sido probadas y existe una total confianza de que funcionan y son seguras. Estas características la hacen como una de las mejores distribuciones dedicadas a servidores o a usuarios que prefieren ante todo la estabilidad del sistema.

Las ediciones testing (en pruebas) e inestable se diferencian bastante de la estable y contienen el software más novedoso y actualizado. Ganan en frescura de sus programas pero pierden en estabilidad.

Entrar a fondo en la filosofía de Debian sería demasiado largo y podría aburrir, por lo que pasaremos de puntillas por los detalles. Resumidamente, el equipo que desarrollan Debian a lo largo del globo abrazan lo que se conoce como el contrato social de Debian cuyos puntos son:

  • Debian permanecerá 100% libre.
  • Contribuiremos a la comunidad de software libre.
  • No ocultaremos los problemas.
  • Nuestra prioridad son nuestros usuarios y el software libre.
  • Trabajos que no siguen nuestros estándares de software libre.

El quinto punto se refiere a que no se aceptan programas de código cerrado.

Los cinco puntos se cumplen a rajatabla pero no es oro todo lo que reluce. Hay ciertos aspectos que son manifiestamente mejorables pero las cadenas que arrastran muchos desarrolladores de Debian, su tradicionalismo, impiden que la modernidad haga avanzar al uso de esta distribución. Es fundamental que se cumplan los cincos puntos del contrato social, pero debe de llevarse hasta  el fin. Si por ejemplo el cuarto punto dice que nuestra prioridad son nuestros usuarios y el software libre, ¿por qué se aferran a no actualizar KDE Plasma, GNOME y otros escritorios a las versiones que se van liberando? ¿no es suficiente con Debian estable para conservar el software más antiguo y probado? ¿Por qué incluso se quiere impedir que algunos desarrolladores trabajen en mantener KDE Plasma actualizado en testing y Sid? ¿No incluye esa prioridad ante los usuarios implementar un inicio alternativo a systemd?

0 0 votes
Article Rating

Relacionados

Subscribe
Notify of
guest
24 Comentarios
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Dainori

Quizá Debian debería disponer de las últimas versiones de todos los escritorios en Testing/Sid. Sería perfecto y sin duda los usuarios estaríamos más contentos. Sin embargo, creo que debe ser más una cuestión de recursos que de política. No es que no quieran que tengamos lo último, si no que no tienen suficientes empaquetadores para soportar el ciclo de publicación de los escritorios al 100%. Imagino que ya deben tener que mantener muchísimos paquetes por cada voluntario (o trabajador).

Dainori

Vaya, lo he leido y es una pena. Del texto se desprenden la amargura y el hartazgo. Suena a que hay normas “difusas” que no son para todos (si caes bien) y que las antipatías del “grupito” de turno pesan más que el trabajo bien hecho. Error mio opinar sin informarme antes y también por pecar de ingenuo. Hasta en la más pequeña asociación de un pueblo hay mamoneo, y yo pensando que en Debian todo sería mejor.

Un saludo, gracias por hacer este blog, y SI, Debian debería cambiar.

Anónimo

Sí, debería de adoptar por defecto el escritorio KDE.

que redhad no se adueñe de todo

Systemd es un ladrillo tan grande, complejo y deseoso de generar dependencias que deja la GPL y libertades 1 y 3 en poco más que papel mojado. Por no hablar de que su única razón de ser es usar llamadas en lugar de enlaces para que redhad pueda eludir la licencia y no proporcionar el código fuente. Al infierno con systemd, en debian no deberían preocuparse por no perder los valores, sino por recuperarlos.

Marcelo

El código de systemd está disponible en Github…

Si systemd viola las libertades 1 y 3 entonces como es que existen forks del mismo?

De la que deberíamos preocuparnos para que no se adueñe de todo es Canonical con sus decisiones cuestionables de desarrollo y de implementación en GNU/Linux, no de Red Hat.

Quiero creer que los anti-systemd por lo menos son anti-snap también, ya que ahí el motivo del rechazo sería justificado al ser este tipo de paquetería privativo del lado del servidor.

Echedenyan

Pero intentamos ser POSIX por el bien de la compatibilidad global.

l1ch

GNU nació para ser un clon libre de Unix…

que redhad no se adueñe de todo

¿Quién ha dicho que la viole o no se puedan hacer folks? Poder ver un determinado software que casi nadie entiende o modificarlo a pesar de romper con medio sistema y aplicaciones no viola la gnu, pero la devalúa (y mucho) si se pretende ser abierto y comunitario, con unix hacen un matrimonio perfecto.

PD: Quema ese snapd y dame mis repositorios.

Marcelo

Que algo sea modularizable como UNIX no necesariamente implica que sea mejor. Ambos inits tienen distintos enfoques a la hora de hacer las cosas. Para mi, cosas como “el sistema arranca 2 segundos mas rapido con cualquier otro init” no es un argumento convincente.

Acaso no provee systemd ya una basta documentacion de su codigo? Digo, como referencia para devs.

l1ch

Signal tiene su código disponible, es GPL, y aún así es privativo…

Marcelo

Cual de las 4 libertades viola Signal?

l1ch

Todo explicado per se en este hilo:

https://github.com/LibreSignal/LibreSignal/issues/37

Marcelo

Yo creo que una cosa mejorable de la versión estable es que suban de tanto en tanto bugfixes, porque por mas seguros de que la rama testing ya está lista para ser estable estén, siempre alguna cosita se les escapa que luego termina afectando en cierto modo la experiencia de usuario.

Por ejemplo, la versión Cinnamon de Debian 10, arrastra un bug molesto desde que salió: el botón de “Abrir nueva terminal” cuando haces click derecho no funciona. Es porque la terminal de gnome o tilix (la de Cinnamon) no están instaladas. El usuario tiene que instalarse una de ellas a mano para que el botón funcione.

O la versión XFCE, que viene con un problema jodido para los procesadores intel: pones la PC en suspenso y la pantalla se queda completamente en negro cuando querés volver a usarla luego. Necesitas modificar Xorg vos mismo para corregir el error.

Algo que creo que también es mejorable es lo que vos dijiste: ciertamente no veo razón para dejar estatico el entorno de escritorio en una versión vieja. Pienso que, si van a hacer eso, deberían considerar usar versiones LTS de los mismos si tienen. Como en el caso de KDE Plasma, que dejaron la estable con 5.14 y justo esa versión no lts tiene un bug molesto en Discover, aunque solucionable, pero hay que hacerlo cada vez vas a actualizar el sistema.

Respecto a los inits… me la suda olimpicamente si lo cambian o no, siempre y cuando funcione bien. Creo que lo mejor es considerar añadir un init alternativo aparte de ofrecer systemd.

Nachete Page

Pa mi gusto creo que Debian peca por “demasiada prudencia” a la hora de actualizar cierto software o paquetes, aunque me choca que haya algunos unos bugs de la ostia : hace unos meses para un SERVER con el paquete para dhcp por ejemplo, y eso que habían subido la última versión.

Desde mi humilde opinion creo que es por falta de una finaciación estable o suficiente. De tener mas dinero los programadores podrían pulir el codigo fuente, mejorar bugs, implementar el kernels con mas seguridad …

Con respecto a los escritorios, KDE no es un escritorio precisamente ligero y tal vez no se quieran pillar los dedos a la hora de la estabilidad del sistema. Probablemente vayan por ahí los tiros, pero si Debian tuviera una mayor financiación tal vez se animarían a “echarle” mas horas de trabajo y, tal vez, darle un toque mas actual.

Yo al menos lo veo así …

Lawrence

Debían ya no es lo que era, una pena.

Geoda

Lo que ningún usuario final entiende es que solamente hay una edición de Debian: la estable. Oldstable obviamente es de mantenimiento y testing, sid y experimental son herramientas de Debian para preparar su edición stable.

Se pueden usar esas versiones integramente o como partes, por supuesto. Pero no es el objetivo por parte de la distribución.

Es un error pedirle cosas a esas ramas, cuando ni siquiera son una distro en si misma y el que las use lo hace bajo su responsabilidad. Rama no es igual que edición.

Debian es oldschool al igual que slackware. No pedirle peras al olmo y no criticarla por lo mismo que se la alaba.

Hay mil distros que cubren ese nicho. Usadlas. Esta cubre otro.

Venom

La velocidad en que actualizan software y parches de seguridad es muy lenta en debian. Es el único punto en contra que le veo. A veces parecen ser muy conservadores.

baron ashler

Yo creo que deberian hacer una version estable servidor y otra escritorio, esta ultima la cual si aceptaria actualizaciones estables de escritorios, navegadores y otras chucherias, pero dejando el kernel y la base estable como la servidor.

Ivan Urgell

La verdad es que no opinare sobre las “polémicas” respecto a si dejan o no dejan trabajar respecto a el mantener al día ciertos paquetes u otros… Por una simple razón, mi desconocimiento al respecto.

Aunque si que me gustaría comentar algo respecto a algo que al menos en mi experiencia mucha gente desconoce… Y es la posibilidad que te ofrece “preferences” (/etc/apt/preferences), dejo links justo debajo… Ademas he dejado un pequeño ejemplo muy básico en un fichero adjunto.
https://wiki.debian.org/es/AptPreferences
https://wiki.debian.org/AptConfiguration

Y la verdad es que la posibilidad que te da para “montarte” tu configuración personalizada de gestión de paquetes según versiones y repositorios asignando una prioridad me parece simple y llanamente fantástica.
Sin embargo tengo algunas pegas, y es que si por ejemplo pongamos que yo quiero tener la versión “inestable” de “krita” por ejemplo, puedo asignar una prioridad mayor a el paquete que se encuentra en el repositorio “inestable”, hasta ahí todo bien… El problema es que si este paquete necesita dependencias, en concreto cuando necesita MUCHAS dependencias que se mantengan a una versión superior a la que se encuentra en el repositorio “estable”…
Tengo que añadirlas una a una, paquete a paquete, o al menos yo no he encontrado una manera de indicar que ese paquete y todas sus dependencias que este necesite…
Y obviamente es un coñazo, que haber sinceramente entiendo que puede llegar a ser “peligroso”, pero al final cuando configuras este tipo de cosas tienes que tener el cuidado suficiente, y si metes la pata… Pues ajo y agua compañero.
Creo sinceramente que debería de haber un parámetro o algo que te permitiera configurar dicha prioridad de manera “recursiva”.

Este sitio web utiliza cookies para mejorar tu navegación. Si las cookies no son de tu agrado, usa alguna herramienta para eliminarlas. Aceptar Seguir leyendo

Privacidad y política de Cookies
24
0
Would love your thoughts, please comment.x
()
x