Slashdot Mirror
Fedora Aims To Simplify Linux Filesystem
jfruhlinger writes "Even Linux's most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users. The developers at the Fedora project want to cut the Gordian knot and consolidate all executables into /usr/bin and all libraries into /usr/lib or /usr/lib64. One downside: this system would conflict with the standards developed by the Linux Standard Base, or the (rarely used) Filesystem Hierarchy Standard."
The one thing that baffles my mind is that Linux filesystems still don't offer compression of specific folders or files. Seriously, Windows has had this for over a decade. There's a few experiemental filesystems that can compress the whole partition, but still not individual files. Why doesn't Linux have such a simple but important filesystem feature? And no, I don't want to make an archive file, because I want to access those files and folders while they are compressed.
Finder on Mac OSX hides all important standard Unix directories such as /etc and /usr, and /home is also empty; users are found in /Users.
This makes Finder pretty useless and stops any users learning about the true directory hierarchy.
I can see the move to simplify the filesystem as great for newtime users, but it isn't actually that bad as it currently is with lib64 and lib and everything else.
Why fix what is not broken?
Don't break it. You'd think they'd want to get rid of lib64 first, since 32-bit libs on 64 bit systems will fade into obscurity sometime soon. It's only really proprietary software compiled for 32-bit libs that uses it anyway so just shove everything into /lusr/lib
maybe /sbin and /bin and /usr/sbin can be consolidated into /bin but i'd definitely leave /bin and /usr/bin separate because at least you'll have a system that kind of works with just /bin if the /usr partition goes missing
But I'd like to still have a conceptual difference between /usr/bin and /usr/local/bin; Perhaps support local, but mirror it's contents into /usr/ using symlinks.
I want to be able to install software from source, then wipe it all in one fell swoop if I'd like, which could be done with a mirrored /usr/local.
Just store everything in /
What could be simpler?
Uhh, I want my stuff separate from system stuff. I want to be able to back-up my stuff without including standard stuff.
System essentials should be in /bin. Non-essentials in /usr/bin, and my stuff in /usr/local/bin.
Fedora has jumped the shark.
Why not standardise on /Program Files/ and /Windows/System ?
The developers at Fedora can do whatever the heck they like. Pat knows what he's doing, and that's good enough for me.
Stick Men
Another reason not to use fedora. I hate how they're moving away from standards. Or even just unix traditions. /bin and /usr/bin? Who are these people looking for files constantly.
Also, does anyone really have a problem finding something in
This is bikeshedding.
As a "most passionate partisan" I will not admit that its filesystem is "baffling to users". With most binaries in /bin, /sbin, /usr/bin/, and /usr/sbin ... what is the problem? Windows has its binaries in thousands of locations ... and it isn't "baffling to users" is it?
Who doesn't want to delete all the files in the etcetera directory, if it was important they would've given it an important meaningfull name.
because i can never remember that FS1= whatever thing you use for bash when writing 'find' scripts
Now, for those who did not know, there's no Gordian Know. It's Gordian Knot.
I am sure all 20 Fedora users will be excited!
I was a long time user of Slackware before switching to FreeBSD about three years back. One of the reasons why I used Slack for ....mmm.. 15 years.. was that Slackware put most things where they should be unlike what I saw happening with the various RedHats, Debians, etc. These guys would do better to clean up their own act before trying to hose everyone else because they think putting everything in the kitchen sink is "simpler".
Just stash the real stuff in those directories, and have a way (i.e. add/remove feature) to create / destroy symlinks in those legacy places. Then, after years of nobody using those "features", you can remove them.
Fedora team needs a history lesson as to why there's 4 different bin file locations. They actually make quite a bit of sense, throwing them all into one is stupid.
I think it's important to realize why the four directions /bin, /sbin, /usr/bin, /usr/sbin exist (and similarly why /lib is separate from /usr/lib).
The reason is that once upon a time discs were small, so that /usr would be mounted separately from the root partition. So /bin and /lib are small directories containing as much of the operating system as you need to get going before you mount /usr and get everything else. In particular, this means the utilities needed to mount those other filesystems and to fix errors in them (e.g. fsck).
The separation between /usr/bin and /usr/sbin means that ordinary users don't have system programs (those from /sbin) in their search path.
Today most installations have the whole system (/ and /usr) on the same partition and it seems that many users use a GUI rather than a terminal. This means that the separation is not needed.
Note that this change is not about multiple-architecture situations like /usr/lib and /usr/lib64. It's about the separation between /lib and /usr/lib (or /lib64 and /usr/lib64).
most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users.
Isn't that [directories] what filesystems are to provide, so things can be well organized ?
Calling them, current UNIX/Linux filesystem hierarcy, "arcane", baffles me. Unless you're Poettering, of course. There is a good reason for things to be where they are, and, due to recent increase of embedded systems, a much more valid reason to split different levels of files across different filesystem hierarchies (read /bin vs. /usr/bin).
I can accept complains about "/opt" and "/usr/local" - they might not make much sense nowadays, but if you happen to need to bootstrap from a read-only 8Mb flash device, and need to have a somehow working system before you access some external data,
or
you have a huge shared filesystem where a few servers rely upon, and you don't want to replicate all system files,
then I see no reason at all to change this.
Actually, perhaps increasing the diversity of directories might come in handy (like in /usr/i686/lib + /usr/x86-64/lib + whatever you might need, and with eventual optimizations, and with eventual debug).
Or is this discussion only about directories which reside on the root of the filesystem ?
the file system hierarchy makes perfectly good sense -- the absolute basics are in /bin, distribution/system stuff is in /usr/bin and anything that an administrator installs for that particular box is in /usr/local/bin. Substitute sbin for sysadmin-y binaries. I guess maybe it doesn't matter as long as it doesn't take off, since I can just not use Fedora ever again, but frankly I like things just they way they are. The weird places that Ubuntu stashes things is already enough of a hassle when you have an extremely heterogeneous environment like I do at work.
AC is Insightful and Informative.
Give me Classic Slashdot or give me death!
As a kindly reader, I'd even put in a note for the editors whilst it was in the firehose queue that this should be "Knot". Not really a major typo and the editors can't be blamed for not reading all the comments, but it'd be good if more people DID pre-screen the submissions and enter USEFUL corrections so that the quality can be improved.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Can't take a hard drive built with LVM and migrate it to another machine with the same name -- i.e. a common operation after a hardware upgrade. I suppose it is possible to rename the logical volume, but this is fairly arcane, and why should I have to do this? ext4 offers no such impediment.
Dog is my co-pilot.
What users should care about where binaries go? Really, which kind of users are baffled to find several binary directories?
I bet that most that do, understand simple concepts such as $PATH, which and are probably able to deal with there being multiple directories.
I can see how this could be beneficial for installers and could help package maintainers that port from one distribution to another. Maybe Linux Standard Base already addresses this and this is only a moot point. This is only good if everybody does it equally anyways, or you will be just another distribution making things their own (different) way.
Is it really that important to consolidate binaries and libraries? I find other things like networking configuration and boot process, init scripts or inittab to be more confusing to system administrators, for example. But binaries?
Why not work on having _persistent_ system setup (like boot process, networking, config files, etc) work as universally as other tools such as ip/ifconfig. Imagine doing package search nmap and have it translate into apt-cache search on debian and yum search on fedora or CentOS. Or "network eth0 192.168.20.3 gateway 192.168.20.1": would write the corresponding /etc/network/interfaces on debian or /etc/sysconfig/network under redhat-based distros. Now THAT would be great.
Everything which works towards being not distro-specific is great, but IMHO you get that through abstraction. Not by saying "no, THIS is the right directory to put things in, I am right and everyone should do it the same way".
It's probably much more easily said than done, but that's how I see it.
Rather that move things around, how about use "union" filesystem to present an optional different view of things. Heck, you could use chroot and union fs to create a completely different singular view of the same file system to different users..
There are reasons things are as they are, and mucking about with something so fundamental because it 'confuses some newbies' isn't a valid reason.
Newbies can learn. Disasters are hard to undo. Leave things be.
---- Booth was a patriot ----
https://en.wikipedia.org/wiki/GoboLinux
forget /usr, just do /bin /dev /etc /home /lib /media /proc /root /sbin /sys /tmp /var
Politics is Treachery, Religion is Brainwashing
Putting everything under C:Windows and C:Windows/system turn out to be the way to go.
First, this makes some setups a lot more annoying. The /bin and /lib dirs might be rather obscure these days, but the separation still comes ocassionally handy with strange disk layouts.
Second, since when do normal users need to care about the distinction? All those are in $PATH anyway, so it doesn't matter whether bash is in /bin or /usr/bin for most end user purposes.
Third, what's with the weird obsession with messing with what works? Ubuntu is annoying enough already with the upstart thing. I don't need more stuff like that. Please leave the base system the hell alone.
why put the executables in a directory called bin ?
its not 1980
how about making the filesystem a bit more intuitive, call it "Programs" or "Applications"
the file system layout is one of the worst things about Linux, we have had long file-name support in "other" OSs for years, yet Linux insists on put things in ridiculous cryptic directory names /usr /bin /etc ?
gotta be some kind of joke that in 2011 thats the best linux can do
A
Although this proposal sounds reasonable at first, actually implementing it is troublesome. Linux systems have an expectation that the root directory / and the /usr directory may be on different filesystems; thus /bin is expected to come with / and be available at boot time, where /usr may not be. This means that making /bin -> /usr/bin via a softlink would break that.
Although the article summary claims that the Filesystem Hirearchy Standard (FHS) isn't used very often, some distributions such as Debian actually do try their best to follow it and even have it as one of the specs for how to build packages. Debian developers discussed the idea of trying to follow Fedora in this proposal, but it looks like it's too troublesome to be worth it. For one thing, all of the filesystem recovery tools or anything else that would be required in an emergency at the command line would need to be built into the kernel initrd images, which could be done but which doesn't seem terribly reasonable.
As such I think most Linux distributions are going to need to wait and see how well it works out for Fedora on this effort.
There isn't a space-saving methodology in the world that's more cost effective than slapping another terabyte into the rack.
Provided you have a rack. Adding another terabyte to a laptop or tablet means carrying around a relatively bulky USB hard drive and powering it somehow.
Did you mean "Gordian knot?" It would be nice if you proofread. Ever. At all.
Just a few actual facts to note here:
a) This is currently just a proposed feature for the next Fedora release. It's been discussed some on the Fedora devel list, but thats it. It's not yet been discussed by the Fedora Engineering Steering Comittee or even answered all the questions presented by the list. So, nothing is sure yet here, it's just a few folks proposing it at this time.
b) The feature page is at:
https://fedoraproject.org/wiki/Features/UsrMove
It had a lot more info and questions on it.
We will have to see how this plays out, it's way to early to tell, IMHO.
http://www.gobolinux.org/ Combines executables and necessary libraries each in their own directory under '/programs' Uses links to show files in traditional places.
Why is everyone talking about compression? Seriously, that isn't the topic or something most Linux really give a damn about.
Now, reorganizing the system so the files are arranged in a more logical fashion? That is great and something I have been waiting for 15 years! I understand the desire to maintain a degree of similarity and do things they way they have always been done, but directory structure on Linux is ridiculous for most users. This is one reason I would prefer a different OS version for desktop and server. I can see why the existing structure is used for servers, which can have hundreds or thousands of users accessing the same files, but most desktops have one or maybe two users.
Yeah, this means I have to learn a new system, after sticking with the RH way of doing things since the 90s, but if it is a BETTER system, a more simple system, then it would be worth the pain.
Tequila: It's not just for breakfast anymore!
Not surprisingly this move is being championed by Lennart Poettering. The same guy who thinks POSIX is a waste of time and said mounting /usr as a separate partition is stupid. It's no shocker he'd want to move all executables to /usr and dump standard directories like /bin and /sbin
This makes sense to me. All those extra directories had historical reasons but time marches on.
Precisely. Some people have too much time on their hands.
Someone had to do it.
It is well-specified. There's a folder for executables, a folder for binaries, a folder for configuration data, a folder for temporary stuff. And its layout hasn't changed for 20 years.
Compare it to Windows, where the file system layout changes from one Windows version to the other, there are no documents specifying most of its organization, and it doesn't matter anyway, because since Windows NT the file system is meant to be only managed by automated installation tools, and even an expert user can not hope to fix it when things go wrong.
What's wrong with /bin and /lib ? They serve a specific purpose, and the files they contain shouldn't be directly handled by a user who gets confused because of the presence of more than a single directory in his $PATH, so who will gain from their "semplification"? Don't tell me the real reason is that Fedora's next-generation self-aware omniscient init system has grown so complex that they're no longer able to support a split /usr installation because of its dependency hell.
Please do not turn Linux into an unmanageable mess as the one Windows has become.
End of rant
At least on a basic level, I get the Linux filesystem, but I do think it's a little silly. Things are pretty fragmented, sometimes arbitrarily, and the names don't make any particular sense. Like storing settings in a folder called "etc"?
I know the conventions have been around for a long time, but I think at a certain level it makes sense to start fresh and come up with a new standard that actually makes sense, and not just stick with old conventions because they're hard to change. Surely they can come up with a directory structure that satisfies technical needs while still making sense to novices and end-users. Unfortunately, it's going to be nearly impossible to get consistent adoption by various unix/linux vendors of any new conventions you come up with.
Even Linux's most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users.
man hier
And, if you're lost,
man man
Plus, it has nothing to do with Linux (my advice applies to *BSD — Mac OS X included —, Solaris, QNX... just to cite a few)
Now if you can explain to me what is in C:\Windows or \\HK* ...
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
First, in a modern Linux system you don't bother if the executables are in /bin /sbin /usr/bin or /usr/sbin or even /home/marvin/bin. You start the programs from a menu or quick start buttons (or how ever your UI has named its buttons).
A really cool thing today would be a set or class based file system. You could also call it tag based or attribute based system. Instead of only having hierarchies (which you still can model) you can group things by other purposes. For example, Alice have an incoming mail. In that mail Bob asks her to read and comment on a document. Now Alice reads that mail, but as it comes she does not have time to read the attached document ('business plan') just right now. She wants to process the rest of the incoming mail first and triage the different tasks. So first she tags the file with 'todo' and the todo list tool will show the file. And the tool would know that the file is associated with the email from bob. She could even mark the task as important or more important than other stuff. Or she could set a delivery date mark, like a event in a calendar. The mail itself is automatically moved from incoming to the set of mails from bob and it is viewable in the todo set/folder under "business plan" or "bob/business plan".
When the mail is processed she fetches the first task from the todo list (fortunately it is bob's business plan) and she reads it. After reading it half way through, she requires additional information to verify the plan. So the plan goes on hold again. Then Alice associates these additional infos to the "business plan" and forwards everything to Claire. Claire than adds her insights to the plan and the extra info. She even adds more data and sends it back to Alice.
Alice has now one file in incoming from Claire, a mail from Bob, a set of additional data and the business plan in a task. She now finishes the corrections and adds comments and sends Bob the resulting document.
Bob gets the file. However, he cannot understand some of the comments as they relate to the additional data Alice omitted. Now Alice has three mails in that task. She selects reply and adds from the task set, the required data and sends that to Bob.
This is the way people will work in future. To do so we need non hierarchical file systems. The gnome journal (zeitgeist) or the nepomuk project go in that direction. However, they implement all that stuff on top of the file system. It would be better to have all that in a database/file-system which provides the necessary features by itself.
Guess which bug I hit when trying to build my Linux 3.1.0 kernel from the gzipped file, the one where if there are more than 16K entries some symlinks get hosed using the usual gzip included in many distros. (yes, there is patch). Now that is probably the most used compression algorithm in the open source world, and it had that long time issue that now cropped up with the massive amounts of files in kernel. And you want to trust your filesystem to some such thing with perhaps other bugs to crop up on massive amounts of internal files? no thanks, filesystems need to be rock solid.
Subj. Where are these "Standards"?
Unix traditions? Do you feel SCO Smell? Or maybe *BSD? Or maybe HP-UX? AIX? SunOS? Mac OS X?
What we have here:
- Difference in init (noSysV, SysV, launchd, etc)
- Hell, difference in packaging or not true packaging, usually pure old-fashioned (AIX additionally has RPM, thanks)
- sysconfdir (/etc) mess everywhere
- No stable solution for labeling/access control (Like Selinux/apparmor)
- Hell knows where are my files/FHS inconsistency
- Patched OSS software
Same applies to most of the non-RPM Linux distros as well.
Usually changes in Fedora are done according to standards like LSB, FHS etc: /etc/sysconfig - you don't change things in /etc/init/* /etc/*.d/ - just add water
- Upstream software is used, only generic patches, no serious changes, contribution is done in upstream, not in distro only (normal OSS way, not like in Ubuntu)
- Fedora changed it's init process SysVinit -> upstart -> systemd
- In sync with updated kernel for functionality (Systemd is compatible with cgroups, easy process control/accounting), of course sometimes it's bleeding edge SW and needs to follow next release in order to use it completely, but at least you are part of it and prepared
- RPM heaven - easy build, RPM -V checks, no extra files, FHS consistency, LSB, compatibility with PackageKIt
-
-
- Same will be done in RHEL6
Personally, I don't think there is a difference for me where files are located, in /bin or /usr/bin or sbins. For me generic file permissions, security and SELinux controls access to them, not the path.
I use Fedora.
BTW, bad way from Mac OS X: /private/etc/ /private/tmp/ /private/var/ /home - empty /net - empty /cores - empty /opt - empty
-
-
-
-
-
-
-
Uppercase structure (why didn't they move it to /Mac or something like this?) /Volumes /Users /System /Network /Library /Developer /Applications
-
-
-
-
-
-
-
Yes, it's all build with standards, sure.
"It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
Seems like a tiny tweak when a giant overhaul might be better.
The filesystem tweak most needed, though, is to stop dumping config stuff into ~ and instead put it in ~/.config (or better yet, ~/config).
Also, wouldn't lib/x32 and lib/x64 be better than lib and lib64?
Leave it as-is, work on actual things that make Linux confusing. See Mac OS X...the same/similar directory layout exists there and normal users are oblivious to it, as they probably should be.
I'm more worried about the loss of sbin (and /usr/sbin) where, although its purpose has morphed over time, it's a great place to put exes that you're NOT supposed to type on the commandline. Like cronjobs, scripts that are called by other scripts, or simply stuff that users shouldn't use or want cluttering their path.
Incidentally, these guys have taken it WAY further:
http://www.gobolinux.org/
I wrote my first program at the age of six, and I still can't work out how this website works.
Why not put the libs into /lib where they belong and boot all libraries out of /usr? While we are at it, all the lib64 stuff could easily have a subdirectory (i.e. /lib/lib64).
While we are at it, can we get rid of the following TLD's? /media: /mnt made sense /misc: what is this even supposed to be used for? /net: not even part of the official standard. /srv: officially there still is no consensus on how its meant to be used, plus its main uses (httpd, databases) were fine in /var /selinux (Im sure you can find a place in /usr for some of it, most of it looks like it belongs in /etc anyway)
Sorry to sound "get off my lawn"ish but it all comes across as unnessecary polution to me and we really did get along fine before all these.
Make SELinux enforcing again!
This, bizarrely, reminds me of an article on feminism, and how, having won the major gender inequality battles, they're starting to pick silly fights where a rational person would see no fight to pick.
I think something similar is happening here, and with Ubuntu's Unity and maybe GNOME 3 as well. Having achieved a big chunk of what they set out to achieve, they start looking for the next big goal, but there's no next big goal to be found, so they just invent something utterly ridiculous. The file system is fine, just leave it be. All the newbies need to know about is their home directory, and those who need to know about the entire file system are perfectly fine with how it's currently laid out.
That '->' in here? That means a symbolic link (ln -s) ...
I think this guy forgot to read his own diagram... if /bin is symlinked to /usr/bin, the scripts will work perfectly fine. This article is a little stupid, imho. In all fairness, the guy does realize that there are workarounds, but this paragraph and the one after talk about complete non-issues.
/usr, /tmp or where-ever to deal with code that hardlinks these locations (which, in most cases should never be required, because you should be accessing 'bin' directories via PATH, and 'lib' directories via LD_LIBRARY_PATH... and 'tmp' directories using the stdlib functions (or a language-specific wrapper).
/sbin has always been stupid so good riddance there. Separating super user executables from normal executables helps nothing in 99% of cases. What matters is the write and execute privileges on the actual executables, not the directory. I believe the argument is that if you want to have tiered write access amongst non-root administrator accounts, with administrators only able to write to /usr/bin but not /usr/sbin, you can do it with SLIGHTLY less work. But really- if everything is written PROPERLY, a simple change to the system's PATH variable, and some time moving the right executables into the more restricted directory will yield an identical result without the clutter by default, and the need for people to explain what sbin is to newbie users.
Many distributions have reworked the filesystem hugely, with some regulo symlinks on
Certainly '/etc' has no standardized variable or way of accessing it other than just hardcoding in '/etc', but this is why we have symlinks.
I agree with the other posts about keeping the boot volume separate from the non-essential OS code volume (/usr). It is there for a reason, not just compatibility. Also,
Also whoever had the bright idea to not have */sbin in the PATH was just retarded. I have no idea what their argument is on that.
When linux gets so simple my mom can sysadmin it with no worries, but I can't get anything done... wtf do I switch to? Corollary: why do we keep fixing things in linux kerneled operating systems that aren't even broken. Just leave the file system alone or you'll end up with Ext5: Unity Disaster.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
I know programmers and developers often like to think they know best, but it is important to remember that the file system belongs to the user, not you. You should respect that by not littering THEIR file system up with thousands of small files that they will never touch directly, obscurely named files and folders, or visible system internals.
There is no good reason an end user should be able to browse in to /dev or even see it at all. In *nix there are no attributes for hidden folders so you hacked it by having files start with a period?!! Individual applications are split up in to many thousands of scary looking files and folders that often get picked up when the user searches for something on the drive.
Look at the original MacOS - each application and even the OS was often just one distinct file each. Nothing scary there, and easy to manipulate.
All modern OSes have gotten away from that. On Mac, Windows, and Linux a "fresh" install easily has 10,000 files on it and an insanely huge directory tree. There is so much stuff it even has to have dedicated locations just for user files. Basically the entire disk belongs to the OS - not the user any more.
It doesn't help that Unix style file systems hail from the multiuser mainframe era where the disk NEVER belonged to an individual user.
Complain about the technical issues all you want, you are making things more confusing for end users than it needs to be.
This sure seems like a bad idea, are there really people who are complaining about this? Seems like it could lead to a backlash of unity-proportions. :-) I'd be ok with if it if looked exact like the current file-system, but without littering my home directory with empty "Videos", "Pictures", "Documents", "Webcam", "Music", "Desktop", "Downloads", "Public", "Templates" directories...
Another set of developers who are to lazy to learn the intricacies of a software and decide to "rewrite". I guess there *was* a reason for Redhat to dump the desktop side.
I remember when all the FOSSies were saying how evil and stupid it was for Microsoft to put all their files into \windows\system and \windows\system32.
But you see, FOSSies are always right, even when they're wrong! Or, probably more accurately, Microsoft is always wrong, even when they're right.
I'm actually one of those baffled new users he's referring to. Coming from windows and trying out Ubuntu. I'm still trying to figure out how I can know what gets installed where when you fetch a program. I did quite a few searches on everything from how to create a package to any kind of document defining the logic behind what files are supposed to go where but still haven't figured out how to locate all the files that were installed by a package and how the os is supposed to know where to find them.
So... what's the secret ?
Be gentle... originally I was expecting to find something like a program files directory.
Is it nonsense-week on /. or what?
"Even Linux's most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users.
Errr... no?
First up, you rarely need to dig out those directories, especially not during daily use. A systems administrator may need to venture into /var/lib/whatever occasionally, but a user? Another non-problem created by people confusing their audiences. A system administrator, who needs to know these things, shouldn't be baffled by it, or whatever you're paying him, it's too much. A user, who would be baffled, shouldn't need to worry about it.
There's method to the madness - the mentioned filesystem standard, for example. If you don't grok the method, don't try to "simplify" it. Simplification only works, if you understand the thing you're simplifying really, really well. Otherwise, you're just throwing stuff out, and then say "oh, crap" when you realize much later that you shouldn't have.
Assorted stuff I do sometimes: Lemuria.org
Given the prevalence of libraries being used by more than one program, trying to organize things into directories-per-program doesn't make a whole lot of sense to me. You'd really need to have a different directories for each package. So now you've got thousands of package folders, each with a handful of files. What does that get us?
I think the idea of keeping track of what files belong to what package is the job of the package manager, not the filesystem layout.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Also, in the 15 years I've had the honor of navigating Linux file systems, I've never once needed to think about this issue except when severe space constraints were an issue. What desktop user cares? Are you people not aware of $PATH?
From my cold, dead hands...
"Flyin' in just a sweet place,
Never been known to fail..."
They address that by saying "There is no way to reliably bring up a modern system with an empty /usr, there are two alternatives to fix it: copy /usr back to the rootfs or use an initramfs which can hide the split-off from the system."
Of course, they conveniently omit the third option: Fix their init system so it doesn't depend on half the software ever written just to bring up a basic system.
Unix wins because it follows KISS. Fedora (and others) have been moving away from that. It's not good.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
As I read the comments for this topic, what stands out is that there are a bunch of arbitrary and conflicting interpretations of the "right" place to put things on a Unix/Linux system, each of which is justified by some sacred "historical reasoning" (even though no one can ever agree on said reasoning).
And that is the problem. Why should I have to know which arbitrary approach happened to be followed by a particular distro or installed package?
I don't have touchy geek pride or a need to whip out my big nerd phallus at parties--I just want the systems I manage or use to be reasonably robust and consistent. I don't care who wins--I just don't want all the variations.
If you have to mount any partition other than / to boot, your OS has a pretty serious security hole.
This post expresses my opinion, not that of my employer. And yes, IAAL.
Finder on Mac OSX hides all important standard Unix directories such as /etc and /usr, and /home is also empty; users are found in /Users.
This makes Finder pretty useless and stops any users learning about the true directory hierarchy. I can see the move to simplify the filesystem as great for newtime users, but it isn't actually that bad as it currently is with lib64 and lib and everything else. Why fix what is not broken?
The unix stuff is behind the scenes, there is no intention to make it necessary for a user to ever become aware of it. The unix stuff is really a secondary environment for those wanting to use traditional unix tools and apps. There was originally debate as to whether the console would even be installed by default, leaving it as an optional install for those who desired it.
Windows, Mac iOS, and Android all have the concept of an application directory where all the files for an app go.
This is perfectly possible on *nix, too. There's nothing magic about any part of the filesystem. As long as the shell can find your executables, and the loader can find your libraries, it will run. But it's not as smart as it sounds.
A great many libraries are used by more than one executable, package, or even family of packages. Where do those libraries go? They don't belong to any particular application. I suppose you could have a different directory for each library package, but what does that get us? Thousands of directories with a handful of library files in each? What's the advantage of that?
Separating files by their intended purpose, the way traditional *nix does, has some advantages. For example, by having executables separate from libraries, the system spends less time searching inapplicable files when you invoke a command name. By having platform-independent files under /usr/share/, one can have share that tree across architectures. Not needed on a traditional personal computer, but in a "cloud computing" design with multiple platforms coming into use on demand, it's quite useful.
I suspect the "one directory per package" mentality is largely driven by the closed-source world, where code sharing is rare, and software tends to be isolated. In the Free/Open Software world, it's very common for many different authors to both provide and make use of others' libraries and resources. Diving things into "products" doesn't make nearly as much sense there.
As a result, any old fool can publish an app in the Android Market with 1/10th the experience and skill required to be in Debian.
Debian (and most other distributions) have rather higher standards of quality. You have to do things like provide documentation, declare your dependencies on shared libraries, etc. This makes the system work better. It does mean "any fool" can't get their software into the distribution. But why would I want software written by a fool? Badly written software causes me pain.
maybe we should instead dump all of an applications files into shared directories, where they can clobber each other
It's the job of the package manager to keep things from clobbering each other, and it generally does a pretty good job. Anything installed on a system can potentially effect that system -- simply using different directories won't make that problem go away. That's why package managers exist in the first place.
Merging /lib and /usr/lib?
I think the /usr vs root distinction is less relevant than it used to be (what with even tiny computers having huge storage), but I do still think there's benefit to keeping a minimal but useful subset that can be used to fix the rest of the system. MS Windows has to use a "recovery environment" for that. I much prefer the idea that the rescue system can just be a smaller portion of the main system. Sure, sometimes it will be totally hosed and you need to boot from some other media, but plenty of times it's just that a more complicated subsystem has gotten broken, and it's nice to be able to fix that in-place.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
if it ain't broke don't fix it! I see no BSOD's here I see no need to reboot everyday Everybody hates success........
In the Unix world, we tend not to bloat one tool with the features of another. Just google linux mount zip or linux mount rar for some interesting ways to do what you want that rely on the Unix many simple tools that work together philosophy.
-- $G
even an el-cheepo hard drive can push 100mb/s these days.
and decompression is 100% pure latency. see
http://corpus.canterbury.ac.nz/details/calgary/DecTimeByDecTime.html
Which is more arcane? /home/username/Maildir
or
C:\Documents and Settings\username\Application Data\Local Settings\Microsoft\Outlook ... blah blah blah
C:\Documents and Settings\username\Local Settings\Microsoft\Outlook
HKCU\Software\Microsoft|Outlook
I really don't understand why people get so hung up on /bin and /usr/bin. One is for stuff needing to be available during boot and system recovery or maintenance, the other is for standard applications. Not very arcane.
I guess since hardware is sooooo cheap then you dont mind paying for my 2T drive then?
No?
Didnt think so.
I've used compression on laptops which are running tight on space, especially when a folder contains hundreds or thousands of infrequently but still useful files. e.g.
http://www.ugg-boots-outlet-sale.org/
Really, Fedora? I used to like Fedora because they weren't afraid to ship current versions of software and always tried to new newer, better ways to build a Unix-like OS. I liked how the Fedora community was organized and how the package management system worked. I liked Ubuntu because it took a solid, sane Linux distribution (Debian) and made it into a user-friendly, everything-just-works OS that practically anyone could use.
But now I'm starting to believe that all of the mainstream Linux distros have lost their fucking marbles. Between adding more and more layers of pointless abstraction, the KDE4/Unity/Gnome 3 bullshit and this, I don't know what to think anymore. It's like they've all totally given up on improving a good thing and are now changing shit just to change it. Did the Linux world somehow absorb a massive influx of middle-managers and HR drones when I wasn't looking?
Christ, it's enough to make me switch to BSD and start drinking.
That's too complicated and confusing. Programs should be in "My Programs" and libraries should be in "My Other Files That I Don't Understand". And what's with those totally incomprehensible command names like "ls", "cp", "mv", "tar"? Make them "Show Me My Files", "Make Another One of These Please", "Put it Over There", and, um, what's tape got to do with anything?
Busybox
You know dump all the common *nix commands into a single blob... problem solved. ^_^
I'll put on my flame retardant suit now...
Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
Is this the same question?
Over time, many alternatives keep popping up. Each time they still fail to gain traction.
Abstraction. Since the desktop user doesn't care, then why mess it up for the rest who do care?? The simple users don't care if you have some convoluted process behind the scenes because even the simple stuff is convoluted to them.
Leave unix alone! if a desktop user can't handle it then they should stick to the GUI.
Proxies... hmm... make a more clear directory like; /binaries and /library and fill it with symlinks to help those people... GUI tools can run a script which auto populates those... or you could mount a virtual FS to handle those (like /proc or /dev)
Then you keep things proper and the losers can go the easy route... software however can continue to properly function the same way (because those people should be able to grasp the concepts.)
Actually, I think the package systems could use a bunch of wrapper features-- a package file handles install, removal and most importantly acts as a proxy for the App-- so you can run, drag and drop, install and delete with the package/receipt file. Then it seems easy and simple like Apple does but is more flexible. A package manager is a special directory where you search for packages and drag/drop to install stuff; the "copy" process is actually download and installation. The user can THINK their app is located in their home directory but its really just a proxy for a standard install. In fact you could even allow them to "run" the app directly from the package system directory; where it downloads and installs then execs and from that point it execs instantly from that location (but can be copied to other locations and run.) This would be the most desktop user friendly. Permissions could be handled in various ways... for example, if you can access the proxy, then you are allowed to run it. For GUI apps this would be a fine system...
Democracy Now! - uncensored, anti-establishment news
Fedora got +1 respect from me because of this - FHS is deprecated IMO, and simplifying the directory hierarchy was needed for a long, long time. If they go a step further and adopt the same reasonable hierarchy from GoboLinux, even allowing installing software one-user-only, I'll switch immediately, even being a RPM distro (I work better with .deb).
.deb packages being fully compatible again;
Now, let me do a wishlist...
* Compressed directories;
* Xfce and Mate fusing into one highly configurable DE, with as much features as the user WANTS, but allowing a small RAM footprint if the user doesn't use them;
* A K3B GTK+ port;
* Ubuntu's and Debian's
* An optimized, bug- and crash-free Firefox fork;
* Ballmer dying in a fire [not really].
Nerdy news for your nerdy needs? http://www.soylentnews.org Soylent News is people!
This just in: everybody disagrees with how the Linux directory hierarchy should be implemented.
That's because there is no truly good way to do it. You either try to split stuff up in some semblance of organization which makes it harder to locate things, or you throw it all in together which also makes it harder to locate things. It's like sorting music; maybe you have an instrumental of an album. Does it go in the same folder with the normal album? Does it go in an instrumentals folder for that particular artist or genre? Does it go into a separate instrumentals folder with all the other instrumental albums? There is no answer because everybody prefers a different layout. Hell, people can't really even agree on a single naming scheme for individual MP3s to begin with. Artist first? Song first? Album first? Include the year?
Unfortunately you can't use a bulk renamer on the Linux filesystem. The only alternative I can think of is to just create like an environment variable system or some other method of letting users choose where stuff will be stored by default. All future software installations would then abide by those rules.
But this is Linux we're talking about, so there aint gonna be consensus over doing it that way either.
Sorry, the AC is completely wrong. That is not the way NTFS works at all, not even close.
I would like to see linux standardize on the VMS filesystem, or at least on certain attributes. First, automatic versioning. Every time a file is written to, a backup is made, and the version number incremented. Second, overlaid directories. These worked like those transparencies of human anatomy in antique encyclopedia. For example, if $bin=/home/username/bin;/var/trap;/usr/$groupname/bin;/usr/local/bin;/usr/bin; then the system would look for a binary in those directories from left to right. /usr/bin would be the OS installed variant. /usr/local/bin would be the local variant. /usr/groupname/bin would be the variant used by members of the user's group. All these would be read only. /var/trap would be writeable. If there was a malware attack attempting to overwrite a critical binary, it would wind up in this folder, and a periodic wiping of this folder would keep the system clean. /home/username/bin would be for user specific variants of the binary.
When our name is on the back of your car, we're behind you all the way!
For example my tape drives can compress everything in hardware but I don't get them to do it becuase some data compresses better than others. It works better to compress the files that can be compressed before they go on the medium instead of getting the tape drive to try to get the get the best fit for everthing, do a miserable job with the compromise and take time to do it. Apart from the device that's the same idea as doing it to an entire disk filesystem (it's just a tape filesystem). What can be done is have a layer that compresses and decompresses individual files on demand and there's something in linux that can do that (as described in other posts here). Come to think of it, doesn't compression on NTFS work that way as well? It's not a compressed file system either!
Not as the main organization tree of the disk, that is still as goofy as ever. However, many companies these days structure their applications in an FHS-like way inside its own directory. Visual Studio makes a similar tree of sorts. Heck, many of Microsoft's own products (bought or in house) these days come in that layout. If Microsoft could keep the root and Windows directories more clean of 3rd party cruft they would have a good compromise in disk/directory layouts. They already have a pretty usable User directory structure in Windows 7 even if some of the shell alias links are broken (wtf?).
On a side note. I used to make distros that shoved optional or 3rd party packages in /opt. Original LSB drafts indicated that was the preferred structure till Redhat, etc. pushed back. I still think that is the best way to organize optional packages. Otherwise I agree. Put everything that is a distro app/util/etc. in /usr, keep / as kernel, disk, and filesystem utils. Otherwise, why even have a /usr?
That is why the X86Open -> linux-as-common-binary -> Linux Standard Base was created.
Lets see: Ubuntu with Unity, Fedora thinking pile all the crap into 2 directories - what GNU/Linux fork isn't busy screwing with how things have been?
I didn't know there was a problem. I have had zero issues with it so don't blame the OS for your inept ability to properly manage your files.
I run Ubuntu. With every upgrade, they break something and I have to spend time researching it.
Mostly this breakage is someone trying to "improve" things.
For example, pulse-audio. I suffered with it for a long while, then finally found how to rip it out by the roots.
I do not want unix to be like Windows.
I do not want my expectations broken on every release. Let it be. Make it stable.
This is compatible with progress. I want great new applications like Chrome. New apps and libraries don't disrupt the platform. I wish these guys would understand how much of other people's time they are wasting.
He gives us a few case studies which show problems in the current layout: http://cr.yp.to/slashpackage/studies.html
If you care to read slashpackage page, you'll see he suggests something like gobolinux does.
I wouldn't put any NAS on my network with less than 8GBPs FCAL or 10Gbit ethernet. True, the clients would only get a 1GBit hookup if they're not a virtual machine or a big database server, but 100Mbyte/second is plenty for plain data where I work.
I was promised a flying car. Where is my flying car?
I would like to see a distro that would put some effort into simplifying, and cleaning up, the rootfs layout to (from) /applications (/opt) /application/apache /application/apache/lib /application/apache/data /system (/bin + /usr/bin) /system/boot (/boot) /system/config (/etc) /system/devices (/dev) /system/runtime /system/runtime/processes (/proc) /system/runtime/security (/selinux) /system/lib (/lib + /usr/lib) /users (/home) /user/guest
+1 Insightful. While they're at it, make the filesystem case-insensitive. I have personally seen users having to migrate (away from Linux systems I set up for them) back to Windows or OS X because of that one issue.
The main problem is not really the current location of binaries. The main problem is that resources related to binaries are spread out all over the place. For example, a library is associated with headers (and multiple versions of the library), a desktop application (and some cli-ones), have a tone of associated resources (png-files, scripts, audio files et.c.). At present these are all spread out in various locations, i.e. /usr/lib/libfoo.so, /usr/include/foo/* and /usr/share/foo/*
I would suggest that the Linux vendors adopt a model similar to the OS X bundles. Essentially, libraries would become more like OS X frameworks.
"Civis Europaeus sum!"
If they want to try this, they should first make a pseudo filesystem that uses the files from various dirs and displays them in 1 dir.
This might even be enough to help the users along, without screwing everything.
Could you communicate with nVidia and ATi so we can have some support for the hybrid graphics cards? Please? It doesn't even look like you're trying.
"Linux and UNIX-like operating systems have followed a particular, if arcane, way of organizing files"
In other news, if somebody doesn't personally understand the reason for something, it is now "arcane".
Personally, I still prefer to have "/usr" on its own filesystem, so I can unmount it if I need to and tidy it up, using the tools in "/bin" and "/sbin". It's not *necessarily* a space thing. I quite like the separation between basic tools, and "everything else". If an "everything else" package install or script or similar stuffs things up, it's nice to be able to fix it in a reasonable environment (which an unmounted "/usr" gets you).
I also don't mind the separation between admin tools, and user tools. I think that covers the "/usr/sbin" versus "/usr/bin" thing.
And there we have it.
Well, so called "new generation" is about breaking rules without understanding what those rules for. I can't say they are totally brain-dead but they do not understand "UNIX soul" definitely. Simplicity? No, chaos! Lenart Poettering is very known by his ugly and annoying "PulseAudio" that is in every Linux distribution now. Do we need another his "innovation"? Is there at RedHat some person with a bit of brains to stop him?
Having developed many programs that comply with the Linux Filesystem Hierarchy standard you come to realize that there is much method to what seems like madness. /opt) or /boot) or /var/spool) or /var/run).
The filesystem provides an interface between the kernel and the processes that run on top of it providing what (when it all comes down to it) is state management. When you realize that the state that a process uses has many dimensions to it you then come to see why each directory exists. To name but a few of the dimensions I am talking about:
The state can be persistent (/var/tmp) or volatile (/tmp) across reboots.
The state can be static and sharable (/usr,
static and unshareable (/etc,
dynamic and sharable (/var/mail,
dynamic and unshareable (/var/lock,
However much of this has sort of evolved organically and I would argue that the much needed cleanup that is being considered would not involved simplifying the layout but rather completing it to encompass all possible state property dimensions.
And user should never see beyond there home directory and even then a good app would not even need to show them this.
it's funny; /. is the only place I've seen this word used regularly....does anybody ever use this word in verbal conversation or just write it??
The linux filesystem (while I can live with it - its far from something sensible to anyone looking at it from outside). really is byzantyne and bizarre. This kind of logical tidy up/clean up should not really be attacked - and it should not really be seen as a competitor of LSB or similar, but rather that it needs to evolve and where vendors can clean and simplify the file system, they should be applauded. The LSB should always consider clean ups and simplification.
In the modern sense - Linux is reaching out to 'normal people'. Its filesystem by design was for the arcane, the clever and the developer. Its filesystem means very little, but worse makes little sense to actual end users. And if thats the case it is *always* worth rethinking it rather than just accepting it is what it is - live with it.
If an end user has to actually start reading deep technical notes just to understand the file system, the filesystem is wrong. I'm not going to claim 'Windows' got it right, but its filesystem has a more humane naming convention at least in part. Programs actually live in a Program folder. Thats a simplistic example I know, but /usr/bin means very little to the average person..
We`re all equal
Sometime executable names colide :
Two application can provide the same exp executable to export data.
How to they expect to handle this if they keep only one directory ?
I would rather keep them in separate directories and alias one of the executable
Mission accomplished: Gnome 3 is an unusable mess. They've ruined the desktop! What's next? Trash the file system! Nothing will be where it used to be.
STOP CHANGING THINGS!!! JUST STOP!!!
Windows is terrible because all they do is shuffle where things are from release to release. FireFox shuffles where things are on the screen for no reason, after leaving them alone for a decade or more. Gnome 3 fundamentally cripples my ability to do my work so I had to move to KDE.
People use Linux every day. They have muscle memory and a mental framework of where things are. Stop changing them. There is no reason for this change. If there was some compelling reason to change things, sure, but there isn't, so don't. The vi editor hasn't changed, ever. No user interface consultant has rearranged the keys. Emacs is the same now as it has been for the past 20 years that I've been using it every day.
Red Hat: If you do not stop this random change for no reason, users are going to be fed up and you will be history.
He isn't. But you also still have the option of using a compressed filesystem.
And isn't the OP telling people what they want? "You must make a compression filesystem like the one what I want". Fairy quiet on decrying that one, weren't we?
On my laptop (2 x 650GB 2.5in drives) I can replace them with 2 x 1TB drives
My Dell Mini 10 has room for only one 2.5 in drive, you insensitive clod! ;-) Also, solid-state laptops such as early Eee PCs and MacBook Air are designed to take an mSATA card instead of a full-size platter drive.
Just install it all in /Fedora won't you? Add some /Fedora/System32, a binary registry container, a /Users folder, and call it Microsoft Fedora Winsux 7. Don't forget the "Aero Unity" User Interface, so users don't get baffled by Gnome or KDE or whatever.
man hier
Now if fedora (and other linuxes) could put /usr/local/bin to good use, I'd be impressed.
DO NOT CHANGE A THING, you have enough different types of filesystems already available, and the user can actually control where he wants the files to be installed or reside, so why start playing with something so inbred in the system, that there are bound to be problems.
It's still useful to have some of those directories separate, for example when combining solid state drives with spinning drives.
That way you could have more than one boot partition on that ssd.
From the OP: "Even Linux's most passionate partisans will admit that its filesystem, which stashes vital files in a variety of arcane directories, can be baffling to users."
/.ers really think Solaris or AIX or BSD or any other *NIX is going to adopt Fedora's bad decision? They won't, so we will have yet another set of system files that will be different from all the other o.s. versions. Sheesh, what a crummy, poorly thought out decision!
Yes, it is a pain in the ass to learn where system files live. Just deal with it. If you can't deal with it, go back to windows.
Do any
Circle the wagons and fire inward. Entropy increases without bounds.
It's time to stop the insanity and stop treating 64 bit stuff as if it's some temporary add-on that will go away. Get over it people, nearly every desktop CPU in the world is 64 bit. There is no reason to rddun a 32 bit Linux any more. I can see it sticking around on Windows, since there's all this legacy software that people can't run any other way, but on Linux everything is natively compiled to 64 bit already. If you want dual-arch, fine, but put the obsolete 32 bit stuff in a specially named dir, like /lib32, instead of treating it like it's going to stay around forever.
And enough with those bogus arguments of "programs not needing 64 bit address space". That's irrelevant. It is much more useful to have a single target platform to develop for, and it should be 64 bit. Additionally, there's only two architectures left: x86_64 and ARM. ARM is used on handheld stuff and sometimes on servers. x86_64 is used on everything else. Since desktop and mobile applications usually use a different codebase anyway, this gives developers just one target to develop for, which is a very big deal indeed. Less work for developers - shorter time to release and cheaper software. It really is a good thing.
some legacy programs are still going to want /usr/local. what i see happening is a bunch of symlink workarounds that end up just confusing everyone. seems like there could be other things to spend time on improving.
Join the Slashcott! Feb 10 thru Feb 17!
In mom's basement, on a poorly secured single-user machine that runs a GUI on the console 24x7, the proposed hierarchy probably makes good sense.
But a general purpose file system reorganization also needs to work for family machines (my kids and their friends each have their own unprivileged accounts) and for small business office servers, and for large enterprise application servers. The tip-off is the word "general" in the phrase "general purpose file system".
In multi-user deployments, particularly large secured ones, it's incredibly useful to have a separate place for user executables (generally dynamically linked to unprivileged libraries), sysadmin executables (often statically linked or suid/guid tagged), and site/host/application specific executables (like X11 apps for example, or tomcat stuff).
Segregating things this way helps with establishing backup and security policies and permits partial upgrades - it makes a smart sysadmin's life easier and makes audits simpler too. Obviously, for unemployed hackers who run X11 on single-user laptops all the time, it's not so important.
Sysadmins have always complained about the way Red Hat piles all the X11-only executables in with the pure CLI stuff. That's the opposite of useful categorization; mix everything up randomly in one bag. Why not just put everything in the fs root if these distinctions aren't useful or meaningful? Screw having a separate directory for configuration files and variable data, eh? This is one step further back down the wrong path - categorization is useful!
For the record I got nothing against unemployed teenager hackers lurking in basements. But re-arranging a general purpose system into a system optimized for their use case seems misguided.
xkcd on standards
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
There is merit in having separation.
1. There should be a core set of OS files that are read only, preferably on a partition that's read only, enforced with a mechanical switch. This allow a set of known good files.
2. The file system hierarchy gives separate name spaces. /bin for OS executables /usr/bin for non OS executables managed by the OS vendor. /opt/vendor name/package/ for third party installations.
3. In general removing any package should be possible by removing a single directory.
I did number 3 when I was sysadmin for the U of Alberta math department. Disk space was still expensive. So we had an NFS share that unix boxes mounted as /opt. The binary and library's directories were OS specific. So for some packages there were up to eleven directories of each (HPUX, IRIX, AIX, Linux, NeXTStep, SysV, Sun. Some had multiple versions). System owners could choose to run off the network drive orby running a script could install to a local drive. In addition there was a public dot file that would do the right thing for path management.
In practice there was a third level in the hierarchy for version number. This meant I could install anew version of foo without removing the old version of foo, control which got used with sym links, and revert in ahurry if something was broken.
Only package maintainers should have to care about the underlying directory structure. Developers provide autoconf/scons/cmake/... scripts. Users can use the GUI and store their documents in their Documents folder. Never mind the Powerusers, they will always feel that things are either too advanced or too dumbed down, until they become Developers (tm).
If it's important to realize why they were separate, I wonder why you didn't take the time to look it up instead of making a wild (and wrong) assumption. Hint: has nothing to do with small discs, distros were comparatively small at the time as well.
It has to do with handling fs corruption and security. A small root fs (/etc /bin /lib) is generally stable against filesystem corruption as it doesn't get written to often. After a crash, it's more likely to be ok. It's needed to boot a usable system that can be used to rescue the rest of the installation (/usr). /var is a separate partition because it gets written to continuously and is more likely to be in need of recovery after a system or disk crash. /tmp is a target for many temporary file prediction exploits so it was also made separate. For example, it was common to mount it "nodev,noexec" so the kernel would refuse to execute programs or open devices from it. /boot appeared when the 2Gb hard drive barrier was breached and BIOSes were unable to read from higher disk cylinders using the standard interrupts, LBA was introduced and we needed a partition to put the kernel in that we can make sure the BIOS can read.
Anyone who goes mucking around in the file system outside their /home/$user folder generally knows what they're doing, so why even bother?
Twinstiq, game news
I can see why it would be nice to consolidate, however I think it will break a lot of legacy applications if symlinks are not put in place. All in all, I don't see the real benefit from this.
Yay, even more files for gnome to chug through when I want to open a file with a non-standard program. Right click on file, select open with other program, navigate to /bin, and wait 5 minutes for the file manager to realise that most of those programs don't have icons.
win$$ is just as big a rigamarole, but hides it from the user. If Linux were actually usefully documented, the tree wouldn't be a problem. here woud be a noobspace with kindergarden decoration. Like the other, ruinously expensive thing.
Probably that is not a good idea. Much of the Unix/Linux security advantage has to do with the tiered organization of the system of executable files. Unix/Linux has no other method of controlling access to programs based on the role of the user. Access by user role is efficiently implemented using this tiered file system. - if implemented correctly. The idea is four layers of security (installation(admin), developer(programmer), privileged application user, unprivileged user). Critical system programs are in /sbin (parted and other sysadmin programs), /bin is used for common utilities and programs publicly available to all users. /usr/bin contains programs which are used primarily by software developers (compilers etc..) /usr/sbin is used for development admin tools. Application packages go in /opt//[bin,include,...]. The unpriviledged user can put files he wishes to execute in his own /bin directory and mark them as executable. This system allows each user to be given access only to the application software actually needed. You don't want the guy in the mail room running the payroll system. The original reason for dividing up executable programs may have differed from this, and the reasons for doing so in the modern era of personal systems are perhaps different from the historic large/mid frame machines it evolved on. Today the primary reason everyone should want to maintain this file architecture is the number of program name collisions between packages. If you build distributions you are either terribly naive, or you know what I mean. The traditional unix/linux file system does a relatively good job of limiting (i did not say eliminating) the name collision problem. It can be used for limiting the damage a system, application, or user can do to itself, friends, or frenemies. You don't really want a executing daemon to have access to it's own or anyone else's development software. There must be a better way. I am sure there are more than 4 roles, or at least a better way to implement access - The $PATH shell variable is the great failure in this scheme, and perhaps why no one bothers with taking any of the rest of it seriously. I am sure there must be some more efficient way to implement roles. I have been looking for a while now, and I have not seen it yet. Just because this method is an old idea don't mean it is a bad idea. It simply is not possible that a better solution involves a single directory with huge numbers of files. The Path method already makes search times too long. The solution has more to do with using the tiered method properly and fixing shell implementations to make it impossible for a user to change his own role ( by tinkering with $PATH). Scrapping the tiered method would make Linux too much like Windows.
They should fix the real Gordian Knot: Glibc.
Simplify how it it so complicated?
What problem are they really addressing?
Graphical file system tools are already
slow and sloppy.
One could stuff them all in /
and resolve some historic name
collisions with some silly notation
as bin.bash alt1.bin.bash alt2.bin.bash
This tells me that it is silly quest and structure IS needed.
$ rpm -qal | wc
337729 337782 18840957
Just watch out for the special /.
case of
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
The filesystem used by SuSE will eventually look something like:
/ -> C:\
/boot -> C:\boot
/dev -> C:\System
/root -> C:\Users\Administrator
/home -> C:\Documents and Settings
Look vaguely familiar?
Journal File Systems are the best way to go. Especially for large database and structured data-store environments. They provide re-synchronization and recovery after an outage. They also provide for virtualization and file system sharing between processing nodes. Offerings from Sun Microsystems like ZFS for Solaris is now offered by IBM for its Linux offerings. Symantec offers Veritas Software's VxFS for Sun Solaris, HP-UX, Linux, and IBM's AIX. IBM also provides a management suite of file systems with backup and recovery technologies under its DFSMS offering which includes the venerable Virtual Storage Access Method, (VSAM), upon which structured data-stores and databases technologies depend on.
Journal File Systems is the best way to go. They provide for file system recovery and re-synchronization after an outage. They also provide for file system virtualization and sharing between processing nodes. Journal File Systems are best for database technologies and structured data-stores for business intelligence or multi-dimentional and object oriented databases. Sun Microsystems Solaris has ZFS now and IBM provides it for its Linux offerings. Symantec offers Veritas Software VxFS for Sun Solaris, HP-UX, IBM AIX, and Linux. IBM also offers its DFSMS solution for sequential data-stores, structured data-stores, backup, archive, and recovery. IBM DFSMS also offers the venerable Virtual Storage Access Method, known as VSAM, which is utilized by structured data-stores, hierarchical and networked database technologies, inverted list database technologies, business intelligence data-stores, as well as, multi-dimentional and object oriented database technologies.
How would this be affected in terminal services or kvm configs which use the /boot /bin struct for the servers and to hand out OS data to terminal/clients? I'm sure this may not be used much either anymore, and do not have time to research atm... Any comments would be appreciated.
I am opposed for the following reasons:
Name conflicts. Many applications have the same launcher name. Therefore one later application can override the earlier one. /usr/bin/application1, /user/bin/application2... Where bin does not hold binaries, but points to the next level of directory from where user application binaries would be found, /usr/bin, I would accept soft-links (shortcuts).
System libraries must be kept apart. I would hate to have some innocent application overwrite a critical system program name.
I would like to see a breakout of libraries. to
In
Leslie Satenstein Montreal Quebec Canada
the file system hierachy in linux is stupid, let system file stay in system folder, let application stay in applicaion folder, let rpm, pkg go to hell, those people who act professional seem really stupid, they don't know what the user want, they just make a toy and play themselves. the file system hierachy follows the rules of 20 years ago, never changed, every linux distrubution keep uprading all the time, but you never find any thing inspired.