systemd is being forced on Debian Jessie users is some sneaky ways.

I have 2 versions of antiX-14R-alpha4, one with sysvinit and the other with upstart. Both run fine live and installed.

BUT - as soon as user tries to install some app such as hplip (for printer) or brasero for cd/dvd burning, systemd is a dpends and you are forced to switch to systemd init system! WTF!
There doesn't seem to be any way to avoid this anymore. A while ago, installing systemd-shim would work, but no more. It simply causes dependency issues so you cannot install the package you want eg brasero or hplip.

So even though we can ship antiX-14R with sysvinit (or upstart), user may end up getting systemd anyway if an app the user installs depends on systemd.

What to do?

Hello anti,

as for brasero, the developers have chosen to use gvfs, which in turn pulls in systemd. It's getting tighter for those who want to stay with sysvinit, that's true. At the moment the only way is to switch applications (I go straight down to CLI packages whenever possible, because GNOME-related things will eventually pull in systemd, and gtk3 anyway), hoping that certain packages will not depend on libpam-systemd etc.

So, something like brasero -> xfburn, printing -> lpr

No idea how long this will work :/

Hello machinebacon,

Yes, as individual users there are still ways to avoid systemd. I'm running antiX-sid with sysvinit with the only issue I have is with hplip. Everytime I want to use the printer, I have to install hplip (for some reason it doesn't work without it), and this brings in all the systemd crap. So I do my printing/scanning, then remove hplip and depends. What a pain!

Can you imagine the commnets? I installed antiX to my desktop, all was running fine and since i use hp printer i installed hplip. Rebooted to using a new systemd init! WTF! antiX sucks!

__{{emoticon}}__

Is it really *necessary* to install hplip? I mean, usually there should be at least one more way to do a thing __{{emoticon}}__

lprng - lpr/lpd printer spooling system

Of course this is only ghostscript/postscript, but should even print PDFs with xpdf (yey! no gtk!)

My friend GekkoP has written a little wrapper for direct printing, I haven't tested it (because I don't even have a printer anymore) ->
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/linuxbbq/toolbox/blob/master/printfile"
linktext was:"https://github.com/linuxbbq/toolbox/blo ... /printfile"
====================================

anti wrote:I have 2 versions of antiX-14R-alpha4, one with sysvinit and the other with upstart. Both run fine live and installed.
...
So even though we can ship antiX-14R with sysvinit (or upstart), user may end up getting systemd anyway if an app the user installs depends on systemd.

Please with systemd!

Where can I download antiX-14R-alpha4 with systemd?
Anti, because no one is coming over.
Let's please antiX live! __{{emoticon}}__

Seems like the folks at Mepis got around thiis type of situation by rolling their own ie: Community Repository. Would this be a possibility here?

I would not sweat it myself. Eventually one will have to roll with the majority.
You may not like it but, Oh Well.

I have little to do with Mepis Forums anymore. Jerry gave me warning. So I decided to stay away.

anticapitalista wrote: user may end up getting systemd anyway if an app the user installs depends on systemd.
. . .
Can you imagine the commnets? I installed antiX to my desktop, all was running fine and since i use hp printer i installed hplip.
Rebooted to using a new systemd init! WTF! antiX sucks!

When user installs kdiff3, or kate, etc., and discovers that doing so brings a boatload of KDElibs, user doesn't (or realistically shouldn't)
point the finger of blame at antiX, right? I would regard"inevitably winding up with systemd, post-install, due to user-initiated package upgrades" in the same light.


Sourceforge download stats for the most recent release for antix"base" version, v13.1, compared to its"full" counterpart
indicates a 20 to 98 ratio...

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://sourceforge.net/projects/antix-linux/files/Final/antiX-13.1/"
linktext was:"http://sourceforge.net/projects/antix-l ... ntiX-13.1/"
====================================

...but, in recent months, download volume suggests that"full version" users' needs are being fulfilled by MX-14.

"Base version" with updated antix-live initramfs + newer kernel + vmlinuz, based on Wheezy this time 'round
(if necessary, to avoid systemd until the Debian devs"come to their senses, and realize their mistake")
~~ that prospect would suit me perfectly. I don't know where the interest in"rolling release" I reacently read stems from.

I may be guilty of skewing the 'base' dowload figures, as I have reverted some 'full' machines just lately. __{{emoticon}}__ __{{emoticon}}__

afab4 wrote:Seems like the folks at Mepis got around thiis type of situation by rolling their own ie: Community Repository. Would this be a possibility here?

The problem is that in the future it seems that the list of packages with built-in depends for systemd is going to grow and it would be too much to keep track off and then build for our own repos.

skidoo wrote:

anticapitalista wrote: user may end up getting systemd anyway if an app the user installs depends on systemd.
. . .
Can you imagine the commnets? I installed antiX to my desktop, all was running fine and since i use hp printer i installed hplip.
Rebooted to using a new systemd init! WTF! antiX sucks!

When user installs kdiff3, or kate, etc., and discovers that doing so brings a boatload of KDElibs, user doesn't (or realistically shouldn't)
point the finger of blame at antiX, right? I would regard"inevitably winding up with systemd, post-install, due to user-initiated package upgrades" in the same light.


Sourceforge download stats for the most recent release for antix"base" version, v13.1, compared to its"full" counterpart
indicates a 20 to 98 ratio...

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://sourceforge.net/projects/antix-linux/files/Final/antiX-13.1/"
linktext was:"http://sourceforge.net/projects/antix-l ... ntiX-13.1/"
====================================

...but, in recent months, download volume suggests that"full version" users' needs are being fulfilled by MX-14.

"Base version" with updated antix-live initramfs + newer kernel + vmlinuz, based on Wheezy this time 'round
(if necessary, to avoid systemd until the Debian devs"come to their senses, and realize their mistake")
~~ that prospect would suit me perfectly. I don't know where the interest in"rolling release" I reacently read stems from.

Fair enough when installing from kde. But it is becoming increasingly difficult to install basic apps that users may need without systemd getting dragged in. Some examples, gimp, cups, libav-tools.

Trigger-heavy anti shooting innocent packages __{{emoticon}}__ gimp (only suggests gvfs) and libav-tools are not yet on systemd (at least not in Sid), but that's really just a matter of time __{{emoticon}}__

machinebacon - yeah, true about gimp. But, it depends on dbus and dbus brings in libsystemd*

That's nothing serious, because the boot process still fully relies on sysvinit even when you have libsystemd* crap installed. If the question in 'init system', then sysvinit plus libsystemd* crap is not a deadly problem (yet).

If we see it from the point of 'libsystemd = pollution' you are absolutely right, but then we would actually have nothing left to install __{{emoticon}}__ Check this:

apt-cache rdepends libdbus*

I'm using dbus (and libsystemd) in combo with sysvinit on all of my computers and this combination is really OK (so far).

Isn't it good enough if you can run sysvinit while systemd amd libsystemd are installed but not in use?

Of course if they stop maintaining sysvinit and stop incorporating new stuff it will soon become impossible to keep it.
If Debian can be persuaded to keep it viable/updated isn't that enough?