Muy a mi pesar, es que hago este post. Digo esto, basicamente, porque no me gusta criticar la distro que uso y apoyo sus decisiones, 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
. 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.
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 de 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 durante 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 durante 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 empaquetadores 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 que provocará
Gracias al encargado del proyecto, por citar la discusion en debian-devel.
Lei toda la discusion, y pude observar que el 80% de las personas no estan de acuerdo, y comentan algo que nadie dijo, ni tampoco pensé.
Al meter un initramfs dentro del kernel, mas el firmware en /boot, aumentará el tamaño del kernel, asi como la cantidad de espacio necesario en /boot.
Esto no supone un problema en PC x86, pero en sistemas embebidos ARM, donde el espacio es a veces de solo 8MB, el tamaño de /boot es importante. Algunos dirán, pero /boot puede estar bajo /, sin separarse, y yo les contesto, que si uno decide encriptar un filesystem, es requerido que /boot esté en una particion separada.
Según el comentario de uno de los developer de Debian, esto es una estrategia de negocio, al menos asi lo supone el, en la cual, RedHat, tendrá mas pedidos de soporte, en clientes con estas limitaciones de espacio en sistemas ARM, asi que, probablemente, si se traslade a RedHat.
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. Y 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 UNIX original, tenia un /bin, si, pero era SOLO un symblink hacia /usr.
Referencia:
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 symlink, como dice freedesktop, como es que montaba el segundo disco?, recuerden que un symlink, 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 maravilla.
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 esta mal y tiene un bug enorme, utilizado para reemplazar Upstart. 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, cubrir 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.
Mas pruebas de que este cambio se debe a un Bug en Systemd
Los que entienden algo de ingles, no van a tener problema, los que no, usen Google Translate, dado que es ingles técnico mas que nada y facil de traducir.
Lo que van a leer ahora, es la confirmacion, por parte de la misma gente de Fedora en sus listas de mail, de que el cambio se debe a un Bug en systemd. Por ese motivo, las distros que adoptaron systemd, deben cambiar tambien (openSUSE), y las que no (Debian, Arch), pueden optar. Debian por el momento, decide que es mala idea, y la wiki de ArchLinux, aclara que NO se debe usar / y /usr en caso de usarse systemd, al menos no mueven todo, no?.
Lo que dicen los mail, basicamente, es que es una excusa rara y estupida, tener mas compatibilidad con Solaris 11, si es una broma, y Lennart, contesta ironicamente, que su idea es llegar a C:\Programas files\
Realmente, es muy decepcionante ver esto, mails de Fedora-Devel
http://lists.fedoraproject.org/pipermail/devel/2012-January/161823.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161833.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161817.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161781.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161788.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161789.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161801.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161832.html
http://lists.fedoraproject.org/pipermail/devel/2012-January/161856.html
-----------------------------------------------------------------------------------------------------------
On Fri, Jan 27, 2012 at 7:43 PM, Jef Spaleta <jspaleta at gmail.com> wrote:
> If you haven't read the new summary write-up on the benefits of the
> /user feature that I think you would benefit from reading it.
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>
> If you have read it, then I fear you either don't fully understand or
> do not value the long term benefits associated with the filesystem
> snapshotting nor the utility of having read-only shared vendor
> supplied /usr across many guest instances.
Apart from fixing things that are not a problem[1], the
stateless/snapshotting benefits are, AFAIK, just vaporware promises.
I can't see they can work as stated because /etc and /var are quite
strongly bound to the details of contents of the newly proposed /usr -
and these objections were raised back when FESCo first discussed this
feature.
Actually getting a stateless system would require first defining what
is "state" and what is "OS" (and that question will have several
different answers, for good reasons!), and then doing the actual work
of separating the two. We already have a readonly-root facility in
initscripts, and I think that one is doing it right - giving the
people that want to use these (non-default, comparatively rarely-used
and site-specific) features the power to create a stateless system
without burdening the most common users with it.
Mirek
[1] Improved compatibility with Solaris - Seriously? We didn't need
that level of compatibility back when Linux was a small niche, why
would we care now? I feel mildly insulted by that argument.
------------------------------------------------------------------------------------------------
On 01/28/2012 10:47 AM, Miloslav Trmač wrote:
>
> [1] Improved compatibility with Solaris - Seriously? We didn't need
> that level of compatibility back when Linux was a small niche, why
> would we care now?
> I feel mildly insulted by that argument.
Why stop with Solaris compatibility and not mimick Windows?
No /usr, no /bin => /redhat. Seems to be the spirit behind all this.
Ralf
-----------------------------------------------------------------------------------------------
On Sat, 28.01.12 11:29, Ralf Corsepius (rc040203 at freenet.de) wrote:
> On 01/28/2012 10:47 AM, Miloslav Trmač wrote:
> >
> >[1] Improved compatibility with Solaris - Seriously? We didn't need
> >that level of compatibility back when Linux was a small niche, why
> >would we care now?
>
> >I feel mildly insulted by that argument.
> Why stop with Solaris compatibility and not mimick Windows?
> No /usr, no /bin => /redhat. Seems to be the spirit behind all this.
Actually we originally wanted to rename "/usr" to "C:\PROGA~1\" but we
feared FESCO might not agree to that, on grounds that backslashes might
be too hard to type on the shell prompt! But we'll propose that for F18,
OK?
Lennart
--
Lennart Poettering - Red Hat, Inc.
------------------------------------------------------------------------------------------------
2012/1/28 Ralf Corsepius <rc040203 at freenet.de>:
>
> Why stop with Solaris compatibility and not mimick Windows?
> No /usr, no /bin => /redhat. Seems to be the spirit behind all this.
>
> Ralf
>
The rhetoric spoils the argument. Various people inside of Red Hat are
either for this, against this, wanting to see where the train wreck
will end, thinking this is the greatest innovation since Unix, etc.
All the rhetoric does is cause people (inside and outside of Red Hat)
to rally more around that idea no matter how silly than allow the idea
to be looked at, valued for its merits and then discarded or kept.
I would like to think that after 8 years of this same argument, and
its ineffectiveness it would time to do something else.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
---------------------------------------------------------------------------------------------
On 01/27/2012 06:33 PM, Bill Nottingham wrote:
> Ralf Corsepius (rc040203 at freenet.de) said:
>> On 01/27/2012 06:05 PM, Bill Nottingham wrote:
>>> Toshio Kuratomi (a.badger at gmail.com) said:
>>>> Actually... we will "always" need the compat symlinks (for a finite but
>>>> definitely long value of "always"). Third party scripts, scripts that have
>>>> been in use on local systems, written by people who have long since passed
>>>> on (to new jobs), people targetting FHS compliant systems (unless the FHS
>>>> changes), etc will all depend on those symlinks being present. Even third
>>>> party software that users want to compile and run may try to install into
>>>> /bin, /sbin, and /lib so we may have that problem even there.
>>>
>>> And things like /bin/sh are compiled into glibc...
>>
>> And hard coded into 1000s of scripts and packages.
>>
>> I seriously think, Fedora has many urgent problems to address than
>> the churn this "Feature" causes.
>
> ? There's no churn required due to packages having /bin/sh in them.
Sure there is - It's really sad you don't see it.
This feature is drain of energy and time of the already scarce resources
Fedora has and contribute to pushing Fedora more into the niche it
already is in.
---------------------------------------------------------------------------------------------------------
Am 27.01.2012 18:00, schrieb Toshio Kuratomi:
> On Fri, Jan 27, 2012 at 02:27:59PM +0100, Nils Philippsen wrote:
>> On Thu, 2012-01-26 at 23:53 +0100, Kevin Kofler wrote:
>>> Toshio Kuratomi wrote:
>>
>>> I don't understand why we absolutely HAVE to change directories to symlinks
>>> when we KNOW RPM doesn't support this, and that in directories as essential
>>> as /bin etc.
>>
>> We could wait until you have convinced people, maintainers and users
>> alike, to fix their packages and scripts all in one go over to using the
>> new paths, so we get by without compat symlinks. But I don't think we
>> want to wait for that. Agreed, it'd be a whole lot nicer if RPM could
>> handle symlink <-> non-symlink transitions without crutches like this
>> one, but right now it can't.
>>
> Actually... we will "always" need the compat symlinks (for a finite but
> definitely long value of "always"). Third party scripts, scripts that have
> been in use on local systems, written by people who have long since passed
> on (to new jobs), people targetting FHS compliant systems (unless the FHS
> changes), etc will all depend on those symlinks being present. Even third
> party software that users want to compile and run may try to install into
> /bin, /sbin, and /lib so we may have that problem even there.
yes, and this is one reason why i do not understand the rush doing this
"feature" now in one big step with a lot of possible pitfalls instead
start it slowly with change the install locations of the packages in
F17 and file bugs for every package who does still install files there
and place symlinks in /bi, /sbin
this is a change which can be done over more releases because it
does nothing change now for the users and in the meantime FHS
maybe updated and third-party packages are also adopted
there is no need doing such change in any rush and completly with
one release especially nobody was interested to do the systemd
transition in one step which would have made much more sense
and solved many many problems, bugreports and a lot of time
in the first step
why in the world is a currently useless "feature" much more forced
than the change of the init-system?
-----------------------------------------------------------------------------------------------------------
On 01/27/2012 12:09 PM, Reindl Harald wrote:
>
>
>
> why in the world is a currently useless "feature" much more forced
> than the change of the init-system?
>
perhaps this change is wanted/needed by the new init system for some
reason that may not be apparent at the moment ...
resource usage aside, even if its not a 'good idea' it doesn't seem
like a 'bad idea' does it?
On 01/27/2012 07:32 PM, Genes MailLists wrote:
> perhaps this change is wanted/needed by the new init system
No, systemd does not care.
----------------------------------------------------------------------------------------------------------
Toshio Kuratomi wrote:
> people targetting FHS compliant systems (unless the FHS changes)
That's the biggest flaw of this "feature": It violates the FHS!
Kevin Kofler
----------------------------------------------------------------------------------------------------------
On Fri, 27.01.12 22:40, Kevin Kofler (kevin.kofler at chello.at) wrote:
> Toshio Kuratomi wrote:
> > people targetting FHS compliant systems (unless the FHS changes)
>
> That's the biggest flaw of this "feature": It violates the FHS!
You know, not even its former editor seems to to believe that (or that
it was a problem), judging by the message this sarcastic posting of his sends:
http://rusty.ozlabs.org/?p=236
;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
----------------------------------------------------------------------------------------------------------
Lennart Poettering wrote:
> You know, not even its former editor seems to to believe that (or that
> it was a problem), judging by the message this sarcastic posting of his
> sends:
>
> http://rusty.ozlabs.org/?p=236
>
> ;-)
Hey, my arguments are not the 2 "anti" arguments he quotes. ;-)
I have nothing against you personally. I have something against pointless
changes to the standard file system we've been using for decades (and which
is still working fine), causing pointless trouble when upgrading.
As for "There are precedents in Solaris and Fedora.", the latter is what
this thread is aiming at preventing. :-p
Kevin Kofler
-----------------------------------------------------------------------------------------------------------
Kevin Kofler, es un reconocido programador y parte del KDE Spin. El cual aplica parches y reparar cosas en C++ en cuestion de horas.
Usen Google Translate y saquen sus propias conclusiones.
Los responsables de este cambio, no diré la fuente son:
Harald Hoyer
Kay Sievers
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 comentaron 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.
