[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora (Linux) is Destroying it self



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]