El 28 de febrero, como era previsto, se lanzó la versión de desarrollo de lo que será Fedora 17 Beefy Miracle. La nueva entrega contará con una interesante serie de cambios en gran parte del sistema, desde la ubicación de directorios del sistema a mejor desempeño del escritorio.
Para empezar uno de los cambios, quizás el más llamativo, es el mover, básicamente, todo el sistema a /usr. Los directorios /bin, /sbin, /lib y /lib64 ya no estarán en el directorio raíz sino en /usr. Sin embargo, para evitar conflictos, se mantendrán la ubicación de dichos directorios pero haciendo uso de enlaces simbólicos.
Otro cambio corresponde a quitar el soporte a controladores de video 3D viejos . Mencionan entre ellos: i810, mga, r128, savage, sis, tdfx y unichrome. Esto no será un problema pues, en primer lugar, ya no reciben soporte oficial y, en segundo lugar, no son compatibles con GNOME Shell y, posiblemente, tampoco lo serán con KDE. Sin embargo, remarcan en la wiki, los controladores 2D de dichas tarjetas seguirán siendo soportados.
También ya ha sido agregado el soporte multitouch. Esto hace que Fedora sea, a partir de ahora, oficialmente compatible a esta tecnología aunque de mucho dependerá de las aplicaciones que aprovechan esta capacidad.
Por otro lado, la lista de cambios se hace mucho más extensa al hablar de lo que está en proceso y lo que aún no se ha hecho y se piensa hacer. Algunos de ellos son utilizar como medio de creación de imágenes de CD a Anaconda, desplazando a livecd-creator. Además, se incluirá GIMP 2.8, la tan esperada versión que dice estar ya lista para ser lanzada.
El equipo de Fedora planea lanzar la beta el 3 de abril y, finalmente, la versión final el 8 de junio. Así que os invito a probar el nuevo lanzamiento de una gran distribución.
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-Desktop.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-Desktop.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-KDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-KDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-LXDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-LXDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-XFCE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-XFCE.iso
En oposicion a la idea de cambiar la jerarquia de directorios, encontré un post en un blog, que explica y dice que es un error, asi como tambien una mentira, pongo la info aquí
UsrMove, la mentira
Muy a mi pesar, es que hago este post. Digo esto, basicamente, porque no me gusta criticar la distro que uso y apoyo sus deciciones, pero en esta ocasion, debo hacer una crítica constructiva a la misma, asi como dar mi punto de vista sobre la gran mentira del verdadero motivo de usrmove. Para los que dijeron que no era objetivo, o era un fanboy, bueno, hasta aqui llego su fundamento.
Si no se dieron cuenta, si, estoy hablando de Fedora, mas precisamente, Fedora 17 que aun no sale, pero ya tienen un Alpha disponible.
Existe algo llamado vulgarmente «usrmove», que es uno de los «features» de F17, y consiste en mover /bin /sbin /lib /lib64 dentro de /usr/bin /usr/sbin /usr/lib /usr/lib64. O sea, todo lo que está historicamente en /, meterlo en /usr.
En esta entrada, explica desde mi punto de vista, porque esto no debe hacerse, y los motivos reales por los cuales creo que harán esto.
Primeramente, deberian leer, este documento que está en ingles en_US
http://fedoraproject.org/wiki/Features/UsrMove
Antes que nada, voy a pedir que lean bien las referencias de la wiki, asi como los motivos, aunque yo traduciré los importantes y los pondré aquí.
«Benefit to Fedora
--Simpler and cleaner overall file system layout, with full compatibility.
--Clear separation of operating system and host specific resources.
--Improve compatibility with other Unixes/linux, no confusion about tools install locations, no $PATH fiddling, all possible paths to a binary will always work. All binaries will be available on both /usr and / thus minimizing compatibility problems.
--Improve compatibility with build systems such as GNU autotools who never have been aware of the /usr split in the first place
--Minimize difference to other Unixes, such as Solaris, which already did the same move
--Isolate the vendor-supplied mostly read-only operating system resources from the rest, thus allow snapshotting of the OS, and easy lightweight container OS duplication»
Traduccion y Respuesta
«Beneficios para Fedora:
* Disposicion de sistema de archivos mas simple y limpia, con compatibilidad completa
* Clara separacion del sistema operativo, y recursos especificos del host (o sea, el usuario en si)
* Mejoramiento de compatibilidad con otros Unixes/Linux, sin confusion acerca de -el lugar donde se instalan las herramientas-, no hay path triviales, todos los path posibles a un binario siempre van a funcionar. Todos los binarios estarán disponibles tanto en /usr como en / minimizando asi, problemas de compatibilidad
* Mejora compatibilidad con -build systems- como GNU autotools, que nunca estuvo al tanto de la division de /usr en primer lugar
*Aislar los recursos del sistema operativo mayormente read-only suministrados por el proveedor, del resto. Por ende permite realizar snapshot del OS, y facilmente aligerar el contenedor de la duplicacion del OS.»
Analizemos estos items uno a uno, y recordemos el nivel de importancia que conlleva cada punto, porque luego lo compararemos con la carga de trabajo que implica este cambio, y las contras.
* Disposicion de sistema de archivos mas simple y limpia, con compatibilidad completa
Realidad: La disposicion del sistema de archivos actual, es acorde al FHS standard. Es el mismo usado por NetBSD, FreeBSD y OpenBSD, los Unixes mas puros, y el ultimo, el mas seguro.
Limpia?, que tiene de limpio mezclar el «core» del sistema (/bin) con los archivos instalados por el usuario para sus aplicaciones?. La compatibilidad completa ya existe, los Linux y Unix mas conocidos usan este FHS Standard. Linus Torvalds tomo esta jerarquia de archivos de Minix, el cual es un OS basado en BSD, con fines educativos, por tanto, se podria decir que Linux, es Unix-Like.
* Clara separacion del sistema operativo, y recursos especificos del host (o sea, el usuario en si)
Realidad: La clara separacion, radica en que el «core» del sistema, se encuenta en / y las cosas del host o usuario en /usr, con la replicacion de los binarios importantes, como si se un chroot se tratase.
* Mejoramiento de compatibilidad con otros Unixes/Linux, sin confusion acerca de -el lugar donde se instalan las herramientas-, no hay path triviales, todos los path posibles a un binario siempre van a funcionar. Todos los binarios estarán disponibles tanto en /usr como en / minimizando asi, problemas de compatibilidad
Realidad: El unico Unix-like que usa este sistema es Solaris 11, acaso Fedora usa muchas cosas de Solaris 11?. Ni siquiera plan9 utiliza usrmove.
No existe confusion alguna en «donde se instalaran las herramientas» actualmente, justamente, por el motivo de que el actual FHS de Linux, es un standard identico a UNIX, y que siguen el resto de las distro GNU/Linux. Actualmente todos los PATH a un binario funcionan, solo que no es lo mismo /usr/local/bin que /bin, entienden el porque, no es verdad?, el primero es del o los usuarios, y el segundo de «rootfs».
Mentira!, todos los binarios no estarán disponibles en / como en /usr, ayer mismo me tome el trabajo de iniciar un Fedora 17, que segun se indica esto ya esta al 100% completo, y no existe UN solo binario en /, sino symlink hacia /usr. Porque mienten?.
* Mejora compatibilidad con -build systems- como GNU autotools, que nunca estuvo al tanto de la division de /usr en primer lugar
Realidad: Actualmente se usa GNU autotools y no hay problema alguno con / y /usr.
*Aislar los recursos del sistema operativo mayormente read-only suministrados por el proveedor, del resto. Por ende permite realizar snapshot del OS, y facilmente aligerar el contenedor de la duplicacion del OS.
Realidad: No son mayormente read-only, y si inician un Fedora 17, veran que no esta montado en read-only, esto no es real. Aligerar en que?, en la no duplicacion de unos, 20mb?, creo que actualmente, eso no es problema, quiza lo era en el año 1993, hoy en dia, los discos rigidos y unidad de backup son mucho mas baratas.
Como pudieron leer hasta aqui, lo unico que se pueden ver, son excusas, asi es señores, son excusas, no veo un beneficio claro, pero en contraposicion, veo una horrenda asquerosidad, rompiendo el FHS Standard, y el mismo FHS que usan los Unixes. No sabia que los Unixes eran solo Solaris 11, que bueno saberlo, ire a modificar la wikipedia - sacarsmo on -
Aqui va la otra parte de los "motivos"
«Scope
--The ability to share /usr is especially useful for clusters and virtual machines.
--The ability to mount /usr read-only (e.g. on read-only media) can add to the security of the machine.
--The entire /usr can safely be snapshotted during upgrades.»
Traduccion y Respuesta
* La habilidad de compartir /usr es especialmente util para clusters y maquinas virtuales
* La habilidad de montar /usr en read-only (por ejemplo, sobre un medio read-only) agrega seguridad
* El completo /usr puede ser snapshotted de forma segura duramente upgrades
Respuesta a las mentiras
* La habilidad de compartir /usr es especialmente util para clusters y maquinas virtuales
Realidad: Actualmente, los cluster no tienen el mas minimo inconveniente en compartir /usr, y tampoco las maquinas virtuales, por algo /bin y /sbin estan replicados dentro de el.
* La habilidad de montar /usr en read-only (por ejemplo, sobre un medio read-only) agrega seguridad
Realidad: No lo hace, actualmente, se podia montar / y /usr por separado, como uno quisiera, sin perder el «core» del sistema, pero claro, systemd tiene problemas con ello, Ups!, se me escapó!.
* El completo /usr puede ser snapshotted de forma segura duramente upgrades
Realidad: Actualmente el /usr tambien puede hacer eso
Como ven, otra vez, excusas y problemas irreales a cosas que no existen.
Trabajo a realizar por este cambio
Debido a este cambio, deberán rediseñar el sistema de construccion de RPM, el archivo .spec, y hacer algunos hacks, para que los empaqueradores construyan RPM's que se acomoden a le jerarquia de directorios propuesta.
Modificar el metodo de construccion en Koji, el servidor build-system de Fedora.
Cruzar los dedos para que aplicaciones antiguas al ser compiladas usando make, funcionen.
Reescribir los documentos sobre construccion de RPM's
Ignorar todo PDF o guia de construccion de RPM que hayan aprendido (si, ustedes los usuarios)
Modificar YUM, el package manager de Fedora
Recompilar los RPM de Fedora 17
Mitos y verdades
Siguiendo con el analisis, a esta altura, se preguntaran, entonces, porque van a mentir y poner excusas irreales solo para hacer ese cambio?, bueno, antes de responder eso, debo mostrar algunas cosas mas, no dejen de leer y entender.
Uno de los link de referencia de la wiki de Fedora «usrmove», hace referencia a la wiki de openSUSE, donde en un apartado, explica el como y porque del cambio, algo que ellos tambien tienen en mente. Solo que esta mejor explicado y cita una fuente, de una lista de mail de BusyBox, donde un developer, explica el porque el spliteo de /bin /sbin /usr/bin /usr/sbin y asi, os dejo el link aqui mismo:
Link de openSUSE: http://en.opensuse.org/openSUSE:Usr_merge
Link al que refiere openSUSE y explica el porque: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
Basicamente, y en resumidas cuentas, la explicacion del developer, dice que la situacion fue esta:
«En la epoca que Ken Thompson y Dennis Ritchie crearon UNIX, las unidades de disco, eran costosas y pequeñas, de tan solo 1.5MB, por lo cual, cuando terminaron de crear el sistema, este cabia en un disco entero, pero solo hasta el /, para continuar con los archivos de usuario, debieron atachar otro disco de 1.5MB, y crearon el /usr, con la replica de contenidos del primer disco.
Luego fue creado el /home de forma intencional, pero, segun la explicacion, si Dennis y Ken hubieran tenidos discos como los de hoy en dia, hubieran metido todo dentro de un solo /usr.
Segun la explicacion, durante años, se siguio tomando el mismo modelo, por cuestiones burocraticas, y nadie se cuestiono el porque de este spliteo, asi como tampoco se lo cuestiono la Linux Foundation, la cual tiene en mayoria, voz y voto sobre el FHS Standard.
Segun lo que dice, al dia de la fecha, no tiene sentido alguno este spliteo, que solo proviene de cuestiones historicas y burocraticas. Luego, AT&T y otros, encontraron excusas a esto, como que el core del sistema estaria en / y el resto que el cliente elija instalar, en /usr»
Esta es la famosa explicacion corta, que nadie explica realmente, sobre la «cuestion historica» del spliteo
Errores en la historia y verdades
1) El pack de discos mencionado, no era de 1.5MB sino de 2.5MB, craso error, algo huele mal, no?
2) Alguna vez, Ken o Dennis dijeron eso?, no que yo sepa, entonces, como es que afirman algo sobre hipotesis y no sobre hechos reales?
3) La mayoria de los inventos y descubrimientos fueron por accidente. Si realmente esto fue asi y luego si se le encontro utilidad a este spliteo y por eso se conserva?
Actualmente, HP-UX, OpenBSD, FreeBSD, NetBSD, IRIX, AIX, usan / y /usr, siendo estos, los mas puros UNIX que aun sobreviven, y siendo Linux, Unix-Like, creo que esta bien que copie la jerarquia del sistema de archivos de sus abuelos.
Tomo como referencia, una captura de pantalla que realice en un OpenBSD5, instalado por mi, en VirtualBox, en el cual se ve, el kernel, la existencia de /bin /sbin /lib, y el resto de directorios.
Ahora, los invito a la reflexion. Un tipo como Theo de Raadt, el cual ha insultado a Torvalds, a los Core2Duo de Intel, y dice lo que piensa, incluso eso le causo la perdida de donaciones de parte de US, creen que si el viera algo mal o que se pudiera mejorar, no lo habria hecho?, solo piensen eso
Notese la existencia de /bin /sbin /lib
Para continuar con las incongruencias, tenemos a freedesktop.org, donde comentan en sus «fact», que el original UNIX, tenia un /bin, si, pero era SOLO un symblink hacia /usr.
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
Myth #6: A split /usr is Unix “standard”, and a merged /usr would be Linux-specific
Fact: On SysV Unix /bin traditionally has been a symlink to /usr/bin. A non-symlinked version of that directory is specific to non-SysV Unix and Linux.
Por si no lo notaron, esto es una mentira, no solo por la prueba real de algun UNIX que este corriendo en alguna casa o empresa, sino por el hecho, de que Dennis y Ken, contenian en / todas las herramientas necesarias para poder montar el segundo disco que contenia /usr, por tanto, si /bin es solo un symblink, como dice freedesktop, como es que montaba el segundo disco?, recuerden que un symblink, es un link simbolico a una ruta o destino real, pero si el disco no esta montado, como puede ser esto real?, wow, ahora si que metieron la pata con sus mentiras no es verdad?, claro que si.
Tomando en cuenta el error al mentir, en el articulo freedesktop, la explicacion sin la palabra de Dennis o Ken del developer de BusyBox, asi como las excusas falsas de Fedora, y si leen mas abajo, la evasion constante en las FAQ, todo me lleva a pensar que esto es por algo que aun nadie nos dice.
Aunque el «owner» en la wiki de Fedora, es Harald Hoyer, un empleado de RedHat, el iniciador de este cambio, y la idea principal, fue del creador de systemd, el mismo creador de pulseaudio (si, esa basura), el fantastico Lennart Poettering, adivinaron!, el chico mavarilla.
Como habrán visto, systemd tiene problemas con / y /usr, y seguramente, cuando fue programado y pensado, Lennart, asumio que todo el mundo seguia el esquema de particionado sugerido por Anaconda, el instalador de Fedora, pero seguro comenzo a ver bug report en bugzilla, acerca de informes de error, en sistemas instalados con / y /usr por separado.
La gran estafa
Ahora, pensemos, que es más facil, arreglar systemd (que quiza no se pueda), y reconocer que lo que se coloco en Fedora 15 y 16, para reemplazar Upstart tiene un bug enorme. Liberar Fedora 17 con Upstart de nuevo, o con init en el peor de los casos, o mover todo a /usr para arreglar el bug de systemd, cubrir a Lennart, y quedar bien con todos?, yo me inclino a pensar, quiza me equivoque, que el motivo de «usrmove» es ese, tapar el error de Lennart.
Segun dice la wiki de Fedora, estará presente en RHEL7, realmente, lo dudo y me rio en sus caras (a menos que quieran perder clientes), dado que un bien sysadmin, con LPI y demas certificados, no va a permitir que conviertan su Unix-Like en un Windows-Like.
Segun el encargado de «usrmove», para reemplazar lo que habia en /, se creara un initramfs de mas tamaño, que contenga los comandos basicos para recuperar un sistema, o bootear en modo monousuario, y solo necesitar el / (algo que si hago y creo que muchos hacen para tareas administrativas).
Y el mismo estaria contenido en /boot. La explicacion de esto, es que conservar / para reparar /usr en caso de corrupcion, no tiene sentido, dado que dependemos de /boot para el inicio y /, con lo cual, es mas optimo (esto si lo comparto), que todo este en /boot, donde vive el kernel, para poder asi reparar / y /usr o lo que fuera, con un initramfs engordado que contenga los comandos que estan en /bin y /sbin. Mi pregunta es, que pasa con las updates que actualizan algunos de esos comandos?, ahora debera actualizar un initramfs?, que debe ser compatible claro, con el kernel del sistema, a la larga, este modelo, va a ser mas complejo.
Desde mi punto de vista, seria mejor un initramfs con los modulos necesarios para montar y cargar binarios de /boot/system por ejemplo, donde se alojen los binarios que ahora se encuentran en /bin y /sbin. Algo mas parecido a GoboLinux.
Y ahora?
Que haremos?, nada, cruzar los dedos para que las soluciones de Fedora funcionen como antes, que no traiga problemas de seguridad, y convivir con un Windows-Like.
Pero... siempre tendremos Paris, perdón, quise decir, RHEL.
Y si RHEL tambien se convierte en eso?, bueno, siempre tendremos *BSD y Gentoo!
PD: Muchos usuarios de UNIX y Linux, con mas de 50 años, incluso en los canales de #fedora y #rhel, gente que usa *nix desde el año 92, me comento acerca de su descontento con esto, y que si pudieran votarian en contra, pero claro, nadie les consulto, todo sea por tapar el error de Lennart
PD2: Solaris, hace 15 años que viene trabajando en esto, y recien se implemento en Solaris 11. Pero posee una cantidad de mecanismos de recuperacion, diagnostico y analisis, que no posee Linux, sin contar, con el soporte nativo de ZFS, lo que implica, una falla casi imposible en su sistema de archivos, algo que Linux no posee. Por el momento, solo tiene Ext4, y el futuro BTRFS que esta en la rama experimental, propuesto para Fedora 18, otro gran error.
Eso es todo, agradeceria comentarios, pero con fundamentos y razones, luego de haber leido todo el post y la documentacion que cito en el mismo.
Para empezar uno de los cambios, quizás el más llamativo, es el mover, básicamente, todo el sistema a /usr. Los directorios /bin, /sbin, /lib y /lib64 ya no estarán en el directorio raíz sino en /usr. Sin embargo, para evitar conflictos, se mantendrán la ubicación de dichos directorios pero haciendo uso de enlaces simbólicos.
Otro cambio corresponde a quitar el soporte a controladores de video 3D viejos . Mencionan entre ellos: i810, mga, r128, savage, sis, tdfx y unichrome. Esto no será un problema pues, en primer lugar, ya no reciben soporte oficial y, en segundo lugar, no son compatibles con GNOME Shell y, posiblemente, tampoco lo serán con KDE. Sin embargo, remarcan en la wiki, los controladores 2D de dichas tarjetas seguirán siendo soportados.
También ya ha sido agregado el soporte multitouch. Esto hace que Fedora sea, a partir de ahora, oficialmente compatible a esta tecnología aunque de mucho dependerá de las aplicaciones que aprovechan esta capacidad.
Por otro lado, la lista de cambios se hace mucho más extensa al hablar de lo que está en proceso y lo que aún no se ha hecho y se piensa hacer. Algunos de ellos son utilizar como medio de creación de imágenes de CD a Anaconda, desplazando a livecd-creator. Además, se incluirá GIMP 2.8, la tan esperada versión que dice estar ya lista para ser lanzada.
El equipo de Fedora planea lanzar la beta el 3 de abril y, finalmente, la versión final el 8 de junio. Así que os invito a probar el nuevo lanzamiento de una gran distribución.
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-Desktop.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-Desktop.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-KDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-KDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-LXDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-LXDE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/i686/Fedora-17-Alpha-i686-Live-XFCE.iso
http://fedora.c3sl.ufpr.br/linux/releases/test/17-Alpha/Live/x86_64/Fedora-17-Alpha-x86_64-Live-XFCE.iso
En oposicion a la idea de cambiar la jerarquia de directorios, encontré un post en un blog, que explica y dice que es un error, asi como tambien una mentira, pongo la info aquí
UsrMove, la mentira
Muy a mi pesar, es que hago este post. Digo esto, basicamente, porque no me gusta criticar la distro que uso y apoyo sus deciciones, pero en esta ocasion, debo hacer una crítica constructiva a la misma, asi como dar mi punto de vista sobre la gran mentira del verdadero motivo de usrmove. Para los que dijeron que no era objetivo, o era un fanboy, bueno, hasta aqui llego su fundamento.
Si no se dieron cuenta, si, estoy hablando de Fedora, mas precisamente, Fedora 17 que aun no sale, pero ya tienen un Alpha disponible.
Existe algo llamado vulgarmente «usrmove», que es uno de los «features» de F17, y consiste en mover /bin /sbin /lib /lib64 dentro de /usr/bin /usr/sbin /usr/lib /usr/lib64. O sea, todo lo que está historicamente en /, meterlo en /usr.
En esta entrada, explica desde mi punto de vista, porque esto no debe hacerse, y los motivos reales por los cuales creo que harán esto.
Primeramente, deberian leer, este documento que está en ingles en_US
http://fedoraproject.org/wiki/Features/UsrMove
Antes que nada, voy a pedir que lean bien las referencias de la wiki, asi como los motivos, aunque yo traduciré los importantes y los pondré aquí.
«Benefit to Fedora
--Simpler and cleaner overall file system layout, with full compatibility.
--Clear separation of operating system and host specific resources.
--Improve compatibility with other Unixes/linux, no confusion about tools install locations, no $PATH fiddling, all possible paths to a binary will always work. All binaries will be available on both /usr and / thus minimizing compatibility problems.
--Improve compatibility with build systems such as GNU autotools who never have been aware of the /usr split in the first place
--Minimize difference to other Unixes, such as Solaris, which already did the same move
--Isolate the vendor-supplied mostly read-only operating system resources from the rest, thus allow snapshotting of the OS, and easy lightweight container OS duplication»
Traduccion y Respuesta
«Beneficios para Fedora:
* Disposicion de sistema de archivos mas simple y limpia, con compatibilidad completa
* Clara separacion del sistema operativo, y recursos especificos del host (o sea, el usuario en si)
* Mejoramiento de compatibilidad con otros Unixes/Linux, sin confusion acerca de -el lugar donde se instalan las herramientas-, no hay path triviales, todos los path posibles a un binario siempre van a funcionar. Todos los binarios estarán disponibles tanto en /usr como en / minimizando asi, problemas de compatibilidad
* Mejora compatibilidad con -build systems- como GNU autotools, que nunca estuvo al tanto de la division de /usr en primer lugar
*Aislar los recursos del sistema operativo mayormente read-only suministrados por el proveedor, del resto. Por ende permite realizar snapshot del OS, y facilmente aligerar el contenedor de la duplicacion del OS.»
Analizemos estos items uno a uno, y recordemos el nivel de importancia que conlleva cada punto, porque luego lo compararemos con la carga de trabajo que implica este cambio, y las contras.
* Disposicion de sistema de archivos mas simple y limpia, con compatibilidad completa
Realidad: La disposicion del sistema de archivos actual, es acorde al FHS standard. Es el mismo usado por NetBSD, FreeBSD y OpenBSD, los Unixes mas puros, y el ultimo, el mas seguro.
Limpia?, que tiene de limpio mezclar el «core» del sistema (/bin) con los archivos instalados por el usuario para sus aplicaciones?. La compatibilidad completa ya existe, los Linux y Unix mas conocidos usan este FHS Standard. Linus Torvalds tomo esta jerarquia de archivos de Minix, el cual es un OS basado en BSD, con fines educativos, por tanto, se podria decir que Linux, es Unix-Like.
* Clara separacion del sistema operativo, y recursos especificos del host (o sea, el usuario en si)
Realidad: La clara separacion, radica en que el «core» del sistema, se encuenta en / y las cosas del host o usuario en /usr, con la replicacion de los binarios importantes, como si se un chroot se tratase.
* Mejoramiento de compatibilidad con otros Unixes/Linux, sin confusion acerca de -el lugar donde se instalan las herramientas-, no hay path triviales, todos los path posibles a un binario siempre van a funcionar. Todos los binarios estarán disponibles tanto en /usr como en / minimizando asi, problemas de compatibilidad
Realidad: El unico Unix-like que usa este sistema es Solaris 11, acaso Fedora usa muchas cosas de Solaris 11?. Ni siquiera plan9 utiliza usrmove.
No existe confusion alguna en «donde se instalaran las herramientas» actualmente, justamente, por el motivo de que el actual FHS de Linux, es un standard identico a UNIX, y que siguen el resto de las distro GNU/Linux. Actualmente todos los PATH a un binario funcionan, solo que no es lo mismo /usr/local/bin que /bin, entienden el porque, no es verdad?, el primero es del o los usuarios, y el segundo de «rootfs».
Mentira!, todos los binarios no estarán disponibles en / como en /usr, ayer mismo me tome el trabajo de iniciar un Fedora 17, que segun se indica esto ya esta al 100% completo, y no existe UN solo binario en /, sino symlink hacia /usr. Porque mienten?.
* Mejora compatibilidad con -build systems- como GNU autotools, que nunca estuvo al tanto de la division de /usr en primer lugar
Realidad: Actualmente se usa GNU autotools y no hay problema alguno con / y /usr.
*Aislar los recursos del sistema operativo mayormente read-only suministrados por el proveedor, del resto. Por ende permite realizar snapshot del OS, y facilmente aligerar el contenedor de la duplicacion del OS.
Realidad: No son mayormente read-only, y si inician un Fedora 17, veran que no esta montado en read-only, esto no es real. Aligerar en que?, en la no duplicacion de unos, 20mb?, creo que actualmente, eso no es problema, quiza lo era en el año 1993, hoy en dia, los discos rigidos y unidad de backup son mucho mas baratas.
Como pudieron leer hasta aqui, lo unico que se pueden ver, son excusas, asi es señores, son excusas, no veo un beneficio claro, pero en contraposicion, veo una horrenda asquerosidad, rompiendo el FHS Standard, y el mismo FHS que usan los Unixes. No sabia que los Unixes eran solo Solaris 11, que bueno saberlo, ire a modificar la wikipedia - sacarsmo on -
Aqui va la otra parte de los "motivos"
«Scope
--The ability to share /usr is especially useful for clusters and virtual machines.
--The ability to mount /usr read-only (e.g. on read-only media) can add to the security of the machine.
--The entire /usr can safely be snapshotted during upgrades.»
Traduccion y Respuesta
* La habilidad de compartir /usr es especialmente util para clusters y maquinas virtuales
* La habilidad de montar /usr en read-only (por ejemplo, sobre un medio read-only) agrega seguridad
* El completo /usr puede ser snapshotted de forma segura duramente upgrades
Respuesta a las mentiras
* La habilidad de compartir /usr es especialmente util para clusters y maquinas virtuales
Realidad: Actualmente, los cluster no tienen el mas minimo inconveniente en compartir /usr, y tampoco las maquinas virtuales, por algo /bin y /sbin estan replicados dentro de el.
* La habilidad de montar /usr en read-only (por ejemplo, sobre un medio read-only) agrega seguridad
Realidad: No lo hace, actualmente, se podia montar / y /usr por separado, como uno quisiera, sin perder el «core» del sistema, pero claro, systemd tiene problemas con ello, Ups!, se me escapó!.
* El completo /usr puede ser snapshotted de forma segura duramente upgrades
Realidad: Actualmente el /usr tambien puede hacer eso
Como ven, otra vez, excusas y problemas irreales a cosas que no existen.
Trabajo a realizar por este cambio
Debido a este cambio, deberán rediseñar el sistema de construccion de RPM, el archivo .spec, y hacer algunos hacks, para que los empaqueradores construyan RPM's que se acomoden a le jerarquia de directorios propuesta.
Modificar el metodo de construccion en Koji, el servidor build-system de Fedora.
Cruzar los dedos para que aplicaciones antiguas al ser compiladas usando make, funcionen.
Reescribir los documentos sobre construccion de RPM's
Ignorar todo PDF o guia de construccion de RPM que hayan aprendido (si, ustedes los usuarios)
Modificar YUM, el package manager de Fedora
Recompilar los RPM de Fedora 17
Mitos y verdades
Siguiendo con el analisis, a esta altura, se preguntaran, entonces, porque van a mentir y poner excusas irreales solo para hacer ese cambio?, bueno, antes de responder eso, debo mostrar algunas cosas mas, no dejen de leer y entender.
Uno de los link de referencia de la wiki de Fedora «usrmove», hace referencia a la wiki de openSUSE, donde en un apartado, explica el como y porque del cambio, algo que ellos tambien tienen en mente. Solo que esta mejor explicado y cita una fuente, de una lista de mail de BusyBox, donde un developer, explica el porque el spliteo de /bin /sbin /usr/bin /usr/sbin y asi, os dejo el link aqui mismo:
Link de openSUSE: http://en.opensuse.org/openSUSE:Usr_merge
Link al que refiere openSUSE y explica el porque: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
Basicamente, y en resumidas cuentas, la explicacion del developer, dice que la situacion fue esta:
«En la epoca que Ken Thompson y Dennis Ritchie crearon UNIX, las unidades de disco, eran costosas y pequeñas, de tan solo 1.5MB, por lo cual, cuando terminaron de crear el sistema, este cabia en un disco entero, pero solo hasta el /, para continuar con los archivos de usuario, debieron atachar otro disco de 1.5MB, y crearon el /usr, con la replica de contenidos del primer disco.
Luego fue creado el /home de forma intencional, pero, segun la explicacion, si Dennis y Ken hubieran tenidos discos como los de hoy en dia, hubieran metido todo dentro de un solo /usr.
Segun la explicacion, durante años, se siguio tomando el mismo modelo, por cuestiones burocraticas, y nadie se cuestiono el porque de este spliteo, asi como tampoco se lo cuestiono la Linux Foundation, la cual tiene en mayoria, voz y voto sobre el FHS Standard.
Segun lo que dice, al dia de la fecha, no tiene sentido alguno este spliteo, que solo proviene de cuestiones historicas y burocraticas. Luego, AT&T y otros, encontraron excusas a esto, como que el core del sistema estaria en / y el resto que el cliente elija instalar, en /usr»
Esta es la famosa explicacion corta, que nadie explica realmente, sobre la «cuestion historica» del spliteo
Errores en la historia y verdades
1) El pack de discos mencionado, no era de 1.5MB sino de 2.5MB, craso error, algo huele mal, no?
2) Alguna vez, Ken o Dennis dijeron eso?, no que yo sepa, entonces, como es que afirman algo sobre hipotesis y no sobre hechos reales?
3) La mayoria de los inventos y descubrimientos fueron por accidente. Si realmente esto fue asi y luego si se le encontro utilidad a este spliteo y por eso se conserva?
Actualmente, HP-UX, OpenBSD, FreeBSD, NetBSD, IRIX, AIX, usan / y /usr, siendo estos, los mas puros UNIX que aun sobreviven, y siendo Linux, Unix-Like, creo que esta bien que copie la jerarquia del sistema de archivos de sus abuelos.
Tomo como referencia, una captura de pantalla que realice en un OpenBSD5, instalado por mi, en VirtualBox, en el cual se ve, el kernel, la existencia de /bin /sbin /lib, y el resto de directorios.
Ahora, los invito a la reflexion. Un tipo como Theo de Raadt, el cual ha insultado a Torvalds, a los Core2Duo de Intel, y dice lo que piensa, incluso eso le causo la perdida de donaciones de parte de US, creen que si el viera algo mal o que se pudiera mejorar, no lo habria hecho?, solo piensen eso
OpenBSD 5.0 corriendo
Notese la existencia de /bin /sbin /lib
Para continuar con las incongruencias, tenemos a freedesktop.org, donde comentan en sus «fact», que el original UNIX, tenia un /bin, si, pero era SOLO un symblink hacia /usr.
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
Myth #6: A split /usr is Unix “standard”, and a merged /usr would be Linux-specific
Fact: On SysV Unix /bin traditionally has been a symlink to /usr/bin. A non-symlinked version of that directory is specific to non-SysV Unix and Linux.
Por si no lo notaron, esto es una mentira, no solo por la prueba real de algun UNIX que este corriendo en alguna casa o empresa, sino por el hecho, de que Dennis y Ken, contenian en / todas las herramientas necesarias para poder montar el segundo disco que contenia /usr, por tanto, si /bin es solo un symblink, como dice freedesktop, como es que montaba el segundo disco?, recuerden que un symblink, es un link simbolico a una ruta o destino real, pero si el disco no esta montado, como puede ser esto real?, wow, ahora si que metieron la pata con sus mentiras no es verdad?, claro que si.
Tomando en cuenta el error al mentir, en el articulo freedesktop, la explicacion sin la palabra de Dennis o Ken del developer de BusyBox, asi como las excusas falsas de Fedora, y si leen mas abajo, la evasion constante en las FAQ, todo me lleva a pensar que esto es por algo que aun nadie nos dice.
Aunque el «owner» en la wiki de Fedora, es Harald Hoyer, un empleado de RedHat, el iniciador de este cambio, y la idea principal, fue del creador de systemd, el mismo creador de pulseaudio (si, esa basura), el fantastico Lennart Poettering, adivinaron!, el chico mavarilla.
Como habrán visto, systemd tiene problemas con / y /usr, y seguramente, cuando fue programado y pensado, Lennart, asumio que todo el mundo seguia el esquema de particionado sugerido por Anaconda, el instalador de Fedora, pero seguro comenzo a ver bug report en bugzilla, acerca de informes de error, en sistemas instalados con / y /usr por separado.
La gran estafa
Ahora, pensemos, que es más facil, arreglar systemd (que quiza no se pueda), y reconocer que lo que se coloco en Fedora 15 y 16, para reemplazar Upstart tiene un bug enorme. Liberar Fedora 17 con Upstart de nuevo, o con init en el peor de los casos, o mover todo a /usr para arreglar el bug de systemd, cubrir a Lennart, y quedar bien con todos?, yo me inclino a pensar, quiza me equivoque, que el motivo de «usrmove» es ese, tapar el error de Lennart.
Segun dice la wiki de Fedora, estará presente en RHEL7, realmente, lo dudo y me rio en sus caras (a menos que quieran perder clientes), dado que un bien sysadmin, con LPI y demas certificados, no va a permitir que conviertan su Unix-Like en un Windows-Like.
Segun el encargado de «usrmove», para reemplazar lo que habia en /, se creara un initramfs de mas tamaño, que contenga los comandos basicos para recuperar un sistema, o bootear en modo monousuario, y solo necesitar el / (algo que si hago y creo que muchos hacen para tareas administrativas).
Y el mismo estaria contenido en /boot. La explicacion de esto, es que conservar / para reparar /usr en caso de corrupcion, no tiene sentido, dado que dependemos de /boot para el inicio y /, con lo cual, es mas optimo (esto si lo comparto), que todo este en /boot, donde vive el kernel, para poder asi reparar / y /usr o lo que fuera, con un initramfs engordado que contenga los comandos que estan en /bin y /sbin. Mi pregunta es, que pasa con las updates que actualizan algunos de esos comandos?, ahora debera actualizar un initramfs?, que debe ser compatible claro, con el kernel del sistema, a la larga, este modelo, va a ser mas complejo.
Desde mi punto de vista, seria mejor un initramfs con los modulos necesarios para montar y cargar binarios de /boot/system por ejemplo, donde se alojen los binarios que ahora se encuentran en /bin y /sbin. Algo mas parecido a GoboLinux.
Y ahora?
Que haremos?, nada, cruzar los dedos para que las soluciones de Fedora funcionen como antes, que no traiga problemas de seguridad, y convivir con un Windows-Like.
Pero... siempre tendremos Paris, perdón, quise decir, RHEL.
Y si RHEL tambien se convierte en eso?, bueno, siempre tendremos *BSD y Gentoo!
PD: Muchos usuarios de UNIX y Linux, con mas de 50 años, incluso en los canales de #fedora y #rhel, gente que usa *nix desde el año 92, me comento acerca de su descontento con esto, y que si pudieran votarian en contra, pero claro, nadie les consulto, todo sea por tapar el error de Lennart
PD2: Solaris, hace 15 años que viene trabajando en esto, y recien se implemento en Solaris 11. Pero posee una cantidad de mecanismos de recuperacion, diagnostico y analisis, que no posee Linux, sin contar, con el soporte nativo de ZFS, lo que implica, una falla casi imposible en su sistema de archivos, algo que Linux no posee. Por el momento, solo tiene Ext4, y el futuro BTRFS que esta en la rama experimental, propuesto para Fedora 18, otro gran error.
Eso es todo, agradeceria comentarios, pero con fundamentos y razones, luego de haber leido todo el post y la documentacion que cito en el mismo.