MX Beowulf (Devuan) Respin

[figueroa]

I actually am using them the other way around, where xfce is subservient to OB. The footprint is about 100MB smaller with OB on top and xfce on the bottom (so to speak).

Have you ever done that before? It sounds like a terrible idea. I'll be interested in the rest of the story, and a how-to if your journey is successful.

[dreamer]

@dreamer https://sourceforge.net/projects/refracta/files/tools/

Nice!
I have this unpleasant feeling that Linux will never get better than it is right now. The future is systemd, GTK3/4, Gnome, Flatpak/Snap and Wayland. We can call it "Linux 10". Everything else is destined to die or keep fighting an uphill battle. I wish I could do something but I can't so I'm going to bed.

[figueroa]

I have this unpleasant feeling that Linux will never get better than it is right now.

No, I don't think so. Yes, some things in the world are going to hell in a hand basket, but I don't think that's the case with Linux and the open source community at large. The reason projects like MX and antiX are succeeding is the optimism of the developers and the users. That said, have a good night. Sweet dreams.

[figueroa]

I actually am using them the other way around, where xfce is subservient to OB. The footprint is about 100MB smaller with OB on top and xfce on the bottom (so to speak).

It dawns on me that Openbox and LXDE go together by default with LXDE providing the tools that Openbox does not provide. That's my default desktop. Since you WANT Openbox, go all the way in the water is nice. I don't know how much you can get out of the allowed image, but a screenshot is provided, for grins.

screenshot.png

[manyroads]

I actually am using them the other way around, where xfce is subservient to OB. The footprint is about 100MB smaller with OB on top and xfce on the bottom (so to speak).

It dawns on me that Openbox and LXDE go together by default with LXDE providing the tools that Openbox does not provide. That's my default desktop. Since you WANT Openbox, go all the way in the water is nice. I don't know how much you can get out of the allowed image, but a screenshot is provided, for grins.
screenshot.png

I have done that... but with LXQt. My problem with LX is that when I use it, I always want to pair it with kwn because of all the neat tools and eye-candy. I'll play with that later.

I had been building an old laptop install for my 6 year old grandson. He's using xfce on MX these days. I am thinking of moving him and my podcasting machine to OB on antiX19 though, to save cycles.

Ooo-oo I just noticed you use a Lion, the witch, and the wardrobe image on your DE. Great Books. Spectacular books... did I mention I really like those books. :lipsrsealed:

[rasat]

For a Devuan based system the Refracta tools are probably a better fit. The thing to keep in mind is that current MX tools and probably current Refracta tools are built for Stretch. Next version of Debian/Devuan is still baking and when it's done tools and repos will be updated. It's probably not a good idea to enable Stretch repos in Buster/Beowulf.

One of the know issues with beowulf/buster repo running stretch MX tools, icon launch may not work. Example this respin, launched with command line:
su-to-root -X -c mx-snapshot (didn't work with icon).

[Stevo]

Yup, those are going to have to switch to pkexec for buster, apparently.

[skidoo]

su-to-root is provided by debian "menu" package.
As it stands, debian's for-buster version of the package will continue to provide su-to-root
ref: https://packages.debian.org/buster/amd64/menu/filelist

The su-to-root script just provides a passthru
ref: https://sources.debian.org/src/menu/2.1 ... -root/#L83
It attempts to pass to: gksu, gksudo, kdesu, kdesudo, kde4su, ktsuss, sux ~~ in that order, based on availability.
All of these have been weeded from the debian buster repository, but they haven't gotten 'round to removing the su-to-root script. FWIW, there's a several-year-old bug ticket for menu package, requesting su-to-root: use ssh-askpass as another frontend

The antiX 19 repository will (already does) continue to provide gksu package.
Any tool which currently calls "su-to-root" should be changed, away from using su-to-root.
In the meantime, when su-to-root passes to gksu, you should expect the (essentially hardcoded) result will be:
sudo -H -S -u root -- commandstring

To be clear: Regardless whether called via su-to-root or called directly, you should expect that future versions of antiX gksu will:
· behave identically, regardless whether invoked as "gksu", or via "gksudo" alias
· unconditionally utilize sudo as the backend
· unconditionally (irrespecitve of sudoers timestamp_timeout) require password entry upon each invocation
· unconditionally request authorization as username 'root', ignoring any -u commandline option passed
· unconditionally abort if called by a process which already bears elevated privileges
· reject any commandstring containing special characters ` · \ · $ · ( · [ · { · ^ · > · < · % · * · !
· unconditionally attempt to preserve $HOME environment variable.
Whether or not $HOME is, in fact, preserved (as well as any other envvars) is governed by the policy directive stated in /etc/sudoers

Here's another, related, forthcoming change:

buster Release Notes draft
page: Issues to be aware of for buster
https://www.debian.org/releases/buster/ ... -variables

5.3.2. Semantics for using environment variables for su changed

su has changed semantics in buster and no longer preserves the user environment variables DISPLAY and XAUTHORITY. If you need to run graphical applications with su, you will have to explicitly set them to allow access to your display. See bug #905409 for an extensive discussion.

bolding preserved from the original

[GuiGuy]

My verdict on this respin:-
It is not fully usable yet; we should wait until Devuan Beowulf is released.

[manyroads]

As for su-to-root... I find the following works fine on MX and antiX in Thunar:

Code: Select all

pkexec thunar %f