Slashdot Mirror

1) Why does everything have to be compiled into the kernel. What? Can the kernel not map shared objects into its memory space? And if it can't, why not?

2) Why don't they establish only standard APIs that device drivers have to implement

(seperate of the kernel and not built into some stupid x-windowing system or something irrelevant to what it does example: sound drivers for KDE)

insert appropriate printer standard, etc.

and make the stupid x-windowing system just another interface that runs on top of OpenGL, jeez

3) The everything is a file mechanism is really getting outdated. Why are there not object oriented shells yet?

4) Why do we still use program based architectures? Programs are way too linear. We need objects and an object handling mechanism (like javascript or something similar to it, like a Delphi UI or something) not programs.

you could chain them together and do all sorts of neat tricks, that you could never dream of with standard file based shells/programs

Lets see: vi, emacs, joe (joe??? what the hell man), yast, lilo, initrd, sh, etc., etc.. Come on guys name your programs something intelligible, and leave the credits in the fscking readme file.

At least if dos had something it had convenient keywords (copy, rename, delete, deltree, EDIT).

6) Why did anybody think it would be a good idea to integrate the inetd with the x-windowing system (xinetd).

7) This one is for the distros: quit using the damn graphical installers.

And don't say, "One word, man" or "info" those systems are pretty fucked up as it is.

9) Standardize the damn locations, follow the LSB biatches

This may sound contradictory to the above, but... abolish the Unix file system layout. I can't stress enough how a simple object persistence/serialization mechanism would be way better than a file system any day.

perhaps I replaced /dev/dsp with a shell script.

That still wouldnt make you a Linux user. :P

*it should be in a lib directory then so we dont all yell at you*

FHS : Filesystem Heirachy Standard.

Forgive my ignorance, but how does the LSB relate to the Filesystem Hierachy Standard. Is it a replacement?

Talking about docs: Is there a good introductory text which explains why everything goes where it goes? Why is /etc called etc, why are there so many different *lib* directories? Stuff like that...

It comes from traditional Unix, most of it. Ask the FHS people.

Use Debian. I'm not saying that it's immune to cruft, but the fact that they have close to 9000 packages which all comply with the Debian Policy (as well as the FHS) means that everything plays nice together, and if it doesn't, it's a bug. There's even a tool called Cruft, which will locate cruft on your system.

Having policies for standard installation directories would be great. I agree, the FHS(?) standard only covers mostly where to place servers or databases. So, even though mostly all distros are near 99% FHS compliant or better the standard does little to specify where to place things like documentation, apps, or a window manager. It is my opinion there should also be another FHS compliant standard that covers these additional files. Even if it were not followed 100% to spec it would still do a deal for making Linux more user-friendly.

Ohh... if the filesystem is what you want standardised, check the Filesystem Hierarchy Standard. It is quite specific in what goes where.

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.

You mean something like a Filesystem Hierarchy Standard? Or maybe even a Linux Standard Base?

Jay (=
(Is there a website that rates distributions according to their adherance to these standards?)

First, I try to adhere loosely to the FHS for ideas on overall organization. Even though it's mostly intended for POSIX systems, following their philosophy will really help you separate your data from your platform-dependent program files and libraries.

Most of my important stuff goes on the Linux server in /home (on an IDE software RAID1). However, I try to limit files in here to stuff that's absolutely essential to keep the size down. I occasionally mirror this offsite to my friends' servers with rsync (with the private stuff pgp encrypted). I try to make browser caches, etc. symlinks to dirs in /tmp . Try to keep only the stuff you created yourself in here.

I keep media and downloads on a plain partition under /home/ftp/pub (which is also symlinked from the http document root). That way, all my computers can easily get access to music and installers and junk.

Samba helps win32 boxes access the /home and /tmp directories.

NFS exports /home to the other UNIXen, as well as /usr for the other machines with the same CPU arch. It should be acceptable to export /usr/share to other UNIXen with different architectures.

I'd like to set up CODA, since it seems to support more different kinds clients than Intermezzo. These support disconnected operation and are good for laptops. For the meantime, I just use rsync to mirror home dirs onto my laptop, though (and just keep track of stuff that I change on the road manually :/ )

No thoughts on how to combine everything into a distributedFS so you could have parts of, say, a music archive living over several machines. There are several projects for Linux-only (PVFS) or Win32-only (more advanced network-neighborhoods). I'd say your best bet for convenience is just to make sure everything is visible from your one server and reexport it from there (invest in a switch so it doesn't deadlock your network). Until better DFSes exist, though, I think you'll get better performance and less confusion from running everything from one beefed-up server with a RAID (or two if you want failover).

If you truly are not a newbie as you claim, what's the big deal about mkdir'ing and adding it yourself?

As far as "upgrading X" goes, I run X built from scratch from cvs on my RH 7.2 box. No big deal.

And by the way, there is no "standard" location for perl. Tear yourself away from your precious slackware box and look at Solaris and HPUX if you don't believe me.

portanto = consequently

clareza = clarity

obrigatoriamente = necessarily

garantindo = guaranteeing

separando = separating

The article is actually about creating high-quality installation programs, so the title is misleading. Here is a link to a copy that is better formatted, but not as well edited:

Creating Integrated High Quality Linux Installation Programs

FHS is the FileSystem Hierarchy Standard, an important standard.

I love Brazil and Brazilian culture, but not everything about the culture is wonderful. Brazilians generally don't like to give attention to detail.

The real FHS says

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being written when the system software is updated. It may be used for programs and data that are shareable among a group of hosts, but not found in /usr.

Nothing about it not being an NFS share (another poster said it shouldn't be). Also, nothing about package managers. It says the distribution may not install there. If I'm installing locally from a downloaded RPM, I'll expect it to install to /usr/local. It makes no difference if my distribution happens to use RPM itself -- only applications shipped as part of that distribution should be outside /usr/local. That is:

Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

The logic is that if I keep a copy of the install options for my Linux distribution along with incremental backups of the /usr/local and /home heirarchies I can completely restore my system at any time.

/opt is in FHS 2.2 at secton 3.12. It begins:

3.12.1 Purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package.

Doesn't look very depricated to me. I think the problem is your FHS link isn't really the FHS; it is the SAG (Systems Administrator Guide), which in section 4.1 clearly says it is loosely based on the FHS.

As for /usr/local, I do agree it should be off-limits to the distribution (besides setting it up if not already present). And packages in the package format of the distribution (e.g. RPM for Redhat, Mandrake, SuSE, etc ... DEB for Debian and any like it ... TGZ for Slackware ... and so on) really should stay out of /usr/local. What /usr/local should be is whatever is local policy (FHS doesn't say it this way). Packages that the administrator really wants to be separate from the package management system, stuff compiled from source, stuff locally developed, all is eligible to be in /usr/local. My guess is the author of the article has no experience doing system administration combined with a decision making role where he might have to choose to do something slightly different than what everone else does.

/opt is not deprecated. In fact it is required that LSB compliant applications are installed under /opt You can download the latest version of the FHS here and the LSB specification here.

Actually, no. It is from the diseased mind of the author of the article. He first cites the FHS, and explains how good it is to have a standard like that, and then proceeds to ignore everything it says. /usr/local is explicitly reserved for local use and therefore no package should *ever* install itself there (my /usr/local, for example was NFS mounted, and RPMs that tried to install there would fail because root didn't have write access to it). So far, so good, and we're in agreement with the article. But then he goes on to say that /opt should never be used. What? According to the FHS, /opt is exactly where IBM should be installing stuff. Quite how he's decided that the two directories are obsolete is beyond me. Both have well defined and useful purposes, both in common usage, and in the latest FHS spec (see http://www.pathname.com/fhs/). I'm afriad IBM have just lots a lot of respect from me for this...

It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.

The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard, which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."

The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement in their official policy manual.

The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.

More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the /opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt /usr/doc) into the FHS mandated /usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.

Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.

Theoretically, software developers should only have to release their files as .TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.

As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:

apt-cache search pppoe

If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:

apt-get install pppoe

and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

-castlan

The first thing it says under Chapter 17. File System Hierarchy is

An LSB conforming system must adhere to the FHS 2.2.

It can be found here and involves rather more than a few files in /dev

I was reading the latest Filesystem Hierarchy Standard (FHS), which should be followed by *NIX developers, and I noticed that it states there should exist a /usr/homosexual/ directory on all standard filesystems. Does anyone know what the purpose of this is?

Now, something that occurred to me regarding the management of "archive" files, such as mp3's, ogg's, and the like. Each time you rip a CD and encode the wav's thereof, you've reduced your storage requirements by nine (roughly). Why not hardlink your archive files to an unorganized ../discXXXX/ directory. Link enough files in each directory to roughly equal the storage media you're using. Then, when you have a full "disc", burn it to CD. We're not talking about an organized disc, remember. Just faithful backup of new data. Do all of your heirarchical data management in a set of different directories, or use a database of some kind. Essentially, you can take out much of the load that would be handed off to Amanda or other archiving schemes.

Heard of the Filesystem Hierarchy Standard? Evidently not. See here for a full telling off and here for further info.

Yeah, God forbid a distro follow the bloody standard by having man pages where the FHS says man pages should go. And it's definitely too much to ask that developers of programs follow the same standard. It'll be much more fun to just do what the other guy's doing, and hope they don't change.

I thought that according to the FHS that /opt is for add on software packages, and that /usr/local is for installing software locally.

Oh dear, you don't seem to have much of a clue about how the Filesystem Hierachy Standard works. Come back and troll again another time.

Oh wait, it's better to have /bin for programs, and /usr/bin for programs, and /sbin for, uh, programs . . . some of which depend on files in various subfolders of /lib (or was it /usr/lib?) . . . much cleaner.

It's amazing how many Unix users there are that doesn't know a thing about FHS, the Filesystem Hierarchy Standard!

The scary part is that some of them is managing large numbers of Unix servers and workstations without knowing the difference between /opt and /usr/local and why it's wrong to have every single piece of additional software installed in /root and run as root.

Bugger'em

Yeah, it seems crazy, but there are good reasons for keeping around most of the Unixisms that Linux still has. There are no good reasons for many of the hacks and 64-bit incompatibilities in the Win32 API, or for Win16 to ever have existed.

/var is specified here in order to make it possible to mount /usr read-only.

That's what FHS says. If you want separate trees for different backup policies, that's not a bad idea, but the name you're using will actively mislead any other admin who assumes /var really means /var.

Last time I looked, SuSE violated the FHS by using /sbin/init.d and having the distribution install software into /opt

Red Hat 7 doesn't use egcs. If you meant gcc-2.96-rh, you should probably have a look at http://www.bero.org/gcc296.html for lots of reasons why gcc 2.96 could be a good choice.

and moves things around in such a way that if a software developer writes a program to be installed on a RedHat Linux system, it won't install on any non-RedHat-based distribution.

Red Hat 7 and later plays rather nicely with FHS...

If it does install, the crazy egcs release will keep it from running on the new machine.

Use binaries compiled for the platform you're using, or compile yourself. Complaining that some binary compiled for JoeRandomsDistro won't work with your Red Hat install isn't very relevant, IMHO.

RedHat often screws with things like init scripts just enough to make them UNIX-like, but to break POSIX standards.

Examples?

What pisses me off about RedHat is how deliberate their embrace-and-extend design policies are. I don't recommend RedHat for anything, because learning the quirks of RedHat puts users into bad practices of using their proprietary tools

What proprietary tools exactly? Red Hat doesn't do proprietary tools.

or expecting the proprietary behavior of their tools to be standard cross-platform.

A behavior cannot be proprietary (unless it's patented), afaik.

It's sort of like how a lot of linux distros have a 'route' command that, for some reason, won't accept 'route add -net default' (which is standard across UNIX) but will accept 'route add default gw'... annoying.

> Can anyone point me to a document which explains the logic of /usr, /usr/share, /usr/local, etc.?

See the Filesystem Hierarchy Standard

--

The primary reason to prefer linux over traditional unices (for me, as a sysadmin and user) is the clean separation of configuration files from the binaries they control and the data those binaries use.
By this I refer to the way one can simply back up the /etc directory structure and capture the entire configuration of most linux distros, without getting anything else. This is extremely useful. Similar tricks can be played with /var on nameservers and DHCP servers.
Traditional unices (the most egregious example being that hideous train-wreck of a Unix, HP-UX) scatter configuration files and binaries willy-nilly across the file systems, every program having its own unique hidey-hole. People steeped in Unix lore become inured to this, and start to think it is desireable because they are used to it. [Reality Check - BINARIES SHOULD NOT BE IN /etc AND rc FILES SHOULD NOT BE IN /sbin! - If that isn't obvious to you, you need a long vacation.]
The LSB specifies the use of FHS 2.2 which seems to be a more elegant version of the old linux file system standard. The FHS standard specs an /opt directory for the installation of major 3rd party applications - that is, the kind of applications that you dedicate a server to, like databases or digital data aquisition systems.
The problem is, the majority of the application vendors ram their code in any old place they want, and then their apps don't run without those specific locations. Symbolic links are the best compromise you can usually get, without forking off your own source base, and sometimes even that won't work. Then, to make matters worse, they often require specific versions of various libraries - usually obsolete and/or insecure ones, in my experience.
So, the major distributors may get off their asses and implement LSB eventually, which will be a Good Thing [TM] and will mean finally getting real total compliance with FHS, but application servers will still be wonky as soon as a big app (like tina or datastage - blech!) is installed. The LSB will supposedly address this by marketplace adjustment and app vendors without clues will fail commercially. I personally am not convinced this will happen seeing how Solaris and the patently inferior HP-UX still command market share today. Commericial needs require applications which require systems, and not the other way 'round.
Me, I'll be happy when the ancient cruft like /etc/exports (I have a link named /etc/nfs.conf on the few machines where I am forced to run insecure crap like NFS and NIS) falls by the wayside. Until then no *nix standard can be both widely used and internally self-consistent.
--Charlie

Eric Dennis (Spothead Lex Animata) says the secret to happiness is lowered expectations.

It's nice to see that the folks at this Open Source Directory are modeling the software categories after Sourceforge'.s Software/application taxonomies typically vary from site-to-site and distribution-to-distribution. While I appreciate that all the site maintainers out there take time to organize information about software applications, the diversity makes it difficult to synthesize materials from multiple sources. I applaud this directory's deference to a previously-existing taxonomy.

A while back, I started creating a list of software categorization schemes/systems relevent to Linuxland:

http://freshmeat.net/browse/627/
http://apps.kde.com/na/2/categories&nav=f
http://sourceforge.net/softwaremap/trove_list.php
http://dmoz.org/Computers/Software/
http://dir.yahoo.com/Computers_and_Internet/Softwa re/
http://ftp.us.debian.org/debian/dists/potato/main/ binary-i386/
ftp://ftp.ibiblio.org/pub/Linux/
http://www.gnu.org/gnulist/production/index.html
http://www.userfriendly.net/linux/RPM/Groups.html
http://www.cpan.org/modules/by-category/
http://www.freebsd.org/ports/
ftp://ftp.isi.edu/in-notes/iana/assignments/media- types/media-types
http://www.pathname.com/fhs/
http://www.labs.redhat.com/gug/users-guide/main-me nu.html
http://www.linux.com/links/Software/

I came across the Filesystem Hierarchy Standard rummaging around /usr/share/doc on my SuSE box.

I'm a couple of years on from my first tentative steps in GNU/Linux, and I can assure you you won't regret the move. I originally set up my PC as a multi-boot NT/95/Debian box, then when I bought a new games PC, my old one went exclusively Debian. Now my games PC is dual-boot, and if it weren't for Diablo II, my last Windows partition would be a distant memory.

I haven't used KDE, so I can't comment, but in my experience GNOME as a desktop environment adds little to usability. The GNOME/Gtk+ libs are good for developers (if only someone would document the Perl bindings properly), and provide a nice standard look-and-feel, the CORBA stuff may one day turn out to be useful, but that damn footprint thing, and the associated bells and whistles add nothing but about half a minute to x startup time. I spent about a year with the footprint, waiting for 'apt-get upgrade' to finally give it some discernable purpose, but eventually gave up. Seriously, there are some good things about the GNOME project, but the sooner you comment out exec gnome-session in your .xinitrc file, the better. A good window manager like Enlightenment is all the desktop eye candy you could ever want.

Read the From DOS/Windows to Linux HOWTO. On Debian it's found at /usr/share/doc/HOWTO/en-txt/DOS-Win-to-Linux-HOWTO .txt.gz. It shouldn't be far away on other distros.

Most of what you will need to know can be found in the HOWTOs or man pages. Best/quickest way to read HOWTOs is:

If that seems like a lot of typing, refer to this HOWTO for why it isn't.

To supplement the online docs, you may want to get O'Reilly's 'Running Linux'; also 'Linux in a Nutshell' is good on those occasions when you know there's a command to do such-and-such, but you can't remember what it's called. The 'apropos' command is also helpful here (in fact you'll save time if you use 'apropos' before reaching for a book). Your distribution-specific docs should also get at least a skim-through

If you really want to get to know your system, I'd recommend you resist the temptation to do everything in X windows. Steer clear of GUI configuration tools unless the docs for the relevant package explicitly ask you not to edit config files by hand.

Go for a wander about your hard drive, looking at your directory structure and what goes where. The Filesystem Hierarchy Standard for POSIX-compliant systems is also helpful for explaining the rationale behind the directory heirarchy. Last I heard, Red Hat doesn't conform to the standard (Debian does, of course), but that may have changed.

Once you've started settling in, you'll need a good text editor and web browser. Forget the vi versus emacs debate. FTE is a thing of beauty, and I can't understand why it isn't raved about more often. I had a friend who installed GNU/Linux purely on the strength of this cool text editor he'd seen me use. It's easy for Windows users to pick up, and in a lot of cases has Windows-style key bindings (Ctrl-c, Ctrl-v) as well as Unixy ones (Ctrl-Ins, Shft-Ins).

Web browser. You'll want Mozilla, so you'll also need one that doesn't suck up all your memory and crash. Links (not Lynx), is jaw-droppingly brilliant. Runs in text mode, yet displays tables and frames. Supports cookies, launches helper apps, has right-click context-sensitive menus, and so on. Good for those occasions when you've stuffed up X-windows and you need to search www.deja.com for a fix.

Now you've got a web browser up and running, check out:

• The Linux Documentation Project
• linuxcommand.org

As Treasurer of the Bucknell University ACM (Association for Computing Machinery), myself and the other officers help to persuade industry, faculty, and students computer experts or evangelists to (of OOP, OSS, Linux, etc) come to Bucknell to give a presentation. In the past year or so, we've had guests like Dan Quinlan of Transmeta, speaking on the Linux Standards Base, Ralph Droms (inventor of DHCP), a faculty member at Bucknell, John 'Maddog' Hall (Linux International executive director) on the Flexibility of the Linux OS, and many others. Currently, Eric S. Raymond has added us to his mailing list and will probably come Spring semester to talk about his ideals and beliefs when it comes to software.

What are our methods of obtaining guests? First, it helps to have some connections with someone related to the person you'd like a have speak at your school. Second, being at a top-notch college like Bucknell University tends to give some incentive, perhaps, for people to visit. Finally, persistance does pay off occassionally; if there's someone you really want, make sure you remind them via email or vmail every so often that you'd be absolutely delighted to have them grace you with their presence ;-D

Good luck!

Redhat has been critized for not following the standard. They have also been critized for following the standard.

I've been using Linux since late 1995; I installed with Slackware 2.1 (kernel 1.1.59!), and have been updating via tarballs since. My /usr/src directory has a good 200 or so packages in it at the moment, most of which I've used at one time or another. The system has worked without any problems to speak of, except occasionally when doing upgrades (installing ELF libraries and compiler was a pain).

I personally enjoy tinkering with the system, customizing it to fit my needs best, but I wouldn't dare give my current setup to anyone else. I have libc4, libc5, and libc6 all coexisting somehow, and programs to go with each--some things like gzip which never change haven't been touched since the original a.out install. The directory structure is a mess, too; I've never gotten around to sorting things out. It can take quite a bit of time to keep things up to date, though I probably would have been better off if I had had something like the FHS to guide me. If you're going to go with your own distribution, such resources are definitely worth a read.

Although it takes effort, the results can be nice. Obviously you can install whatever software you like without having to worry about dependencies or wonder what someone's install script will do to your /etc directory; you can also tune it to fit different configurations if your computing environment changes. When faced with a PC at a summer job whose SCSI card was flakey, I was able to extract the bare bones from my home system and create a two-floppy Linux system with pico, telnet, ftp, and ssh (plus basic shell utilities)--more than enough for what I needed it for.

So yes, there's at least one person out here who uses a homegrown distribution. (-:

There's already a pretty definitiveLinux filesystem standard. (FHS, the standard formerly known as FSSTND)
--

We need to get someone to provide a definitive explanation of what each part of the file system is for, and how they should be used, so that we'll be able to say "RTFM", and have a sounder understanding of our own operating system.

See www.pathname.com.

That's because most linux distibutions ignore the Filesystem Hierarchy Standard. I believe that this is part of the Linux Standard Base which has most of the major distributions as members so IMHO they should be using /opt.

Yellow tigers crouched in jungles in her dark eyes.

The FileSystem Hierarchy Standard shows the suggested directory and files placement for Linux (and for BSD systems too).

Heir to the original UNIX placement scheme, there are real-world, VERY GOOD reasons for the naming and placement rules, and it shouldn't be broken just because you don't know them or you feel uncomfortable with them, because we would lose a lot of standardization this way.

The Joe User? He doesn't care as long as he has his place on the hard disk. He is not a system administrator. Maybe he has got his little system with Linux where he can do his particular mess, but don't expect serious people to try to follow his own common-sense thinkings about this placement of files.

Patola
Patola (Cláudio Sampaio) - Solvo IT
IBM CATE
SAIR GNU/Linux Certified

There is already a standard for Linux(/UNIX) filesystems. The /sbin/bin (/usr/sbin/bin, /usr/local/sbin/bin) directories shouldn't be there, but the rest are normal.

But according to every interpretation of the FHS I've ever read (except for yours :), that's where they should go. /usr/X11R6 is reserved for the X Window System itself, not X applications:

This hierarchy is reserved for the X Window System, version 11 release 6, and related files.

Such an app would have to be enormous to handle all those distros and every package that ships with most distros.

I suppose it could start by *strictly* adhering to the Filesystem Hierarchy Standard, excuse my ignorance (I've used SlackWare in the past and RedHat currently) but I haven't seen many distros that fully *comply* with FHS (even though FHS gives you a lot of leeway).

This could bring us a little closer to the the universal source package.

Also, the "Distro-O-Matic" would allow you to choose your kernel, from a predefined list (SMP, pgcc optimized, full networking, etc.).

Probably a pipe dream :)

Marcus

• The way I usually remove source packages is with make uninstall in the package's source directory. On most (well-maintained or relatively recent) packages, this should reverse the make install command. You may still have to resort to locate to find empty directories, but it's a start.
  
  
• If you haven't already, check out the UNIX Filesystem Hierarchy Standard to get a very general idea of where installers will put files. Granted, packages may not adhere to the standard, but usually the document can at least allow you to make educated guesses.
  
  
• In a previous article, someone mentioned GNU Stow, available from ftp.gnu.org. Stow organizes installations into subdirectories of /usr/local, creating links in the $PATH to point to the executables.
  
  

One of the first things you have to overcome when installing a unix system for the first time is the belief that your former system rather it be dos or windows was somehow better. There is an established standard (FSSTND) that dictates where files should be placed but more importantly dictates where files can be found which is critical for any system administrator; Instead of wading through "/programs" you can be reasonably assured that if it's a userlevel binary it's somewhere in /usr/bin or /usr/local/bin (there are exceptions to the rule where categories are made such as /usr/X11R6/.) This also makes it much easier to migrate from different versions of unix since the structure is generally the same.

what's the difference between /usr and /usr/local and why can't i just link /usr/local to /usr?

Well technically there's nothing wrong with that, (/usr/local/ is meant for if you have a nfs /usr you can mount a /usr/local with binaries relevent to only the local machine). I find however that it serves a more useful purpose in separating out the files that came with my distribution/or the files i installed as packages from the files i've compiled on the system. If i ever have to clean up my system all i have to do is wade through abit of /usr/local.

So in answer to your post there is a predictable placement to where the files are located it jsut takes abit of getting used to.

Filesystem Hierarchy Standard
- MbM

The problem is, that's not true. We have RFCs, just like everything else. Some stuff implemented on linux doesn't live up to the RFCs in question (dhcpd 2, for example, doesn't implement DHCPINFORM), but then again it also implements some stuff far better than mere standards-compliance (gnutar, bzip2, a whole gamut of decent shells).

This is a key point I missed commenting on earlier. It is very true that Linux and other open source OS's have a great track record for following networking and Internet standards, as well as some UNIX standards. (And I must admit I like reading some of Linux's manpages when it comes to having to deviate from a standard or explain why a standard is silly -- the attitude is very refreshing.) :-) However, there are currently no good desktop standards, which I think was the thrust of the article.

For example, as far as filesystems go, there's the Filesystem Hierarchy Standard, but beyond the distribution-makers, who really follows it? (Don't even get me started on how StarOffice installs... groan.) Maybe that has something to do with the fact that Linux users are so grateful for certain kinds of applications that they don't even concern themselves with whether or not they follow established standards...?

Also consider that there are now countless ways of running your desktop. The unification efforts behind KDE and GNOME (and the nonexistent efforts between these guys and anyone else) are not anywhere near mature enough for me, as an application developer, to even say "ok, regardless of what environment Joe Blow has here, I want to register this mime type as mine, this icon, put this on the launch menu, etc." That's just as an important part of standards than sending the right bytes over your network wire.

Do I personally care so much about whether or not an application can install its own file associations and launch menu icons? Nah. I still like the power. But it sure would be nice.

My / is > 100 megs, but that's a matter of preference. my /usr is not a partition like most systems, neither is /home. Just didn't feel the need. Oh, that and I'm not a sane sysadmin :)

But seriously, I have my system set up:

/dev/hda1 (fat) /dos_c
/dev/hdb1 (e2fs) /
/dev/hdb2 (swap) swap
/dev/hdb3 (e2fs) /usr/data (6 gb)

I'm going to be moving my dos_c drive to another box (and formatting it for linux only) soon, so this will change. While the fhs suggests you should run / at about 16-64 megs and /usr or /usr/home should be your largest partition, I just decided since this is a single user system, I could break the suggestions.

That, And I was fast running out of primary partitions.

A distribution should never touch /usr/local. That's the whole point of /usr/local -- it's somewhere for the local admin to put things that where they won't get touched. If Red Hat ever put anything in /usr/local... well, I just don't want to think about it.

You should read the FHS some time instead of shooting off at the mouth randomly. Here's what is says about /usr/local .

A distribution should never touch /usr/local. That's the whole point of /usr/local -- it's somewhere for the local admin to put things that where they won't get touched. If Red Hat ever put anything in /usr/local... well, I just don't want to think about it.

You should read the FHS some time instead of shooting off at the mouth randomly. Here's what is says about /usr/local .

This directory should always be empty after first installing a FHS-compliant system. No exceptions to this rule should be made other than the listed directory stubs.

/usr/bin is for "most user commands", /usr/sbin is for non-essential standard system tools, while /opt sounds like what you expect from /usr/local.

Redhat vaguely bothers me because it does mess with /usr/local...