Understanding the bin, sbin, usr/bin , usr/sbin split • Hacker News Board

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

#151

Post by sambeau » Sun, Jan 29, 2012, 1:29 PM UTC

hollerith wrote: post #52

tmhedberg wrote: post #24

Earlier quoted context omitted.

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.

Well, first let me extend your explanation of the rationale for /usr/share: the reason for having a place to store not-executable shareable data is that in some network environments, it helps to have to maintain only one copy of this data, on some file server somewhere, which then gets mounted over the network to every machine. We need to keep /usr/share separate from /usr/bin, the rationale continues, because our ne…

I very much appreciate your added comment. I feel like banging my head against a wall every time I see a new programming language that boasts a 'hello, world' along the lines of:

  System.Console.WriteLine

or

  System.out.println

or

  Ada.Text_Io.Put_Line

just to get a little text output.

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

#152

Post by sambeau » Sun, Jan 29, 2012, 1:45 PM UTC

rlpb wrote: post #88

peterwwillis wrote: post #32

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 m…

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

You'd need a bigger hard drive rather than more memory: dynamically shared libraries are paged-in to be used just as statically linked libraries are and are also paged-out when not in use, in just the same way.

Thus, to run a dynamically linked program you need to use the same amount of memory as you would a statically linked program.

However, if you are lucky (or have enough RAM), there is a chance that you won't have to load the page containing the library as it may already be in memory.

So there is a valid argument that to take full advantage of dynamically linked libraries you need more memory than for statically linked libraries.

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

#153

Post by pconf » Sun, Jan 29, 2012, 7:59 PM UTC

prewett wrote: post #144

pconf wrote: post #142

Earlier quoted context omitted.

Given today's disk capacities it rarely makes sense to create any partitions whatsoever within a disk other than for swap. Partitioning /usr, /var or anything else on the same disk only increases the chances of one or more partitions filling. Admins and OSs who create inter-disk partitions without an explicit need are operating on legacy superstition.

If /tmp fills up, things start mysteriously not working (a surprising number of things create temp files, including things you wouldn't expect to), so it needs to be on a partition that won't fill up. I usually put it in its own partition, so that accidentally filling up / won't bring cause mysterious problems. /var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A…

> If /tmp fills up ... so it needs to be on a partition

Makes no logical sense. When you create an (inter-disk) partition you reduce the blocks available to all remaining partitions on that disk. By reducing partition size you _increase_ the probability of all remaining partitions filling.

If you had said adding disks for /tmp and /var were indicated I might agree, but would still be wondering what kind of applications you have.

Looking back at Unix' history we see that partitioning was only added before RAID and only to accommodate additional disks. It is the failure to understand this history and rational that leads certain sysadmins to believe that inter-disk partitions accomplish anything other than reducing robustness (in absence of a badly behaved application, which is 99% of the time a badly configured server or application, per the log rotation example).

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

#154

Post by EvilLook » Mon, Jan 30, 2012, 3:42 PM UTC

triffidhunter wrote: post #22

nailer wrote: post #18

Earlier quoted context omitted.

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.

There are plenty of good reasons to make a /boot. Encrypted laptops for example.

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.

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

#155

Post by Sorpigal » Tue, Jan 31, 2012, 1:30 PM UTC

pconf wrote: post #141

kstenerud wrote: post #27

Earlier quoted context omitted.

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 consid…

I really like the way FreeBSD separates system and third party software, the latter typically being installed to /usr/local. Linux' failure to differentiate between system and non-system binaries is IMO one of it's worst features. Neither FreeBSD nor Linux accommodate network mounted NFS mounted applications as well as SunOS did so successfully by the late '80s. This is probably due to the corrupting influence of Uni…

BSD is in a position to differentiate in a way that Linux just isn't. In Linux all* software is third party, except for the kernel and util-linux (and maybe fileutuls or some other set of GNU software).

To me the BSD distinction doesn't make much sense anyway. You still have to just know which bits are "local" and which are not, plus anything I pull in that isn't a port gets lumped in with them anyway.

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

#156

Post by Sorpigal » Tue, Jan 31, 2012, 1:38 PM UTC

rat87 wrote: post #146

DrCatbox wrote: post #115

Earlier quoted context omitted.

"and a GUI is used to provide easy access to the application" How do you think the GUI finds the application? There is a PATH. Open up a cmd and type the name of any installed program. 1) Programs put themselves in various directories on my windows 7 machine, some are under \Program Files, some are under \Program filees (x86), some are \Programs and so on, variations and variations. 2) to locate a program you need to…

I thought the many of the shortcuts used fullpaths in windows I'm pretty sure not all of them can be accessed with name in cmd. Looking at the .desktop files under /usr/share/applications (ubuntu) most execute by name but some especially games(both third party and some gnome games) use fullpaths.

In Windows from a cmd.exe prompt you rely on the contents of %PATH% to access programs. This is a holdover. In Windows proper there are other methods; from cmd.exe you can use the 'start' program to invoke executables in a Windowsy way. The most convenient/reliable way to set up an easy to use/remember way to launch an executable in Windows is to go to the registry and locate hklm/software/microsoft/windows/currentversion/app paths/, inside of which are a series of keys. Each key is the name of an alias and its default reg_sz value is the path to the executable to invoke when the alias is passed to 'start' (or entered into the run prompt, or what have you). You will find a number of these already in existence on any Windows box, most notably iexplore.exe.

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

#157

Post by Sorpigal » Tue, Jan 31, 2012, 2:05 PM UTC

pconf wrote: post #153

prewett wrote: post #144

Earlier quoted context omitted.

If /tmp fills up, things start mysteriously not working (a surprising number of things create temp files, including things you wouldn't expect to), so it needs to be on a partition that won't fill up. I usually put it in its own partition, so that accidentally filling up / won't bring cause mysterious problems. /var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A…

> If /tmp fills up ... so it needs to be on a partition Makes no logical sense. When you create an (inter-disk) partition you reduce the blocks available to all remaining partitions on that disk. By reducing partition size you _increase_ the probability of all remaining partitions filling. If you had said adding disks for /tmp and /var were indicated I might agree, but would still be wondering what kind of applicatio…

Partitioning has some security and performance gains. Different filesystems for different workload (e.g. perhaps xfs for database files and reisterfs for /tmp), mounting with noexec or ro in some cases.

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

#158

Post by Sorpigal » Tue, Jan 31, 2012, 3:20 PM UTC

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?