81–90 of 158 posts
Earlier quoted context omitted.
Your encountering them doesn't make them part of FHS. Their being included in FHS does.
At no point did I ever say they were part of the FHS.
> I'm still waiting for /opt/local to show up... Wait no longer: http://guide.macports.org/
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.
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.
Does 'ip' have a form that just prints the current addresses without all the surrounding cruft? That would be pretty useful for the occasional shell script.
Earlier quoted context omitted.
For those who haven't seen the proposal for the / /usr merge: "Fedora (and other distributions) have begun work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead" http://www.freedes…
Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?
Earlier quoted context omitted.
I also have no memory of /home even existing in roughly the first decade of Unix's existence.
home directories iirc, lived in /u (/usr these days)
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.
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.
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…
Would you mind buying me a memory upgrade when this happens? I'll need one.
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.
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…