Slashdot Mirror

While it's a good idea to have things in sbin statically compiled, sbin actually stands for "system binaries," according to the File Hierarchy Standard. "System binaries" is the FHS way of saying programs that only root should have permissions to execute.

It's only split into separate directories for convenience, as sbin does not appear in the normal users path.

While it's a good idea to have things in sbin statically compiled, sbin actually stands for "system binaries," according to the File Hierarchy Standard. "System binaries" is the FHS way of saying programs that only root should have permissions to execute.

It's only split into separate directories for convenience, as sbin does not appear in the normal users path.

While it's a good idea to have things in sbin statically compiled, sbin actually stands for "system binaries," according to the File Hierarchy Standard. "System binaries" is the FHS way of saying programs that only root should have permissions to execute.

It's only split into separate directories for convenience, as sbin does not appear in the normal users path.

until OS X shows major improvements in the area of FHS compliance, it's not an operating system that i would find useful for my work.

Actually, your understanding is incorrect. From the FHS:
"/usr/local : Local hierarchy
Purpose

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

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

If you read it, you'll see that /usr/local is where the admin installs software. The distrobution is not supposed to put its packages there because it might overwrite locally compiled packages.

Those install programs only pretend to give you control. There is still a bunch of files, especially, DLL and configuration files, that get scattered all across your filesystem. When have you specified "c:\windows\system" as an install dir? Yet it just keeps growing!

And considering the fact that uninstallers are an afterthought in the Windows world, you'll be lucky to find half of them. In my experience, the average uninstaller fails 2/3 times; good hunting!

Yes, we need a way to specify a specific install path for special cases, but Windows certainly does _not_ do package management right... it has no package management, only "installers".

What kind of control do you want over your filesystem? There are good reasons behind why Linux programs are installed the way they are. Read the FHS for more: http://www.pathname.com/fhs/.

Why can't we just agree on a standard or two (such as putting everything in the same place, and using the same format for the "installed packages" list) so that I could start with RPM, delete it and install Apt, and keep going (or vice versa)?

The FHS (Filesystem Hierchy Standard) is designed to address this very issue: http://www.pathname.com/fhs/

Unfortunately it isn't specific enough. We need a second set of guidlines to deal with specific classes of software (KDE-based, GNOME-based, pytho n programs, Java programs, etc.). They have some special requirements (CLASS PATHS, ksycoca system, gconf, etc.) that probably need to be addressed. Until then it's up to the distros to decide these issues.

Debian, for example, has a set of "policies" to deal with Java programs, Perl programs, etc: http://www.debian.org/devel/. I think these should be used as a basis for an FHS-like standard.

Sounds to me like one of them isn't following the Filesystem Hierarchy Standard...

Directory paths are specified by the Filesystem Heirarchy Standard, not the LSB.

Either those distros mangle the path ignoring the spirit of the Filesystem Hierarchy Standard, or they ignore the standard all together.

http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINS YSTEMBINARIES

opt is my area where I can install my big self-contained stuff and not worry about it getting changed or overwritten at the next upgrade or apt-get. If Arch puts half of /usr in /opt, where is non-distro related software supposed to go? ~/stuff?

Could put your stuff in /usr/local.

There is a filesystem hierarchy standard

As defined by the fhs:
"/opt : Add-on application software packages"
"/usr/local : Local hierarchy"

That'll be tough. The "Distros" can't even decide on what files to put in what directories [...]

There is a standard on that.

I don't see the purpose.

• Static (not changed except by action of the system administrator), or
• Variable (subject to change at any time

• Shareable (multiple machines can have a common copy), or
• Unshareable (each machine needs a separate copy).

The 'aha moment' comes when you think of groups of workstations with identical hardware, which are candidates for having a common image from which they can be built, and realize that you can build a relational database that correlates MAC addresses (possibly to some other locally-unique but shorter machine number) to the HW configuration. Now, conceptually all of those cookie-cutter-identical machines are a single entity for the purposes of configuration. A lot of what FHS considers 'unsharable' is now quite 'sharable' within such a HW config group.

As workstations age, the IT department brings in a couple samples of the next HW configuration, loads drivers, tests against the app suite, and when they're ready for primetime, the vendor delivers them, the MAC addresses are added to the database, the workstations boot up, find Mommy (bootp server), and Just Work. The user can log out of an old computer and into a new one, and find all his 'stuff' right where he left it. It's the only sane way to compute in an institutional environment.

Given that the FHS is headed up by notables Rusty Russell and Dan Quinlan, I've got a lot of confidence in their judgement.

I'm sure you'll be flabbergasted by this and this then!

Where things were kept was probably my biggest issue when I first started to. If you want you can check here for more information on where everything is kept. It's long and dry, but you'll learn a lot. There is also this which is the migration guide the Germans paid for. If you ever just need a question answered and can't find anyone, feel free to send me a message through here. Again, good luck and have fun. :)

2. A consistent filesystem hierarchy is followed from distribution to distribution...

Actually all distributions should be following the Linux Filesystem Hierarchy Standard.

If yours isn't, then you need to get them to follow it, or find another distribution that does.

You would find this http://www.pathname.com/fhs/ a useful link to follow and read.

The FHS explains the why of the distribution of the various files tossed around the system by various packages.

As for the where were the files dumped, each package manager has a command to show you that.

rpm -ql package-name will list the files installed via the rpm for package-name

> 1) Standard control panel through EVERY distro & desktop environment. Gnome and KDE need to learn how to play nice. Obviously, this will involve some work at lower levels by others. We need everyone to create some STANDARDS here.

You could maybe lend a hand. The source is available, you know. First problem to tackle : write configuration software that will parse *any* configuration file thrown at it. That's not so trivial. Some configuration files have very hairy syntax (*cough* Sendmail *cough*). Next, make sure your software doesn't do a big mess while writing changes, this will irk power users (I did make a clean, commented /etc/fstab, and the stupid Mandrake configuration tool wrote back a mangled thing without comments or indentation. This is not acceptable). I wish you good luck. This ain't a piece of cake, to say the least.

Still, there are efforts in this area. One example would be the GNOME System Tools. Although I won't settle for something less than stellar, this kind of software could satisfy you. As for your demand that everything should be the same from distro to distro, I just can't understand why that would be. The very point of having more than one distro is, we get to choose which one is best suited to our working methods. And, generally, we end up settling on one preferred distro and we don't move anymore (instead, we go trolling on Web forums saying it is the best distro ;-)) For my part, I chose Debian. But I guess it wouldn't please you. That's why you'll be so happy when you'll be able to get Mandrake or SuSE (or Fedora, or Gentoo, or even Slackware, whatever).

> 2) An installer. n00b's don't know what the hell a freakin' tar.gz file is and once they do figure it out, they don't know to where they should extract it. If Linux had a standardized software installer (complete with a dedicated file extension that could be "picked up" from a browser click)

An installer... you mean, like apt-get ? You know, that tool you just tell 'install foobar', and it downloads and installs the program foobar ? Or would you like some graphical thingie like Synaptic, where you just click on the program, then on Install ? Don't tell me you're still building from source without some specific reason on a 2004 distro ? That's SO nineties ;-) Also, I gather you want the files to have specific extensions. I'm not sure why (MIME types are way better metadata to identify files), but be advised the .rpm and .deb extensions are just that. Ain't life cool ?

> 3) Rules for software companies. Right now, there's no problems with this as there are with Windows because Linux hasn't become mainstream. What am I talking about? Software installs run amok. I hate to see Windows programs putting shortcuts *everywhere*

Then, you'll just LOVE Linux : you see, the Filesystem Hierarchy Standard specifies very clearly where files go on a Linux distribution : binaries (executables) in /usr/bin, libraries in /usr/lib, data files in /usr/share/{programname}, and so on. The menus also have been unified between KDE and GNOME. Not to mention that package management makes it a lot easier to know what your package has really installed, and you'll be sure to find your configuration and documents in your home directory. No more nightmares finding them in C:\Program Files\Foobar\Obscure\Path\Name\You\Would\Never\Hav e\Thought\Of. Linux makes managing your software a breeze :-)

That's it. I hope I've been helpful, and I wish you good luck in your quest for a better Linux. But remember : diversity and freedom to experiment with your own solutions is what appeals so much to Linux users. A more rigid f

I'm confused. Are you complaining about doing things in a UNIX-like way, or about FHS?

I agree that Joe Sixpack would run screaming from figuring out FHS, but that doesn't mean that we need to get rid of concepts like pipes, using text for inter-process communication, and treating everything as a file. I think these are things that programmers enjoy and, simultaneously, thing that Joe doesn't ever need to know or care about.

I'm honestly curious, are you saying we should hide the UNIX-ness (ala OS X) or dump it altogether?

Get real!

If someone is worth their salt then skills learnt with one distribution will be transferrable to another. The days of rote memorisation being sufficient for passing are pretty much gone - it'd even be a challenge to pass a MS exam with zero understanding of what you had memorised. The days of any employer (or even client) being impressed solely by a certificate are also (thankfully) passed. Any cert is just another fibre in a CV bow that indicates a minimum achievment, which should be strenthened by experience in the field

Besides - last I heard Redhat pretty much followed the few standards that exist such as the FHS.

It's not as if redhat is the only distribution to have tools that it developed for itself

ahem.

read the FHS, then come back.

now, realize that while you can critisize what you don't understand, you come off looking about 14.

there are reasons for /usr/local and /usr, /bin and /sbin - try to understand what they are, and if you do any admin work above your desktop machine, you might agree they make good sense.

I realize that it comes as a surprise to many people, but the standard Unix filesystem arrangment is not just a random pile of stuff that's accumulated over time. The directory structure- though not necessarily the names- is the result of a great deal of experience and careful thought. While it might make sense to rename standard directories with more descriptive names, like "libraries" instead of "lib" or even "temp" instead of "tmp", any suggestions to change their basic structure need strong justification. Just read the Filesystem Hierarch Standard, and you'll see that there are some very good reasons for the existing structure. Proposed alternatives should include a reason why their ideas will work better than the existing layout.

locate and/or slocate are excellent tools for this. You may need to 'updatedb' as root in order to build the initial database of filenames / paths, but then it becomes extremely easy to '$ locate filename', and is a whole lot faster than using 'find' to traverse the entire directory structure to hunt down one file.

See Filesystem Hierarchy Standard for an expanded explanation of the filesystem structure, though your distro may vary significantly from it.

a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead

For all those thinking "what a nice idea":

afaik LSB requires FHS which, in turn, requires the standard directory structure. Does this mean we should throw the whole LSB out now?

And no, OSX is not LSB compliant - go figure.

This kind of proposal about scrapping the current directory structure has been discussed ad nauseum on the Filesystem Hierarchy Standard mailing lists. Here is the Standard Rebuttal against scrapping /bin and /usr/bin:

With each app in its own directory, your $PATH becomes a mile long, and too difficult to maintain.

Different application packages can have identically-named binaries. Upgraded packages always have the same binary names.

The Standard Rebuttal against scrapping /lib:

Apps which depend on other apps for libraries won't know where to look. This is especially true if each installed version of a required app is stored in its own numbered directory.

Rebuttals for getting rid of /usr (i.e., having a One (Partition) Size Fits All approach):

#1: Some boxes have read-only disks for security (CD-ROM firewalls come to mind). Now you can't install new applications.
#2: You have one 100GB partition and you get a power spike. Now you have to wait for the fsck to finish before you can troubleshoot the damage.
#3: You're in a diskless environment with centralized, NFS-mounted applications. With no /usr, you have no suitable mount point.

On the mailing lists, the use of /package (or /pkg) also has been discussed ad nauseum. Keep in mind that the filesystem hierarchy is designed so that non-local (commercial) packages don't step all over each other when installing. Local (enterprise) software installation can happen wherever the hell you want it to, as long as it doesn't have to play nice with COTS software.

Executive summary: you can run whatever directory structure you want -- I won't stop you. Just expect to hear lots of complaints from your developers and sysadmins. The reason things are the way they are is partially due to industry inertia, but mostly due to the fact that they just work better that way. If you don't like it, go contribute.

The latter.

The system makes a lot more sense when you start thinking about either a) putting different parts of it on different machines or b) backing it up.

You can fish through this to explore some of the ideas behind the structure. Is it perfect? No. But it's not as arbitrary as it seems at first, either.

The FHS specified that you can install packages independently in /opt.

See it here

Installing different packages in their own directories... this is nothing new.
Indeed, this has been specified in the FHS (Filesystem Hierarchy Standary) long long time ago. This is what the /opt tree is for.


Indeed, I've always been wondering why major Linux distributors haven't been using the /opt tree for simplicity, but kept on keeping all the files together in /usr and /usr/local. That's a hell to clean up when your rpm or apt doesn't work.

I couldn't possibly agree less. One thing I like especially about linux is freedom of choice. I positively *love* having dozens of browsers available. I like having a gazillion of different toolkits at my command, also as a developer. I like being able to chose from a plethora of window managers.

And even more important: I like being able to chose from a wealth of linux distributions, each one taylored to different needs, so that I can choose the right one for me without having to flame about that stupid thing being designed for n00bs/geeks/servers/games/whatever. Instead I get what I need and ignore the rest. That is what I hate about Window$. It is made to fit the needs of one specific group: The people who just want to Run That Damn Thing (tm). This is the lowest common denominator. If I want to go beyond that in Windows I suddenly find myself doing things of a crypticality-level far greater than anything I ever did to my linux system.

Imagine if Bruce Perens' UserLinux came with nvidia and ati's binary drivers and automatically installed them during the distro installation. Currently no distro that I know of does this, the drivers must be manually installed.

Okay, so what if I don't want them stinkin' nvidia and ati binary drivers? I severely dislike my computer forcing anything on me (except perhaps basics such as glibc or XFree).

One could argue that in most cases you have to do the same thing in Windows, but in Windows all that requires is double clicking an install file. In Linux you have to usually exit X, check dependencies, and all kinds of other cryptic stuff.

The downside to this is when it doesn't work. When I last installed windows on my box, I spent several hours installing seven different versions of the nvidia graphics drivers. No logs, no error messages, the stupid thing just hung in the middle of boot. I had to dig out an installation disk from once upon a time and install an obscure, old (prob'ly buggy) version until it worked. I still don't know what went wrong. With linux I could have resorted to the open-source nvidia-without-3d driver. Doesn't accelerate well, but actually works.

Finally, the one thing that we most need that a standardized distro can provide, is a standardized directory layout. None of this /usr/bin or /bin or /var/usr/bin confusion. If one distro took over by having all the features that desktop Linux needed, which in my view is basically Fedora to unify toolkit look across gtk, gtk2, and qt, but with better hardware detection (ala binary non OSS drivers) and better package management (ala automatically installed apt-get), the standardized directory layout would encourage more Linux ports of games.

I'm curious. What is /var/usr/bin supposed to be? The standardized directory layout has been there for ages, it's just that no one cared to follow it. It's called the FHS (filesystem hierarchy standard). Check it out, it does what you want.

As for one distro having all the features users need, what users? Newbies will have different needs than die-hard geeks have. My first linux distribution was SuSE. As long as I left the system under YaST's control, everything was bliss. Then I developed some courage and tried to update the thing online. Half of the update RPMs failed for some obscure reason (often involving dependencies).

So I switched to Debian, which is generally seen as having better dependancy handling than SuSE, but is less comfortable. Updates with Debian were smooooth. The installation procedure reminded me of FreeBSD, though. Definitely not ready for the desktop. Plus, Debian's stable packages are old. So I tried the move to unstable. Suddenly I was left with a system that was somehow broken in new and interesting ways.

So my next move was to Gentoo. The first time I tried it, the installation proc

I'm using SUSE as my primary distro for a couple of years now, and I think SUSE has evolved greatly, supporting Linux standardization efforts widely.

While they are definately producing one of the most polished distro's available, it deviates from most linux distributions somewhat dramatically

There will alway be differences between different distributions, but I think that LSB and FHS compliance is the key. SUSE 9.0 is e.g. certified to comply with LSB Runtime Environment for IA32 Version 1.3

I still don't know how exactly the init system works.

The init system is designed according to the LSB specifications. I personally find it very easy to use.

I also found that you HAD to do things SuSE's way ... you couldn't do it yourself because YaST would stomp all over your changes.

Why this partly was true for older versions of SUSE, the sitaution is much better now (or my knowledge on how to do things improved:-). Of course, there are things like when you have a configured X and then start the X config programms, you'll get an altered XF86Config. But I find that's hardly surprising.

I happily alter config files by hand all the time and I experience no problems using YaST on other occasions.

(again, you can't just update say, package X from a source tarball because SuSE will throw a fit).

You know what package management is all about, right? How can you expect the system to know about your nicely compiled update if you don't tell it? You can't get it both, the comfort of managed software installs and the freedom of source upgrades without spending some work on it.

I frequently install software from source, either newer versions than the ones from SUSE or stuff not supplied by them. The key is to build packages out of them. It's really not that difficult (it gets difficult when you want to build a whole consistent distro, that's why I happily pay for SUSE's boxes - they do all the dirty work).

It's probably not bad for novice and intermediate computer users; I'd reccomend that experienced users who want a pretty desktop with little hassle use Mandrake.

I'd recommend SUSE for both :-) I think SUSE is a very nice distribution usable both for the newbie and more experienced users. Heck, I also like Debian and SouceMage, but in my experience, SUSE delivers a good allround solution. That's why it runs on my laptop, my desktop, and some servers around here. The cluster, otoh, belongs to SourceMage :-) .

So, yes, my experiences do differ. But that's OK, isn't it?

Finally, the one thing that we most need that a standardized distro can provide, is a standardized directory layout. None of this /usr/bin or /bin or /var/usr/bin confusion.

instead of mouthing off, maybe linking to the LSB standards page that contains the specifications. Thing is, you probably mean theFilesystem Hierarchy Standard /etc/firmware may not be in either documents, but since it is used by MANY rpms, including the kernel-util rpms for microcode data it is the de-facto standard for binary firmware images that need to be accessed by device drivers at boot time....

I totally agree with that. But I think there should be two options for a each distribution - the native one, and a cross platform one. For filesystem layout, cross-platform packages should assume that everything defined in FHS - Filesystem Hierarchy Standard (part of LSB). And the distributions should provide that, either by changing their native format to conform, or providing some sort of compatibility layer (symlinks, for example). So if you want to make a .rpm, good for you, but it'll only work on RedHat. If you want to make a new-fomat package, it'll work on all the major distros. Unfortunately, these debates seem to get mired down in flame wars about how apt is better than rpm, and .tgz is far superior to everything else, etc, etc.

• Binaries meant for normal users go in to /usr/bin, unless they're part of the base system, in which case they go in to /bin. If they're part of XFree86's special playground, then they go in to /usr/X11R6/bin, but that's really an ugly holdover more than anything.
• Binaries for administrators go in to /sbin or /usr/sbin
• Shared libraries go in to /usr/lib or /lib, depending on how close to the base system it is. Sometimes they put their own subfolder in /usr/lib, but not as often.
• Executables meant just for the app and not the user, as well as images, sounds, etc go in to /usr/share/appname
• Documents go in to /usr/share/doc/
• System-wide config files go in to /etc

emerge is a step forward but still not the answer. Bandwidth is expensive and it does not scale.

Backwards compatibility for libraries, often times there are packages I cannot install without installing a newer version of a library that breaks other packages. This is a useful feature if you are using more than one package that uses the same library.

The idea of placing desktop applications on a handful of /bin, /sbin, /usr/bin /usr/sbin directories is in bad taste. ping, traceroute, fdisk fine. But there is no directory set aside for GUI applications. It would be like taking every file on a windows machine and moving it to either /windows or /system32. This is not a requirement for POSIX compliance, but hey, the current method sucks and of you are saying is NEEDS to stay that way than you are just reinforcing my point.

It would take all of 2 minutes for someone to add one line to FHS 2.3 that says "3.4 /apps : Optional directory for graphical applications" but that will never happen. There are 59 sections in FHS that state where to put everything but GUI applications are not even mentioned. That might have something to do with the reason people seem to throw them all over the disk.

Figuring out where shit is requires checking the package manager DB or running locate, which, whereis, or something like 'find / -name application 2/dev/null' THAT is intuitive. On my windows box I can tell you Trillian is in /program files/trillian without having to look.

emerge is a step forward but still not the answer. Bandwidth is expensive and it does not scale.

Backwards compatibility for libraries, often times there are packages I cannot install without installing a newer version of a library that breaks other packages. This is a useful feature if you are using more than one package that uses the same library.

The idea of placing desktop applications on a handful of /bin, /sbin, /usr/bin /usr/sbin directories is in bad taste. ping, traceroute, fdisk fine. But there is no directory set aside for GUI applications. It would be like taking every file on a windows machine and moving it to either /windows or /system32. This is not a requirement for POSIX compliance, but hey, the current method sucks and of you are saying is NEEDS to stay that way than you are just reinforcing my point.

It would take all of 2 minutes for someone to add one line to FHS 2.3 that says "3.4 /apps : Optional directory for graphical applications" but that will never happen. There are 59 sections in FHS that state where to put everything but GUI applications are not even mentioned. That might have something to do with the reason people seem to throw them all over the disk.

Figuring out where shit is requires checking the package manager DB or running locate, which, whereis, or something like 'find / -name application 2/dev/null' THAT is intuitive. On my windows box I can tell you Trillian is in /program files/trillian without having to look.

Most people criticize the unix file system w/o realizing that a lot of thought has been put into its design.

The key here is that they are attempting to put something together that our naive end users will be able to dig and thus buy - pushing the precentage of desktops more on an even keel with you know who. This can't be bad for the Linux world domination conspiracy -er- Linux users... :)

One of the major complaints I hear is about differing interpretations of the file system hierarchy. While I think standardization is good, I also believe developers should have a certain amount of flexibility - which the standard allows. The key here, I think, is for the distributions to honor the locations that the developers established for their files - so compatability crosses all boundaries and documentation can be maintained by the developer on the particulars of his application - instead of the distributor. In cases where the application creates problems due to inappropriate placement - the issue needs to be raised to the developer to correct his implementation; distributors would have the option not to include the application/system if it was too disruptive - but that is all (more than this and the distributor can cause more problems than he intends to fix). Developers need to understand the standard; distribution creators need to cede the responsibility for application locations to the developers - with the right to veto bad locations from entering their distro until corrections are made by the developer. This way, no matter which distribution you are using, foo.ini is located in the same place every time.

Related to this, and probably more frustrating for end users, is when application developers make assumptions about libraries and other applications that exist on the system during the build. For hard core *nix system administrators this is no big issue - something they have been dealing with for years; however, for a general purpose workstation this has to be idiot proof. Coupled with standard locations includes being able to check those locations for particular files, and if not found, have the confidence to load them for the user, rather than simply complaining and dropping back to the command line. Again, the onus is on the developer to include all parts necessary to work with his tool (perhaps even going so far as loading a different library in an alternate location [sub directory in standardized path location] - then changing an environmental variable used exclusively by the application to locate it without disturbing an existing library or any applications that depend upon it - lets definitely do it smarter than Microsoft DLL hell)

These two items coupled together would make installation and maintenance across all distributions easy - and dependent on the documentation and careful work of the developer community - instead of left at the whim of the distribution agents - who are not on the same sheet of music. If developer X creates app Y and puts it in location Z - then Z should be where everyone finds Y when they look on their system.

Finally, I think easy to use tools for administering very clearly standardized core items (the rc.d run level scripts, crontab management, X configurations etc...) should leverage existing text based configuration files. Lets not get into the trap of reimplementing the Microsoft registry - as a single point of failure. Up to this point these types of tools have been adhoc; someone needs to take the ball and run with it to create something that is clearly superior and usable for all distributions that intend to target the niave user (hmmm - sounds like a good open source project to me - maybe a python Tk gui with a builtin command language parser for power users... :)

These are the core items I think are critical to a successful linux desktop to compete with Microsoft's dynasty.

One additional frill I would suggest:
Implementation of a better 'Annotea' W3C

yo its not imaginary
click here

Unless the assumption is that any significant portion of the OS X user base actually uses the shell, I doubt there will be many that even notice.

I still view OS X as a definite non-unix. It's right up there with say, windows+cygwin. A non-unix kernel with some unix userland stuff sprinkled on top.

And to address the "But it's the best integrated Unix desktop ever!" argument, tell me why the tar that ships with it breaks all the filesystem meta information (which many mac apps still rely on, in my experience). I've heard similar problems with the rest of the user space utils (i.e., cp)

Or, of course, the complete disregard for the Unix filesystem hierarchy standard

-transiit

You are probably more inclined to than look at this project than POSIX compliance different issue altogether though within the scope of LSB.

POSIX compliance is mainly in the API
while the directory layout is a matter the LSB is approaching it is not part of POSIX specification except for some directories that must exist.
Detail

The point is not that it's theoretically possible to move apps or RPM under linux, or it can be automated if you do some fiddling under the hood (and anything that involved touching a file that starts with a '.' is almost by definition under the hood), but that Linux should offer this functionality automagically.

Why should it? Because it's possible in Windows of Mac OS? Or because it adds some useful functionality for a user, in which case what is that functionality?

For any given app, in a properly organised Linux system, there is only one right place. Being able to move it to the wrong place is not a benefit.

And if you're going to whine but what happens if the file system is full, isn't it time you were using logical volume management?

Installing or moving apps in Linux can be a nightmare. In OS X its just drag and drop. Why can't we improve?

In what sense would it be an improvement? It looks to me like a category error, or someone who doesn't understand how UN*X systems are organised.

Why would you want to put different programs all over the place? Your PATH would be huge.. and there's no point. There is a standard that describes how the filesystem should be laid out. Linux FHS

Running out of space? Increase your logical volume size and grow your filesystem.

Want to copy your configuration over? Copy all of /etc. Don't want to backup data that you can get from your distro? Just backup /home /var /etc and /usr/local. Very simple, well-defined ways of using the filesystem.

Guess what? Lots of smart people have been doing it this way. Guess what? It works.

Linux is not MacOS. MacOS X is not a Unix(tm) because its filesystem layout is all fucked up. That is why they failed the Unix conformance tests and that is why they are getting sued over using the term Unix.

-molo

Hmm. Actually Solaris and HP-UX do. My Linux box seems not to, however. It seems I misremembered the Linux Filesystem Hierarchy Standard. On Solaris, /bin is a link to /usr/bin which would mean it might not be mounted on a given boot. If you follow the FHS, /bin is supposed to be part of / and therefore this takes away the problem I stated before, and the FHS says /sbin should be things run by root only and /bin things that everyone runs. I don't think /sbin should be suid programs.. that sounds backwards to me.

GoboLinux Rethinks The Linux Filesystem

Filesystem Hierarchy Standard has included the BSDs since 1995 - it's more than just Linux. I'm all in favor of questioning the assumptions to avoid getting caught on a local maxima, and I think this one is a dead end. FHS has some historical baggage, but it also has the strength of years of tempering.

IDE's suck anyways. They don't support autotools

Perhaps you mean to say that current IDEs suck? What's stopping an IDE from integrating autotools support? I'd use it. I don't know how to use autoconf/automake (more from lack of caring than anything), but I think if an IDE made it easy for me, I would. As well, why does an IDE need to support autotools? There's no reason why you need to compile within an IDE. I spend probably 95% of my programming time writing code in an IDE but compiling it from the commandline. I don't use the IDE to compile, but I'm not going to switch to notepad because I like all the extra features I get from the various IDEs I like.

Don't give me the "X86" only thing because there are now probably 10-15 somewhat incompatible varieties of X86.

And unless you're writing assembly code, you're never (well, 99.5% of the time) going to see any of those differences. The compiler should take care of those small differences.

For Debian at least, you can use GNOME, KDE, GTK, whatever you want because the package will pull in all the required libs when you go to install it. It's a no-brainer for the user, and not much more work for the developer either.

And now you've got a debian-only distributable. People cry foul when someone like Oracle (for example) releases their product only for Redhat, but that's what developers are forced to do. Distributions are just too different for a developer to support more than one or two of them. I know there's the FSH, but filesystem standards aren't enough. Linux needs one standard interface for common functions, like ui for instance -- why do we need 50 different UI widget sets? pick one, whether it be gtk or qt or something else, and make it standard. You can be assured everybody with Linux will have that widget set, and so you can confidently write against it without having to add another dependency to your project. Dependencies suck. Look at trying to compile GNOME by hand. You have to track down a metric pantload of different libraries before you can even get the core installed. Yes, package managers make that easier, but there's another problem -- we've got deb, rpm, tgz, and whatever else, and even within those things are different. An rpm for Redhat may or may not install on SuSE or Mandrake, and vice versa.

The point here is that without having some guarantee of what will be available to every end-user (not that they can get it, but that they already have it), few developers but the hardcore will target Linux because they either have to give up potential users or write to the least common denominator (ie, write directly to X for UI work). The former costs potential profits, and the latter is simply way too expensive (not to mention that it's usually only the hardcore that have that kind of knowledge, anyway). Testing for multiple distributions adds major complexity. Text matrices are already huge given the variety of hardware developers need to support. Adding in tests for every distro (multiply the costs of testing by a factor of N, for N distros), and for each distro they have to test scenarios where various optional components are not installed that the software requires. It's a mess, and Linux will have a hard time gaining ISVs if it doesn't do anything about it. Windows isn't better by much (though it's getting there with the death of the Win9x line), but it's still better.

Great... another person itching to reimplement Window's design mistakes. Listen people, as a datastore, the Windows registry is nothing more than a specialized filesystem. It's atrocious because you cannot manipulate it in the same way you can a regular filesystem... it's difficult to work with. If you're going to push standardization, why not advocate something truly neat, like creating a standard config file syntax in XML with governing schemas and GUI tools that help with configuration.

What we need (and what the Windows registry provides for Windows) are standards that govern where things go and how they get installed, and we already have those in the form of a loose confederation of unix conventions and packaging formats. On Debian, for instance, all packages adhere to the File Hierarchy Standard and Debian Policy. The last thing we need is a meaningless overgrown forest of GUID's that are hard to get to, back up, maintain, inspect, and live with.

/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/ directory tree, where is a name that describes the software package.

This is the primary directory of executable commands on the system.

I'm not too bothered about the whole LSB issue. But I'd love it if Solaris at least adopted the Linux FHS. This is one of the best thought out and best documented standards I've seen in a long time. Everything has its place, and everything is given a rationale to explain why it's there. Solaris has inherited too many things from Unix that were poorly thought through at the time, but have stuck due to inertia.