Fedora (Linux) is Destroying it self

[Krzysztof Halasa]

Michael Nielsen <mike at thetroubleshooters.dk> writes:

>     This is called the Filesystem Hierarchy Standard, and it encodes decades of
>     experience organizing file systems into a standard which minimizes
>     differences across implementations.
>
>
> I know of the standard, however, I really doubt the current Fedora
> configuration really
> follows it, I still don't see why everything needs to be thrown in
> /usr/bin? 

The standard says binaries go to /usr/bin, so it then seems current
Fedora really follows the standard :-) BTW UNIX was doing this for ages
(with the long gone exception of executables in /etc).

> Currently
> on some installations, if you try to open them, are exceedingly heavy, I've had
> smaller
> machines stall out, as I try to change the application that starts when for
> instance a movie
> is to be played in firefox, apparently due to the amount of files in
> /usr/bin.

You've got many executables, you've got many files in /usr/bin.
What do you want instead, that many directories (where?), each
with a single file?

>     Actually Window$ is the system which started this "one directory per app"
>     stupidity. *nix has never worked that way.

I guess perhaps DOS started this.

> I beg to differ, having worked with several different UNIX flavours, I've yet
> to see a commercial
> UNIX that throws everything into one directory.

Fedora doesn't throw everything into one directory either. Binaries go
to one directory (actually at least four), libs go to others, shared
files and directories go elsewhere etc.

I wonder what different UNIX flavours you used were different? I was
using several and all of them used a similar scheme.

> ones in 1999, and went to Linux then.   I noted the installation procedure of
> not throwing everything
> in one directory, before windows 3.1 was implemented, so I doubt it started
> with windows.

Windows, or DOS maybe, started to put all files (binaries, libs, text
files, shared arch-dependent or independent :-) files in a
one-per-program directory. What a mess.

PATH=c:\program1;c:\program2;c:\program...999
gcc -Ic:\program1\include -Ic:\program2\include ... -Ic:\program999\include
No, thanks.

Though I think it had a positive side, too - it was really easy to
remove a program. They didn't do any package management, you know.

BTW Windows 3.1 wasn't exactly the first version.

> Windows have seperated parts of the applications into specific directories, is
> a good idea,

Seen better.

> however,
> in Windows everything that is shared, is thrown into system32, and therefore
> removing an installation
> of a problem is nearly impossible, because there is Junk spread throughout the
> system, relating to a
> particular application, one of the causes for problems with windows.
>
> Thus if you need to run a non-packaged software, due to patches that you need
> (security), you can
> only hope that the package manager successfully removes everything, and does
> not leave junk behind
> which may, or may not affect the running of the newer compilation.

Perhaps they need a better package manager? I guess they could use RPM.

> Throwing everything in one directory hierarchy causes one particular problem
> that I personally find
> rather annoying, the inability to use the package manager system to have
> multiple versions of
> for-instance firefox installed on a system

Nope, you can have multiple versions. The package has to be created with
this requirement in mind.

> The same situation can be seen when you run 64 bit systems, sometimes you need
> to run something
> in 32bit compatibility, however you cannot install the libraries you need
> because of conflicts in the
> packaging system, as - again - everything is thrown into one directory - in
> this case the /usr/share/doc
> directory, which means you need to find out how to force the installation of
> the libraries.

It would be a bug. Bi-arch (32 + 64-bit) packages are created to coexist.
-- 
Krzysztof Halasa