MX Linux Forum

rasat wrote: Tue Jun 04, 2019 11:31 am
I am still curious to know what does it take to get AntiX to run all DE. Sounds better, as well as more acceptable by many MX users to have "MX powered by AntiX" than "Devuan". There is MX forum and community support. @manyroad can you get Gnome to run in your prototype?

@rasat... Sure, I'll set up a separate snapshot of antiX19 alpha (with Buster) for Gnome. You should see it before Friday.

manyroads wrote: Tue Jun 04, 2019 11:35 am
I will upload an xfce antiX19 alpha snapshot, later this week. It uses Buster; you'll see it works quite well. In the end (my layman's opinion) I think you can always use a flatpak of an app that might not be available in the antiX repos (or use a snap or appimage). I know that eats disk, but it keeps the 1 million line of code systemd corralled.

At lest that's how I understand things.

snap requires systemd.

asqwerth wrote: Tue Jun 04, 2019 11:02 am That co-existence won't be possible anymore in Buster, because the shim package is no longer maintained.

The shim has been un-maintained for the entire lifetime of the Debian stretch release (with outstanding bugs) but it has been removed completely in Debian buster.

asqwerth wrote: Tue Jun 04, 2019 11:02 am If you go full Debian, you will be on systemd.

^ This is not true.

The Debian init metapackage now has three possible dependencies: systemd, sysvinit & runit-init, buster can be run with any of those packages serving as PID1.

https://packages.debian.org/buster/init

And Debian now has a dedicated init diversity mailing list that is devoted to keeping the non-systemd options viable:

http://www.chiark.greenend.org.uk/mailm ... -diversity

rasat wrote: Tue Jun 04, 2019 11:31 am Devuan does the job but beowulf packages will be slightly behind buster.

^ This is not true.

Devuan beowulf draws all of the packages from Debian buster via their so-called merged repositories, the versions are identical.

The release of their stable version of beowulf may be delayed compared to Debian buster though.

@OP: if you want XFCE without systemd then install either Devuan (which has XFCE as the default desktop) or antiX with the task-xfce-desktop package and then add the MX tools afterwards.

I'm pretty sure the MX tools won't have systemd as a dependency.

And if the massive codebase of systemd is a problem for you then why are you OK running the Linux kernel? That's *much* bigger...

GuiGuy wrote: Tue Jun 04, 2019 11:22 am My other wish is that MX will forget about the 9% of users who want systemd (they could use straight debian instead) and just make MX sysviinit only.

Being forced to alienate a group of users is not to be taken lightly nor would it be easy to forget. What kind of person would force us to make such a choice?

Thanks for the clarification and the precision, HOAS.

This is however from the view point of an ordinary non-tinkerer MX user or someone who just installs Debian and simply uses it out of the box.

I'm not a technical person, and I am aware (you have mentioned it in a previous post) that knowledgeable people can decide which init they want to run on Debian.

asqwerth wrote: Tue Jun 04, 2019 12:00 pm snap requires systemd.

MX Snapshot doesn't. Both MX ascii and bewulf respin were made by snap.

@Head_on_a_Stick, thanks for the info about beowulf draws from Debian buster merged repositories.

these sorts of threads always crack me up.

but seriously, the problem isn't really systemd vs. sysVinit.

the problem is libpam-systemd vs. ???? well that's the problem. there are a lot of debian applications that depend on libpam-systemd. there is a "compat" package called libpam-elogind-compat that forces a symlink but I'm told by debian maintainers that libpam-systemd != libpam-elogind, so that package (a devuan one I believe) remains in experimental.

can you build a debian buster based system without systemd. yes, absolutely. can you build anything you want with just the debian repositories? the answer to that is no.

rasat wrote: Tue Jun 04, 2019 12:38 pm

asqwerth wrote: Tue Jun 04, 2019 12:00 pm snap requires systemd.

MX Snapshot doesn't. Both MX ascii and bewulf respin were made by snap.

I believe manyroads was referring to snaps the portable/sandboxed file format.

He mentioned appimage and flatpak in the same line.

This is not about MX Snapshot.

asqwerth wrote: Tue Jun 04, 2019 12:42 pm

rasat wrote: Tue Jun 04, 2019 12:38 pm

asqwerth wrote: Tue Jun 04, 2019 12:00 pm snap requires systemd.

MX Snapshot doesn't. Both MX ascii and bewulf respin were made by snap.

I believe manyroads was referring to snaps the portable/sandboxed file format.

He mentioned appimage and flatpak in the same line.

This is not about MX Snapshot.

Yes, sir. I was talking about the 'universal' app delivery tool from Canonical... To quote from that center of all human knowledge (Wikipedia):

Snappy is a software deployment and package management system developed by Canonical for the Linux operating system. The packages, called snaps, and the tool for using them, snapd, work across a range of Linux distributions allowing distro-agnostic upstream software packaging. Snappy was originally designed for Ubuntu Touch. The system is designed to work for internet of things, cloud and desktop computing.

https://www.wikiwand.com/en/Snappy_(package_manager)

dolphin_oracle wrote: Tue Jun 04, 2019 12:38 pm these sorts of threads always crack me up.

but seriously, the problem isn't really systemd vs. sysVinit.

the problem is libpam-systemd vs. ???? well that's the problem. there are a lot of debian applications that depend on libpam-systemd. there is a "compat" package called libpam-elogind-compat that forces a symlink but I'm told by debian maintainers that libpam-systemd != libpam-elogind, so that package (a devuan one I believe) remains in experimental.

can you build a debian buster based system without systemd. yes, absolutely. can you build anything you want with just the debian repositories? the answer to that is no.

Humor not withstanding; hopefully you can see, in this thread, there is a lot of fear, concern, mis-understanding, confusion, even 'grief'.

To my mind these are issues worth time, consideration, and discussion. This type of discussion tends to build a more informed and committed community.

But that just an old guy's opinion...