|
|
Log in / Subscribe / Register

The case for the /usr merge

[Posted January 26, 2012 by corbet]

Lennart Poettering has announced the posting of a summary of the motivations for merging several root-level directories into /usr. "A unified filesystem layout (as it results from the /usr merge) is more compatible with UNIX than Linux’ traditional split of /bin vs. /usr/bin. Unixes differ in where individual tools are installed, their locations in many cases are not defined at all and differ in the various Linux distributions. The /usr merge removes this difference in its entirety, and provides full compatibility with the locations of tools of any Unix via the symlink from /bin to /usr/bin."
to post comments

The case for the /usr merge

Posted Jan 27, 2012 0:10 UTC (Fri) by cantsin (guest, #4420) [Link] (104 responses)

My understanding for having /bin, /lib, /var and /etc on root file system level and not in /usr was that absolutely essential OS tools could reside, if necessary, on a very small file system usable for all rescue scenarios, without the additional bloat of all the additional (but non-essential) software in /usr. This allows to put /usr on a separate disk. Even with today's disk capacities, this seems not a completely outmoded concept. It still makes sense, in many scenarios, to put all root directories on a small but fast SSD and /usr on a slower but bigger hard disk.

I wonder why one would throw out such a sane design.

The case for the /usr merge

Posted Jan 27, 2012 0:26 UTC (Fri) by Karellen (subscriber, #67644) [Link] (92 responses)

From the Fedora project page[0] that Lennart's article is based off of and links to in the opening paragraph:

"You are doing it wrong! /bin and /sbin are there to rescue a broken /usr!

The most critical filesystem is /boot, because the kernel lives there. So the purpose of having /bin and /sbin for /usr repairing relied on _two_ working filesystems ( / and /boot). If either of them was broken, you were not able to rescue /usr. The role of the rescue system can easily be fulfilled by a rescue initramfs. So having the rescue initramfs in /boot, which contains the fsck utils, is in the same danger of becoming corrupted as the kernel. Now you only have to pull out your rescue CD, if /boot is corrupted and not if / is corrupted."

[0] https://fedoraproject.org/wiki/Features/UsrMove

The case for the /usr merge

Posted Jan 27, 2012 0:40 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (91 responses)

More Lennart-speak:
The purpose of having /bin and /sbin for /usr repairing relied on _two_ working filesystems ( / and /boot).

1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

2. Even that aside, it's highly likely that two deliberately small, seldom modified filesystems will be available even if much-vaster, far more dynamic /usr cannot be mounted and must be repaired.

The role of the rescue system can easily be fulfilled by a rescue initramfs.

Yeah, thanks loads, Lennart. So, every time I have to maintain fsck, filesystem-diagnostic, backup/restore, etc. contents that would normally be in /bin, I have to rebuild an initramfs filesystem image. Swell.

For Pete's sake, stop trying to help, Lennart. (I remember he's been on this kick for a while with other justifications such as, paraphrasing, 'Binaries in /bin are often not even statically linked, or at least depend on libs inside /usr/lib.' Well, fix that, then.)

Rick Moen
rick@linuxmafia.com

The case for the /usr merge

Posted Jan 27, 2012 0:45 UTC (Fri) by sjj (guest, #2020) [Link] (8 responses)

You didn't RTFA, or you wouldn't be blaming Poettering.

The case for the /usr merge

Posted Jan 27, 2012 0:52 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (7 responses)

You are correct that I didn't RTFA attentively; haven't had time yet, and frankly I knew the inevitable bullshit arguments resting on prior bullshit arguments (regardless of whose they were) were just going to annoy me.

By the way: Congratulations on hitting the necessary sixty-second window before I was able to notice my error and post my regrets for having made it. You must be extremely proud.

Rick Moen
rick@linuxmafia.com

The case for the /usr merge

Posted Jan 27, 2012 3:51 UTC (Fri) by sjj (guest, #2020) [Link] (3 responses)

It was a simple factual correction. No need to get personal.

I just wish that people commenting on this site would try to be a little more thoughtful and not just assert "bullshit" based on their preconceived notions. Yes, I'm old fashioned and often disappointed.

The case for the /usr merge

Posted Jan 27, 2012 6:32 UTC (Fri) by dvdeug (guest, #10998) [Link] (2 responses)

No, "You didn't RTFA" is not a simple factual correction.

The case for the /usr merge

Posted Jan 27, 2012 16:04 UTC (Fri) by faassen (guest, #1676) [Link] (1 responses)

True, saying "my understanding of the article is different" or something along those lines would have been more polite, though less succinct.

The case for the /usr merge

Posted Jan 27, 2012 17:24 UTC (Fri) by sjj (guest, #2020) [Link]

Point taken. Argument by assertion just pushes my buttons.

The case for the /usr merge

Posted Jan 27, 2012 7:22 UTC (Fri) by hillman (guest, #82597) [Link]

Awesome comeback, you are definitely one of the sharper dudes here. I'm a /. refugee and your post warms my heart.

BTW, love the bullshit on your site, even if it is "(of historical interest, only)".

Peace out, bro.

The case for the /usr merge

Posted Jan 27, 2012 15:57 UTC (Fri) by faassen (guest, #1676) [Link]

You make it sound as if sjj magically should have known that you were going to come back and correct your error, and that it was very impolite of him to have done so before you did.

People correct each other not only because they're smartasses, but also for the benefit of others reading the discussion, and for guiding the discussion away from the wrong direction.

Perhaps you are proposing that before we correct anyone we should:

* check when this person was posting

* if it's less than a minute, wait a minute, check again whether they posted a correction

If so, I propose you lead by example. :)

The case for the /usr merge

Posted Jan 30, 2012 8:27 UTC (Mon) by sbergman27 (guest, #10767) [Link]

What is this "sixty-second window" you are talking about? I've never been able to correct even a minor speelling error after I click "Publish comment" on LWN.

The case for the /usr merge

Posted Jan 27, 2012 0:48 UTC (Fri) by Karellen (subscriber, #67644) [Link]

IT'S NOT LENNART-SPEAK! Lennart did not write the Fedora project page, or have anything to do with the writing of it. He only linked to it, tried to explain some parts which he thought were unclear, and then, just in case that wasn't clear enough, explicitly wrote that he didn't write the original, but wanted somewhere to point people when they wrongly assumed he had something to do with it!

Does no-one read the linked articles any more?

Hang on, I'm not on /. by mistake, am I?

The case for the /usr merge

Posted Jan 27, 2012 0:56 UTC (Fri) by motk (guest, #51120) [Link] (6 responses)

People still rely on static stuff in /bin for rescue work, rather than pxeboot or dc-monkey-boot a rescue image? How quaint!

The case for the /usr merge

Posted Jan 27, 2012 3:55 UTC (Fri) by sjj (guest, #2020) [Link] (5 responses)

Exactly. When did you last see a server that couldn't PXE boot? Workstations? Every distro has a live CD/USB nowadays.

The case for the /usr merge

Posted Jan 27, 2012 8:42 UTC (Fri) by petur (guest, #73362) [Link] (4 responses)

hint: embedded systems (will not boot from USB or CD)

The case for the /usr merge

Posted Jan 27, 2012 9:59 UTC (Fri) by hitmark (guest, #34609) [Link]

How about SD or similar?

The case for the /usr merge

Posted Jan 27, 2012 15:35 UTC (Fri) by the.wrong.christian (guest, #73127) [Link] (2 responses)

> hint: embedded systems (will not boot from USB or CD)

If your embedded system is borked, it's much more likely that you'd simply reflash the whole system, surely? An embedded system is not going to provide much of a recovery console to fix things.

The days of a 30MB / died with IRIX. Lets just move on.

The case for the /usr merge

Posted Jan 27, 2012 19:07 UTC (Fri) by xxiao (guest, #9631) [Link] (1 responses)

this is totally wrong, small embedded linux system is 1000X than those servers/desktops, and we design a recovery scheme to it.

The case for the /usr merge

Posted Jan 28, 2012 13:57 UTC (Sat) by HelloWorld (guest, #56129) [Link]

What do embedded systems have to do with this? You'd hardly install Fedora on an embedded system anyway.

The case for the /usr merge

Posted Jan 27, 2012 1:09 UTC (Fri) by josh (subscriber, #17465) [Link] (7 responses)

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Encrypted root filesystems, for one thing.

The case for the /usr merge

Posted Jan 27, 2012 1:53 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (5 responses)

Or a root filesystem on LVM, software RAID, or any other kind of complicated filesystem the bootloader can't understand. Although it looks as though GRUB2 is smart enough to get all those systems (including encrypted filesystems), so maybe separate /boot partitions are going to be as unnecessary as separate /bin, /sbin, and /lib directories.

The case for the /usr merge

Posted Jan 27, 2012 4:49 UTC (Fri) by jackb (guest, #41909) [Link] (2 responses)

Is it possible to install grub 2 on a hard drive that has a LUKS header instead of a partition table?

The case for the /usr merge

Posted Jan 27, 2012 9:54 UTC (Fri) by jengelh (subscriber, #33263) [Link]

There is no bootblock hole like there is on ext2, so the answer is no.

The case for the /usr merge

Posted Jan 30, 2012 19:13 UTC (Mon) by blitzkrieg3 (guest, #57873) [Link]

Not _instead_ of, but you could get grub to read your partition table and then read the luks volume inside the partition.

The case for the /usr merge

Posted Jan 27, 2012 9:01 UTC (Fri) by job (guest, #670) [Link] (1 responses)

I think it's much more common to utilize an initrd to boot from encrypted or DMed filesystems. At least all the normal distros do it that way.

The case for the /usr merge

Posted Jan 30, 2012 19:16 UTC (Mon) by blitzkrieg3 (guest, #57873) [Link]

Initrd and separate /boot are two separate things. You could have the initrd on a / file system in your /boot directory, as you can have a separate /boot partition that just tells linux to load / on another partition and execute /bin/init there.

The case for the /usr merge

Posted Jan 28, 2012 12:04 UTC (Sat) by gbrun (guest, #82611) [Link]

> Encrypted root filesystems, for one thing.

Yes. Another reason are special requirements for the boot loader itself.

For instance, I'm using ReiserFS for /. This FS employs "tail packing", i. e. there are cases when file data will be stored in units smaller than a full cluster ("sector").

File-system agnostic boot-loaders like LILO assume that all sectors in a block list have the same size, and therefore require ReiserFS volumes to be mounted with a special option which disables tail packing when updating the LILO configuration/mapping files.

But mounting ReiserFS with this option defeats its main advantage of space-efficiency for small files, so one does not generally want to do that.

As long as /boot is a separate small file system, this does not matter: One can either use ReiserFS for /boot and mount it with tail packing disabled, or use a different FS like ext2 there which only uses equally-sized clusters (this is what I do).

Also, the current FHS does not force anyone to put /boot onto a different partition - it's just an option.

Therefore, no matter where the basic discussion /bin vs. /usr/bin will eventually lead to, I strongly advise *not* to change the existing practice regarding /boot.

The case for the /usr merge

Posted Jan 27, 2012 1:18 UTC (Fri) by Wol (subscriber, #4433) [Link]

1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Because you've got a multi-boot system, and only have one copy of grub? Doesn't grub belong in /boot?

I've got a system that triple-boots - gentoo, suse and Windows. It helps if I keep all my boot stuff together.

Cheers,
Wol

The case for the /usr merge

Posted Jan 27, 2012 5:38 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Even that aside, it's highly likely that two deliberately small, seldom modified filesystems will be available even if much-vaster, far more dynamic /usr cannot be mounted and must be repaired.

The root filesystem is not seldom modified; in fact, until recently it was very difficult to avoid having to mount it read-write.

The case for the /usr merge

Posted Jan 27, 2012 20:01 UTC (Fri) by ttonino (guest, #4073) [Link]

I thought that /sbin and /usr/sbin were supposed to be the 'rescue' directories.

As far as I'm concerned, move everything to a central location (/usr/bin is fine) and keep statically linked _copies_ (or busybox) for rescue work.

That should keep that FS even more static and likely to be available. And package management will keep it up to date.

The case for the /usr merge

Posted Jan 27, 2012 6:28 UTC (Fri) by drag (guest, #31333) [Link] (5 responses)

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Yes. /boot.

The reasons you have /boot are for:

* Encrypted Root
* LVM
* File systems not supported by Grub
* Network boot
* Non bootable RAID devices (including software raid)
* Union file systems for /
etc etc.

How Linux works now is this:

Bios --> Executes boot loader
Grub --> Loads kernel + Initrd into ram and executes them

The purpose of having a /boot is to provide a platform for bootloader, of which Grub2 is one of many possible loaders, for boot strapping the kernel and initrd.

Initrd performs the necessary functions to get a root file system built up and configured correctly. Starts up software raid, mounts encrypted file systems, performs consistency checks, and can even provide for a emergency repair console if distributions choose to set it up that way.

The initial root file system in ram can perform all the necessary functions that originally having a separate / and /usr directory was meant to accomplish. Only now the 'kernel + initrd' is massively more robust and more flexible then a separate / ever was. Initrd is self contained, executes in ram, and can be loaded in dozens of different ways without breaking it and without it caring how it got loaded.

/boot is just the standard for boot strapping your system on x86 systems with a local hard drive. However there are many different ways it can be done.

A few commonly used examples:
* Load your kernel/initrd from PXE network boot
* Load it from a ISO with isolinux
* Load it from USB drive with syslinux
* Specify a abritrary kernel and initrd to be executed by Qemu/KVM via the command line or Libvirtd XML for launching virtual machines.

All sorts of stuff beyond that. Things that you could never, ever, pull off with trying to do a separate / partition, without massive headaches and all sorts of problems.

So not only has the most significant purposes of having a separate / file system have superseded by superior technologies, but having a separate / file system, for purposes of boot-strapping or rescuing the system, has been a fundamentally broken configuration for many years now. It's not just systemd or Lennart. It just isn't going to work well except in specific hand-crafted setups.

Try it for yourself sometime. Get rid of the initrd, make a custom kernel with everything you think you need, and try to boot / locally while mounting /usr over nfs. It can be done, but it's going to be a headache.

Seriously. I am surprised that somebody would think to try to defend a separate / while lambasting the idea that a separate /boot is necessary. If anything it would make more sense to try to use /boot to help defend the idea that preserving the ability to use a separate / would be necessary.

> Yeah, thanks loads, Lennart. So, every time I have to maintain fsck, filesystem-diagnostic, backup/restore, etc. contents that would normally be in /bin, I have to rebuild an initramfs filesystem image. Swell.

I don't know why you are thanking Lennart. You should be thanking hundreds, if not thousands of people, who put about 20 years of Linux operating system development into practice.

Have you not noticed that when ever you perform a significant system update on you rebuild your initrd? When you install lvm tools, or software raid stuff, or encrypted file system support that this usually causes your initrd to be be rebuilt. It's been like that for a long time.

The case for the /usr merge

Posted Jan 31, 2012 16:38 UTC (Tue) by wookey (guest, #5501) [Link] (4 responses)

This is a very x86 PC-centric view. It is not 'how Linux works' in a more general sense. Other hardware boots in various other ways, not involving BIOS or GRUB, and may or may not have an initrd.

An initrd slows things down quite significantly which is a big deal for some use cases. It provides great advantages in terms of single-boot-image generality and ease-of-rescue but also a cost in speed (and size, although that's small these days at ~2-10 Mb compressed). Boot speed and image generality tend to be in direct competition.

And to answer another post further up, plenty of 'fairly embedded' machines provide a (serial or USB or LCD) console though which rescue can be done and you don't simply want to re-flash and (for example) lose 3 years of logging data. I am thinking of the balloon board controlling my heating system in this case.

Whether overall, moving everything to /usr is a good plan remains to be seen. Personally I am skeptical but I have only spent a limited amount of time reading about the implications so far.

The case for the /usr merge

Posted Jan 31, 2012 17:36 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

In the common case where /usr is not its own filesystem then it's a simplifying cleanup and a noop for reliability and where /usr is a separate filesystem then making sure you have to tools to mount it in initrd, same as you already need tools to mount the root filesystem. Basically its simpler to make sure the appropriate tools are available in an initrd, which only needs a working bootloader to load, than to limit the design of the system so that the rootfs and /usr must be available without tools to set them up. If you already have an initrd then duplicating that functionality in the root filesystem isn't necessary and if you don't have an initrd then the root filesystem and /usr need to be mountable by the bare kernel without tools.

Is any of that a good explanation?

The case for the /usr merge

Posted Jan 31, 2012 21:44 UTC (Tue) by wookey (guest, #5501) [Link]

Yes, thank you. Put like that I can't see any reason to object to it.

Now lets see what I think after reading the other 250(!) comments...

The case for the /usr merge

Posted Feb 2, 2012 5:44 UTC (Thu) by thedevil (guest, #32913) [Link] (1 responses)

"if you don't have an initrd then the root filesystem and /usr need to
be mountable by the bare kernel without tools"

'Scuse me, I don't follow this part. / yes, /usr no. They can be very
different, after all, /usr can be a network filesystem or more generally
just require a kernel module to mount. Isn't that what the whole debate
is about?

The case for the /usr merge

Posted Feb 2, 2012 7:06 UTC (Thu) by raven667 (subscriber, #5198) [Link]

The point is that the initrd is the appropriate place to put those tools as it can be reliably loaded using he same method as he kernel. You could have a root filesystem that requires a module or network mount so you already need to support this kind of complexity in the initrd. If you don't want an initrd for some reason then this naturally limits the filesystem setup you can boot off of.

The problem with maintaining a split system is that it is currently broken on the major systems and has been for some time. At least a dozen binaries in the base system depend on resources in /usr. Fixing it by moving more of the system into the root directories seems more complex and prone to breakage than relying on the toolkit in initrd. Since all the tools you need are already in the initrd, maintining the /sbin /usr/sbin split doesn't have a point. Getting rid of the split makes the system simpler and more flexible so it seems like the right choice

The case for the /usr merge

Posted Jan 28, 2012 1:27 UTC (Sat) by sbergman27 (guest, #10767) [Link] (37 responses)

"1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)"

For whatever reason, a separate /boot filesystem is necessary to convince RHEL's Anaconda to install grub on /dev/md0 rather than /dev/sda. Red Hat says a separate /boot is necessary to boot off software RAID.

Amusingly, that advice about "older systems" is still alive and well in 2012. New users worry about it since their machine is one of those older Core2 Quad systems and not a modern Core i7.

Anyway, I'm still waiting for one of Lennart's inventions not to be 0 steps forward, 2 steps back. Isn't destroying sound *and* init in Linux enough for one person?

The case for the /usr merge

Posted Jan 28, 2012 15:36 UTC (Sat) by HelloWorld (guest, #56129) [Link] (36 responses)

> Anyway, I'm still waiting for one of Lennart's inventions not to be 0 steps forward, 2 steps back. Isn't destroying sound *and* init in Linux enough for one person?
You're clearly confused. Both PulseAudio and systemd are massive improvements.

The case for the /usr merge

Posted Jan 28, 2012 23:28 UTC (Sat) by sbergman27 (guest, #10767) [Link] (35 responses)

I can honestly say that I have *never* had a desktop machine that used PulseAudio where pulse did not cause some problem or another. I've also never had one where Pulse brought with it any advantages. Per app volume controls? What apps don't have thier own? Software mixing? What sound chipsets, even really cheap ones, don't support hardware mixing of multiple channels? Network audio? ESD did that just fine without causing audio problems so severe that a reboot (yes, a reboot) was required. Simply logging out, killing pulse, and logging back in, has not helped on the machines which exhibited this problem.

Regarding systemd... Scott James Remnant's team looked into the port-listening strategy that systemd is based upon for possible use in Upstart. It had architectural problems that were irresolvable, so they quite reasonably abandoned it.

Mark my words. Fedora will be changing its init system again in the not so terribly distant future. After they've had enough of Lennart and systemd, and something newer and shinier comes along.

-Steve

The case for the /usr merge

Posted Jan 28, 2012 23:53 UTC (Sat) by HelloWorld (guest, #56129) [Link] (12 responses)

> I can honestly say that I have *never* had a desktop machine that used PulseAudio where pulse did not cause some problem or another.
This is the typical FUD of lwn trolls. How many machines did you try it on? When was that? What specific problems did you run into? Without this kind of information, a comment like yours is just useless trolling.
Anyway, I've been using PulseAudio for some time now and it works flawlessly.

> Per app volume controls? What apps don't have thier own?
Firefox doesn't and I don't know how to use mplayer's. And I don't feel like I should need to learn, after all, pavucontrol offers a consistent interface for *all* sound applications.

> Software mixing? What sound chipsets, even really cheap ones, don't support hardware mixing of multiple channels?
Err, like, almost every one? I haven't seen an audio chip with hardware mixing since my Asus A7V880 broke. That's because hardware mixing is useless nowadays.

> Network audio? ESD did that just fine without causing audio problems so severe that a reboot (yes, a reboot) was required. Simply logging out, killing pulse, and logging back in, has not helped on the machines which exhibited this problem.
It's obvious that these problems are caused by the audio driver, not by PulseAudio. In fact, most PulseAudio-related problems could be traced back to driver bugs.

> Regarding systemd... Scott James Remnant's team looked into the port-listening strategy that systemd is based upon for possible use in Upstart. It had architectural problems that were irresolvable, so they quite reasonably abandoned it.
This is, again, totally useless. Where's your source? I checked netsplit.com and couldn't find anything about these supposed problems.

The case for the /usr merge

Posted Jan 29, 2012 2:58 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

"This is the typical FUD of lwn trolls."

I don't intend to spend the evening flame-warring with you. However, I will respond exactly once.

I've used it on many machines (too many to remember or count) since it first debuted in Fedora... whatever it was. 7? And I'm not kidding. There has always been *some* problem that prompted me to uninstall it. The first time through it immediately locked up all the remote X desktops at the client site where I had done the upgrade that introduced PA. And the problems continued, year after year.

Granted, over the last year or two I've taken to just uninstalling it immediately after installation. I did not do so on my new Scientific Linux 6.1 desktop... and sound in totem-plugin didn't work at all... until I uninstalled pulse.

"Firefox doesn't and I don't know how to use mplayer's"

Firefox should probably provide a volume control for its HTML5 video, if it doesn't already. Certainly Totem, VLC, and Mplayer plugins do. As well as the all-important Flashplayer. I can't say as I've noticed the Firefox issue since there is so little HTML5 streaming media available now. There's Youtube HTML5 beta. But it still doesn't work well enough to use on an every day basis.

"I haven't seen an audio chip with hardware mixing since my Asus A7V880 broke."

What color is the sky on your planet? I haven't seen a motherboard in years that didn't provide hardware mixing. Uninstall pulse, and I'll bet your current Mobo will mix just fine. Don't just buy the the PA propaganda uncritically. Try it for yourself.

"It's obvious that these problems are caused by the audio driver, not by PulseAudio. In fact, most PulseAudio-related problems could be traced back to driver bugs."

And yet I uninstall PulseAudio, and without exception, sound works perfectly fine. A very strange series of audio driver bugs, indeed. They only ever affect Pulse Audio.

"This is, again, totally useless. Where's your source?"

That information came from a talk given by Scott. It's available online. I spent a bit of time looking for it. But like I say, I'm not about to waste excessive time this evening arguing with an obvious Poettering fanboy over trivialities.

You want to suffer with his crapware? It's certainly no skin off my nose. Go right ahead.

-Steve

The case for the /usr merge

Posted Jan 29, 2012 10:11 UTC (Sun) by niner (guest, #26151) [Link] (9 responses)

> Firefox should probably provide a volume control for its HTML5 video, if it doesn't already. Certainly Totem, VLC, and Mplayer plugins do. As well as the all-important Flashplayer.

The only thing that MPlayer does is control the PCM volume. So when you turn down the volume in MPlayer, everything else gets quiet as well. That's hardly what I would call per application volume control.

> What color is the sky on your planet? I haven't seen a motherboard in years that didn't provide hardware mixing. Uninstall pulse, and I'll bet your current Mobo will mix just fine. Don't just buy the the PA propaganda uncritically. Try it for yourself.

Your motherboard does nothing! It's ALSAs dmix plugin that does the mixing in this case.

> And yet I uninstall PulseAudio, and without exception, sound works perfectly fine. A very strange series of audio driver bugs, indeed. They only ever affect Pulse Audio.

Because PulseAudio tries to do something better than sound systems on Linux have before. It uses timer based scheduling instead of interrupt based which lieterally increases battery life on my laptop for hours due to fewer CPU wakeups. Just like for example OS X has been able to for years.

The case for the /usr merge

Posted Jan 29, 2012 11:12 UTC (Sun) by mikachu (guest, #5333) [Link] (4 responses)

echo softvol = yes >> ~/.mplayer/config

The case for the /usr merge

Posted Jan 29, 2012 11:32 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

Which raises the inevitable question "Who, exactly, thought that softvol=no being the default was a good idea?".

The case for the /usr merge

Posted Jan 29, 2012 13:43 UTC (Sun) by mastro (guest, #72665) [Link]

Softvol uses a bit more CPU and when used at very low volume degrades sound quality when compared with just setting the correct PCM volume. At least this was the case a few years ago, not sure how stuff works with pulseaudio.

The case for the /usr merge

Posted Jan 29, 2012 13:58 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

Why bother with editing config files, when I can just use pavucontrol which gets the job done and works the same everywhere?

The case for the /usr merge

Posted Jan 30, 2012 20:18 UTC (Mon) by mikachu (guest, #5333) [Link]

I was just correcting an incorrect statement, feel free to use whatever you want.

The case for the /usr merge

Posted Jan 29, 2012 17:06 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"Your motherboard does nothing! It's ALSAs dmix plugin that does the mixing in this case."

Even better. Then Pulse is not only redundant, but in some cases double-redundant.

"It uses timer based scheduling instead of interrupt based which lieterally increases battery life on my laptop for hours due to fewer CPU wakeups."

Show me the data. I'm extremely skeptical. Unless you mean that you save a lot of power after your sound dies. That would make sense.

The case for the /usr merge

Posted Jan 30, 2012 1:40 UTC (Mon) by slashdot (guest, #22014) [Link] (2 responses)

dmix won't be enabled if Pulse is active, in sane distributions, obviously.

The case for the /usr merge

Posted Jan 30, 2012 19:40 UTC (Mon) by sbergman27 (guest, #10767) [Link] (1 responses)

But ALSA will be there. (Is anyone using OSS?) So PA's "functionality" is still redundant in this capacity.

The case for the /usr merge

Posted Feb 2, 2012 8:54 UTC (Thu) by keeperofdakeys (guest, #82635) [Link]

ALSA is incapable of software mixing, the dmix plugin handles this. So PA isn't redundant in this capacity.

As for OSS, no one uses it directly (or at least shouldn't). Many programs will use the OSS emulation offered by ALSA (which doesn't support software mixing). The interesting thing about OSS is that it was originally open source, became closed, and became open source again with version 4. Although, now we have shifted to ALSA, it will probably never be as popular.

The case for the /usr merge

Posted Jan 31, 2012 10:37 UTC (Tue) by daniels (subscriber, #16193) [Link]

You want to suffer with his crapware? It's certainly no skin off my nose. Go right ahead.

It's a shame that this approach doesn't extend to LWN comments too.

The case for the /usr merge

Posted Jan 29, 2012 5:12 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

Last time you made a bet against Fedora, you lost but you probably don't remember that. So I am curious. What's the timeframe and what do you promise to do if you lose your bet? :-)

The case for the /usr merge

Posted Jan 29, 2012 5:48 UTC (Sun) by sbergman27 (guest, #10767) [Link] (20 responses)

"What's the timeframe and what do you promise to do if you lose your bet?"

It depends upon when the next new and shiny comes down the pike. One thing you guys can never seem to resist is new and shiny. Sometimes my Fedora predictions turn out to be correct. And sometimes they don't. To which one are you referring?

I'll sincerely give you credit, though. In general, the churning nightmare that is Fedora, after being vetted, tested, filtered, beta'd, properly QA'd and released by your parent organization, is absolutely top notch. Oh, RHEL's PulseAudio is nearly as bad as it was in Fedora, as I have already described. But it's easily removed. And packagekit inherits the perrenial locking problems that yum has had since the FC1 days. And it's still slower than Synaptic. (Although better than it used to be.) But other than that, RHEL and its clones are absolutely fantastic. I've taken a hiatus from Ubuntu on my home desktop, and am quite enjoying RHEL, CentOS, and SL. Especially SL, which is a new one for me.

Not that I ever left the RHEL family behind. It is a bitter-sweet combination of sadness and joy to me that several of my customers' venerable CentOS 4 servers must be upgraded in the next month. It's been a great 7 years of perfect OS stability. Some will be going CentOS 6.2. Others to Scientific Linux 6.1, or 6.2 if it is ready.

Oh, what the hell. I predict you'll be off systemd in 3 years or I'll buy you a burger. We can sync up in 2015. :-)

-Steve

The case for the /usr merge

Posted Jan 29, 2012 15:59 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (19 responses)

Nah. No burger. You will lose the bet and when you do, if you can sing praises of Fedora all the time, we have a real wager. See you in 2015.

The case for the /usr merge

Posted Jan 29, 2012 17:50 UTC (Sun) by sbergman27 (guest, #10767) [Link] (18 responses)

"You will lose the bet and when you do"

Time will tell. Your last new init replacement didn't lask very long in the very fickle Fedora. Few things do. So the odds are in my favor.

"if you can sing praises of Fedora all the time,"

Highly unlikely, but not entirely beyond the pale. It depends upon how responsibly the Fedora devs and advocates behave in future. I'm am critical. Even biased by long experience with the distro. But I am also fair.

BTW, my memory may be somewhat better than you counted on. I distinctly remember you stating that you had lost all respect for me because you felt that I was blaming Fedora for that Fedora creation, Pulse Audio, causing widespread problems in other distros. You claimed that all the other distros just weren't doing it right. And that all the problems had been resolved in Fedora. That was a while back.

Well... I now have 3 Scientific Linux 6.1 machines within 1 meter of me which put the lie to that claim. Unless you want to claim that Fermilab and Cern took the perfectly functional PA from Red Hat's premier OS, RHEL 6, based upon F12 and F13, and broke it, I must conclude that PA in F12 and F13 was as broken as I claimed at the time. Sound randomly dies on all three of these machines (with 2 different audio chipsets) until PA is removed. That, after an additional 3 years of QA from Red Hat, which normally does do well.

I really should have bet you a nice lobster dinner on *that* one.

-Steve

The case for the /usr merge

Posted Jan 29, 2012 18:09 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (12 responses)

My instinctive questions would be "How large a sample size is two audio chipsets?" (I have no particular feel for how many different audio chipsets exists) and "Which audio chipsets, and did you file a bug report or just go 'bah, poxy lennartware *uninstall*' and not bother?".

The case for the /usr merge

Posted Jan 29, 2012 20:22 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

It's been admitted in this very thread that PA tries to do things that have worked for Apple on its tightly controlled harware, but apparently don't work well in the freewheeling world of PC hardware. That was a fatal design in PA for its intended audience.

Vendors of sound hardware don't care if PA works or not. And with Linux having been stuck at ~1% of the desktop market for the last 10 years, that situation is not likely to change. Best to deal with sound hardware the way it *is* and not the way you'd like it to be.

ALSA FTW! The pragmatic approach is often the best.

-Steve

You've started it...

Posted Jan 29, 2012 21:34 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.

ALSA FTW! The pragmatic approach is often the best.

Right. And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID. This reduces amount of testing required - which is practical for me. Systems with uninstalled PulseAudio most definitely fit the bill as far as sound is involved.

You've started it...

Posted Jan 29, 2012 21:40 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID.
Right. So in the end nobody but the developers can use the configuration options provided, because if they use them they can't report bugs or get them fixed. And then those configuration options get removed because they're unused. And then we look around at the non-configurable desert which our free platform has become and wonder when exactly we took this wrong turn.

You've started it...

Posted Jan 30, 2012 9:56 UTC (Mon) by khim (subscriber, #9252) [Link]

Why do you think someone took the wrong turn? Non-configurable desert is one description which tries to imply this is somehow bad. Uniform experience is another description for the same thing - and it's usually praised by reviewers... unless they themselves want to change something - and can not.

I'm not saying all options are worthless (it'll be hypocritical for me to say so since I toggle quite a few knobs on new systems). But they should all earn the right to live. No exceptions. You must compare overhead the developer faces for given option with popularity of said option. If option is wildly popular then it must be supported even if it's quite painful for the developer. If it's trivial and does not require a lot of Q&A resources then it can be kept even if it's not all that popular. But if it's both not popular and painful - then it's better to make it go away.

You've started it...

Posted Jan 29, 2012 22:05 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.
"""

44 million. But since PA depends upon the underlying sound system, if one's chances of getting sound working in Linux without PA are bad, their chances of getting it working with PA are far worse.

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish. No, that's not right. At this point, in 2012, it's pretty certain that Desktop Linux has always had a deathwish. We never had a chance. We only kill the things we love.

You've started it...

Posted Jan 30, 2012 9:49 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish.

Sorry, but you are wrong again. Try the aforementioned search with esd instead of pulseaudio or alsa - and you'll get more results then in pulseaudio case.

The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd.

You've started it...

Posted Jan 30, 2012 14:48 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Even better than ESD, remember ARtS? Why have one sound server when you have have two incompatible ones both vying for access to a single, exclusive, sound output along with applications who try to use the sound output directly. Having one sound server rather than a bunch of incompatible ones fall in an out of fashion every few years is an improvement in and of itself, even if it was no better, which it is.

You've started it...

Posted Jan 30, 2012 19:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd."

I only use a sound server when such functionality is useful. i.e. network transparency. (Though HelloWorld has mentioned another feature useful for some.)

You don't seem to understand that the sound server is dependent upon the underlying sound system on either the client or the server machine.

I've had less trouble (in fact, no trouble) with ESD. But I don't use any sound server when none is required.

The case for the /usr merge

Posted Jan 29, 2012 21:43 UTC (Sun) by elanthis (guest, #6227) [Link] (1 responses)

> Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before. Also, ALSA/ESD don't support device hot plugging with automatic output switching, which I do use here and there on my laptop.

Anecdotes are a GREAT way to debate!</sarcasm>

The case for the /usr merge

Posted Jan 29, 2012 22:50 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"""
My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before.
"""

Obviously, that was a problem with your configuration or harware.

(That's a little joke. But do try the latest ESD nightlies! They're fantastic!)

I quite agree with you about anecdotal evidence. Unfortunately, it's pretty much all we have in Desktop Linux. Rightly or wrongly, one's own anecdotes take priority over others' anecdotes. And there is some justification for that. About all we can do right now is keep careful notes and do the best we can with the information we have, trying to keep in mind the 'p' significance of our own personal datasets.

It would be much nicer to have actual data. But indeed, the plural of "anecdote" is not "data".

On my machines, and my customers' machines, over the last serval years, PA has been pretty much a failure.

The case for the /usr merge

Posted Jan 30, 2012 2:07 UTC (Mon) by HelloWorld (guest, #56129) [Link] (1 responses)

> But why bother when it offers no advantage to just using ALSA?
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets). Anyway, you're obviously biased against PulseAudio, so discussing this with you is probably a waste of time.

The case for the /usr merge

Posted Jan 30, 2012 7:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"""
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets).
"""

That's a reasonable enough point. It's not one that interests me. But it is likely significant to others. I would have nothing against PA if it did not so often break sound completely. If it sometimes allows people to enjoy a degree of increased flexibility, I would not begrudge them that.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 0:57 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

"You claimed that all the other distros just weren't doing it right. And that all the problems had been resolved in Fedora. That was a while back."

This is clearly not something I have ever claimed and I bet the world you cannot produce a direct quote at all. So yes, my memory is much better than yours. We will see you in 2015 when you lose your bet :-)

The case for the /usr merge

Posted Jan 30, 2012 7:04 UTC (Mon) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
This is clearly not something I have ever claimed and I bet the world you cannot produce a direct quote at all.
"""

It was either here or on OSNews. I might even bother to look it up if there were a lobster dinner in it for me. Just kidding on that last. Lobster is... tedious. But it *was* either here or on OSNews. And I'm not kidding on that point. :-)

-Steve

The case for the /usr merge

Posted Jan 30, 2012 15:40 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I am sticking to my bet. You can't provide a direct quote.

The case for the /usr merge

Posted Jan 30, 2012 20:42 UTC (Mon) by sbergman27 (guest, #10767) [Link] (1 responses)

It's not important enough to go digging through the archives for. I suspect you do remember it. I do, since it was the first response which I had seen from you in which you seemed to have lost your cool. It made me wonder if I had, perhaps, pushed things too far.

If so, I belatedly apologize. We do spar. But know that I do value your contributions, and respect your convictions. (In case you didn't already know.)

I still dislike Fedora. But it results in RHEL, which is superb. Hey, most people don't think of the stinking draught of the slaughter house when they go to Wendy's for a burger. I don't think of Fedora when I use Scientific Linux or CentOS.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 21:13 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

People putting words on my mouth is a pet peeve of my mine but I do remember clearly what I said and you are badly paraphrasing it, which is what I was hinting at strongly. Feel free to look up the archives if you want to confirm what I said.

IMO, it doesn't make sense to look down on a parent distribution while praising a derivative when the benefits you see on the derivative are the direct result of a lot of the work in the parent. This applies as much to Fedora and RHEL and in many even more so when compared to say Debian and derivatives. In other words, work done in Fedora is a necessity for the results you see in RHEL and rest of the Linux world. Fedora might not be suitable for you and I understand that. However the evident disdain is irrational and just seems like a sore gripe from the past, be it Fedora or PulseAudio considering for instance, majority of distributions seem to be defaulting to it and I don't think most people are having any issues anymore. I would say, time to let go and move on to whatever works best.

The case for the /usr merge

Posted Jan 28, 2012 5:04 UTC (Sat) by jimparis (guest, #38647) [Link] (16 responses)

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

And the 2TiB limit came up to take its place. I'm glad that separate /boot is still so well supported. I have a system with 3 TB drives, but the BIOS only recognizes and boots from MBR partition tables. I need a /boot partition entirely contained within the first 2 TiB, and then a GPT containing the actual partitions for Linux.

The case for the /usr merge

Posted Jan 29, 2012 13:51 UTC (Sun) by mastro (guest, #72665) [Link] (15 responses)

This sounds like a bootloader limitation, AFAIK the BIOS just reads and executes the first sector if it has a two-byte magic signature, even if it's not a MBR.

The case for the /usr merge

Posted Jan 29, 2012 18:08 UTC (Sun) by jimparis (guest, #38647) [Link] (14 responses)

In a way, yeah, it is a bootloader limitation -- GRUB is still using BIOS to read sectors off the disk, so it can only ask for sectors within the first 2 TiB. GRUB does have an (incomplete) ATA driver that can work in some cases, and that driver support could be improved, but there's no way you're going to fit all those drivers into the first 512 byte sector, so there will necessarily still be BIOS calls to read more sectors from the disk. And since those sectors need to be below 2 TiB, you're limited to either playing tricks (like cramming your drivers into empty alignment space before your real partitions) or something a bit cleaner (like giving it a real /boot partition, in which case you can keep using the BIOS calls for loading the kernel and initrd too).

The case for the /usr merge

Posted Jan 29, 2012 20:33 UTC (Sun) by sbergman27 (guest, #10767) [Link] (12 responses)

We take these things as being "normal". But sometimes newbies say the darndest things. A while back, I had one ask me the question (paraphrased) "We know from long experience that hardware capabilities are increasing geometrically. And we have a good idea what that geometric rate is. Why don't they just build computers and software accordingly?". And I've got to admit, he had a point.

I've already had enough of dealing with silly "limits" to last a lifetime. Current rate of change doesn't matter. It's the first derivative that does. The second has always remained remarkably close to 0. :-)

-Steve

The case for the /usr merge

Posted Jan 29, 2012 23:03 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] (11 responses)

I suspect that the problem is not with software authors not understanding the speed of hardware development, but with them underestimating the lifespan of their projects. They assume that their project will have a limited lifespan, so they take shortcuts that will make their work easier but cause problems in a predictable but seemingly long time. What they are forgetting is that sensible people don't replace working infrastructure just for fun, so their design is very likely to remain in use until one of those arbitrary limits is hit.

The case for the /usr merge

Posted Jan 30, 2012 0:01 UTC (Mon) by sbergman27 (guest, #10767) [Link] (10 responses)

"I suspect that the problem is not with software authors not understanding the speed of hardware development, but with them underestimating the lifespan of their projects."

Of course, it's also to IHV's advantage for their hardware to become obsolete in a few years. After all, how were they to know that hard drives would increase in size so fast?

Today, they are happy to sell you a new system that is 100x more powerful, which will do for you... about as much as your old system did.

A permanent state of hyperinflation which people are so used to that they hardly notice that they are on a treadmill. Fundamentally, there is less reason to replace their computers than to replace their cars.

Computers generally don't wear out. Except for hard drives. And if the new drive won't work with your old machine, planned obsolescence wins again.

And the "ka-ching!" sound of the cash register rings again at Dell, or HP, or Acer.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 3:15 UTC (Mon) by raven667 (subscriber, #5198) [Link] (9 responses)

One thing that does make a difference is "fuel efficiency", the resource savings on a new computer paired with consolidation often more than pays for the cost of new hardware. The funny thing is that the benefits of fuel efficiency in cars is often overrated, the cost of a new car or the difference in price between a Prius and a 20mpg car is not going to be made up by fuel savings over the average lifetime of the car

The case for the /usr merge

Posted Jan 30, 2012 8:17 UTC (Mon) by sbergman27 (guest, #10767) [Link] (8 responses)

The fuel savings between a Prius and a 20mpg car in the US works out to about $9000 over 150,000 miles. I'm not sure what to put in for a car's "lifetime". Mine have 160,000 - 380,000 miles on them, currently. And range from 24 to 45 years old. I don't think that's typical. The one with the 380,000 miles on it is my 1988 Chevy Sprint Metro. (Really a rebadged Suzuki.) It beats the Prius, with an original 55mpg city/60mpg highway EPA rating. The 2008 adjusted numbers being 44mpg city/51mpg highway. (In which case it only beats the Prius on the highway.)

The Sprint has saved me over $30,000 in fuel cost over its lifetime, compared to the 20mpg car you suggest for comparison. Not including the avoided cost of buying new cars to replace it. (Suzuki reliability was amazing.)

The "advantage" to throwing away old computers and replacing them with new, more fuel efficient ones has always seemed a bit iffy to me. I support the practice. But I'm not sure it makes economic sence based solely upon electricity savings.

On an absolute scale, looking at fossil fuel usage kilogram for kilogram, more efficient cars are clearly more important than more efficient computers.

The case for the /usr merge

Posted Jan 30, 2012 14:43 UTC (Mon) by raven667 (subscriber, #5198) [Link] (7 responses)

I would put 100k-150k for a lifetime of a car, most people don't hold on to them even that long. In the Prius case that's not even including the cost of replacing the battery packs which I would expect to wear out in that time frame. So at best you have 10k savings, probably less, which means that keeping an older car and putting more miles on it (taking it past 150k like your cars) is probably more energy efficient than building/buying a new one every couple of years just to take advantage of a 5-15mpg difference.

This is different than computers as they are both getting more energy efficient _and_ more capable leading to consolidation in addition to the per CPU core power savings so it's more like a 20:1 efficiency improvement, actually 40:1 because you usually spend as much in cooling as in power usage. A 20 yr old car only has minor capability differences with a modern, high efficiency car.

The case for the /usr merge

Posted Jan 30, 2012 18:28 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

I have seen capacity growing at the rates that you are talking about, but not energy efficiency.

do you have pointers to the efficency claims for capacity/power savings growing that significantly?

the other issue is that electricity is pretty cheap, so it takes a LOT of power savings to equal the cost of a new server.

The case for the /usr merge

Posted Jan 30, 2012 20:12 UTC (Mon) by raven667 (subscriber, #5198) [Link] (2 responses)

The efficiency is that you can run an 8 or 12 core machine with 64-128GB RAM using the same power as a 2 core machine with 4-8G RAM from 5 years ago. Power needs per CPU core are dropping. That trend coupled with virtualization allows you to get more out of you new hardware purchase, consolidating 20:1 on servers and 40:1 on power to run the same workload, and giving plenty of breathing room for your facilities for growth. Having a datacenter run out of power/cooling is very expensive.

The case for the /usr merge

Posted Jan 30, 2012 20:30 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

consolidating 20:1 on servers is fantastic, my company is going heavily into vitualization and is only seeing about 3:1 so far (with the target being 6:1)

also, this sort of savings from virtualization assumes that you are running your prior servers lightly loaded. If you have an application that is large enough that you need to run it on multiple machines to start with, virtualization is a net loss (although this net loss is frequently covered by by doing the consolidation at the same time as a server upgrade)

I don't know about your servers, but on the ones I am seeing 8-12 cores with 64-128G of ram takes significantly more power than the 2-core servers with 4-8G of ram that I still have in production. measurements show somewhere between 2x and 3x

The case for the /usr merge

Posted Jan 30, 2012 21:06 UTC (Mon) by sbergman27 (guest, #10767) [Link]

This reminds me of that great TV commercial IBM did several years ago. "They've stolen the servers! They've stolen the servers!"

The Heist: http://www.youtube.com/watch?v=T-NpLu2xC38

-Steve

The case for the /usr merge

Posted Jan 30, 2012 20:10 UTC (Mon) by sbergman27 (guest, #10767) [Link] (2 responses)

"I would put 100k-150k for a lifetime of a car, most people don't hold on to them even that long."

That's quite a different thing than the lifetime of the car. It gets sold to someone else. Pick up an Autotrader mini-mag sometime. Basically, a classifieds specializing in used cars. Not classics, necessarily. Just used cars. 200,000+ miles is not in the least uncommon.

And I. too, would be interested in your data supporting your claim of such amazing efficiency improvements in computers.

Also, while I have your ear, and in reference to another thread, I would be interested in your explanation as to why the Linux i/o schedulers would not sort the read/write requests of a random access benchmark to provide *far* better performance than the 6ms per request then you seem to agree with Dave about. Even the noop scheduler does elevator sorting of requests. For that matter, so does the drive's internal cache.

If you do not understand one or more of those terms, let me know and I will explain them to you.

The case for the /usr merge

Posted Jan 30, 2012 21:08 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

I did some googling and came up with some representative links. The take-away is that each new generation of machines for the last 5 years or so has relatively the same or slightly higher power consumption but we went from dual single-core to dual dual-core to dual quad-core and dual hex-core without doubling, quadrupling, octupling power usage. All that power not generating heat also takes a load off cooling which is more power savings.

http://www.networkjack.info/blog/2007/02/13/power-consump...
http://www.utahsysadmin.com/2007/04/19/power-requirements...

http://www.dell.com/us/dfb/p/poweredge-1950/pd
http://www.dell.com/us/business/p/poweredge-r610/pd

As far as IO schedulers, elevators help but are no panacea. I think the estimate of 175 IOPS on a 7.2k RPM drive is about right. A 15k RPM drive may get you close to 250 IOPS but that's the limit of spinning rust. An average seek time of 6ms doesn't seem out of whack, it actually sounds pretty good. With perfect elevators if the data isn't immediately adjacent then there is going to be some number of milliseconds of track to track seek time for every IO. The longer IO is delayed so that it can be sorted the more latency is added onto all the requests. In any event a random IO test is going to be the worst possible case for an elevator algorithm.

For example here are the results of a naive model where one has 65535 tracks and a linear track to track seek cost. The first table is random and the second has been sorted by an elevator. In practice with disks there is always an elevator in the drive, in the drive controller, in the OS so you will never see the first access pattern and more sorting isn't going to make the second pattern any better.

More info on actual drive characteristics for better modeling

http://en.wikipedia.org/wiki/Disk-drive_performance_chara...

request address seek
1 62640 #VALUE!
2 34681 27959
3 21062 13619
4 39674 18612
5 46138 6464
6 42942 3196
7 3227 39715
8 25600 22373
9 62505 36905
10 18344 44161

Total 213004

request address seek
7 3227 #VALUE!
10 18344 15117
3 21062 2718
8 25600 4538
2 34681 9081
4 39674 4993
6 42942 3268
5 46138 3196
9 62505 16367
1 62640 135

Total 59413

The case for the /usr merge

Posted Jan 30, 2012 21:16 UTC (Mon) by sbergman27 (guest, #10767) [Link]

Let's move this back to the XFS thread.

The case for the /usr merge

Posted Jan 30, 2012 1:44 UTC (Mon) by slashdot (guest, #22014) [Link]

<<
The current 48-bit LBA scheme, introduced in 2003 with ATA-6 standard, allows addressing up to 128 PiB. Current PC-Compatible computers support INT 13H Extensions, which use 64-bit structures for LBA addressing and should encompass any future extension of LBA addressing, though modern operating systems implement direct disk access and do not use the BIOS subsystems, except at boot load time. However, the common DOS style Master boot record partition table only supports disk partitions up to 2 TiB in size. For large partitions this needs to be replaced by another scheme for instance the GUID Partition Table which has the same 64-bit limit as the current INT 13H Extensions.
>>

The limit is in the MBR format and/or BIOS implementation.

The case for the /usr merge

Posted Jan 30, 2012 23:03 UTC (Mon) by ondrej (subscriber, #27872) [Link] (1 responses)

> 'Binaries in /bin are often not even statically linked, or at least depend on libs inside /usr/lib.'

JFTR On my Debian stable system:
$ ls -1 /bin | wc -l
104
$ ls -1 /bin | xargs -i ldd {} | grep /usr
/bin/ping6
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f88fc791000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f88fc014000)

$ ls -1 /sbin| wc -l
182
$ ls -1 /sbin | xargs -i sh -c 'echo {}; ldd {}' | grep /usr -B10
fsck.cramfs
libz.so.1 => /usr/lib/libz.so.1 (0x00007f48dc0a2000)
mkfs.cramfs
libz.so.1 => /usr/lib/libz.so.1 (0x00007f478f0cb000)
mkfs.ntfs
libntfs.so.10 => /usr/lib/libntfs.so.10 (0x00007f4208125000)
mount.ntfs-fuse
libntfs.so.10 => /usr/lib/libntfs.so.10 (0x00007f02a6a86000)
libfuse.so.2 => /usr/lib/libfuse.so.2 (0x00007f02a6851000)
nfnl_osf
libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x00007f1af01b8000)
umount.udisks
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007fc7b1575000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fc7b1111000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007fc7b068f000)

Not that bad, isn't it?

The case for the /usr merge

Posted Feb 2, 2012 13:01 UTC (Thu) by Comet (guest, #11646) [Link]

FreeBSD and using *(.) in zsh to avoid the compatibility symlinks I've added for a couple of shells, not needed for booting:

% ls -1 /bin/*(.) | wc -l
41
% ls -1 /bin/*(.) | gxargs -i ldd {} | grep /usr
%

Use *(-.) to include the symlinks and there's output.

Myself, I use a separate / from /usr and /var because while / may need to be mounted read-write, it needs far fewer writes than the other areas. This means that in the event of a system crash it is less likely that there was I/O pending to / and increases the odds of my booting without having to sort out recovery options, just being able to repair and move on.

That applies no matter which OS. It has helped when some neighbours in a building with bad wiring were able to trip our fuses and rebooted my Linux box often enough before I bought a UPS. That helped me get up enough connectivity in those pre-bootable-USB-recoverydisk days to be able to make a CD backup of the stuff I could recover from a corrupted ReiserFS before reinstalling with ext3. Without a second CD drive or the money for a second computer, that would have been notably more awkward.

Some habits save your butt often enough that it is going to take a *lot* to convince folks like me that the latest shiny shiny is worth surrendering a practice which has proven its worth repeatedly.

The case for the /usr merge

Posted Jan 27, 2012 0:42 UTC (Fri) by sjj (guest, #2020) [Link]

It makes a lot of sense. Read the myth/fact part.

On a production RHEL5 server I have this:
$ du -sh /sbin /usr/sbin /bin /usr/bin /lib /usr/lib /lib64 /usr/lib64
38M /sbin
26M /usr/sbin
8.4M /bin
113M /usr/bin
130M /lib
440M /usr/lib
27M /lib64
339M /usr/lib64

$ du -sh /usr
2.2G /usr

I don't think you're going to find an SSD *smaller* than this, so why not just put everything on the same filesystem. Even on my Fedora desktop box (that I don't have access to right now), I don't think / and /usr are more than 15 GB together.

The split is from the era when hard drive sizes were measured in megabytes, not giga- or terabytes.

The case for the /usr merge

Posted Jan 27, 2012 0:42 UTC (Fri) by tchernobog (subscriber, #73595) [Link] (3 responses)

As explained in the article, booting without a /usr has been broken for years. That kind of support nowadays goes into a ~12MB initramfs. It won't be fixed even without the /usr move, as the initramfs + busybox and friends works well enough.

The idea of having /usr containing everything a system might want after booting (in terms of shared resources) is better, especially if you want to share it as a network filesystem or mount different guest systems using the same kernel.

For instance, to keep updated a distributed environment like a university lab you wouldn't have to care if running an update writes in /usr/bin (only one instance in the network, you update it centrally) or in /bin (changes need to be propagated manually).

Having /var and /etc in the root is because they offer different assets than /usr: they are machine-specific: each machine has its own version with its own configuration and spool directories (think of /var/mail). Binaries and shared files instead pertain to /usr.

Incidentally, if you were to put the whole /usr on a slower disk, considering 90% of libraries in use by a running system are in /usr/lib(64) and executables are in /usr, you wouldn't perceive much of a difference in performance. You'd waste your money on a SSD then. If you want to check, just try opening the normal applications you use (I don't know: firefox, evolution, libreoffice...) and run:

sudo lsof | awk '$9 ~ /^\/([s]?bin|lib)/ { print $9; }' | sort | uniq | wc -l
sudo lsof | awk '$9 ~ /^\/usr\/([s]?bin|lib)/ { print $9; }' | sort | uniq | wc -l

This actually doesn't tell you the whole story, because it should be seen also how many files are read at application startup from other directories such as /usr/share (all icons, desktop files, resources, databases, etc.). That bumps up the number considerably.

The case for the /usr merge

Posted Jan 27, 2012 2:06 UTC (Fri) by fest3er (guest, #60379) [Link]

For most desktop/server systems, there's little reason not to build the standard initramfs to contain everything needed to explore and repair a broken system. I did this, at least partly, with Roadster, my version of Smoothwall I've been developing. The install initramfs contains a usable user environment for checking hardware, exploring disks, hacking the installer, and other stuff.

In fact, the standard initramfs *needs* a number of utilities in order to boot the system anyway. So put all the necessary booting/fixing progs in the initramfs, and put everything in /bin and /lib on the hard drive. Building with '--prefix=/' will handle most of it; the rest is in system-specific scripts and config files.

That said, I can still see a good reason to keep /usr separate. Keep the most commonly used utilities, programs and libs in / and put the rest in /usr: it may well make it easier to keep /bin, /sbin and /lib dirs cached (the dirs, not necessarily their contents). The less you have to hit the disk, the faster the system will be.

The case for the /usr merge

Posted Jan 27, 2012 4:47 UTC (Fri) by steffen780 (guest, #68142) [Link] (1 responses)

Booting without /usr has been broken for years? How curious, I'm doing that right now and I hardly have what I'd call stale software (kernel 3.2.1, gcc 4.6.2, kde 4.8.0, ...). So I can't boot? That's rather annoying indeed!

The case for the /usr merge

Posted Jan 27, 2012 5:34 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

In this context "broken" means "will fail to work under various circumstances in which you would expect it to work" rather than "will fail under all circumstances". The work required to make separate /usr work in all circumstances would involve moving a large part of /usr to /, which kind of defeats the point.

The fundamental problem with a separate /usr is that writing a tool that may be used in the booting of some estoric platform or setup would require you to limit yourself to the libraries available in /. Those vary across distributions, so which subset do you use? If you want to use a library that's in /usr, do you duplicate the functionality in your code or get every distribution to move it to /? What if that library has dependencies on a pile of other libraries that are currently in /usr as well? The / and /usr divide artificially split the platform in two, without any clear semantics as to which subset of functionality you can actually depend on. The world has got more complicated than it was when the worst case was /usr being on an NFS server connected by ethernet. Something has to change.

The case for the /usr merge

Posted Jan 27, 2012 2:22 UTC (Fri) by AndreE (guest, #60148) [Link] (4 responses)

Firstly, this is about merging /bin, /sbin and /lib* into /usr. No one is suggesting that /var and /etc. should be merged. Let's stick to the real argument here.

Secondly, are you seriously suggesting the that performance of these rescue tools are constrained by their startup time due to the slowness of rotational media? And if performance is actually of such great importance, then what you really should be doing is, as has been suggested by Lennart, building them into a ramdisk, which is still much much faster than an SSD. Either way, "performance of system rescue" is not a compelling argument for such separation.

The case for the /usr merge

Posted Jan 27, 2012 8:43 UTC (Fri) by kju (guest, #61936) [Link] (3 responses)

building them into a ramdisk, which is still much much faster than an SSD
You really believe this? It is likely much slower because the ramdisk needs to be completely loaded into RAM (and maybe unpacked) before it can be used. If you only use part of the content (selected binaries) you are loading lots of unnecessary stuff and in the end this is much slower than loading only the needed files directly from an SSD.

The case for the /usr merge

Posted Jan 27, 2012 9:54 UTC (Fri) by ebiederm (subscriber, #35028) [Link]

Last I benchmarked it I could load a full distro image compressed to about 800MiB in about 8 seconds over GigE. Almost enough time to notice I was waiting and then everything ran out of RAM.

Anything less than a full distro looks like too little data to even care about the performance on modern hardware.

The case for the /usr merge

Posted Jan 27, 2012 21:42 UTC (Fri) by AndreE (guest, #60148) [Link] (1 responses)

Booting the ramdisk MIGHT be slower ( but I'd bet you'd have a hard time noticing). Running programs from the ramdisk would certainly be faster

So what arbitrary measure should we use to benchmark our system rescue? The main point remains that "performance of loading binaries" is hardly a prime concern for system rescue situations.

The case for the /usr merge

Posted Jan 27, 2012 22:06 UTC (Fri) by dlang (guest, #313) [Link]

> Booting the ramdisk MIGHT be slower ( but I'd bet you'd have a hard time noticing). Running programs from the ramdisk would certainly be faster

as long as you have enough ram to both hold the ramdisk _and_ the working set for all your applications.

The case for the /usr merge

Posted Jan 27, 2012 10:29 UTC (Fri) by k3ninho (subscriber, #50375) [Link]

>absolutely essential OS tools could reside, if necessary, on a very small file system usable for all rescue scenarios

Am I stupid to think you can mount these small, stable, reliable filesytems as subdirectories within the /usr folder? I'd really like to join in the bikeshedding here, but the everything-is-a-file metaphor has a complementary everything-is-mounted-somewhere concept which leads me to think 'meh'.

K3n.

The case for the /usr merge

Posted Jan 27, 2012 0:25 UTC (Fri) by xl0 (guest, #52696) [Link] (24 responses)

Oh noes! Lennart is trying to ruin everything yet again. :/ What did we do to deserve this?

The case for the /usr merge

Posted Jan 27, 2012 0:29 UTC (Fri) by Karellen (subscriber, #67644) [Link] (2 responses)

From Lennart's announcement, linked to in the LWN article:

"One of the features of Fedora 17 is the /usr merge, put forward by Harald Hoyer and Kay Sievers[1]"

"Primarily I put this together to have a nice place to point all those folks who continue to write me annoyed emails, even though I am actually not even working on all of this..."

"[1] And not actually by me, I am just a supportive spectator and am not doing any work on it. Unfortunately some tech press folks created the false impression I was behind this. But credit where credit is due, this is all Harald's and Kay's work."

FFS!

The case for the /usr merge

Posted Jan 27, 2012 0:32 UTC (Fri) by nirbheek (guest, #54111) [Link] (1 responses)

I'm pretty sure xl0 is joking. Of course, I could be wrong. Hard to tell based on a single comment. :)

The case for the /usr merge

Posted Jan 27, 2012 0:40 UTC (Fri) by xl0 (guest, #52696) [Link]

Or course I am. But every joke has some truth in it, and some of Lennart's creations seem to be a bit controversial.

The case for the /usr merge

Posted Jan 27, 2012 0:46 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (20 responses)

It's true that it's too easy to blame Lennart for the latest follies emerging from freedesktop.org, so sorry about that.

The freedesktop.org separate usr is broken page is what I had in mind when I vaguely recalled the non-sequitur '/bin no longer makes sense because it's common to have utilities in there dynamically linked to /usr/lib' argument, which I misattributed a minute ago to Lennart. (Obvious remedy to inappropriate lib dependencies: Don't Do That, Then.)

Rick Moen
rick@linuxmafia.com

The case for the /usr merge

Posted Jan 27, 2012 0:56 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] (19 responses)

I've had a number of issues over the decades related to what is in /bin vs /usr/bin, or what is in /sbin vs /usr/sbin. I will be happy to see the distinction go away (and Solaris has already done this).

Your "don't do that then" assumes that people can maintain a careful, rigorous, and correct distinction between /{bin,lib,sbin} and /usr/{bin,lib,sbin} and keep it clean, and evidence shows that they cannot.

The case for the /usr merge

Posted Jan 27, 2012 1:15 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (18 responses)

Joe wrote:

Your "don't do that then" assumes that people can maintain a careful, rigorous, and correct distinction between /{bin,lib,sbin} and /usr/{bin,lib,sbin} and keep it clean, and evidence shows that they cannot.

Your assertion rests on an incorrect foundational premise. I believe I said 'inappropriate library dependencies'. (Emphasis added.) That's not particularly difficult, as few contents in /lib are critical in situations where /usr is unavailable. One is the mount utility. Checking locally: 

 $ ldd /bin/mount
        linux-gate.so.1 =>  (0xb7867000)
        libblkid.so.1 => /lib/libblkid.so.1 (0xb7842000)
        libuuid.so.1 => /lib/libuuid.so.1 (0xb783e000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7823000)
        libsepol.so.1 => /lib/libsepol.so.1 (0xb77ee000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb76a7000)
        /lib/ld-linux.so.2 (0xb7868000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb76a2000)
 $

Gee, doesn't seem like I even had to do anything to avoid inappropriate /usr dependencies for that one.

Watch out for straw-man arguments, Joe. They can make you sneeze.

Rick Moen
rick@linuxmafia.com

The case for the /usr merge

Posted Jan 27, 2012 1:17 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (1 responses)

And I meant /bin, not /lib. Maybe sjj can breathlessly catch my error again, though this time he has only about a 30-second window.

The case for the /usr merge

Posted Jan 27, 2012 7:24 UTC (Fri) by hillman (guest, #82597) [Link]

WHAM!! You nailed him again! Way to go, bro.

The case for the /usr merge

Posted Jan 27, 2012 1:26 UTC (Fri) by josh (subscriber, #17465) [Link] (15 responses)

From just the binaries installed on my system:

/bin/ntfsdecrypt:
	libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f72ccfd8000)
	libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f72cc7c5000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f72cc5ad000)
	libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f72cc17f000)
/bin/ping6:
	libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fce2b78c000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007fce2afec000)
/sbin/fsck.cramfs:
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f7093762000)
/sbin/mkfs.cramfs:
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f28d6b53000)
/sbin/nfnl_osf:
	libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x00007fa4f20a8000)
/sbin/umount.udisks:
	libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007f7af2ca1000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f7af2832000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f7af1c4a000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f7af1a47000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f7af1842000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f7af0fd0000)
/sbin/wpa_supplicant:
	libpcsclite.so.1 => /usr/lib/libpcsclite.so.1 (0x00007f108a009000)
	libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f1089db7000)
	libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f10899f1000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f1088964000)

So, making /bin and /sbin self-contained without requiring /usr would require expanding the "minimal" root filesystem to include zlib, libcrypto, PKCS#11, PC/SC smart-card support, gnutls, libtasn, libnfnetlink, several glib libraries, gio, dbus, and OpenSSL.

All because, for example, someone *might* need to run wpa_supplicant to connect to a wireless network to mount /usr over NFS.

And this from Debian, a distribution which goes out of its way to allow its users to continue using insane use cases rather than just saying "don't do that then". (One of Debian's biggest features and biggest faults.)

The case for the /usr merge

Posted Jan 27, 2012 5:44 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

Hell, even nfs-common relied on libraries in /usr for several months and I don't think we got any bug reports from users before fixing it.

The case for the /usr merge

Posted Jan 27, 2012 8:50 UTC (Fri) by kju (guest, #61936) [Link] (11 responses)

Well in this context I believe the biggest failing of Debian (and still a feature) is to include many features of a package even if most users won't need it. Seriously when I see from your post that for example wpa_supplicant depends on libpcsclite it makes me shudder. Yes it's nice to have smartcard support in wpa_supplicant but the vast majority of users won't need it and this just adds an unncessary dependency.

The case for the /usr merge

Posted Jan 27, 2012 11:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

I need it. Why should it be removed in the name of separate /bin directory?

The case for the /usr merge

Posted Jan 27, 2012 12:01 UTC (Fri) by kju (guest, #61936) [Link] (9 responses)

And because you need it, everyone else should have binaries which have unnecessary depends and therefore use up more resources? It would make more sense to have a wpasupplicant-full package or something which includes all the bells and whistle and a more stripped down version for the majority of us.

The case for the /usr merge

Posted Jan 27, 2012 12:45 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (7 responses)

Or, why couldn't it just dlopen() rarely needed libs like this on the fly, if and only if it actually needs them at the time? Then, it wouldn't be linked against them and actually require them to run at all...

The case for the /usr merge

Posted Jan 27, 2012 14:20 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (6 responses)

The sanity or otherwise of that approach is so wildly variable that it can only be evaluated on a case-by-case basis. dlopen() adds a significant comprehensibility overhead compared to just invoking the library's API directly, and may well preclude sane-and-convenient use of the normal programming model for the library in question.

(The latter effect becomes particularly severe when you're writing a C++ program using C++ libraries, of course.)

The case for the /usr merge

Posted Jan 27, 2012 14:51 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (3 responses)

True enough... But, if it's just some obscure rarely used feature, I'd think it makes sense anyway... Even if you don't want to indirect all API calls through dlsym() and such, what you could do is separate out all the code that interacts with that library into a sort of plug-in library of its own, needing just one simple call into that lib from the main app to do everything... The separate lib can still directly call all functions from the system library with no confusing indirection, and even be linked against it if you want... (Or, the main app can just dlopen(RTLD_GLOBAL) it prior to dlopen()'ing this separate lib...)

The case for the /usr merge

Posted Jan 27, 2012 16:45 UTC (Fri) by dashesy (guest, #74652) [Link] (2 responses)

While the whole plugin approach is nice, it is not worth it just to save a few bytes. It might even produce bigger binaries, and the additional complexity will bring more errors.

The case for the /usr merge

Posted Jan 27, 2012 17:00 UTC (Fri) by RobSeace (subscriber, #4435) [Link] (1 responses)

I didn't think the idea was to reduce app size, but rather to reduce dependencies required for rarely-used features... So that one could choose NOT to install the plugin and its required system library, and still be able to use all the more common features of the app, and merely lose the ability to use the obscure feature...

Just run gentoo :-) n/t

Posted Jan 28, 2012 12:22 UTC (Sat) by Wol (subscriber, #4433) [Link]

Cheers,
Wol

The case for the /usr merge

Posted Jan 29, 2012 21:55 UTC (Sun) by elanthis (guest, #6227) [Link] (1 responses)

This is in part because the library wasn't designed for this use case in the first place.*

However, why should the library be directly dlopen'd? Why not put a plugin architecture into wpa_supplicant itself, with the plugin linking against the library normally, and with only a very narrow and plugin-friendly interface being shared across that dlopen boundary? This even makes it trivial to have the package manager intelligently support the package dependencies by putting the plugin in its own package; users who need the feature install the plugin and get all dependencies pulled in, and users who don't will not need those. There's then a case to be made that the network configuration tools in Anaconda and the desktop tools need to be made aware of feature package dependencies to pull these things in automatically, but that's a polish thing (not FOSS's strength, but not out of the realm of possibility by any stretch).

[*] There's an argument to be made -- especially in the FOSS world where the source is available and modifiable by anyone and everyone -- that libraries should offer the kinds of interfaces their clients prefer, rather than client applications making "not our fault" claims when library interfaces don't allow features users want (like moving dependencies from compile-time to run-time).

The case for the /usr merge

Posted Jan 30, 2012 2:30 UTC (Mon) by HelloWorld (guest, #56129) [Link]

The question is, why bother? It works just fine now and nobody outside the embedded world cares about the few dozen kB of "bloat" libpcsclite induces. On embedded systems, a custom-compiled version can be used. Any amount of time spent on stuff like this would a useless waste of developer resources.

The case for the /usr merge

Posted Jan 27, 2012 14:30 UTC (Fri) by foom (subscriber, #14868) [Link]

I'd bet that nobody has actually ever noticed the extra resources it uses, other than the very scarce "resource" of the extra lines in the ldd output.

The case for the /usr merge

Posted Jan 27, 2012 11:48 UTC (Fri) by sorpigal (subscriber, #36106) [Link] (1 responses)

> So, making /bin and /sbin self-contained without requiring /usr would require expanding the "minimal" root filesystem to include zlib, libcrypto, PKCS#11, PC/SC smart-card support, gnutls, libtasn, libnfnetlink, several glib libraries, gio, dbus, and OpenSSL.

You say this like it's ridiculous, but I don't see a big problem. On one of my systems, also Debian, I have 10 binaries in /bin or /sbin which need /usr, on another I have 11. They depend, between them, on 22 unique libraries. This seems like a small problem to require such a big solution.

"10 of 332 binaries in /bin and /sbin require /usr. Obviously the correct solution is to get rid of /usr and merge it into /, and not to move 22 libraries into /lib/" - does that sound right?

The case for the /usr merge

Posted Jan 27, 2012 14:21 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

And one day you find that /usr/lib contains nothing but high-level GUI libraries, because creeping dependencies have slurped everything simpler into /lib. Given that a lot of "separate /usr" advocates also seem to be "slimline /" advocates...

The case for the /usr merge

Posted Jan 27, 2012 1:10 UTC (Fri) by jmorris42 (guest, #2203) [Link] (2 responses)

Gotta agree with this one. The whole OS is small enough to stuff on the small expensive media now and just mount it at /usr if that is what floats yer boat. It is /var and /home where the massive consumption happens these days.

And I kinda like the notion of having all of the executables and libraries on /usr where you can just mount it readonly and have done with 90% of potential exploits... especially you mount /tmp as a separate filesystem and remove exec. Then you only need to watch out for /etc.

The case for the /usr merge

Posted Jan 27, 2012 21:16 UTC (Fri) by nix (subscriber, #2304) [Link]

Quite. I moaned about this when it was first mooted, but on further analysis, I was wrong. So this means a tiny bit of futzing with your initramfs to boot /usr early. Big deal. (A bigger deal is that busybox mount could historically not handle as many filesystem options as real mount, so if you were using busybox mount, you had to mount filesystems with an artificially limited set of options, then remount them with different options once you'd switched roots. I'm not sure if this has changed in recent versions of busybox mount or not.)

The case for the /usr merge

Posted Jan 29, 2012 15:13 UTC (Sun) by kasperd (guest, #11842) [Link]

especially you mount /tmp as a separate filesystem and remove exec.

I wish I could have that level of security on the computer I use for e-banking. Unfortunately a couple of years ago it was decided that allowing banks to compete on the quality of their e-banking systems was not acceptable in such a civilized country as Denmark. Instead one company was granted a monopoly on handling authentication for e-banking. And every bank in this country is now required to use that centralised authentication system.

The vendor of that system is guaranteed to not lose market share to competitors, so they can do whatever they please. One consequence of that is that if I want to access any e-banking, I must have /tmp mounted with exec. Mounting it noexec will prevent me from logging on the banks website.

The case for the /usr merge

Posted Jan 27, 2012 2:28 UTC (Fri) by arjan (subscriber, #36785) [Link] (5 responses)

I completely agree with this; in fact, for the OS I am working on, I already did this quite some time ago.....
(with various RPM macro glues and some auto-packaging tricks to cope with apps that still install stuff in the old places)

The case for the /usr merge

Posted Jan 27, 2012 8:52 UTC (Fri) by kju (guest, #61936) [Link] (3 responses)

Have some more details about the "OS you are working on"? I'm dreaming of something I call "legacy free linux" for so long (e.g. getting rid of things like /etc/passwd which are no longer strictly necessary since the advent of thinks like nss and pam).

The case for the /usr merge

Posted Jan 27, 2012 11:40 UTC (Fri) by kragilkragil2 (guest, #76172) [Link] (1 responses)

AFAIK he was working on Meego, so it might be Tizen now. Not sure though ..

The case for the /usr merge

Posted Jan 27, 2012 14:42 UTC (Fri) by arjan (subscriber, #36785) [Link]

I don't work on Tizen
(and MeeGo is basically dead, I'm not working on that anymore either)

The case for the /usr merge

Posted Sep 26, 2017 18:22 UTC (Tue) by pgagne (guest, #118775) [Link]

I too have thought of something like this in the back of my head. I was more thinking about device and protocol support and not including "legacy" items (which would require defining what that meant) from the kernel and userland (sort of what you were suggesting).

For example the kernel build would not include support for things like SATA (replaced by NVMe), old school bios (UEFI only), etc. Even going so far as removing IPv4 support in kernel and userland in favor of IPv6 only everywhere.

Clearly this would be a largely academic project, and would probably only boot on specialized hardware or in a VM, but I think it would provide an interesting testbed for certain projects.

The case for the /usr merge

Posted Jan 27, 2012 10:49 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

"The OS you are working on" definitely needs more publicity!

useless and useful distinctions

Posted Jan 27, 2012 5:16 UTC (Fri) by eru (subscriber, #2753) [Link] (17 responses)

It is surprising how much passion this trivial issue raises. Having used various Unix and Linux over the years, I got used to random variation in the usage of /bin and /usr/bin, and find it just an irritant that can well be eliminated. Just occasionally wastes a bit of time when porting scripts.

By the same logic, the distinction between the bin and sbin directories could also be eliminated.

By contrast, it would be useful to ghettoize all GUI programs to their own bin. They are typically large, depend on huge shared libraries and data files, and are not needed in all installations. In the distant past they usually lived in /usr/X11/bin. Something like this could be brought back. Probably better name it /usr/gui/bin to not tie it to any particular GUI platform.

useless and useful distinctions

Posted Jan 27, 2012 8:40 UTC (Fri) by gravious (guest, #7662) [Link] (7 responses)

Or maybe call it /Applications

useless and useful distinctions

Posted Jan 27, 2012 10:50 UTC (Fri) by cmccabe (guest, #60281) [Link]

I think it should be called /Bikeshed.

useless and useful distinctions

Posted Jan 27, 2012 12:30 UTC (Fri) by bluss (guest, #47454) [Link] (3 responses)

/Applications should better be a place for "packaged" programs that keep all their files together in one place. It's a nice concept from OS X with benefits both high and low.. to begin with you can just copy files into place, instead of trusting a random installer to not spray files over the filesystem ("services" you didn't ask for etc).

useless and useful distinctions

Posted Jan 27, 2012 16:56 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

That doesnt always work out that way in practice. Removing an app from /applications doesn't remove any settings or cache files in your home directory or any system wee services or config files. Applications absolutely do spread files around that don't get cleaned up when putting the .app in the trash

useless and useful distinctions

Posted Jan 30, 2012 1:39 UTC (Mon) by slashdot (guest, #22014) [Link] (1 responses)

That is a feature, since it results in uninstallation + reinstallation being a no-op.

useless and useful distinctions

Posted Jan 30, 2012 17:42 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

The downside is that it means there are old configuration files around when you upgrade. That's OK if you make sure that the new version can't be tripped up by older configuration files, but that's apparently harder than it looks. This isn't terrible when you're upgrading only one application, since you have only one configuration to look through for incompatibilities, but it can be a pain when you're upgrading your whole distribution while trying to keep an old /home. My recent experience is that tracking down configuration incompatibilities takes more time on a distro upgrade than installing all the packages. It's still easier than completely recreating a configuration from scratch would be, but it's a definite area for improvement.

useless and useful distinctions

Posted Jan 27, 2012 14:58 UTC (Fri) by smokeing (guest, #53685) [Link] (1 responses)

Call it (gasp!) /Program Files ?

useless and useful distinctions

Posted Jan 27, 2012 19:44 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

Well, lots of programs have bugs in dealing with spaces in paths. We might need a symlink to that, say, "/progra~1".

useless and useful distinctions

Posted Jan 27, 2012 11:43 UTC (Fri) by kragilkragil2 (guest, #76172) [Link] (5 responses)

Yeah, I also don't get why we still need sbin directories? Any ideas?

useless and useful distinctions

Posted Jan 27, 2012 12:03 UTC (Fri) by angdraug (subscriber, #7487) [Link] (4 responses)

For one, so that normal user's PATH isn't cluttered with commands that only root is supposed to run. Improves autocompletion, too.

useless and useful distinctions

Posted Jan 27, 2012 12:42 UTC (Fri) by zyga (subscriber, #81533) [Link] (1 responses)

I kind of like being able to tab-complete $ sudo ...

useless and useful distinctions

Posted Jan 27, 2012 17:58 UTC (Fri) by iabervon (subscriber, #722) [Link]

In order to tab-complete "sudo ...", your shell needs a rule that what follows "sudo" is found from $PATH, not cwd. If it has a rule, it can have the rule tab-complete based on /usr/bin and /usr/sbin instead of actually using $PATH (which is likely to include things like ~/bin which won't be in root's PATH, as well as not including /usr/sbin).

useless and useful distinctions

Posted Jan 27, 2012 17:52 UTC (Fri) by sjj (guest, #2020) [Link]

FWIW, Fedora has had sbin directories in the default user path since F10.

My personal annoyance is that ifconfig is in /usr/sbin, and I often need to consult it as a regular user.

useless and useful distinctions

Posted Jan 28, 2012 16:42 UTC (Sat) by josh (subscriber, #17465) [Link]

A quick look at the contents of /sbin on my system turns up quite a few programs useful for non-root users, and very few only usable by root. In particular, disk and filesystem utilities work well on loopback files, networking tools provide useful output, and most other binaries have some useful function for non-root (even if just displaying useful output without allowing changes).

useless and useful distinctions

Posted Jan 27, 2012 11:55 UTC (Fri) by sorpigal (subscriber, #36106) [Link]

I like the idea of merging bin and sbin dirs, since the distinction isn't really important in most cases. I would also like to get rid of /usr/bin/games, since its use is not much respected anyway and never made sense (who do games get to be a special class of binary but nothing else does? Throwing all pg* and mysql* tools into a separate dir makes at least as much sense).

I don't think getting into the business of putting binaries into different directories for categorization purposes is more useful than harmful. What is the goal? If it were to be done I think subdirectories of /usr/bin (or /bin if we're not using /usr any more) makes the most sense.

useless and useful distinctions

Posted Jan 27, 2012 21:18 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

That would be /usr/bin/X11, aka /usr/X11R{3,4,5,6}/bin. It was killed for a reason.

useless and useful distinctions

Posted Jan 28, 2012 14:58 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Which is a shame. I actually liked not having all the X programs in tab-completion in X-less terminals and consoles.

But yeah, it wasn't a big deal.

The case for the /usr merge

Posted Jan 27, 2012 11:10 UTC (Fri) by njwhite (guest, #51848) [Link] (18 responses)

The reasons for the /usr merge make a lot of sense, and I'm glad the arbitrary and confusing distinction between / and /usr are going away.

However I still don't really understand why dispatching of /usr and sending its directories into / isn't sensible. The only reason given in Fedora's FAQ is that it would mean mounting a few more network shares to get the OS over the network, but that doesn't sound like much of a hurdle to me. I'd just like /bin to contain all binaries, directly (not as a symlink). This solution has the most clarity to me. Can anyone explain slower why merging to /usr rather than to / is significantly better?

The case for the /usr merge

Posted Jan 27, 2012 11:59 UTC (Fri) by rleigh (guest, #14622) [Link]

I am a strong proponent of this strategy. It makes logical sense that were / and /usr to be unified, we only need the root. We can just have a /usr → / symlink for backward compatibility.

The primary issue is one of upgrading; it's common to have a small / and large /usr, in which case users would run out of disc space on upgrade due to their / being filled up. However, migrating the smaller content of / to /usr is less likely to fail. This would not be an issue for clean installs. Given the appropriate documentation, and resizing of partitions prior to an upgrade, this is possible to work around.

The advantages are numerous, and it makes long-term sense to unify the two. On a modern package-managed system, the two are intimately tied, and the historical reasons for the split no longer apply. It's not just library dependencies that become simpler, we also have access to the glibc locale data from the moment init starts, meaning that it's possible to use UTF-8 locales in early boot, in addition to having no chance of NSS or PAM modules failing due to missing dependencies.

Regards,
Roger

The case for the /usr merge

Posted Jan 27, 2012 12:08 UTC (Fri) by angdraug (subscriber, #7487) [Link] (6 responses)

Check the comment by jmorris42 earlier in the thread, he's already explained why it would be nice to have /usr with all the executable files in it mounted read-only at all times, except when you're upgrading the system. The security benefit alone is tremendous.

The case for the /usr merge

Posted Jan 27, 2012 12:15 UTC (Fri) by njwhite (guest, #51848) [Link] (2 responses)

The security benefit of mounting read-only is marginal. If a user has access to write files which are marked read-only in the filesystem, they have access to remount /usr read-write. Unless I'm missing something?

The case for the /usr merge

Posted Jan 27, 2012 16:52 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Read-write access can be controlled at the server for networked filesystems and not overridden by the client. Even in a local filesystem case it can prevent accidental modification or break canned exploit scripts

The case for the /usr merge

Posted Jan 27, 2012 18:31 UTC (Fri) by iabervon (subscriber, #722) [Link]

Just having /usr mounted read-only isn't that big a win, but if the system will work with /usr mounted read-only, it will also work (which real benefits) if /usr is storage the system is technically incapable of modifying. (That is, where changing it requires doing something entirely different, like swapping CDs or flipping a physical switch on the device or something like that; or where it is a different system which can modify it.)

The case for the /usr merge

Posted Jan 27, 2012 18:08 UTC (Fri) by jmorris42 (guest, #2203) [Link] (2 responses)

And I just had another thought along those lines.

With this change /usr is basically the same as \Windows, the whole OS is in one directory except we are smart enough to pull out the dynamic info into /var and /etc. Now we just make /etc a symlink to /var/etc and we get the whole operating system down to two directories, one per host changing information and one static read only binaries, libraries and documentation.

Of course they are also busy repolluting / with new top levels, otherwise we could look forward to a root with only:

/boot for the boot loader, kernel and initrd
/dev
/home for users
/media as the modern replacement for /mnt
/opt, probably can't get 3rd party vendors to give up on that one.
/proc for the kernel
/root since it probably can't go in /home/root safely
/sys for the kernel
/usr for the OS
/var for the OS

Plus symlinks for /bin, lib and /sbin. But I currently have /cgroup, /run and /srv cluttering things up. Why did we need those others in root and not somewhere under /var or /sys?

The case for the /usr merge

Posted Jan 27, 2012 20:08 UTC (Fri) by sytoka (guest, #38525) [Link] (1 responses)

/lib64 is just horrible. Debian have a nice solution for multi-arch that will be maybe in wheezly....

The case for the /usr merge

Posted Jan 28, 2012 12:27 UTC (Sat) by Wol (subscriber, #4433) [Link]

Are they changing release names from Toy Story to Harry Potter? :-)

Cheers,
Wol

The case for the /usr merge

Posted Jan 28, 2012 4:43 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] (9 responses)

I think the underlying idea is to move all of the program stuff that can potentially be shared between systems to /usr and leave the system specific stuff like /etc on /. That way you can have /usr on a network share, probably mounted read only, with only a minimal / partition. As I see it, there are two reasons this is a better solution than moving everything from /usr down to /:

  1. There are things that exist in /usr that don't currently exist in /, like /usr/share and /usr/src. That means merging /usr down to / doesn't just involve moving binaries and libraries to different directories; it means you have to add a bunch of directories to /, which is generally frowned upon.
  2. Related to this, moving stuff down to / is messy if you want to network mount your binaries (one of the goals of the project) because /usr has a bunch of directories. On my system, /usr has 11 subdirectories, so fully sharing it as separate directories under / would involve 11 separate mounts.

So the options are pushing everything into /usr, which lets you mount your binaries from the network with 1 mount and requires 4 symlinks in / for backward compatibility, or pushing everything down to /, which requires 11 mounts to network everything and 11 symlinks in /usr for backward compatibility. Pushing stuff up into /usr sounds a lot simpler to me.

The case for the /usr merge

Posted Jan 28, 2012 23:43 UTC (Sat) by lindi (subscriber, #53135) [Link] (7 responses)

How would sharing read-only /usr really work in a distro with package management? The package management state would be in /var anyway, how would it then track files in /usr?

The case for the /usr merge

Posted Jan 29, 2012 7:30 UTC (Sun) by raven667 (subscriber, #5198) [Link] (5 responses)

The simplest solution seems to be to manage the packages on the file server, just share out its /usr. Trying to manage packages on the client systems is folly for the reason you mentioned and probably others.

The case for the /usr merge

Posted Jan 31, 2012 5:11 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

That lets you manage the packages, but it doesn't fix the problem of packages that want to put files outside of /usr, especially into /etc. You'll need some way of getting any updated files from the server to the rest of the systems. Some of that is probably a sign that /etc needs a serious cleanup- there's a fair amount there that looks as if it belongs in /usr/share rather than /etc, and some of the other configuration stuff might be better done dynamically- but even with a well managed distribution there's going to be a need for updated files in /etc.

The case for the /usr merge

Posted Jan 31, 2012 7:22 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

The cases where there is a shared /usr implies a degree of sophisticated system administration already, probably capable of rolling out more complex changes if necessary when there is a platform update. That said, the common case is going to be patch deployment that should not require changes outside of /usr and for admins used to RHEL they won't expect intra platform upgrades anyway.

Actually thinking of RHEL I see a use case for virtualized servers where many OS instances share /usr but have private /var, /etc and /opt. That could provide great gains in memory and disk dedup for "free"

The case for the /usr merge

Posted Jan 31, 2012 19:35 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

Actually thinking of RHEL I see a use case for virtualized servers where many OS instances share /usr but have private /var, /etc and /opt. That could provide great gains in memory and disk dedup for "free"

Virtualized machines is one of the use cases they mention specifically. The idea is that with all of the binaries and libraries pushed into /usr, / will shrink to something quite small and it will be easy to give every server its own copy without wasting much space. Cleaning up /etc would make management easier and save space for that kind of virtualization.

The case for the /usr merge

Posted Jan 31, 2012 13:17 UTC (Tue) by bluss (guest, #47454) [Link]

Maybe union-mounted /etc and /var?

The case for the /usr merge

Posted Feb 2, 2012 17:47 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Environments that want to share /usr probably use tools like Chef or Puppet to control the content of /etc anyhow. At least, we do. ;-)

That said, there are really many files in /etc that are there for historical reasons and could go to /usr/share, IMHO.

The case for the /usr merge

Posted Jan 29, 2012 10:55 UTC (Sun) by nix (subscriber, #2304) [Link]

On a system with read-only /usr, you would of course make the package-management directories in /var symlinks into somewhere under /usr. Package management state is then shared.

The case for the /usr merge

Posted Jan 29, 2012 0:58 UTC (Sun) by dlang (guest, #313) [Link]

however since package managers don't know how to deal with a /usr that's shared between machines (an update isn't confined to only making changes within /usr) I really question the value of this argument as a practical matter.

I tend to build my machines using /, /var, and a spare / (for upgrades rollback) but that doesn't mean that all files that are in subdirectories should get moved up.

it seems like a lot of this is to work around problems in the rpm packaging system, and that the arguments against it are dismissed because 'fedora is broken in that situation anyway'

The case for the /usr merge

Posted Jan 27, 2012 12:08 UTC (Fri) by jensend (guest, #1385) [Link] (9 responses)

Great idea! Why not just move the entire FS into /usr? Then after some years we can move the entire hierarchy into /usr/bin or something like that (/usr/usr? then after that, /usr/usr/usr?) and so on ad infinitum...

If the prefix has become meaningless or useless, why keep it? Wouldn't moving things from /usr/foo back to /foo make more sense?

The case for the /usr merge

Posted Jan 27, 2012 12:10 UTC (Fri) by jensend (guest, #1385) [Link]

BTW, I see their FAQ entry, I'm just not buying it.

The case for the /usr merge

Posted Jan 27, 2012 16:46 UTC (Fri) by paulj (subscriber, #341) [Link] (6 responses)

Yeah, double-plus on this. If separate / and /usr do not make sense anymore (and I'd agree with that - storage is cheap these days), then it should be the /usr/ stuff that's migrated to /, not other way around!

The case for the /usr merge

Posted Jan 27, 2012 17:01 UTC (Fri) by raven667 (subscriber, #5198) [Link] (5 responses)

I'm not sure what this has to do with storage, you'll need the same amount of space in either case. For a locally installed system it doesn't make sense to have /usr be a seperate mount point at all. Where keeping stuff in /usr makes sense is in the remote mount situation so that there is one mount point needed, also look at how many subdirectores are in /usr, do you really need them all in / and all with separate mountpoints? That seems obviously less clean and organized than just centralizing the system into /usr.

The case for the /usr merge

Posted Jan 27, 2012 17:33 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

Well, I wasn't intending to get into an argument about the merits of a separate /usr. Storage is cheap in that there is no merit locally in having a separate /usr for either speed or convenience of rescue (i.e. any media you might use for rescue will almost certainly be big enough for a full system). As for remote mount:

a) It's been a *long* time since this was supported by distros.

b) Package management generally can't cope with shared /usr's (Solaris IPS is the only modern one I know of that tried to, for zones - but it's hard & I don't know if they succeeded).

c) If you can't share /usr's, then there's no real point having a separate /usr - just remote mount the whole /.

As for /usr/ having lots of directories, and that it'd pollute /:

# for H in /usr/* ; do printf "%14s in /?: " $H ; [ -d ${H#/usr} ] && echo yes || echo no ; done
/usr/bin in /?: yes
/usr/etc in /?: yes
/usr/games in /?: no
/usr/include in /?: no
/usr/lib in /?: yes
/usr/lib64 in /?: yes
/usr/libexec in /?: no
/usr/local in /?: no
/usr/sbin in /?: yes
/usr/share in /?: no
/usr/src in /?: no
/usr/tmp in /?: yes

Half the /usr dirs are in / already (actually, one of them is same directory). Of the rest, at least 1 or 2 are system directories (libexec, share) that should be kept in the system directory (i.e. /, if you're moving to /). Which leaves games, local src and include. Those could stay in /usr I guess (/usr will have to stay anyway, to keep backwards-compat symlinks).

The case for the /usr merge

Posted Jan 27, 2012 18:13 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

a) standardizing and simplifying management make supporting remote /usr easier
b) in a shared /usr system packages would only be installed on the file server system so the clients wouldn't need the package tools or database
c) I think you probably can share /usr, at least some people wish to have that capability cleanly and safely.

To have a shared system with everything in / you'd need seperate mount points for at least

/bin
/include
/lib
/lib64
/libexec
/sbin
/share
/src

rather than one mount point for /usr which seem simpler.

The case for the /usr merge

Posted Jan 28, 2012 12:26 UTC (Sat) by rleigh (guest, #14622) [Link] (2 responses)

This sort of approach is no longer useful, IMO. Why would you /want/ a remote /usr? That is to say, when you can even more easily have a remote / (which includes /usr)? This makes no sense in a package-managed environment where / and /usr are a managed whole. Modern systems have so much disc space, that sharing /usr between systems is a historical curiosity only. By all means share the /entire/ rootfs, but /usr separately is not useful.

Regards,
Roger

The case for the /usr merge

Posted Jan 29, 2012 22:19 UTC (Sun) by elanthis (guest, #6227) [Link]

Storage is not the problem. It has _never_ been the problem, even back when storage was small and not necessarily that cheap. Management is the problem. These are of course problems many Linux users are not familiar with, as their Linux experience is basically limited to "I run a Web server out of my mom's basement and I put Ubuntu on my laptop 'cause I'm such a tech-rock-star woooo go me!" Folks who have to or had to manage large rollouts of dozens, hundreds, or thousands of servers or workstations are the audience of separate /usr these days, not the masses of Linux fans.

I don't want to have to upgrade 10,000 machines individually. I want to upgrade one network image, and have all 10,000 machines automatically get the update next time they reboot and attach to the network share. (Noting that this is doable by versioning the images, having new connections always get the newest image, and existing connections retaining the image they already had.)

And when doing that, I want to have ONE network share to update, so there are no race conditions or such when a client is halfway through mounting /bin, /lib, /share, etc. and the rollout kicks in.

Finally, / itself can't just be the share point, because if it is to be read-only then /var, /etc, /home, /tmp, and so on would be screwed. The best you could do would be to put something like "/var /dev/sda1" into the network-mounted /etc/fstab, but then various other bits of machine-specific data need a lot of hacks to get working correctly. I've seen people try these hacks, like putting /etc on a separate network share and serving different images based on MAC/IP that are known to correlate to different hardware configurations... but man is that a lot of work and very error-prone.

The case for the /usr merge

Posted Feb 2, 2012 17:52 UTC (Thu) by jschrod (subscriber, #1646) [Link]

> Why would you /want/ a remote /usr?

If you have an environment with 100,000s of virtual machines, you want it. Package management is not a problem there, it happens on the server; /etc on local systems is controlled by Chef/Puppet/some other SCM system.

The case for the /usr merge

Posted Feb 2, 2012 17:53 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Because /usr is one remote mount, otherwise I'd have ca. 10 of them, for each sub-dir of /usr.

The case for the /usr merge

Posted Jan 27, 2012 12:39 UTC (Fri) by bluss (guest, #47454) [Link] (2 responses)

Snapshotting is a claimed feature, yet /etc and /var usually change with package upgrades and installations. If you rollback /usr, you will have to rollback /etc and /var as well.

The case for the /usr merge

Posted Jan 27, 2012 19:48 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Yes, I noticed that too. Changes to /usr should already be easily reversible by downgrading the package. Changes to /etc and /var may not be reversible without resort to backups, and that's where the snapshot feature might be more useful.

The case for the /usr merge

Posted Jan 28, 2012 2:30 UTC (Sat) by russell (guest, #10458) [Link]

Snapshotting is never going to be an atomic operation, this is a false argument for unified /usr. What happens if a package is being installed when the snapshot takes place. e.g. parallel installation of a tarball by someone else. If you roll back you end up with something half installed.

So you have to procedurally "quiesce" the system FS to avoid race conditions. Given that, what's the difference between snapshotting one FS or 3,4,5,etc?

The only reliable way to manage the system is to use the package manager to undo the changes as it currently does. And if this is not possible, because the system won't run the package manager. Shame the sys admin who broke it for being so careless.

The case for the /usr merge

Posted Jan 27, 2012 15:41 UTC (Fri) by deater (subscriber, #11746) [Link] (1 responses)

From all of their claims about "traditional UNIX" you can tell they haven't used many traditional UNIXes. I seem to remember on Irix that ifconfig was under /etc for some reason, that was always fun to remember.

Also anyone who has ever used Solaris should shudder at the thought of making the Linux userspace more like theirs, although I have to admit I haven't used Solaris 11 yet.

I ran a large cluster where /usr was mounted read-only by all the compute nodes,
which PXE-booted with a bare-minimal / in initrd (just enough to mount /usr). Worked well most of the time except for shutdown, when the initscripts just couldn't handle the idea that /usr would go away at unmount-all time. I suppose this proposal wouldn't necessarily make things worse, but it will make it harder to populate an initrd with a minimal / setup if no one is even pretending to try to have a version of mount that can live w/o /usr anymore. I guess you'd have to make it out of busybox or something instead of just copying over selected files from /bin, /sbin, and /lib.

The case for the /usr merge

Posted Jan 28, 2012 12:20 UTC (Sat) by rleigh (guest, #14622) [Link]

"I ran a large cluster where /usr was mounted read-only by all the compute nodes,
which PXE-booted with a bare-minimal / in initrd (just enough to mount /usr). Worked well most of the time except for shutdown, when the initscripts just couldn't handle the idea that /usr would go away at unmount-all time. I suppose this proposal wouldn't necessarily make things worse, but it will make it harder to populate an initrd with a minimal / setup if no one is even pretending to try to have a version of mount that can live w/o /usr anymore. I guess you'd have to make it out of busybox or something instead of just copying over selected files from /bin, /sbin, and /lib."

Exactly, this is essentially describing a modern initramfs. Nowadays, there's no need to mount /usr over the network in a cluster environment--you just NFS mount the rootfs (which can include /usr), making the need for a separate /usr in this context redundant.

The case for the /usr merge

Posted Jan 27, 2012 15:51 UTC (Fri) by landley (guest, #6789) [Link] (2 responses)

I've been symlinking /bin /sbin and /lib to their /usr equivalents in my systems since 2001. I've ranted about it multiple times:

This was more than 5 years ago:
http://landley.net/hg/aboriginal/file/be48c60f9edb/design...

This was last year:
http://lists.busybox.net/pipermail/busybox/2010-December/...

And so on...

The case for the /usr merge

Posted Jan 27, 2012 16:32 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (1 responses)

Very useful stuff, thanks. I have linked your mail from 2010 now on the wiki text.

Thanks,

Lennart

The case for the /usr merge

Posted Jan 28, 2012 0:20 UTC (Sat) by landley (guest, #6789) [Link]

And from there it hit http://news.ycombinator.com/item?id=3519952 where people who were actually around at the time are commenting on it...

Rob

The case for the /usr merge (WOW just WOW)

Posted Jan 27, 2012 17:33 UTC (Fri) by ebiederm (subscriber, #35028) [Link] (1 responses)

A huge part of the justification is that they are doing this to provide compatibility with commercial unix.

Very politely let me point out that the largest commercial unix is linux.

The case for the /usr merge (WOW just WOW)

Posted Jan 27, 2012 18:14 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I think they are just pointing out that it has been done on other UNIX OSs successfully so it's not an untried thing.

The case for the /usr merge

Posted Jan 27, 2012 18:27 UTC (Fri) by gb (subscriber, #58328) [Link] (41 responses)

Someone should tell that guys to stop 'fixing' things that already working!

The case for the /usr merge

Posted Jan 27, 2012 18:35 UTC (Fri) by raven667 (subscriber, #5198) [Link] (40 responses)

What do you mean "already working" or for that matter why is fixing in quotes as if you mean breaking. There is already a list of many things that would be broken in a default system if /usr isn't mounted both on freedesktop.org and even in the comment thread. That means /usr is currently _REQUIRED_ to be mounted in early boot or some parts of the system will be broken. Since a working user is required to have a fully working system, and has been for some time now, then there is no justification for having a separate /bin, /sbin/, /lib. Standardizing this in one place, as has been done on other UNIX OSs, fixes a bunch of corner cases, opens up easier setup for having the system files on shared/networked storage and _can't_ break anything because there are symlinks from the original location to the new standard location. This is all upside. People do like their bike shed arguments though.

http://www.freedesktop.org/wiki/Software/systemd/separate...

The case for the /usr merge

Posted Jan 27, 2012 19:15 UTC (Fri) by gb (subscriber, #58328) [Link] (39 responses)

Oh, it's already broken. Thanks for link... Now i am wondering how my home desktop still working without initramfs, i have a / on raid, and do not want to create and maintain special purpose initramfs to mount all partitions.

From my point of view, it's something wrong with using initramfs in general. It is some special fs which is autogenerated and has predefined purpose - load drivers required to start up /, i think it should not be customizable by user (because it's not easy to do so), so it can serve only as very limited replacement of /.

Just sad, it seems for me that Linux goes somewhere to hell. Than i switched in 2000 it were so nice system, but now it has gconf(i never liked windows registry), d-bus(i can't just run program as other user, need launch d-bus), network manager(gui only!), video drivers in kernel space(kms!), gnome3, pulseaudio, (notice all this is rh ideas!) and this list seem growing. And now someone unhappy with system layout, that's why i am saying: it works just don't touch it please, put your effort in something useful...

The case for the /usr merge

Posted Jan 27, 2012 20:26 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

>Now i am wondering how my home desktop still working without initramfs, i have a / on raid, and do not want to create and maintain special purpose initramfs to mount all partitions.

Kernel can autoassemble RAID arrays, so in simple cases it is possible to make do without initramfs.

However, it's a doomed battle. It's way to easy to create configurations that can't be sanely processed inside the kernel.

The case for the /usr merge

Posted Jan 27, 2012 21:17 UTC (Fri) by gb (subscriber, #58328) [Link]

Sure, kernel does exactly that for my /, and mdadm init script assemble rest.

The case for the /usr merge

Posted Jan 30, 2012 9:08 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> Kernel can autoassemble RAID arrays, so in simple cases it is possible to make do without initramfs.

From my recent experience: it can, but only with the old metadata format. My impression is that this functionality is deprecated and nobody cares about it anymore. I trust that the kernel devs know what they're doing, so I'm not complaining ;)

The case for the /usr merge

Posted Jan 27, 2012 20:28 UTC (Fri) by cmorgan (guest, #71980) [Link]

All of those services you mention are just a part of the system growing up and developing.

The best thing is that the source is open so no one is really stuck using something they don't want to use. You've got the option to fix it and if people agree they'll follow enthusiastically.

The case for the /usr merge

Posted Jan 27, 2012 21:00 UTC (Fri) by Kit (guest, #55925) [Link]

>gconf
gconf already existed in 2000 ;) And there's nothing fundamentally wrong with using a common infrastructure for configuration (instead of the mess of almost-compatible hand-rolled systems out there that's common in the non-desktop realm).

>d-bus(i can't just run program as other user, need launch d-bus)
Maybe it's because I tend to use KDE, but I've never had to /manually/ start dbus when launching programs as another user. DBus is definitely a massive improvement over the crapfest we had before, where KDE had one system, GNOME had multiple failures, and they couldn't work together. It also couldn't be used by system services to provide services to standard users.

>network manager(gui only!)
nmcli?

>video drivers in kernel space(kms!)
I'll take video drivers (partly) in kernel space over having BOTH a video driver in kernel space (to manage the console) _AND_ a massive user-space process poking the hardware, and arbitrarily switching between them. A kernel is supposed to take care of the hardware, and Linux wasn't. Quite frankly, I can't recall a person ever complaining about KMS on a fundamental level.

Hell, now I can switch VTs without worrying that the system will crash... couldn't say I had much confidence about that back in the day!

>gnome3
I've not been able to run it since it requires decent graphics drivers... which I still don't have on any system (Linux graphics sucks for many users still... but even the suck is far better than the joke that it was back in the XFree/early Xorg days), so I can't really comment on GNOME3 much.

>pulseaudio
Had some hiccups early on (primarily due to ALSA drivers being buggy), but I definitely appreciate the features it gives. hell, anything that makes it so mplayer wouldn't hijack the system's PCM/master channel as its "volume control". PulseAudio has definitely been a massive win for Linux (well, 'win' in the since of 'making Linux competitive with OSX/Windows on the desktop', and in some cases even being better).

>(notice all this is rh ideas!)
An absurdly large percentage of stuff that occurs in Linux land has Red Hat involved to at least some extent. They're involved with every level of the stack, from the kernel to the desktop environment, paying people to improve it. RH even pays people to improve Linux in ways that doesn't benefit RH, at least beyond the belief that "any improvement to Linux is good for RedHat". Thank you Red Hat.

>And now someone unhappy with system layout, that's why i am saying:
>it works just don't touch it please, put your effort in something
>useful...
The / and /usr separation on Linux is done quite haphazardly these days (what goes where? who cares, just put it somewhere!), and mostly exists only because "that's how its always been done". Something needs to be done about it... either moving everything into /usr, or actually trying to standardize what goes where (which won't be easy), or something else. But there's no reason to keep it the way it is when the way it is makes no sense, and could be greatly improved.

Linux needs people willing to try things, and to buck "it's how we always did it"isms. A lot of them won't lead to improvements and won't go anywhere, but, if you don't try, Linux will stagnate... and stagnation results in death.

The case for the /usr merge

Posted Jan 27, 2012 21:32 UTC (Fri) by nix (subscriber, #2304) [Link] (11 responses)

Most of these are actually good ideas.

initramfs: without it, a *lot* is impossible. No heavily modular kernels. No rootfs on LVM. No rootfs on md/RAID. No rootfs on any other filesystem requiring userspace involvement to mount. No rootfs over the network (sounds silly for most machines until you have a disk failure and can revive the system, temporarily mounting everything over the network, with a one-line change). The list goes on and on. And the cost of the initramfs? These days, nearly nil.

dbus: we didn't have a decent RPC mechanism on Linux before now. SunRPC is dead and a security nightmare to boot. The service invocation stuff is nice too, no longer do we need scads of always-running daemons for rarely-needed jobs. The XML configuration file swarm is a horror, I wish they'd picked something, *anything* else. But we can't have everything.

network-manager: useless-verging-on-destructive on machines with wired networks doing lots of persistent network connections to other machines (e.g. remote filesystems). Bloody useful in dynamic situations, e.g. laptops with wifi. Which is these days a pretty common case.

KMS: video drivers in userspace were a nightmare to keep working, and there are lots of things they simply cannot do: a lot of the jobs necessary to keep modern video cards happy requires privileged support, some of it requires interrupt handlers (which is a kernel-only thing), much of it requires a full-blown memory manager to manage memory on the card, which will only work if the video driver is shared between X instances, which means the kernel again or some sort of cross-user, cross-X-instance daemon. Drivers for hardware in userspace sometimes work OK, but normally only if driving the hardware is simple (e.g. USB, and even there the job of driving the actual USB hardware is down to the kernel). Video cards are by some distance the most complex hardware on the system: driving them from userspace was always backwards, and was dragging X down.

gconf: well, OK, I'm a KDE man and prefer the ini-files-and-ksycoca thing. gconf *is* horrible and has no right to exist: there are better ways to provide performance as good as binary deserialization without needing all your configuration to spend all its time living in a binary lump.

pulseaudio: as long as we have to have a software mixer -- and we do, modern sound cards don't do hardware mixing -- we may as well make it a nice capable one. When you do that it turns out that nothing it has to do requires kernel-side operation, and for the non-pro-audio use-case of pulseaudio millisecond latencies are not required, so you might as well implement it in userspace. I note that you cannot simultaneously damn pulseaudio for being in userspace and KMS for being in kernelspace while remaining consistent.

The reason why a lot of these are RH ideas is because RH does so much of the work to keep Linux infrastructure going.

The case for the /usr merge

Posted Jan 28, 2012 14:44 UTC (Sat) by Los__D (guest, #15263) [Link] (10 responses)

> gconf: well, OK, I'm a KDE man and prefer the ini-files-and-ksycoca thing. gconf *is* horrible and has no right to exist: there are better ways to provide performance as good as binary deserialization without needing all your configuration to spend all its time living in a binary lump.

Errrr, GConf is not using a binary lump... It is using directories and XML files.

The case for the /usr merge

Posted Jan 28, 2012 15:02 UTC (Sat) by nix (subscriber, #2304) [Link]

I thought it could use both, but preferred binary lumps?

... oh, hang on, that's *d*conf, isn't it, where the d stands for 'a letter earlier than g in the alphabet' or something like that. I always get them mixed up.

gconf

Posted Jan 29, 2012 0:22 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link] (8 responses)

..in fact, gconf really is excellent. It:
- Has an underlying XML filestructure, which is possible to manually edit (though not so good as the .ini format), and these files can be copied around like other dotfiles.
- Has a CLI interface, gconftool-2, which lets you get and set certain keys. This is REALLY(*) useful.
- Can support changing settings in real-time (across multiple instances of the app without restarting the app, and even without needing an "Apply" button).
- Has a GUI editor: gconf-editor, which is useful for finding the keys whose name you don't know.

(*)For example, I've set up a new system. I want to preserve most of the system defaults, and especially if there is a new feature I don't know about, I don't want to remove it from the conf-file. But there are about 20 settings I really want to keep. So I have a script with lots of lines such as:
gconftool -t string -s /apps/metacity/general/button_layout 'menu:minimize,maximize,close'
I can run these commands inside a running GNOME session, and they immediately take effect.

[Sadly, KDE doesn't have such a system, as far as I can tell. It's impossible to script the setup of a KDE system in a non-brittle way]

gconf

Posted Jan 29, 2012 11:38 UTC (Sun) by k8to (guest, #15413) [Link] (2 responses)

You lost me at "excellent ... XML".

gconf

Posted Jan 29, 2012 22:49 UTC (Sun) by Los__D (guest, #15263) [Link] (1 responses)

I was just waiting for an ridiculous comment about XML... A there it was.

gconf

Posted Jan 29, 2012 23:09 UTC (Sun) by k8to (guest, #15413) [Link]

That was actually a pretty reasonable one. I could make a ridiculous one if you want.

gconf

Posted Jan 29, 2012 15:27 UTC (Sun) by HelloWorld (guest, #56129) [Link] (4 responses)

> [Sadly, KDE doesn't have such a system, as far as I can tell. It's impossible to script the setup of a KDE system in a non-brittle way]
KDE does have tools for that purpose. Check out kwriteconfig/kreadconfig. It doesn't work as well gconf though. Changes aren't applied immediately, and there's no GUI editor I'm aware of.

gconf

Posted Jan 29, 2012 15:41 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link] (3 responses)

I know of kreadconfig/kwriteconfig. Unfortunately, it doesn't work at all well - you have to already know which file the setting is in, and details of the setting name and the ini-file grouping. kread/writeconfig are simply a friendlier equivalent of 'sed' that speaks the .ini format.

The way this should work (and I filed a bug on this years ago) is that kcontrol ought to expose every single field in the GUI via DCOP. Then it would be easy to find out what keys to use. At least a way to recursively dump all the kreadconfig keys would be nice...

gconf

Posted Jan 30, 2012 2:34 UTC (Mon) by HelloWorld (guest, #56129) [Link] (2 responses)

Huh? You can explore the configuration simply by looking at ~/.kde/share/config, so why do you need kreadconfig to dump all keys?

gconf

Posted Jan 30, 2012 2:44 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link] (1 responses)

Well, it can be rather tricky to find out which conf-file does what, if you don't already know. If you don't know the key-name, section-name, or possible values, it's not easily discoverable.

BTW, In gnome, the easiest way to derive the changes is this:

1. Start with a clean distro installation.
2. Dump all the gconf keys.
3. Change lots of things to taste, within the GUI.
4. Dump all the gconf keys.
5. Use diff to discover the changes, and generate a script that will make these changes the next time.

gconf

Posted Jan 30, 2012 3:32 UTC (Mon) by HelloWorld (guest, #56129) [Link]

I still don't get it. What stops you from doing just the same with .kde/share/config? diff -r is your friend.

The case for the /usr merge

Posted Jan 27, 2012 21:39 UTC (Fri) by misc (subscriber, #73730) [Link] (21 responses)

First, I should remind to people that Linux based systems are not the only free software unix out there. The various BSD are alive and kicking, and maybe they would be more what you want than some linux distributions. That's also the freedom of free software.

Now, for the point you make "initramfs should not customizable" is rather wrong. One, you cannot prevent people from messing with it, this is free software. Two, most people do not have to mess or do not know how to do, because most of the time ( and at least for me ), it simply work.

Now, gconf backend was just file based, editable with any editor. Maybe you speak of dconf, and even in this case, there is less complexity than with registry. Microsoft switched to a more featureful system to be able to offers stuff like audit, permissions and stuff like that. While there is maybe othes ways to achieve this, having a opaque storage and forcing to use a API was not more horrible than what a SGBD do. Most problem comes from usage of pseudo-uuid, and the constant need to tweak the internal to change something.

For dbus, i can perfectly run most program as other user. Maybe you mean "I cannot run some graphical program that requires to access to shared service and some kind of IPC for that", in which case this is correct, but I would ask how you would design the system differently. If there is the concept of session, something need to start the session, and in this case, this is dbus-launch.

Network manager is working without gui, there is cnetwork-manager thanks to dbus. And network-manager is not really mandatory, you can always do stuff by hand. Of course, that's annoying for wifi, but for a server, this work fine, setup once and that's all.

Video driver in kernel space is agan rather unavoidable. If you want the kernel to manage the graphical card ( and if you want to have a text console, it has to be done by the kernel ), then you need to have part of the driver in kernel. That's what kms is about. But maybe you would prefer to have no console, or weird lock and problem because both X and the kernel use the same memory without talking to each others.

Gnome 3 is rather controversial yes, but you may notice that there is also lots of others desktop environment and choice if it doesn't please you. I found that most of the reasons listed on gnome.org to be valid, and I can understand that despites being reported twice, gnome-shell can still be improved based on various feedbacks.

Finally, you seems to not like pulseaudio, and either you have issues with it ( and maybe that's not pulseaudio ), or maybe you think there is no use to the feature ( like saner mixer defaults ). It is hard to answer without you being more specific, but if you didn't liked having video driver in the kernel, you surely would prefer to have all the features of pulseaudio ( per application mixer, bluetooth support, streaming support, ease of use to change sound output for video card with hdmi output, music being stopped when you get a soft-phone call ), being out of the kernel ( and alsa ) as well. Maybe you don't care about the features, but I am rather happy to have my hardware working ( bluetooth ).

So if you do not want any changes and if your system worked fine, you can simply not upgrade.

The case for the /usr merge

Posted Jan 27, 2012 22:32 UTC (Fri) by gb (subscriber, #58328) [Link] (4 responses)

Oh, seem i touched topic which is very heavy, and largely off-topic for the article...

initramfs: without it, a *lot* is impossible. No heavily modular kernels. No rootfs on LVM. No rootfs on md/RAID. No rootfs on any other filesystem requiring userspace involvement to mount. No rootfs over the network (sounds silly for most machines until you have a disk failure and can revive the system, temporarily mounting everything over the network, with a one-line change). The list goes on and on. And the cost of the initramfs? These days, nearly nil.

Sure. It's not avoidable for it's purpose, i see no other way than loading two files with bootloader, it just seems pity for me that where is no simplier way to solve problem of unaccessible /. Sidenote, you CAN have / on mdraid without initrd, kernel can autodetect / array and run init from mounted lets say /dev/md0, modularity of kernel is almost not impacted too because you can put all modules on /, only modules you really need in initrd are modules to mount your /, ie fs module, hdd device module and partition style support.

But i meant a bit different thing talking about / contents in initrd. i meant that it's so less natural to edit it than normal files on / that such rescue tools location seems inappropriate.

The case for the /usr merge

Posted Jan 27, 2012 22:59 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

You don't have to load two files with the bootloader to use an initramfs. They can be automatically assembled by the kernel build process and merged into the kernel image, whereupon the bootloader need not know of it at all. Most distros don't do this purely because they ship the binary over to the user but want to assemble the initramfs on the user's machine. For those of us building our own kernels, this is not a concern. In this situation you never need to edit it, either, just as you never need to edit the binary kernel image: just change its source and rebuild the kernel.

You can only have / on md/raid with in-kernel mounting if you want to use a somewhat-horrible and somewhat-deprecated v0.90 array. v1.x arrays are not supported and may never be.

The case for the /usr merge

Posted Jan 27, 2012 23:19 UTC (Fri) by gb (subscriber, #58328) [Link] (1 responses)

Embedding mostly for embedded systems i guess, i didn't mentioned all this details just to keep post in reasonable size :)

The case for the /usr merge

Posted Jan 28, 2012 14:56 UTC (Sat) by nix (subscriber, #2304) [Link]

I find embedding really useful even for non-embedded systems, and *particularly* for heavily modular kernels in which you must load modules from the initramfs just to mount root.

The problem with a non-embedded initramfs is that it can get out of synch with the kernel it goes with, especially if it has modules in it. So you might find that you preserve your kernel for future use in case of emergency but, oops, it's useless, it has the wrong initramfs and won't boot. With an initramfs linked into the kernel image, that is completely impossible: the kernel is a single self-contained file again. And that's a very valuable property.

initramfs

Posted Jan 28, 2012 12:22 UTC (Sat) by bjartur (guest, #67801) [Link]

You should be able to mess with initramfs gzipped CPIO archives just fine.

IMO initrd/initramfs is a great thing for portable operating systems such as live CDs and installers, because there is no way they can know in advance what hardware they might need to support before they are booted. And having an emergency kernel and rootfs populated with recovery tools could easily come in handy.

On regular, fairly static systems, where you don't replace your MBR with a GPT or a BSD disklabel after every other reboot, you can compile the stuff you always need into the kernel image and load additional modules lazily. But if disks and video cards vary from boot to boot, initramfs might actually be considered an optimization, allowing you to disable module unloading and use userspace tools to aid boot.

But none of this is why mainstream distros use initramfs. The actual reason is that they insist on distributing kernel binaries, but are OK with users assembling initramfs images. And who can blame them, compiling kernels takes CPU time.

The case for the /usr merge

Posted Jan 27, 2012 23:08 UTC (Fri) by gb (subscriber, #58328) [Link]

>pulseaudio: Finally, you seems to not like pulseaudio, and either you have issues with it ( and maybe that's not pulseaudio ), or maybe you think there is no use to the feature ( like saner mixer defaults ). It is hard to answer without you being more specific, but if you didn't liked having video driver in the kernel, you surely would prefer to have all the features of pulseaudio ( per application mixer, bluetooth support, streaming support, ease of use to change sound output for video card with hdmi output, music being stopped when you get a soft-phone call ), being out of the kernel ( and alsa ) as well. Maybe you don't care about the features, but I am rather happy to have my hardware working ( bluetooth ).

No, exactly opposite, i enjoy pulseaudio. Especially for it's original purpose - transferring sound over the network. It's best tool available for this task, and i am using it for to centralize my home sound.

Ah, dynamic changing of output card. You right, anyway some entity needed to implement this kind of functionality. Thanks for description, didn't thought about it.

The case for the /usr merge

Posted Jan 27, 2012 23:18 UTC (Fri) by gb (subscriber, #58328) [Link] (5 responses)

> Video driver in kernel space is again rather unavoidable. If you want the kernel to manage the graphical card ( and if you want to have a text console, it has to be done by the kernel ), then you need to have part of the driver in kernel. That's what kms is about. But maybe you would prefer to have no console, or weird lock and problem because both X and the kernel use the same memory without talking to each others.

Right again, but i can recall that early Linux feature: hey, our video processing is in userspace, so you have much less chances of lockup guys! I slowly fades out. I want to add more about kernel in general, former Torvalds told 'move as much as possible out to userspace!' now it seem for me that everything moves in opposite direction and kernel is bigger and bigger. Yes, it's unavoidable again. But pity that some ideals lost.

The case for the /usr merge

Posted Jan 27, 2012 23:21 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

the thing is that with video, more was moved out than was possible while still keeping the system reliable.

note that most of the driver is still in userspace, it's only a tiny portion that's been moved in to the kernel, just enough to be able to track (and set) the video mode.

to butcher a quote
things should be as simple as possible, but no simpler

this is just a small correction

The case for the /usr merge

Posted Jan 28, 2012 14:58 UTC (Sat) by nix (subscriber, #2304) [Link]

Memory management is also in the kernel (again, because it has to be, you can't share that sort of thing between multiple instances of Mesa, and you have multiple instances of Mesa all the time because the apps often have their own instances rather than going through the X server, for performance reasons). The command stream checker also obviously has to be in the kernel, to protect against a malicious userspace.

The case for the /usr merge

Posted Jan 28, 2012 3:43 UTC (Sat) by HelloWorld (guest, #56129) [Link]

> I want to add more about kernel in general, former Torvalds told 'move as much as possible out to userspace!'
Torvalds never said anything remotely like that.

The case for the /usr merge

Posted Jan 28, 2012 13:56 UTC (Sat) by farnz (subscriber, #17727) [Link]

And with KMS, the architecture is still that most of the video work is done in userspace. The kernel manages memory (both graphics card memory, if any, and shared system memory), dispatches command streams from userspace to the GPU in a safe fashion (stopping apps disrupting each other or accessing each other's memory space), handles interrupts, does modesetting, and resets the GPU when userspace apps crash it.

Everything else (all the complex command stream creation) is done in userspace still.

The case for the /usr merge

Posted Jan 29, 2012 21:45 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"I want to add more about kernel in general, former Torvalds told 'move as much as possible out to userspace!'"

Linus has never taken that position. All other things being equal, he favors that things stay in user space. But if there is good argument for moving it into the kernel, he's always been OK with that. In fact, he has been very explicit on the point that the goal should not be to keep the kernel small, but to make the right decisions as to what goes in and what does not.

The GGI guys wanted to move the whole graphics driver nightmare into the kernel. Linus put his foot down on that idea. But DRM, memory management, and kernel mode-setting were the peices of Linux graphics which were always fundamentally broken under the old "all graphics in userspace" model. Do you know that switching from X to a text console and back has never been guaranteed not to hard lock your machine? Surely, if you've been around long enough, you've encountered such console crashes. And when that happened, it was likely not a bug, per se. It was the result of a fatally flawed design. Only with the inclusion of KMS is your distro's graphics system not fatally flawed at a fundamental level.

Regarding your concerns about the size of the kernel, what does it matter? The vast majority of kernel code expansion is in additional drivers. And those are all modules. Modules whose code-bases are orthogonal to each other.

In comparison, DRM, KMS, and GEM are not particularly large. I'd never want to go back to the bad old days of our former "Green Acres" graphics architecture.

The case for the /usr merge

Posted Jan 27, 2012 23:59 UTC (Fri) by gb (subscriber, #58328) [Link] (8 responses)

Network manager and dbus guys: One of aspects of this tools that they keep integrating into my favorite applications. In 2005, my mail application didn't need a 'X session' and export $(dbus-launch) and somehow worked in ssh -X session. It also didn't need to know about network manager connection state which magically wrong too often.

dbus: My ideal were fine systems without "system wide message bus" and related program interdepedency (now all programs are on single bus which one need other? who knows... you mailer doesn't work? check network-manager!). I am not a big specialist in it, but it seems that d-bus has very limited applicability (low-bandwidth transfers), but seem used as panacea everywhere. Dbus services seem special harm. I need to learn it othervise it would be security concern (something starts somewhere at random time - is it really so nice?). As i see it, system should have single point for starting services, not separate init.d and some black d-box.

Of course 'not upgrading' is never an option because i want and must have new features of rest of system - support for new hardware, new editors, new secutiry updates, new architectures, new videos, new internet browsers. Once i saw in openmoko list hardcore guy who really not upgrading, and using some VAX system with original software, his problems with ftp were nice example of 'non-upgrade' path.

The case for the /usr merge

Posted Jan 28, 2012 0:34 UTC (Sat) by Kit (guest, #55925) [Link] (6 responses)

Applications adding stupid restrictions/requirements is the application's fault. Applications have been doing stupid things based on what they ASSUME is the state of the network since long before Network Manager (and really, a NM like service is the only reasonable solution for any mobile system).

>As i see it, system should have single point for starting services,
>not separate init.d and some black d-box.

So now you're wanting systemd? The old init systems are most certainly not capable of that!

>Dbus services seem special harm. I need to learn it othervise it would
>be security concern (something starts somewhere at random time - is
>it really so nice?).
You can fairly easily figure out all the things that could possibly be started on demand... so how is that different than having them _always_ running? Of course, you'd still need to connect to them via an IPC system like dbus...

>I am not a big specialist in it, but it seems that d-bus has very
>limited applicability (low-bandwidth transfers), but seem used as
>panacea everywhere.
IPC has lots of uses in a desktop environment. Everything from an applet on your panel that controls your music player to administrative tools that don't expose root access to your whole X session (if you launch a graphical app as root on your regular X session, you better trust every program running as your user with root privileges, because they could have them if they wanted!). There are tools (including graphical ones) that let you explore the dbus user bus and system bus, to see what's accessible. You might be surprised at the large amount of functionality easily accessible.

The case for the /usr merge

Posted Jan 29, 2012 11:44 UTC (Sun) by k8to (guest, #15413) [Link] (5 responses)

Like it or not, the common programming patterns and libraries around dbus are pretty fragile. It's very common for dbus programs to fail to operate correctly if dbus isn't already running when they start up. It's common for them to fail to establish communication with launched subprocesses.

Essentially, the filesystem, pipes, sockets are pretty safe to assume to be always present, and you can develop against them without fear (though please handle the errors). With dbus, you have to handle a number of additional cases, and it seems more difficult than real programmers are going to do in reality.

For that problem alone, I question the value of having dbus at all.

Then there are the security concerns.. but that's the topic for another day.

The case for the /usr merge

Posted Jan 29, 2012 21:48 UTC (Sun) by paulj (subscriber, #341) [Link] (4 responses)

A good example of fragile DBus programming patterns is systemd. Guess what happens if early boot goes wrong (e.g. cryptsetup fails on some not-very-important filesystem) and you get dumped to a rescue shell and you try use systemctl? A nice "Can't connect to message-bus" type of error.

Why on earth is systemctl not talking *directly* to systemd??

The case for the /usr merge

Posted Jan 30, 2012 0:11 UTC (Mon) by mezcalero (subscriber, #45103) [Link] (3 responses)

This is simply not true. systemd speaks the D-Bus protocol without relying on the D-Bus daemon. One of the nice things about systemd is that is is fully introspectable even if the only processes running are systemd itself and a bash. For example, boot into emergency mode by passing "emergency" on the kernel cmdline, and you'll see that "systemctl" works just fine even though no processes between PID 1 and bash are around.

Don't spread obvious falsehoods, please!

The case for the /usr merge

Posted Jan 30, 2012 1:35 UTC (Mon) by slashdot (guest, #22014) [Link]

paulj seemed to speak from experience though, so maybe (some past version of?) systemctl first tries to talk via dbus, but doesn't always properly fallback to direct communication when that fails?

The case for the /usr merge

Posted Jan 30, 2012 12:20 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Systemctl gives DBus connection errors in certain situations. And, other than to those quite familiar with systemd, it's NOT an obvious falsehood. I know you get a lot of uncalled-for personal crap from snipers, but does it help for you to respond to other people in a bordering-on-insulting fashion?

Here's what I was going by:

https://picasaweb.google.com/114169232705420738100/System...

I'm not sure, but there's probably some combination of a couple of silly little bugs here:

a) If emergency mode had root mounted RO (I'm not sure if that happened at shutdown or at beginning of emergency mode): Going to emergency mode with root RO when some ancillary fs has failed to mount (I don't remember what old initscripts did, but I think they first mounted / RW before mounting rest?)

b) Shutdown having become fragile in the face of a RO /. I've had old init + initscripts in a similar situation, & services would fail to stop, but init would eventually reboot anyway. A fragile reboot can be a huge problem if you're remote and have no physical access to the power/reset buttons.

c) A slightly misleading or confusing error message from systemctl.

d) Unrelated to my original post, but also evident in those photos: Parallel jobs stomp over the tty with output. Particularly confusing if you've missed the fact you're supposed to type in a passphrase. (This possibly isn't a little bug, in terms of fixing it).

Bugs, which will be fixed no doubt, I'm sure. Also, just because a messenger doesn't have a perfectly set-out message, doesn't mean the messenger should then be shot.

The case for the /usr merge

Posted Jan 30, 2012 16:55 UTC (Mon) by michich (subscriber, #17902) [Link]

If you can find a sequence of steps to reproduce the problem reliably, please file a bug in Bugzilla.

But... the second screenshot shows 2.6.34.7-66.fc13. Are you really running Fedora 16 on a kernel from Fedora 13?

The case for the /usr merge

Posted Jan 29, 2012 21:24 UTC (Sun) by speedster1 (guest, #8143) [Link]

> Of course 'not upgrading' is never an option because i want and must have new features of rest of system - support for new hardware, new editors, new secutiry updates, new architectures, new videos, new internet browsers.

It sounds like you are not using one of the Linux distributions best suited to your needs. Distributions such as debian and gentoo are well suited for an experienced user, such as yourself, who does not want to trade extra integration and automation for additional complexity. With one of those more flexible distros, it is easy to set up a useful desktop system without gconf, network manager or dbus, and without getting stuck on old versions of software. At this moment, I happen to be doing a gentoo install without any of those packages.

Ah, yes, well...

Posted Jan 27, 2012 18:58 UTC (Fri) by jd (guest, #26381) [Link] (2 responses)

Most of the good points have been made, so here are some bad points that can be added on:

  1. Since you're not continually writing to the recovery partition, you want a format that can always be accessed and possesses a high read speed even if that sacrifices write speed and write robustness. You want a reasonably wide range of recovery tools, statically linked so that they're independent of any other change in the system, so you don't want filesystems with overheads. This is a highly specialized set of requirements that applies to no other part of the system. It should be isolated as far as is humanly possible. Files containing filesystems are only a replacement if all the criteria above and mentioned by others as necessary can be met.
  2. Optimal performance will always mean having a large set of specialized systems, not a single compromise-driven one-size-fits-all system.
  3. We need a broader and maybe deeper directory tree, not a shallow, simplified one. Packing too many files into one directory risks name collisions and invites security problems (it's easier to remember to lock down one directory than it is to remember to lock down every file that needs it). It also complicates the case where you need multiple versions of things.
  4. If any directory should go, I'd eliminate /usr as a physical tree and make it a virtual one. Each user and each process would then see /usr/* according to what they have rights to see. This solves the need of commercial software, avoids the collision issue, maintains LSB as far as the users are concerned, unclutters what is visible and allows even finer granularity on your choice of filesystems as you can have "/usr" be on several according to the needs of the software.

Yes, there will be complaints about this approach, but I did tell you these were bad points so don't blame me. However, I'm twisted so I like it.

Ah, yes, well...

Posted Jan 27, 2012 20:30 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>If any directory should go, I'd eliminate /usr as a physical tree and make it a virtual one. Each user and each process would then see /usr/* according to what they have rights to see.

That's actually what Nixos ( http://nixos.org/ ) is doing.

Ah, yes, well...

Posted Jan 28, 2012 3:17 UTC (Sat) by pabs (subscriber, #43278) [Link]

As is GoboLinux:

http://www.gobolinux.org/

The case for the /usr merge

Posted Jan 27, 2012 19:31 UTC (Fri) by pr1268 (guest, #24648) [Link] (3 responses)

From the article:

> 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.

Mulehockey! That smacks of merely wishing to copy Solaris. If the FreeDesktop devs wish to merge /usr then do so on technical merits, NOT because they want Linux to be "just like Solaris".

Copying someone else sounds like what that OS company from Redmond has done for the past 28 years. I thought Linux was better than that.

The case for the /usr merge

Posted Jan 27, 2012 19:45 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Considering that Linux ( and hundreds of programs) itself is a reimplementation of Unix, you had no reason to believe that. Good ideas can be and should be copied from wherever possible including Solaris, Mac OS X and (gasp!) Windows. Open source thrives on it.

The case for the /usr merge

Posted Jan 28, 2012 1:09 UTC (Sat) by leoc (guest, #39773) [Link]

Open source thrives on it.

So does closed source. Microsoft and Apple also copy ideas (and literally code too) from open source.

The case for the /usr merge

Posted Jan 31, 2012 15:07 UTC (Tue) by vonbrand (guest, #4458) [Link]

Mulehockey! That smacks of merely wishing to copy Solaris. If the FreeDesktop devs wish to merge /usr then do so on technical merits, NOT because they want Linux to be "just like Solaris".

Have you looked at this reason only, or have you considered all the ones forwarded for this? AFAICS, it is mentioned more in the line of "It is also nice that...", not as the reason behind the move.

Copying someone else sounds like what that OS company from Redmond has done for the past 28 years. I thought Linux was better than that.

You give MSFT too little credit. They did invent/create some cool, new stuff (the idea of an interoperable office suite comes to mind) and are in a large measure responsible for the standardization (as it stands) of PC hardware. Sure, they made gargantuan blunders on the way too, and now can't for the life of them get rid of the fallout. That they didn't play nice with others isn't exactly their behaviour alone, BTW.

Besides, the fabled GNU project was to be a drop-in replacement for Unix (even though RMS didn't like that system at all), so all Linux distributions are just "copying somebody else." Get over it, ideas worth copying will get copied; one just hopes not too much crap comes along for the ride.

The case for the /usr merge

Posted Jan 27, 2012 23:36 UTC (Fri) by slashdot (guest, #22014) [Link] (2 responses)

Wow, finally!

This is one of the things that one immediately notices as being idiotic when he starts learning about Unix.

The case for the /usr merge

Posted Jan 30, 2012 12:18 UTC (Mon) by Seegras (guest, #20463) [Link] (1 responses)

Idiotic?

You didn't think about NFS, read-only /usr and so on. Granted, nobody uses these anymore, BUT that is the reason the setup is like this.

The case for the /usr merge

Posted Feb 2, 2012 14:28 UTC (Thu) by rleigh (guest, #14622) [Link]

These /were/ reasons for the existence of /usr. But nowadays we can mount / read-only (including /usr), and we can also NFS mount / (including /usr), making the need for a separate /usr mount redundant.

Regards,
Roger

The case for the /usr merge

Posted Jan 28, 2012 8:43 UTC (Sat) by linusw (subscriber, #40300) [Link] (1 responses)

IIRC ages ago in system V, some vendors (I know for sure the Swedish spin-off DIAB DNIX) would populate /bin with a shell and tools that were not only statically linked, but could also run *without the kernel* if need be, i.e. with compiled-in file system support etc. This is totally alien these days...

The case for the /usr merge

Posted Feb 6, 2012 7:24 UTC (Mon) by k8to (guest, #15413) [Link]

I'm curious about this.

I can see how you could go out and read the filesystem yourself, especially if there was only one filesystem. But I have no idea how they would get started. Was there a kernel-less shell? Was there process management? How did they get access to the storage medium? This sounds so bizarre.

sbin vs. bin and tab completion

Posted Jan 28, 2012 12:20 UTC (Sat) by gbrun (guest, #82611) [Link] (3 responses)

Not all systems out there make use of sudo.

Actually, only private end-user desktop PCs are commonly configured like that where administrator and end-user are the very same person.

In those contexts the distinction between bin and sbin is indeed superfluous.

However, in many other installations the roles of end-users and administrator are fundamentally different and will also be impersonated by different people.

In those cases, the distinction between bin and sbin limits "namespace pollution" of tab-completion for normal users, i. e. tab completion will not suggest executables which cannot be executed by non-privileged users anyway.

Therefore, whether or not /bin and /usr/bin gets merged, bin and sbin should be left separate.

sbin vs. bin and tab completion

Posted Jan 28, 2012 13:17 UTC (Sat) by slashdot (guest, #22014) [Link]

Except that, of course, almost all programs can still provide some functionality when run by unprivileged users (or at least they would in a well-designed system).

sbin vs. bin and tab completion

Posted Jan 29, 2012 22:13 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"In those cases, the distinction between bin and sbin limits "namespace pollution" of tab-completion for normal users"

I'll query my normal business desktop users about that.

MOTD: Users. How do you feel about the pressing issue of tab-completion namespace polution on your Gnome desktops? Would you condider it to be more, less, or of about the same urgency as the world economy, the unemployment rate, and the predominent color of countryside bike sheds?

sbin vs. bin and tab completion

Posted Jan 31, 2012 12:57 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

> In those contexts the distinction between bin and sbin is indeed superfluous.
It's not just in single-user systems where the bin/sbin split makes no sense. A lot of sbin programs provide useful functionality to non-root users. My favorite example: On Debian it's /sbin/ifconfig, but as a normal user I like to run ifconfig to see IP, tx information and so on. Why must I type the full path? (Yes, sure, I could use 'ip addr' for that. I am a creature of habit.)

> However, in many other installations the roles of end-users and administrator are fundamentally different and will also be impersonated by different people.
In all cases that I know of tools which you need to be root to be useful also safely refuse to run if executed by a non-root user, so there seems little *need* to segregate them.

> In those cases, the distinction between bin and sbin limits "namespace pollution" of tab-completion for normal users, i. e. tab completion will not suggest executables which cannot be executed by non-privileged users anyway.

There are so many binaries in /usr/bin these days that I don't think a few more will make much difference. "Cleaner tab completion for some users" seems like such a tiny gain.

Space requirements for initramfs

Posted Jan 28, 2012 12:39 UTC (Sat) by gbrun (guest, #82611) [Link] (7 responses)

While it is certainly true that the "big" desktop distros are all based on initramfs/initrd "preboot" environments, this does not mean it is an equally well-suited solution for all Linux installations.

Obviously, in situations where the initramfs approach works, the traditional roles of /bin, /sbin and /lib as a "rescue system" are no longer required.

On the other hand, the initramfs approach requires a rather large amount of main memory in order to store the extracted contents of the preboot environment.

This is certainly not a problem for the current generation of hardware where most boxes have at least 1 gig of RAM.

But there are still a lot of smaller and more restricted older systems out there with as little as 16 megs of RAM!

Those systems can still run a (somewhat stripped-down) Linux installation (typically 2.4 or 2.5 based), but they certainly cannot afford to extract and run an initramfs.

Such systems *depend* on the traditional /bin /sbin /lib layout for a rescue system, especially in cases where alternative boot devices are not available.

Merging /usr/bin and /bin is therefore certainly a valid choice for bloated desktop distros, but I strongly advise against general adoption of this scheme in a forthcoming update of the FHS.

What *could* be adopted, though, is the *optional* of replacement /bin, /sbin and /lib with symlinks.

Space requirements for initramfs

Posted Jan 28, 2012 13:22 UTC (Sat) by slashdot (guest, #22014) [Link]

All such embedded platforms would of course build any necessary driver to mount all filesystems statically in the kernel, so this is a moot point.

Space requirements for initramfs

Posted Jan 28, 2012 14:19 UTC (Sat) by HelloWorld (guest, #56129) [Link] (2 responses)

Why would you ever need a "rescue system" on an embedded system? There's typically not much to rescue there, and things can be fixed by simply flashing a new firmware.

Space requirements for initramfs

Posted Jan 28, 2012 14:35 UTC (Sat) by bluss (guest, #47454) [Link] (1 responses)

Maybe it's an exploration robot on a different planet?

Space requirements for initramfs

Posted Jan 28, 2012 15:53 UTC (Sat) by Eckhart (guest, #74500) [Link]

> Maybe it's an exploration robot on a different planet?

Bonus points for picking the most unlikely scenario?

Space requirements for initramfs

Posted Jan 28, 2012 14:54 UTC (Sat) by Los__D (guest, #15263) [Link]

In what way does desktop distributions and services relate to 16MB devices?

If you are using a small embedded device, you would of course use a distribution for embedded purposes, or roll it yourself, making all of this moot.

Space requirements for initramfs

Posted Jan 29, 2012 0:40 UTC (Sun) by dlang (guest, #313) [Link]

don't forget virtualized systems, the main system may have lots of ram, but how many virtual machines do you want to run on that hardware?

Space requirements for initramfs

Posted Jan 30, 2012 0:20 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

On embedded machines it's usually not interesting to split off /usr anyway. And systems without /usr split off can boot without initrd just fine.

Note that the same people who are behind the /usr merge have actually been working on making Linux work with a read-only / out-of-the-box, for use in embedded and stateless systems (We are mostly there, but not entirely). We have the embedded use of Linux and systemd firmly on our map, but initrd-less systems with /usr split off are definitely of little usefulness in our eyes, since they are useless for embedded and pointless on bigger setups.

File name encoding issues in /boot

Posted Jan 30, 2012 19:09 UTC (Mon) by gbrun (guest, #82611) [Link] (2 responses)

Another point why it might be a good idea to put /boot and the main system on different partitions.

GRUB2 and other boot loaders which "understand" file systems must make assumptions about the character set encoding in file systems which do not store file names in UTF8/UNICODE, such as AFFS, SFS or HFS.

OK, I admit that I see little purpose to assign non-ASCII names to files relevant to the boot loader.

Nevertheless, separating /boot from / allows to use an ASCII/UNICODE-friendly encoding in /boot which Bootloaders will support in any case, and to use a filesystem with the weirdest possible LC_CTYPE encoding on / if one desires.

File name encoding issues in /boot

Posted Jan 31, 2012 10:34 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (1 responses)

OK, I admit that I see little purpose to assign non-ASCII names to files relevant to the boot loader.

Being able to label the files in one's native language seems perfectly reasonable to me, and shouldn't be restricted to people whose native language can be written acceptably in ASCII :)

File name encoding issues in /boot

Posted Jan 31, 2012 12:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, my native language is not written using ASCII and I can't say I ever wanted to name kernel images in my native language.

Now, menu entries in GRUB are another matter but GRUB2 supports non-ASCII for menus just fine.

The case for the /usr merge

Posted Feb 28, 2012 7:36 UTC (Tue) by stock (guest, #5849) [Link] (1 responses)

Lennart Poettering listened to his pulse audio triggered mind
and uttered :

"Solaris implemented the core part of the /usr merge 15 years ago already, and completed it with the introduction of Solaris 11. Solaris has /bin and /sbin only as symlinks in the root file system, the same way as you will have after the /usr merge: Transitioning From Oracle Solaris 10 to Oracle Solaris 11 - User Environment Feature Changes. "

I can remember the times when the old timer BSD dudes were raving mad
as (s)hell bombs when SUN OS got trashed into something like Solaris.
And they got good arguments for that. Maybe consult first with the
chiefs of OpenBSD and FreeBSD why your suggestion would be a brilliant
move, before your trigger us into this concocted move and shot in
the arm for that poorly designed project called ("Open")Solaris.

Many of us got our freedom back by going to Linux, thereby leaving
Windows, Solaris, [Insert your oldie OS here]. Don't force us into a
merger which will move Linux also onto this garbage dump of discarded
oldie Operating Systems.

Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net

The case for the /usr merge

Posted Feb 28, 2012 9:05 UTC (Tue) by ovitters (guest, #27950) [Link]

Bad troll, no cookie.

The case for the /usr merge

Posted Feb 28, 2012 8:06 UTC (Tue) by stock (guest, #5849) [Link]

Fedora is typically the testcase environment where RedHat makes its
well-tested pick of nuggets. If Fedora 17 is going to a /usr merge,
then RedHat is going to such a merge as well. You mentioned in your
article that Solaris with version 11 now has also completed this
Merger. When speaking of Solaris we are not speaking anymore of Sun
Microsystems Solaris, but i understand it is today called Oracle
Solaris.

It wouldn't surprise me if Larry Ellison would be up into his eyeballs
in taking over RedHat as well.

Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds