MX Linux Forum

Posted: **Fri Jun 29, 2018 3:47 am**

I ran across a post by someone on this forum who had issues with their MX install, which the user was able to correct by switching to systemd mode during boot. I don't know anything at all about systemd, but it made me curious what it is, how it's implemented, why it's implemented, and to understand the apparently ongoing controversy about it. Well, I could find quite a bit of information on systemd, but couldn't find any logical reasons why systemd should be eliminated in lieu of something else?

https://wiki.debian.org/systemd

https://www.infoworld.com/article/28324 ... users.html

https://www.tecmint.com/systemd-replaces-init-in-linux/

https://www.freedesktop.org/wiki/Software/systemd/

https://en.wikipedia.org/wiki/Systemd

It's interesting (to me anyway) to read everything in these links because instead of being able to determine why systemd wouldn't be used by default for MX Linux installations, seeking some great enlightenment about this subject, quite the opposite happened. It's the default for Debian on which MX Linux is based. So now I'm wondering more than before, if running systemd by default aids in correcting potential problems, then why wouldn't systemd be used by default for MX Linux as well? That's the question that prompted this post, directed at any MX Linux developers who might be spending time here. Is it even possible to explain why systemd is not used by default, or is this strictly a matter of choice?
This post was written to promote professional / technical discussion (and to satisfy my curiosity).
Cheers.

Posted: **Fri Jun 29, 2018 4:10 am**

You forgot the MX Wiki.

Posted: **Fri Jun 29, 2018 4:26 am**

Whoops, sorry, I didn't realize that the MX Wiki had a dedicated section for systemd. My bad ...

Posted: **Fri Jun 29, 2018 5:17 am**

We set that out at the front (Section 1.7 "Our positions") of the Users Manual as well.

Posted: **Fri Jun 29, 2018 5:42 am**

From the Wiki:

To be fair, systemd is good enough for most users and it's actively maintained which is no longer the case with sysvinit. OTOH, sysvinit has had a *long* time to weed out the bugs so one wouldn't expect it to need a lot of maintenance.

That does make me wonder though, at which point doesn't an obsolescence factor come into play? If sysvinit has no active support, does it not stand to reason that at some point, with future advancements in software as well as hardware, any system that uses sysvinit will become more prone to breakage and/or system crashes? Kind of like thinking about FAT versus FAT32 versus NTFS. Certainly at least (for sake of discussion) 99% of all Windoze users in todays world have the NTFS file system as their default, while perhaps another 1% might still be using software such as obsolete Windows98 or WindowsME which could also run with FAT32. But the FAT file system itself has become so obsolete that nobody would be using that anymore, unless they're using Windows 3.11 or the original Windows95 release.

Isn't there a risk that at some point, without active development, sysvinit will follow the same path as the FAT file system? And if that happens, would it not be much more difficult to then play catch-up with various alternatives to sysvinit for everything that's newer, actively developed & maintained? I understand that syvinit is not a file system, it's just the only thing that I could think of in order to make my comparison point.

Posted: **Fri Jun 29, 2018 6:37 am**

We'll cross that bridge when we come to it--but note in the meantime that a user can boot into systemd on MX already, though there are residual problems such as we note in the Wiki article.

BTW: Jesse Smith (from DistroWatch) is updating sysvinit, see his contributions here

Posted: **Fri Jun 29, 2018 10:05 am**

...And if that happens, would it not be much more difficult to then play catch-up with various alternatives to sysvinit for everything that's newer, actively developed & maintained?

Or waiting might mean that the newer init alternatives to systemd like runit, openrc or s6 might improve and grow in the interim?

I don't know the technical side of things but from what I'm able to vaguely grasp about general concepts, I suspect it's not so much that sysV becomes obsolete but more that certain developers of applications just take the "lazy" way out and choose to include prebuilt systemd "hooks" as a easy way to get their app's services or daemons initialized and up and running (since they assume most distros already have systemd), rather than code in a init-neutral way to work with whatever init system is running in the distro.

Thus, if Application X works with systemd and not with sysV or other init systems, it may look as if systemd is so much better or more modern than the other init systems, when what happened was that the programmer of the App X made the program look for systemd only. [Note: I could be completely off-course. Experts, please correct me if I'm wrong]

If more developers do that, then it may get more troublesome for non-systemd distro users to install certain applications or programs because they will need systemd by default.

Posted: **Fri Jun 29, 2018 10:25 am**

Well, I like what Jerry3904 had to say, because if the tried & true (flawless?) sysvinit is actually still being maintained by Jesse Smith or anyone else with the knowledge to do so, then by all means I suppose there's nothing wrong by continuing with the present methods for MX development. And based on the post by the other person, he or she used the grub customizer to manage booting into systemd by default, so that seems like a really good solution for anyone who might need systemd. Being able to use grub-customizer to default boot into MX with systemd actually seems like the perfect solution all-around since parties from both sides of the discussion are thereby able to have what they want, in a matter of seconds. Thus it becomes a permanent solution, while the second option still remains accessible to fall back on, for anyone, at anytime (on an installed MX setup).

Posted: **Fri Jun 29, 2018 10:28 am**

It is already an issue for a few programs that install a systemd script to start a service but don't include a sysvinit script. So far, debian has been adding those scripts when they include one in their repos.
The main issue is with third party programs that aren't licensed to allow repackaging and/or redistribution. We can often recommend a workaround for those if it is brought to our attention.

And sysvinit is getting maintenance again. Jessie Smith is fixing bugs and incompatibilities as they arise. He took the workarounds that the various distributions still using sysvinit had come up with and used that info to fix those problems in the main tree, and since then has been fixing bugs & incompatibilities as they arise. Most of it is small stuff because sysvinit is so mature, but he's keeping it current.

Posted: **Fri Jun 29, 2018 10:44 am**

For me systemd is a hot topic because its "Windows design" that is hurting other init systems and putting a lot of power in the hands of a few individuals that clearly don't care about the Unix philosophy.

As a user I think systemd is frustrating because it doesn't work well out of the box like SysV or Upstart. As a systemd user you are supposed to write start-up delay scripts so that your desktop boots to a fully working state. Also you have to modify the shut-down time-out to less than 90 seconds if you think that is too long to wait for shutdown or restart. Some say the shutdown delay issue has been fixed but on most Linux forums it's an issue that regularly pops up.

On the other hand if you are a System Administrator maybe systemd is a gift from the gods. Many experienced Linux users do like systemd. Just don't expect a systemd based distro to work "out of the box".

Posted: **Fri Jun 29, 2018 11:38 am**

dreamer wrote: Fri Jun 29, 2018 10:44 amOn the other hand if you are a System Administrator maybe systemd is a gift from the gods. Many experienced Linux users do like systemd. Just don't expect a systemd based distro to work "out of the box".

My understanding is that Debian runs by default with systemd. I've never had any problems running Debian out of the box. We use Debian on our Server too and never have to fix or patch anything related to systemd, at least not that I'm aware of. I'm not a certified SysAdmin, but we do have one who does any server related work that I can't do on my own. Hah, until I read that post about someone switching their default MX boot to a systemd boot instead, I never even knew that systemd existed.

It's like they say, you learn something new every day.

Posted: **Fri Jun 29, 2018 11:55 am**

Sysadmins swear by systemd until it fails. Then they swear at it.
It allows some simple process control that's harder to do without it, but it's much harder to troubleshoot when the SHTF.

Posted: **Fri Jun 29, 2018 12:18 pm**

I don't know much about Debian. The quality of Ubuntu (and every Ubuntu-based distro) skydived after the introduction of systemd. Coincidence? I don't know. Dedoimedo will tell you that the last good Ubuntu release was 14.04 (Upstart-based) and I fully agree. He also gave some praise to Kubuntu 17.04 (systemd-based), but that wasn't a LTS release so not very important. Of course he gave a lot of praise to MX 17, which was expected (maybe even distro of the year?).

If Debian has a solid implementation of systemd, that's great. Someone (a very knowledgeable guy) tried to tell me that systemd is better than other inits, I just didn't know how to use it. He was right about that, but am I as a user supposed to dive into the inner workings of systemd? It's clearly the server mentality vs desktop user mentality.

https://www.dedoimedo.com/

Posted: **Fri Jun 29, 2018 1:03 pm**

dreamer wrote: Fri Jun 29, 2018 12:18 pm
If Debian has a solid implementation of systemd, that's great. Someone (a very knowledgeable guy) tried to tell me that systemd is better than other inits, I just didn't know how to use it. He was right about that, but am I as a user supposed to dive into the inner workings of systemd? It's clearly the server mentality vs desktop user mentality.

It really shouldn't matter to a desktop user, with the caveat that timkb4q added about scripts that start services sometimes being problematic. A big example right now is "plex" which doesn't package a sysvinit script. We hacked one on if plex is installed by MX-packageinstaller, but it ain't exactly pretty.

I personally don't care what the init system is, but the antiX live system (which gives MX the live-USB goodness) utilizes and expects sysVinit to be in use.

Posted: **Fri Jun 29, 2018 4:22 pm**

I haven't seen those quick boot times promised by systemd, instead it has made boot times across some of my OS's boot slower. systemd-analyze blame will show slow boot issues. systemd is a cancer, it infects the entire OS and I have serious doubts anyone will be able to avoid it on any Linux distro in another two years, maybe less. Already I've seen it cause me trouble on MX.
When I first heard about systemd I really didn't have any strong feelings about it. Now I wish Linux had avoided it entirely. But Redhat and Fedora, whose actions are mimicked by Debian for reasons that elude me, have stuck us with systemd and it is becoming critical software that it will soon take herculean efforts to avoid.

Posted: **Fri Jun 29, 2018 4:33 pm**

My problem with systemd started with malfunctioning systems. The shut down time-out was described as a "feature" by the systemd expert, but in my case it was an unwanted feature. The network connection in Ubuntu became very unreliable after systemd, but it would be unfair to blame systemd for everything without proof.

HessenZone has mentioned Debian as a distro which doesn't require user invention to have reasonably working systemd. Are there any other distros like that? What I really want to know is if someone has had a good systemd experience out of the box? (booting to fully working desktops, no time-outs, no unwanted restarts etc.)

I booted with Upstart since 2008 and I hardly knew what an init system was, because it just worked, just like SysV works in MX. Then came systemd and init became "rocket science".

systemd = more than one million lines of code
https://www.phoronix.com/scan.php?px=sy ... =news_item

sysvinit = ten thousand lines of code (max)

I won't complain if MX switches to systemd because if anyone can make systemd work out of the box it's probably the antiX/MX team. Still sad if complexity wins over simplicity because then even fewer people will be able to understand and troubleshoot.

Posted: **Fri Jun 29, 2018 5:28 pm**

I use a website called skylinewebcams.com in conjunction with a screen recorder called Vokoscreen screencast to record wild animal sightings. If I start any of my Dell laptops with systemd everything works well, but if I start the same PCs with sysvinit, the Vokoscreen crashes and it crashes the whole system.
Why, I have no clue.

Posted: **Sat Jun 30, 2018 2:30 am**

dreamer wrote: Fri Jun 29, 2018 4:33 pm My problem with systemd started with malfunctioning systems. The shut down time-out was described as a "feature" by the systemd expert, but in my case it was an unwanted feature. The network connection in Ubuntu became very unreliable after systemd, but it would be unfair to blame systemd for everything without proof.

HessenZone has mentioned Debian as a distro which doesn't require user invention to have reasonably working systemd. Are there any other distros like that? What I really want to know is if someone has had a good systemd experience out of the box? (booting to fully working desktops, no time-outs, no unwanted restarts etc.)

I don't think it's as simple as just pointing to any particular distro. We've been using Linux full time for everything, professionally too, for the past 10 years. Of that time, we've been using distros such as Debian, Mint, and others, but always with the XFCE desktop since we like that one the best. During the past 4 years or so we've used primarily Linux Mint on our machines. We're not gamers either. So between the type of desktop and the lack of gaming, perhaps that has a lot to do with the long-term performance of any distro with systemd as well? I can't speak for other people, but ever since Mint 16 I can honestly say that we've experienced hardly any negative issues that couldn't be tracked back directly to our own behavior on a computer.

Two browsers with dozens of tabs open, heavy duty Office applications including databases, Web authoring with Komodo, Server usage, Watching hundreds of videos and playing thousands upon thousands of songs, with never a problem that could be blamed on the system. As a matter of fact, I had mentioned this elsewhere, our Livingroom machine has a bad reset function which forces us to do a hard reset on it every day, been doing that for months, and that Mint 18.3 setup runs just as well as on the first day. All of our machines are hard-wired and home-networked together too, with never a problem.

As stated before, I don't know anything about systemd and have to judge the perfomance of my OS based on my experiences with it. On very very rare occasions we've seen some minor bugginess with Mint over the years, but nothing serious that couldn't be easily & quickly corrected. That's why I call it trouble-free, since nothing is actually perfect. But with MX Linux 17 we've indeed experienced enough issues that my wife isn't ready to make that switch yet. We've experienced WiFi connectivity issues which inexplicably fixed themselves during the course of 3 to 5 days while working on machines that belong to other people. We've experienced printer issues that couldn't be corrected - but in all fairness that seems to be a linux wide problem. And most recently I've experiened a mount problem with MX 17 that I simply cannnot fix, an internal drive with an NTFS partition that simply can not be made to auto-mount. But that's another issue for aother day in another part of this forum.

I have believed for quite some years now, that 99.9% of all computer issues, regardless if on Windows or on Linux machines, have to do with either gaming, excessive use beyond that which other hardware was designed to handle, or software incompatibility which was created by the installer i.e. the user of a particular machine. So far, I can't find any reason to use or not to use systemd, since I don't personally see any more stability with MX Linux than I've seen with Mint or with Debian. I'm not a certified SysAdmin though and I'm not a code guru either. I'm thrilled with MX Linux because of the speed, compatibility with 10 year old computers, the snapshot feature, and some other things. I plan on being an MX Linux user as long as it exists.
Wow, some pretty cool discussing going on here.

Posted: **Sat Jun 30, 2018 7:01 am**

Thank you for your post. It made me feel more positive about the future of Linux. If Linux Mint can get systemd right it means that it is possible (if the stars align

). Still why bring the monolithic design issues from Windows to Linux? Didn’t great engineers figure out how to build a flexible and robust system back in the 70s?

From Wikipedia:
“Unix systems are characterized by a modular design that is sometimes called the "Unix philosophy". This concept entails that the operating system provides a set of simple tools that each performs a limited, well-defined function,[6] with a unified filesystem as the main means of communication,[3] and a shell scripting and command language to combine the tools to perform complex workflows.”

I knew that Linux Mint added some polish to the Ubuntu base and just like MX devs they are good at making things that work. So I believe you when you say you have a trouble-free experience with systemd in Linux Mint. Still I believe that for distros that don’t really care anymore (Ubuntu) or distros that lack the Linux Mint resources, making systemd work out of the box can be difficult. These distros refer to “upstream”, when talking about systemd problems. That is actually correct, because those systemd problems I have described are not distro-specific, but in most cases “features” of Systemd. Linux Mint has the resources to work around the problems of Systemd, most distros don’t. Linux Mint introduced start-up delays in Cinnamon Control Center, but the measures probably went further than that to make sure Linux Mint boots to a functional desktop.

The problem with Mint is that they not only add polish but also restrictions. Clem pulled their snapshot tool (think it was called Mint Constructor or something like that) and made sure Systemback wouldn’t work with Mint (workarounds did exist). The Linux Mint brand was more important than users’ ability to create installable ISOs. He claimed the ISO creation functionality was abused by people creating Linux Mint distro clones.

I’m glad your experience with Linux Mint has been really positive. I have read that people experience the 90 sec time-out even on Mint and that Mint isn’t immune to the Ubuntu problem best described as “a tiny tiny update that breaks the system”. For example a minor security update to the kernel that breaks some important part of the system. In the past Linux Mint didn’t include kernel updates by default. Now I see Linux Mint is including those kernel updates in Linux Mint 19.

I’m still sceptical about systemd, but reading that it is possible to have a fully working system with systemd made feel better. I still see systemd as a sysadmin tool that has been forced on desktop users. The “systemd expert” stated that if he can choose init himself his preferred init is runit. I think he defended systemd mostly because he was tired of people complaining about it.

“One of the runit project's principles is to keep the code size small. As of version 1.0.0 of runit, the runit.c source contains 330 lines of code; the runsvdir.c source is 274 lines of code, the runsv.c source 509. This minimizes the possibility of bugs introduced by programmer's fault, and makes it more easy for security related people to proofread the source code.”

https://www.dragora.org/repo.fsl/doc/tr ... tsystem.md

Posted: **Sat Jun 30, 2018 10:30 am**

let's make it simple, try to create zram and zswap on systemd.

https://suckless.org/sucks/systemd/

Posted: **Sat Jun 30, 2018 12:15 pm**

stsoh wrote: Sat Jun 30, 2018 10:30 am let's make it simple, try to create zram and zswap on systemd.

https://suckless.org/sucks/systemd/

To add to the above. Might as well delete your /usr/local/bin files.
Cuz systemd defaults to doing it's own thing and uses it's self imposed rules as default.
Not the dev idea of what his distro should run like.

In other words. The steering wheel does not steer the car any more The in dash stereo knob does that function now.

Some folks may like to drive this way how ever.

Posted: **Sat Jun 30, 2018 12:23 pm**

To be fair, most end users aren't even writing small scripts and they aren't going to notice the issues with systemd.

But systemd certainly tries to do too much, needlessly reinventing wheels, gears, levers, and pipes. Some of its bits are quite useful but I don't want it in charge.

Posted: **Sat Jun 30, 2018 2:09 pm**

read this:

https://www.reddit.com/r/copypasta/comm ... simpleton/

Posted: **Sat Jun 30, 2018 3:57 pm**

I've not been impressed with much when it comes to Ubuntu/Canonical, but I wish they had stuck to their guns with Upstart. It would have been nice to have two well supported init systems in Linux. You have choice in everything else regarding Linux from DE's to file managers, etc. I don't know who decided we should have "One Init System To Rule Them All...."

Posted: **Sat Jun 30, 2018 11:01 pm**

I used Arch linux since early 2008. It used to have the most wonderful "unix like BSD style init" as it was called. Where you had an /etc/rc.conf that was quite a short file when you consider that you could configure most things that matter in your OS quite simply & easily (with initial reference to the ArchWiki of course).

Arch had a brilliant wiki (these days, I don't think it is as good as it used to be). All in all, I loved the old Arch, with its personalised custom setup; rolling release package management, & the wondrous pacman, to manage your packages.

Then the Arch "management" chose to move to systemd (I won't go into how so many of them - including the mods & trusted users - lowered themselves with personal attacks on anyone who disagreed with their stance re. systemd). I watched the arguments, I didn't get involved in any of them, but I could no longer use Arch due to my loss of respect for "most" not all, of those at the top.

I went back to BSD for a bit of time, during which I received an email from mips, who told me I should come over to Manjaro, as it was pretty new & had a small number of users; was Arch based & they had a really good attitude (noob friendly). So I went there in the latter part of 2011.

Manjaro was using systemd. I didn't like that, I don't like the ever growing systemd complexity. Simple is always better in my book. Then artoo (who's arguments, & the treatment that they & he had received by the Arch dudes, I was aware of), came over to Manjaro, where he was welcomed.

He has been, & still is, one of the main forces behind making the OpenRC init a viable proposition for Linux users outside of Gentoo (where it is still the native, with systemd as an option). Artoo put an enormous amount of work in (with others) to bring OpenRC up to the level that it is today.

I used Manjaro with the OpenRC init, until it was no longer supported, as artoo took it away & made the Artix distro (= Arch linux without systemd). He had done that with the help & inclusion of the other main (non-Gentoo) OpenRC people out there. Artoo moved from Manjaro as his project is less time consuming when systemd is not part of the distro - there was/is NO animosity between the two camps.

I didn't go straight to Artix when it first started up, I went over to Void (runit init) for a while. The init & package management were fine, though there are no where near enough packages available for me (I didn't want to make my own). I'm not sure where Void is up to at the mo' as last I heard the dev' disappeared?

Went to Artix, & it was great. Arch linux without systemd is fine by me. The Artix community/forum is fine. BUT, they don't use the same repo structure (naming) as Arch. This one problem, means that I can't use a wonderful piece of software that PIA VPN, supply to their users on "some other OS's" & Debian, Ubuntu, Mint, Arch (probably Red Hat & Fedora too), based distros. Which sucks! :( PIA are in the process of making their software all open source. So the day may come where I can make the tiny modifications needed.

So I went looking for systemd free distros. Devuan, Refracta - both OK, but not stable when I do what I do to them. MX 17, has been perfectly stable & I've made it nothing like it was meant to be by its creators. So here I sit. :)

If MX was running systemd, I would certainly not be here.

I could get into a rant as to why I don't like systemd, but I really couldn't be bothered, as it won't achieve anything.

So I'll leave it with the fact that I value freedom of choice, & since systemd has come along, there has been an ever diminishing amount of choices available to me, as a Linux user. Most point & click OS users wouldn't notice, & they most likely wouldn't care. I do.

If systemd had not been invented I'd most likely still be a happy Arch user (as would a number of other ex Arch users I know)...

Posted: **Sun Jul 01, 2018 12:14 am**

@handy, void was still running nicely and getting updates as of 10 days ago. That was the last time I used my void+cinnamon partition on my pc.

I understand they're in the process of moving their repositories and at some point users will need to change the Repo locations.

It's quite a pleasant distro but yes, the number of packages is small compared to Debian or Arch.

On the other hand, I'm a normal everyday user and am pretty equal-opportunity about init systems, so I use Manjaro because I like it and it works well for me.

I just want freedom of choice in init systems like you, handy. People should not have problems running a program just because of the init they use.

Posted: **Sun Jul 01, 2018 1:34 am**

I've helped to maintain the without-systemd.org wiki page: "Arguments against systemd"
Hopefully it stands as one of the most well-reasoned and most comprehensive references on the subject.

stsoh wrote: Sat Jun 30, 2018 2:09 pm read this:

https://www.reddit.com/r/copypasta/comm ... simpleton/

That is a poor citation. It contains some misinformation.
Please step back from the (out-of-context) "copypasta" version; read the (probably) original discussion it was pasta'd from:
eli5_systemd_advantages_and_disadvantages

Posted: **Sun Jul 01, 2018 2:07 am**

systemd vs kernel background history.
https://thenewstack.io/systemd-vs-linux-kernel/

inspiration-behind-systemd
https://thenewstack.io/unix-greatest-in ... d-systemd/

Note: was Torvalds an “enthusiastic supporter” of systemd??

Posted: **Sun Jul 01, 2018 4:02 am**

Wow, this post has turned into a real classroom lesson of sorts, for all those who don't know anything about systemd with its predecessors. Found this link to be fairly interesting as well:
http://without-systemd.org/wiki/index.php/Main_Page

I for one, not having to deal with systemd on a personal/coding level, have definitely received all the input and more that I can process about systemd. It's very refreshing to read all of the different comments, review the diversity of information within the supplied systemd links, and so on. Thank you to everyone for making this such an educational experience.

Have an excellent Sunday.

Posted: **Mon Sep 17, 2018 5:12 am**

I don't know which init system precedes which in birthdate but OpenRC, S6, and Runit all took off, in interest and development, because of systemd. So this is one thing we must be thankful to systemd. If you think of another, let us know

Posted: **Mon Sep 17, 2018 5:25 am**

timkb4cq wrote: Sat Jun 30, 2018 12:23 pm...
But systemd certainly tries to do too much, needlessly reinventing wheels, gears, levers, and pipes. Some of its bits are quite useful but I don't want it in charge.

+1

Posted: **Wed Mar 13, 2019 1:35 pm**

systemd is a ball of crap.
I currently have about 3 staple linux sysadmin related issues of software I used for years and rely on suddenly wont install etc.
I really like MX, but next OS install I am running as far a way from it as possible due to this.
I have for example Samba that fails to work on MX due to this etc.
Systemd will eventually bring a lot of linux down or make it very impalatable.
I dont mind new, but not this kind of irresponsible "systemd"new.
Since installing MX it has been 1/2 a year of battling software that were stalwarts for decades.
Unacceptable and maybe worse .... irresponsible and undermining linux at its core abandoning init etc.

Posted: **Wed Mar 13, 2019 2:09 pm**

You do know MX is a sysvinit system, not systemd unless you choose the advanced option in the boot menu.

Posted: **Wed Mar 13, 2019 2:22 pm**

zimbodel wrote: Wed Mar 13, 2019 1:35 pm systemd is a ball of crap.
I currently have about 3 staple linux sysadmin related issues of software I used for years and rely on suddenly wont install etc.
I really like MX, but next OS install I am running as far a way from it as possible due to this.
I have for example Samba that fails to work on MX due to this etc.
Systemd will eventually bring a lot of linux down or make it very impalatable.
I dont mind new, but not this kind of irresponsible "systemd"new.
Since installing MX it has been 1/2 a year of battling software that were stalwarts for decades.
Unacceptable and maybe worse .... irresponsible and undermining linux at its core abandoning init etc.

I'm sorry, but this is all FUD.

Posted: **Wed Mar 13, 2019 2:28 pm**

A good article for those like me, that prefer Debian based systems but get caught up in Systemd problems.
Basically Debian Fork without systemd. That is the way I am going in the future with all my servers.

https://www.makeuseof.com/tag/debian-wi ... md-devuan/

Posted: **Wed Mar 13, 2019 2:48 pm**

Then why the hell is it running on my MX18 out of the box.
I will be VERY glad to get rid of systemd.
I tried to uninstsll systemd and it brought the entire MX18 installation down.
So howcome an uninstall brings down Mx18, if according to you MX18 do not use it.
Talk about misinformation.

[/quote]I'm sorry, but this is all FUD.
[/quote]

Posted: **Wed Mar 13, 2019 2:59 pm**

Maybe you should read a bit about MX Linux on this question. Here's a good start:

https://mxlinux.org/wiki/system/systemd/

Posted: **Wed Mar 13, 2019 3:19 pm**

zimbodel wrote: Wed Mar 13, 2019 2:28 pm A good article for those like me, that prefer Debian based systems but get caught up in Systemd problems.
Basically Debian Fork without systemd. That is the way I am going in the future with all my servers.

https://www.makeuseof.com/tag/debian-wi ... md-devuan/

Since MX Linux doesn''t use Systemd as init the main problem with Systemd is packages that rely on it. MX Linux tries to solve it with Debian packages like CUPS. But then there are third party packages like Snap and Snap packages that rely on Systemd. Several VPN applications and other applications also seem to rely on Systemd.

Devuan may have a base system that is free from Systemd (just like antiX), but as soon as you add stuff outside of those repos you may run into problems.

Systemd is like the new Pulseaudio. Firefox and other applications rely on Pulseaudio so if you don't use Pulseaudio expect sound problems with certain applications.

Then on the horizon is Wayland. Gnome and KDE (Kwin) don't develop X.org (X server) specific features anymore and new stuff is targeting Wayland.

So if you like "classic Linux" like myself you are going to be more of a "niche user" in the future. Doesn't matter if you use Devuan. Devuan doesn't have more packages than Debian. But for servers you probably don't need more packages anyway so Devuan might be a good choice for a Systemd free server.

For a desktop system like MX Linux it's pretty cool (and future-proof) that you can choose your init. I don't know of any other distro that lets you do this out of the box. It's a feature.

Posted: **Wed Mar 13, 2019 3:37 pm**

Using systemd with MX can only happen by choice.
The default is sysvinit.

And, if you choose systemd then you are running an untested system, not MX18.
Devs may try to support you, but it is not the interest.
MX18 is designed to avoid systemd init.

If you don't want to see systemd in the system,
you'll have to go back to Devuan to help them catch up, or BSD.

Posted: **Wed Mar 13, 2019 3:38 pm**

Well said, dreamer!

zimbodel, many of us posting here are well aware of Devuan, thankyouverymuch.
Evident from your posts, you (seriously) have a few points of misunderstanding regarding cause and effect, and whatall is going on "behind the scenes, under the hood" of the operating system.

~ skidoo, aka "kriv", one of the https://without-systemd.org wiki maintainers

Posted: **Wed Mar 13, 2019 3:47 pm**

If you don't want to see systemd in the system,
you'll have to go back to Devuan and help them catch up.

That's not a helpful comment; it's an eyepoke, and... is it even (still) accurate?
For the Debian10 -based Devuan Beowolf release, is the Devuan collective still bent on performing the busywork of "weeding out" the harmless .service files provided by various upstream Debian packages?

Posted: **Wed Mar 13, 2019 3:57 pm**

@skidoo, You need to add https://= to your link. Right now it goes to a page not found message.

Posted: **Wed Mar 13, 2019 4:25 pm**

@skidoo,
Apologies if my statement was inacurate.
I last tried ASCII 2 and there were some items missing from the repos.
I only thought too suggest that the poster could support them if he wanted to have systemd completely removed.
Perhaps antiX is closer to his needs?
I have not used Samba for years so you are right, I don't need to comment and neither have I tried Beowulf.

Posted: **Wed Mar 13, 2019 5:13 pm**

I cannot say that I understand it or like or dislike it really but will briefly share a recent experience that has left me to use it at boot or to have no online sound after boot and no access to the pulse audio mixer as it will no longer start without systemd. I'm sure it started with the upgrade I did from mx17 to mx18 in which I made a terrible mistake of not checking my repo's list first and found after the fact that I had my Debian Testing and backport repo's open and settings set to upgrade to the highest available distro. The result was my borked sound. After reading something about pulse audio and systemd I decided to try booting with the systemd option in mx and to my surprize the sound issue resolved and I was able to start the pulse audio mixer again. I really prefer the way it was before I borked it as it takes forever to boot with the systemd option but I'm left with it till I figure out what exactly the problem is and I have not had time recently to weed it out.

Posted: **Wed Mar 13, 2019 5:19 pm**

The default may be sysvinit, but there shure is a hell of lot of interference from the systemd.
This is not the way Unix and by large Linux is supposed to work. systemd is a huge fork and all I can think of that it is a dual purpose fork.
The fork per se and the fork that is paid for to kill linux. There is just too much unaccounted for sudden aggresive evangelism for systemd @ Debian.
Looks like the process is funded.
All unneeded.

I am glad that Mx at least attempt to stick with Sysv,

Richard wrote: Wed Mar 13, 2019 3:37 pm Using systemd with MX can only happen by choice.
The default is sysvinit.

And, if you choose systemd then you are running an untested system, not MX18.
Devs may try to support you, but it is not the interest.
MX18 is designed to avoid systemd init.

Nope, out of the box install with hilarious behavior.

If you don't want to see systemd in the system,
you'll have to go back to Devuan to help them catch up, or BSD.

Exactly what I will do... indeed.!
I rather have installation problems in front of me from the package space than to have the OS byte me due to some savant at Debian's idea that systemd is a good idea.
Irresponsible software, but thanks at least for clearing up that Mx tries not to be dependent on it.

Posted: **Wed Mar 13, 2019 5:28 pm**

I am aware of the contents of that page as it is basically a lift of another systemd page.However it is Irrelevant as systemd uninstalled kills Mx, therefore must be in use or at least relied on.

Jerry3904 wrote: Wed Mar 13, 2019 2:59 pm Maybe you should read a bit about MX Linux on this question. Here's a good start:

https://mxlinux.org/wiki/system/systemd/

Posted: **Wed Mar 13, 2019 5:54 pm**

@zimbodel,
You misquoted me

Your comment in this line should be preceded by a close comment:

Nope, out of the box install with hilarious behavior.

And then an open comment afterwards to continue my comment.

I haven't had any hilarious behavior with MX since 02-April-2014 when first installed.

Posted: **Wed Mar 13, 2019 6:27 pm**

zimbodel wrote: Wed Mar 13, 2019 5:28 pm I am aware of the contents of that page as it is basically a lift of another systemd page.However it is Irrelevant as systemd uninstalled kills Mx, therefore must be in use or at least relied on.

Jerry3904 wrote: Wed Mar 13, 2019 2:59 pm Maybe you should read a bit about MX Linux on this question. Here's a good start:

https://mxlinux.org/wiki/system/systemd/

Then it sounds to me like it's maybe time that you should look around for another distro that meets your criteria--not much use in complaining about MX when it makes perfectly clear what its policy is and why. Luckily, there are a lot of them out there...

Posted: **Wed Mar 13, 2019 6:30 pm**

zimbodel wrote: Wed Mar 13, 2019 5:28 pm However it is Irrelevant as systemd uninstalled kills Mx

That's FALSE. Are you the same guy from Google Plus? I responded to a similar incorrect, possibly lying and trollish claim with this:

Also, regardless of your wrong reasoning your claim that you base your fallacy upon is simply incorrect, nothing happens if you remove systemd, some libs get installed some removed as one would expect, everything works just fine, Try it.. and stop lying. Nobody likes lying activists that have an ax to grind.

Posted: **Wed Mar 13, 2019 6:49 pm**

zimbodel wrote: Wed Mar 13, 2019 2:28 pm A good article for those like me, that prefer Debian based systems but get caught up in Systemd problems.
Basically Debian Fork without systemd. That is the way I am going in the future with all my servers.

https://www.makeuseof.com/tag/debian-wi ... md-devuan/

And you'll find it even more impossible to run those outside programs that rely on systemd on Devuan than MX, since they removed the option.

Posted: **Thu Mar 14, 2019 1:09 am**

Nice try to troll me, by accusing me of being someone I am not.
Troll? Look in the mirror Maybe ? with this attempt of yours.
There is definitely more than one person with systemd trouble .. it is quite an uproar if you take your systemd headphones off.

I came to MX from one of your developers giving me very kind help.
MX have great people and I have no trouble with any person here. I was happy with it until I saw what a baitball it really is.
Not really MXs fault it is Debian at fault for creating this mess.

Adrian wrote: Wed Mar 13, 2019 6:30 pm
zimbodel wrote: Wed Mar 13, 2019 5:28 pm However it is Irrelevant as systemd uninstalled kills Mx
That's FALSE. Are you the same guy from Google Plus? I responded to a similar incorrect, possibly lying and trollish claim with this:
Also, regardless of your wrong reasoning your claim that you base your fallacy upon is simply incorrect, nothing happens if you remove systemd, some libs get installed some removed as one would expect, everything works just fine, Try it.. and stop lying. Nobody likes lying activists that have an ax to grind.

Posted: **Thu Mar 14, 2019 1:15 am**

Its fine, I can live with trouble if I know where it comes from and then get solutions from there.
What I cant live with is this subterfuge that comes from dubious initializing of the system which is a fundamental issue.
So, I will go the other way and support those distros , even financially as this time it is a very very serious fork.

https://www.makeuseof.com/tag/debian-wi ... md-devuan/
[/quote]

And you'll find it even more impossible to run those outside programs that rely on systemd on Devuan than MX, since they removed the option.
[/quote]

Posted: **Thu Mar 14, 2019 1:21 am**

Adrian wrote: ↑

Also, regardless of your wrong reasoning your claim that you base your fallacy upon is simply incorrect, nothing happens if you remove systemd, some libs get installed some removed as one would expect, everything works just fine, Try it.. and stop lying. Nobody likes lying activists that have an ax to grind.

BTW Which axe and activism for what ? This is becoming surreal accusations with no basis.

I rather point out your gross inaccuracies and false claims.
see below.

Oh yeah? !!!!

Then why if I try to uninstall systemd I get the following... (Lol! even mx-installer depnds on systemd )

The following packages will be REMOVED:
brasero colord fskbsetting gnome-disk-utility gufw gvfs gvfs-backends gvfs-daemons gvfs-fuse k3b
libpam-systemd mx-installer mx-repo-manager nautilus network-manager network-manager-gnome
network-manager-openconnect network-manager-pptp network-manager-vpnc policykit-1
policykit-1-gnome rtkit synaptic systemd systemd-sysv systemd-ui udisks2

Then .....
The following NEW packages will be installed:
sysvinit-core

I thought, sysvinit is the defaullt ??

Go figure

# apt remove systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
brasero-common gazelle-installer-data-mx gir1.2-polkit-1.0 grub-efi-ia32-bin libbrasero-media3-1
libcolorhug2 libcrack2 libpwquality-common libpwquality1 pptp-linux
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
sysvinit-core
The following packages will be REMOVED:
brasero colord fskbsetting gnome-disk-utility gufw gvfs gvfs-backends gvfs-daemons gvfs-fuse k3b
libpam-systemd mx-installer mx-repo-manager nautilus network-manager network-manager-gnome
network-manager-openconnect network-manager-pptp network-manager-vpnc policykit-1
policykit-1-gnome rtkit synaptic systemd systemd-sysv systemd-ui udisks2
The following NEW packages will be installed:
sysvinit-core
0 upgraded, 1 newly installed, 27 to remove and 0 not upgraded.
Need to get 135 kB of archives.
After this operation, 61.3 MB disk space will be freed.
Do you want to continue? [Y/n]

Posted: **Thu Mar 14, 2019 1:31 am**

Looks like you installed gnome desktop first. Lots of non-default packages in that list.

How was it done?

Posted: **Thu Mar 14, 2019 1:49 am**

asqwerth, good observation.

yes I installed it much later and I already had these problems way before I installed it as the MX interface was severely restrictive and basically unusable. Had more the feel of an arcade game.
In the end I use XFCE as window manager and it works way waybetter than the MX window manager default.

For my Desktops, MX is the best distro I came accross so far, except for the perpetual systemd nightmare which makes anything "server" unpleasant.
systemd probably comes from the same place as securelinux. It has the same feel and evangelism.

I didnt installed it on servers and definitely never will install MX on servers. It would have been great as I could have good use for it, but they will run vanilla sysv No systemd Debian flavor there end of story.

Posted: **Thu Mar 14, 2019 1:56 am**

zimbodel wrote: Thu Mar 14, 2019 1:21 am
Also, regardless of your wrong reasoning your claim that you base your fallacy upon is simply incorrect, nothing happens if you remove systemd, some libs get installed some removed as one would expect, everything works just fine, Try it.. and stop lying. Nobody likes lying activists that have an ax to grind.

Oh yeah? !!!!

Then why if I try to uninstall systemd I get the following... (Lol! even mx-installer depnds on systemd )

The following packages will be REMOVED:
brasero colord fskbsetting gnome-disk-utility gufw gvfs gvfs-backends gvfs-daemons gvfs-fuse k3b
libpam-systemd mx-installer mx-repo-manager nautilus network-manager network-manager-gnome
network-manager-openconnect network-manager-pptp network-manager-vpnc policykit-1
policykit-1-gnome rtkit synaptic systemd systemd-sysv systemd-ui udisks2

Then .....
The following NEW packages will be installed:
sysvinit-core

I thought, sysvinit is the defaullt ??

Go figure

# apt remove systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
brasero-common gazelle-installer-data-mx gir1.2-polkit-1.0 grub-efi-ia32-bin libbrasero-media3-1
libcolorhug2 libcrack2 libpwquality-common libpwquality1 pptp-linux
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
sysvinit-core
The following packages will be REMOVED:
brasero colord fskbsetting gnome-disk-utility gufw gvfs gvfs-backends gvfs-daemons gvfs-fuse k3b
libpam-systemd mx-installer mx-repo-manager nautilus network-manager network-manager-gnome
network-manager-openconnect network-manager-pptp network-manager-vpnc policykit-1
policykit-1-gnome rtkit synaptic systemd systemd-sysv systemd-ui udisks2
The following NEW packages will be installed:
sysvinit-core
0 upgraded, 1 newly installed, 27 to remove and 0 not upgraded.
Need to get 135 kB of archives.
After this operation, 61.3 MB disk space will be freed.
Do you want to continue? [Y/n]

You are either a lying weasel or you messed up your system. I just did a MX-18.1 fresh install and just did a aptitude upgrade, look here:

Code: Select all

 dpkg -l sysv*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                 Version                 Architecture            Description
+++-====================================-=======================-=======================-==============================================================================
ii  sysv-rc                              2.88dsf-59.9            all                     System-V-like runlevel change mechanism
ii  sysv-rc-conf                         0.99-7                  all                     SysV init runlevel configuration tool for the terminal
un  sysvinit                             <none>                  <none>                  (no description available)
ii  sysvinit-core                        2.88dsf-59.9            amd64                   System-V-like init utilities
ii  sysvinit-utils                       2.88dsf-59.9            amd64                   System-V-like utilities

See.... sysvinit-core is preinstalled, how come you don't have it on your system?

Posted: **Thu Mar 14, 2019 2:08 am**

How must I know why it is not on my system.
I did not roll up a distro called MX.
I dont know why I would go through this effort to lie. But it seems important to you as your only real defense.
I can only report what I find.

Here is what I run from a clean install. System was never "messed up"
I did a clean install and systemd is clearly running as I showed above but which you seemingly MUST counter as false.
$ cat /proc/version
Linux version 4.19.0-1-amd64 (stevep@mxlinux.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.5-2~mx17+1 (2018-12-12)

Was a fast clean install .... a bit too fast I would say. But unlike you I dont jump/to conclusions.

And by the way your dpkg -l is a bit misleading.
Here is mine.......basically similar than yours, but the proof in the pudding is what apt wants to install, when systemd is uninstalled.
I really dont know what you tried to prove.

# dpkg -l sysv*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================-==============-==============-===========================================
ii sysv-rc 2.88dsf-59.9 all System-V-like runlevel change mechanism
ii sysv-rc-conf 0.99-7 all SysV init runlevel configuration tool for t
un sysvinit <none> <none> (no description available)
rc sysvinit-core 2.88dsf-59.9 amd64 System-V-like init utilities
ii sysvinit-utils 2.88dsf-59.9 amd64 System-V-like utilities

Posted: **Thu Mar 14, 2019 2:16 am**

zimbodel wrote: Thu Mar 14, 2019 2:08 am How must I know why it is not on my system.
I did not roll up a distro called MX.
I dont know why I would go through this effort to lie. But it seems important to you as your only real defense.
I can only report what I find.

Here is what I run from a clean install. System was never "messed up"
I did a clean install and systemd is clearly running as I showed above but which you seemingly MUST counter as false.
$ cat /proc/version
Linux version 4.19.0-1-amd64 (stevep@mxlinux.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.5-2~mx17+1 (2018-12-12)

Did you fix antix expired key problem? That would stop you from getting the packages that you need to replace some of the dependencies. That's one of the problem I had with the new installation

Was a fast clean install .... a bit too fast I would say. But unlike you I dont jump/to conclusions.

I can install MX in Virtual Box in 5 minutes or so. I actually installed it again because I messed the testing because of the antix repo problem.

Posted: **Thu Mar 14, 2019 2:17 am**

That's why I asked how you installed gnome (eg which packages, from what source, what was removed in the midst of installing those packages, etc) .

Because the most likely conclusion from your posts here , as well as an earlier post about not having samba on your system, is that whatever you did or installed earlier, removed sysv and various default packages.

Posted: **Thu Mar 14, 2019 2:20 am**

Screenshot from ISO, you can see how sysvinit-core is installed on ISO anybody can check that.

Posted: **Thu Mar 14, 2019 2:26 am**

asqwerth wrote: Thu Mar 14, 2019 2:17 am That's why I asked how you installed gnome (eg which packages, from what source, what was removed in the midst of installing those packages, etc) .

Because the most likely conclusion from your posts here , as well as an earlier post about not having samba on your system, is that whatever you did or installed earlier, removed sysv and various default packages.

asqwerth,
I think you are onto something, but if true this is horrendously dangerous.
Any package that just goes willy nilly willy and replaces systemv with systemd, is opening huge security trouble. Now I am really getting suspicious about the entire systemd thing.

If you are right there better be alarms going off when systemv is replaced with systemd without users knowledge during an install.
I think you are right that it is gnome that must have done it.

Thank you for pointing this out.

I use Linux since 1997, and never had this kind of fundamental system changes done just to install an application. It is really serious. I wonder how many people start out with Systemv and end up with systemd just because they installed a gnome application.

Posted: **Thu Mar 14, 2019 2:28 am**

[/quote] by Adrian » Thu Mar 14, 2019 1:20 am
Screenshot from ISO, you can see how sysvinit-core is installed on ISO anybody can check that.
[/quote]

Nice try adrian. A Live Disc is NOT an installation as you claimed to have done.,
This is laughable.

I get the same as your supposed proof on my system while I have systemd running !!

What you present as proof is therefore misleading and false as I get the same as you while I have systemd installed.

# dpkg -l sysv*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================-==============-==============-===========================================
ii sysv-rc 2.88dsf-59.9 all System-V-like runlevel change mechanism
ii sysv-rc-conf 0.99-7 all SysV init runlevel configuration tool for t
un sysvinit <none> <none> (no description available)
rc sysvinit-core 2.88dsf-59.9 amd64 System-V-like init utilities
ii sysvinit-utils 2.88dsf-59.9 amd64 System-V-like utilities

Posted: **Thu Mar 14, 2019 2:31 am**

How could you not know, though? Whether you carry out installation by terminal commands or synaptic or mx packageinstaller, there are messages about what will be removed.

There's an additional yes or no step before it proceeds.

Posted: **Thu Mar 14, 2019 2:39 am**

asqwerth wrote: Thu Mar 14, 2019 2:31 am How could you not know, though? Whether you carry out installation by terminal commands or synaptic or mx packageinstaller, there are messages about what will be removed.

There's an additional yes or no step before it proceeds.

I dont use Mx packagemanager, it is a bit awkward. I install with apt or compile from sources.
Beats me, why I didnt see it in apt and never would expect an application removing init, but then sometimes these lists of software that will be installed in apt is loooooog.
I promise you I will not be the only one with this problem and it is a huge seccurity issue.

The good that came from this is that I will now write a script that will stop all interference with sysv. and check if it was removed. Merely relying on the apt flash-by is not acceptable anymore if applications now changes your init....

Posted: **Thu Mar 14, 2019 2:54 am**

OK, so now we know how you got gnome onto your system. The way you did it probably caused your problems.

But if you are so against systemd, I'm rather surprised you would not know how interconnected with systemd the full gnome suite is. It's the red hat, poettering connection.

Not many people are going to compile gnome from scratch ; they would install binaries from Debian repos. And that can be done in mx without leading to removal of sysv or samba.

Posted: **Thu Mar 14, 2019 3:03 am**

zimbodel wrote: Thu Mar 14, 2019 2:28 am
by Adrian » Thu Mar 14, 2019 1:20 am
Screenshot from ISO, you can see how sysvinit-core is installed on ISO anybody can check that.
Nice try adrian. A Live Disc is NOT an installation as you claimed to have done.,
This is laughable.

Like I mentioned before, I did a second fresh installation, sysvinit-core is both on ISO and on installed MX, anybody can check. I am interested what you claim that it doesn't exist on ISO or it doesn't exist when you install the ISO on the harddrive? What version of MX do you talk about?

Also, you can remove systemd, look:

You need to fix your antix repo first and also use aptitude that gives you a second option to replace system with elogind, I also had to overwrite a file.

Let's recapitulate:
1. false claim that sysvinit-core is not installed on ISO and harddrive -- easy to verify by anybody
2. false claim that you cannot replace systemd without removing important parts of MX -- it's doable with minimum skills and using aptitude correctly.
3. you "laugh" at me for some reason and imply that I cannot or didn't do a fresh install of MX, that's actually what's laughable, why would an MX developer have a problem to do a fresh install? Even more everybody can test if sysvinit-core is present on ISO or on their installation and it would be obvious who is the liar here. So... MX users if you are unsure do a dpkg -l sysv* both on live ISO or on your installed system and see who lies...
4. you seem to be an one-issue account that has a problem with systemd. That's fine, everybody has an opinion and an xxxxxxx, my problem begins is when you start to make false claims. I will continue to call you on your lies if you continue to spread them here.

Posted: **Thu Mar 14, 2019 3:07 am**

Youre a child with your perpetual bickering.
Either help solving a problem like others on the thread did constructively for me or shut up.

Your post have become belligerent beyond the scope of the topic.
Please give the people who help constructively and actually solved my problem a chance rather than to inject your random noise with preschool show-and-tell proofs.

Adrian wrote: Thu Mar 14, 2019 3:03 am Let's recapitulate:
1. false claim that sysvinit-core is not installed on ISO and harddrive -- easy to verify by anybody
2. false claim that you cannot replace systemd without removing important parts of MX -- it's doable with minimum skills and using aptitude correctly.
3. you "laugh" at me for some reason and imply that I cannot or didn't do a fresh install of MX, that's actually what's laughable, why would an MX developer have a problem to do a fresh install? Even more everybody can test if sysvinit-core is present on ISO or on their installation and it would be obvious who is the liar here. So... MX users if you are unsure do a dpkg -l sysv* both on live ISO or on your installed system and see who lies...
4. you seem to be an one-issue account that has a problem with systemd. That's fine, everybody has an opinion and an xxxxxxx, my problem begins is when you start to make false claims. I will continue to call you on your lies if you continue to spread them here.

Posted: **Thu Mar 14, 2019 3:08 am**

zimbodel wrote: Thu Mar 14, 2019 3:07 am Youre a child with your perpetual bickering.
Either help solving a problem like others on the thread did for me or shut up.

Adrian wrote: Thu Mar 14, 2019 3:03 am Let's recapitulate:
1. false claim that sysvinit-core is not installed on ISO and harddrive -- easy to verify by anybody
2. false claim that you cannot replace systemd without removing important parts of MX -- it's doable with minimum skills and using aptitude correctly.
3. you "laugh" at me for some reason and imply that I cannot or didn't do a fresh install of MX, that's actually what's laughable, why would an MX developer have a problem to do a fresh install? Even more everybody can test if sysvinit-core is present on ISO or on their installation and it would be obvious who is the liar here. So... MX users if you are unsure do a dpkg -l sysv* both on live ISO or on your installed system and see who lies...
4. you seem to be an one-issue account that has a problem with systemd. That's fine, everybody has an opinion and an xxxxxxx, my problem begins is when you start to make false claims. I will continue to call you on your lies if you continue to spread them here.

You are lying, you stop lying then we take you seriously. Maybe you should start by retracting your false statements if you did them in good faith (which obviously I doubt)

Posted: **Thu Mar 14, 2019 3:11 am**

Get a life, read the posts someone already helped me solve this.
You are making a fool of yourself and I hate to see it.

Adrian wrote: Thu Mar 14, 2019 3:08 am You are lying, you stop lying then we take you seriously. Maybe you should start by retracting your false statements if you did them in good faith (which obviously I doubt)

Posted: **Thu Mar 14, 2019 3:16 am**

I havent used Fedora or Redhat for over 10 years and did not follow at all what they do.
I just used gnome applications if they were indispensable.
Did not expect this kind of subterfuge of init.

Poettering......., so thats the source of the trouble.
Dont bet on IBM continuing systemd, they have way way different interests than RedHat.
This might get interesting as the competing companies will jump to linux alternatives which might kickstart sysv development again.
https://www.cringely.com/2018/10/29/red ... -over-ibm/

Anyway you helped me a lot. I now know where the fish rots.
Thanks

asqwerth wrote: Thu Mar 14, 2019 2:54 am OK, so now we know how you got gnome onto your system. The way you did it probably caused your problems.
But if you are so against systemd, I'm rather surprised you would not know how interconnected with systemd the full gnome suite is. It's the red hat, poettering connection.
Not many people are going to compile gnome from scratch ; they would install binaries from Debian repos. And that can be done in mx without leading to removal of sysv or samba.

Posted: **Thu Mar 14, 2019 3:32 am**

It's the emacs vs. vi wars all over again.

Posted: **Thu Mar 14, 2019 3:43 am**

zimbodel wrote: Thu Mar 14, 2019 3:16 am I havent used Fedora or Redhat for over 10 years and did not follow at all what they do.
I just used gnome applications if they were indispensable.
Did not expect this kind of subterfuge of init.

Anyway you helped me a lot. I now know where the fish rots.
Thanks

asqwerth wrote: Thu Mar 14, 2019 2:54 am OK, so now we know how you got gnome onto your system. The way you did it probably caused your problems.
But if you are so against systemd, I'm rather surprised you would not know how interconnected with systemd the full gnome suite is. It's the red hat, poettering connection.
Not many people are going to compile gnome from scratch ; they would install binaries from Debian repos. And that can be done in mx without leading to removal of sysv or samba.

zimbodel, I do have to agree with Adrian that your initial claims that:

1) MX was running systemd by default (and thus that MX's statements about itself were wrong)
2) removing systemd would remove sysV and various other MX default packages
3) (another thread) that samba was not on your system by default and could not be installed

were not correct.

Like I said, I think how you installed gnome wholesale (and did not check what was being removed) caused the issues.

By default, sysV is definitely on the MX live and installed system, and systemd is not running. Samba is also preinstalled.

If you check MX Packageinstaller >> Popular Apps tab >> desktop environment category, you can install a base Gnome system without causing havoc to your system or changing the default init manager.

You may also want to read this thread about whether it's appropriate to use MX as a server: viewtopic.php?f=104&t=48337

From the thread discussion (although it isn't long), the conclusion appears to be that standard Debian kernels with lower frequency are more suited to server usage, while MX is optimised for desktop use with higher frequency kernel. However, samba is already set up.

Posted: **Thu Mar 14, 2019 9:42 am**

Topic closed pending mod discussion

MX Linux Forum

To systemd or not systemd - Ever wonder about it?

To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?

Re: To systemd or not systemd - Ever wonder about it?