Can you provide any specifics of the serious issues you’ve encountered with journald and networkd? There were some performance issues with journald early on, but I know a lot of work has gone into it over the years (a coworker of mine, for example, improved the performance of log retrieval by 10x). And networkd has always fulfilled my needs nicely, so I’m curious what sort of trouble you ran into.
Only issue I have with networkd is lack of adoption: network manager is pushed hard (Red Hat still clinging to nm for servers, ew) or want to add another abstraction around it (Canonical with netplan). It's an awesome, declarative way to manage networking, embrace it.
Man, we fought hard at Red Hat to get them to continue using networkd with their latest container-focused OS. Ultimately, the organization just had too much institutional momentum behind NM. Frankly, I’m disappointed that they lacked the imagination and drive to push the industry forward.
Networkd is fine if you don't need vlans, bonding, and a bunch of semi-esoteric stuff. /e/n/i does fine there.
Journald is too monolithic IMO. Direct access to the files in a text format is standard Unix stuff. Forcing everyone through the journalctl tool is rough, performance being just one issue. The binary format has a habit of changing too, having written a journald log tailer.
Overall, like I said, systemd is work software for me. It's fine for the complexity in a company (where you have to balance time and business value), but for my own use I wouldn't choose it.
Hence, please don't touch Alpine ;). I was on KISS previously but got tired of compiling my own packages (and Firefox is nigh impossible to compile in a 'ragged' version package system)
What more semi-esoteric stuff would you be missing?
> Hence, please don't touch Alpine
I'm with you here though: I too appreciate Alpine being on OpenRC rather than systemd. And hope a musl port does not change the calculation there. You may also appreciate https://chimera-linux.org/ if you haven't checked it out already.
I recently found that systemd-networkd isn’t generating “up” events (or something similar, not posting from work) for bonded interfaces set up by cloud init which causes the network wait job to spin until it times out, adding about 60s to boot time for any debian-based box we run in our medium sized deploy, so maybe a few 1000. I noticed because my dev box took forever to come back after a kernel update and I was sweating that I’d broken something.
Unfortunately I was unable to allocate the time to figure out systemd at the layer where the event is expected but not generated to file a coherent bug. I ended up working around it several layers up by hard coding “bond0” as an argument in some config and moved on.
I don’t think openrc is perfect and I find broken shit in Alpine constantly but when I do it’s a whole lot easier to figure out what broke when you don’t have to dig through several layers of dbus event generators and consumers before figuring out what even happened.
I think I may be facing the exact same issue with bonded interfaces not being brought up properly (unrelated to cloud-init) and was hesitating if I should mention it as a caveat in the previous comment but maybe to your point I'm not 100% confident we're not missing anything in the configuration (:
For now an `ip link set up` hook has been a passable workaround here.
Yeah, the cloud init bit was from memory and might not even be right. What I found was that the dbus event doesn’t get generated for the bonded interface when it comes up.
journald is still very, very slow. As in, getting the entries for a given process can take a minute or more, whereas just grepping a normal text file is nearly instant. It doesn't help that the default rotation settings are insane (like, why would using a certain percentage of my total space be fine, what if all programs thought that?).
Generally I don't really understand what journald brings to the table. I'm sure there are esoteric setups where the hash chaining thing makes sense, but meh? A lot of things needed fixing and systemd fixed many of them, but everything journals is a terrible user experience for me.
This... is just not true. I use journald extensively on a 600Mhz Cortex-A9 daily and it's not slow. I don't know what kind of log load you have, but even when I have processes crashlooping and am sending logs over SSH over a VPN it's fine.
> like, why would using a certain percentage of my total space be fine, what if all programs thought that?
Because the journal’s role in a system is inherently different than most programs. It’s collecting logs for everything; not just itself. It seems reasonable to me that a system-wide service would use a percentage of the system’s resources.
Plus, if you don’t like it, reconfigure it. It’s only the default, after all.
> Plus, if you don’t like it, reconfigure it. It’s only the default, after all.
Or -- and I know this is crazy but hear me out here -- if you don't like it, and it brings nothing but problems to the table, just don't use it at all.
First, i'm a vocal systems appreciater. But. The one thing that frustrates me about the journal is that there is only one journal. If I have a chatty app, it can entirely take over the journal. Set a 1GB hour al, come back in a couple days, and nothing else is left in the journal other than it logging. I hate this so much.
If I could assign some apps to a secondary journal, or better quota individual services, that would make sure I can keep tabs on my entire system, even when one app is logging heavily.
Bro no. Logrotate shit was gross and gnarly. Every service has its own way of doing with logs. None of it worked the same. It never was simple it always had been crap.
I have my complaints but not replying on each service to do something special conpatible with each other log rotation system was not a complaint. Having this managed reasonably has been great.
Tangentially I now have to remove systemd-resolved on each machine. It gets too complicated because I use dnsmasq on family machines and resolved is always trying to open ports to the internet (opensnitch knows).
Already run DNS on my router, so why have a second or third cache on each machine? Network manager is involved also.
Right, you need a mechanism. (Ice cream makes you fat, fat people can't swim, ergo drownings). Haight clearly outlines the mechanisms by which social media and smartphones have detrimental effects on mental health, see: https://www.youtube.com/watch?v=-l2TdinWoM8
And if you swim enough, you can't get fat no matter how much ice cream you eat. Ever seen the diet Phelps was on? Guy ate like crap, has over 20 gold medals to his name.
Author here, I found it pretty interesting the amount of similarity between BPF and embedded development. My original background is in computer design and low-level software, so this was a bit of a blast from the past - lots of delicately holding the compiler in just the right way to get it to emit the desired set of instructions, reading through the resulting assembly (_much_ easier with the validator annotating register values), digging deep into language specs and compiler documentation. It makes sense in retrospect, but it caught me off guard when I first started.
1. itch.io uses PayPal. Assuming you trust them, there is nothing to worry about.
2. itch.io provides the same mechanism. You are paying for the game, not the single download.
3. As long as you can re-download the game, then there is no reason to save the installer. Serials/keys are up to the discretion of the game developer and I don't see why giving the game developers control is a bad thing. I think most indie games are against DRM anyway.
4. In order to support auto-updates, the game developer has to invest in the Steam APIs. There is nothing stopping games on itch.io to using out-of-band updates.
The developer doesn't need to do anything to enable steam updates. Steam just does a binary diff vs the master copy.
For 2 & 3, that's great, but to be honest there is a huge burden of proof - frankly, I don't really expect any random startup that doesn't even have a .com domain to be around in 5 years.
