Fedora (Linux) is Destroying it self

[Ian Chapman]

Michael Nielsen wrote:

>> Simply not true. Right this moment I'm copying podcasts to my mp3 
>> player which was mounted directly by Gnome. It's accessible under 

> Try to mount an NFS/CIFS, which were what i was talking about, sorry for 
> being imprecise.

Appears under .gvfs? At least in Gnome. I'm still failing to understand 
why this is a problem though. Even if as you're saying it's impossible 
for scripts / command line programs to access shares mounted through the 
GUI, then mount them the 'traditional' way. Be that via fstab, 
automounter or whatever. Really, what have you lost?

 >> Solaris systems amongst others, I get tired
>> of playing guess the location of the binary, hunt the man page and 
>> setting an ever increasing $PATH.

> Actually all the install script (for the application) was to update the 
> global login scripts, for the PATH variable, then the user
> would see it as if the whole system was a flat directory.

Seems messy to me. I have a well loaded system, 2214 packages installed. 
If as I think you're suggesting, most of these would be under /opt in 
their own tree, I can just imagine the size of $PATH.

> It is a big disadvantage when testing, because the current scheme 
> prevents having Firefox-2 and Firefox-3 (apache-1.3, apache-2.2 etc) 
> installed, under package management because they contain files that 
> conflict, similarly with 64 bit systems, where you need to install 32bit 
> compatability software, they usually conflict, due to irrelevant 
> documentation files conflicting.

It is perfectly possible to have multiple versions of a package 
installed, providing it meets various requirements. Most people usually 
have at least 2 kernel packages installed for example. The current 
scheme doesn't prevent what you're suggesting, it just discourages it. 
You are still able to install software in /opt if you wish, either from 
a tarball or from an rpm. In addition, I suspect there would be a 
serious lack of man power if you expected the Fedora packagers to 
maintain multiple official versions of many packages.

> I find it a huge problem, when there is a problem with system package, 
> that I need to replace with a newer version, sometimes there are files 
> left behind, that cause problems when you compile your own version.

RPM does a good job of cleaning up after itself. Far better than the 
average human chucking tarballs over the system could. The kind of 
problems you're describing, I've only ever really seen when people 'make 
install' over their system files, or don't follow the logical upgrade 
route. Eg, installing Foo V1 from repo A but upgrading it with Foo V2 
from repo B. Sure, somebody can build a terrible RPM which is just plain 
nasty but that's not the norm for Fedora, nor a fault in the 
methodology. I've seen vendors package a tarball inside an RPM, which 
installs everything in the %post scripts. As far as the RPM database is 
concerned, all it's done is installed foo.tar.gz in /tmp.

> Also you cannot with the "everything in one dir" philosophy handle the 
> situation where a user (or administrator) compiles a newer version from 
> source, and there is a version installed via the package manager..

Of course you can! Just don't install the self compiled version over the 
top of the packaged version. Lookup --prefix and DESTDIR=. Users can do 
the same in their home directory.

> You can avoid using the GUI (which I prefer), however, what I mean is, 
> if you use the gui to configure the network, and you're not careful, you 
> can find that the configuration you performed, is tied to your GUI 
> account, and when you reboot, the settings are lost, until you log in 
> again.

Then do it from the command line, like you prefer? What's the problem? 
If you're a power user, I would imagine you would know what belongs to a 
user's session and what is system persistent. If you're a novice user, 
then I would think you'd enjoy choosing your network from the 
NetworkManager applet and would not care that your network settings were 
specific to your session.

> I don't like the approach of creating 
> parallel configurations, that are tied to the GUI.

That's the whole point! UNIX has always been a multiuser system. User's 
have their configuration files and there are system wide configuration 
files. Why should all users be forced to use the system default display 
mode for example? Sure set a system wide default, but if one user wants 
  1600x1200 when they log in and another wants 1024x768, why limit it?

-- 
Ian Chapman.