Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora Aims To Simplify Linux Filesystem

samzenpus posted more than 2 years ago | from the like-sunday-morning dept.

Red Hat Software 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."

cancel ×

803 comments

When do we get compression? (2, Insightful)

SharkLaser (2495316) | more than 2 years ago | (#37927196)

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.

Re:When do we get compression? (3, Informative)

royallthefourth (1564389) | more than 2 years ago | (#37927262)

Make the directories you want compressed into mountpoints on the compressed partition.

Re:When do we get compression? (2)

Shikaku (1129753) | more than 2 years ago | (#37927280)

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:When do we get compression? (2, Interesting)

billcopc (196330) | more than 2 years ago | (#37927284)

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:When do we get compression? (1)

SharkLaser (2495316) | more than 2 years ago | (#37927372)

It can be really important if you're storing thousands of files (text, or anything that compresses well) and still need fast direct access to them. I just had a need for it this weekend (and still do), but the only solution was a stupid workaround and create and mount compressed partition to what files and folders I wanted compressed and then move them there. In Windows this would had just been a case of ticking the compression option in folder options dialog.

I've used it on Windows sometimes too, it's a simple yet important feature. There are times where it can save you thousands of MB's.

Re:When do we get compression? (1)

0123456 (636235) | more than 2 years ago | (#37927604)

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.

Re:When do we get compression? (1)

barrkel (806779) | more than 2 years ago | (#37927580)

SSD = very expensive small storage; mobility = no space for extra storage

Re:When do we get compression? (0)

Anonymous Coward | more than 2 years ago | (#37927624)

SSD = very expensive small storage; mobility = no space for extra storage

What about a 500 GB 2.5" hard drive ? Not good enough for mobility ?

Re:When do we get compression? (0)

Anonymous Coward | more than 2 years ago | (#37927636)

May not be all that useful in some cases, but I find it useful. I'm on a laptop with a 250GB drive and only 32GB of free space. I have all my applications and files compressed, saving me 35GB of space. Without this compression, I'd either have files I couldn't open when I need them or 0 free space. The latter means I need to spend money I don't have for a new HDD, the former is impractical.

Re:When do we get compression? (1)

Anonymous Coward | more than 2 years ago | (#37927294)

You might wanna upgrade that 20megabyte hard disk to something more modern, like maybe 100.

Re:When do we get compression? (1)

blair1q (305137) | more than 2 years ago | (#37927324)

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 (1)

tepples (727027) | more than 2 years ago | (#37927692)

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:When do we get compression? (2)

Arker (91948) | more than 2 years ago | (#37927296)

And no, I don't want to make an archive file, because I want to access those files and folders while they are compressed.

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? (3, Funny)

SuperQ (431) | more than 2 years ago | (#37927346)

This isn't 1995. Nobody cares about filesystem level compression anymore. Go buy a 2T drive.

Re:When do we get compression? (1)

SharkLaser (2495316) | more than 2 years ago | (#37927426)

It's not a matter of that, I have TB's of space. But if my files compress up to 90% and they take 1TB, isn't it much better if they only take 100GB? Otherwise it's just stupid waste.

Re:When do we get compression? (1)

0123456 (636235) | more than 2 years ago | (#37927536)

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:When do we get compression? (5, Insightful)

SuperQ (431) | more than 2 years ago | (#37927640)

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:When do we get compression? (2)

c2me2 (2202232) | more than 2 years ago | (#37927454)

It's not your business to tell people what they should want. And not every machine or situation is right for a 2TB drive. Flash drives, laptops, tablets, etc.

Re:When do we get compression? (5, Insightful)

antifoidulus (807088) | more than 2 years ago | (#37927524)

Actually there are valid reasons to compress at least some of your files beyond the need for saving space, namely that the speed differential between I/O(esp. platter drives) and CPUs is continuing to grow incredibly fast. The performance gap is getting to the point that for files that tend to compress(executables and libraries are among them), the time it takes to read the compressed file off the disk and then decompress it in memory may be less than the time it takes to read the entire uncompressed file from disk.

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? (4, Insightful)

skids (119237) | more than 2 years ago | (#37927586)

Add to that, in network attached storage solutions, every file you read is squeezed through something as small as a 1GBbps pipe.

Re:When do we get compression? (1)

barrkel (806779) | more than 2 years ago | (#37927590)

How will I get that into my Macbook Air?

Re:When do we get compression? (3, Insightful)

Anonymous Coward | more than 2 years ago | (#37927354)

And no, I don't want to make an archive file, because I want to access those files and folders while they are compressed.

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 usage change and you'll see. You can easily set up a situation where you do not have enough free disk space to open a compressed file, and that is not intuitive for a user.

What you want is an ability to compress small individual blocks of the file that can be accessed separately without having to decompress the entire file. But doing that creates all sorts of other problems such as how to efficiently allocate the space for the compressed contents which might change over time (and change size) without causing a great deal of additional fragmentation. This is rather harder to do.

Mod Parent Up (0, Offtopic)

Hatta (162192) | more than 2 years ago | (#37927448)

AC is Insightful and Informative.

Re:Mod Parent Up (1)

Surt (22457) | more than 2 years ago | (#37927620)

Regrettably, that was the last sign of the apocalypse. Doesn't look like we'll even make to 2012.

Re:When do we get compression? (4, Informative)

dmitrygr (736758) | more than 2 years ago | (#37927712)

wrong wrong wrong wrong wrong wrong wrong wrong just tried it. NTFS FS, 2GB free, file on there 30GB full size, compressed to 15GB. opens juts fine even though there isn't 30GB free there. also opens instantly (does NOT decompress 30GB anywhere)

Re:When do we get compression? (5, Interesting)

jd (1658) | more than 2 years ago | (#37927392)

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:When do we get compression? (1)

GioMac (862536) | more than 2 years ago | (#37927422)

It's out of the Subj.

Use BTRFS, which is available in Fedora too. BTRFS is aimed to be default in version 17.

Re:When do we get compression? (2)

mysidia (191772) | more than 2 years ago | (#37927514)

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 really not "production quality" yet.

Compression seems to be one of those things that Solaris excels at.

Of course this is useless if your storage hardware is low-end or you lack CPU, since while compression increases capacity, it doesn't increase how much of that storage you can have live data on at average activity

Re:When do we get compression? (0)

morcego (260031) | more than 2 years ago | (#37927526)

Filesystem level compression is something very dangerous. It is very easy to end up with corrupted files, not to mention the processing and memory cost of these operations. Because of that, you will also never have optimum compression, not to mention that if you store a compressed file inside a compressed filesystem, you might end up using more disk space than storing the raw (uncompressed file). And yes, the compression layer might be smart enough to not try compressing in those cases - another layer of complexity.

Several of these things are far from intuitive, causing plenty of grief for both the user and the support department.

Re:When do we get compression? (1)

peppepz (1311345) | more than 2 years ago | (#37927560)

Seriously, Windows has had this for over a decade.

You mean, since the last time Microsoft updated Windows' file system? I can't believe they're still using the aging NTFS when other operating systems have advanced file systems such as ZFS and BTRFS.

There's a few experiemental filesystems that can compress the whole partition, but still not individual files.

Correction: there's a next-generation, not experimental file system, BTRFS, that does that and also sports features that Windows 8 is missing. You can compress individual files or folders using the "btrfs filesystem defragment -c" command.

On top of that, if you want, you can use NTFS-3G which will allow you to use the legacy file system of Windows, NTFS, with all of its '90s features *including transparent compression of individual folders*.

Re:When do we get compression? (1)

Anonymous Coward | more than 2 years ago | (#37927582)

File system compression is not of much use these days. Big files, such as video and audio data, are already compressed and cannot be compressed further (at lest not by much). Same applies to docx or odf files, which are actually zip archives of XML files. Images are also compressed. Leaving only normal text files and some executables to be uncompressed. AS these files are very small compared to the other data, it is not of much use to implement or use an compression system for files or the whole volume.

Re:When do we get compression? (1)

CjKing2k (309058) | more than 2 years ago | (#37927606)

Simply put, it's not that important anymore. If you're talking about a decade ago, when your typical desktop drive was 20 gigs, then sure it made a difference. Now that sub-terabyte drives are on the way out, the added cost associated with transparent compression makes it almost completely useless.

Re:When do we get compression? (1)

Gumber (17306) | more than 2 years ago | (#37927648)

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.

Errr (-1)

Anonymous Coward | more than 2 years ago | (#37927244)

Gordian Know? dumbasses

Re:Errr (3)

jd (1658) | more than 2 years ago | (#37927466)

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.

Not a Mac dumb down, please (0)

Anonymous Coward | more than 2 years ago | (#37927246)

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?

Re:Not a Mac dumb down, please (2)

mattventura (1408229) | more than 2 years ago | (#37927348)

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.

Re:Not a Mac dumb down, please (1)

antifoidulus (807088) | more than 2 years ago | (#37927364)

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.

Re:Not a Mac dumb down, please (2)

Iskender (1040286) | more than 2 years ago | (#37927716)

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.)

If it ain't fix (1)

ickleberry (864871) | more than 2 years ago | (#37927256)

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

Re:If it ain't fix (1)

skids (119237) | more than 2 years ago | (#37927686)

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.

Good idea (1)

Tragek (772040) | more than 2 years ago | (#37927266)

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:Good idea (2)

l2718 (514756) | more than 2 years ago | (#37927300)

/usr/local/bin is not supposed to contain any system executables, only locally installed ones. Fedora does not install anything there already. In any case, /usr/local/ seems to have been replaced by /opt/ in most UNIX installations today.

Re:Good idea (1)

jimshatt (1002452) | more than 2 years ago | (#37927408)

I use /opt/ to install software in (that isn't available through the package manager) and then link its binaries in /usr/local/bin, which is on the PATH. This gives me a clear view of what I've installed myself, and still be able to execute it easily.

Re:Good idea (1)

GioMac (862536) | more than 2 years ago | (#37927482)

RPM packaged SW is never installed in /usr/local/, for /opt/ you can find a lot.

Re:Good idea (0)

Anonymous Coward | more than 2 years ago | (#37927474)

I think it would be good to consolidate them into one or two directories. When I first moved to Linux I had a hell of a time trying to figure out where a program was located when a file I was trying to open didn't have anything associated with it. I still do resort to "sudo updatedb;locate [string]" instead of manually searching for things and I've been using Linux for years. If it's hard for a geek to get used to, imagine how confusing it must be to someone who barely understands Windows.

Simple (3, Funny)

wsxyz (543068) | more than 2 years ago | (#37927268)

Just store everything in /
What could be simpler?

Re:Simple (1)

Anonymous Coward | more than 2 years ago | (#37927490)

/dev/null ?

Re:Simple (1)

satuon (1822492) | more than 2 years ago | (#37927546)

Microsoft hears you.

Dumb move (1)

Anonymous Coward | more than 2 years ago | (#37927270)

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.

Re:Dumb move (5, Interesting)

ThorGod (456163) | more than 2 years ago | (#37927434)

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:Dumb move (0)

Anonymous Coward | more than 2 years ago | (#37927528)

What I'd like to know is what's wrong with the FreeBSD file system, and why don't they just 'do that'?

That's what it does now.

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:\

Re:Dumb move (0)

Anonymous Coward | more than 2 years ago | (#37927438)

Completely agree.

Standardise (1)

Anonymous Coward | more than 2 years ago | (#37927278)

Why not standardise on /Program Files/ and /Windows/System ?

because id have to google 'space in find bash' (0)

Anonymous Coward | more than 2 years ago | (#37927362)

because i can never remember that FS1= whatever thing you use for bash when writing 'find' scripts

Re:Standardise (1)

SuricouRaven (1897204) | more than 2 years ago | (#37927396)

Or Program Files (x86) and system32. This problem isn't unique to linux.

Re:Standardise (1)

Surt (22457) | more than 2 years ago | (#37927660)

Don't forget about SysWOW64

Re:Standardise (1)

Anonymous Coward | more than 2 years ago | (#37927398)

Fuck it, /System and /Library

Re:Standardise (0)

Anonymous Coward | more than 2 years ago | (#37927412)

Its hardly a standard, besides Windows doesn't even use it always (as it adds x86 sometimes).
Then theres the fact that its a stupid name for something that doesn't only hold programs.
If you want to standardise it Windows style it should be called /Program Files and Config Files and Data Files and Libraries but not x86 Programs (and 64 bit when we move to 128 bit)/

Re:Standardise (0)

Anonymous Coward | more than 2 years ago | (#37927442)

Or at least spell out the current directories instead of the current three-letter designations.

Re:Standardise (1)

freedumb2000 (966222) | more than 2 years ago | (#37927662)

Why stop there? I'd go even further and use \Program Files\ and \Windows\System. A simple simple sed s/\//\\/g on all system source files should fix any incompatabilities.

Fedora, eh? (4, Insightful)

turgid (580780) | more than 2 years ago | (#37927286)

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:Fedora, eh? (1)

chill (34294) | more than 2 years ago | (#37927310)

Has he seen reason on PAM, yet?

Re:Fedora, eh? (1)

megalomaniacs4u (199468) | more than 2 years ago | (#37927554)

There is no reason for PAM ever

Re:Fedora, eh? (0)

Anonymous Coward | more than 2 years ago | (#37927670)

PAM What's that?

obligatory (-1)

Anonymous Coward | more than 2 years ago | (#37927304)

http://xkcd.com/927/

Fedora standards (0)

Anonymous Coward | more than 2 years ago | (#37927314)

Another reason not to use fedora. I hate how they're moving away from standards. Or even just unix traditions.
Also, does anyone really have a problem finding something in /bin and /usr/bin? Who are these people looking for files constantly.

This is bikeshedding.

Re:Fedora standards (0)

Anonymous Coward | more than 2 years ago | (#37927642)

Also, does anyone really have a problem finding something in /bin and /usr/bin? Who are these people looking for files constantly.

This is bikeshedding.

For one, you'd think that /bin would be for system stuff and usr/bin for applications. But no. I've come across apps that put stuff in /bin and all over the damn place. You do a find on the program name and shit pops up all over the goddamn place - including executables and libraries.

And then, when you're installing something not supported by your distro creator (fedora, Ubuntu, etc....), you have to go and "find" libraries and their dependencies and their dependencies to get your shit working. There's nothing I hate more than having an up to date system only to get some error that says, "... not compatible with this version of xxxx.o ..." Arrgggggg! So, it's back to "find" up and down your file system.

Help online? Ha! You'll see shit from '03 that says "Oh, yeah! It's in /usr/lib/xxx/lib/whatever' only it's not there! So, it's off to 'find' again.

Then, if you have some hardware that isn't supported, it's back to find up and down the file system looking for configs - which are placed any 'ole place - and libraries.

And then, you have folks who want to give it all to you! Great! Bit their package has an older version and they put it where they want to; thereby completely confusing the shit out of your version.

If I have to set up a server again, it'll be fedora BECAUSE of the file system simplification!

It aint broke (0)

Anonymous Coward | more than 2 years ago | (#37927332)

As a "most passionate partisan" I will not admit that its filesystem is "baffling to users". With most binaries in /bin, /sbin, /usr/bin/, and /usr/sbin ... what is the problem? Windows has its binaries in thousands of locations ... and it isn't "baffling to users" is it?

Re:It aint broke (1)

royallthefourth (1564389) | more than 2 years ago | (#37927498)

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:It aint broke (1)

0123456 (636235) | more than 2 years ago | (#37927544)

Actually, Windows has had a totally baffling directory layout ever since XP.

And it got much worse in Windows 7.

Re:It aint broke (1)

alcourt (198386) | more than 2 years ago | (#37927638)

/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.

etcetera directory (1)

Anonymous Coward | more than 2 years ago | (#37927358)

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.

Gordian Knot (1)

webbiedave (1631473) | more than 2 years ago | (#37927366)

Now, for those who did not know, there's no Gordian Know. It's Gordian Knot.

User Base (0)

Anonymous Coward | more than 2 years ago | (#37927382)

I am sure all 20 Fedora users will be excited!

no thanks (1)

Lawrence_Bird (67278) | more than 2 years ago | (#37927386)

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".

Re:no thanks (0)

Anonymous Coward | more than 2 years ago | (#37927548)

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".

I have to agree with your comment, especially since Slackware, the BSDs, and Arch (well to some degree anyways) do a pretty darn good job of making things easy to understand. Everything can be found in easy to remember places, while many others *cough* struggle to keep things consistent (oh idk like they were too lazy to just remember the difference between /usr/share/ and /usr/local/share, ... I mean really people get your act together. There was a time and place when users and admins actually knew how their filesystem was organized (and no it doesn't take a CS degree to understand it).

Seriously just go get an O'Reilly book or something for crying out loud.

Symlinks (0)

Anonymous Coward | more than 2 years ago | (#37927390)

Just stash the real stuff in those directories, and have a way (i.e. add/remove feature) to create / destroy symlinks in those legacy places. Then, after years of nobody using those "features", you can remove them.

Bad Idea (1)

GeneralTurgidson (2464452) | more than 2 years ago | (#37927400)

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.

Re:Bad Idea (1)

Shimdaddy (898354) | more than 2 years ago | (#37927510)

Please, generalturdigson, enlighten /. (and any Fedora team members who are reading) as to your reasons for calling them stupid.

/bin, /sbin had their functions (5, Informative)

l2718 (514756) | more than 2 years ago | (#37927402)

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).

Baffling to users ? (2)

alvieboy (61292) | more than 2 years ago | (#37927404)

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 ?

Re:Baffling to users ? (1)

steveb3210 (962811) | more than 2 years ago | (#37927522)

/usr/local (or /opt if you insist) are quite vital - when I custom compile something for a server, I prefer to keep anything I install completely and 100% separate from the packages that the system install..

Ruby for example, I compile with --prefix=/usr/local/ruby...

I had to custom install node for a production environement recently, --prefix=/usr/local/nodejs...

Should later on I want to replace ruby or node or whatever, its as simple as replacing or removing a single directory rather than trying to separate compiled from packaged. These two are especially good examples because they both have package managers themselves. Since by default they will install relative to the binary for the program, you get all your language-specific packages installed all in the same place.

Re:Baffling to users ? (1)

alcourt (198386) | more than 2 years ago | (#37927680)

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.

no thanks (2)

bsDaemon (87307) | more than 2 years ago | (#37927420)

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? (1)

Scareduck (177470) | more than 2 years ago | (#37927478)

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? (1)

Superken7 (893292) | more than 2 years ago | (#37927486)

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.

"union" filesystem can do this already, no? (1)

yossie (93792) | more than 2 years ago | (#37927500)

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..

This is stupid (0)

nurb432 (527695) | more than 2 years ago | (#37927502)

There are reasons things are as they are, and mucking about with something so fundamental because it 'confuses some newbies' isn't a valid reason.

Newbies can learn. Disasters are hard to undo. Leave things be.

Re:This is stupid (0)

Anonymous Coward | more than 2 years ago | (#37927644)

Why don't you explain the reasons then, and more importantly, why they're still relevant?

Re:This is stupid (0)

Anonymous Coward | more than 2 years ago | (#37927700)

I second that. It would just piss me off. How hard is it, seriously? If I can learn the Linux filesystem, so can a newbie.

GOBO (1)

Anonymous Coward | more than 2 years ago | (#37927506)

even simpler (2, Interesting)

FudRucker (866063) | more than 2 years ago | (#37927520)

forget /usr, just do /bin /dev /etc /home /lib /media /proc /root /sbin /sys /tmp /var

So windows is right (1)

microbee (682094) | more than 2 years ago | (#37927540)

Putting everything under C:Windows and C:Windows/system turn out to be the way to go.

No thanks (0)

vadim_t (324782) | more than 2 years ago | (#37927566)

First, this makes some setups a lot more annoying. The /bin and /lib dirs might be rather obscure these days, but the separation still comes ocassionally handy with strange disk layouts.

Second, since when do normal users need to care about the distinction? All those are in $PATH anyway, so it doesn't matter whether bash is in /bin or /usr/bin for most end user purposes.

Third, what's with the weird obsession with messing with what works? Ubuntu is annoying enough already with the upstart thing. I don't need more stuff like that. Please leave the base system the hell alone.

no long filenames ? (0)

Anonymous Coward | more than 2 years ago | (#37927610)

why put the executables in a directory called bin ?
its not 1980

how about making the filesystem a bit more intuitive, call it "Programs" or "Applications"

the file system layout is one of the worst things about Linux, we have had long file-name support in "other" OSs for years, yet Linux insists on put things in ridiculous cryptic directory names /usr /bin /etc ?

gotta be some kind of joke that in 2011 thats the best linux can do

A

The idea is problematic (5, Insightful)

Sipper (462582) | more than 2 years ago | (#37927668)

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.

Gordian "know" (0)

Anonymous Coward | more than 2 years ago | (#37927710)

Did you mean "Gordian knot?" It would be nice if you proofread. Ever. At all.

a few facts... (1)

nirik (5709) | more than 2 years ago | (#37927714)

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 [fedoraproject.org]
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.

GOBO Linux (4, Informative)

pentalive (449155) | more than 2 years ago | (#37927722)

http://www.gobolinux.org/ [gobolinux.org] Combines executables and necessary libraries each in their own directory under '/programs' Uses links to show files in traditional places.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...