You can forward logs to rsyslog or something, but you really can't disable systemd-journald. Technically you don't need to run systemd-boot, you can use grub or something else, but then bootctl and systemd kexec stop working. You don't need to run dbus, but if you don't several systemd features break, and it's not even documented what needs it. The list goes on and on.
Also, the fact that all components are in the same repository and need to be built together causes a lot of headaches with packaging due to dependency cycles (like, systemd -> cryptsetup -> lvm2 -> udev -> systemd).
Systemd is literally not a monolith because it's not one big piece of software. It's a collection of software. For example, systemd-boot has basically nothing to do with systemd-init.
Yes, some software is more tightly coupled than others, naturally. systemd-init and systemd-journald work tightly together because logging is a core requirement of any init system.
I think that mostly comes down to distro choice and a lot of distros are more than okay with systemd soup. That’s the beauty of OSS, you can always choose not-Fedora ;)
Since the rules are entirely reconstructed, I have to say I'm a bit skeptical of a game where a central point is keeping a count of moves up to 150. It seems too unpractical for a casual game.
Are there other known ancient games that work like this?
Yeah, I don't know about the author, but my brain spatial memory is very much tied to Euclidean geometry. The holonomy effect (view is rotated when coming back to the same point) in particular is very disorienting.
I'd say not much: you update the channel, run nixos-rebuild switch, fix all the warnings/errors due to renamed/changed options until it succeeds and you're done. If you have a database like postgres you may have to do a schema upgrade manually, since the default version is updated every 4/5 releases or so.
It's very rare to find something that prevents you from directly updating. Nixpkgs tries very hard to no require new Nix features, so it evaluates with even Nix versions from a decade ago. Also, NixOS options and packages are frequently changed, but the automatic migrations (mkChangedOptionModule, mkRenamedOptionModule, alias, etc.) are never removed in practice.
Since the binary cache has never been cleared since its creation (2002?), it should actually be easy to install a super old NixOS release and upgrading it to the latest to see what happens.
By the way, there are LTS versions of NixOS, just not officially supported. See https://docs.ctrl-os.com/.
And when it happens, that there are new Nix features used in Nixpkgs, then you can download the closure for the new Nix executable, directly from the build farm, and update your OS from this new Nix version.
> they still see the URL so they can get the content if they want it
That's incorrect, a MitM can only reveal the server hostname by inspecting the SNI during the TLS handshake, but the HTTP request, including the URL and headers, is encrypted.
No they can't. They obviously know the IP addresses, but that's not terribly useful since everything is behind a cloudflare proxy nowadays. The server hostname may provide some more information, if the server doesn't support ECH [1], but the full URL is encrypted.
If you use HTTPS they can see that you hit wikipedia (they will see you are trying to do a DNS lookup for en.wikipedia.org), but they can't see that you are viewing https://en.wikipedia.org/wiki/Hundeprutterutchebane in particular- that is only available to someone who can read the body of the HTTP request, which with HTTPS is encrypted.
I just do this for the IP ranges of Amazon, OpenAI, Huawei and other companies that run these insane crawlers: it's 100% effective and it doesn't annoy real users with a captcha or some PoW thing. There's simply no reason for them to reach my homeserver other than to scrape the hell out of it.
The breeding blanket is entirely contained inside a vacuum vessel, so there isn't any oxygen to react with. Also, the are many blanket designs, but the lithium is never present in its elemental form (precisely because it would be very reactive), but in a stable chemical bond with some neutron multiplier (like lithium-lead alloys or beryllium ceramics). In some design the lithium is even immersed in the coolant itself, which is high pressure helium, so it's not going to ignite in any reasonable way.
> breeding blanket is entirely contained inside a vacuum vessel, so there isn't any oxygen to react with
When the vessel works. If the vessel breaches, that lithium could ignite. Note a showstopper. But I suppose a risk to be thought about by the engineers (probably not by policymakers).
Commonwealth Fusion Systems plan to use lithium in salt form FLiBe, a molten salt made from a mixture of lithium fluoride (LiF) and beryllium fluoride (BeF2). It does not violently react with air or water.
Thanks. So the author's point in the linked article is wrong, it's the opposite of what they wrote. Contrary to what they say, it's indeed a bus, and it isn't the case that CSMA/CD is useless, it's that isn't enough to deal with the situation, so additions have been made to it.
Thanks for your link that helped clarifying this for me!
When you have switches that link two nodes together, for only the duration of one-way transmission you don't need CSMA/CD. We literally have no use for it. We will never have two computers transmit onto the same Ethernet wire anymore.
WiFi is different of course. However as the author wrote, your WiFi devices always go through the access point where they use 802.11 RTS/CTS messages to request and receive permission to send packets. All nodes can see CTS being broadcasted so they know that somebody is sending something. So even CSMA/CA is getting less useful.
Yes I'm only talking about wifi networks. I get that CSMA/CD itself is getting less useful, but it's because something else is doing its job, not because what it did is useless (that's why I wrote "or something similar" when I asked). Wifi is still, necessarily, a common bus where everyone talks.
CSMA/CD - Collision Detection and CA Collision Avoidance. - FYI the article is from 2017!
for Non-WiFi, we don't use CD because all is bi-dirireactional and all communication have their own lane, no needed because there will never be a collision this is down to the port level on the switches, the algorithm might be still there but not use for it.
For WiFi, CD can never be good or work, because "Detecting" is pointless, it cannot work. we need to "Avoid" so it has functionality because is a shared lane or medium. CA is a necessity, now in 2026, we actually truly don't need it or use it as much since now WiFi and 802.11 functions as a switch with OFDM and with RF signal steering, at the PHY (physical level) the actual RF radio frequency side, it cancels out all other signals say from others devices near you and we "create" similar bi-directional lanes and functions similar as switches.
The article is good and represents how IETF operates a view (opinionated) of what happens inside. We actually need an IETF equivalent for AI. Its actually good and a meritocracy even though of late the Big companies try to corrupted or get their way, but academia is still the driver and steers it, and all votes count for when Working-Groups self organized. (my last IETF was 2018 so not sure how it is now in the 2020s)
How can wifi be a star topology when all clients connect to the base station using the same airwaves? If it really were a star topology, it would also not be possible to use aircrack-ng or other tools to gather data for WPA cracking by passive listening -- that can only happen on a shared medium network.
I think the most accurate classification is that wifi emulates a star topology at OSI layer 2 on top of a layer 1 bus topology.
Not much, Revolut just got tricked by hackers into giving out customer information: https://news.ycombinator.com/item?id=49682087