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.
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
You can enable some hidden setting somewhere to show hidden files, but then it shows it shows EVERYTHING, including dot files. There's now way to get it to show /bin, etc but not .bashrc and stuff.
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.
This makes Finder pretty useless and stops any users learning about the true directory hierarchy.
Um, if any user is smart enough, or actually cares enough to learn about the true directory hierarchy, they will be using Terminal to do so, not finder. Also, telling Finder not to hide any folders is pretty easy to do, but the default for hiding them makes sense as most Mac users don't need, or even want, to see them, so hiding them makes the interface much cleaner.
Monstar L
Now, for those who did not know, there's no Gordian Know. It's Gordian Knot.
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".
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.
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.
Actually, Windows has had a totally baffling directory layout ever since XP.
http://gadgets.boingboing.net/2008/06/25/bill-gates-rant-from.html
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..
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.
Actually, Windows has had a totally baffling directory layout ever since XP.
And it got much worse in Windows 7.
Regrettably, that was the last sign of the apocalypse. Doesn't look like we'll even make to 2012.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
/bin separate from /usr/bin has been a major annoyance to me in trying to administrate RHEL boxes alongside HP-UX, AIX and Solaris. "Oh, yeah, RHEL puts that one in /bin, but this other one in /usr/bin, gotta remember which is where."
40MB hard drives have been gone for a very long time. /bin should only be a symlink to /usr/bin as they are on say HP-UX and Solaris and AIX. The only things that should go into /sbin are those things absolutely required to boot or single-user repair (fsck, mount, etc.) a filesystem so it can be booted in case you have an idiot who still thinks /usr is too big to fit on the same spindle as /. (That said, combining /sbin and /usr/sbin is a good idea to me).
Now, this does not cover some of the other filesystem stunts pulled by RHEL and Fedora, but binary locations is something I've never seen Red Hat do intelligently.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
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.
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.
Why fix what is not broken?
Because sometimes when I install software on Ubuntu I can't find the magic file that makes it run.
I can choose the software I need, I can install it perfectly, and I know how to use it. I also know that some bin directory or other tends to house these things, but somehow that's not always enough - I can't trace the single action needed to make it run.
Call me dumb if you like. But seeing as how I've built my computer from components myself and installed the OS myself I have a feeling it's not solely my fault when I can't find an "executable" on my own computer. Hasn't happened on any other OS either...
(That said the part where they break standards is probably an actual problem with any reform.)
http://www.gobolinux.org/ Combines executables and necessary libraries each in their own directory under '/programs' Uses links to show files in traditional places.
The reasons stated were 1. "clean up the mess that was made when the /sbin and /bin directories were first split" 2. "it would be far simpler to run multiple instances of the operating system on different machines on a network," 3. "facilitate the use of snapshots"
The first of these is begging the question (what mess?). I can't make heads or tails of the other two.
If Lennart Poettering is a primary advocate, it means that the change would make something the Lennart wants to do on his personal desktop easier for him.
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!
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.
Word!
The Unix file-tree got it right. It's kind-of clear where your files are, and everything is rooted in / (duh).
Microsoft messed up, people are not finding their files in folder hidden deep in some weird structure, and are trying to solve
the problem by abstracting away the hierarchal structure, which only confuses people even more. Now up to a point where the tree is going to be "killed"
(hidden even more)
Sadly the major linux distros seems to have swallowed the bait. I suddenly have weird folders for my desktop, photos, documents, etc, and they /media ? What's fuckng wrong with /mnt that
seem to be "localized" so it's not entirely clear what they are named. Dynamic mounts are suddenly made under
has been around since the seventies, is as aptly named, and is shorter to type? I am waiting for "tags" on Ubuntu, Unity seems to heading in that direction.
User experience geeks can rave all they want about tags and that people do not "think hierarchically", but I am confident that the confusion is rather the leaky and broken abstractions on the windows platform.
The unix file tree is a little like this: http://xkcd.com/297/
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.
Power users are being cornered ever since people started to look at Apple for vision. I just had to switch from GNOME to KDE because GNOME (and Canonical) made a very good job at killing productivity.
none
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.
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)
There are reasons things are as they are
99% of the time the reason is simply: because that's how the developers did it. Just because there are reasons doesn't mean the reasons are good. "Leave things be" is quite possibly the worst advice, ever, when it comes to advances in computing.
In comparison, Windows scatters executables all over the disk so I'm not sure how Linux is worse exactly.
A few links would deal with apps that expect stuff in one place to see it in another. But most apps are configurable these days so it's not a big deal except when have binaries, many of which would go in /opt/ anyway and have scripts to deal with the vagaries of different systems. Really the issue is that Unix filesystem is arcane and in most cases for no good reason. So if Fedora want to simplify it a bit then I don't see the issue with that.
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!
And you'd have a better time finding the executable in a directory with thousands of files, vs. several directories with hundreds of files? You can't even go by the file date, as that doesn't reflect the date the file was installed (but whatever date the package says it is). What I do (on an RPM based system) is: rpm -ql packagename |grep bin (or grep man), to find what I'm looking for. And, "rpm -q --last" to find the most recently installed package.
I think we can. Remember, just when the drama starts to build...ad break!
Synaptic can tell you about every file that belongs to a software package it knows about and show you where it is located on your system. Search the database for the software package you are interested in and select it in Synaptic's main window. Next, click on the Installed Files tab to see a list of all files and where they are.
hth hand
https://www.gnu.org/philosophy/free-sw.html
Repeat the same reasoning replacing "bin" with "lib" for libraries.
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'm sure you aren't really as dumb as you seem, but the unix filesystem heirarchy makes a fuck of a lot more sense than "other OS". I can install stuff using a "make install" and then find every single piece of it later when I want to remove it. I have "Linux From Scratch" based systems that I don't even have package management on.
It's also not hard to guess where a particular executable is, based on the type of program. I know a typical user program installed from a distro's repository is going to be in /usr/bin. Core system utilities will be in /bin. Daemons will be in /usr/sbin and so on. Libraries will be in the appropriate install --prefix's lib directory. Headers will be in the appropriate prefix's include directory. Resources like icons and shit will be in the appropriate prefix's share directory.
Besides, you have tools like "whereis" at your fingertips for finding executables that are in your PATH, and if that doesn't cut it, you have tools like locate and find.
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.
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
how about making the filesystem a bit more intuitive, call it "Programs" or "Applications"
and break a gazillion programs out there that have been working for years. What about the transition -- some with have /bin/date and others /Programs/date -- it will make porting programs between systems much harder.
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).
Actually: No. Most programs that my systems start are out of scripts of one sort or another. You are talking about desktop systems, the Unix/Linux world is much bigger than that -- servers are very important.
power user? sorry to bust your bubble but neither KDE or GNOME were ever meant much for power users. Try a customized tiling WM (awesome, i3, dwm; I personally use musca). Or if you must, use Openbox. Once you get the hang of it and customize it how you like, your productivity will shoot up (get used to those shortcut keys).
No it doesn't. Open a terminal and its all there. If you aren't comfortable with the terminal, you probably shouldn' be fucking with those directories.
I'm a power user / unix admin of 15 years, and I've yet to find a reason to go poking around the unix filesystem on my mac, other than to edit the default apache configuration on my little lion server mac mini. If you're running desktop OS X, there is pretty much ZERO reason to be poking around in those directories.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
The thing is, a mac is fine if you're a power user. Unfortunately Gnome and KDE are trying to replicate bits of OS X without getting the foundations laid properly first to make such pieces actually work
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
You can enable some hidden setting somewhere to show hidden files, but then it shows it shows EVERYTHING, including dot files. There's now way to get it to show /bin, etc but not .bashrc and stuff.
Sure you can:
/Developer/Tools/SetFile -a v <File> #make a file / folder visible
/Developer/Tools/SetFile -a V <File> #make a file / folder invisible
dpkg -L packagename | grep bin
Knowing a tiny bit about package management is all it takes.
From my cold, dead hands...
"Flyin' in just a sweet place,
Never been known to fail..."
A power user isn't going to spend hours configuring a fucking window manager.
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.
No, he is completely wrong about NTFS decompressing the files. It does not, like others have noted too.
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.
(for those that care you can use shift-command-G to navigate to a "hidden" dir like /usr/bin and the finder will work just fine!)
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
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.
> how about making the filesystem a bit more intuitive, call it "Programs" or "Applications"
For the same reason we call it cp instead of copy, mv instead of rename, etc. We aren't drag and drool mouse users, we type.
I really wish we had insisted the Windows refugees had been properly assimilated into UNIX culture before we gave you guys commit rights on our repos.
Democrat delenda est
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.
> I'm actually one of those baffled new users he's referring to.
Short version, man hier. Longer version google up the linux FHS, it explains what should be where and why things were made the way it is. Personally I'd be open to eliminating /usr since the reason for its existence is not nearly as strong as it once was. But there are still people who do have a need for a tiny root fs and network mounting everything else. And since everyone is already used to it there really needs to be a compelling reason to change it, not just another of Pottering's jihads against everything UNIX/POSIX.
Democrat delenda est
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........
And the thousands of RHEL users will be terrified, knowing damn well what happens at the Red Hat guinea pig farm may soon come down on their heads.
Fooled
Experimental
Downloaders
Of
Redhat's
Absudities
Uninterested Brotherhood of Unapproachables Not Tending Users
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
In comparison, Windows scatters executables all over the disk so I'm not sure how Linux is worse exactly.
Linux isn't worse than Windows in this regard, they're just trying to make it even better. I can't help but feel, though, that it's another case of "we don't like the existing standards so let's make a new standard!"
My bugbear isn't where library and executables are located - it's where user configuration files are located. Programs seem to store things randomly, such as ~/.configfile or ~/.program/configfile or ~/.config/configfile or ~/.config/program/configfile. Then there are the ~/.gnome and ~/.gnome2 folders which seem to get a lot of 3rd party junk in them. And ~/.local.
Please, pick one place and make everyone migrate their data there!
FYI the OS X version of "chflags" supports "hidden" / "nohidden". You don't have to use SetFile (which may not be installed since not everyone installs the developer tools). I believe it would be:
chflags nohidden # make a file / folder visible
chflags hidden # make it invisible
Please, pick one place and make everyone migrate their data there!
You can support this effort by finding a developer of a Linux program and hitting them over the head with a rubber chicken until they make it so they read configuration information from either ~/.config/frobinator.conf or ~/.config/frobinator/whatever.
(I have seriously thought about writing an LD_PRELOAD library that redirects any access to a file named ~/.something to ~/.config/something, but that seems... dangerous.)
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.
/bin is for important system files that can be useful to mount the rest of the file system.
And you have to "mount the rest of the system" where exactly? /usr on a different partition from the root filesystem, and it is this way for a good purpose?
Can you point your finger at a system which has
My exception safety is -fno-exceptions.
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?
You can support this effort by finding a developer of a Linux program and hitting them over the head with a rubber chicken until they make it so they read configuration information from either ~/.config/frobinator.conf or ~/.config/frobinator/whatever.
Occasionally I do. Some people get very defensive about their projects though and the majority of GUI users don't show hidden files, so developers rarely see a need to move things around.
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!
Why would you use `find` when you could use `locate`?
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!
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.
This is backwards. Advocates of this idea should be the one to jump through hoops to justify taking away an option that has been there forever.
This idea doesn't solve even one problem for anyone. Anyone who can't grasp the file system will still be stupid after Fedora changes it, but mounting /usr on its own will no longer be an option. How is that an improvement?
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
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?
There is - a small one, but (your milleage may vary) an annoying one.
Simplifying the hierarchy would ease the things both for users and for devs - you don't need to "guess" or search anymore where is the executable and the libraries.
I know that "if it's working, don't fix it" is a good rule of thumb, but it's just this - a rule of thumb. When misused, it becomes "if it's working BADLY, don't fix it".
Nerdy news for your nerdy needs? http://www.soylentnews.org Soylent News is people!
what GNU/Linux fork isn't busy screwing with how things have been?
Debian.
Have you got your LWN subscription yet?
If I had mod points I would give them all to this post.
This is exactly the problem almost every single "Mac-a-like" product endeavor suffers from. They rush to getting something that looks vaguely similar, by hacking together the base it runs on and produce something incredibly fragile and inconsistent.
In my experience users really don't care about the window dressing provided something works solidly, and has an intuitive and consistent interface.
Perhaps the single worst thing efforts like Gnome 3 and Unity represent is a solid move away from the Unix philosophy of combining a set of small tools that do one task very well in favor of being "Mac-a-like", rather then embracing that idea and presenting it in user-friendly way.
+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!"
It's done for a very good reason (better network boot, boot from usb devices, more flexibility in general) but I don't think the average user can deal more easily with an initrd than he can with a plain /usr mount point. So it's not being done for simplicity as they say here. Especially if you consider that the added simplicity (moving two dozens files from a folder to another) is hindered by the complexity which would need to be added for compatibility reasons (don't think that scripts starting with #!/bin/sh would disappear overnight).
"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.
Yup, you could even say the same of Windows to an extent.
Conversely, it also works against the mac a bit because people use a mac for 5 minutes, see that it looks like it has a few "dumbed down" features in the GUI, but if you never scratch the surface you don't find the "wow that's so cool" features that enable you to do so much without a lot of time or effort expended.
Automator, applescript, pervasive drag and drop, the services menu, self contained app bundles, time machine and spotlight are all huge wins, and nothing on any other platform i've used so far comes close.
Sure, knock-off look-alike tools may exist on other platforms but none are as well integrated or easy to use.
There's a lot more to OS X than the GUI and in fact IMHO the GUI has a lot of design decisions (especially pre-lion) that really piss me off. The good stuff is underneath - and I use OS X despite the Aqua UI, not because of it.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Actually, that's EXACTLY what power users do - take the time to configure their environment to their liking and in a way that makes them efficient at a minimum of effort. I spent a couple of hours one day choosing keyboard shortcuts and so on, and have never had to touch it since - everything I do has been faster ever since.
But you can continue stabbing at the "Start" menu if you like.
If this were Usenet, I'd killfile the lot of you.
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?
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
Declaring yourself a power user won't make it so, and surely the window manager is relatively unimportant compared to the actual work environment, which is typically a terminal and a text editor.
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.
AND break a gazillion tutorials and blog posts that rely on the traditional filesystem layout.
Fedora is "pulling an Ubuntu", they want to make their OS an unique experience so that migrating away is more difficult. That's what ubuntu windows and macs do, I wonder if fedora has enough clout to outweigh the obvious problems of this transition.
Normal users need only to know the package system, advanced ones invisible files in their dir and /etc and /user/local. Pro users are not scared by a bunch of dirs.
If the file layout mattered so much, gobolinux would have enjoyed more fame I guess.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
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 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.
without getting the foundations laid properly first to make such pieces actually work
If there's one thing that would get me to drop a thousand dollars on a Macbook, it's that KDE still doesn't know how to hide the cursor while I'm typing. There, right now it's oVer the V in this sentence. How frustrating - Apple has been doing this right since the 80's.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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
You have a point if you say that the / - /usr split is less relevant today because it has been somehow superseded by the use of an initrd/initramfs.
I think it has been superseded by extinction of dickless machines (typo approved by ESR) that have such a small local hard drive that you can't fit the entire system on it.
My exception safety is -fno-exceptions.
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.
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.
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.
... trying out Ubuntu. ... how to locate all the files that were installed by a package
dpkg -L <package>
E.g.
dpkg -L base-files
If you want to do the reverse, you would use dpkg -S <filename> /etc/debian_version
E.g.
dpkg -S
alias sudo="echo make it yourself #" ; # https://pipedot.org/~stderr & http://soylentnews.org/~stderr
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.