Fedora Aims To Simplify Linux Filesystem 803
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."
When do we get compression? (Score:2, Insightful)
Re:When do we get compression? (Score:4, Informative)
Make the directories you want compressed into mountpoints on the compressed partition.
Re: (Score:3)
It's still possible with squashfs and aufs, but squashfs is readonly so aufs is so you can still write to the directory.
It's not very user friendly obviously however.
Re: (Score:3, Interesting)
How important is that, really ? The only times I've used NTFS compression were for freeing up temp space on ancient servers, back when 9gb and 18gb SCSI drives were the norm. Seems like a throwaway feature to me.
For portable usage like CD/DVD and USB flash, a full-disk compressor like squashfs is just fine.
Re: (Score:2)
SSD = very expensive small storage; mobility = no space for extra storage
Re: (Score:3)
Re: (Score:2)
There are times where it can save you thousands of MB's.
Like, wow. THOUSANDS of megabytes.
Given my ~$1000 home server has around ten million megabytes of disk space, I'm totally worried about saving a few thousand.
\usr\bsd\games\advent (Score:3)
From my cold, dead hands...
Re: (Score:3)
my 10TB server I bought & built with my fiancee disagrees with your narrow view of the world. Just because you're not capable of planning ahead doesn't mean others aren't. More astroturfing from Microsoft's elite!
Re:When do we get compression? (Score:4, Funny)
tl; dr
try compressing your comment for greater readability
Re: (Score:3)
Bzip2. Vim, bzcat, bzdiff can give you direct access. If you *need* the filesystem to do this and not userspace well there is probably a fuse plugin, but I believe btrfs has this feature as well.
Re: (Score:3)
Yes, actually you do, because once you do you can.
Anyhow back towards the 'article' such as it is, conflicting the the LSB is no reason not to do something, the LSB has never been relevant to anything. If you want a standard file layout just copy Slackware's - it's the most sensible and broadly compatible.
Re:When do we get compression? (Score:4, Funny)
This isn't 1995. Nobody cares about filesystem level compression anymore. Go buy a 2T drive.
Re: (Score:2)
Re:When do we get compression? (Score:5, Insightful)
Now there are tools that allow you to do this just for executables, but since they don't run on all platforms you can be in kind of a bind. By putting your executables and libraries in their own file compressed file system, you can gain a lot of the advantages of executable compression while still being able to use it on pretty much any platform.
Re:When do we get compression? (Score:5, Insightful)
Add to that, in network attached storage solutions, every file you read is squeezed through something as small as a 1GBbps pipe.
Re: (Score:2)
How will I get that into my Macbook Air?
Re: (Score:3)
Yup. Its all about de-dupe. Files are already compressed as CPU speed has outstripped IO by a large margin - compressing your file format gets you better IO speed. Thus, having the FS try and compress your already compressed data with some generic algorithm = LOSE.
Block level de-dupe on the other hand, can save you HEAPS of space on a typical system. Like, cut your disk utilization by 50-60% on a typical file share storing end-user files.
Re: (Score:2)
What the heck kind of files do you have that take up 10TB and aren't compressed? Video, images, audio, all of those are already compressed in the vast majority of uses.
Re: (Score:3)
No one listens to feature requests
Why should they? OSS devs aren't a group of altruistic folks just waiting around to fulfill arbitrary feature requests from end users. They, like the rest of us, need some incentive to implement a new feature. If a dev on the project finds your proposed feature useful, or sees it as an interesting technical challenge, or has some other (possibly financial) incentive to implement it, then he'll listen. Otherwise it's up to you to either implement it yourself or hire someone to do so.
It's not sane people t
Re:When do we get compression? (Score:4, Insightful)
So are you Wikipedia, the Gutenberg project or SourceForge? You're certainly not going to read 1TB of text unless you plan to live the next billion years or so, you are some kind of speciality site. The point is that most use appropriate compressed formats for their purpose. PNG beats BMP-in-a-ZIP. FLAC beats WAV-in-a-ZIP. Lossy formats like JPG, MP3, H.264 video are already well compressed.
Sure, compression is the way to go. But is it that vital that it's in the file system instead of working with zip files? Maybe to you. But I think you know you are an extreme minority on this one. Most people are happy having zip folders and a search engine that reads inside zip files and I know Linux has both. Or actually most people have no problem storing their text uncompressed at all because it takes up <1% of their drive.
I guess none of the people you talked to felt this was a problem worth solving. To me it would be a bit like learning Linux has issues with >1 TB RAM or >1000 cores, even if that was so I wouldn't exactly feel it is or ever would become a problem for my desktop. So yeah, it probably would get returned with "Well, if it's a problem to you feel free to do something about it, but I don't think anyone here will work on it."
Or something less polite, depending on who you ran into and how you formulated your feature requst.
Re:When do we get compression? (Score:5, Insightful)
Sounds like you have a problem with file formats, not filesystems. Filesystem level compression is a stupid idea since it doesn't have any way to apply appropriate compression methods to the files. Should I apply zlib to uncompressed audio? No, use FLAC. Should I apply zlib to logs files? No, I should probably use something like LZO or Snappy that have block seeking.
Re: (Score:3, Insightful)
The way I understand it, there's really no good generic way to handle file compression at the FS level.
Even the way NTFS does it is to create a compressed file to hold the contents of the original file, like an archive. But if you'll notice, whenever you open the compressed file, NTFS will expand the whole compressed data into another special file until you close it. Watch the disk space
Re:When do we get compression? (Score:4, Informative)
Re: (Score:3)
No, I think you are confusing the compressed files/folders function (right-click, send to compressed folder) with the compression filesystem property (right-click, Properties, Advanced). The former is just a userspace program, like Winzip, that makes archives. The latter is exactly what you described in your second paragraph. The filesystem transparently compresses files in small clusters, and it suffers from fragmentation problems, like you also mention.
Re: (Score:2)
Regrettably, that was the last sign of the apocalypse. Doesn't look like we'll even make to 2012.
Mod Grandparent Ignorant (Score:3)
Sorry, the AC is completely wrong. That is not the way NTFS works at all, not even close.
Re:When do we get compression? (Score:5, Interesting)
They don't need to. Linux has the ability to read/write compressed files directly (zclib?) and doesn't need the filesystems to support this. Which is great because it means compressed files will work under ALL filesystems ALL of the time (if you have the library installed) and you don't have to wait for each filesystem maintainer to add it. You also have no risks of one FS maintainer deciding another's implementation sucks and not being compatible with it. Which is very likely under Windows.
Re: (Score:3)
What you really want is something like http://code.google.com/p/fuse-zip/ [google.com] Fuse-zip(ideally one with support for all common archives you are going to run into; but if this is just for
Re: (Score:3)
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.
It sounds like you want ZFS [zfsonlinux.org]. ZFS has supported compression for a long time LZJB compression since early on, GZIP compression since pool version 5, ZLE compression since pool version 20...
The only problem is.... well, on Linux it's mostly available only using FUSE. There is the ZFS On linux port mentioned, but I suppose that's r
Re: (Score:2)
Well, putting aside the fact that you are talking about filesystem internals, and the OP is talking about conventions for filesystem layout:
Disks are really big these days. The things people tend to fill them with are images, video and audio that is already in a compressed format. So, for the average user, directory compression isn't going to be a big win.
To put it more succinctly, this isn't an important filesystem feature.
Re: (Score:3)
fuse-zip, as its name suggests, lets you mount a zip archive as though it were a filesystem, giving arbitrary programs the ability to interact with the contents as though it were an ordinary FS, so no need for tool-specific zip support. The
Re: (Score:3)
What you probably really want is de-dupe. Run ZFS. ohwait...
IMHO, this effort is pointless. If you're poking around in the file system you want it to be like any other Linux so that you don't piss off admins any more than redhat already does due to being different. If you're an idiot who can't RTFM to find out where files are, then you probably shouldn't be poking around the filesystem outside of ~/.
If you want to make linux user friendly, get rid of the need for users to go poking around in the fi
Re:When do we get compression? (Score:4, Insightful)
The one thing that baffles my mind is that Linux filesystems still don't offer compression of specific folders or files.
If you need to do this why not try a compressed, gzip'd or bzip2 tar, rar or zip file. You can even use your a graphical explorer to actually create and manage your archives (yes you can have more than one). When I say manage you can easily (ie. point and click) display, extract and even insert specific files.
Windows has had this for over a decade.
Well you could do this in Unix for over 20 years.
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.
Linux does, I think I already explained this above.
Re: (Score:2)
True dat. There isn't a space-saving methodology in the world that's more cost effective than slapping another terabyte into the rack.
Mobility (Score:2)
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.
Re: (Score:3)
A tablet without a fast wi-fi connection to a honking big server is a serving tray for the beer you're going to go get me.
Re: (Score:3)
Re: (Score:3, Insightful)
NTFS has been updated pretty consistently actually (the last being Windows XP with NTFS 3.1). Since then the Windows OS on top of it has evolved to actually take advantage of the features of 3.1.
What you said is akin to, "You mean, since the last time the default *nix file system was updated? I can't believe they're still using the aging ext file system, with all of it's 90s features like 'symbolic links' ".
If it ain't fix (Score:2)
Re: (Score:2)
32-bit libs on 64 bit systems will fade into obscurity sometime soon
Not in multiarch boot scenarios. The number of different lib subdirs is likely to increase over time, not decrease, and it's better for all concerned if one does not have to write two versions of "how to fix problems with libxxx", one for systems booting off multiarch media, and another for systems not carrying a multiarch library suite.
This will be especially true of ARM, with its many variants.
Re: (Score:2)
Re: (Score:3)
I mount /boot, /bin, /sbin, /lib, and /lib64 read-only from a small SSD; I mount /usr on a large HDD. Maybe that's not a good argument, but it's yet another reason I'll probably never use Fedora.
Re: (Score:3)
Fedora's excuse for this is that their distro can't boot properly with /usr on a separate partition anyway, so rather than fix that bug so it at least boots far enough to mount that filesystem — like every other distro I've installed with that partition layout seems capable of doing — they're just saying "fuck the standards" and doing their own thing.
Good idea (Score:2)
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.
Re: (Score:3)
Re: (Score:3)
For example,
Re: (Score:3)
What package manager GUIs are for. There's a lot going on in the filesystem that you'll probably never know or care about. Trying to simplify some at this level of the system for reasons of end-user convenience is just asking for trouble.
Simple (Score:4, Funny)
What could be simpler?
Re: (Score:2)
Microsoft hears you.
Fedora, eh? (Score:5, Insightful)
The developers at Fedora can do whatever the heck they like. Pat knows what he's doing, and that's good enough for me.
Re: (Score:2)
Has he seen reason on PAM, yet?
Re: (Score:2)
There is no reason for PAM ever
Re: (Score:3)
There is no reason for PAM ever
Other than not wanting your food to stick to the foil [wikipedia.org].
no thanks (Score:2)
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".
/bin, /sbin had their functions (Score:5, Informative)
Re: (Score:3)
Having the separate directories still comes in handy when rescuing systems. Something Fedora is missing here is that it's not the separate directories that confuse people, it's the abbreviations.
In all honesty, users this new don't need to be messing around with the system at such a low level, Windows actively discourages it as well. The problem is that there is still not enough mature applications available for new users. They are not always satisfied with what comes prepackaged, so they venture out on
Re: (Score:3)
I don't think it matters with separate directories. On a rescue disk you'd only have the essentials to get going anyway, right? But I agree that the abbreviations can be confusing. I'd love to see a simpler installation like OS X (NeXT) app bundles become the default. Since it's all mostly open source , or some commercial bits relying on open source frameworks (Gtk+, KDE/Qt) these app bundles would rarely need to bundle any dynamic libraries.
I doubt a mess of symlinks is avoidable for now, though. Linux has
Baffling to users ? (Score:2)
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 file
Re: (Score:2)
Save yourself pain. Make a new filesystem naming point, say /usr/companyname. Put your company specific code into that directory. Isolate all applications into some application naming structure, say /appl/foo for application foo. Don't allow applications to put so much as an init script elsewhere, because you were smart and told them they aren't allowed to run any code as root, not even startup scripts.
Re: (Score:3)
You can make Linux applications that run out of a single directory. Use the RPATH option to the linker, which is effectively the same as adding the directory the executable is in to LD_LIBRARY_PATH. Readlink /proc/self/exe to find the executable and use that to find all your other data files.
Most commercial Linux software does exactly this. Installers pretty much dump an Application directory into /opt and then do a bit more cruft to add a symbolic link to /usr/bin, and to add launch menu items and .desktop
no thanks (Score:3)
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.
Forget filesystem location, what about LVM? (Score:2)
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.
what users? (Score:2)
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
"union" filesystem can do this already, no? (Score:2)
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..
even simpler (Score:3, Interesting)
So windows is right (Score:2)
Putting everything under C:Windows and C:Windows/system turn out to be the way to go.
The idea is problematic (Score:5, Insightful)
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.
Or they could fix the actual problem (Score:3)
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.
Re: (Score:3)
This is bullshit. I know because I've done it plenty. I've setup servers with minimal / filesystems for years, because /usr and all other filesystems are iSCSI/NFS/etc. mounts that aren't brought-up until needed (as indicated by heartbeat, or whatnot).
There are only a couple spots that need to be fixed (with RHEL5 init scripts) to allow booting multiuser without /usr mounted. One is the use of head/tail,
GOBO Linux (Score:5, Informative)
Compression? (Score:2)
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 deskto
I like it (Score:3)
This makes sense to me. All those extra directories had historical reasons but time marches on.
RANT: Don't break my file system (Score:5, Insightful)
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
Re: (Score:3)
What's wrong with /bin and /lib ?
Among other things: They force you to splatter files from different pieces of software into the same directory, making it impossible to install different versions of the same application.
Re: (Score:3)
/lib, /bin, /usr/lib, /usr/bin, /sbin, /usr/sbin, /usr/local/bin, /usr/local/lib have their place. You are not "forced" to splater files from different pieces of software into the same directory, but it makes sense to have these in a standard location if they are meant to be shared with other programs. Don't forget you can
Re: (Score:3)
Indeed, a while back I had a Vista install go tits up because I had added new partitions and had accidentally run bootrec forgetting about what that would do to the partition labeling. And MS doesn't provide proper tools to handle a situation like that without loading up a recovery disc. By the time I had that mostly sorted out, the profiles wouldn't load.
Right, now Linux is largely impervious to that sort of thing, so obviously, the thing to do is find ways of making it pervious to that stuff.
Re: (Score:3)
There is nothing exoteric or baffling with the filesytem of Linux.
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.
Right, because computers haven't changed much in the last twenty years probably.
WHY do you cut every single program into little pieces and box them together?
Look at the RHEL Tomcat RPM, compare to traditional /opt/tomcat or /usr/local/tomcat or even /tomcat
WHY does anyone think cutting that or any application into ten different directories, mixing its private bits with private bits of completely unrelated programs is a good idea?
I can think of reasons to seperate user configuration and data from non-user th
My Mom (Score:3)
nonsense (Score:3)
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.
Re: (Score:3)
Is it nonsense-week on /. or what?
Well, no. It appears to be bad summary week. And people replying without RTFA week. Actually skip the article even, read Lennart Poettering's post on fedora.devel. [gmane.org]
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:3)
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
Unix stuff is behind the scenes (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Don't forget about SysWOW64
Re: (Score:2)
Re: (Score:2)
Hell, if we are really going to cater to the numb, lets make it all case insensitive.
Re:Dumb move (Score:5, Interesting)
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.
I agree. I suspect the libraries are the more 'needed' change, but your point is valid even there.
What I'd like to know is what's wrong with the FreeBSD file system, and why don't they just 'do that'? IIRC, everything non-standard is in /usr/local. Some configs are in /etc, but most (all?) non-base configs live in /usr/local/etc. If you blow your system away and have backups of /usr/local and /etc under FreeBSD then you can just reinstall the base system and be 'fine' (aside from the local user files, but that's an obvious restore/backup situation.)
This smells a lot like "we want to do things our own way" (tm). I suppose that's fine, but don't act like you're doing humanity a service by wiping your butt with a different hand ;)
Re: (Score:3)
> Trying to understand all those folders It hurts the widdle windows users' heads
> since they don't understand why they can't just keep throwing everything in C:\
(dryly) I see you've never visited \winnt\system, \winnt\system32, and the half-dozen or so directories with parenthesized "x86", "64", and/or "wow" that stupidly perverted the entire win64 file hierarchy. Sigh. We finally got symlinks & real directories for \users and \programs, then Microsoft realized its "error" and fucked them all up
Re:Errr (Score:4)
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.
Re: (Score:2)
Actually, Windows has had a totally baffling directory layout ever since XP.
http://gadgets.boingboing.net/2008/06/25/bill-gates-rant-from.html [boingboing.net]
Re: (Score:2)
Actually, Windows has had a totally baffling directory layout ever since XP.
And it got much worse in Windows 7.
Re: (Score:2)
/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 fil
Re: (Score:2)
Re: (Score:2)
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 t
Re: (Score:2)
Precisely. Some people have too much time on their hands.
Re: (Score:3)
what GNU/Linux fork isn't busy screwing with how things have been?
Debian.