Live data from Hacker News

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

lists.busybox.net

91–100 of 158 posts

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

#91
post #87

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

While the system is, indeed, complicated, there is a reason changing it has not been Ubunutu's highest priority: almost all installation is done via the package manager. I haven't used Ubunut much, but at least on Fedora 95% of what I use is in the repositories and the rest is available as an rpm file which installs itself. I have never had to worry about where to put executable files.

Of course, I have installed things manually from source. But when I do, I only install them locally in my home directory.

So the complexity is there, I just haven't had to deal with it.

Also, I think that GUI-centrism is short-sighted, but that's another matter altogether. In short: command-line tools are just as "modern" as GUI tools; they're just harder to learn but tend to be more powerful.

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

#92
post #88

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.

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?

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

#93
post #57
post #50

Earlier quoted context omitted.

The central thing about all these conventions is they developed in the absence of good union mounts. In Plan 9 there is no $PATH: all such things are bound into /bin. This works both because Plan 9 has very good union mounts, but also because those union mounts can be localized to a specific process and as a result are user accessible. I seem to recall some work was done to make this possible on Linux but It didn't g…

I wonder why rc still has $path in Plan9. term% echo $path . /bin What happen with Ape ports whom expect the path environment variable?

Ape's execlp() tries first the program name passed to it (be it relative or absolute), and if that fails it prepends "/bin/" and tries again. It ignores environment variables entirely.†

Rc's path variable allows you to easily tell rc to check the current directory when looking for programs to exec. Doing that with bind after each cd would be clumsy. And if your working directory is a remote server, you can set path to just /bin so that you aren't statting the remote directory before each exec. Inferno's sh does use a path variable, but it is typically left unset and the default (/dis .) is used.††

† See http://plan9.bell-labs.com/sources/plan9/sys/src/ape/lib/ap/...

†† See /usr/inferno/appl/cmd/sh/sh.b:/^runexternal

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

#94
post #87

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

For future reference, you can list all of the files associated with a package using this:

    dpkg-query --listfiles package-name
Or use Synaptic's 'Installed Files' tab in the package detail dialog.

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

#95
post #65

Earlier quoted context omitted.

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.

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.

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

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

#96
post #94
post #87

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

For future reference, you can list all of the files associated with a package using this: dpkg-query --listfiles package-name Or use Synaptic's 'Installed Files' tab in the package detail dialog.

Or:

    dpkg -L package-name

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

#97

Earlier quoted context omitted.

home directories iirc, lived in /u (/usr these days)

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

Indeed, /usr was already in place in UNIX version 1, according to the 1971 UNIX Programmer's Manual.

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

#98
post #87

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

I come from a DOS / Windows background, but now use Cygwin as my primary interface on Windows, and also regularly use Nexenta (Debian-flavoured Solaris) and Linux. I find the Unix way more understandable, particularly when things break.

Only the most simple of Windows applications get away with putting everything into a single folder under $PROGRAM_FILES. More usually, lots of stuff is in $COMMON_FILES, and may or may not be shared. And these common files are tied in to the program files via a giant complicated global variable, the registry; the program looks up ProgIDs and CLSIDs to instantiate COM objects, so the registry becomes a very sensitive source of failure, particularly when you have different versions of $COMMON_FILES that break the various linkages.

Furthermore, these days Windows Installer is often used to manage the Windows equivalent of packages. These too are sensitive to corruption; if you end up missing the MSI files from c:\windows\installer for one reason or another, you can easily get into a situation where you can't even reinstall an application cleanly, because the installer notices that you already have it installed, and tries to uninstall it first, but fails (usually quietly, in the middle of the installation, where the progress bar goes into reverse and at the end you get a cryptic and unhelpful error message). To fix this, you must venture forth once more into the registry, find out the cryptic (hex) name for the relevant package, and surgically excise it. Not even the MSI/MSP/etc. files have meaningful names. It's tortuous.

All that said, I by far prefer working in Windows to any other OS. If it had a faster performing yet fully POSIX compliant layer as well integrated as Cygwin (i.e. not off in its own parallel little world like SFU/SUA), it would be even better.

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

#100

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…

And the exactly corresponding security problem: when a problem is found in a library, you'll have to update all your applications, not just the library, otherwise you'll have an insecure system.
Post reply on HN