14 ms·

Understanding the bin, sbin, usr/bin , usr/sbin split

• saulrh 15y ago
  There's an interesting piece of advice at the bottom of this post - the author symlinks /bin, /sbin, and /lib to /usr/whatever. Anybody else have an opinion on that practice? It's kind of unnecessary, but it also doesn't break anything.
  • bryanlarsen 15y ago
    That's an over simplified version of what the next Fedora is going to be doing. http://fedoraproject.org/wiki/Features/UsrMove http://fedoraproject.org/wiki/Features/UsrMove The Fedora move is why this link got posted and is getting upvotes.
    • waitwhat 15y ago
      While they're at it, they should move /usr/src somewhere else (/var/src?)
  • jrockway 15y ago
    There are a variety of tools that live in /bin but are symlinked in /usr/bin, at least on my 10.04 LTS box: $ for f in /bin/*; do [ -e "/usr$f" ] && echo /usr$f; done; /usr/bin/dumpkeys /usr/bin/ksh /usr/bin/less /usr/bin/lessecho /usr/bin/lessfile /usr/bin/lesskey /usr/bin/lesspipe /usr/bin/loadkeys /usr/bin/mail /usr/bin/nano /usr/bin/tcsh /usr/bin/touch /usr/bin/which /usr/bin/zsh This has the potential to blow something up during the installation procedure if it is not carefully crafted to realize that these files are the same and to ignore link's failure.
  • calloc 15y ago
    It would break FreeBSD's single user mode when using the defaults during installation for partitioning. FreeBSD's default install creates: /, /usr, /tmp, /var and swap space. When you boot in single-user mode all you get is / and nothing else. If everything was in /usr you wouldn't be able to mount /usr ... :P
    • waitwhat 15y ago
      Presumably if FreeBSD went down the same path as Fedora, they could also change the default partition layout.
      • IgorPartola 15y ago
        Wouldn't that interfere with the core BSD system vs p ackage binaries/libs paradigm?
        • X-Istence 15y ago
          Packages/binaries/ports tree installs into /usr/local/. See man hier [1]. For example, on a FreeBSD install, it is perfectly safe to rm -rf /usr/local/. Your system will still boot without issues. [1] http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
          • lmm 15y ago
            Which I find is actually quite problematic; "make install" by default puts things into /usr/local, and I would prefer to distinguish between things I've installed and things ports have installed. (Specifically, I need to build my own mplayer, but I also need the ports version installed as some other ports depend on it).
            • X-Istence 15y ago
              Feel free to change the prefix passed to the packages you install by hand. /usr/local is the default used by almost all packages I am familiar with, if for example you want /opt you have to modify that yourself.
• lanstein 15y ago
  great sig: GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
• drewcrawford 15y ago
  > I'm still waiting for /opt/local to show up... Wait no longer: http://guide.macports.org/ http://guide.macports.org/
  • farmdawgnation 15y ago
    If someone else didn't say this already, I was going to. Although, I've got to admit that Fink's solution of /sw isn't much better.
• ggchappell 15y ago
  The title isn't quite correct. He explains /bin vs. /usr/bin, but not /bin vs. /sbin. My understanding for the latter is that /bin is "normal stuff", while /sbin is system maintenance. But, hey, maybe that split is actually there for obsolete historical reasons, too. Does anyone know?
  • bebop 15y ago
    My understanding is that bin is used for programs that do not require super user privileges, where as sbin programs do.
    • rcthompson 15y ago
      And the reason for splitting them is so that normal users don't have the super-user programs in their $PATH, since they would be useless there. Of course, this is arguably obsolete now since the advent of sudo, policykit, and so on.
      • wmf 15y ago
        For some reason traceroute is in /sbin, but it works for normal users. Probably another historical accident (did it used to require root?).
        • gchpaco 15y ago
          Conventional (that is, without capabilities) traceroute and ping were setuid root because it there was no provision for emitting ICMP packets in the network APIs and only root could assemble raw packets.
        • koenigdavidmj 15y ago
          The particular way traceroute runs is implementation-defined. Some use ICMP echo request packets (ping), which you have to be root to send on most Unices. Most of them, however, use UDP packets instead.
      • nathan_f77 15y ago
• agumonkey 15y ago
  Glorious. More history bits like this please. At the same time, makes you think about dropping FHS .. yeah I said it.
  • kryptiskt 15y ago
    A distribution that does just that is NixOS (http://nixos.org/nixos/ http://nixos.org/nixos/). It has to, because it's purely functional (new stuff shouldn't overwrite any of the old stuff) and it has to support several different versions of the same package being installed at the same time. It is awesome, especially the easy rollback and that you can specify an entire system with a recipe. Still, it feels strange for us who are used to mainstream Unix systems.
    • aaronh 15y ago
      GoboLinux does it too. And for that matter, another "unixy" OS uses "bundles" to keep all of an apps files together instead of splattering them all over the OS: Mac OS X.
      • X-Istence 15y ago
        OS X isn't just "unixy", Snow Leopard is UNIX certified...
    • agumonkey 15y ago
      Funny I just installed my first nixos yesterday. They indeed can move away from FHS even if they support it. As said before GOBO does that too; there was a handful of distros at max.
• aaronh 15y ago
  much of the original traditional unix file system hierarchy is basically redundant and unnecessary in the modern age. for a good overview (from the author of a linux distribution which departs completely from this tradition), see: http://www.gobolinux.org/index.php?page=doc/articles/clueless http://www.gobolinux.org/index.php?page=doc/articles/clueles...
• tmhedberg 15y ago
  The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be mounted, say, from a network share. This is useful because then network admins can install software to the common `/usr` share and make it immediately available to all machines which mount that share. The `/sbin` and `/usr/sbin` directories are for commands needed only by administrators, which will not normally be used by regular users. Most systems don't really require this separation, but it does make sense. Perhaps the historical reason for doing it is no longer a factor, but that doesn't mean it's perpetuated merely because of tradition. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html http://www.pathname.com/fhs/pub/fhs-2.3.html
  • hollerith 15y ago
    I know about FHS and the rationale FHS uses for the continued existence of /usr, I just do not agree with it (nor with the existence of /usr/share).
    • tmhedberg 15y ago
      I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.
      • kstenerud 15y ago
        Because everyone's idea of what "makes sense" is different. Thus: /bin /usr/bin /usr/share/bin /usr/share/local/bin /usr/local/bin /usr/local/share/bin /opt/bin /opt/some/clever/path/system/bin Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's considered "essential" on some systems but not others. It reminds me of this: http://xkcd.com/927/ http://xkcd.com/927/
• rachelbythebay 15y ago
  Let's not forget the whole partition split situation due to the 1024 cylinder limitation. Once upon a time, you couldn't get to certain parts of the disk from your bootloader (using BIOS calls), so you had to make something like a tiny /boot which would hide < 1024. This situation has only improved a little. There are still lingering bits of it here and there, depending on how deeply you poke and which distribution you have installed.
  • nailer 15y ago
    It annoys the hell out of me that people are still imposing the 486-era 1024Cyl and 8GB limitations in 2012. ArchLinux, for example, still really, really wants you to make a /boot.
    • triffidhunter 15y ago
      There are plenty of good reasons to make a /boot. Encrypted laptops for example.
      • dredmorbius 15y ago
        Excellent point, I forgot that use case.
      • vacri 15y ago
        I ran into problems when /boot was part of the larger xfs filesystem, so had to create an ext3 /boot instead.
        • sirclueless 15y ago
          And in general, if you want to use any filesystem that your operating system supports but your bootloader does not, you need a /boot
      • EvilLook 15y ago
        People who are serious about having an encrypted system should have absolutely none of the bootstrap process residing unencrypted on the disks of that system because somebody could take out the drive, look through the boot process, and log your passphrase. I have an encrypted laptop that boots from a read-only USB key that is attached to my keyring. It will only boot from this keyring (and a backup CD-R that I have), and the system and the boot media are never stored together. Before USB keyrings became common, I would have the boot media be a CD-R.
• triffidhunter 15y ago
  The Fedora changes are bikeshedding. They start with wanting to change something, and then find a justification. Why not just put all the executables files in /Program Files/? All this to save a few bytes in $PATH, to avoid problems with systemd, and to avoid fixing udev.
  • aaronh 15y ago
    why not put all .txt files in /txt? we have .../man for man pages, .../lib for libs, .../src or source and .../include for C includes after all.
    • im3w1l 15y ago
      I know, I know! Why not let the extension indicate which package a file belongs to? Then we could have /txt/readme.GTK
  • sirclueless 15y ago
    That would break compatibility with a lot of existing scripts, which look for things in /bin, /lib, /usr/bin etc. There are specific reasons why having a single mount point for all OS-provided binaries is a good idea, for example because maintaining a split that differs across distros and unixes is a maintenance nightmare. The main counterargument -- that it is desirable to have a minimally functional system without /usr mounted -- has been obsolete for years.
• nailer 15y ago
  Way, way too long. Go read the FHS: - If it's needed to boot the system, it belongs in / - Binaries for normal users are in bin, system (i.e., root user only) binaries are in sbin That's all.
• ChuckMcM 15y ago
  Wow. As someone who was there (I know dating my self here) reading this is kind of like that scene in Sleeper where the person from the future is trying to understand artifacts from the past. So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem was introduced as a way to keep 'packages' separate from 'system'. The difference between /bin and /sbin was that sbin was 'static-bin' which is to say everything in it was statically linked and could run without any libraries being available. The fact that Linux starts up differently is because Linux never was UNIX they are two different OSes, pretty much from the ground up. They use similar concepts, processes, file descriptors, Etc, but they are two different species. FreeBSD on the other hand is a derivative of UNIX and last time I checked it started up in a similar way. The lack of space on the RK05s was indeed the reason for the addition of /usr/{lib, bin} and the general consensus at Sun and AT&T in the 80's was that the root file system contained the system, and the /usr file system contained stuff that was not-system. AT&T (the guys that 'owned' UNIX) had some pretty detailed specifications about what lived in what directory and why. It was a "BigDeal" (tm) to add a new directory in the root file system so new directories, when they were proposed, appeared under /usr. And once /opt existed it gave people free reign to create their own trees. Early package managers would build /opt/<package>/{bin/lib/share/man} and the downside was that ones path variable got longer and longer, and there arguments about if there should be more constraints on opt.
  • cbsmith 15y ago
    I also have no memory of /home even existing in roughly the first decade of Unix's existence.
    • spitfire 15y ago
      home directories iirc, lived in /u (/usr these days)
      • bodyfour 15y ago
        Depended completely on the site. The first UNIX machine I worked on (ca 1985-1986) still was putting them in /usr for instance. There were certainly sites that used /u for what is now commonly /home (or /export/home on Solaris, /Users on OS/X, ...) This was not something that predated "/usr" though: /usr was already added back in the early 1970s (the linked article was correct about that, although it got many other details wrong) Basically /usr was originally only for home directories (as the name implies) Then it became the place for anything you didn't want to use the precious space on the root filesystem for (hence /usr/bin popped up, and later things like /usr/dict/words) Finally, it became so cluttered that people started locating home directories elsewhere and now the name "/usr" is completely unrelated to its actual purpose.
• calloc 15y ago
  I still have various partitions: /, /var, /usr, and /tmp (on a single slice). When I am in single user mode the only binaries I have available are in /bin. Unless I mount /usr that is all I have access to, so the split still makes perfect sense. A lot of Linux distributions by default suggest using the entire disk and creating a single partition named /. In that case it doesn't make sense to have the various different locations since mounting / means you have /usr/bin as well. I don't want a user being able to fill up the hard drive stopping me from writing my logs, stopping me from logging in or various other things (yes, i've filled up my / partition at one point and was unable to log in because SSH was failing to log something or other). There are also security reasons and being able to set various security flags on mount makes it easier to secure a machine as well (such as noexec on /tmp and or /var).
  • rosser 15y ago
    If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)
    • dredmorbius 15y ago
      'Nix allows mounts at any arbitrary point in the filesystem hierarchy. While you could symlink /var/tmp to /tmp, you could also dedicate a filesystem to it. Given that the strict definitions differ (/var/tmp does persist across reboots, /tmp may persist), you risk annoying/disapointing someone at some point if you do otherwise.
      • justincormack 15y ago
        I am sure I have used systems with tmpfs /var/tmp.
        • mgedmin 15y ago
• xenator 15y ago
  Cargo cult driven development
• emillon 15y ago
  So, /usr really means "user", and the "Unix System Resources" acronym was put together afterwards. Interesting, thank you !
  • taopaipai 15y ago
    I knew it as "User Shared Resources".
  • tomprince 15y ago
    I don't think I have ever heard that acronym before. I don't think it is common usage.
    • prewett 15y ago
      I've heard "user shared resources" which is similar. I'm glad "usr" meant "user", though, I can go back to naming my home directories on Windows "usr" instead of "home" :)
• dreamdu5t 15y ago
  Directories that are based on objective criteria don't have this problem. For example /dev is defined by objective criteria, and thus there's not much argument to what goes into /dev. We should only have core directory structure defined by objective criteria.
  • justincormack 15y ago
    They start like that, like /proc did, and then get other stuff.
  • joeyh 15y ago
    Except for /dev/MAKEDEV (required to be there by the FHS and for hysterical raisins). And then there was all the crap udev used to put in /dev/.udev/, which has thankfully migrated to /run.
• peterwwillis 15y ago
  Oh man... if only we had all statically-compiled Linux systems these days. Sure it'd be a pain to deploy changes in libraries, but less dependency-breaking consequences means you can push a patch to a single application without testing a whole suite of dependent apps. The really hacky solution to that seems to be building versioned packages in versioned directory paths (e.g. "/opt/lib/db/4/4.2/4.2.52/libdb.so") and mess with linker paths and create a sprawling tree of symlinks and wrappers for weird use cases. With a custom package manager it works really well: run 6 conflicting versions of the same library and just build apps against the library you know works, instead of fighting to get everything running on one compatible library.
  • taopaipai 15y ago
    The stali(static Linux) project is an interesting try at that.
  • rlpb 15y ago
    > Oh man... if only we had all statically-compiled Linux systems these days. Would you mind buying me a memory upgrade when this happens? I'll need one.
    • corysama 15y ago
      I honestly have no clue how much extra memory this would cost. I can see it being a big issue on embedded systems. But, with 512 megs being considered very low on modern desktop/server systems, I always thought the vast majority of recent memory use was data rather than code. Roughly how many processes are you running? Can anyone give a wild-assed guess how much memory it take to boot and load gmail in FireFox on a statically linked Linux?
      • yew 15y ago
        You shouldn't see that much difference, at least on a system designed for static linking (modern GNU/Linux is explicitly not such a system, see http://www.akkadia.org/drepper/no_static_linking.html http://www.akkadia.org/drepper/no_static_linking.html). There's still quite a bit of potential for interprocess resource-sharing. If you somehow managed to get a statically linked Firefox (I think it would be very difficult, given the degree to which Drepper has abandoned the idea) on a modern Linux system, though, the resource usage would admittedly probably be quite impressive.
• comex 15y ago
  It drives me crazy every time I'm on a Linux system and ifconfig is in /sbin, and not on users' PATH, even though the no-argument form works perfectly fine as a user.
  • vacri 15y ago
    use 'ip' instead, ifconfig is deprecated. 'ip addr show' is the simple replacement for 'ifconfig', but ip is pretty flexible in what it can do.
    • X-Istence 15y ago
      Why? What exactly does ip bring to the table that ifconfig doesn't have? Why am I required to learn YET another tool to do something that ifconfig has no problems doing. On linux to configure a wireless device you have iwconfig and ifconfig. And you have to use each in a different order to get it work. Whereas in FreeBSD I have ifconfig and it does all of it.
      • rlpb 15y ago
        Most newer advanced networking is unavailable in ifconfig. ifconfig and route are now just there for backwards compatibility. The ip tool lets you do all of what ifconfig and route can do, and more.
      • akira2501 15y ago
        I would typically agree with you; but the thing that I have really enjoyed in the transition to iproute2 is that ip handles all of: link state, address configuration, arp, tunnels, routing, transformation and a few other obscure things. It brings these together into one tool and unifies the argument syntax for all of them, I find it much easier to play with the network stack using 'ip'.
      • mikemaccana 15y ago
        Ifconfig will fail completely in some cases. Eg, an alias on a vlan on a bond.
    • 15y ago
• drhowarddrfine 15y ago
  Reason #9364 why I am soooo glad I stick with FreeBSD.
  • jamesgeck0 15y ago
    How does FreeBSD handle this?
    • X-Istence 15y ago
      man hier http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
• dredmorbius 15y ago
  And why / /usr split still makes sense: If it's needed to boot, it goes in root: boot images (including root filesystem) can be initrds, bootp images, flash sticks, or other similar tools. Maintaining the discipline of keeping what you need in / and what you don't need to boot in /usr helps when you're trying to minimize boot images, troubleshoot, and/or just simply keep things comprehnsible. Different partitions can be mounted differently: There are still a few things in the root FS which are written periodically, especially in /etc. By contrast, /usr is largely static. They can be mounted writeable vs. read-only (dittos /boot BTW). Root may require device permissions. Both require suid (but /home doesn't). For various degrees of security and self-inflicted foot-gunshot incidents, mounting with minimal permissions can be useful. Not all bootloaders handle all filesystems and storage: Applies more to /boot, but particularly for exotic / networked storage, ensuring that early-stage bootstrapped filesystems are accessible with a minimum of fuss can be useful. The arguments from Fedora about the ability to manage a system from within an initramfs are particularly amusing given RHEL's traditional use of a non-interactive, script-only shell: Yes, that's right, you can't exit out of the initramfs shell to do maintenance. Debian's 'dash' shell is not only smaller than the RHEL equivalent, but supports interactive use. Go figure. (Apologies if this has changed recently but it was true as of the past year or so). Shared/network mount purposes: A read-only, shared /usr filesystem can be used and accessed by multiple systems. Maintaining the root /usr split ensures that local system commands (if necessary) can be provided independently of the shared bits. While the origins of /bin vs. /usr/bin lie in what are now largely irrelevant disk capacity constraints, there are a number of reasons why maintaining the split continues to make sense. As has been noted, a fair bit of hierarchy persistence is on account of differentiating between differently-managed packages at different parts of the system. As the guy who gets to come in, comprehend, rationalize, and clean up systems afterward, I can assure you that a logical ordering and seggregation does help markedly. For distros with a decent package management policy and toolset, there's no particular problem to maintaining this. $PATH variables already make the end-user impact essentially nil. For those who wish to combine things, union mounts or symlinks can certainly be used, again, with little or no end-user impact. For some embedded/small systems this makes sense. There's no reason to force one-size-fits-all on everyone, however. I'm also generally opposed to arbitrarily adding top-level directory trees. The naming rarely stays consistent over time (business unit / institutional name changes are notorious). And it tends to complicate matters especially concerning backups and where essential local data lives. Tempest in a teapot.
• vacri 15y ago
  I've been liking the new location /srv, where you stick things that are custom to that machine. No more trying to guess where the previous admin thought files should go (/usr/share? /usr/local? /usr/foo?). http://www.linuxtopia.org/online_books/linux_beginner_books/linux_filesystem/srv.html http://www.linuxtopia.org/online_books/linux_beginner_books/...
  • DrCatbox 15y ago
    You dont stick things that are custom to that machine in /srv, thats not what the article you linked to says. Its for serving using various services, so you would have /srv/http /srv/ftp and so on, you dont put packages/programs into /srv
    • vacri 15y ago
      Looks like I might be misusing it then. I've been migrating some old spaghettied servers to single-use VMs recently, each server has had almost half a dozen admins all with their own weird ideas. The idea of saying 'hey, all the custom stuff is in this directory' for future admins is seductive. Basically I'm replacing half a dozen admins' peculiarities with one admin's peculiarity...
• mtree 15y ago
  Alas, sbin is not always true to its name. Though static-linking was originally used for a different purpose, today statically linked binaries make my life easier, and it has nothing to do with space constraints. Paths are a pain in the neck. It feels like 90% of the work we have to do at the prompt is typing/automcompleting paths, or symlinking or setting env variables to deal with paths. We certainly need a way to differentiate "system" stuff from "user" stuff. And on BSD, one can do this with the mtree spec files. mtree is one of my favourite utilities. One that is of course absent in Linux. Linux could never have an mtree because its userland development has been too haphazard. Moreover, different "distros" are always pushing for idiosyncratic changes. The goalposts move much more frequently than with BSD. Moving goalposts are also a pain in the neck.
• Osiris 15y ago
  As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suited to today's much more complicated GUI applications. Mac OS X, I think, has done a decent job of structuring the file system to be more user friendly despite the -nix background. Modern use cases typically revolve around either installation and use of specific applications, often with dozens or hundreds of files needed, and data storage. In Windows/Mac, applications (for the most part) are installed into their own individual application folder and a GUI (as opposed to the PATH) is used to provide easy access to the application. This makes it easy to 1) know where to put a program you're installing, 2) know how to locate a program after install, and 3) keeps all the application components in a single place for easy move or removal. In my somewhat limited experience with Linux, I find that the complicated nature of the file system makes package management systems necessary to simply keep track of where all the files are: executable in /usr/local/share/bin, configuration files in /etc, libraries in /usr/lib, and I'm not sure where non-binary resources of an application get stored. I once installed my favorite browser (Opera) in Ubuntu. It didn't make a desktop or Applcation menu icon for some reason, so I figured I'd just go make a icon to point to it. It took quite a while to just figure out where the executable was at. This could very well be one of the reasons that many people find Linux on the desktop difficult to use. They don't understand where anything goes. I hope that one day one Linux distribution will at least step up and consider restructuring the file system to be more friendly and straight forward and to take advantage of the availability of long file names.
  • Florin_Andrei 15y ago
    I learned Linux pretty well before I learned Windows (I was an early adopter) and I felt equally baffled by Windows at a time. I felt nothing made sense. :)
    • contextfree 15y ago
      I don't think either make any sense. I guess you could give Windows the nod for not really even making any pretense of making sense (my favorite detail is how 64-bit system files go in "System32" and 32-bit system files go in "SysWOW64"). OTOH while I never got the /bin /sbin /usr/bin /usr/sbin thing, I always vaguely assumed there was some deep reason behind it that I just didn't understand.
• snowape 15y ago
  Why did the Fedora team choose to move /bin -> /usr/bin etc instead of moving stuff out of usr into root (/usr/bin -> /bin)? What is the point of having a usr directory when there is no separation between stuff in usr and stuff in root?
  • sirclueless 15y ago
    If you want to mount system directories read-only or over a network, it's easier if you put them all in a single mount point. This way you can just mount /usr, instead of having to mount /bin, /lib, and /lib64 this way.
    • snowape 15y ago
      So /usr is now the directory for where all programs installed by the system or package manager gets installed. That actually does make sense.
• p0ckets 15y ago
  /opt/local is already used (by MacPorts).
• Drorm 15y ago
  This email is clearly wrong. Anyone, who knows anything about Unix knows that the world didn't start till 1970, so all this stuff about things happening in 1969 is clearly impossible.
• lispler 15y ago
  Everyone's talking about initramfs as if it would replace a self-contained /. Have you ever been there? Usually all the relevant repair tools are missing and the shell gives you a headache. Its the point where you usually give up, walk into office and boot a rescue disc. So no, it does not replace a working /.
• cturner 15y ago
  I think that the motivations for shared libraries was once valid but these motivations are obsolete, and they're destructive. I think there's a lot to be said for the simplicity and reliability of static linking. There is an argument that it's nice to be able to upgrade libraries and have everyone pick them up, but in practice that's mostly a myth because such upgrades are vulnerable to nasty small failures. Another argument is that is saves hard disk space - not an issue these days (perhaps it is in a small number of embedded systems still). Any good counters to that? Update: thanks for response. I found the link to the Drepper article linked elsewhere in this thread v informative also.
  • Derbasti 15y ago
    Well, consider GUI libraries like Qt, GTK or Cocoa. Cocoa in particular does not have any concept of a user modifyable "theme" or "style". However, it changes its looks with OS upgrades and all GUI applications change with it. With static linking, that would clearly not happen. Also, these libraries/frameworks are not exactly small, not even for todays hard drives, so the de-duplication does make some sense (and that is not factoring in the smaller size of SSDs). That said, I guess you could make this into an argument for filesystem level deduplication instead of dynamic linking.
  • Symmetry 15y ago
    Hard disk space isn't an issue, but internet bandwidth is. Also, being able to fit a fairly complete operating system on a CD.
• Sorpigal 15y ago
  How about we stop mincing around and make some gut-wrenching modifications? As long as you're going to go through all the trouble of shuffling things around let's kill more than one bird at a time. Let's not worry about legacy needs, let's just worry about current needs. We no longer care about disk space and (for the most part) things can be tab-completed, so there's little reason to keep anything small if there's a down side. What's attractive about /usr? A lot of things, but mostly: single export-point, possible to separately mount (from a network, read only, whatever), logically nice to have all those directories not polluting /. I propose that / should contain the following directories: /cfg/ /home/ /local/ /mnt/ /system/ /tmp/ You would mv /boot /dev /bin /sbin /var /root /proc /sys /usr /lib /run /system, then mv /opt /local /etc/ is renamed /cfg/ just because I can and left in / because some things really are global configuration (and we can't be mounting /etc ro all the time). But don't stop there, because now /system/ is a mess. You obviously still can't treat /system as /usr because e.g. /dev is there, so put /dev, /proc and /sys under /system/kernel, because these things are figments of the kernel's imagination anyway. Under /system/boot/ throw in a directory for your bootloader, initrd and whatnot and one for any statically-linked binaries you have, if you have any (hey, it's optional). No need for a lib, because it's all static or in the initrd. Just because I'm a mean curmugeon who hates greybeards and love n00bs, let's mv /system/var /system/data. Inside /system/usr let's merge files from games, bin and sbin into bin and get rid of the empty directories. Then mv /system/usr/local/ /local/usr/. Speaking of /local/, it'd have two subdirs: /local/opt/ and /local/usr/. The former would contain an opt-style directory hierarchy and the latter would be like /system/usr, only with the purpose of the FHS /usr/local. Okay, so the /local/ stuff isn't to be found in an exported /system/usr/, but /local/ is just a fetish of mine. You could put it in /system/usr/, too. And yes, /system and part of its structure is required to be on / during boot. So sue me. Now you have: /cfg/ /home/ /local/ /local/usr/ /local/opt/ /mnt/ /system/ /system/data/ /system/boot/loader/ /system/boot/sbin/ /system/kernel/dev/ /system/kernel/proc/ /system/kernel/sys/ /system/root/ /system/run/ /system/usr/bin/ /system/usr/lib/ /system/usr/share/ /tmp/ Now you have a tree for homes, a tree for the whole system, which has a splits where you might need them for partitioning and exporting, a tree for configuration, which also has a name users can understand, a tree for non-packaged software, which allows for both crazy-opt style layout and traditional, and you have your global tmp and temporary mount point root. Did I leave anyone out?