Fedora developers defend the proposed merger of /usr directories
The Fedora Project is currently mounting a concerted effort to merge Linux filesystem directories into a more organized structure, an effort known as /usr merge.
This is not really new news: I covered this back in November. But a new posting on FreeDesktop.org from systemd developer Lennart Poettering is seeking to dispel many of the arguments against such a merge, while touting the merger's advantages.
Poettering is not the initial proposer of /usr merge--that designation goes to fellow Red Hat developers Harald Hoyer and Kay Sievers, as an effort to clean up the mess that was made when the /sbin and /bin directories were first split off from each other. The Grand /usr-fication Theory will, when implemented, essentially pull in every component of the operating system to a single mounted volume.
When all of the binaries and libraries are on such a volume, it would be far simpler to run multiple instances of the operating system on different machines on a network, as well as facilitate the use of snapshots. With the onset of the btr filesystem (btrfs) in the Linux world, such a unification would be a huge advantage.
In his post this week, Poettering takes pains to note that this filesystem change is neither dependent on systemd, or Fedora alone. systemd is a new init daemon developed by Poettering designed to improve services management on Linux systems--particularly mobile ones that have variable needs depending on where or when the system is used. (Carla Schroder has an excellent series of articles on Linux.com that highlights the features of systemd.)
"systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems," Poettering wrote on FreeDesktop.org. "That said we want to encourage distributions adopting systemd to also adopt the /usr merge."
Poettering highlights four broad issues why such a merge makes sense to him:
In order to discount some of the objections to this proposal, Poettering listed eleven "myths" that he then dispelled. Of these, the one that caught my eye was this one:
"Multiple other Linux distributions have been working in a similar direction," Poettering wrote.
That is not in dispute, but there is also no denying that the Fedora Project is by far the most aggressive proponent of such moves. Initially, I was critical of this effort, mostly because of my bias towards the Linux Standard Base and concerns that Red Hat was yet again thumbing its nose at the rest of the Linux community and going off and doing it's own thing.
But maybe there's something else afoot here.
A few times, Poettering mentioned this change would mean better compatibility with Solaris 11. Normally, that would be a point of trivial interest. But after running up against a lot of people from Joyent this past weekend at SCALE 10X, some dots are getting connected.
Joyent is a cloud services provider that provides a complete software stack for its customers… with its SmartOS operating-system layer based on Solaris. Joyent is coming out will all guns blazing of late, with lots of presence at events like SCALE 10X, Node Summit, and Monki Gras, not to mention some aggressive positioning of Solaris' Dtrace and other features.
Again, taken alone, this is all well and good… you certainly can't blame Joyent for being enthusiastic about their product.
But, given all of these little breadcrumbs, not to mention more than a little groundswell about Oracle Solaris these days, now one wonders: are Fedora/Red Hat trying to shift themselves (and the rest of Linux) into a better position to combat Solaris?
It might not be a bad idea. If Solaris were to take off (and the cloud is a great platform on which one could deploy bazillions of Solaris instances pretty darn quickly), one area of competition would definitely be application compatibility. If Linux can maintain better compatibility with Solaris (and any other UNIX contender), then that point of contention would be come moot--or at least weaker.
Suddenly, what seemed to be a power-play by Red Hat might ultimately be of great benefit to the overall Linux ecosystem. Sure, Red Hat would reap the initial benefits, but if they were the ones who saw this challenge coming, I certainly wouldn't begrudge them that.
Speculation, to be sure, but broader unification with UNIX-based platforms has to have some reason driving it, and this seems as likely as any.
This is not really new news: I covered this back in November. But a new posting on FreeDesktop.org from systemd developer Lennart Poettering is seeking to dispel many of the arguments against such a merge, while touting the merger's advantages.
Poettering is not the initial proposer of /usr merge--that designation goes to fellow Red Hat developers Harald Hoyer and Kay Sievers, as an effort to clean up the mess that was made when the /sbin and /bin directories were first split off from each other. The Grand /usr-fication Theory will, when implemented, essentially pull in every component of the operating system to a single mounted volume.
When all of the binaries and libraries are on such a volume, it would be far simpler to run multiple instances of the operating system on different machines on a network, as well as facilitate the use of snapshots. With the onset of the btr filesystem (btrfs) in the Linux world, such a unification would be a huge advantage.
In his post this week, Poettering takes pains to note that this filesystem change is neither dependent on systemd, or Fedora alone. systemd is a new init daemon developed by Poettering designed to improve services management on Linux systems--particularly mobile ones that have variable needs depending on where or when the system is used. (Carla Schroder has an excellent series of articles on Linux.com that highlights the features of systemd.)
"systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems," Poettering wrote on FreeDesktop.org. "That said we want to encourage distributions adopting systemd to also adopt the /usr merge."
Poettering highlights four broad issues why such a merge makes sense to him:
As I wrote in November, all of this seems like a pretty good idea, as this will make cross-distro development a lot easier for those distros who adopt the new filesystem architecture. Currently, different distros locate key libraries and binaries in different locations in the Linux filesystem, for which application developers have to compensate when they code and package their apps. An all-in-one solution that would merge or symlink all of these locations together would make things a whole lot easier.
- "Improved compatibility with other Unixes/Linuxes in behaviour: After the /usr merge all binaries become available in both /bin and /usr/bin, resp. both /sbin and /usr/sbin (simply because /bin becomes a symlink to /usr/bin, resp. /sbin to /usr/sbin). That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration. /usr/bin and /bin (resp. /usr/sbin and /sbin) become entirely equivalent.
- "Improved compatibility with other Unixes (in particular Solaris) in appearance: The primary commercial Unix implementation is nowadays Oracle Solaris. Solaris has already completed the same /usr merge in Solaris 11. By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris.
- "Improved compatibility with GNU build systems: The biggest part of Linux software is built with GNU autoconf/automake (i.e., GNU autotools), which are unaware of the Linux-specific /usr split. Maintaining the /usr split requires non-trivial project-specific handling in the upstream build system, and in your distribution's packages. With the /usr merge, this work becomes unnecessary and porting packages to Linux becomes simpler.
- "Improved compatibility with current upstream development: In order to minimize the delta from your Linux distribution to upstream development the /usr merge is key."
In order to discount some of the objections to this proposal, Poettering listed eleven "myths" that he then dispelled. Of these, the one that caught my eye was this one:
"Myth #9: The /usr split is useful to have a minimal rescue system on the root file system, and the rest of the OS on /usr."To which Poettering responds:
"Fact: On Fedora the root directory contains ~450MB already. This hasn't been minimal since a long time, and due to today's complex storage and networking technologies it's unrealistic to ever reduce this again. In fact, since the introduction of initrds to Linux the initrd took over the role as minimal rescue system that requires only a working boot loader to be started, but not a full file system."Poettering seemed to take on the issue that I and others have raised about this proposal, as well as the adoption of the new syslog system, Journal, by the Fedora Project. There are concerns by many, including me, that Fedora's (and subsequently Red Hat's) adoption of these new techniques and tools are an attempt to move forward in the marketplace and set themselves apart from other Linux distros as an "easier" platform for which to develop.
"Multiple other Linux distributions have been working in a similar direction," Poettering wrote.
That is not in dispute, but there is also no denying that the Fedora Project is by far the most aggressive proponent of such moves. Initially, I was critical of this effort, mostly because of my bias towards the Linux Standard Base and concerns that Red Hat was yet again thumbing its nose at the rest of the Linux community and going off and doing it's own thing.
But maybe there's something else afoot here.
A few times, Poettering mentioned this change would mean better compatibility with Solaris 11. Normally, that would be a point of trivial interest. But after running up against a lot of people from Joyent this past weekend at SCALE 10X, some dots are getting connected.
Joyent is a cloud services provider that provides a complete software stack for its customers… with its SmartOS operating-system layer based on Solaris. Joyent is coming out will all guns blazing of late, with lots of presence at events like SCALE 10X, Node Summit, and Monki Gras, not to mention some aggressive positioning of Solaris' Dtrace and other features.
Again, taken alone, this is all well and good… you certainly can't blame Joyent for being enthusiastic about their product.
But, given all of these little breadcrumbs, not to mention more than a little groundswell about Oracle Solaris these days, now one wonders: are Fedora/Red Hat trying to shift themselves (and the rest of Linux) into a better position to combat Solaris?
It might not be a bad idea. If Solaris were to take off (and the cloud is a great platform on which one could deploy bazillions of Solaris instances pretty darn quickly), one area of competition would definitely be application compatibility. If Linux can maintain better compatibility with Solaris (and any other UNIX contender), then that point of contention would be come moot--or at least weaker.
Suddenly, what seemed to be a power-play by Red Hat might ultimately be of great benefit to the overall Linux ecosystem. Sure, Red Hat would reap the initial benefits, but if they were the ones who saw this challenge coming, I certainly wouldn't begrudge them that.
Speculation, to be sure, but broader unification with UNIX-based platforms has to have some reason driving it, and this seems as likely as any.
No comments:
Post a Comment