Ian Malone ibmalone at gmail.com
Sun Nov 10 21:56:57 UTC 2013

On 10 November 2013 20:55, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Sun, 10 Nov 2013 18:02:46 +0000, Ian Malone wrote:
>> You are arguing that system management should only be possible through
>> a GUI where the affected components are themselves graphical.
> No, not at all.
>> Please take some time to reflect on how ridiculous that is.
> http://fedoraproject.org/code-of-conduct

The dreaded code of conduct! I'm being horrible to you! I take it all back!
Hang on: "When we disagree, we try to understand why." That's what I asked.

>> Should non-gui packages be excluded from automatic updates because the
>> tool used to manage that is graphical?

> without affecting LibreOffice.  A "System Updates" tool that handles all
> updates of installed low-level "packages" could be a completely different
> piece of software.

>> Should firewall management be only possible at the CLI?
> No. And firewall-config is a GUI.
> I don't understand why you've asked that question.
>> I'm looking at the software management menu
>> in KDE right now and on my system there are 26 entries listed in the
>> servers management section, since these are non-graphical should they
>> be dropped?
> I don't understand why you've asked that question.
> It seems to me you may have misunderstood something _completely_.

You're the one that keeps saying you don't understand...
I'll try again. And then I'll give up, because I know how futile it is
to argue when the other side is has already decided how things must

> What I don't like is the situation that somebody uses a graphical tool to
> install "software", and the installed stuff doesn't show up anywhere in
> the graphical desktop user interface (such as a menu system), but is only
> listed as installed. That's the "WTF?" scenario, where the user needs to
> be an expert to figure out that the installed thing is CLI-only (or not
> even "executable" at all) and something that cannot be "used" from within
> the desktop UI.
> If an "application installer" will be able to install arbitrary
> "packages", I would welcome a very obvious distinction in the UI,
> a special interface for specific types of components and "add-ons".
> Not old-school ambiguous "categories". What I don't like is a graphical
> "package tool" that tries to handle the 40,000 "packages" by sorting them
> into categories. And the user is confronted with many thousands of "lib"
> packages, for example, which are no "applications" (no "programs" to
> use). A developer (or a sysadmin) has different requirements.

What you are saying here is that if we want a graphical package
manager it must be separate to an 'application manger' for 'normal'
users (you've used the word 'software', which until today I thought
meant anything that ran on a computer). I can only see that
*increasing* confusion as you're creating a distinction based on
whether a package contains graphical tools or not. And to work out
where you want to install something from will depend on whether it's
an application, a tool or a library. And so someone who has started
with the system for a while and finds they want to install a library
or command line tool now has to learn a new tool to do it with.
I agree with your final paragraph, I don't see why it should be a
problem to simply distinguish in the package manager what the type of
package is. It's got a desktop file, it's probably an application, it
doesn't, it's probably not.

Finally, to return to auto-launching of programs on install. I don't
think it's helpful. This is the only time the user ever interacts with
the software in that way. Afterwards they're left to figure out on
their own where it is.


More information about the devel mailing list