Fedora Wants To Simplify the Linux Filesystem

You bad Scott. No beer for you.

This is a landmark week, I agree with Grishnakh too.

the separation of / and /usr is going to be harder and harder to achieve and is no longer serving its purpose. more and more stuff is being added to / making it less and less useful to put it on its own device. the stuff that you really need to boot and fix things could almost fit into an initrd. one problem with separating /usr is that it doesn't really solve the problem. you also need to separate /var, /tmp, /srv, /home, /opt and /usr/local, and that's just to many partitions for a desktop system unless you play around with links (i usually put /srv, /home, /opt and /usr/local into /local and /tmp on /var/tmp/root).

with all that it becomes easier to just separate /boot and be done with it. my /boot is nowadays just as large as my / partitions used to be.

as for history, actually the separation of /usr came from the original unix. the operating system was in /. /usr was where everyone could share their custom utilities. (hey, i got this little tool called more, which lets you look at a file one screenful at a time instead of letting it scroll past you at the speed of your terminal...) that's why it's called /usr.

greetings, eMBee.

The 68020-based 'Plexus' UNIX-alike system I dealt with back in '91 treated /usr the way we treat /home nowadays: ~crb3 was /usr/crb3. So, the roots of our current tree are shallow in places.

That said, I rather like the current system, with a stabilizing FHS that changes only in a slow and methodical manner, and a natural tiering which fits system priority. It makes sense to me to have the vitals in one pocket, /bin, where they can be tripwire-checked on the hour if you're paranoid. If these people don't, nothing says they can't stuff /usr/bin with symlinks to everything in /bin, then they can have their "simplified" scripts work and we can have ours still work.

There seems to be some kind of mind-virus going around lately of reduction-to-absurdity and make-work for the sake of discovering limits by surpassing them. Is this some kind of Jobs-creation tactic for dealing with the recession? It's a global thing, so it can't be drugs or Death Eaters.

It's not how it's done in Windows -- there must be something wrong with it!

@Grishnakh, did you or others agreeing with you ever read the feature page at all? It doesn't seem so.

https://fedoraproject.org/wiki/Features/UsrMove

Hint: symlinks

Im not sure whether its a good idea or bad idea, but niether am i sure that a mass of symlinks is a good idea either just look at Windows 7 structure more links than you can shake a stick at making it confusing at first glance.

Im on the fence on this one.

Lately, Fedora and Ubuntu seem to be working very hard at making debian and Slackware look good.

Symlinks... symlinks are your friend...

@JaseP -

they're also a PITA.

I propose a movement to simplify knives.

We can start by getting rid of the point, and the complex curve associated with that -- after all the edge is the important part that does the cutting. That would leave use with a nice, straight edge -- much simpler. While we're at it let's get rid of the handle too, and makes manufacturing much more complicated than it needs to be (if that's too radical in one jump, we could start by just disposing of the crosspiece, as that's the worst offender against simple, straight-forward design).

@BernardSwiss

If the sharp edge is what is important, why not get rid of everything else? Even the blade.

All you need is the edge, so remove the curve, the handle and all of the blade that is not the edge.

A very simple design indeed.

you mean stuff like this?

http://en.wikipedia.org/wiki/Wire_saw

greetings, eMBee.

I'm with Koriel on this one. I see what they're getting at with having all that stuff in /usr and allowing it to be read-only and shared across multiple machines (with /var, /etc, and /run (which I assume has a /run/tmp directory)) not shared and machine-specific, but having a giant mess of symlinks back to /bin, /sbin, and /lib sounds like a bad idea. Symlinks have their place, and this doesn't seem like it.

For instance, what if someone does a package update on one of these setup where you're sharing /usr across a bunch of nearly-identical machines, and this changes or deletes a file in /usr/bin? Suddenly you've got a dead symlink in /bin in all those machines. Symlinks are normally maintained along with the files they're pointing to. So, for instance, with shared libraries, you'll have libfoo.so.1.0.0.1.2, and then a symlink to that from libfoo.so.1, and another symlink to that from libfoo.so. But that library and its symlinks are all in the same directory together, so when you do a package update that affects them, they all get updated at once. You don't have to worry about them being on different partitions or volumes, one of those volumes being somewhere else on the network or read-only, etc.

Quoting: but having a giant mess of symlinks back to /bin, /sbin, and /lib sounds like a bad idea. Symlinks have their place, and this doesn't seem like it.

Am I missing something? I believe the symbolic links are for backward compatibility and for transitional period. Eventually, they might disappear.

That touches on a good point, Fettoosh. What will be the determining factor for their final removal?

Lack of new Fedora bug reports?

Other distros following suit?

Or maybe they'll stay in forever? Symlinks don't use much space.

Inquiring minds want to know.

(Apropos: my virtual keyboard thought I meant "disastrous" for "distros".)

@number6x @mbaehrlxer

That did occur to me, but I didn't think it fair to carry the analogy quite that far.

The problems with the current system are plain enough, but I strongly suspect that the proposed solution would be merely replacing one set of problems with a different set.

And I also suspect that overall the current arrangement would prove more satisfactory over-all, but that it would (for human rather than technical reasons) be far more difficult to return to a more structured arrangement again.



(Disclaimer: I'm a "hobbyist", not a "coder", so my opinion may be worth about as much as you paid for it. But I shall be very interested in what the genuine *nix grey-beard gurus have to say on the matter.)

Quoting: What will be the determining factor for their final removal?

I guess the fundamental question becomes, is there a valid enough reason to remove them? I don't see one and I don't see any harm in keeping them. So, my choice would be

Or maybe they'll stay in forever? Symlinks don't use much space.

You guys should check out the FreeBSD system. Core materials under / but everything that has been customized for the system under /usr/local.

So I can make a partition /, one one for /usr/home one for /usr/local and one for /usr/ports. This gives me the ability to move a system by simply copying /, move a system with all of my apps by copying / and /usr/local. All my data is in /usr/home so that's recoverable. And if I have customized development I can keep /usr/ports out of the process.

I can tell you that there Linux needs a better system of seperating it's core utils and key chain from it's installed apps. It would make administrator much simpler.

Been using Gobolinux for 3-4 years now and there things have been taken all the way. The legacy tree is maintained via symlinks and the various binaries, libs and such are in a separate dir tree sorted by package name and version.

Funny thing is that this results in a very robust system. Robust in that each installed version is in its own subdir, allowing a botched install to rolled back. I have even rolled back core package updates using a livecd and some effort.

Sadly the distro is growing stale because the community is small and various compilation scripts needs to be patched to play nice with the layout (in the past Gnome have been a struggle, and KDE4 turned out to be a pain because of the switch to cmake).

the gobolinux devs should take a look at the conary package manager and build tools.

the package recipes are python classes inheriting a parent class where all the common behaviour is defined. with that it would be easy to define a class that sets different prefix and destdir etc values for each package, and creates the necessary symlinks. there shouldn't be any patching necessary just to stuff each package into a separate subdir.

greetings, eMBee.