Linked by Thom Holwerda on Wed 2nd Nov 2011 23:17 UTC
Fedora Core Good news from the Linux world. Fedora has announced its intention to drastically alter the file system layout of its Linux distribution. The plan's been out for a while, but was brought to my attention by Brian Proffitt (still the best name ever) over at ITWorld. The gist is to move all binaries to /usr/bin, and all libraries to /usr/lib and /user/lib64.
Order by: Score:
...
by Hiev on Wed 2nd Nov 2011 23:20 UTC
Hiev
Member since:
2005-09-27

Thank you, this is something really needed, I hope the other distros follow this move.

Reply Score: 4

RE: ...
by phoenix on Wed 2nd Nov 2011 23:33 UTC in reply to "..."
phoenix Member since:
2005-07-11

Except, why should my OS applications (like ifconfig) be in the same programs directory as my installed applications (like httpd)?

Considering how poorly most filesystems work when you have thousands of files in a single directory, why dump everything into one directory?

While the Linux filesystem hierarchy "standard" isn't that great, dumbing it down further isn't going to help. Especially once you add in all the aggravation of having symlinks everywhere to make it look like the "old" way.

Edited 2011-11-02 23:34 UTC

Reply Score: 7

RE[2]: ...
by LB06 on Wed 2nd Nov 2011 23:39 UTC in reply to "RE: ..."
LB06 Member since:
2005-07-06

There's always the difference between ./bin and ./sbin. Both in / and /usr/. Merged or not.

Reply Score: 5

RE[3]: ...
by VistaUser on Wed 2nd Nov 2011 23:47 UTC in reply to "RE[2]: ..."
VistaUser Member since:
2008-03-08

Except they plan to merge them two together too.

Reply Score: 3

RE[2]: ...
by Gusar on Thu 3rd Nov 2011 00:07 UTC in reply to "RE: ..."
Gusar Member since:
2010-07-16

On my machine, ifconfig is an "installed application". I use Arch, which uses iproute2 by default, so net-tools (which contains ifconfig) is entirely optional. The point - your distinction is pretty much completely arbitrary.

Read their rationale for doing this: https://lists.fedoraproject.org/pipermail/devel/2011-October/158845....
I'm sure there'll be huge uproar from some people, but the rationale does make sense. No matter how you slice it, the distinction between these dirs is already arbitrary. And the "minimal boot system" is nowadays in an initramfs.

Reply Score: 2

RE[3]: ...
by sorpigal on Thu 3rd Nov 2011 11:48 UTC in reply to "RE[2]: ..."
sorpigal Member since:
2005-11-02

The distinction is variable, not arbitrary. It's different between arch and fedora, but it's pretty clear on one or the other. Some programs are supplied by default and are always required, some are supplied optionally by the distribution but required under certain configurations, some are supplied optionally by the distribution and are not required to boot, some are installed by the sysadmin from distro-compatible packages and some are installed by the sysadmin from generic packages not necessarily made for the distribution or from source. Each class of binary needs a place to go and ought to be listed separately.

Each distribution can do it differently and that's okay, as long as internally it's pretty consistent.

Reply Score: 2

RE[3]: ...
by phoenix on Thu 3rd Nov 2011 17:03 UTC in reply to "RE[2]: ..."
phoenix Member since:
2005-07-11

I've read the rationale, I've read the mailing list thread, I've read Lennart's summary. It still doesn't make sense, and unnecessarily complicates things with symlinks and over-simplifies things to the point of complexity.

But, maybe I've been spoiled by FreeBSD where there's a real, working, followed filesystem hierarchy (aka hier(7)). And a clear, logical separation between "what's needed to boot", "what's needed to run", and "third-party apps".

"what's needed to boot" is /, /lib, /bin, /sbin, /etc; the kernel, init system, and binaries needed to login and mount stuff.

"what's needed to run" is the rest of the OS itself, all under /usr

And "third-party apps" are kept under /usr/local.

Nice, neat, logical, and very, very, very useful. It's too bad most Linux systems don't work in a similar fashion, and that Fedora wants to takes things to the grand ol' days of DOS where everything is dumped into one directory.

Reply Score: 6

RE[4]: ...
by Soulbender on Thu 3rd Nov 2011 17:10 UTC in reply to "RE[3]: ..."
Soulbender Member since:
2005-08-18

I've read Lennart's summary.


Ah, Poettering. That explains *everything*.

Yes, I too like the clear BSD hier.

Reply Score: 3

RE[4]: ...
by rycamor on Thu 3rd Nov 2011 17:22 UTC in reply to "RE[3]: ..."
rycamor Member since:
2005-07-18

But, maybe I've been spoiled by FreeBSD where there's a real, working, followed filesystem hierarchy (aka hier(7)). And a clear, logical separation between "what's needed to boot", "what's needed to run", and "third-party apps".

"what's needed to boot" is /, /lib, /bin, /sbin, /etc; the kernel, init system, and binaries needed to login and mount stuff.

"what's needed to run" is the rest of the OS itself, all under /usr

And "third-party apps" are kept under /usr/local.


This also makes the FreeBSD jail system quite powerful. All jails share the kernel, and if you want, you can have them share the OS-level binaries too, mounting the same /usr for all jails. This leaves you free to change /usr/local aplications to your hearts' content in each jail, while still depending on the core OS to remain solid.

In fact, you can even decide to share a specific /usr/local among various jails, so that they can share a common application space. Keep boot, userland, and applications orthogonal to each other!

Reply Score: 1

RE[4]: ...
by darkcoder on Thu 3rd Nov 2011 17:27 UTC in reply to "RE[3]: ..."
darkcoder Member since:
2006-07-14

I've read the rationale, I've read the mailing list thread, I've read Lennart's summary. It still doesn't make sense, and unnecessarily complicates things with symlinks and over-simplifies things to the point of complexity.

Symlinks will add a complexity when browsing directories, otherwise no.


But, maybe I've been spoiled by FreeBSD where there's a real, working, followed filesystem hierarchy (aka hier(7)). And a clear, logical separation between "what's needed to boot", "what's needed to run", and "third-party apps".

"what's needed to boot" is /, /lib, /bin, /sbin, /etc; the kernel, init system, and binaries needed to login and mount stuff.

"what's needed to run" is the rest of the OS itself, all under /usr

And "third-party apps" are kept under /usr/local.

If I remember correctly most Linux distributions have that directory structure. The guy that suggested the filesystem change in Fedora is suggesting it since these days Fedora use an initramfs that has all the necesary kernel drivers and stuff to boot the system. While there are still some needed stuff in /bin like the bash, most stuff is in the initram itself. Thus making the old 30+ years definition of /sbin and /bin not that valid in terms of stuff needed to boot the system anymore.

Also people should considered while Fedora is a multipurpose distribution, is desktop oriented. And that FS change IMHO is more towards desktop. Many people should remember the flame when Fedora decided to move X to init1. And is working very good so far.

But I accept, the proposal needs more in-deep analysis, both as desktop and server targets.

My only concern is that with every change (GPL3, init changes, X driver removal, filesystem) Linux is separating itself from other UNIX like systems. Since UNIX derivative market is small compare to others, I prefer if they find a way to work out most of that differences and provide an unified layer where developers will be able to work once, deploy anywhere.

Edited 2011-11-03 17:32 UTC

Reply Score: 1

RE[2]: ...
by Hiev on Thu 3rd Nov 2011 01:23 UTC in reply to "RE: ..."
Hiev Member since:
2005-09-27

What could be worse than this mess?

http://imagebin.org/182175

And why would you care if ifconfig is mixed with other files?

Reply Score: 4

RE[2]: ...
by vidarh on Fri 4th Nov 2011 09:59 UTC in reply to "RE: ..."
vidarh Member since:
2011-10-14

Except, why should my OS applications (like ifconfig) be in the same programs directory as my installed applications (like httpd)?


They already are, for the most part in pretty much every Linux distro.


Considering how poorly most filesystems work when you have thousands of files in a single directory, why dump everything into one directory?


This isn't even a problem with ext2fs on modern system unless you reach tens of thousands of files. Much less for more modern filesystems. Non-issue unless you're planning on running ext2 on a 486 and dumb a massive amount of extra files in there.


Especially once you add in all the aggravation of having symlinks everywhere to make it look like the "old" way.


Why is this an aggravation? It's not like you need to maintain them manually.

Reply Score: 1

RE: ...
by Laurence on Thu 3rd Nov 2011 08:17 UTC in reply to "..."
Laurence Member since:
2007-03-26

Thank you, this is something really needed, I hope the other distros follow this move.

Why?

The nice thing about Linux/UNIX is it doesn't matter were apps are installed, unlike Windows.

But if you really need to dig out the executable, then just which it: http://unixhelp.ed.ac.uk/CGI/man-cgi?which

People make such a big deal about the directory hierarchy in Linux, but I don't think it really makes a huge amount of difference unless you're a systems administrator - and in those cases you'd be using tools like the above anyway.

Reply Score: 5

RE[2]: ...
by Verunks on Thu 3rd Nov 2011 10:48 UTC in reply to "RE: ..."
Verunks Member since:
2007-04-02


The nice thing about Linux/UNIX is it doesn't matter were apps are installed, unlike Windows.

what are you talking about? you can install programs wherever you want on windows

Reply Score: 1

RE[3]: ...
by Laurence on Thu 3rd Nov 2011 13:37 UTC in reply to "RE[2]: ..."
Laurence Member since:
2007-03-26


what are you talking about? you can install programs wherever you want on windows

It would be nice if people actually thought a little about the post they reply to rather than just reacting to it ;)

At no point did I say you couldn't install apps where-ever you wanted in Windows. I just said it matters. In Windows there is no global directory for 3rd party application like there is in Linux. This means everything has to be called for with absolute paths when writing scripts.

Granted you could easily configure Windows to behave a little more like Linux in that regard, but I'm talking about default behavior.

I know none of this is an issue for regular users who just key off installed shortcuts or even on Win7 where you can type the name of the application into the start menu. But equally the different directory structures in Linux is a non-issue to those same kind of users. However to people who do write batch/shell scripts that run utilities not located in (%windows|%system%) nor have their install locations added to %PATH% (which, again, is not the default action for most installers), then it very much matters where programs install to.

Plus Windows Add/Remove programs isn't perfect, so many power-users are left tidying up directory structures. This, again, is a non-issue with Linux package managers.

So my point wasn't a criticism of Windows (and thus no need for yourself to get riled up). I was just making a generalisation; comparing Windows administration to Linux administration.

Reply Score: 3

RE[4]: ...
by manjabes on Thu 3rd Nov 2011 14:36 UTC in reply to "RE[3]: ..."
manjabes Member since:
2005-08-27

"
what are you talking about? you can install programs wherever you want on windows

It would be nice if people actually thought a little about the post they reply to rather than just reacting to it ;)

At no point did I say you couldn't install apps where-ever you wanted in Windows. I just said it matters. In Windows there is no global directory for 3rd party application like there is in Linux. This means everything has to be called for with absolute paths when writing scripts.
"

One word: %PROGRAMFILES%
One link: http://technet.microsoft.com/en-us/library/cc749104(WS.10).aspx
One request: Please don't troll!

Reply Score: 1

RE[5]: ...
by Soulbender on Thu 3rd Nov 2011 14:45 UTC in reply to "RE[4]: ..."
Soulbender Member since:
2005-08-18

One word: %PROGRAMFILES%


%PROGRAMFILES% does not solve that problem. I still can't just type "firefox" in a cmd window and have firefox launched. I'd have to know what directory firefox is in, even if it's only relative to %PROGRAMFILES%.
Unless of course I add every programs folder into %PATH% but that's a bit awkward.

Reply Score: 2

RE[6]: ...
by djhayman on Fri 4th Nov 2011 05:36 UTC in reply to "RE[5]: ..."
djhayman Member since:
2006-07-04

%PROGRAMFILES% does not solve that problem. I still can't just type "firefox" in a cmd window and have firefox launched.


No, but you can type in "start firefox".

Applications on Windows can register themselves in the "known applications" list, and can then be launched from anywhere with the "start" command (or Start -> Run, or in code using ShellExecute and ShellExecuteEx).

Edited 2011-11-04 05:53 UTC

Reply Score: 1

RE[5]: ...
by Laurence on Thu 3rd Nov 2011 14:54 UTC in reply to "RE[4]: ..."
Laurence Member since:
2007-03-26


One word: %PROGRAMFILES%
One link: http://technet.microsoft.com/en-us/library/cc749104(WS.10).aspx


%PROGRAMFILES% is only a variable name for an absolute path to a top level install directory. Nothing more.

It wont include the full install paths to any application installs (as they will be sub-directories) and it wont work for any applications that install out of that specific top level folder (which may not be the norm, but it does occasionally happen).

What I'm talking about is %PATH%, which holds multiple directories and anything within those directories runs without an absolute path. You could add every single directory for every single application install into %PATH%, but that would be time consuming and could likely screw up other things due to:
1/ length of the environmental variable
2/ access times where the HDD is forced to seek dozens of different directories.

So perhaps you'd want to research a little into your own suggestions before being condensing to others ;)

One request: Please don't troll!

Is it even possible to have a discussion on here without someone accusing someone else of "trolling" or being a "fanboy"?
*bangs head on desk until it goes numb*

Edited 2011-11-03 15:03 UTC

Reply Score: 2

Comment by _txf_
by _txf_ on Wed 2nd Nov 2011 23:35 UTC
_txf_
Member since:
2008-03-17

This is indeed great and long past due.

Still, cue on breakage and hordes complaining about fixing things that aren't broken...

Reply Score: 3

rklrkl
Member since:
2005-07-06

I don't have an issue of moving all binaries and libraries under /usr somewhere, but won't it actually lead to more complexity in the short term? This is because soft-links will have to be left behind in their original places for a while (2-3 years at least?).

Also, here's some stuff that might be affected by this:

X.org driver libraries (currently scattered around /usr/lib/xorg/modules/* - expected to go in /usr/lib or /usr/lib64 now?)

Third party packages that install their binaries and libraries into /opt/<package> (e.g. Adobe, Google, LibreOffice and Oracle products) - I can't see them changing their install locations since they're cross-distro.

Kernel (/lib/modules/*) and pam (/lib/security) modules

A laudable idea in theory, but in practice, it'll be many years before this could potentially (look at LSB - many distros have either ignored it or not installed it via default after how many years?).

Reply Score: 3

Delgarde Member since:
2008-08-19

Third party packages that install their binaries and libraries into /opt/ (e.g. Adobe, Google, LibreOffice and Oracle products) - I can't see them changing their install locations since they're cross-distro.


Third party packages installing into /opt are not affected by the proposal. They're talking about merging /bin and /lib into /usr, not merging *everything* into /usr...

Reply Score: 2

GoboLinux for thew win!
by transami on Thu 3rd Nov 2011 00:04 UTC
transami
Member since:
2006-02-28

Woot! Woot! Triple woot! It's about time!

Now, RedHat, go the last yard and adopt the GoboLinux file hierarchy (http://gobolinux.org/?page=at_a_glance). Then the Linux file hierarchy will finally be out the dark ages altogether.

Please, please, please. You can do it!

Reply Score: 8

RE: GoboLinux for thew win!
by ggeldenhuys on Thu 3rd Nov 2011 07:01 UTC in reply to "GoboLinux for thew win!"
ggeldenhuys Member since:
2006-11-13

I can't agree with you more! I have read quite a bit about GoboLinux - many years back. The file-system hierarchy seemed a lot more "sane" than what we have now.

How can we notify the Red Hat guys about GoboLinux? They could take a look at an actual working Linux distro which uses an alternative file hierachy. Maybe there is something (which I am sure there is) they can learn and take from GoboLinux.

For those that don't know, here are some more link to what GoboLinux did, and why they did it.

http://www.gobolinux.org/?page=k5
http://en.wikipedia.org/wiki/GoboLinux

Edited 2011-11-03 07:03 UTC

Reply Score: 5

RE[2]: GoboLinux for thew win!
by jabjoe on Thu 3rd Nov 2011 09:22 UTC in reply to "RE: GoboLinux for thew win!"
jabjoe Member since:
2009-05-06

You think they don't know of GoboLinux? I would be gob-smacked if they didn't. They have chosen not to do like Gobo. Why? Well it will probably be the old problem when revolution needs legacy compatibility. They you end up having made the problem worse because you still have the old system, but you have a new one too. Gobo still has the "legacy tree" but it hides it with the "GoboHide" hack.

http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Way#The_.22...

There is a reason the Gobo way didn't catch on. The "legacy tree" is a Unix standard and will be with us a long time yet. Considering it's age and how it evolved, I think it's actually quite clean, once you read how it works.

Reply Score: 3

RE[3]: GoboLinux for thew win!
by Slambert666 on Thu 3rd Nov 2011 09:56 UTC in reply to "RE[2]: GoboLinux for thew win!"
Slambert666 Member since:
2008-10-30

You think they don't know of GoboLinux? I would be gob-smacked if they didn't.


I would be surprised if they did. NIH adversity runs deep in the Fedora project.

Reply Score: 3

RE[4]: GoboLinux for thew win!
by sorpigal on Thu 3rd Nov 2011 11:42 UTC in reply to "RE[3]: GoboLinux for thew win!"
sorpigal Member since:
2005-11-02

I'm sure they do. The Linux community is still relatively small (and was smaller still when Gobo made its big splash). More likely they don't like the workarounds gobo used to make things still function (and I'm not talking about backwards compatibility).

Reply Score: 2

RE[3]: GoboLinux for thew win!
by JAlexoid on Thu 3rd Nov 2011 11:14 UTC in reply to "RE[2]: GoboLinux for thew win!"
JAlexoid Member since:
2009-05-19

Why is a certified Unix - Mac OSX - have a different structure and still is a Unix?

Reply Score: 2

RE[4]: GoboLinux for thew win!
by No it isnt on Thu 3rd Nov 2011 11:27 UTC in reply to "RE[3]: GoboLinux for thew win!"
No it isnt Member since:
2005-11-14

OS X still has /bin and /sbin and /usr and so on, they're just hidden from Finder.

Reply Score: 3

lucas_maximus Member since:
2009-08-18

Because POSIX is not about your File System Hierarchy ... it is more about system utilities and so forth.

http://en.wikipedia.org/wiki/Single_UNIX_Specification#Specificatio...

Edited 2011-11-03 15:44 UTC

Reply Score: 2

RE: GoboLinux for thew win!
by No it isnt on Thu 3rd Nov 2011 10:39 UTC in reply to "GoboLinux for thew win!"
No it isnt Member since:
2005-11-14

Sure. Or you could just stick with Windows.

Reply Score: 1

RE: GoboLinux for thew win!
by Soulbender on Thu 3rd Nov 2011 16:35 UTC in reply to "GoboLinux for thew win!"
Soulbender Member since:
2005-08-18

This change has nothing to with making things easier for the user though and will not result in anything like the
gobolinux stuff.

I don't quite understand this obsession with making the the file system hierarchy "simpler". As a user I rarely ever look at files outside the home directory and when I do it's almost always on a removable device.
As a developer you need to know a bit more about the hierarchy but the gobolinux changes does not really make a big difference here.
If I was a new admin I might find these alternative hierarchies easier to use but it's questionable.
Why not focus on making better applications and a better user experience rather than obsessing over something that doesn't matter much in the grand scheme of things?

Reply Score: 2

Giving up on recovery
by malxau on Thu 3rd Nov 2011 00:07 UTC
malxau
Member since:
2005-12-04

It makes sense in the context that Fedora requires /usr to be populated in order to boot today, but the whole point of a separate /usr is to enable the system to boot and be repaired without depending on all of the "applications" to be available.

Root could be small, readonly, and always there as a failsafe. Becoming more monolithic really makes it harder to recover when things go wrong - if your openoffice install corrupts some part of the filesystem tree, you'll need more dramatic recovery options (eg. boot from CD/DVD.)

Reply Score: 8

RE: Giving up on recovery
by Delgarde on Thu 3rd Nov 2011 01:07 UTC in reply to "Giving up on recovery"
Delgarde Member since:
2008-08-19

Root could be small, readonly, and always there as a failsafe.


These days, we call that "initramfs". Because if you already have a small readonly version of the system that's sophisticated enough to mount root from a network filesystem or an encrypted device, there's not much value in the separate root device at all...

Reply Score: 6

RE[2]: Giving up on recovery
by sorpigal on Thu 3rd Nov 2011 11:40 UTC in reply to "RE: Giving up on recovery"
sorpigal Member since:
2005-11-02

Is initramfs required to boot? Last I knew, it wasn't.

Reply Score: 2

RE[3]: Giving up on recovery
by phoenix on Thu 3rd Nov 2011 17:06 UTC in reply to "RE[2]: Giving up on recovery"
phoenix Member since:
2005-07-11

It is for Fedora.

Reply Score: 2

RE[3]: Giving up on recovery
by Delgarde on Thu 3rd Nov 2011 20:23 UTC in reply to "RE[2]: Giving up on recovery"
Delgarde Member since:
2008-08-19

Is initramfs required to boot? Last I knew, it wasn't.


Strictly speaking, no, but almost all distros default to using them, and you'll need a fair bit of work to configure the system not to need or use one.

Reply Score: 2

RE: Giving up on recovery
by foregam on Thu 3rd Nov 2011 11:39 UTC in reply to "Giving up on recovery"
foregam Member since:
2010-11-17

[...] the whole point of a separate /usr is to enable the system to boot and be repaired without depending on all of the "applications" to be available.

Root could be small, readonly, and always there as a failsafe. [...]


My feelings exactly. The result of moving /bin and /sbin to /usr will be a major clusterfuck. The OS graveyard is full of Unices which did that. Think HP-UX. Oh, and it will make mounting /usr from NFS even more nightmarish than it is now. So I say first implement union directories a la Plan 9 (aufs is fine but doesn't come anywhere close to that) and improve u9fs, and then screw with the filesystem layout as much as you wish.

Reply Score: 2

Why kept everything under /usr?
by fabien on Thu 3rd Nov 2011 00:50 UTC
fabien
Member since:
2011-11-03

Next step would be to have merging directory under /, including $HOME, /opt, etc. (Isn't what Hurd is supposed to do ?) That would be very nice.

Reply Score: 2

RE: Why kept everything under /usr?
by ddc_ on Thu 3rd Nov 2011 01:27 UTC in reply to "Why kept everything under /usr?"
ddc_ Member since:
2006-12-05

HURD was basicly linking /usr to /.

The whole idea of moving everything to / is incompartible with Red Hat's effort to share the application and data folder between users - / contains much more.

Reply Score: 2

Not Quite
by MeatAndTaters on Thu 3rd Nov 2011 00:55 UTC
MeatAndTaters
Member since:
2005-11-16

"Brian Proffitt" is not the best name ever.

"M3 Sweatt" is: http://blogs.msdn.com/b/mthree/about.aspx

Reply Score: 4

RE: Not Quite
by KLU9 on Thu 3rd Nov 2011 16:28 UTC in reply to "Not Quite"
KLU9 Member since:
2006-12-06

"M3 Sweatt" is not the best name ever.

"Max Power" is : http://en.wikipedia.org/wiki/Max_Power

Reply Score: 2

Why not go all the way?
by Lazarus on Thu 3rd Nov 2011 00:58 UTC
Lazarus
Member since:
2005-08-10

I find the whole thing kind of silly, but if you're going to do this, why not make it as simple as possible.

/System
/Library
/Programs
/Users

Reply Score: 13

RE: Why not go all the way?
by OSbunny on Thu 3rd Nov 2011 01:06 UTC in reply to "Why not go all the way?"
OSbunny Member since:
2009-05-23

Because that's too long and complicated to type.

Moving everything to /usr is a nice idea. I just wonder how long before those symlinks in / will no longer be needed. Until then it won't feel like a real move.

Reply Score: 0

RE[2]: Why not go all the way?
by tylerdurden on Thu 3rd Nov 2011 01:25 UTC in reply to "RE: Why not go all the way?"
tylerdurden Member since:
2009-03-17

That makes no sense, following your logic to its ultimate consequences, everything should be in /

Reply Score: 7

RE: Why not go all the way?
by caruccio on Thu 3rd Nov 2011 01:07 UTC in reply to "Why not go all the way?"
caruccio Member since:
2010-10-19

lowercase, please. shift keys are expensive.

Reply Score: 10

RE[2]: Why not go all the way?
by oinet on Thu 3rd Nov 2011 03:40 UTC in reply to "RE: Why not go all the way?"
oinet Member since:
2010-03-23

lowercase, please. shift keys are expensive.


Exactly!

Reply Score: 3

RE[2]: Why not go all the way?
by bogomipz on Thu 3rd Nov 2011 07:13 UTC in reply to "RE: Why not go all the way?"
bogomipz Member since:
2005-07-11

This and many more concerns are answered very well by the GoboLinux creator:

http://gobolinux.org/?page=doc/articles/clueless

In fact, the concerns on typing-friendliness always comes up in discussions about the GoboLinux tree. To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab.

Reply Score: 4

ThomasFuhringer Member since:
2007-01-25

When does a user ever type this?
They just select it in a list in the GUI. And the current ridiculous naming scheme is inpenetrable to them. And ugly.

Computers should be made for users and not developers.

Reply Score: 2

RE[3]: Why not go all the way?
by oinet on Thu 3rd Nov 2011 11:09 UTC in reply to "RE[2]: Why not go all the way?"
oinet Member since:
2010-03-23

When does a user ever type this?
They just select it in a list in the GUI. And the current ridiculous naming scheme is inpenetrable to them. And ugly.

Computers should be made for users and not developers.


CLI users are users too.

Reply Score: 2

RE[3]: Why not go all the way?
by l3v1 on Thu 3rd Nov 2011 11:34 UTC in reply to "RE[2]: Why not go all the way?"
l3v1 Member since:
2005-07-06

When does a user ever type this?


Uhmm... all the time.

There exist users other then "users".

Reply Score: 3

RE[3]: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 11:39 UTC in reply to "RE[2]: Why not go all the way?"
sorpigal Member since:
2005-11-02

Since it doesn't matter to dumb "desktop users" who don't understand anything and just click anyway and it DOES matter to those of us who use the command line, why not satisfy everybody instead of just the philistines?

Reply Score: 1

lucas_maximus Member since:
2009-08-18

Obviously because you use a command line and have memorized obscure commands makes you a better human being ... :-|

Anyway most shells have tab completion. Even cmd.exe (which is well known for being a bit rubbish) has it (since Win XP). The length of the word is pretty much irrelevant.

The word "System" is pretty clear what it is ...

Edited 2011-11-03 13:42 UTC

Reply Score: 2

RE[5]: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 13:47 UTC in reply to "RE[4]: Why not go all the way?"
sorpigal Member since:
2005-11-02

Again I ask: Since you admit and accept that one class of users doesn't care and it doesn't matter to them, and you admit that it does matter to another class of users, what then is the harm to making BOTH sets of users happy?

Tab completion is rather irrelevant to the issue. With or without it I am not touching my shift key. Gobo's approach of case-insensitive tab completion is just obscene (not to mention dangerous).

Reply Score: 4

lucas_maximus Member since:
2009-08-18

Again I ask: Since you admit and accept that one class of users doesn't care and it doesn't matter to them, and you admit that it does matter to another class of users, what then is the harm to making BOTH sets of users happy?


What I am saying is that you are making a big deal over nothing ...

Also some will be confused if "clicking through" the same folders ... so tbh the same criticism is valid both when using a CLI and a GUI.

"What is the /usr thing?" ... seriously everytime I see /usr I think U.S.S.R. When I see /etc I think ".etc" not "editable text configuration".

Overly Terse naming schemes are a constant frustration in my job already thankyou.

Tab completion is rather irrelevant to the issue. With or without it I am not touching my shift key. Gobo's approach of case-insensitive tab completion is just obscene (not to mention dangerous).


LOLWOT ... Pressing a Shift key isn't a big deal, there is even two of them on a keyboard.

Edited 2011-11-03 14:49 UTC

Reply Score: 2

RE[7]: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 14:56 UTC in reply to "RE[6]: Why not go all the way?"
sorpigal Member since:
2005-11-02

What I am saying is that you are making a big deal over nothing ...

No. I'm making a big deal over something that's nothing to you. It really matters.

Also some will be confused if "clicking through" the same folders ... so tbh the same criticism is valid both when using a CLI and a GUI.

"What is the /usr thing?" ... seriously everytime I see /usr I think U.S.S.R. When I see /etc I think ".etc" not "editable text configuration".

Overly Terse naming schemes are a constant frustration in my job.

Off topic! We were discussing why the proposed new names should be all lower-case, were we not? Nobody is disputing that the existing names are confusing.

"Tab completion is rather irrelevant to the issue. With or without it I am not touching my shift key. Gobo's approach of case-insensitive tab completion is just obscene (not to mention dangerous).


LOLWOT ... Pressing a Shift key isn't a big deal, there is even two of them on a keyboard.
"
Let me say it again for you very slowly because you and I seem to be having a communication problem: This. Really. Matters. I care. Lots of people care. Pressing a shift key is a big deal. You may not think so, that was pretty clear from the start, but this entire conversation has been about disabusing of the notion that your evaluation is correct. Advocating "/Users" instead of "/users" helps no one and harms some of us. You may not think it's much harm, but since you are not one of the people it harms you are in no position to judge that. I am one of those people. I am telling you "This is harmful." You can ignore people like me only if you don't care to actually get what you want.

Reply Score: 4

RE[2]: Why not go all the way?
by mikelward on Thu 3rd Nov 2011 17:04 UTC in reply to "RE: Why not go all the way?"
mikelward Member since:
2007-03-22

Agree, but it's trivial to adapt to.

~/.inputrc
set completion-ignore-case On

~/.zshrc
zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}'

Reply Score: 2

RE: Why not go all the way?
by ddc_ on Thu 3rd Nov 2011 01:32 UTC in reply to "Why not go all the way?"
ddc_ Member since:
2006-12-05

I find the whole thing kind of silly, but if you're going to do this, why not make it as simple as possible.

/System
/Library
/Programs
/Users
What is simple here? The end user shouldn't browse / until he knows how that works. and when he learns the principals, the naming simplicity turns out to be the typing simplicity, so /s, /l, /p and /u (respectively) will make more sense. And You forgot /m (local media) and (possibly) /n (network resources).

Reply Score: 0

RE[2]: Why not go all the way?
by lucas_maximus on Thu 3rd Nov 2011 13:33 UTC in reply to "RE: Why not go all the way?"
lucas_maximus Member since:
2009-08-18

lolwot!

I give all my variable names in programming proper variables name so when another developer comes along and read my code they might know what the hell was going through my head at the time.

Stupid one letter names would be confusing.

Most shells have tab completion so the length of the actual word is largely irrelevant .. If you have problems typing "System" quickly ... I suggest you should invest in a better keyboard.

Reply Score: 3

RE: Why not go all the way?
by ebasconp on Thu 3rd Nov 2011 02:22 UTC in reply to "Why not go all the way?"
ebasconp Member since:
2006-05-09

I find the whole thing kind of silly, but if you're going to do this, why not make it as simple as possible.

/System
/Library
/Programs
/Users



I actually agree with this hierarchy (available in Mac OS X, PC-BSD and in some extent, in Windows).

Edited 2011-11-03 02:23 UTC

Reply Score: 5

RE: Why not go all the way?
by oinet on Thu 3rd Nov 2011 03:37 UTC in reply to "Why not go all the way?"
oinet Member since:
2010-03-23

I find the whole thing kind of silly, but if you're going to do this, why not make it as simple as possible.

/System
/Library
/Programs
/Users


1. "<Shift>First char</Shift>remnant chars" (after all: we're talking Unix with case sensitive FSs, and not Windows or AmigaOS where that luxury (pain) is absent) isn't exactly as simple as possible: one of the the few stupid ideas in GoboLinux.

2. You have "library" (singular/collective), and then "programs" and "users" (plural). Non-uniformity is not as simple as possible.

My few rotten cents...

Reply Score: 2

RE[2]: Why not go all the way?
by tupp on Thu 3rd Nov 2011 05:34 UTC in reply to "RE: Why not go all the way?"
tupp Member since:
2006-11-12

1. "<Shift>First char</Shift>remnant chars" (after all: we're talking Unix with case sensitive FSs, and not Windows or AmigaOS where that luxury (pain) is absent) isn't exactly as simple as possible: one of the the few stupid ideas in GoboLinux.

No.

Gobolinux by default uses a version of zsh which is configured to auto-complete regardless of case.

So, the procedure to type "/System" in the shell is simply "/", "s" and "<tab>".

Reply Score: 8

RE[3]: Why not go all the way?
by bogomipz on Thu 3rd Nov 2011 07:22 UTC in reply to "RE[2]: Why not go all the way?"
bogomipz Member since:
2005-07-11

On top of that, the captialized names prevent name clashes with standard directories. When GoboLinux was introduced, /sys did not yet exist. People used to complain that Gobo should use /sys rather than /System, but that would have created problems later.

Reply Score: 3

RE[3]: Why not go all the way?
by oinet on Thu 3rd Nov 2011 10:57 UTC in reply to "RE[2]: Why not go all the way?"
oinet Member since:
2010-03-23

Gobolinux by default uses a version of zsh which is configured to auto-complete regardless of case.

So, the procedure to type "/System" in the shell is simply "/", "s" and "".


Ok, that might be the case now. But surely the sensible thing is to just lower-case the thing so one doesn't have to use modification of filesystem x ?

Reply Score: 2

RE[4]: Why not go all the way?
by tupp on Thu 3rd Nov 2011 16:46 UTC in reply to "RE[3]: Why not go all the way?"
tupp Member since:
2006-11-12

Ok, that might be the case now.

Yes. Such is the case, if "now" means "from 2002 to the present."


But surely the sensible thing is to just lower-case the thing so one doesn't have to use modification of filesystem x ?

Not sure what is meant by "so one doesn't have to use modification of filesystem x." The file system is not being modified.

Using lower-case is sensible in this situation for a few reasons. Bogomipz has hinted above at one advantage of using capitalized system directories, and bogomipz has also linked in another post above to the explanation of the way things are done in Gobolinux by Hisham Muhammad (Gobolinux's creator). Here is the link again: http://gobolinux.org/index.php?page=doc/articles/clueless

Reply Score: 2

RE[5]: Why not go all the way?
by oinet on Thu 3rd Nov 2011 19:57 UTC in reply to "RE[4]: Why not go all the way?"
oinet Member since:
2010-03-23

Yes. Such is the case, if "now" means "from 2002 to the present."


I'm not sure, last time I tried it (4 years ago ?) I don't remember it auto-capitalize. But then, my memory == RAM...sometimes :|


Not sure what is meant by "so one doesn't have to use modification of filesystem x." The file system is not being modified.


Filesystem as in "filesystem driver". Pardon me and my RAM, or "webcam", since I have forgotten a thing or two *nix related (z-shell included), I somehow thought "zsh" was a filesystem, even though that sounded really weird that autocompletion would be implemented on filsystem driver level (I deserve rotten tomatos for breakfast).

Using lower-case is sensible in this situation for a few reasons. Bogomipz has hinted above at one advantage of using capitalized system directories, and bogomipz has also linked in another post above to the explanation of the way things are done in Gobolinux by Hisham Muhammad (Gobolinux's creator). Here is the link again: http://gobolinux.org/index.php?page=doc/articles/clueless


I have read it in the past.
But regardless, an OS that has /sys and /System "directories" is where Alice belongs. Reminds me of AmigaOS which has SYS:, the system partition, and SYS:System, containing a few percent of core system files (the rest are simply in SYS: >_>). AROS, which I played with a few years ago, now (at least back then) mostly holds GUI related files in SYS:System !

Should the same name be used for sibling "directories" that hold different content ? does that make any sense ? regardless how you "decorate" the names ? /sys and /System, /sys and /system, /_sys(tem) and /sys(tem), /sys(tem) and /Sys(tem).... WTH ?!

Reply Score: 1

RE[2]: Why not go all the way?
by raddude9 on Thu 3rd Nov 2011 14:21 UTC in reply to "RE: Why not go all the way?"
raddude9 Member since:
2009-07-15

"I find the whole thing kind of silly, but if you're going to do this, why not make it as simple as possible.

/System
/Library
/Programs
/Users


1. "<Shift>First char</Shift>remnant chars" (after all: we're talking Unix with case sensitive FSs, and not Windows or AmigaOS where that luxury (pain) is absent) isn't exactly as simple as possible: one of the the few stupid ideas in GoboLinux.

2. You have "library" (singular/collective), and then "programs" and "users" (plural). Non-uniformity is not as simple as possible.

My few rotten cents...
"

Except that you would not have
/System
/Library
etc.
on AmigaOS. You would use device names to point to relevant directories, eg:
SYS:
Libs:
Devs:
Fonts:
C: (for commands)
etc.
Then it does not matter where you put those directories and you could re-point any of those device names at will.

Took a little while to get used to when if you were a DOS or UNIX head back in the day, but it was a far neater system IMHO. Maybe Linux should use that instead ;-)

Reply Score: 1

RE[3]: Why not go all the way?
by oinet on Thu 3rd Nov 2011 21:24 UTC in reply to "RE[2]: Why not go all the way?"
oinet Member since:
2010-03-23

Except that you would not have
/System
/Library
etc.
on AmigaOS. You would use device names to point to relevant directories, eg:
SYS:
Libs:
Devs:
Fonts:
C: (for commands)
etc.


I know that. I was referring to case sensitivity of *nix filesystems.

Then it does not matter where you put those directories and you could re-point any of those device names at will.


Yep.

Reply Score: 1

RE: Why not go all the way?
by jabjoe on Thu 3rd Nov 2011 09:36 UTC in reply to "Why not go all the way?"
jabjoe Member since:
2009-05-06

Because you have to support the Unix standard hierarchy. If you reinvent the hierarchy, you end up having the new one, and the old one. Like GoboLinux. Sure you can hide the old one, like GoboLinux, but that just pretending it's simpler when actually it's now more complicated. Windows NT kind of does this and it makes things much more complicated. What I love about Unix is it is simple. Everything is a file and those files are plain to see. It's all out in the open. The standard hierarchy really isn't that bad, especially considering it's age and how it's evolved, once you read how it works. So tweak it by all means, but don't try and throw it away, because unless you want to limit what can be run, you will end up with it anyway. As always, evolution not revolution.

Reply Score: 4

RE: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 12:08 UTC in reply to "Why not go all the way?"
sorpigal Member since:
2005-11-02

Okay big shot, reality check time.

Do you put libraries required by the system under /library or /system?

Where do you put databases?

Where do you put log files?

Do you split up logs for system and non-system components? How?

Where do you put temp files? Is that a /system sort of thing or a /users sort of thing? What if it's a temp file written by something from /programs - should we write into /system? If they write into /users, which home directory should be used when it's a daemon doing the writing?

Where does configuration go? If it's in /system, what about configuration for things that sit in /programs? Do you distinguish them? How?

If I put Firefox in /programs do I put its libraries in /library or under its directory in /programs? What counts as a library? Is it only ELF .so files or can I include e.g. Perl modules and "libraries" of shell code? What do you do about 32/64 bit programs and libs on the same system? Wht about libraries that aren't meant to be shared?

I could go on. Your idea of utopia is sweet but in the real world would be so much uglier than it appears in your head.

Edited 2011-11-03 12:10 UTC

Reply Score: 2

RE[2]: Why not go all the way?
by Icaria on Thu 3rd Nov 2011 13:06 UTC in reply to "RE: Why not go all the way?"
Icaria Member since:
2010-06-19

Have you actually used OSX? The root file system looks neat enough but start making you way down the filesystem tree and you'll get as lost and as quickly as you would browsing the FHS.

In short: 'yo dawg, I herd u liek filesystem layouts so we put file system layouts inside your filesystem layouts so u can file while u file'.

Funnily enough, OSX still makes a distinction between core OS resources/programmes and optional ones, with it's /Library and /System/Library directories (not to forget /Users/*/Library), which is exactly what Red Hat are trying to eradicate.


Anyway, I'm going to voice an unpopular opinion, here and state that I think the DOS style of filesystem layout is a lot better than anything the Unices have offered. The fundamental hierarchy is superior, as it doesn't lead to weird situations where users have to get their heads around mounting media inside another HDD's tree (WinNT can do this also but it's not often used), or dealing with virtual abstractions created by the kernel (eg. linux's /proc and *nix's /dev) inside your HDD's tree.

The obvious advantage of this goofy system is being able to do things like share /usr between multiple workstations over the network but a more ideal solution would still be to symlink /usr (or it's equivalent) to b:\ (or it's equivalent).

Eg. the first harddrive should appear as something like:
/devices/drive_a/

While the root filesystem remains simply as an abstraction for stuff like /proc and /dev[ices] (and perhaps a virtual /bin dir that populates with all items from all system paths).

Reply Score: 2

RE[3]: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 13:45 UTC in reply to "RE[2]: Why not go all the way?"
sorpigal Member since:
2005-11-02

Have you actually used OSX? The root file system looks neat enough but start making you way down the filesystem tree and you'll get as lost and as quickly as you would browsing the FHS.

If you're advocating a user-level UI decision about which things to hide and show then you are off topic, since the article was talking about physical layout. If you honestly think that the OS X approach of just hiding some of the complicated things is the right answer to technical challenges then I welcome you to make the case to the makers of user level software that their UIs should do this.

Funnily enough, OSX still makes a distinction between core OS resources/programmes and optional ones, with it's /Library and /System/Library directories (not to forget /Users/*/Library), which is exactly what Red Hat are trying to eradicate.

OS X can do this by (a) using app bundles and (b) meaning something a little different when they say "Library". If you want to discuss the pros (and holy crap the cons!) of app bundles, you're welcome to, but again that is off topic. No fix up of the FHS which depends on doing app bundles first is likely to be accepted any time soon by any mainstream distribution. Do you have an incremental proposal to get us there?

Anyway, I'm going to voice an unpopular opinion, here and state that I think the DOS style of filesystem layout is a lot better than anything the Unices have offered. The fundamental hierarchy is superior, as it doesn't lead to weird situations where users have to get their heads around mounting media inside another HDD's tree (WinNT can do this also but it's not often used), or dealing with virtual abstractions created by the kernel (eg. linux's /proc and *nix's /dev) inside your HDD's tree.

You're right, and I think you're crazy if you think that the awful CP/M workspace hack is better than the VFS approach. Drive letters actually make no sense whatsoever.

The obvious advantage of this goofy system is being able to do things like share /usr between multiple workstations over the network but a more ideal solution would still be to symlink /usr (or it's equivalent) to b:\ (or it's equivalent).

In the first place, even if you did it that would be b:/, in the second place how is this different from mkdir /b:/ ? The answer is that on the Windows side you *STILL* have a root above the drive letters, it just doesn't seem that way (most of the time). When your system is a special case of my system, my system is better.

Eg. the first harddrive should appear as something like:
/devices/drive_a/

While the root filesystem remains simply as an abstraction for stuff like /proc and /dev[ices] (and perhaps a virtual /bin dir that populates with all items from all system paths).

It's entirely possible to revise the FHS to be like this (and I recommend you try it!) I am all for it provided you don't break anything useful in the process. The problem is that there are broadly two camps: Those who don't understand the FHS and want to do things like you propose and those who like it and don't want to change it. A third camp involving people who like it AND want to change it would be useful.

Reply Score: 2

RE[4]: Why not go all the way?
by Icaria on Thu 3rd Nov 2011 15:07 UTC in reply to "RE[3]: Why not go all the way?"
Icaria Member since:
2010-06-19

If you're advocating a user-level UI decision about which things to hide and show then you are off topic, since the article was talking about physical layout. If you honestly think that the OS X approach of just hiding some of the complicated things is the right answer to technical challenges then I welcome you to make the case to the makers of user level software that their UIs should do this.


I have to ask: what point do you think I was trying to make? You seem to have phenomenally misconstrued my intent.

The post to which you were replying was suggesting that the OSX layout was the way to go. You quite rightly tore that to shreds but it appears that you didn't realise where that poster got their layout from. I was agreeing with you, while providing some additional context.

OS X can do this by (a) using app bundles and (b) meaning something a little different when they say "Library". If you want to discuss the pros (and holy crap the cons!) of app bundles, you're welcome to, but again that is off topic. No fix up of the FHS which depends on doing app bundles first is likely to be accepted any time soon by any mainstream distribution. Do you have an incremental proposal to get us there?
Again, you're way off base. This wasn't what I was suggesting at all.

You're right, and I think you're crazy if you think that the awful CP/M workspace hack is better than the VFS approach. Drive letters actually make no sense whatsoever.
Agreed.

In the first place, even if you did it that would be b:/
Well no, it wouldn't be but I digress.

in the second place how is this different from mkdir /b:/ ?
Well for starters, you'd have a static directory sitting on a HDD partition, somewhere.

The answer is that on the Windows side you *STILL* have a root above the drive letters, it just doesn't seem that way (most of the time).
Except it's all virtual; Windows doesn't throw it's it's VFS and the OS partition in a blender.

It's entirely possible to revise the FHS to be like this (and I recommend you try it!) I am all for it provided you don't break anything useful in the process. The problem is that there are broadly two camps: Those who don't understand the FHS and want to do things like you propose and those who like it and don't want to change it. A third camp involving people who like it AND want to change it would be useful.
Except, for the purposes of spitballing, I'm really not concerned with backwards compatibility. As for use cases supported, for something like the following, can you see any specific limitations?

______________________

/bin (symlink/merge of all bin/ directories on OS volume)

/boot (symlink to OS volume: /devices/storage/drive01/volume01/)

/devices/
..storage/
....drive01/
......volume01/ (first hdd, first partition, OS location, first non-virtual part of filesystem tree)
........user/ (optionally symlinked to /devices/drive02/volume01/)
..........username/
............bin/
............libraries/
............config/
........system_files/
..........bin/
..........libraries/
........optional_files/ (optionally symlinked to eg. /network/compname/storage/volume01)
..........bin/
..........libraries/
........temp/ (temp files and logs)
......volume02/
....drive02/
......volume01/

/network/
..compname/
....storage/
......volume01/
......volume02/

/proc
______________________________

Just a half-arsed effort on my part. Obviously would put more than 5 minutes thought in to it, were I about to go and write my own OS.

Reply Score: 2

RE[5]: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 18:15 UTC in reply to "RE[4]: Why not go all the way?"
sorpigal Member since:
2005-11-02

The post to which you were replying was suggesting that the OSX layout was the way to go. You quite rightly tore that to shreds but it appears that you didn't realise where that poster got their layout from. I was agreeing with you, while providing some additional context.

The OP was suggesting that we simplify even further than the article describes and proposed a scheme that closely resembles OS X. However, while it's easy to say "Just make it simple" it's hard to do. I was attempting to explain why the real world isn't simple (and how OS X gets away with sometimes pretending it is). You came in talking about what the user sees, but that's not the topic of the article that started all of this and thus not what we were discussing. The article is talking about physical layout, so AFAIK the OP was talking about physical layout, so I am objecting to an oversimplification of physical layout and you are saying "But physical layout doesn't matter, only what the user sees matters"-- but the topic is changes to phsysical layout! Now *I'm* confused. What the user sees is another topic, how it actually works is what I care about (and what we are, AFAIK, discussing).

Whether OS X is what the OP modeled his naive suggestion on, or not, is not important to me since it ignorantly omits the hidden directories. If the OP would care to chime in and clarify whether he was intending for those hidden directories to exist, that would be helpful.

"In the first place, even if you did it that would be b:/

Well no, it wouldn't be but I digress.
"
The entire world uses forward slashes to delimit directories at this point in history, except for systems which spiritually inherit from DOS, which had already used forward slash for its switch character. To continue using backslash is just silly. The use of backslash on Windows is itself essentially unnecessary and is only kept around (AFAICT) "Just in case" something is installed which might break it. Windows has supported forward slash for directories for a long time. Proposing the (re)introduction of backslash in a non-legacy context is crazy, so it would be b:/

Side note: If you were really going to do this you should use drive labels and not arbitrary drive letters. Like "system:/" and "my thumb drive:/" - makes more sense these days.

Well for starters, you'd have a static directory sitting on a HDD partition, somewhere.

Then make the "static" directory be managed by udev or something like it and appear and disappear as needed. Automounters are perfectly capable of doing this today.

"The answer is that on the Windows side you *STILL* have a root above the drive letters, it just doesn't seem that way (most of the time).

Except it's all virtual; Windows doesn't throw it's it's VFS and the OS partition in a blender.
"
I'm really confused by this. You advocate simply hiding the real VFS root from the user? I don't see how this helps; your original complaint was about how confusing it was, but you can make it less confusing with simple UI gimmicks and a sprinkling of policy without requiring any fundamental change to Unix. Why throw out the VFS when it can be used to implement exactly what you want without nearly as much effort as starting again?

Except, for the purposes of spitballing, I'm really not concerned with backwards compatibility.

I'm sorry, I thought we were discussing actual, practical real-world things that Fedora might actually be able to do within the next 2-3 release cycles to actually improve real FHS issues on a real mainstream distribution, both as they relate to packagers and sysadmins. I wasn't aware that you were off on some tangent about what might be a nice design in theory for a new system someone could build.

Reply Score: 2

RE[5]: Why not go all the way?
by sorpigal on Thu 3rd Nov 2011 18:25 UTC in reply to "RE[4]: Why not go all the way?"
sorpigal Member since:
2005-11-02

A second reply for the other topic in your post - your new FHS.

I'd say that I generally like it, modulo (as you point out) the fact that it's a five minute kind of job.

I like having a network root in the VFS; this is definitely where Unix faceplants pretty hard and Windows (and Domain OS) do well.

I'd certainly want to discuss the virtue of your /bin idea; I've tried to do that before but I don't know how to make it work.

I certainly don't like the FS roots to be inside the device tree; that makes some things simpler to understand at the cost of making everything harder to manage. The VFS is really good for seamless hardware migrations, which you throw out for no good reason. It would be okay if you could map physical hardware into logical components that don't change and then base your heirarchy on top of that, thus.

/devices/
..storage/
....disk01

and then logically map disk01 as being part of MyAwesomeVolume

/system/
..MyAwesomeVolume/
....home/

and so on. That would be only a little more complex and a lot less breaky when the 2T disk01's data is migrated to the 20T disk02 at some point in the future (and then disk01 is used to serve some other part of the fs).

Whatever usability you gain it's important not to lose this kind of flexibility.

Reply Score: 2

RE: Why not go all the way?
by krreagan on Thu 3rd Nov 2011 13:21 UTC in reply to "Why not go all the way?"
krreagan Member since:
2008-04-08

I agree. It time to move the file/directory system out of the last century.

Reply Score: 1

RE: Why not go all the way?
by sirhalos on Thu 3rd Nov 2011 13:35 UTC in reply to "Why not go all the way?"
sirhalos Member since:
2007-04-04

You should have it as /Applications and /Programs since it would help guarantee that the programs show up first if sorting alphabetically. Also you would always have symlinks to the traditional file system that you can use.

Reply Score: 1

RE: Why not go all the way?
by xyproto on Thu 3rd Nov 2011 13:55 UTC in reply to "Why not go all the way?"
xyproto Member since:
2011-10-12

Just remember include files, logs, temporary files, configuration files (both systemwide and per user), cache files, the possibility to mount some directories on a speedier drive etc etc

Reply Score: 1

Why not simply move it to nul ...
by tomcat on Thu 3rd Nov 2011 01:40 UTC
tomcat
Member since:
2006-01-06

... and save the effort.

Reply Score: 5

not sure if I like this
by TechGeek on Thu 3rd Nov 2011 01:46 UTC
TechGeek
Member since:
2006-01-14

While I have nothing against simplicity or change, I am not sure I like this. These folders were separated out for reasons. While I guess it makes no difference if you combine /bin and /sbin these days, why put everything under /usr? That doesn't change anything. You are just adding one more layer into the path of any file while breaking pretty much everything in the process. Is there really a difference between /lib and /usr/lib? Seems like a lot of work for minimal gain.

Reply Score: 4

RE: not sure if I like this
by bnolsen on Thu 3rd Nov 2011 03:06 UTC in reply to "not sure if I like this"
bnolsen Member since:
2006-01-06

i typically have /bin, /lib, boot and /etc on one partition. I keep /usr on another (on lvm). It allows me to have a minimal bootable system for recovery.

Reply Score: 3

RE: not sure if I like this
by vidarh on Fri 4th Nov 2011 10:05 UTC in reply to "not sure if I like this"
vidarh Member since:
2011-10-14

While I have nothing against simplicity or change, I am not sure I like this. These folders were separated out for reasons.


Yes, they were, and the Fedora page addresses that. They were separated out to be able to boot before /usr is available. That can be easily taken care of by initramfs today, so there's no justification for keeping lots of stuff in /bin, /sbin etc. these days.

/usr has a long tradition of being for stuff that should be possible to mount read-only from a directory shared amongst multiple servers, so it makes sense to try to keep as much as possible of the system there.

Reply Score: 1

just don't 'finder' us
by stabbyjones on Thu 3rd Nov 2011 02:15 UTC
stabbyjones
Member since:
2008-04-15

As long as I can easily see the filesystem, organise it however you want. Like multiarch there are some valid reasons for doing thise.

/run caused enough controversy so why not just update everything?

Reply Score: 2

RE: just don't 'finder' us
by jabjoe on Thu 3rd Nov 2011 09:44 UTC in reply to "just don't 'finder' us"
jabjoe Member since:
2009-05-06

Luckily /run was an easy change. Imagine trying to change everything? You would never be able to and run everything, so you end up with the old system hidden away in the background. Is that simpler? I don't think so. You going to get everyone to agree to the new hierarchy so you can phrase out the old system? I don't think so, so you will be stuck with both systems forever. To be clean, you either do revolution and straight up front say you won't support old apps, or you do evolution and do incremental improvements.

Reply Score: 2

RE[2]: just don't 'finder' us
by sorpigal on Thu 3rd Nov 2011 11:36 UTC in reply to "RE: just don't 'finder' us"
sorpigal Member since:
2005-11-02

Indeed. And there's a lot of evolution to be had. I'd start by nixing sbin and games.

mv /usr/games/* /usr/bin/
mv /usr/sbin/* /usr/bin/
mv /sbin/* /bin/

And see how that strikes people. At this point in history these things make no more sense than /usr/X11/ did.

Reply Score: 2

Not good news and fortunately not final
by Sodki on Thu 3rd Nov 2011 02:18 UTC
Sodki
Member since:
2005-11-10

This is just a proposal, not a final decision, fortunately. A user doesn't have to know where the binaries are installed, everything he needs to execute in on his $PATH. On the other hand, the people that need to know the difference are called System Administrators and they know why the current separation exists. There are very good reasons for it.

Reply Score: 6

Delgarde Member since:
2008-08-19

This is just a proposal, not a final decision, fortunately.


Yes, and the OSNews doesn't make that clear at all. There's currently nothing more than a discussion of what would be involved and whether it would be a good idea - not a decision to go ahead and do it.

There's also separate two issues involved. One is the merging of bin and sbin directories, which is relatively uncontroversial. The second is removing all applications and libraries from / to /usr, and that's the subject of most of the argument.

Reply Score: 7

AdamW Member since:
2005-07-06

Yes, this is exactly correct. This is only a feature proposal. Anyone with a Fedora account can make a feature proposal; all the existence of a feature proposal proves is that one person with a Fedora account thinks something would be a neat idea.

It's not a Fedora feature unless it's accepted by FESCo after their review process.

Reply Score: 3

Yoko_T Member since:
2011-08-18

Yes, this is exactly correct. This is only a feature proposal. Anyone with a Fedora account can make a feature proposal; all the existence of a feature proposal proves is that one person with a Fedora account thinks something would be a neat idea.

It's not a Fedora feature unless it's accepted by FESCo after their review process.


God, I hope this is in fact the case. Fedora *DOES NOT* need a repeat of the Gnome 3 Disaster.

Reply Score: 1

v Yes!
by tuaris on Thu 3rd Nov 2011 02:19 UTC
Comment by Jason Bourne
by Jason Bourne on Thu 3rd Nov 2011 02:23 UTC
Jason Bourne
Member since:
2007-06-02

why not

/sys
/lib
/app
/user


better for typing !!

Reply Score: 6

RE: Comment by Jason Bourne
by boxy on Thu 3rd Nov 2011 03:31 UTC in reply to "Comment by Jason Bourne"
boxy Member since:
2011-06-20

why not

/sys
/lib
/app
/user


better for typing !!


Yeah, since the file-system is case-sensitive definitely go the path of least resistance and make the standard all lowercase.

I'd choose /programs and /users (plural) instead of /app and /user, respectively.

/sys already exists and is mounted as sysfs, so I'd choose /system as the actual os dir in order to not clash with the existing /sys. I'm guessing /selinux, /boot, /dev, /proc, and possibly even /tmp could then get moved under /os. You could also even move /sys (sysfs mount) under /os. All of these changes would, of course, initially provide appropriate symlinks for backwards compatibility.

/lib is an interesting folder since both /programs and /system would probably use components from it, and I don't see an easy way (nor a distinct need) to separate out system from program libraries, so I'd just move /lib and /lib64 into /system also.

I like the GoboLinux structure of retaining side-by-side versions for /programs and /system/lib, so I'd definitely keep that.

The layout would then be
/programs
/users
/system

You could also possibly have a folder like /media with /music, /videos, /tv, /books, /whatever-other-stuff in it, but you'd have to make it very clear to the user that this folder is shared by everyone on the machine (and/or optionally across a network, hopefully choosable at os installation).

Reply Score: 1

RE[2]: Comment by Jason Bourne
by sorpigal on Thu 3rd Nov 2011 11:34 UTC in reply to "RE: Comment by Jason Bourne"
sorpigal Member since:
2005-11-02

A discussion on building a better FHS would be valuable, if that's what you want to talk aout. That's pretty off topic, of course.

Any imagined new FHS would have to account for both "desktop" and "server" use. If you're moving things around you might as well stick /sys under your /system or /os directories; then there's no reason you can't say /sys for your new /system.

You have to look at how things go together. You want the same FHS to apply during initramfs as the final system (that's just easier) and you want booting to work when some parts of the filesystem are stored on NFS or otherwise available late. You need to have a plan for what the system looks like from single user mode and how recovery is performed. One nice thing about a read only / of a minimal size is that you can be pretty sure it's never going to be corrupt, even if your fancy btrfs /var or /home is. What are the recommended partitioning schemes in your Better FHS design?

Where does /home/ go? Where do packages which install to one big directory go if there's no /opt/? How do you distinguish between base-system components, optional components provided by the distribution, and locally-installed components provided by the sysadmin? What about programs installed by regular users? What are your replacements for /usr/share, /usr/include, /usr/share/doc, /var/cache/, /var/lib/ and /etc/init.d/? What do you do with /mnt and /media? What do you do with /lib/firmware/ and /lib/modules/? Remember that these things probably shouldn't be mounted from NFS.

If you're improving things, what about defining more structure for /var and /tmp? In fact, take a look at http://www.osnews.com/thread?327769 where I asked some questions like these before.

Here's a thought experiment I did a few years ago:

/ - contains:
/local/
/system/
/mount/
/cfg/
/home/
/tmp/

/system/ - contains
-- /boot/ - files required to boot the system
--- /exe/ - copies of the programs executed during boot (statically linked?) so that /system/exe/ can be absent
-- /exe/ - symlinks to (or otherwise a collection of) all executables that a user or another process might be expected to run (non-internal, think public methods)
-- /lib/
--- one directory per package
---- any non-portable (arch-specific) files not needing to be writable at runtime. These may be .so or may be executables, or anything. Think private methods.
--- /all/ - symlinks to (or otherwise a collection of) all system libraries. LD_LIBRARY_PATH points here.
--- /system/ - ld-linux.so, libc, etc. Libraries not provided by packages.
-- /share/
--- one directory per package
---- any portable (not arch specific) files not needing to be writable at runtime
-- /data/
--- one directory per package
---- any non-temp files that will need to be written to during a program's run time
--- /<package>/run/ - lock files and named pipes
--- /<package>/lib/ - ?
--- /<package>/spool/ - write queues
--- /log/ - log files
---- /user/<username>/ - user's log files? Perhaps symlink back to ~/.sys/log/?
---- /<package>/
---- /system/ - log files for things that are basic and not part of another package. Kernel and what else?
---- NO log files in /log/ itself.
-- /kernel/ - kernel virtual fs mounts
--- /sys/
--- /proc/
--- /dev/ - device files


/local/ - contains
-- /lib/
--- one directory per package
--- /all/ - symlinks to (or otherwise a collection of) all locally installed non-system libraries. LD_LIBRARY_PATH points here.
--- as with /system/lib/, so here.
-- /share/
--- one directory per package
--- as with /system/share/, so here.
-- does NOT contain /data/. Runtime data is runtime data, regardless.

/cfg/ - contains
--- /<package>/ - one directory per package
--- /system/ - configuration files for things that are basic and not part of another package
---- /paths/ - directory containing files describing paths by name. This will make sense.
----- home - contains the string "/home/" by default. This is used when computing a user's home directory.
----- mount - contains the string "/mount/" by default
----- dev - contains the string "/kernel/dev/" by default
----- basically, the local admin can change the base name of system directories by altering these files. Woe betide you if you make a typo.


/home/ - contains
-- one directory per user
-- /<user>/
--- /.sys/ - hidden directory containing all files and the only files in the users home directory which the user does not create himself
---- /cfg/ - all userland app config files go under here, dotfile or no, subdir or no
----- /<package>/ - programs SHOULD store their config data in a subdir named after themselves, even if it's only one file
----- investigate fd.o ~/.local/ and see if it's worth duplicating
---- /mount/ - user mounted filesystems (remote or local). Perhaps system policy can lock users out of mount privileges unless it is under this directory.
----- /net/ - mirrors /mount/net/ in structure. User-mounted network locations.
----- /disk/ - non-network mounts
----- instead of /local/ the user's naming policy is to have symlinks called whatever the user likes pointing back to net or disk directly. I think this is OK.
---- /exe/ - user's executables. This directory is in the front of the user's PATH
---- /log/ - log files for user's processes
----- /<app>/ - one directory per application, internal structure is up to the app


/mount/ - contains
-- Perhaps by policy nothing will be mounted outside of /mount/ and /home/$user/.sys/mount/. I think using symlinks is sufficient to make this OK.
-- /net/ - network hosts sorted by host name
--- /<hostname>/
---- /<some_export_name>/
-- /local/ - directories for mounts named however the local sysadmin likes. In reality anything can be mounted anywhere as needed, but this is the correct location for transiant mounts. might be symlinks to ../disk/*/*. NOTE: not just local devices! Local naming policy. Policy may be *described* in /cfg/system/ somewhere, but here is where those named links are created in fact.
-- /disk/ - local disks sorted by disk name (as found in /dev/). If something is mounted anywhere it is ALSO mounted here
--- /cdrom0/ - for example, the first cdrom device (device file: /system/kernel/dev/cdrom0)
--- /floppy/ - for example, the first floppy (device file: /system/kernel/dev/floppy)


I eventually gave up on this approach. Remember, please, that it's all about what problems you're trying to solve (and that with the FHS you have to solve ALL PROBLEMS).

Reply Score: 2

RE[3]: Comment by Jason Bourne
by JAlexoid on Thu 3rd Nov 2011 12:07 UTC in reply to "RE[2]: Comment by Jason Bourne"
JAlexoid Member since:
2009-05-19

I'd also add that all non-system software should be split off, so that it does not "pollute" the system directories.
I know that the best software package management tools have been created to deal with the mess, but they should be able to add a good option of cleaning up the scattered data that software packages tend to leave behind.

Reply Score: 2

RE[2]: Comment by Jason Bourne
by Jason Bourne on Thu 3rd Nov 2011 14:04 UTC in reply to "RE: Comment by Jason Bourne"
Jason Bourne Member since:
2007-06-02

Well,

I would choose /app and /user because it's definitely better for typing; it's a real pain when you have to browse manually file systems directories.

actually

/adm
/app
/lib
/med
/sys
/user
/var


Would do better, the new /adm to replace /root and /med in place of /media. we could keep /var and let /tmp inside it.

Anyways, any simplification of this current mess would be nice to have.

Reply Score: 2

RE[3]: Comment by Jason Bourne
by sorpigal on Thu 3rd Nov 2011 15:02 UTC in reply to "RE[2]: Comment by Jason Bourne"
sorpigal Member since:
2005-11-02

Why this fetish for /user instead of /home?

Try this experiment: Find some non-technical users and ask them: "If you're looking for your files are you more likely to click on a folder called Home or a folder called Users?" My experiments over the years have been about 70% in favor of "Home," pretty consistently too.

"Users" may be a technically correct classification of the directory, but users don't think of themselves as users.

Reply Score: 2

Might As Well Finish The Job
by softdrat on Thu 3rd Nov 2011 02:50 UTC
softdrat
Member since:
2008-09-17

Why not abandon directories entirely? Just shove everything into one big, disorganized, incomprehensible mess. Who cares if it confuses the heck out of users? It makes snapshotting easier.

Reply Score: 4

RE: Might As Well Finish The Job
by JAlexoid on Thu 3rd Nov 2011 11:33 UTC in reply to "Might As Well Finish The Job"
JAlexoid Member since:
2009-05-19

Just shove everything into one big, disorganized, incomprehensible mess.

Wasn't that the point of WinFS?

Reply Score: 3

big pile of crap
by bnolsen on Thu 3rd Nov 2011 03:03 UTC
bnolsen
Member since:
2006-01-06

i'd prefer seeing some things installed as packages but then someone has to decide what gets installed into the system and what gets installed as a bundle.

I just know that arch throws everything in /usr/bin and i frankly have a difficult time using a file browser to navigate into /usr/bin due to the long delay required to populate the browser.

Reply Score: 2

why not just /bin /lib
by kristoph on Thu 3rd Nov 2011 04:06 UTC
kristoph
Member since:
2006-01-01

Why does it need to go to /usr?

In the custom distribution I run on my servers I pul all packages in /pkg as in ....

/pkg/org.vendor/product/1.2.3

... I then symlink specific files into /bin and /lib.

(It's based off of Slackware so there is no dependency managed. Although there is a package remove mechanism I can usually just rm a pkg.)

]{

Reply Score: 3

RE: why not just /bin /lib
by bogomipz on Thu 3rd Nov 2011 07:35 UTC in reply to "why not just /bin /lib"
bogomipz Member since:
2005-07-11

Did you get rid of /usr entirely, like in http://sta.li/ or is it still there for /usr/include and /usr/share?

Reply Score: 2

RE: why not just /bin /lib
by sorpigal on Thu 3rd Nov 2011 11:09 UTC in reply to "why not just /bin /lib"
sorpigal Member since:
2005-11-02

Because directories are also containers and it's easier to mount /usr ro than /bin and /lib and /share, etc. It also makes selinux and apparmor policies easier. There are a lot of reasons worth considering.

Reply Score: 2

v Comment by ilovebeer
by ilovebeer on Thu 3rd Nov 2011 07:09 UTC
v RE: Comment by ilovebeer
by tupp on Thu 3rd Nov 2011 07:50 UTC in reply to "Comment by ilovebeer"
RE[2]: Comment by ilovebeer
by ilovebeer on Thu 3rd Nov 2011 15:17 UTC in reply to "RE: Comment by ilovebeer"
ilovebeer Member since:
2011-08-08

Exactly! That's why OSX and Windows are such pieces of crap.
...

Yeah, lamely hiding the underlying directory hierarchy and using a registry instead of addressing the root problem... oh, wait... that's what OSX and Windows do!
...


Yes, OSX should've just started with a completely new directory hierarchy, instead of using the established Unix hierarchy and hiding it beneath their lame hierarchy -- would've been some growing pains, but it would have been a better long-term solution.
/sarcasm
...

Why are you whining about Windows and OSX in a thread about a change in Fedora Linux? Regardless of what's done in Windows and OSX, the topic is Linux and what should be done there. If you want to soil about Windows and OSX, start a new thread.

Reply Score: 1

RE[3]: Comment by ilovebeer
by tupp on Thu 3rd Nov 2011 16:56 UTC in reply to "RE[2]: Comment by ilovebeer"
tupp Member since:
2006-11-12

Why are you whining about Windows and OSX in a thread about a change in Fedora Linux?

No whining -- just stating facts.

You made a vague, unsupported whine that Linux has "layered" fixes. My question would be: "Compared to what?" Which OS is did you have in mind that is different, and exactly why is it different.


Regardless of what's done in Windows and OSX, the topic is Linux and what should be done there. If you want to soil about Windows and OSX, start a new thread.

My friend, "Welcome to the Internet!"

Forum threads often grow and develop in unpredictable and interesting ways, and trolls do not determine the rules of what what is accepted as on-topic or off-topic.

Reply Score: 2

RE[4]: Comment by ilovebeer
by ilovebeer on Fri 4th Nov 2011 16:15 UTC in reply to "RE[3]: Comment by ilovebeer"
ilovebeer Member since:
2011-08-08

You made a vague, unsupported whine that Linux has "layered" fixes. My question would be: "Compared to what?" Which OS is did you have in mind that is different, and exactly why is it different.
In truth I made an accurate statement that is common knowledge and a view shared among many linux developers/contributors. Join the linux kernel mailing list and see for yourself. It's not as if I've just revealed how the Egyptians built the pyramids.

And, "compared to what?".. Compared to nothing, we're not talking about OS comparisons here. Start a new thread if you want to talk about that.

Edited 2011-11-04 16:16 UTC

Reply Score: 1

Why is this good?
by Soulbender on Thu 3rd Nov 2011 07:55 UTC
Soulbender
Member since:
2005-08-18

Soo...instead of putting more tools in / they move everything from / to /usr and put symlinks in /. Say what? Wtf? Might as well put everything in /bin and /lib then since it's pretty much what they're doing anyway.

The long-term plan is to clean up the mess and confusion the current split of / vs. /usr has created.


What confusion? Normal users don't care and those who do should know better than to be confused.

All tools will move back to /usr where they belong


Really? The belong under the cryptic path "/usr" rather than the straihtforward, and shorter, /?

Compared to today's setups, the rootfs will be very small.


Sure, you could say that but it's a moot point since you'll require /usr anyway . Come on, if you want to actually simplify this just move everything from /usr to /, since that's what they're effectively doing anyway, and just keep /usr/local.

The ability to share /usr is especially useful for clusters and virtual machines. The ability to mount /usr read-only (e.g. on read-only media) adds to the security of the machine.


Or if you moved everything to / you could just mount /bin and /lib read-only. Not really a big difference in practice.

less toplevel directories

Yeah, because moving them down one level makes a giant difference.

I dunno, it' s not like it matters a whole lot if it's /bin or /usr/bin but this change feels rather pointless and the arguments aren't that great.

Edited 2011-11-03 08:02 UTC

Reply Score: 6

RE: Why is this good?
by sorpigal on Thu 3rd Nov 2011 11:51 UTC in reply to "Why is this good?"
sorpigal Member since:
2005-11-02

Compared to today's setups, the rootfs will be very small.

I like how he says this even though it would actually be smaller by only 3 directories. You'd still have /boot, /root, /etc, /var, /usr, /sys, /proc, /tmp, /media, /mnt, /opt, /home, /dev. Did I forget any?

Come on, if you want to actually simplify this just move everything from /usr to /,

A proposal to do that was brought up and shot down earlier this year.

Edited 2011-11-03 11:53 UTC

Reply Score: 2

RE[2]: Why is this good?
by Delgarde on Thu 3rd Nov 2011 20:33 UTC in reply to "RE: Why is this good?"
Delgarde Member since:
2008-08-19

"Compared to today's setups, the rootfs will be very small.

I like how he says this even though it would actually be smaller by only 3 directories. You'd still have /boot, /root, /etc, /var, /usr, /sys, /proc, /tmp, /media, /mnt, /opt, /home, /dev. Did I forget any?
"

I think he meant small in the sense of filesystem size, not number of directories under /. And in a typical setup, half of the directories you list are empty, used only as mountpoints for other filesystems.

Reply Score: 2

About time!!!
by OSGuy on Thu 3rd Nov 2011 10:12 UTC
OSGuy
Member since:
2006-01-01

After Fedora, everyone else will follow...just watch! I truly support this move.

While this might go against the LSB and FHS...

Do we really care? The LSB and FHS are a mess when it comes to this so who cares? Do we really want to keep living in the past - 30+ years old rules?? The people in charge of LSB and FHS will have to think twice when everyone follows Fedora or we will just create LSB++ and FHS++ respectively ;)

Edited 2011-11-03 10:15 UTC

Reply Score: 3

RE: About time!!!
by ichi on Thu 3rd Nov 2011 10:22 UTC in reply to "About time!!!"
ichi Member since:
2007-03-06

After Fedora, everyone else will follow


First you'd have to wait for Fedora to actually approve that change.

Reply Score: 2

RE[2]: About time!!!
by OSGuy on Thu 3rd Nov 2011 10:42 UTC in reply to "RE: About time!!!"
OSGuy Member since:
2006-01-01

Well I hope they do ;)

Reply Score: 2

RE: About time!!!
by sorpigal on Thu 3rd Nov 2011 12:00 UTC in reply to "About time!!!"
sorpigal Member since:
2005-11-02

Do we really care? The LSB and FHS are a mess when it comes to this so who cares?

I think this is an important point that you and other supporters of this idea (and others like it) need to understand. I care.

Lots of people care. Just because you don't like, don't understand or don't want to deal with the FHS doesn't mean it isn't logical and valuable. It certainly isn't perfect, and many aspects of it could be improved, but you can't just throw it out. You must understand it and love it before you can hope to improve upon it.

You complain about being bound by 30-year-old rules, but in fact that's not necessary. The FHS hasn't been updated lately but it could be. If you actually have a way to improve it and you can get some consensus you can get it changed. I believe there are people looking at an update now if for no other reason than to add the much-needed /run directory. If you think other changes are valuable go forth and conquor!

Reply Score: 4

A half baked idea
by sorpigal on Thu 3rd Nov 2011 11:08 UTC
sorpigal
Member since:
2005-11-02

Let's see...

no plan for /boot
no mention of /usr/sbin
apparent ignorance of the usefulness of the root usr split

So let's review. Someone who doesn't know the FHS, much less understand the FHS, thinks the FHS was created purely to be sadistic and decides he wants to just slap things together because "It will be simpler." No rational justification given as to what the benefit is. Attempted justifications don't hold water: Read only /usr? Already supported. Simpler to package because we don't need to split things up? A tiny cognitive gain which doesn't hold up against the loss. I hope the Fedora project rejects the proposal as it stands.

Don't get me wrong, the FHS seriously needs updating and a lot of improvements could be made... but this proposal is a half-baked joke.

Reply Score: 4

RE: A half baked idea
by Soulbender on Thu 3rd Nov 2011 14:30 UTC in reply to "A half baked idea"
Soulbender Member since:
2005-08-18

no mention of /usr/sbin


I think he wants to move sbin to bin. Why? dunno.

Read only /usr?


Yeah, that was kinda funny. Does he really think that we can't mount /usr read-only today and that it can't be shared over NFS already? Seriously? Been living under a rock long?

Reply Score: 2

RE[2]: A half baked idea
by sorpigal on Thu 3rd Nov 2011 15:03 UTC in reply to "RE: A half baked idea"
sorpigal Member since:
2005-11-02

Actually sbin -> bin makes sense. There's really a very limited usefulness to that distinction at this point in history.

Reply Score: 2

RE[3]: A half baked idea
by Soulbender on Thu 3rd Nov 2011 16:21 UTC in reply to "RE[2]: A half baked idea"
Soulbender Member since:
2005-08-18

There's really a very limited usefulness to that distinction at this point in history.


Perhaps but I like that daemons goes into sbin because, really, how often do you need to run a daemon from the command line? They'll just be needlessly cluttering bin, which is already badly cluttered after you install a DE.
Maybe Linux (and more software) should adopt libexec for binaries that are almost never used by users directly.

Reply Score: 2

RE[2]: A half baked idea
by phoenix on Thu 3rd Nov 2011 17:16 UTC in reply to "RE: A half baked idea"
phoenix Member since:
2005-07-11

If you read Lennart's postings on fdo, he advocates against /usr being a separate filesystem, and he actively breaks it in systemd (you can't use systemd if /usr is a separate fs). The justification? Some packages are broken and install files into both / and /usr, therefore /usr needs to be part of / in order for boot to work. Uh, what? Instead of fixing the 2 or 3 broken packages, you want to break the entire boot process that's worked for 30-odd years?

Perhaps it's time for Fedora to drop "Linux" from it's name, and to stop pretending to be a Linux distro, and just go off and do it's own incompatible things, and leave the rest of the Linux/Unix world alone. Between PusleAudio, SystemD, breaking /usr a separate fs, and now this proposal, they basically already have.

Reply Score: 2

RE[3]: A half baked idea
by Delgarde on Thu 3rd Nov 2011 20:38 UTC in reply to "RE[2]: A half baked idea"
Delgarde Member since:
2008-08-19

he actively breaks it in systemd (you can't use systemd if /usr is a separate fs).


Completely false - systemd has no problem with having /usr on a separate FS, and never has. Other parts of the boot may stop working (which is why systemd prints out a warning message), but systemd itself will work fine.

Reply Score: 2

RE: A half baked idea
by Soulbender on Thu 3rd Nov 2011 16:44 UTC in reply to "A half baked idea"
Soulbender Member since:
2005-08-18

Another odd argument: it makes snapshot'ing /usr easier.
Why do you need to snapshot /usr? It contains no variable data and it almost never changes.

Reply Score: 2

RE[2]: A half baked idea
by darkcoder on Thu 3rd Nov 2011 16:53 UTC in reply to "RE: A half baked idea"
darkcoder Member since:
2006-07-14

First, I never said in my previous post user. I said admins and programmers. For the normal Joe, it will be transparent. If you use synaptics, yum, pacman, Ubuntu One, it doesn't matter. Users don't deal with complexities, users don't think in other than browsing, chatting, making docs.

Backing up an /usr folder with everything is far faster, and reliable than other methods like anaconda kickstart. Kickstart take a list of packages installed on your system, and while it works, what happens if the day you need to restore your system, you also have a ISP problem which will prevent you from downloading the packages. Also, does that app works with manually installed sources or packages? Does every distro has a kickstart like feature???

Backing up your system locally is the safest, fastest way to go. Those suggestions where made primary thinking on that purpose.

Reply Score: 1

RE[2]: A half baked idea
by Delgarde on Thu 3rd Nov 2011 20:40 UTC in reply to "RE: A half baked idea"
Delgarde Member since:
2008-08-19

Another odd argument: it makes snapshot'ing /usr easier.
Why do you need to snapshot /usr? It contains no variable data and it almost never changes.


Never changes - except when you install patches. Taking snapshots of /usr before installing system updates gives you a rollback option in the event of something going wrong...

Reply Score: 2

Does anyone know?
by JAlexoid on Thu 3rd Nov 2011 11:51 UTC
JAlexoid
Member since:
2009-05-19

Does anyone know, is there any effort to have software installed similarly like ROM image?
- Software package defines what it provides and what it needs
- Software package is stored as a self contained single file containing all components (a loopback mounted ISO is you will)
- The configuration is stored in user's home or /etc for system

I like how Android apps work in that regard. They fulfil a lot of these requirements.

Reply Score: 2

RE: Does anyone know?
by sorpigal on Thu 3rd Nov 2011 11:55 UTC in reply to "Does anyone know?"
sorpigal Member since:
2005-11-02

Yes, this has existed for years on Linux and is called Klik. See http://en.wikipedia.org/wiki/Klik_%28packaging_method%29

Reply Score: 2

RE[2]: Does anyone know?
by JAlexoid on Thu 3rd Nov 2011 12:14 UTC in reply to "RE: Does anyone know?"
JAlexoid Member since:
2009-05-19

Is it similar to Mac DMG? Or does Mac OS actually unpack something out of DMG?

Reply Score: 2

RE[3]: Does anyone know?
by sorpigal on Thu 3rd Nov 2011 12:15 UTC in reply to "RE[2]: Does anyone know?"
sorpigal Member since:
2005-11-02

Mac OS unpacks somethnig out of the .dmg file. For Mac OS each application is a directory named Whatever.app and finder hides the extension then treats it differently. Something like that is also possible under Linux, if you want to do that take a look at the Rox desktop.

Reply Score: 2

Comment by greygandalf
by greygandalf on Thu 3rd Nov 2011 12:07 UTC
greygandalf
Member since:
2008-04-07

Why is this good news? More mess? The "end-user" shouldn't even care where his binaries are. The one who uses a console instead, will appreciate the distinction between bin and sbin, between system stuff and user stuff.
Somebody called Linux a watered down version of Unix. He was an optimist.

Reply Score: 2

The easiest solution to this mess
by twitterfire on Thu 3rd Nov 2011 13:20 UTC
twitterfire
Member since:
2008-09-11

The easiest thing to do is:

#umount /dev/sd0 && mkntfs /dev/sd0 && shutdown -r now

Reply Score: 1

sorpigal Member since:
2005-11-02

Don't be vulgar.

Also, even as root your umount command will fail.

Reply Score: 2

twitterfire Member since:
2008-09-11

Don't be vulgar.

Also, even as root your umount command will fail.

Forgot
#mkdir -p /mnt/ram && mount -t ramfs -o size=2048m ramfs /mnt/ram && cp -r / /mnt/ram && chroot /mnt/ram

Reply Score: 3

sorpigal Member since:
2005-11-02

Probably you want pivot_root, actually.

Reply Score: 2

Why not do it the right way?
by twitterfire on Thu 3rd Nov 2011 14:57 UTC
twitterfire
Member since:
2008-09-11

Both this approach and the Gobo Linux approach have some disadvantages attached. Why not do it the right way? Like Hannah Montana Linux distribution does it?

For more info of the file system hierarchy see: http://hannahmontana.sourceforge.net/Site/Home.html

Reply Score: 2

axilmar
Member since:
2006-03-20

And it must be abolished.

Each application must reside solely in its own folder.

Shared libraries must be merged and reference-counted by the filesystem. For example, if the library 'foo_1_0.so' is in directories 'bar1' and 'bar2', the filesystem should keep only one copy of the library and link it to both directories, with a reference count = 2.

Reply Score: 2

phoenix Member since:
2005-07-11

Sounds similar to how PBIs work in PC-BSD 9.x.

Reply Score: 2

scripts?
by jweinraub on Thu 3rd Nov 2011 16:10 UTC
jweinraub
Member since:
2009-06-22

What about scripts? Quite a few of my scripts I give the full path, and at times relative paths to certain programs/files/etc.

Heck, even the interpreter itself, /bin/sh following the shebang symbol. Wouldn't that screw things up? Are they intending to keep the legacy system in place by using symlinks so nothing screws up along the way?

I am all for change, when change is necessary, but honestly, I am so used to /sbin/ifconfig and the current location of things, I rather not relearn. At least I am more of a Debian user, so I hope they don't change. Though a lot of my endusers seem to like Fedora, and I get people liking Ubuntu for some reason, but at least it is a Debian flavour.

Reply Score: 2

RE: scripts?
by darkcoder on Thu 3rd Nov 2011 16:20 UTC in reply to "scripts?"
darkcoder Member since:
2006-07-14

In the sugested Plan, they suggested making symlinks that will keep compatibility.

/
|-- etc
|-- usr
| |-- bin
| |-- lib
| `-- lib64
|-- run
|-- var
|-- bin -> usr/bin
|-- sbin -> usr/bin
|-- lib -> usr/lib
`-- lib64 -> usr/lib64

Reply Score: 1

My Opinion
by darkcoder on Thu 3rd Nov 2011 16:31 UTC
darkcoder
Member since:
2006-07-14

Changing the hierarchy of the system can be a good thing for admins and programmers. Anyone that has worked either in packaging, fixing packages, programming in Linux knows that the current hierarchy just sucks. Many programs when directed to install in /usr directory, actually store its configuration in /usr/etc instead of /etc. Take a deep look in Arch or Gentoo how many packages they have to sed fix for that.

I suggest a little more drastic change and also storing the /etc directory in /usr. That way, if an admin backup /usr, everything will be backup at one: system programs, configuration, locally installed programs, everything.

In terms of security, a revision of user/group access policies must be made in the whole tree to make sure no compromises are made. But a note: most security breaches are made by lazy admins that give way too much access (root access, shell access), instead of security within files or directories.

Also about dir names, if the whole system is placed under /usr, it will make that name kind of void. A new name like /system, or /os should be used instead, with sysmlinks for compatibility.

Reply Score: 1

bin and sbin can be merged
by darkcoder on Thu 3rd Nov 2011 18:58 UTC
darkcoder
Member since:
2006-07-14

But I think that /bin and /sbin can be merged. Because:
1. Both are need for the basic system to start.
2. While /sbin are supposed to be root only tools, it's path is included in every normal user in most if not all linux distros.
3. Any /sbin app that require root these days has the requirement implied in the binary itself (attributes, selinux/apparmor rules)
4. Some /bin programs sometimes require /sbin progs for certain operations.

That will help with a lot of scripts since some distros have some progs in /sbin while others have it in /bin.

Edited 2011-11-03 19:01 UTC

Reply Score: 1

OS X and GoboLinux got it right
by sicofante on Fri 4th Nov 2011 00:44 UTC
sicofante
Member since:
2009-07-08

I don't know exactly what the problem is with these two systems, but I find them very easy to use, very logical and much more functional.

Just keep the symlinks there -and hidden- for a transition period (two to four years, I dunno). Then remove them.

Reply Score: 1

Simplify
by filletofspam on Fri 4th Nov 2011 21:26 UTC
filletofspam
Member since:
2008-04-04

Wouldn't it be simpler to get rid of /usr?

How about:

/bin: All programs
/lib: All libraries
/etc: All configuration files
/home: All home directories
/var: All log files
/stand: Stand alone programs (kernel, diags, etc)

If you insist on a directory for 3rd party apps

/opt: with bin, lib, and etc below

Edited 2011-11-04 21:31 UTC

Reply Score: 1

RE: Simplify
by cjcox on Fri 4th Nov 2011 23:08 UTC in reply to "Simplify"
cjcox Member since:
2006-12-21

You make the same point I tried to make to Lennart. The idea of a useless indirection (usr) seems silly. The problem isn't /bin, /lib, etc... arguably, the problem is /usr. However, changing that WOULD have greater impact. I look at what Red Hat is proposing (yes. Red Hat) as being a quick and dirty way to get around problems inherent with restructuring init in their way (systemd). Sure... it make life easier for them... but perhaps it's not really making things "better".

So... not arguing against "better".. just saying this really isn't about "better".. it's about "easier". For now anyhow...

systemd... it keeps growing and growing and growing...

Reply Score: 1

This looks very convincing
by darkcoder on Mon 7th Nov 2011 15:09 UTC
darkcoder
Member since:
2006-07-14

I found an in-deep explanation of why they are looking to change the filesystem layout.

Most of the failures you will experience with /usr split off and not pre-mounted in the initramfs are graceful failures: they won't become directly visible, however certain features become unavailable due to these failures. Quite a number of programs these days hook themselves into the early boot process at various stages. A popular way to do this is for example via udev rules. The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices. Here's a short, very in-comprehensive list of software we are aware that currently they are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, the locale logic of most programs and a lot of other stuff.

You don't believe us? Well, here's a command line that reveals a few obvious cases of udev rules that will silently fail to work if /usr is split off and not pre-mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* -- and you find a lot more if you actually look for it. On my fresh Fedora 15 install that's 23 obvious cases.


More info about it here <a href="http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-br...

Edited 2011-11-07 15:10 UTC

Reply Score: 1

Comment by zima
by zima on Wed 9th Nov 2011 23:08 UTC
zima
Member since:
2005-07-06

Whoa, quite a nerd rage above ;p ...and, ultimately, this probably doesn't matter that much. OS uptake hardly seems dependant on their fs hierarchy; the widespread ones appear fairly "good enough" for those who need to really work with them - and too complex (NVM "uninteresting") for too many average users, either way.

Edited 2011-11-09 23:09 UTC

Reply Score: 2