KDE run Dolphin as root?

[Default User]

Hi, all.

As an experiment, I just installed Debian 10.4 Stable on a spare drive, and installed kde on it.

I have not tried kde in many years, so am not really familiar with it. Perhaps I am overlooking something obvious, but I can not seem to run Dolphin or Konqueror as root. 

Searching online, I was astounded to see many references to this problem, saying that this is not a bug, but a feature - that kde developers are deliberately working to prevent users from using some programs, including Dolphin as root, as a "security measure".

So, can the current version of Dolphin in Debian Stable be run as root (without re-compiling, etc)? 

And, if not, how (and why) would anyone use kde at all?

[Default User]

So . . .  no one here using kde?

Hmmm . . . 

: )

[Paul Johnson]

I think it's less "nobody running KDE" so much as "who logs in to KDE as root?" 

[Marco Möller]

To my knowledge it for years is not possible to run Dolphin in KDE with
root permissions, so also not in Buster. I never tried to use Dolphin
outside of KDE and therefore cannot state on that situation.

IMHO, the nice thing of KDE over GNOME is that in KDE usually I am
offered high control on the appearance and interactive control of my
desktop. GNOME instead appears to copy an Android cellphone, not only
that its appearance remind on it but also that you either like it or you
have to make yourself to accept it as it is. Changes on some of its
desktop elements have been quite restricted when I seriously would have
needed a change. This was what forced me to change. On my quite old
hardware I then went for LXQt until I noticed that running it with kwin
was greatest. Well, anyway running kwin I then tried out KDE and found
that its footprint is not significant higher than the one of LXQt and
that its responsiveness is excellent if staying with KDE Plasma and a
selection of helpful tools but sparing out its akonadi dependent apps.
Actually, both LXQt and KDE fro me run much better than GNOME on my
hardware - and today I am a quite satisfied KDE user.
But concerning Dolphin and the infantilizing amputation to not allow it
to run with root permissions, here KDE completely fails to keep up with
its fame.

Sorry for the bad news. Marco.

[Marco Möller]

I would easily agree with you concerning not to log into a graphical
session as the user root. But Dolphin is also not running with sudo
prepended.
Marco.

[Keith bainbridge]

On 7/6/20 8:30 am, Marco Möller wrote:
>
>
> I would easily agree with you concerning not to log into a graphical
> session as the user root. But Dolphin is also not running with sudo
> prepended.

And here I was thinking that the dolphin issue ran here for several
days, just a few weeks ago.

And yes - not good idea to log into any GUI. My experience is I can't -
I guess by design

--

Keith Bainbridge

keit...@gmail.com

0447 667468

[Kushal Kumaran]

Dolphin is just checking the SUDO_USER environment variable. Just unset
the variable before starting dolphin. Ref:
https://codesearch.debian.net/search?q=Executing+Dolphin+with+sudo+is+not+possible+due+to+unfixable+security+vulnerabilities&literal=1

I have no idea what the unfixable security vulnerabilities are.

> And, if not, how (and why) would anyone use kde at all?

You might be overestimating the number of people who need to do file
management as root with a graphical tool. I, for one, use plasma as my
primary desktop environment, but almost all file management activity is
through emacs (with tramp for root stuff), or just a shell. Until I saw
your post, I had no idea dolphin would refuse to run as root.

--
regards,
kushal

[Default User]

First, to Keith:

Yes, I vaguely remember that thread.  I did briefly look through the list archive but could not find it. 

Perhaps there is a search function for the list archive, but I am unaware of it. 

Second, to Kushal:

I did look at the code you referenced. Interesting. But I am not a programmer. 

I did try to under the SUDO_USER environment variable as you suggested.  Maybe I didn't do it correctly, but it did not resolve the problem. Dolphin refuses to run with elevated privileges.  

Anyway, for now, I can use Midnight Commander, either as sudo or as root, to do file management of root folders and files. But it is somewhat "clunky" to do so.

And just to note: I do a lot of management of files and directories requiring root privileges. 

So I guess I just got spoiled, using the nemo file manager in Cinnamon. Just right click the Cinnamon desktop, select "Open as root", then use nemo with temporarily elevated privileges.  Then close nemo, and I am back to the desktop as a regular user again. Easy.

[Kushal Kumaran]

Running

sudo sh -c 'unset SUDO_USER; KDE_FULL_SESSION=true dolphin'

from a shell gets a dolphin window.

There is some advice at
https://forum.kde.org/viewtopic.php?f=223&t=161021#p425888 that can
arrange things so that you get an action on the right-click context
menu.

> Anyway, for now, I can use Midnight Commander, either as sudo or as root,
> to do file management of root folders and files. But it is somewhat
> "clunky" to do so.
>
> And just to note: I do a lot of management of files and directories
> requiring root privileges.
>
> So I guess I just got spoiled, using the nemo file manager in Cinnamon.
> Just right click the Cinnamon desktop, select "Open as root", then use nemo
> with temporarily elevated privileges. Then close nemo, and I am back to
> the desktop as a regular user again. Easy.

Sounds like you have your needs properly met with cinnamon and nemo, and
they seem to be available in debian. Is there a particular reason you
need to solve this problem with dolphin? I assume you could have just
installed nemo and used it even while using the plasma shell as the
desktop.

--
regards,
kushal

[David Wright]

On Sat 06 Jun 2020 at 18:10:10 (-0700), Kushal Kumaran wrote:
> Default User <hungupo...@gmail.com> writes:
> >

> > As an experiment, I just installed Debian 10.4 Stable on a spare drive, and
> > installed kde on it.
> >
> > I have not tried kde in many years, so am not really familiar with it.
> > Perhaps I am overlooking something obvious, but I can not seem to run
> > Dolphin or Konqueror as root.
> >
> > Searching online, I was astounded to see many references to this problem,
> > saying that this is not a bug, but a feature - that kde developers are
> > deliberately working to prevent users from using some programs, including
> > Dolphin as root, as a "security measure".

> I have no idea what the unfixable security vulnerabilities are.

Perhaps the attack claimed here will answer that:

https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/

> You might be overestimating the number of people who need to do file
> management as root with a graphical tool.

Yes, I've certainly never done that. Even using mc requires some care
in selecting its configuration options.

Cheers,
David.

[Keith bainbridge]

On 7/6/20 12:56 pm, Default User wrote:
>
> So I guess I just got spoiled, using the nemo file manager in Cinnamon.
> Just right click the Cinnamon desktop, select "Open as root", then use
> nemo with temporarily elevated privileges.  Then close nemo, and I am
> back to the desktop as a regular user again. Easy.
>
>

Have you tried nemo (cinnamon's file mgr) in KDE? It'll likely bring in
a bit of gtk stuff, but that shouldn't hurt anything.

[Marco Möller]

On 07.06.20 02:42, Keith bainbridge wrote:
> On 7/6/20 8:30 am, Marco Möller wrote:
>>
>>
>> I would easily agree with you concerning not to log into a graphical
>> session as the user root. But Dolphin is also not running with sudo
>> prepended.
>
>
>
> And here I was thinking that the dolphin issue ran here for several
> days, just a few weeks ago.
>
> And yes - not good idea to log into any GUI. My experience is I can't -
> I guess by design

Yes, design options exist. However, I never tried out if the user root
could be blocked by the graphical session manager only, in the case of
KDE usually sddm is in use. But I know that the login of user root can
be blocked in general: when nowadays installing Debian, then there is
offered to keep the root account deactivated, which is achieved by
simply not assigning it a password but to leave the root's password
empty and then activating the sudo mechanism for the during installation
created normal user. Then the login as user root is disabled in general,
not applying only to GUI login but also to text terminal login. As a
consequence it is always required to log in as a normal user and using
the command sudo would be the way to run commands with root permissions.
The deactivation of the root account could also be achieved later on,
any time, not only during installation of the system, by changing the
password of user root to an empty string. But I am afraid that you then
will have to care yourself to set up sudo properly when still possible
to do so as user root.

Interestingly, although having disabled the root account during
installation and having sudo automatically configured during
installation, it by default appears to still be allowed to run command
"sudo su -", which still lets you run a root terminal once you have been
logged in as the normal user and knowing the user's password needed to
use sudo! So, for repetitive work requiring root permissions it at least
is not necessary to prepend sudo to all root commands again and again -
but this is still not reaching the comfort like running Dolphin with
root permissions would do, and Dolphin also resists to start up when
called from such root xterminal running in the normal user session.

Reminding on the question of the OP:
If in need to handle files with root permissions, I simply use sudo and
CLI commands. Remember the above mentioned comfort option to invoke a
root terminal by command 'sudo su -'. Then, besides on the CLI running
nano, cp, rm and mv, maybe having available mc, using the command chown
should be considered as well. If I am pretty sure (this is of course
important) that it will not do any harm to change the ownership of files
or directories to the group and name of my normal user, then chown is
fast to do and afterwards I can continue to work with Dolphin as my
normal user.

[Andrei POPESCU]

On Du, 07 iun 20, 21:21:07, Marco Möller wrote:
>
> Yes, design options exist. However, I never tried out if the user root could
> be blocked by the graphical session manager only, in the case of KDE usually
> sddm is in use. But I know that the login of user root can be blocked in
> general: when nowadays installing Debian, then there is offered to keep the
> root account deactivated, which is achieved by simply not assigning it a
> password but to leave the root's password empty and then activating the sudo
> mechanism for the during installation created normal user. Then the login as
> user root is disabled in general, not applying only to GUI login but also to
> text terminal login. As a consequence it is always required to log in as a
> normal user and using the command sudo would be the way to run commands with
> root permissions. The deactivation of the root account could also be
> achieved later on, any time, not only during installation of the system, by
> changing the password of user root to an empty string.

Careful, an empty password is not the same as a disabled password (see
'man shadow'). The command 'passwd' will not even accept to change a
password to an empty one.

To lock the password for an account use 'passwd -l'.

> But I am afraid that
> you then will have to care yourself to set up sudo properly when still
> possible to do so as user root.

In Debian's default configuration members of group 'sudo' have sudo
access, so all you need is:

adduser my_user_name sudo

As far as I know the installer does the equivalent of that.

> Interestingly, although having disabled the root account during installation
> and having sudo automatically configured during installation, it by default
> appears to still be allowed to run command "sudo su -", which still lets you
> run a root terminal once you have been logged in as the normal user and
> knowing the user's password needed to use sudo!

Warning, useless use of 'sudo su -' :)

There is no need for that, use 'sudo -i' ;)

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Greg Wooledge]

On Mon, Jun 08, 2020 at 09:07:58AM +0300, Andrei POPESCU wrote:
> In Debian's default configuration members of group 'sudo' have sudo
> access, so all you need is:
>
> adduser my_user_name sudo

(and then log out and back in)

> As far as I know the installer does the equivalent of that.

If you enter an empty root password, yes, I've been told that it does.
If you enter a non-empty root password, then it doesn't.

[Default User]

On Sunday, Jun 7, 2020, at 12:11, Kushal Kumaran <kus...@locationd.net> wrote:
>
>Running
>
> sudo sh -c 'unset SUDO_USER; KDE_FULL_SESSION=true
> dolphin'
>
> from a shell gets a dolphin window.

Thanks, Kushal. That does work. For Dolphin, anyway.

> There is some advice at
> https://forum.kde.org/viewtopic.php?f=223&t=161021#p425888 that
> can arrange things so that you get an action on the right-click context
> menu.

Could not figure out how to get this to work. Whatever.

> Sounds like you have your needs properly met with cinnamon and
> nemo, and they seem to be available in debian. Is there a particular
> reason you need to solve this problem with dolphin? I assume you
> could have just installed nemo and used it even while using the plasma
> shell as the desktop.

Yes, I have been getting along fine with nemo on Cinnamon. Much
better than the crippled nautilus that Gnome makes these days. I was
just looking around, to see if there was anything better. I have heard
people praise dolphin (and kde) lately. And dolphin does seem to be a
little more configurable than nemo.

Nemo does work from within kde:
nemo as user
sudo nemo for elevated privileges.

Since I am the system administrator for my computer, I find myself
having to do a lot of things as root. I can enter the snippet you
provided, to run dolphin with elevated privileges. Or nemo. But it
really does bother me the arrogant attitude of one or more kde
developers: deliberately working to prevent users from deciding for
themselves how to use their own systems, even after considerable user
complaints. And that they apparently promised users they would change
this, over a year ago! Sounds like "tell them whatever they want to
hear, then ignore them until they get too tired to complain any more."


On Jun 7, 2020, at 1:55 PM , Marco Möller wrote:
> For me the task to handle files as root is not frequently coming up. If
> so, then I simply use sudo and CLI commands. Besides on the CLI running
> nano, cp, mv and rm, I figured out that many times using chown helps a
> lot: if needing to manipulate many files as user root, then this is
> usually caused because a bunch of files was received from a backup
> storage directory or files on external storage devices come marked to be
> owned as root, but if I am pretty sure (this is of course important)
> that it will not do any harm to change the owner of those files or
> directories to the group and name of a normal user then chown is fast to
> do and afterwards I can continue to work with Dolphin as a normal user.
>
. . .

>
> Reminding on the question of the OP:
> If in need to handle files with root permissions, I simply use sudo and
> CLI commands. Remember the above mentioned comfort option to invoke a
> root terminal by command 'sudo su -'. Then, besides on the CLI running
> nano, cp, rm and mv, maybe having available mc, using the command chown
> should be considered as well. If I am pretty sure (this is of course
> important) that it will not do any harm to change the ownership of files
> or directories to the group and name of my normal user, then chown is
> fast to do and afterwards I can continue to work with Dolphin as my
> normal user.

Thanks for the explanation.

-------------------------------------

Now, a final note.

When I did my main install, it was a day or two before the release of
Buster 10.0. I immediately upgraded to Unstable. But it is still
originally based upon Stretch. It was set up with both root and user
passwords. And I use good quality, long passwords.
: )

Here's the point:
I can do everything requiring elevated privileges just by using the
user password, and sudo in a terminal as needed. Never need to use the
root password.

Well, when I did an alternate Buster Stable install on a spare drive,
I was surprised (not happily) that when running from that setup,
various programs demand the root password, and will not accept the
user password. So, now I have to remember not one, but two "good"
passwords. And try to determine which one is being asked for. And
re-remember both every time they are changed.

I am guessing this has to do with a change made for Buster. Perhaps
it is a "security thing".

Maybe I am lazy, but I quite prefer to only have to remember and use
one password. And this feels like another step backward to me.

Oh, well . . . I guess it's for my own good. After all, I'm sure
Debian developers know what is best for me, better than I do. After
all, these are the same people who actually thought systemd was a good
idea. And shouted down those who didn't.

Have a nice day!
: )

[Andrei POPESCU]

On Ma, 09 iun 20, 17:55:07, Default User wrote:
>
> Well, when I did an alternate Buster Stable install on a spare drive,
> I was surprised (not happily) that when running from that setup,
> various programs demand the root password, and will not accept the
> user password. So, now I have to remember not one, but two "good"
> passwords. And try to determine which one is being asked for. And
> re-remember both every time they are changed.
>
> I am guessing this has to do with a change made for Buster. Perhaps
> it is a "security thing".
>
> Maybe I am lazy, but I quite prefer to only have to remember and use
> one password. And this feels like another step backward to me.
>
> Oh, well . . . I guess it's for my own good. After all, I'm sure
> Debian developers know what is best for me, better than I do. After
> all, these are the same people who actually thought systemd was a good
> idea. And shouted down those who didn't.

You are making some claims above without providing even one example.

There might be simple explanations and / or solutions for what you
experience...

[Marco Möller]

On 09.06.20 23:55, Default User wrote:
> (...)

> Now, a final note.
>
> When I did my main install, it was a day or two before the release of
> Buster 10.0. I immediately upgraded to Unstable. But it is still
> originally based upon Stretch. It was set up with both root and user
> passwords. And I use good quality, long passwords.
> : )
>
> Here's the point:
> I can do everything requiring elevated privileges just by using the
> user password, and sudo in a terminal as needed. Never need to use the
> root password.
>
> Well, when I did an alternate Buster Stable install on a spare drive,
> I was surprised (not happily) that when running from that setup,
> various programs demand the root password, and will not accept the
> user password. So, now I have to remember not one, but two "good"
> passwords. And try to determine which one is being asked for. And
> re-remember both every time they are changed.
>
> I am guessing this has to do with a change made for Buster. Perhaps
> it is a "security thing".

Others might correct me, I am still learning and might be confused about
things, but this is how I understand the situation be now:
In the past I thought that upgrading from release to release would be
all what someone good desire, especially when the upgrade process is
well designed and not breaking things. The Debian team is really doing
an excellent job to care for the release upgrade not being likely to
break things.
I then noticed that a release upgrade brings in more than simply
upgrading many packages and renewing version numbers, the latter being
what the in-release upgrades already do. Worth noting is that in a new
release additionally old concepts are deprecated or substituted, and new
concepts become introduced! Besides you having mentioned systemd already
here giving you another example: remember the (in 2015 ?) announced
changes in the use of the root directory structure concerning the
philosophy on which data is supposed to land in which directory
("filesystem hierarchy standard"). For now there are introduced symbolic
links from the old directory locations to the new locations, so that
software will not break right away if still not updated to respect the
new concept. If you would for long time roll from release to release,
then I imagine that conceptual changes like this will not become visible
in your system, and some time in the future the backward compatibility
to old concepts might need to be cut. You coming from a Debian/stretch
installation and having rolled upgrades via Debian/buster to
Debian/bullseye might still not find these changes cleanly applied.
Therefore, in order to keep up also with the conceptional changes, it is
worth to consider a fresh installation as the alternative to a release
upgrade. This is why many of us maintain detailed notes on package
installations and system configurations, in order to be able to
re-install quickly and thus also being well prepared for a new release
installation instead of a rolling upgrade.
(You are more then welcome to correct me if I misunderstood things ;-) !)
Best wishes, Marco.

[Default User]

On Jun 10, 2020, 2:36 AM Andrei POPESCU, <andreim...@gmail.com> wrote:
> You are making some claims above without providing even one example.
>

Well, . . . yes.

>
>There might be simple explanations and / or solutions for what you
>experience...
>

Perhaps. Problems can seem so simple, once they are solved.


On Jun 10, 2020, 4:12 AM, Marco Möller

Marco, no correction is needed. I agree with you. I run Unstable for
two main reasons:
1) to get relatively up to date packages.
2) to avoid reinstalling.
The trade-off? Some instability, at least. And just plain
"messiness". (Right now, I have 14 packages that can not, or should
not, be upgraded - until fixes are made by the developers.)
I do resent having to choose between old but stable, and new but unstable.

Unfortunately, as you have correctly observed, one will eventually
have to re-install. For me, it is not a lot of fun. In a better
world, things would "just work", and continue to "just work". But
this is not a better world. So, we just do the best we can.

[Gary L. Roach]

Hi all,

I'M late getting into this but after reading through all of the
missives, I have a few comments.

I assume that with respect to the original message that it should be
obvious that the root user problem stems from the underlying Debian OS.
Someone in the Debian hierarchy decided that root Dolphin was too much
of a security risk. So the problem has propagated to at least a half
dozen other distros (Ubuntu,Kubuntu, Mint) to name a couple.

This drives me nuts. You can talk about not using root with GUI's but I
would like to see how long that lasts if you had my work flow. I am in
and out of different user files constantly. Dolphin was my go to package
for manipulating files until this latest "bright idea". Now it is near
useless. You could not use Dolphin as root before unless you went into
properties window for the Dolphin, picked the Application tab and then
selected the Advanced Options button. You could then set the "Run as a
different user" to root. After that selecting Dolphin popped a window to
enter a password for root use or blank for normal use. This was not a
process that a normal user ( what ever that may be ) would probably do.
I am all for security until it starts to get in the way of usability. I
have found no way around this mess.

As for as upgrades are concerned, I usually upgrade to say Buster and
then go into my sources.list and change Buster - or what ever - to
stable. This way when the upgrade comes down the line my system just
slips right in; assuming that you upgrade you system a couple of times a
week.

A word of warning. Qt4 has been dropped from Bullseye completely. I just
upgraded to Bullseye and all of a sudden some of my software wouldn't
compile any more. I just got finished reinstalling Buster to get around
the problem and lost a chunk of data in the process.

For Pete Sake Debian let you users have some say over the use of root.
The fact that Ubuntu over pampers its users, in this area, is one reason
I don't like the distro.

Gary R.

[Andrei POPESCU]

On Lu, 15 iun 20, 12:47:59, Gary L. Roach wrote:
>
> I assume that with respect to the original message that it should be obvious
> that the root user problem stems from the underlying Debian OS. Someone in
> the Debian hierarchy decided that root Dolphin was too much of a security
> risk. So the problem has propagated to at least a half dozen other distros
> (Ubuntu,Kubuntu, Mint) to name a couple.

Do you have any source for this claim?

Debian tends to do little if any customization to such big software
packages like KDE (there simply aren't enough resources for it), with
the obvious exception of integrating it with the rest of the system.

[to...@tuxteam.de]

No, no. The secret Debian Hierarchy is out to get us! Run!

;-)

Now more seriously, Gary: I think the default policy to disable root
for such huge GUI programs is sensible: there is no way in hell one
could make them secure.

As a default, it seems to make sense.

OTOH it is *your* computer, so there should be a way to override that
default behaviour. And it seems there is. All is well?

Software shouldn't *force* you to do something.

Cheers
-- t

[Keith bainbridge]

Here, hear i say. It is my computer.


Now, i just tested both caja and nemo and both run as sudo and su -c.
caja could not connect to ibus. (Default file managers for Mate & Cinnamon)

I am sure I have had other file managers run as sudo.


I reckon the problem is dolphin specific. Having said that, I can't
check in another environment, other than debian, mint - oh I could
download and run an ISO in vbox. Am I that desperate to prove the point
- not yet.

[to...@tuxteam.de]

On Tue, Jun 16, 2020 at 08:33:29AM +1000, Keith bainbridge wrote:

[...]

> Here, hear i say. It is my computer.

You own it, you do the work. Complaining ain't working ;-D

> Now, i just tested both caja and nemo and both run as sudo and su
> -c. caja could not connect to ibus. (Default file managers for Mate
> & Cinnamon)

> I am sure I have had other file managers run as sudo.

This might just be because the others don't care as much about
your security. Who knows.

> I reckon the problem is dolphin specific. Having said that, I can't
> check in another environment, other than debian, mint - oh I could
> download and run an ISO in vbox. Am I that desperate to prove the
> point - not yet.

As long as there is a way to change the defaults all seems wellm no?

Cheers
-- t

[to...@tuxteam.de]

On Tue, Jun 16, 2020 at 09:21:24AM +0200, Marco Möller wrote:
> On 15.06.20 21:47, Gary L. Roach wrote:
> >Someone in the Debian hierarchy decided that root Dolphin was too
> >much of a security risk. So the problem has propagated to at least
> >a half dozen other distros (Ubuntu,Kubuntu, Mint) to name a
> >couple.
>

> To my knowledge, this is not true!

You're too polite ;-D

To my perception, this is borderline... conspiracy theory.

Cheers
-- t

[Marco Möller]

On 15.06.20 21:47, Gary L. Roach wrote:

> Someone in the Debian hierarchy decided that root Dolphin was too much
> of a security risk. So the problem has propagated to at least a half
> dozen other distros (Ubuntu,Kubuntu, Mint) to name a couple.

To my knowledge, this is not true!

It is the Dolphin upstream team which implements the blocking mechanism.
In some of the many threads on this issue flooding the internet there
are given instructions how to compile your personal version of Dolphin
after having changed (removed) the respective code in the Dolphin source
code, in order to finally make it run as user root again.

Best regards, Marco.

[Gary L. Roach]

Hi all,

Andrei, after thinking about your question for a while I realized that I
use KDE5 for just about everything. I'm even using Kubuntu for my Ubuntu
installation. I really don't care for Ubuntu's Gnome desktop. Personal
preference. That may have to change. I just loaded up the latest Kubuntu
version (20.04) and now, not only is Dolphin completely locked out as a 
root user, they have now locked out everything. I can't even read a root
directory. Everything is grayed out. So to hell with Dolphin. I loaded
in Nemo and took the memory hit from all of the Gnome support packages.
With two one terabyte drives and 16 GB of ram. who cares. Apologies for
slandering Debian but if they want to keep using KDE as their desktop
they had better bring the hammer down on someone in the KDE hierarchy .
I now have to start communications with the Elmerfem people who have
religated their GUI Qt4 problems from a bug to an inhancement. I have
gotten warnings from several different sources that Debian is dropping
Qt4 because of maintenance problems up line. One of these days I may get
a working physics modeling setup.

Regards

Gary R.

[Gary L. Roach]

Miacopa

I think I was venting. I am so frustrated with this whole Dolphin mess that I may have gone overboard. Dolphin is probably the most used package on my systems. I do a lot of compiling from source code and complicated computer modeling and the frustration this has caused is very very unfortunate. So who is responsible for messing around with my head. My last post did include an apology  to anyone I maligned.

Gary R

[didier...@gmail.com]

(Apologies if this link have been given before)

You will find a thread there on a KDE forum detailing why running Dolphin as root is discouraged and how to bypass this measure:
https://forum.kde.org/viewtopic.php?t=141836

[didier...@gmail.com]

Le mercredi 17 juin 2020 01:40:05 UTC+2, Gary L. Roach a écrit :
[...]

> I now have to start communications with the Elmerfem people who have
> religated their GUI Qt4 problems from a bug to an inhancement. I have
> gotten warnings from several different sources that Debian is dropping
> Qt4 because of maintenance problems up line. One of these days I may get
> a working physics modeling setup.
>
> Regards
>
> Gary R.

Debian is droping Qt4:
https://wiki.debian.org/Qt4Removal

QT4 is not facing maintenance problems upstream, it is unsupported upstream since 2015:
https://en.wikipedia.org/wiki/Qt_version_history#Qt_4

[to...@tuxteam.de]

On Tue, Jun 16, 2020 at 04:51:39PM -0700, Gary L. Roach wrote:

[...]

> Miacopa

All is well, and sorry if my tone was... rough.

> I think I was venting. I am so frustrated with this whole Dolphin

> mess that I may have gone overboard [...]

I feel your pain. Not from KDE land, but I think it's a basic problem.

We are being torn apart by the attempt to democratize free software
(which is something we *must* attempt!).

Making things user friendly (something we *gotta* do) means sometimes
taking decisions for the user. Where's the limit? Where's too much
(authoritarian software)? Where's too litle (RTFM software)? You'll
be wrong most of the time for some users, and some of the time for
most users.

As an example: yesterday, I got a laptop from a customer. Doesn't
boot. Thinkpad something something, with Ubuntu on it. Now I think
it's so awesome that a psychotherapist runs Ubuntu for his business.
He gets a special price.

What was the problem? Basically a b0rked kernel upgrade[1], where
the corresponding Intel CPU firmware was missing. The two youngest
kernels in the Grub menu didn't boot, the third oldest did (though
I found about that in a somewhat roundabout way: it seems at least
80% of our profession consists of barking up the wrong tree, but
I disgress).

Back to our topic: this customer has auto-upgrade running. While
his box was up and running, it did two (!) kernel updates without
the owner even noticing[2]. This is an incredible luxury, but in
this case the effect was that after the next shutdown the box didn't
boot, with no obvious reason for him.

What is "the right" degree of automation? Finding an adequate answer
to this will be our job for the next ~20 years. I don't expect a
scalar number as answer :-)

Cheers

[1] https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1882890
[2] "But there was this notification saying the box needs a reboot, blah,
blah" you'll say. Yeah, right.

-- tomás

[Andrei POPESCU]

On Mi, 17 iun 20, 10:55:55, to...@tuxteam.de wrote:
>
> Making things user friendly (something we *gotta* do) means sometimes
> taking decisions for the user. Where's the limit? Where's too much
> (authoritarian software)? Where's too litle (RTFM software)? You'll
> be wrong most of the time for some users, and some of the time for
> most users.

In my opinion Chrome OS (and I assume Chromium OS as well) gets many
things right, Debian could learn a lot from it.

[to...@tuxteam.de]

On Fri, Jun 19, 2020 at 05:54:38AM +0300, Andrei POPESCU wrote:
> On Mi, 17 iun 20, 10:55:55, to...@tuxteam.de wrote:
> >
> > Making things user friendly (something we *gotta* do) means sometimes
> > taking decisions for the user. Where's the limit? Where's too much
> > (authoritarian software)? Where's too litle (RTFM software)? You'll
> > be wrong most of the time for some users, and some of the time for
> > most users.
>
> In my opinion Chrome OS (and I assume Chromium OS as well) gets many
> things right, Debian could learn a lot from it.

That's the point. In Sally's opinion it's Mac. In Betty's, it's Windows
(but not after '95). In Sue's, OTOH...

(BTW. for all I've seen of Chrome OS, I'd either run away screaming or
scrub it from the computer, depending on my momentary mood).

How to cater to all of those? And, more importantly: how to enable (or
better: seduce) all of those to tinker away, if they wish to do so?

After all, that last point is the "mission statement" of free software.
There was a meme around one of the first free smartphones, the OpenMoko:

"WARRANTY VOID WHEN NOT OPENED" [1] [2]

I think in these days, where the attacks on freedom come sometimes in
the guise of convenience rather than constraint (in some privileged
parts of the world, at least!), this point becomes ever more important.

Cheers

[1] https://www.vanille.de/blog/openmoko-10-years-after-mickeys-story/
[2] http://fidzu.com/fidzu/openmoko

-- tomás

[Andrei POPESCU]

On Vi, 19 iun 20, 09:58:40, to...@tuxteam.de wrote:
> On Fri, Jun 19, 2020 at 05:54:38AM +0300, Andrei POPESCU wrote:
> > On Mi, 17 iun 20, 10:55:55, to...@tuxteam.de wrote:
> > >
> > > Making things user friendly (something we *gotta* do) means sometimes
> > > taking decisions for the user. Where's the limit? Where's too much
> > > (authoritarian software)? Where's too litle (RTFM software)? You'll
> > > be wrong most of the time for some users, and some of the time for
> > > most users.
> >
> > In my opinion Chrome OS (and I assume Chromium OS as well) gets many
> > things right, Debian could learn a lot from it.
>
> That's the point. In Sally's opinion it's Mac. In Betty's, it's Windows
> (but not after '95). In Sue's, OTOH...
>
> (BTW. for all I've seen of Chrome OS, I'd either run away screaming or
> scrub it from the computer, depending on my momentary mood).

Chrome OS itself is definitely not something for the typical debian-user
subscriber, as it is "just enough OS to run Chrome" ;)

What would be interesting to at least consider for Debian (in my, not so
humble, opinion):


By default it is using secured boot (signed kernel, etc.) with the user
data partition fully encrypted and no root access whatsoever. It can be
switched to "developer mode" with full root access by a special
(documented) boot procedure, which involves full erasure of all user
data (for privacy reasons).


Robust and user friendly auto-update mechanism. There is just one
notification informing you to reboot to upgrade. On the next reboot you
are running the upgrade, not additional waiting time involved.

As far as I know it uses two "boot" (system?) partitions. The upgrade is
written to the "other" partition and marked to be booted from next time.
The "current" partition is kept as backup with an automatic fall-back
mechanism (never seen it trigger as far as I could tell).

During the lifetime of my Acer Chromebook R13 I've had countless
updates, including a "firmware" upgrade (u-boot?) and a filesystem
change (to ext4 I think, don't recall what it had before), all without a
glitch. These did involve some (one?) additional confirmation and the
filesystem change did take a while (unavoidable).

For a while I was also running the "beta" channel, similar to Debian's
testing, no issues with the upgrades.


Too many apps installed? Some things appear to now work properly? Are
you selling / giving away the Chromebook? No problem. Just use
"Powerwash" (something like a "factory reset") to restore the OS to its
basic state (with all updates applied) and erase all user data.

Sounds quite similar to what was recently discussed here on the list.


As I wrote above, it's not for the typical debian-user subscriber. It is
however a really good option for the kind of users that spend 95% of the
time in a browser. The other 5% are most likely covered by Chrome and
Android Apps, if the user is willing to ignore / doesn't care about the
privacy issues.

Building something similar with just Debian is mostly doable, though by
far not easy.