Slashdot Mirror

← Back to Stories (view on slashdot.org)

Rage Against the File System Standard

Posted by CmdrTaco on from the stuff-to-read dept.

pwagland submitted a rant by Mosfet on file system standards. I think he's sort of over simplified the whole issue, and definitely wrongly assigned blame, but it definitely warrants discussion. Why does my /usr/bin need 1500 files in it? Is it the fault of lazy distribution package management? Or is it irrelevant?

10 of 612 comments (clear)

  1. he's pretty far off base by kaisyain · · Score: 5, Interesting

    Anyone who claims that RedHat started the use of /usr/bin/ as a dumping ground can't be taken seriously. Pretty sure slackware and SLS did the same thing. Same goes for Solaris, AIX, AUX, Sun/OS, Irix, and HPUX.

    It's not about lazy distributors. It's about administrators who are used to doing things this way and distributors going along with tradition.

  2. Linux From Scratch by MadCamel · · Score: 4, Interesting

    This is _EXACTLY_ why I use LinuxFromScratch. You do not HAVE to use the package managment system, you can install anything *just* the way *you* want it. X applications in /usr/bin? No way jose! (My appoligies to anyone named Jose, I'm sure you are sick of hearing that one), /usr/X11 it is! If you are not happy with the standards, make your own, it just takes a little time and in-depth knowledge.

  3. Use /usr/local for add-ons, keep /usr clean by Baki · · Score: 4, Interesting

    ~> ls /usr/bin | wc -l
    403
    ~> ls /bin | wc -l
    36
    ~> ls /sbin | wc -l
    91
    ~> ls /usr/sbin | wc -l
    220
    ~> ls /usr/local/bin | wc -l
    796

    This is FreeBSD, which installs a relatively clean OS under /usr and puts all extra stuff in /usr/local (sometimes the executable is in /usr/local/bin, sometimes in /usr/local//bin).

    I like that much more, it is the old UNIX way to separate the essential OS from optional stuff. It really is a pity that most Linux distro's dump everything directly in /usr.

    As for my slackware, I installed only the minimum, and roll my own packages for everything I consider not to be 'core Linux'; all these packages go under /usr/local. It can be done, and keeps things tidy and clean.

  4. Translucent file system by Pseudonym · · Score: 5, Interesting

    Even better would be if Linux had a translucent file system. Simply mount all the path directories on top of each other and let the OS do the rest.

    For the uninitiated, a translucent file system lets you mount one filesystem on top of another filesystem, the idea being that if you tried to open a file the OS would first search the top filesystem, then the bottom one. In conjunction with non-root mounting of filesystems (e.g. in the Hurd) it removes the need for $PATH because you can just mount all the relevant directories on top of each other.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    1. Re:Translucent file system by Just+Some+Guy · · Score: 5, Interesting

      FreeBSD comes with something called a union filesystem that is exactly what the poster described. From man (8) mount_union:

      DESCRIPTION
      The mount_union command attaches directory above uniondir in such a way
      that the contents of both directory trees remain visible. By default,
      directory becomes the upper layer and uniondir becomes the lower layer.

      Non-FreeBSD users can read an online version.

      --
      Dewey, what part of this looks like authorities should be involved?
  5. Related to yesterday's story by vrt3 · · Score: 5, Interesting

    I think the fundamental problem here is related to yesterday's story about new user interfaces. It's a problem of how and where storing our files. Regarding applicationsn, there are two ways to do it: you can store all files (binaries, config files, man pages, etc.) of the same application in the same directory, or you can store all files of the same type from different applications in their respective directories (all config files in /etc, man pages in /usr/share/man (I think), etc.).

    Both approaches have their advantages. The problem with hierarchical file systems is that we have to choose one of them. I would love to see a storage system where we can use both ways _at the same time_. A system that groups file depending on relationships they have. Such that 'ls /etc' gives me all config files for all apps, and 'ls /usr/local/mutt' shows me all mutt-related files, including it's config file(s).

    I have no idea how to implement such a beast. I'm thinking about a RDBMS with indices on 'filetype' and 'application', but I would love to see something much more flexible. All pictures should be accessible under ~/pictures and subdirectories, all files relating to my vacation last year in ~/summer2000. Files relating to both should be in ~/pictures/summer2000 _and_ ~/summer2000/pictures.

    To a certain extent, this can be done via symlinks, but it should be much easier to deal with. You shouldn't have much manual work

    --
    This sig under construction. Please check back later.
    1. Re:Related to yesterday's story by droleary · · Score: 5, Interesting

      I think the fundamental problem here is related to yesterday's story about new user interfaces [slashdot.org]. It's a problem of how and where storing our files.

      You could also trace it back to the hierarchical database article, which is when I started making a lot of posts on the subject. It seems there is finally a lot of interest being generated about this sort of thing.

      I have no idea how to implement such a beast. I'm thinking about a RDBMS with indices on 'filetype' and 'application', but I would love to see something much more flexible. All pictures should be accessible under ~/pictures and subdirectories, all files relating to my vacation last year in ~/summer2000. Files relating to both should be in ~/pictures/summer2000 _and_ ~/summer2000/pictures.

      This is exactly the sort of thing I'm doing with my Meta Object Manager (MOM) software called Mary. Metadata in the form of attributes and values is associated with each file/object and you can do a query (both textually and graphically) on that metadata. For simple paths like you describe, it is a value query irrespective of a particular attribute, but there is support for a more structured "path" (I actually call it a "focus" as it restricts your focus to a subset of the objects on the system) like /type=picture/location=Hawaii/year=2000. Because the focus items are metadata attributes, order is not significant. With such a system, there are no directories or symbolic links; it's all dynamically structured based on what your metadata focus is at any particular time.

      Mary is just in the alpha stages at this point, but it already works well on the command line for the type of things you describe and I'm using it myself to manage nearly 350,000 objects that have been flowing through my system. I'm not exactly sure when it'll be ready for public consumption, and it'll require a GNUstep port to get working on Linux (I'm doing development on Mac OS X) systems. I was hoping year end, but I don't think I'll have the time. Summer 2002 has a nice ring to it, though. :-)

  6. RiscOS... by mirko · · Score: 4, Interesting
    In RiscOS, applications are directories which contains several useful files (besides the app binaries, conf or data files):
    • !Sprites[mode] contains the icons to be used with the app and whichever file to be associated with after its filetype
    • !boot which contains directives (associations, globalvariables, etc.) to be executed the first time the Filer window that contain this app is opened (the app is "seen" by the Filer)
    • !run which describes any action to be associated with a double-click on the app icon

    There's also a unique shared modules directory in the System folder.

    This system is at least 10 to 15 years old (not sure Arthur was as modulable, though) and sure proved to be an excellent way to deal with this problem...
    --
    Trolling using another account since 2005.
  7. FreeBSD by sirket · · Score: 4, Interesting

    The file systems on a Unix system make a lot of sense, when people use them correctly.

    /bin for binaries needed to boot a corrupted system.

    /sbin for system binaries needed to boot a system.

    /usr/bin for userland binaries installed with the base system.

    /usr/sbin for system binaries installed with the base system. The are not programs required to boot the system.

    /usr/local/bin for locally installed user binaries such as minicom, mutt, or bitchx.

    /usr/local/sbin for locally installed system binaries such as apache.

    Large locally installed programs such as Word Perfect get installed in a sub directory of /usr/local but they put a single executable in /usr/local/bin so that you do not need to change your path.

    FreeBSD has only about 400 programs in a complete /usr/bin. Other programs are spread about the file system in sensible locations or are user installed. Possibly the only directory that does not make a whole lot of sense is /usr/libexec (where most of the internet daemons are kept).

    -sirket

  8. Why package management sucks by TomatoMan · · Score: 5, Interesting

    Package management is a way to standardize the way software is installed, upgraded, and removed.

    It sounds very appealing. The problem is that a lot of the software I need right now (openLDAP, openSSL, etc) has packages that are a full development generation old. There isn't a 2.x package yet for openLDAP on RH 6.2, for example, and I don't think anybody in particular is in charge of building it.

    Building from source is the only way to be current, although it is often an immense pain in the ass.

    The other gripe I have is about packages failing to recognize libraries that are installed just because they weren't installed by a package manager. Yes, you can force a --nodeps sometimes and cross your fingers, but you shouldn't have to lie to the software to get it to work. Package managers should be a little smarter and be able to look around a little to satisfy dependencies.

    If the package system really worked cleanly, it would be great, but I'm still using Pine 4.20 on my box because of conflicting dependencies in the 4.3x packages. I'm about to nuke the whole thing and build Pine from source - which I'll do as soon as I can get those library dependencies solved.

    Grr.

    --
    -- http://frobnosticate.com