Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I don't think any comparison between a MATE desktop and an XFCE4 desktop is going to be valid.
Going from Debian 7 XFCE4 (not systemd) to Debian 8 XFCE4 (systemd), I do notice the boot times are a lot faster, but I don't really care about that very much because I don't power cycle my machines all that often. The RAM usage is about the same either way. Basic day to day performance? I don't notice any difference.
In contrast, going from Debian 3.1 Sarge to Debian 4 Etch was a bigger pain for me. The RAM requirements for my tightest systems went up by just enough to keep me on Sarge for some of my most pathetic ancient computers - we're talking 32MB and 64MB machines. I haven't had a real problem with the transitions to Debian 5/6/7/8.
So far on this Ubuntu install systemd has been mostly benign. Mostly.
The problematic part is shutting down sometimes seems to take an indeterminate amount of time. And during this time, there's no feedback to me at all, just a black screen to stare at. I haven't really tried to diagnose what the issue is. Thing is, sometimes it *doesn't* do that and shuts down right away. That's unsettling.
I'm often highly critical of people who want to say that Linux is trying to be Windows, but today it sure seems like we've really nailed our own "Linux is shutting down" screen that may or may not take several minutes to actually shut down when we ask it.
So far on this Ubuntu install systemd has been mostly benign. Mostly.
The problematic part is shutting down sometimes seems to take an indeterminate amount of time. And during this time, there's no feedback to me at all, just a black screen to stare at. I haven't really tried to diagnose what the issue is. Thing is, sometimes it *doesn't* do that and shuts down right away. That's unsettling.
I'm often highly critical of people who want to say that Linux is trying to be Windows, but today it sure seems like we've really nailed our own "Linux is shutting down" screen that may or may not take several minutes to actually shut down when we ask it.
That is the random scheduling of shutdown processes. Something gets out of order sometimes hanging things.
Now, if you can identify what it is, and identify what it is depending on (and it may not be obvious), then you can add to the dependency list. That will force the ordering once you get it right.
This is part of the reason using dependency networks stopped being used back in the 70's/80's. The network is NOT easy to analyze, and adding a single node can gum up the works (most project tools moved into using Gant charts instead. Much simpler, and easier to present and analyze). The other part is that systemd isn't using one dependency net. It also has "requires", "wants", "before", "after"... making the network VERY complex.
Systemd is supposed to be for the most part out of the way.
However.. ->
When things crash, it refuses to honor a shutdown -r now as it says it's destructive. With no other options to turn off the computer (as the correct way to shutdown was failing and simply loading up X to a login screen again) I am forced to hard reboot (hold down the power button)
Looking at logs is more difficult. I'm instructed to run some kind of systemctl log service command something rather then just looking in /var/log/program or /var/log/syslog (the command provided has always had no output)
Making a startup process has become more confusing. I've yet to successfully get it to work reliably. Others may of had more success. Definitely not as simple as placing a script in /etc/init.d/ anymore..
I have a LUKS encrypted drive It's now fighting with me to provide a LUKS unlocking password multiple times during boot and after boot - despite successfully unlocking after I provide it once.
There's probably things good about it, but I'm wishing I could easily switch it out for sysinit. Which of course, is difficult and risky to do :\
systemd does NOT use exactly the same commands to function (ie as the former type of Linucks), and the underlying structure is different. Giving the impression (to newbs, pnewbs and beyond) that it is the same would NOT be correct. Especially not correct if they (newbs, pnewbs, etc) were sorting out difficulties, only to find existing solutions off the Net are not relevant. [In that (ie in that) it becomes ANOTHER level of irrelevancy to deal with.]
On several occasions, when I needed to do stuff at CLI level, I came across this problem of a whole new command set. (For example, to switch things on or off.)
I have been using Mageia-5/MATE which is systemd and is slick, and virtually unbreakable (on my config). On occasion, when I have had to go CLI, it is systemd.
I also use Antix-16/xfce, which is bi. [Well, sort of. I installed mine as non-systemd.] However, if I have to use that at CLI, the Net help I find often does not apply. It is annoying. [Please, no suggestions for me to move on. Antix works well too.]
To me, Mageia-5 seems to boot more slowly (which I believe is consistent with the systemd grab-all effect) and functions more slowly (which MIGHT be systemd related, although it could also be, in part, due to the xfce/MATE difference).
Herein, I am not complaining one way or t'other about systemd or sysVinit - EXCEPT - that they are different SETUPS. They serve the same purpose, but the functionality is different. Implying there is no difference, wouldn't be right.
I'm saying (some from experience, some from these posts, some from research the real differences are: need for additional MEMORY; faster CPU; probably extra Memory PLUS Speed; alt command-set knowledge; alt solutions; booting diffs; esoteric logging; removing easy manipulation from Users. [On that last point, compare it to (say): changing from old, simple, MECHANICAL, hands-on, DIY car-repairs - to - modern, computer-controlled, plasticized, NON-DIY, TAKE-IT-BACK-TO-THE-SHOP everything.]
(Mentioning any other practical diffs would be appreciated.)
While the OP (wormy is asking (I think), what difference it makes at a functional level for the User(s) - I think functional here also needs to include the part where you have to get your hands dirty at CLI. Then there are differences.
Of course, a supplementary question (which needs to be answered with clarity) is WHY did systemd happen?. Or, perhaps, WHY was it absolutely necessary to change Linux at the nuts-and-bolts level?. Explaining that (in brief laymans terms) would be nice for the understanding in this thread too. My conclusion, from a rather brief reading of political Linux history, was that kickstart (Ubuntu) may have kicked it off. Or is that too simple (or wrong)?
Regards,
some interesting thoughts here.
i, too, would like to hear answers to these questions.
There are a lot of errors in that article. SysVinit does do:
1. device activation is available with SysVinit
2. device dependency configuration with udev - well, it uses eudev which is NOT systemd dependent.
3. Automatic Service Dependency Handling - yes it does handle shutdown properly. Why should multiple services be shutdown for a restart of a single service? That can cause major interruption where it isn't called for.
4. Kills users Process at logout - as the system is designed. Init isn't supposed to, that is up to the user login. Problems are caused when this is done.
5. Swap Management? The kernel does that.
6. SELinux integration yes, that is handled. SELinux was developed well before systemd, and worked quite well.
7. Support for Encrypted HDD, yes that is handled - as encrypted disks were supported before systemd existed.
8. Static kernel module loading - has been working ever since kernel modules exists (about kernel 2.2)
9. GUI? Why.
10. List all the child processes. Linux has done that ever since it existed. If the parent process id is 1, then the process is a child.
11. Interactive booting? I was doing that around Linux kernel 1.1.
12. Portable to non x86: systemd has run on non x86 (at least I've seen it on ARM). What it ISN'T portable to is any other OS - such as BSD or UNIX, as it is deliberately non-portable
13. Parallel service startup - Of course sysVinit has parallel startup. Did somebody miss how wired terminals/console terminals are handled? Want to know why it isn't used for general system setup? It is unreliable - as is systemd (sometimes things get out of wack and the system hangs, currently usually during shutdown if a new service is added).
14. Resource limit per service - up to the service.
15. Automatic dependency calculation - yes, trivial and easily modified/extended (systemd is not)
16. Size 560 KB - yeah about right. systemd? Last time I looked it was about 20-30MB. The variation is due to parts of systemd having to be added to the services to get them to work (and makes those services dependent on systemd).
And one last thing - the log files are now trivially corruptible and made unusable (binary format).
I like systemD and I'll continue to use it untill its replaced by whatever's next.
like SysVinit
or
windows 95
compared to systemd windoze 95 is almost totaly bug free
the one and only time I ever tried it was in a usb drive
not only did it fail to boot it messed up my sd card
and erased the HDD from the boot menu in the BIOS
there is no way in hell
I will never let systemd anywhere close my computer
the developers of systemd should be fixing it's bugs
not expanding it's scope
I simply can not afford having systemd brick my computer
like it almost did
Of course, a supplementary question (which needs to be answered with clarity) is "WHY did systemd happen?". Or, perhaps, "WHY was it absolutely necessary to change Linux at the "nuts-and-bolts" level?". Explaining that (in brief laymans terms) would be nice for the understanding in this thread too. My conclusion, from a rather brief reading of "political" Linux history, was that kickstart (Ubuntu) may have kicked it off. Or is that too simple (or wrong)?
Regards,
most likely
it happemed because Linus Torvaulds (might be misspeled)refused to put a back door
in to the kernel so the U.S. government hired red hat to do it for them
this would go along way in explaining why it's so big and complex
I wonder if anybody has run a sniffer to look for back doors in systemd
Distribution: Mainly Devuan, antiX, & Void, with Tiny Core, Fatdog, & BSD thrown in.
Posts: 5,484
Rep:
As a first time or desktop user, I'd say it doesn't matter - that is, until something goes wrong - did you ever get to grips with a MS Windows Registry, if not you're looking at the same sort of added complexity if you have systemd.
I don't like it at all, & will avoid it - I will use a system that adheres to the unix way - even if I go over to BSD.
While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron.
systemd is an all-in-one solution that breaks Unix principle, i.e. it increases risks in terms of likeliness and severity.
I am awaiting the first "systemd shock"s already in 2017.
Security researcher Sebastian Krahmer has recently discovered that a previously known security flaw in the systemd project can be used for more than crashing a Linux distro but also to grant local attackers root access to the device.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
the real differences are: need for additional MEMORY; faster CPU; probably extra Memory PLUS Speed; alt command-set knowledge; alt solutions; booting diffs; esoteric logging; removing easy manipulation from Users. [On that last point, compare it to (say): changing from old, simple, MECHANICAL, hands-on, DIY car-repairs - to - modern, computer-controlled, plasticized, NON-DIY, TAKE-IT-BACK-TO-THE-SHOP everything.] 
