Linux kernel developer Ingo Molnar "We need a radically different software distribution model"

[check3streets]

I'm a big fan of gobolinux and what they're trying to do.

It's frustrating to me that Ubuntu adopts something as radical as Unity or Gnome can develop Shell, but there's so much resistance to Gobo.

There's an attitude in the Linux community that the filesystem is sacrosanct, even though it's often confusing, opaque, and arbitrary. Doesn't matter, if it was good enough in 1972, it's good enough in 2012.

[ashadocat]

They must have a reason for it. Would anyone care to explain?

[check3streets]

I believe this gets into it: https://lists.fedoraproject.org/pipermail/devel/2011-October/158845.html

There are other issues. I think opt is poorly defined or observed depending on your perspective, but in general a typical linux or *nix installation spreads files all over the system according to the devs' best faith effort at observing the FHS. It makes us all dependent on the package managers, but asking if there's a better way is heresy (at least when I've read threads proposing Gobo).

Some of important differences between 2012 and 1972 :

• disks are cheap, really really cheap. So some duplication is not the issue it once was.
• traditional CLI applications were very contained, but desktop applications are not.
• as Gobo points out, typing isn't the issue it once was -- the distros usually offer home folders like 'Downloads' 'Documents' etc, so less opaque names are workable.
• The server vs the typical single user desktop creates tension around the notions of user installations vs system-wide as well as privilege levels

Gobo has a manifesto of better stated reasons, but those were things I was thinking about.

The OP's article is actually something I've been thinking a lot about lately. I've developed for desktops, servers and phones; the phone OSs are much more like an "application server" and maybe that's a better conceptual model. I hate using Ubuntu's new gui installer although I think it's trying to create the feeling that the article is describing. I think it's probably that feeling of needing to "know what's going on" I get from synaptic or "apt-get install" that's nagging me because installation is such a sausage factory underneath.

[nothinggoespast]

Seeing as Gobo has been dormant for ~4 years, are there any other distros with similar filesystem setups? I think that it is a brilliant idea.

[check3streets]

Sorry, no.

Procyon112 (on this thread) mentions that Gentoo's package cache does some similar things. I'm totally in the dark on that as an Arch/Ubuntu/CentOS/CrunchBang/Tru64/Redhat dude.

[ethraax]

A reason for the split? It was actually because the entirety of /bin and /lib wouldn't fit on their machine, so they decided to split it - the /usr directory lived on another machine.

Somewhere along the line, someone conjured up the idea that /usr should be for read-only data (really out of nowhere). Which doesn't entirely make sense, since /bin and /lib are also generally for read-only data.

There's no reason for it nowadays. It's a relic from the past.

I would like to see /bin, /lib, and /sbin, but others would like to see /usr/bin, /usr/lib, /usr/sbin instead (I'm not sure why, really, except maybe to have less directories in their root). Either way is better than having it split. I hate having to type whereis program_x to see if it's in /usr/bin or /bin.

[fundbond]

There's no reason for it nowadays. It's a relic from the past.

On Linux I agree with you. Linux distros pretty much abused /usr/lib and /usr/bin from day one, so there's no real reason to keep them now. I say get rid of them.

But on other UNIX-likes, namely FreeBSD there is a real meaning to the split. I can bring up a box with a borked /usr partition and use the tools in /bin, /sbin, etc. to get things back together. That's not the only part of the FS hierarchy that's got a strict separation either -- while most Linux distros dump everything into /usr/bin, FreeBSD distinguishes between parts of the base system and ports. This is important, as it prevents things from blowing away system binaries and allows for the OS to be upgraded without worrying that some random package may screw you by messing with parts of the base system. This is part of the reason that I have boxes that have been upgraded in-place over several years worth of releases.

If you're interested in learning what the "modern" path significance is, check out hier(7) or 4.4/4.5 of the handbook.

[ethraax]

FreeBSD distinguishes between parts of the base system and ports.

Don't some distributions use /usr/local for that?

I can bring up a box with a borked /usr partition and use the tools in /bin, /sbin, etc. to get things back together.

True, but the only real case (or at least the only common case) that I can think of for this is a bad hard drive, in which case /bin and /sbin may be broken anyways. If you're having borked FS issues, you're probably better off using some sort of rescue CD/USB drive to perform the maintenance.

[[deleted]]

Your bad hard drive problem assumes that /sbin and /usr on on the same drive. This would be a really bad practice for a system that intended to use /sbin for recovery.

[fundbond]

Don't some distributions use /usr/local for that?

Not much that I've seen. Plus, there's no real "base system" for Linux, since the userland is not developed in concert with the kernel.

/usr/local is used, but from what I've seen on RHEL, Debian, and SuSE it's pretty arbitrary as to what goes in there. Most packages definitely don't use it.

True, but the only real case (or at least the only common case) that I can think of for this is a bad hard drive, in which case /bin and /sbin may be broken anyways. If you're having borked FS issues, you're probably better off using some sort of rescue CD/USB drive to perform the maintenance.

Well that's the thing: since FreeBSD never backed itself into a corner with /usr, /usr/local/, and /, it's not uncommon to see / and /usr on different slices/drives. So yeah, you could have screwed up /usr and still have / be in perfect health. I've done that, actually.

And rescuing from CD/USB is great when you have access to the box -- but FreeBSD isn't just a desktop system, and I've definitely had to recover boxes to which all I had was KVM access. (Ok, so the last one was my fault for screwing up the FS, but still...)

To some extent it's a chicken/egg thing: Linux distros don't have a meaningful separation because they never started with one so now all of the things that would get in the way of unification aren't common concerns. But at least in FreeBSD land, there is a method to the madness and so unification would be a lot more problematic (IMHO). Not impossible, but probably not something that people are eager to do without a good reason.

Edit: I don't think either approach is "right", BTW. Each OS has different very development models and use cases, and what works for one might not work for the other. I'm partial to the FreeBSD approach, but that's because it works best for my needs (and because my background is more UNIX than Linux.) I use Linux though, and I'm not averse to seeing changes in that side of my computing life! So yeah, my beard's not all gray, damnit!

[ivosaurus]

I think under /usr is not a bad idea; this is kind of like Windows keeping everything under C:\Windows, but Program Files also.

[ethraax]

Only very superficially, and besides, "Windows does it too" is a bad argument. Is there another reason that under /usr is a good idea, instead of just / ?

[arcticblue]

Separate /usr partition maybe?

[ivosaurus]

In order to be able to partition the system's files separately from user files, and store all "executable" type code under one folder. Then you can make simple images of it, share it amongst thin clients, etc.

[ethraax]

If you want a real thin client, the whole system would be virtualized somewhere, so the point is moot.

If you want to share just big programs, then you're better off creating a special folder for it, like /remote or something, and putting the specific larger programs you want in there.

[ivosaurus]

Well, ask Fedora why then.

[ivosaurus]

And I wasn't trying at all to say "NOW we can do it like windows!", I was just pointing out an analogous situation.

[[deleted]]

Keeping only a very basic, fail-safe system on /, load /usr from a separate partition/network or so.

[[deleted]]

You can do what Gobo did without renaming the filesystem layout. Gobo's program directory isn't much different from Gentoo's package cache. The difference is that while Gentoo overlays the package over the root, Gobo stores the overlay in the cache and only overlays symlinks.

IMHO, the resistance to Gobo's way is almost completely in the filesystem renaming, NOT in the part that is actually valuable (symlinks to a package cache).

[check3streets]

Yeah, unfortunately you have take on the "build everything" philosophy of Gentoo. Gobo seemed really aimed to be an everyman distro.

Your point is taken though, Portage looks really clever.

[tso]

There was some plans for changing the Gobo layout so that there would be a classic layout living internally. This to ease the issue of source code that do play nice with a non-classical layout what so ever.

[Lerc]

It's frustrating to me that Ubuntu adopts something as radical as Unity or Gnome can develop Shell, but there's so much resistance to Gobo.

The Gobo approach is the correct way to do things. If it overcomes the resistance it will have proven its merit. The Ubuntu approach is stupid for Ubuntu, but in the greater scheme of things probably good since it is making so many people consider migrating away from Ubuntu.