I like it because I had found a tons of subtle issues over time with some of the scripts that were "simple" and system default of "just put it in ExecStart and set user" mitigates many of those.
For example:
Java app that gets put to background before it writes PID (which takes some startup time). In result running status right after start will say that app is stopped. Pacemaker didn't liked it and freaked out. Not only Java problem but start exacerbated it
MySQL disto package (Hi Red Hat) that didn't put PID into temporary partition, nor checked whether PID there is one running mysql so after reboot there was an edge case where "old" pid that's still in old file after crash was used by new app, mysql didn't start coz "simple" sysv script thought it's already running
Then there is dependencies that make a lot more cases simple like "start the service to get the encryption keys before you try to mount the encrypted volume" is just few deps, not modifying any code, and auto restart removed our use of monit
I do dislike the vast suite of stuff that worked fine before that comes with it and journald design is a bit shit, especially disk format (still have bug open when running status on app can take tens of seconds on spinning rust, why they just didn't use SQLite and indexes...) but overall, without exaggerating, it allowed us to remove tens of thousands f lines of code of "simple" sysv stuff that needed to be fixed.
Systemd has admittedly grown on me, in the sense that the pros have begun to outweigh the cons, when divided by the amount of time since I began using it, multiplied by the amount of time I'll likely still be using it.
Homed might take another decade or so. Gives me the goosebumps on my arms just speaking about it.
Not suggesting you are (were) a systemd hater, but all the systemd haters might find that systemd is actually damn awesome if they stopped their hating and learned about it.
Here's an instant tasty systemd tip that I used yesterday ..... I had to prevent a forward proxy server from accessing local networks. How do you solve this without systemd? Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide.
Or, you pull out systemd and get the job done by application IP address restrictions on a per application / service level:
[Unit]
Description=glider service
After=multi-user.target
[Install]
WantedBy=multi-user.target
[Service]
IPAddressDeny=localhost
IPAddressDeny=169.254.0.0/16
IPAddressDeny=192.168.0.0/16
IPAddressDeny=198.18.0.0/15
IPAddressDeny=172.16.0.0/12
IPAddressDeny=100.64.0.0/10
IPAddressDeny=10.0.0.0/8
ExecStart=<proxy command line goes here>
systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere.
systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves.
If the title GNU/Linux makes sense (which I don't think it does), then systemd/Linux makes much more sense.
If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."
I have been pretty vocally opposed to systemd's gradual takeover of core Linux systems that I was previously familiar with, but it's clearly not going away and I'm gradually getting up to speed on it. In your example, I'm super comfortable with iptables and it would probably take me less time to solve it there than it would to discover that a systemd service could have ip address filters added to its unit file.
When people say "just read its documentation" ... that seems really dismissive of both the volume and the inconsistent quality of it. I spent hours about a week ago working on a single service file for an encfs mount (not a mount unit, which is a different thing, which I also spent hours reading documentation on!). Ultimately it was only through trial-and-error that I discovered that it would only work with "Type=forking". The systemd docs do a fine job of describing the different "Type" values and how they matter to systemd, but don't fill in the blanks that certain things require certain Type values.
Most of my interactions with systemd have required time with its documentation. It's fiddly and quirky and not a big improvement over historical tooling in that respect.
But I recognize that it is capable of doing some things better than the old tooling could, and it's not gonna go away, so it'll just be another volume of arcana to memorize and I should get to it.
> As a systemd hater, I have to say that I like the systemd approach here better than messing with iptables. The locality of behavior is nice.
Until someone new comes along and is not aware of this seemingly obscure feature and can't figure why traffic is not getting to the app: nothing in iptables, tcpdump shows the packets getting to the system… WTF?
Looking at a service's systemd unit file would be the last place I would think for network filtering configuration.
Or does systemd place the appropriate lines into iptables (or nftables nowadays) on your behalf?
Nah, I'm still passed off about nspawn. Broke chroots for me in some embedded linux contexts, well the fact that you have to use nspawn in order to launch systemd services.
You are correct. Systemd is not necessarily easy, but that because it is surfacing the power of linux and many of the concepts take some learning. Or you probably already know the concepts but do not yet know how or where systemd brings them out.
It’s worth reading as much as you can stomach of the systemd documentation.
Even if you’re just skimming over it, you’ll pick up useful things for the future.
Like socket activation, file change activation, timers, nspawn and lots of other good stuff.
You might even come to like it. Or at least forgive its sins.
> Well you have to start fiddling with iptables and descend into that level of hell wherein you are fundamentally fiddling with stuff you do not want to fiddle with, and beside that solution is going to be system wide.
This is just a really strange and depressing-to-hear stance, as you seem to simultaneously be claiming that it is worthwhile to read the documentation for systemd to learn about all of its one-off solutions but somehow NOT worthwhile to read the documentation for the actual Linux IP stack?
> systemd is chock full of super awesome stuff like this if you read the docs you'll find simple solutions to challenging problems everywhere.
Honestly, this just sounds horrible... this sounds like a project that has a million tiny one-off "simple solutions" to individual "challenging problems" instead of providing a generic tool that can be integrated with other generic tools to solve arbitrary problems in infinite combinations.
> systemd is a beautiful, integrated work of art, and there's constant payoffs and benefits from the fact that it encompasses so much functionality previously split across a huge range of inconsistent small solutions to the various problems systemd solves.
And so like, here is just where I guess there's a philosophy problem at play: those "inconsistent" solutions were just combinations of separate components. To me, that's beautiful... and it's beautiful, in no small part, because it was NOT "integrated", and was instead extensible and transparent.
> If Linux had started off with systemd and someone came along and said "better idea, lets tear systemd apart into a wide range of tiny applications all with different approaches, syntaxes, maintainers and functionality, with no overarching architecural approach and call it sysV", everyone would say "what a crazy idea, no thanks."
Really? You seriously don't see any benefit to taking a monolithic framework and breaking it apart into a ton of libraries? Yes: there are people out there who like the large monolithic opinionated frameworks... but there are also a lot of people who prefer having a toolkit of libraries.
In particular, when we see this debate show up in other places, a big benefit of the "lots of libraries" approach is that it is an inclusive and extensible way of approaching a complex problem, where if you have an idea that you think makes the world better you can just work on that part.
And so when someone is working on new network addressing or new ways of doing hypervisor-assisted sandboxing or new ways of managing user accounts, some of us would like to think that the mechanism for "run a bunch of stuff when the system boots" doesn't have to understand any of that.
When you have a single program that has decided to form a giant knot in the space of solutions--where to solve anything you feel like you can't just add another library but you have to go modify the big central framework--you stifle a lot of participation and narrow the set of options.
And that's where I feel like you are just going to say "that's great! I don't like options! I'd prefer someone else not only solve my problems but tell me what my problems are in the first place" and again: that's where this becomes a big philosophical argument instead of a technical one.
So like, do I have technical issues with systemd? I mean, yes: I'm sick of being burned by this "journald" issue--one which has been open over a decade now and will probably never get fixed--because as far as I'm concerned if you build a logging system and you routinely lose log messages you probably aren't qualified to develop a logging system.
But, at the end of the day, the reason that systemd makes me sad is because when I started doing system administration the entire community was firmly in the "we should strive to have a lot of separate tools that can be composed in fun ways" camp, and now it seems like the reins have been taken by the "you shouldn't know or care how things are put together: let me solve it for you" camp, and that makes me nigh-unto existentially sad about the state of computing. :(
(And like, I want to be clear: normally, I just don't care that much?... I went into my past HN comments to find the link to that journald issue, and it seems like meekly asking after that specific bug is the only time I've ever even commented about systemd... I've always just figured it's yet another annoying change that maybe I'll have to get used to, from the ever-increasing essential complexity people like to foist on us every year; but then I see your comment here, and it is just SO SAD to see that it seems like you don't even consider it a depressing tradeoff but seem to actually WANT IT and I'm just like "ugh".)
>from the ever-increasing essential complexity people like to foist on us every year
From my perspective, the Jedi are evil.
I think I understand and sympathize with how you feel, but, from my perspective: read the man page this thread links to. Look at the (what is to a relative Linux newcomer like me) extreme, byzantine complexity of best practices you should follow to make a traditional daemon. I've made systemd ("new-style") daemons already, but I still don't have the know-how to make a traditional daemon; 85% of the terms in that list are still mysterious to me. And, after all that investment, I'd have something that's more difficult to operate and less cross-platform across distros.
To someone focusing on the UX they have to deal with, that's complexity, while systemd represents "simplicity".
It's complicated, of course. The externalities of convenience and centralization are problems, if rather ethereal ones.
Rational actors don't often incur tangible pain for ethereal gains, though. In tangible terms, centralization is simplicity (compare SVN...); decentralization is bought with complexity (...with git). And it shouldn't be surprising that people want to be able to do things in the most painless way possible (especially when the deltas of tangible pain are so huge).
After a bit of digging, this article (2020) has a very clear and open-minded discussion of the whole systemd and System V etc. issue. The author notes that the init system is tightly interwoven with the Linux distro and isn't sanely swappable, and the more popular distros are all systemd, which makes some people unhappy.
One problem I'm having is that learning to manage sockets with systemd, with good security practices implemented (i.e. not toy examples) is an area where there's not a whole lot of accessible information, however. I've been using Beej's Guide to Network Programming Using Internet Sockets (C), which seems to be a more general approach.
At want point to do you accept you’ll have to buy into _some_ vendor lock-in? Should you always program in a way that ensures your application will function a Zaurus running OpenBSD?
> At want point to do you accept you’ll have to buy into _some_ vendor lock-in?
If I wanted that, I'd go back to Windows. Well. Maybe Apple. Either way, I wouldn't be here.
> Should you always program in a way that ensures your application will function a Zaurus running OpenBSD?
Preferably? Like, your framing makes me think that you think that's somehow extreme, but... unironically yes, if your program wouldn't run on OpenBSD on a Zaurus you should seriously sit down and consider why and whether that's really how it should be. And there are valid reasons to decide "no" (ML needing really high performance can justify hardware lock-in, cutting-edge development on things like DPDK could justify needing a specific kernel, I guess needing very specific features and not having the developer-hours could justify using systemd features), but 90% of software should absolutely 100% work on any of FreeBSD/NetBSD/OpenBSD/Debian Linux/Alpine Linux/Gentoo/Fedora/whatever on any of x86/x86_64/aarch64/mipsel/riscv/whatever
It’s clear that you’re upset at systemd, but what you said here doesn’t really scan if you actually read the document. Everything you could describe as “lock in” has a conditional statement clearly making it optional. The document barely even covers the extensive motivations for features it discusses, which I would expect if it was really propaganda.
If you implement a daemon in the new style documented here, and skip 5,7,8,9 - all optional, then the outcome is more portable than one following the sysv list (just doing the sysv list correctly for Linux and a BSD is a quite large burden due to differences). If you follow the Unix purist notion that this should all be composed of commands then all of the other sysv tasks could be handled by wrapper programs - you can also best use the new style. That’s mostly what using daemontools feels like, and it works pretty well, but boy is it a mess in the process tree and require a ton of boilerplate.
systemd v SysVinit was a war between developers and admins. admins don't reboot, so the advantage of faster booting, which is the prime reason for systemd development, is silly and unnecessary from the perspective of professionals that do not reboot their machines. Nor do admins care about laptops, unlike developers who are obsessed with them and can't function without them for more than a minute at a time, give or take, thus their need for their reboots to be as instant as possible.
systemd, being complex and not written in Bash, was always the antithesis of UNIX philosophy. It keeps getting more and more complex as it creeps ahead adding features, taking over more and more of the system. systemd won the war because developers held all the cards, and admins, being cautious and overly concerned that systems remain stable and resilient, are slow to react. Inexplicably, admins will not do anything to fix something that was never broken in the first place, while developers, without restraint, are forever changing things to make them "better."
Mercifully, there is still some rock solid BSD around which by and large Linux replaced in a way similar to how systemd replaced init, primarily because of making faster-booting a priority, because developers don't want to wait around while they are constantly rebooting their laptops, but also a fanatical verve and the entitlement that it would be more comfortable for developers if the datacenter at their day job ran the hobby OS on their constantly rebooting laptops. It was a very one-sided battle of young developers against sleepy greying UNIX admins and neckbeard engineers that were hardly aware of what was happening and were retiring soon anyway.
But as it turns out, systemd only conquered so much territory and was some how stopped before assimilating every single Linux distribution.[1]
As a sometimes-administrator of Linux systems, I have lots of reasons for finding setting up, altering, and reasoning about various daemons to be all much better and less error-prone in a systemd world.
It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times. I also barely ever reboot my system but still appreciate systemd's approaches to things like logging, service status, and service overridability.
> It also seems a bit of a straw man to still be making the pro-systemd side as if it's mostly about boot times.
It couldn't possibly be a straw man because I didn't disagree with the OP nor did I bother misstating his argument (flagged due to pretentiousness but not his own) in order to attack it. It is simply a fact that fast boot was the prime reason for systemd development. The most fundamental goal of the developers' was to increase efficiency with parallel service startup to achieve fast boot. Everything else may be considered feature creep, and without the feature creep, there would have been less criticism and resistance, as faster boot in and of itself isn't necessarily terrible. What is terrible is complexity and increasing complexity, as it will necessarily introduce fragility the more complex it becomes.
For the record, if it wasn't obvious, my post was tongue-in-cheek and supposed to be funny in using false stereotypes to poke fun at developers, whom, of course, I respect immensely, yet by and large they can be a little sensitive sometimes, especially to any criticism of Linux or anything Linux does. There are valid views from all sides, and tribalism is usually not a good thing, yet humility and tolerance are virtues. If developers can't laugh at themselves, I can do it for them in hopes of dragging them along, kicking and screaming if need be.
A lot of those things don't use plain bash either... Of that bigger things in that list:
There is OpenWRT, which uses "procd" (a process management daemon written in C, like systemd but smaller) with its own system bus ubus (like dbus but smaller)
There is Android with its own proprietary init system.
And many others use OpenRC, which is 65% C and 30% shell (according to github). the init files do use shell syntax, but you are supposed to use their interpreter [0] "if you insist on using #!/bin/sh you're on your own" [0]. In fact, the recommended approach is declarative method when you specify name of main binary and their args.. just like systemd.
> The world is moving and sysvinit is left behind.
Contrary to the popular belief in your microcosm, the world did not adopt systemd. Android, Knoppix, Slackware, among dozens of other distros, rejected systemd. macOS uses launchd, which inspired systemd, yet launchd is generally more unix-like in that it assumes a daemon knows what's best for itself, and doesn't make decisions for it, nor is launchd aggressively annexing Darwin. Oracle Solaris, Illumos and variants use SMF of which sysvinit is likely a dependency, while NetBSD, FreeBSD and OpenBSD use rc, a BSD-style init also of which sysvinit is likely a dependency. Though Linux replaced a lot of BSD installations in the last decade, like systemd has replaced sysvinit in a lot of distros, the decision to do so was arbitrary and without compelling advantage or reason, and apparently mostly due to fanatical devotion. BSD, fwiw, isn't going away, and in various implementation, neither is init.
Did you notice I haven't mention systemd in my comment at all? And other than this first sentence, I am not going to mention it in this comment at all.
The important thing is not who won, but the fact that the idea of writing init scripts in bash/sh has lost. Almost no one wants to maintain yet another incomplete or buggy shell script implementating of "start", "stop" and "status" commands. It is declarative way now - somehow define the command, arguments, user etc.. and let init system handle start/stop.
(Yes, there are still ancient systems like Slackware which use plain bash and have no plans to change. But even FreeBSD is pushing toward declarive: look at [0], does this look like a simple shell script which makes it cleat what's going on?)
That's why the people who advocate sysvinit get so little support. Try advocating for runit or daemontools or launchd or openrc or even SMF ( :) ), this will get you further.
> the advantage of faster booting, which is the prime reason for systemd development
It was more of a side effect, rather than being a primary reason. Good design and utilizing dependency resolution and parallelization led to it also happening to be faster.
Faster boot was most certainly not a side-effect but instead it was the inspiration and drive behind systemd development. The prime goal of the original developers in parallel initializations was more efficient processing so booting would be fast. If anything, the design was a side-effect of the faster boot agenda, not the other way around.
> Nobody happens across good design as a side-effect of going fast.
Straw man. What I argued, and what is the case, is that the developers wanted faster boot; that was the motivational spark behind systemd, not good design. The design followed in order to achieve the faster boot, thus the design can be seen as a side-effect of the faster boot agenda.
The subject of speed is dominant in the document you cited: "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast.... For a fast and efficient boot-up two things are crucial... and hence the overall start-up time minimized." It is obsessed with boot time. As I stated, that is the foundational goal of systemd, reducing the time it takes to reboot.
sysadmins should reboot to update kernels, but even if you want to avoid reboots you still need to correctly and reliably update a tree of dependent services periodically in order to apply security updates.
There is such a thing as live patching a kernel without rebooting. Whatever it is that you think you need to reboot because of, it would always be better if you did not need to, because uptime and constant and consistent availability of services is virtuous.
That's true, but that only reinforces what I'm saying. Lets say you have a working kexec setup so you never need to reboot, that is very likely to increase the need for you to be able to robustly restart trees of dependent services in userspace.
Stateless systems aren't difficult. The load balancer need not route to nodes with updating services. It is possible to design code that can update without restarts, but few developers are industrious enough to make it a priority. Evidently, the trickier and more difficult a specification is, the less likely a developer is enthusiastic about providing it.[1]
The first part of the document highlights the absurdity of the old way. Is there anything in that long long part of the document you think is unreasonable?
Whatever systemd suggests, the old way looks byzantine as heck & not fun & elaborate, to me.
"Modern daemons should follow a SIMPLER yet more powerful scheme" LOL. I don't mind systemd in turnkey consumer products like chromebooks or in enterprise. Maybe it's faster or complexity is necessary to do complex/failsafe things etc. But for me the point of Linux is being able to understand and customize how everything works. Which is not necessarily purely education and impractical. Maybe I have something tangibly useful to myself hooked up to Raspberry Pi GPIO pins and want to control it with a little custom daemon. A shell script with start and stop commands is all the time I have to spare rather than learning all the red tape that may be appropriate for complex software.
> But for me the point of Linux is being able to understand and customize how everything works.
I have always thought that is a valuable feature of a Linux system, too. That being said, I’ve also contemplated init scripts and wondered how that could possibly work. And, as anyone who has troubleshooted a stale daemon subprocess, a malfunctioning pidfile, or a messed up rc symlink can attest, legacy init scripts do not actually function very well.
Systemd may be far from perfect, but it’s a vast improvement over initscripts.
We literally removed ~10k lines of code that was just dealing with sysv init scripts bugs when moving to systemd. I have few issues with systemd but benefits far outweight the cons
That’s kinda the point, just run your process with no regard to daemonizing, write to stdout, stderr, crash normally with panics, don’t bother forking, don’t clean up fds, don’t think at all about privs, what’s a pid file?, what’s /dev/log?, what’s a scheduler?, and let systemd do all of this correctly for all services regardless of how well written they are.
My foo-daemon needs some arguments and several steps to shutdown while saving its work. Like maybe kill -HUP, wait 10 seconds and then kill -9. Any suggestions that would be obvious to me without always having you for one-on-one consultation? Rare cases where saving work is not complete after 10 seconds are acceptable for my use case.
You can find this doc by typing "systemd.service" into your favorite search engine.
The title I link to is the simple case example, which explains just below the content sample that it has pretty much the behavior you want:
Since no ExecStop= was specified, systemd will send SIGTERM to all processes
started from this service, and after a timeout also SIGKILL. This behavior can
be modified, see systemd.kill(5) for details.
Per this, you can either implement SIGTERM rather than SIGHUP, or you can change the stop signal. It already has a generous shutdown timeout (on one of my systems where I have a similarly simple unit, it's defaulted to 1m30s). You can change the timeout by setting https://www.freedesktop.org/software/systemd/man/systemd.ser...
If your daemon needs kill -9 you fucked up but even then you can just set "stop timeout" and your demon will get the termination signal, and kill after that interval.
More crude option is putting all of the custom stop behaviour in ExecStop script
At this point it feels that systemd has also grown its group of fans that try to silence any opposition, and the colour of your post is surely evidence.
Personally, I don't really care either way. I am more comfortable with sysv init because I used it far longer, and I can rock out with some shell, but systemd seems to work okay on any decently modern system.
My real issue is that Microsoft is now pushing toward TPM being required in Linux, they fund the Linux foundation and kernel development, they employ Lennart (afaik), and this feels very very much like their old "embrace, extend, extinguish" modus operandi. It also screams of the Halloween documents where Microsoft talked about needing to kill off open protocols.
Now, it's given that sysv is still around and could be used (is used by some distros still) in the event that systemd takes a bad road, but given how much stuff has become dependent upon it, that may not be easy. Likewise the code base of systemd has grown quite large so a fork would carry a very large maintenance burden.
> Microsoft is now pushing toward TPM being required in Linux
Oh? I think you may be reading too much into what Microsoft has actually done here. How exactly could a TPM be required for Linux?
> It also screams of the Halloween documents where Microsoft talked about needing to kill off open protocols.
Wow this is a blast from the past! Almost twenty five years ago! I think it's fine to not like Windows (yep), even hate (somewhat irrationally, sure) Microsoft for the company they were, but a generation has passed since 1998. Maybe its time to find some new material.
AFAIK the requirement only applies to Windows? And hardware vendors care about working on Windows, news at 11. Show me where "Microsoft is now pushing toward TPM being required in Linux."
I fail to understand your's or the GP's point. I think you think "We got 'em!" On what? A vibes violation? A TPM, or something like a TPM, seems pretty sensible these days.
It moves process from "put any distro and just install it" to "open the bios, find the right options to change or disable and then you can actually install it".
Why would this even have to be the case? Linux will work on hardware with a TPM chip. It will also work on hardware without a TPM chip. If you're saying one day, some distro may choose not work on hardware without a TPM chip, take it up with that disto (in your imaginary future)? It's not Microsoft's problem?
If Microsoft didn't mandate TPMs for hardware running Windows 11 (or kept Windows 10 supported in parallel indefinitely), then governments wouldn't be able to pass such a law without potentially bricking the computers of millions of citizens.
I'm not expecting Microsoft to make a moral stand against TPMs, but they could at least have accidentally been on the right side just by not mandating TPM support.
You have to look at the incentives, though. If a government passed this law, it would put huge barriers in the way of people developing innovative new Linux distros, especially if, in practice, every distro had to pay a "tax" to Microsoft to have their signing keys whitelisted by device manufacturers.
Even if Microsoft didn't see this as a way to stifle niche OSes, industry groups (of which Microsoft is a member) would push for such laws just to prevent "software piracy", and of course Hollywood would push for the laws to prevent "media piracy". That would in turn raise demand for mainstream OSes, because those would be the only ones that could stream movies and music.
So when I suggest that the government would mandate it, that's in the context of a political climate where big businesses often write and lobby for laws which make it difficult for smaller competitors to challenge them. Whether Microsoft does that lobbying publicly, or privately, or via proxies, is somewhat immaterial to my argument.
And yet, many of the current senior management were there in 1998 and were obviously fine with it. Most of the rest joined shortly after and were obviously also fine with it.
And yet you should still get some new material. I don't like Windows and I still have bad taste in my mouth re: Microsoft from the 90s, but I/the world got over it. You should too.
Of course it would not be "required" required—so long as you're okay with maintaining your own distro, with forks of everything having essential TPM-based security features excised, working with your own builds of the kernel. Good luck selling this your employer.
So, it's not literally true. It's just vibes, man. And I guess that's what disappoints me.
If lots of Linux people see TPM as a good thing that should be adopted in the major distros (not unlike systemd), because of the benefits, what's the problem?
Perhaps you need to consider the possibility that the battle between systemd vs sysv init is not unrelated to the desire of Microsoft (and others) to lock down general purpose computers.
By giving Linux one tightly-coupled system that controls everything from the boot process to process permissions, it becomes much easier to add the missing "features" needed to implement such a lock down (and harder for distros to support "non-standard" configurations which slow the adoption of this).
This probably already sounds like a conspiracy theory, but I absolutely believe that intelligence agencies are eagerly awaiting the day they can convince governments to ban "insecure" computers from going online, where "insecure" means "not supporting Secure Boot attestations and not supporting an app blacklisting service like Gatekeeper[0]".
The existence of Linux (especially non-mainstream distros) is an impediment to a government introducing such a law right now, but if 90% of Linux users are running systemd, and users can install some future "systemd-gatekeeperd" with a couple of clicks, then no government will hear the cries of the greybeards who refuse to configure their machines this way.
Once the law is in place, the loopholes for distributing and running "unapproved" code will be slowly closed one by one, meaning fewer and fewer people will have access to apps/protocols like Tor, BitTorrent, E2EE messengers, and VPNs (unless those apps/protocols also include endpoint blacklists and do client-side scanning for illegal files).
The push for everything to go to HTTPS feels like it fits in here. I'm envisioning one day your browser just doesn't speak unencrypted HTTP and you can no longer bypass warnings for untrusted/self-signed certificates. You can't use a better browser or install/remove certificates as you please without illegal jailbreaking.
I'm not quite sure what the threat model is that you're suggesting. Are you imagining that a government will demand that browsers drop support for unencrypted HTTP? It would be simpler for that government to just demand that ISPs drop traffic on port 80 (or do deep packet inspection for a slightly more sophisticated approach).
But in any case, what's the danger with that? Are you worried that a government could tell all CAs not to issue certificates to "subversive" websites? Obviously there are jurisdictional problems with ordering CAs in foreign countries not to issue certificates, but I suppose a government could instead require that all browsers (within their jurisdiction) only trust certs from the government-run CA.
Those would certainly be bad outcomes, but if your threat model includes "the government controls what your browser can do" then I don't see how the situation is any worse due to widespread adoption of HTTPS. If the government is going to interfere with your browsing, then it's actually some consolation that other random attackers aren't also able to do that.
The only extra attack I can think of that mandatory TLS makes possible, is that this government which controls its citizens' browsers in this way could then put pressure on Let's Encrypt (via the US government?) to require ID information from all their users (and a similar rule for other CAs, which wouldn't be too hard as most of them require non-anonymous financial transactions). That still seems like a lot of unnecessary work for little benefit, though, surveilling web publishers when this government already controls its citizens' browsers.
For example:
Java app that gets put to background before it writes PID (which takes some startup time). In result running status right after start will say that app is stopped. Pacemaker didn't liked it and freaked out. Not only Java problem but start exacerbated it
MySQL disto package (Hi Red Hat) that didn't put PID into temporary partition, nor checked whether PID there is one running mysql so after reboot there was an edge case where "old" pid that's still in old file after crash was used by new app, mysql didn't start coz "simple" sysv script thought it's already running
Then there is dependencies that make a lot more cases simple like "start the service to get the encryption keys before you try to mount the encrypted volume" is just few deps, not modifying any code, and auto restart removed our use of monit
I do dislike the vast suite of stuff that worked fine before that comes with it and journald design is a bit shit, especially disk format (still have bug open when running status on app can take tens of seconds on spinning rust, why they just didn't use SQLite and indexes...) but overall, without exaggerating, it allowed us to remove tens of thousands f lines of code of "simple" sysv stuff that needed to be fixed.