(untitled)

What's wrong with systemd again?

>>38504 For some reason whenever I use a systemD distro, my PC always reboots when i shut it down afterward. I have to hold the power button to prevent this. You should try out OpenRC. Works great so far.

>>38504 It's big and new and different and unavoidable and it's a burden being forced to learn a big new different thing when I don't even care about any of the new features it brings. Also everything I don't understand is a (((backdoor))) and anyone who shllls it is not smarter than me they're just jews running psyops.

>>38505 Have you checked in your logs to understand why instead of just giving up? I used to use OpenRC in the past on my Gentoo systems, but I later switched to systemd and never looked back.

>>38513 To be honest, I'm really not technically inclined enough to do that. I was able to suspend the PC just fine, so that's what I kept doing when using systemd distros. I first tried OpenRC when I used GhostBSD. I liked it and it seemed lighter than systemd, so I stuck with it.

I used systemd for a reasonable amount of time, and bluntly I just wasn't impressed. It didn't bring anything new to the table, but did introduce a lot of problems. Crashing during boot (unacceptable for any init, I'm sorry, but that is just trash), and sticking its fingers all over the system where it didn't belong. Also, you should take a look at news revolving around security holes, and take a look at the bug tracker (sort by oldest still open). It isn't pretty. (also, I found out recently from an acquaintance that a bug that existed and was causing serious problems for me ~10 years ago is still present and requires manual intervention to fix today...). Let's assume the software isn't crap, but unfortunately the developers are so full of themselves with their heads so far up their own asses, they actually believe they can dictate terms to the linux kernel (kid you not). However, that isn't the situation - they're arrogant, impossible to work with and think they can dictate terms. Hilarious, but also troubling for software with such a significant amount of buy in. Personally, I'll be sticking with OpenRC or literally any other system, at least until they reform their development and security practices. If you don't mind all of these things, then hey, go wild. >>38511 An exploitable surface isn't necessarily a backdoor. It's unfortunate that you need to resort to stupid non-arguments like this when there's plenty of valid reasons both for and against. >>38519 I like OpenRC because it is a simple, light, flexible tool that does what it is suppose to and doesn't force me to adopt a bunch of other software. I'm pretty inclined on customization and running a relatively minimal system, and systemd just doesn't allow for that. >>38513 I often found the logs to be profoundly unhelpful with debugging systemd. This may have changed though, so I cannot weigh in on good conscious today.

The fact that s6 is prettier, faster and better. But really, the problem is that it forcefully monopolizes the application environment and at the same time unjustifiably hampers other init systems by forcing people to put it as a dependency for anything and everything. If it wasn't buggy and untrustworthy, such situation wouldn't be a big problem, but unfortunately that's not the case.

>>38531 but but but, it isn't concurrent, in 2020

What happened to CentOS can happen to systemD. Too big of a project for an individual to pick up when Red Hat pull off the plug.

>>38532 If I can't multitask during the day without defaulting to first drinking some coffee, my OS should be free to do the same. And both me and s6 end up booting up faster than systemd that way.

>>38537 Hm... that's a good point, but systemd is a redhat project. I don't see them divesting it because it gives them a lot of influence in the linux world. CentOS was a derivative, and diluted red hat's market share, so it seems like their approach was calculated and intentional. >>38538 I think they were being sarcastic, but what you said is still true.

>>38540 I know they were being sarcastic. It wasn't an attack against them or anything like that.

>>38540 Think like a corporation for a second. Would you rather maintain with no charge, or charge a fee for software everyone depends?

>>38544 They already do this, that's their business model. Redhat is a billion dollar company. Hence, the CentOS situation. Now, as for systemd, look at what Google and Facebook do with all of their free offerings (license notwithstanding, gratis). Companies benefit from buy-in to your technology offerings, even if you don't receive direct financial compensation. So ya, you really should think like a corporation for a second.

>>38545 Not a contradiction with my post. But I guess is difficult to see the schemes corporations do to squeeze money. Is all fuzzy and suspicious until is blatant and too late.

>>38546 Agreed. You should always be suspicious of companies. They have wildly out of control powers and abilities that normal, actual people simply cannot hope to tap into.

>>38504 Youre letting a company wiggle in between hardware and your os making yourself dependent on them which will give them ultimatively power over you longterm same as windows holds the majority hostage by programs requiring windows. Letting any corp monopolize a critical part is flawed.

Related: anybody know of any operating systems looking to, or even just considering, move away from systemd? I saw one mention of such a thing not long ago, but I can't remember who or why or where...

>>38553 There are various projects that build linux distros with a systemd replacement. Not sure what you exactly want.

>>38582 They said >away from systemd. Not alternatives, projects that are detransitioning.

>>38583 I mean the guys running these alternatives are from the original project. Groups just split at systemd going popular into supporters and adversaries. If only projects collectively going back count then im of course missing the point.

>>38585 Sorry for the confusion. I meant literally moving away. Alternatives are ok, but I'm more interested in seeing if any projects are having buyer's remorse. That would be an indicator that people who work with the technology directly (those more competent than anybody in this thread) believe there are problems that cannot be overcome.

>>38520 >>It didn't bring anything new to the table It brought lots of new things to the table and improved upon existing concepts that weren't present in GNU/Linux. Socket activation, cgroup support, service slices and parallel startup are just some of them, and other inits still have to catch up (OpenRC developers officially discourage using PARALLEL=yes). >but did introduce a lot of problems. Crashing during boot Works on my machine. Was the problem displayed in the logs? >sticking its fingers all over the system where it didn't belong. Where doesn't it belong? systemd was never meant to be "just an init system", that's just FUD that was spread by haters. It's a suite of low-level userland components to manage the system and services (hence why components such as journald, logind, timesyncd, etc. which non-systemd systems usually must have anyway in the forms of additional software to achieve the same amount of functionality). Having all these components under one repo simplifies maintainance and actually makes the system more minimal and less redundant. Just take timers, for instance: additional support for them in systemd units is very small compared to what they already do, and they can fully replace cron, which has to have its own full blown bespoke parser and launcher. And let's be honest, nobody really likes cron job syntax. systemd, being an integrated suite, lets these individual components reuse shared code and functionality, making the overall system actually smaller.. >Also, you should take a look at news revolving around security holes, and take a look at the bug tracker (sort by oldest still open). You should take a look at bug reports for all software, then, including Linux itself. And let's not even mention that many "famous" bugs, such as the EFIvars bricking, was actually a Linux bug, which systemd was unjustly blamed for. Take it from the guy who actually wrote the code for it: https://twitter.com/mjg59/status/693494314941288448 >also, I found out recently from an acquaintance that a bug that existed and was causing serious problems for me ~10 years ago is still present and requires manual intervention to fix today... Which problem? Can you describe it further? >developers are so full of themselves with their heads so far up their own asses, they actually believe they can dictate terms to the linux kernel (kid you not) Userspace software inefitably influences kernel development, like it or not, to the point that Trovalds makes it very clear that all changes to Linux breaking userspace programs are kernel bugs, and they shouldn't blame others. Yes, they did try to incorporate kdbus (which even prominent Linux developers such as GKH promoted) but it was ultimately rejected. I disagree with their final decision, but I can understand why. To take another example, Wireguard was recently merged in the mainline Linux repository. Are the Wireguard developers assholes as well for "dictating terms to the Linux kernel"? >However, that isn't the situation - they're arrogant, impossible to work with and think they can dictate terms. Sorry, but that's how free software works. Contributors decide what direction software takes, non-contributors don't. Thousands of PRs have been accepted and merged, you could try submitting one too if you want to be heard.

>>38688 >Works on my machine. Was the problem displayed in the logs? I've also had severe problems, and no, they weren't in the logs. I ended up having to fix it blind, and no, nobody was around to help me since they all gave me the same non-advice you're trying to give this guy. A major problem with systemd is the developers like to say "works on my machine" while creating problems for people. This is well documented. >Where doesn't it belong? systemd was never meant to be "just an init system", that's just FUD that was spread by haters. No, false. The original project stated they wanted to make a basic init system. From there, they ballooned out into other areas. You can argue and try to retcon this all you want, but it is the unfortunate history. >was actually a Linux bug, which systemd was unjustly blamed for. >iT wAs LiNuX's fAuLt Don't cover for bad developers. >Userspace software inefitably influences kernel development, like it or not, to the point that Trovalds makes it very clear that all changes to Linux breaking userspace programs are kernel bugs, and they shouldn't blame others And hence why they rightfully reject systemd's buggery. >Are the Wireguard developers assholes as well for "dictating terms to the Linux kernel"? >These other people did get their way, does that make them assholes? Nice. >Sorry, but that's how free software works. Contributors decide what direction software takes, non-contributors don't. Thousands of PRs have been accepted and merged, you could try submitting one too if you want to be heard. You're making quite a presumptuous claim. No, PRs are not going to make a fuarrrking damn difference. The whole thing is a corporate project, and they dictate terms. Your contributions won't stand a rat's chance making a dent. It's pretty sad that systemd zealots need to resort to such bogus lying and bullshit to make their software look even remotely reasonable.

>>38716 >I've also had severe problems, and no, they weren't in the logs. I ended up having to fix it blind, and no, nobody was around to help me since they all gave me the same non-advice you're trying to give this guy. Ever wondered why? You, like most people complaining, haven't even given some more details as to what problems you had exactly. Just some non-falsifiable, non-reproducible claim like "it didn't work and it wasn't in the logs". What do you expect from people other than "works on my machine" if they can't even reproduce the bugs themselves and therefore help? >The original project stated they wanted to make a basic init system. No they didn't. systemd was always meant to be a larger suite. It's precisely claiming that it's "just an init system bro" and hence too big for being "just an init system bro" that is dishonest revisionism of the worst kind. >Don't cover for bad developers. Are you retarded or just stupid? The infamous firmware bricking bug, despite systemd getting sh1t on a lot, was actually, literally, not their fault. Do you even know how software development works? Do you even know anything besides sh!tposting on this dumpster fire? The job of a kernel is abstracting hardware. Linux failed at this. But somehow, it's systemd's fault. Remember Torvlads' mantra: we NEVER break userspace. Linux here did break userspace, hence it's at fault. >And hence why they rightfully reject systemd's buggery. Who is "they"? You know they cooperate every day, right? Ever looked at the mailing lists? Nobody is "rejecting" anyone here. >Nice. I can smell the buttmad for being called by double standards from here. >You're making quite a presumptuous claim. Sorry, but no. All free software projects, corporate or not, do work like this. You are just living in a fantasy. >No, PRs are not going to make a fuarrrking damn difference. Actually yes, they do. Whether they reject them or not is another story. But, as I said, no project is forced to accept any PR, they will only do so if it's actually beneficial. >The whole thing is a corporate project, and they dictate terms. Literally nothing wrong with this. https://youtu.be/radmjL5OIaA?t=1540 >Your contributions won't stand a rat's chance making a dent Maybe not, but it's irrelevant. Why should they anyway? And in the particular case of systemd, it has already hundreds of different people who have already made at least some significant contribution. The majority of the work is done by few developers, but this isn't a problem in itself. You are just dogmatically assuming it is. >bogus lying All my claims are true and verifiable, to the point that (You) got so buttblasted that you had to MoCk aNd CrY when you saw proof and hid behind a finger with this sorry excuse of "covering for bad developers". Basically, you don't know how software development works, you don't know what free software is about, and you don't have the slightest idea how systemd (and the rest of the overall GNU/Linux system) works. Nobody ITT managed to point out ONE technical flaw other than >nooooo i had problems, they weren't in the logs and those meanies didn't help me! whuaaaaa! For being obsessed about /g/, /Ω/ manages to be even worse.

>>38688 >systemd was never meant to be "just an init system" Then it's broken by design and will always be bad no matter how good the implementation becomes.

>>38531 >But really, the problem is that it forcefully monopolizes the application environment and at the same time unjustifiably hampers other init systems by forcing people to put it as a dependency for anything and everything. This pretty much sums it up. The fact that SystemD replaces simple shell scripts with direct C char pointer string parsing nonsense or that it's run by RedHat is secondary. Nobody wants to relearn the application environment because some code base coupled several unrelated applications together for developer convenience. I have no doubt with enough time SystemD will become decent, but it will kill the ability to experiment outside of it, make other projects redundant, and continue to cause massive knowledge churn for little benefit. It's a lot of change to get minuscule improvements at the cost of user space diversity. Does anyone really think there are any OS services SystemD developers will decide to leave alone? Why would anyone want a second layer on top of the kernel?

>>39567 Complete non sequitur. You already use the "bloat" provided by systemd in the form of cron, syslog, logrotate, xinetd, ntp, etc. The combination is also more bloated since it can't reuse common code and interfaces. If systemd is bloated, so is the entire concept of Unix (which is not an unfounded accusation). >>39569 You have to "relearn" nothing. Most end users aren't even aware of the init system or other low-level userland components. What particular software do you use that hard depends on systemd and forced you to "relearn" your entire workflow? Besides, if you people are so concerned with Red Hat, you should stop using Linux, since they are one of the main contributors. systemd is not special in being developed by large corporations, lots of free software is.

>>39573 >Complete non sequitur. Who cares? It's true.

>>39573 >You have to "relearn" nothing. Most end users aren't even aware of the init system or other low-level userland components. Most end users on Linux are also developers and system administrators or at least have to play at being a developer or system administrator. Most end users are aware of the init system and other low-level userland components.

>>39573 >The combination is also more bloated since it can't reuse common code and interfaces. Consolidating everything into a monolithic project will always reduce "bloat", but at the loss of redundancy, modularity, and autonomy. I have no doubt that SystemD can be made faster and lighter than existing systems, but it's the wrong trade off. Having cron, syslog, and ntp separate from the init system is worth more than any potential gain in efficiency. The bloat you complain about is the overhead of communication and project boundaries. Giving user applications control over the kernel would be much faster than having indirection through system calls, but is wrong for the same reason: centralized solutions are fragile maintenance nightmares. Centralization is synonymous with coupling. Knowing all this, why couple things together? Is it faster? Not in any qualitative way. Is it easier to use? Not in any quantitative way. Then why?

>>38504 >What's wrong with systemd again? It's a pragmatic corporate monster that invaded the cozy world of people who believe that Linux-based operating systems must be tinkerer-friendly, like Commodore 64. It also started as an init system, which made people wrongfully assume that it is an init system and should do just that, but systemd is a... system. If it was just an init system - it would be called systeminitd, not systemd. You can say that "Fedora is a systemd/Linux OS distributive". >>39578 >Knowing all this, why couple things together? Less organizational complexity: project becomes manageable, code base becomes more consistent, programmers who work on it can be less attached to a project that they work on and be more "systemd programmer who worked on..." than "The Creator and Keeper of a minor system utility".

>>39580 >It's a pragmatic corporate monster that invaded the cozy world of people who believe that Linux-based operating systems must be tinkerer-friendly, like Commodore 64. The monster is more myopic than pragmatic. Divided projects are better for everyone in the long run.

>>39573 >You already use the "bloat" provided by systemd in the form of cron, syslog, logrotate, xinetd, ntp, etc. So, what is the point of having both cron + systemd's "cron", syslog+systemd's logger, etc? The repetition is pointless. Also, if systemd wasn't meant to be "just an init system", I guess we have to start saying GNU+Systemd+Linux. At this point, some software is un-usable anyways if you aren't using systemd, so it has assisted with reducing portability. Wow, I didn't realize I hated systemd until you made me think about it. Hah. I don't use it, but that was just out of preference of openrc.. I never even really felt too strong about it before. Oh well, before I get too involved and waste more time finding reasons to see why I should hate it, I'm going to leave you with this: I'm not going to argue for openrc, it's just an initsys, I could use any other one and be fine. I just want to understand why you care so much more about this than anything else you could be doing in the world. I'm pretty interested in this mentality, and I would never care to ask in other communities because they tend to be really stupid... anyways, when you are about to die, are you going to remember this moment, when you came to bat for systemd? How much does it really matter?

>>38505 You have "Wake on LAN" enabled.

>>38504 lots of bugs >kernel panics >file corruption >300 years stop job on shutdown >actually restarts instead of "shutdown" >file corruption again >aggressive coredump causing severe corruption and hardware failure >you even had to turn it off manually because sane default https://wiki.archlinux.org/index.php/Core_dump >coredump of death if your DE crashes, again, filling up the drive to full (the size of your entire RAM dumped) and you just wake up with bad sectors from aggressive thrashing and overall failure. >>38505 this too.

>>38531 >forcefully monopolizes the application environment ... forcing people to put it as a dependency for anything and everything. I see this as a huge opportunity for a new wave of baby-tier linux rootkits that somehow are tailored for specific ring negative access applications and soykaffed motherboards/CPU all the while systemd being the needful bridge to that gap. Imagine, if some package dependent on such thing had a severe fontconfig or imagemagick bug, a series of overflows plus a sandbox bypass if it has one. Definitely not the best scenario with a really "modernized" soykaf init system that does and has something that it shouldn't have in the first place. Future of linux is bleak.

>>38504 The government forced people to use it and it's bloatware. Pretty sure.

>>38504 Since the release of systemd in 2010 the project has been getting a continuous and steady stream of new features and added capabilities, and with a code count of more than 1.3 million lines of code, where Lennart Poettering has just added yet another 20.000 new lines of code with the merge of his personal systemd-homed git tree into systemd, and with a continuous open issue counter at about 1.400 issues, where new issues keep popping up, systemd should be considered experimental and not safe to run anywhere. Considering how systemd is being developed where the code hasn't even undergone (as far as I know) a single code audit, and the developers keep adding new features instead of focusing on bugs, security, and stability, the project doesn't belong in any GNU/Linux distribution except as in a "testing stage", and any kind of GNU/Linux distribution with systemd is not suited as a production system if security matters. Even Debian GNU/Linux, with its extended testing in its "testing" and "unstable" releases, before anything goes into the "stable" release, isn't suited for production because systemd still has many open issues and even open bugs dating back all the way to 2015. The GNU/Linux many of us know so well, is slowly turning into a disaster, an operating system apocalypse of security issues just waiting to happen. Just because everyone wanted a new init system, but somehow ended up with everything but a new kernel.

>>38531 based s6 and obarun

>>39682 The main problem with systemd is that its continued development is motivated by a company's economic interests and not the Open Source Linux community interests. As time goes by more and more "issues" will most likely pop-up and the other major Linux distributions will possibly regret the integration and adoption of systemd into their projects. Not because of systemd as an init system in itself, systemd init is pretty good and Lennart Poettering and Co. have contributed and implemented some great features. What I mean by "issues" is not the software bugs, but the way user concerns, privacy concerns, and other important security issues are dealt with by Lennart Poettering and Co.

>>38504 It violates the unix philosophy

Just use emacs from the bootloader

>>40265 GNU is not Unix

>>40266 >ring 0 emacs Of course! Do you take me for a coward?

>>40265 Maybe you should consider that the 'Unix philosophy' isn't so great in the first place.

>>38505 >distro What crappy distro are you running?

>>40265 I wish I could start systemd services by doing echo enable > /proc/services/blah

>>38504 systemd just keeps filling my system storage with corrupted logs and I have to delete all the logs manually to free up space also when I press my shutdown button it just throws an error message (I have checked ACPI settings) so I have to keep my button held everytime to close my pc switched to openrc and I have 0 problems and it boots up faster never looked back since