Bob doesn't write a specification, because Bob doesn't know as well what he wants. He will have to explore, try out until he reaches something that he can work with. Nobody is willing to spend time planning and documenting stuff. Everyone feels one youtube away from being expert in software development.
Like guns for civilians. Nobody should have one, except the Politician body guard.. I am not advocating for guns in Europe! it is just an example. We can use the example with private health insurance, private schools and so on.. it is more like to exemplify the "Do what I say, don't do what I do" kind of politics
Except that civilians CAN have guns, they just need - just like police and military - a background check, training, certifications and permits. Police and military can't take their guns home, anyway. On paper.
How many? Can you list some of them? I think that your assumptions are kind of the general opinion, but I am interested in facts. I couldn't find "many unpopular laws being passed during such events", can you?
- summer 2017, a law to limit demonstrations and strikes.
-summer 2020: LPR, that incite scientist to shut up, and limit their autonomy while strengthening administrative power over them (students tends to protest laws like this).
But usually, how you do it: you make a 'protect the children' law, or a 'counter terrorist' law, and you expend it's reach with executive power, that how Macron does it. Is it authoritarian? Yes.
> Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs.
This is a general "back in the days always was better" answer. Fact is that along the years systemd had less than 50 CVEs published, it reinvented for good the whole initialization process and linux administration in general, and together with SELinux are great foundation for any modern Linux distribution. Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.
When there's a CVE in a program written in a memory-unsafe language that has a position of privilege in your security model, that's a much much bigger deal than if there's a poorly written bash script running as a user.
Seperate out your service manager from your pid1, pid1 needs to just be responsible for reaping orphan processes. If you're going to have a monolithic daemon in that privileged position at least write it in a memory-safe language, as that's where most of the nasty RCE vulns come from.
I do have bunch of servers on Centos 7, which is quite old and have met just couple of minor issues related to systemd, never had a downtime because of it. I'd say NOC doing some networking maintenance brings me more problems then systemd.
> but systemd is just the evolution that Linux needed to become what it is today.
Not at all. The linux of today doesn't owe anything to systemd, is not radically different from when systemd didn't exist, and arguably we would have a better alternative if systemd had never been adopted.
> arguably we would have a better alternative if systemd had never been adopted.
Not true. We have many alternatives, adopted in some distros. But AFAIK no Enterprise distro. For servers or desktop.. why?
because systemd starts as many services as possible in parallel this speeds the overall startup and gets the host system to a login screen or reduce the server downtime dramatically than SystemV. That is for sure a well wanted characteristics today...
Sure RC was super simple, but systemd is just the evolution that Linux needed to become what it is today.
At this, I just vomited a little in my mouth.
Linux owes nothing to systemd. In every measurable way, systemd adds more complexity, reduces security by expanding the vulnerability footprint, creates a monolithic ecosystem, and handles everything far worse than, for example, Debian's use of sysvinit.
I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems.
> I spend more time dealing with systemd edge cases, and bugs, and security issues every few months, than I did in 30 years of other init systems.
It's been the same situation for me, too.
Every time I get stuck dealing with a new systemd-related problem and search online for solutions, the huge number of bug reports, mailing list posts, forum posts, IRC logs, and other communications I incidentally see describing my problem and/or other troubles involving systemd remind me that I'm not alone. Many other people are consistently having a wide variety of problems with it, too, and this has now been going on for years and years.
Systemd has driven me to move systemd-using Linux systems I end up responsible for over to FreeBSD or OpenBSD whenever possible. Their init systems aren't perfect, but they almost never cause me problems. In the very rare cases when they aren't working for some reason, at least those systems are simple enough that I can usually debug the issue on my own, without having to search for help online.
Can you describe one of your problems? I've had very smooth sailing with systemd and I like not having to play games with pid files and pgrep like I had to in the 90s.
I can't speak for VancouverMan, but my experience has been similar. A few examples of the problems I have with systemd:
System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.
Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope -p "Delegate=yes" <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.
At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.
There are more examples, but I'm tired of re-living them and don't really want to write a book.
> Systemd has driven me to move systemd-using Linux systems I end up responsible for over to FreeBSD or OpenBSD whenever possible.
Nice that you privately do it privately. In Enterprise environment however is different, and systemd played an important role in having Linux reaching that level.
It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost.
Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community.
I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd.
Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange.
The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible.
We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited?
I personally cannot wait for another, better, init system to come out and replace systemd.
Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.
> Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. ... We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited?
systemd was pretty consciously patterned after launchd, not svchost. The goal was, and for good reasons, to make Linux behave like a more integrated Unix-like that already existed: MacOS.
Benno Rice has an excellent presentation on systemd that's worth watching through to the end; unlike most of the table-pounding (and "it's just svchost.exe!!" is exactly that), he provides what I think is a pretty fair--and, interestingly to me, a BSD-grounded--view as to where systemd is strong and is weak. https://www.youtube.com/watch?v=o_AIw9bGogo
The thing is, I own a mac, and I've never had to touch launchd.
I've hit severe systemd bugs on 100% of the linux desktop installs I've set up in the last 5-10 years. (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on).
The fact that pid 1 can even be involved in those sorts of userspace bugs shows how broken the architecture is.
> (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on).
I used to be release manager for a Linux distro. Mostly, such issues were integration problem and not a systemd problem. In some cases that I worked on, the integration wasnt well-thought, or it was done in some amateurish way which needed actually some extra hours of professional software development to make it "production ready". Unfortunately part of the process of working with open source.
This is one of the downsides of systemd from a community perspective--it's not that it doesn't work; it largely has, and has consistently, for most people and most distros who've adopted it pretty much since the jump! But the bonkers level of partisan poo-flinging by folks who will not simply go off to Devuan or whatever has inculcated an automatic assumption that a system built by some of the most talented folks working in the Linux space simply has to be broken whenever they have a problem.
By being ambitious, systemd brought it on itself, but it's frustrating because the conversations don't go anywhere and don't matter.
Take a look at S6 and dinit. They both embody what systemd was intended to be while keeping the portability, technical simplicity and loose coupling.
You might also want to consider Void and Chimera. Void has a unique combination of technical simplicity, functionality, rolling updates and low maintenance along with some beefy repos. It's close to being the perfect desktop Linux to me.
Chimera uses dinit, which is closer to systemd's features, whereas Void uses runit, with is more of a minimal viable init + rc.
They are very interesting for sure, but I'm waiting for the S6 successor that's in development before I switch from systemd. There are a number of things systemd offers that are either easier, better, or unavailable in other tools that keep me happy for now. If the successor ends up being good but still missing those features, I'll try my hand at implementing them for the greater good.
Are you referring to svchost.exe, the performance hack that allows multiple Microsoft-supplied services to share a single process, or the Service Control Manager[1], the Windows component responsible for starting and stopping Windows services?
If the former, I agree that trading off service process isolation for reduced start time and lower resource usage is an optimization that has probably outlived its usefulness and should not be emulated on systems that aren't severely resource-constrained.
While systemd arguably bundles too much functionality into its own process, AFAIK it doesn't include any mechanisms to support svchost.exe-like behavior in services it controls.
If the latter, I'd argue that the SCM is actually quite minimalistic, especially in comparison with systemd: it's responsible for starting services in the correct order per a supplied list of dependencies, restarting failed services, notifying services of important lifecycle events — service configuration changes, shutdown requests, network interface status changes, etc. — and that's about it.
I think you underestimate the cost involved of creating and supporting something more than barebones.
Building a barebones platform for people who are largely self sufficient is cheap. Building a full fat platform for people who need more hand holding, is a bit more costly.
- In Hotel, Airport. VPN can be used to bypass DNS based captive portal.
- Yes true hopefully all website are encrypted with ssl, but still an attacker can easily fingerprint me through my internet usage, even though everything is ssl, there are still a lot of plain-text data flying around. So yeah, ProtonVPN, ftw.
I care, and my feeling is that more people do each day as they become aware of how tracked they are. Why does anyone need to know anything about me - it feels like a violation. There are all sorts of possible costs to that, but I think many of us value privacy on its own.
But as for an attacker - maybe they discover something about you from one compromised service and correlate it to something else. Or maybe they extort you in some way. Who knows - there are many possibilities and it’s safer to reduce exposure.
> In the Nordics, we have a couple of sites dedicated to fact checking news stories, done by real people.
We have it everywhere. The problem is however well-known: Human bias, political engagement from the fact checkers, etc.. AI (without any kind of lock, political bias built-in etc) could be the real deal, but because it may be not political correct, it will never happen.
