Fedora (Linux) is Destroying it self

Yaakov Nemoy loupgaroublond at gmail.com
Mon May 11 14:35:56 UTC 2009


This is trolling, not starting debates.

2009/5/11 Michael Nielsen <mike at thetroubleshooters.dk>:
> Hi,
>
> I've been told this is the right place to place this debate starter.
>
>
> Not to demean the fine work that has been done in maintaining fedora,
> however the distribution is slowly killing itself, being destroyed by
> contradicting philosophies. Many of the problems have been directly copied
> from the Windows world.
>
> The main problems are.
>
> 1. Removal of features - the user interfaces are being dumbed down, like
> recently I've searched for the ability to remove the "Raise on Click"
> feature that is default for Gnome MetaCity, there does not appear to be any
> such feature anymore / argument being to simplify how it works.. Fine,
> create a simple view and an advanced view for the configuration tools, so
> that people who are clueless about any other way than the official Redmond
> way, can avoid being confronted with an alternative.

This is upstream and has to do with Gnome. Fedora stays as close to
upstream as possible, which means if the Gnome developers think this
is a good idea, then this is (possibly) a good idea. If you don't like
it, get a clue and install a different window manager. Try Openbox.

> 2. The network interfaces are being bound to the user interface, such that
> if your X fails for some reason, or you are running on a text console, you
> are unable to open the wireless configuration, at least it's not obvious how
> you do it, without X running. The configuration for the network interfaces
> are so tightly bound to the user interface, such that if there is no user
> interface there are no network interfaces.

This is the artifact of working in a desktop environment. If you need
more functionality then you are a power user. There is a very advanced
interface for configuring the network, we like to call it the command
line.

Not to be picky, but in your previous post, you commented you want a
simple and advanced view. Think of the desktop as a simple view, and
the command line as your advanced view.

>
> 3. Mounts are also embedded into the user interface, rather than in the unix
> mount system, which means that the shares are not accessible for non-gui
> programs, for instance, I like to script most thing I do often, however,
> there is no way for scripts to get a hold of a drive that is mounted through
> the gui mount system (kde and gnome).

You're right, they could potentially do a bit better. Except that they
do, most of your mounts should be available in /media.

If you have a specific complaint, please file a bug report on Gnome or KDE.

>
> 4. Everything is thrown in huge collective directories, such as /usr/bin,
> /usr/lib etc, and it is a huge mess, just like windows with it's system32
> directory, which is also a huge mess. really the /usr/bin,/bin/sbin, /lib
> etc, has very specific purposes, and should represent a core operating
> system, that is capable of being used as repair, with no major applications
> present. However even Open office is stored in these directories.

This is by design. Complaining about the design isn't going to start a
debate unfortunately.

If the design really does bother you, try Gobo.

http://www.gobolinux.org/

>
> 5. More and more services are bound up in the userinterface, such as the
> pulse audio, which is started by the GUI, this means if you use 2 user
> environments, which I often do for testing, where I have X:0 and X:1
> running, the GUIs will conflict, because you cannot run two instances of
> pulseaudio. In addition pulse audio is crap, I have yet to see any
> installation actually work without crackling, and chopping like crazy. I
> like the concept that is the basis of pulse audio, but it just does not
> work.

Read the answer to #2. Also, if you have a specific complaint, file a
bug on Pulseaudio and Alsa.

>
> 6. NetworkManager which appears to be installed default, does not work with
> shared drives, because, the NetworkManager is shut down before the network
> drives are detached, and you need to modify the NetworkManager to start
> properly, before you mount the network drives. I've gotten used to explicit
> uninstalling the NetworkManager, because it just doesn't work properly.

Again, you're a power user. Reorder your shutdown sequence.

>
> It is a lengthy discussion to describe what i mean.
>
> However, if I take a sample application like firefox, it presents a
> reasonable proxy for what I mean.
>
> currently default installation of firefox on my machine installs firefox in
> these following places.
>
> /usr/lib64/firefox
> /usr/lib64/firefox-3.0.7
> /usr/lib/mozilla
> /usr/lib64/mozilla
> /usr/share/mozilla
> /usr/bin/mozilla-plugin-config
> /usr/bin/firefox
>
> etc.
>
> All of which are related to the firefox installation. If something goes
> wrong, it's a real pain to clean it up, or even to detect what went wrong.
> The original concept for unix was to install an application such as firefox
> in either, /opt or /usr/local/. Such that the entire application was
> contained within a single installation directory, and then to use the PATH
> and LD_LIBRARY_PATH to allow the execution of the application.
>
> The standard approach with /opt or /usr/local installation also makes it
> triviel to have multiple installations, and configurations operating in
> paralellel, by simply creating.
>
> /opt/mozilla/firefox -> /opt/mozilla/firefox-3.0.7
> /opt/mozilla/firefox-3.0.7
> /opt/mozilla/firefox-2.0.9
>
> A user can then easily conifgure their account to use either version of the
> application, without installation problems.
>
> Additionally using that installation method, also means that if someone
> wants to use a newer version of an application, they can download the
> source, and trivially install it in parallel to the package managed
> application, by using the --prefix option, and the installation can easily
> be removed, by simple rm -rf /opt/mozilla/firefox-3.0.7.
>
> With the current installation, it is nearly impossible, or at least very
> difficult to find out if the package manager has cleaned up properly, or if
> there is something left behind - something which is identicial to the
> problem on windows.

Wrong, see Gobo if this is a feature you want.

Using this split up file system layout is by design, it's a standard
of the Unix Way of Doing Things. Everything that ships in Fedora
and/or a 3rd party repo that is designed to integrate with the core
functionality will use this layout. /opt is for third party software
that doesn't want to behave. /usr/local is for bits that are specific
to your machine.

If your installation fails it's because of two things. A) there is a
bug in RPM/Yum that needs to be fixed. The design goal is for these
bits to be rock solid reliable. They should never fail.
2) Your power went out. RPM and Yum really should recover and continue
from where they left off. Handling such a use case is really a very
difficult to solve problem. If you have any concrete ideas, let's hear
them, but complaining about the file system layout is not going to
solve the problem one bit.

<snip>

> I'm really curious as to the reasoning for moving everything from the
> standard configuration mechanisms to the gui layer, breaking compatibility
> with scripting, and other standard UNIX featuers..   I'm also curious as to
> the reasoning for throwing everything in one huge mess in the /usr/bin,
> /bin, /sbin, etc..   As all that is achieved is to make it hard to strip the
> system back to a minimal setup.

Is there anything concrete that breaks? Can you give us an example of
shell code that doesn't work in Fedora 11 anymore?

-Yaakov




More information about the fedora-devel-list mailing list