Ubuntu Desktop Favorite Apps

Xen list at xenhideout.nl
Sat Jul 22 16:41:50 UTC 2017


Ralf Mardorf schreef op 22-07-2017 17:23:
> On Sat, 22 Jul 2017 11:26:56 +0200, Xen wrote:
>> Linux does not have a good single-window (no tabs) text editor.
> 
> Perhaps xfw is "good" for your purpose?

I did not write my message to get attention for the only purpose of 
exposing my personal gripes and issues.

As you may have noted the points you disagreed with are points that 
would be relevant for non-hardcore-linux users. So they are relevant for 
ordinary or I wanted to say, average desktop users.

>> The only viable solution for copy and pasting in terminals
> 
> Given that you could use the completion feature via tab-key and
> history features via cursor-keys and replace parts of what you already
> typed instead of retyping everything, you unlikely need coping from the
> clipboard. E.g....

I was talking about copying to the clipboard.

> [rocketmouse at archlinux tmp]$ ^123^ echo

Power tips are fine, but new users or even long term common Linux users 
who love Linux but are not computer scientists or tech power users or 
developers would still need to be able to use the system. Having to 
learn every single power tip in the book before the system really starts 
to work is not doable. That is like being rewarded after death by 
something like paradise, but in the meantime you weren't having fun ;-).

I mean it's the carrot to hold in front of the donkey: one day it will 
work for you.

The solutions you disagree with would create a workable system for 
basically everyone without incredible investment in advance.

> I need to complain about the ongoing Windows vs Microsoft
> discussions. When in Rome, do as the Romans do. IOW if you migrate from
> Windows to Linux, please don't force native Windows users like me, to
> migrate to Windows habits. I dislike that by default way too much
> _wrong_ user-friendliness tends to Windows, iOS and Co restrictions.

Why would you complain about an easier copy system if you say you are 
not using that at all?

Why would you *ever* select text if you are not going to copy it?

So how would it impede with your workflow? You have not shown anything 
that it would hamper with.

You say you don't use copy & paste, then why would a change to the copy 
and paste system be relevant to you?

The only time I have mentioned... well whatever. I said something that 
equally didn't work in Windows.

> In short, if you need to copy and paste much when using the terminal,
> get used to another workflow.

No, you're not my boss, and you don't decide the workflow of millions of 
other people either.

They want something that works for them. If they can't get it, they 
might stay away. If you only care about your needs, fine. I am just 
telling you that it does cause people to stay away. If that is your 
desire, fine. It is still the way it is.

>> Another thing that has to be solved is running administrator-privilege
>> applications in the desktop. Having to use "kdesu" or "gksudo" or
>> equivalent is NOT acceptable. It has to be an automatic thing based on
>> standard tools. We MUST do away with the corruption that results from
>> forgetting to use these tools. Programs must also be written to allow
>> elevation while running, but that's a different discussion.
> 
> https://lists.archlinux.org/pipermail/arch-general/2017-July/043948.html

Really. That message was 6 days ago. I might be running behind things.

(Kate apparently already has the feature I mentioned).

> It is not nearly that destructive as risky unmounting is. An app might
> currently not keep open a file via a needed mount point, so e.g. green
> drives have time to sleep, but before closing the app, tons of data
> might be written to a file via that mount point.

Then there needs to be a way to force an application to close its 
handles. I am not giving you solutions, just needs.

>> 1. A good, no-tabs notepad.
> 
> What is "good" for? Is e.g. syntax highlighting needed?

A copy and paste notepad doesn't need syntax highlighting.

There needs to be a way to quickly save bits of data.

There is no need for every editor to be a programmer's editor.

>> 2. Ctrl-shift-c no longer used to copy text in terminals.
> 
> Use the right-click instead or learn how to use a terminal without copy
> and paste the desktop way at all.

Why do you try to give me random advice?

If you don't care about this workflow, then stay away from it. Let 
carpenters worry about carpenting, and fishermen worry about fishing.

You don't have to have an opinion on something you don't use.

>> 4. Allow editors and other such applications such as file managers to
>> be elevated in-place.
> 
> This would be a step in the wrong direction. However, you at least
> could run an editor without root privileges and save files with root
> privileges, which does cause the confusion in the posted Arch mailing
> list link above.

That confusion results from users not being used to this being possible.

Hence still inquiring about kdesu and kdesudo.

But what you say here is what I meant, actually.


>> 5. Try to introduce a capabilities-based elevation system in which the
>> user can be informed as to what capabilities have been requested.
> 
> If a user needs a nanny, the user should use a restricted operating
> system. If a user wants freedom, the user needs to learn how to use
> freedom.

It's not the user that gets the freedom, but the applications they run, 
which may not be of their own making. Linux _is_ restricted. All user 
accounts are restricted. That is its security model. Doing away with 
restrictions means having everyone be root.

Your argument is absurd. Users do not want unlimited capabilities for 
every application they run. Certainly not if they could be malware, _and 
they don't know that_.

If the application were to request in advance all the capabilities they 
need, the security manager could display the requested capabilities and 
grant only those. Android does this, why shouldn't Linux.

If you say that Linux doesn't have malware and therefore this is not 
needed, that is equally absurd. Design for best practices and you will 
be prepared for a future in which you do need it.

Therefore a user does not *want* freedom, but rather safety, or at least 
knowing what is or could be going to happen. So your argument falls 
apart.

AppArmor is also based on the premise of applications saying in advance 
what they want, btw.

Those security policies already limit the scope of what applications can 
do, provided it is well designed and always present. Provided you can 
depend on it.

I don't know enough about other security policies to have an opinion on 
that. I am just saying that this is what is needed.

It is no different than being able to control, see and monitor what 
connections are created to the outside world, by means of some firewall 
you can manage. It is power, and therefore freedom. You want to be free, 
you don't want every freaking application to be free?

The freedom to control applications is the freedom for the user.

The unlimited freedom of every application is tyranny.

Applications are your servants, not the other way around.

Choose to be in control of your computer please, and allow others to do 
the same.



>> 7. Get rid of gksudo and kdesudo as separate applications.
> 
> Why don't you use pkexec or set up your environment in any other way,
> if you dislike gksudo and kdesudo as separate applications?

It is not my job to decide on security policies.

> If somebody does use an Ubuntu DE flavour with it's defaults, the user
> don't need to care what is used at all.

That is nonsense. Kdesudo/gksudo issues constantly pop up. If you know 
stuff I don't know, please enlighten.

> Yes, ask users, but remember to ask native Linux users, don't care too
> much about those who migrate from other operating systems.

90% of all desktop users would fall into the category you are not part 
of, Ralf. My advice is for the greatest user experience for the largest 
number of people, not the select group you are part of, that wouldn't 
even be hurt by these advancements ;-).




More information about the Ubuntu-devel-discuss mailing list