so they need to boot, but only the kernel needs to boot.
There currently is no way to fire specific events based on vendor/device id like you would with systemd.
This forced me to write a shim script to enable USB passthrough with arbitrary k8s nodes. The shim was short but is very hacky and relies on 3p packages because the info needed isn't available in stock alpine.
Blog post about it here: https://stephentanner.com/home-assistant-on-k3s.html
Follow up post in the works based on additional improvements up streamed to OpenRC. The biggest issue was getting literally anyone from the project to comment on the PR to progress it forward to acceptance.
"Can leave my charger at home" moment for me.
So I doubt if systemd and its subsystems are using much energy.
It doesn't seem likely to explain 20 vs 8 hours battery.
Have you actually profiles that copying the 500mb rootfs is the bulk of your boot time? At around 150MiB/s, which is common for USB these days, I would expect that to only take ~4s, and copying from ram location to ram location is far faster. I would expect your boot time is a lot longer than that.
I think the need for faster boot comes from people who scale cloud servers or containers up and down a lot.
The key derivation step is designed to take a set amount of CPU time (say, a second), so it's difficult to brute force.
(A cloud instance with a disk without encryption is a different business.)
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.
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.
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.
The file format is not text, and I use it under Linux, which is good at processing text files.
The command line arguments are insane.
Bad handling of log lines emitted at system crash.
Broke an entire prod network’s observability stack because ubuntu replaced syslogd with it in the middle of an lts support cycle.
Brings in a systemd dependency, which causes 100x more problems than this.
That makes it sound that your main problem is the fact that it exists.
> Broke an entire prod network’s observability stack because ubuntu replaced syslogd with it in the middle of an lts support cycle.
That's more ubuntu's fault I guess. I don't really remember this happening though.
> Brings in a systemd dependency, which causes 100x more problems than this.
Is it other made up problems or real things?
1475/1475 systemd:libsystemd / test-journal-verify OK 28.44s
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.
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.
Already run DNS on my router, so why have a second or third cache on each machine? Network manager is involved also.
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)
networkd does support vlans, bonding, bridges, and whatnot since quite some time now.
https://wiki.archlinux.org/title/VLAN#systemd-networkd
https://wiki.archlinux.org/title/Systemd-networkd#Bonding_a_...
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.
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.
For now an `ip link set up` hook has been a passable workaround here.
This person blogged a bit and the details and fix don’t match my situation but the broad strokes do: https://www.thomas-krenn.com/en/wiki/Job_systemd-networkd-wa...
People bring it up because it's usually the first thing they notice. Of course the faster boot times are not what makes systemd great, rather it's what makes those fast boot times possible.
You probably are looking for a different word, rather than “indifferent”. Indifference is a property of the observer/subject, not the observed/object. For example, if I don’t care about sports, I might say that I’m indifferent to the outcome of the game my friends are watching.
Perhaps “mediocre” is what you’re looking for?
https://www.collinsdictionary.com/dictionary/english/indiffe...
Linux has no problems running S2Idle but due to how S2Idle works, more components can wake up your system, therefore more components can misbehave, incl. devices attached by USB. Ugh.
I'm assuming this is for a personal use computer. Can you talk more about the setup here? Sounds interesting. If the OS is immutable, where do you store personal data and how do you perform updates?
In a mounted folder.
"how do you perform updates?"
You use another image.
For the majority of deployments of systemd, that's probably true. Note that this is a musl port, and that the existing musl port is from OpenEmbedded. It's embedded devices that are often using cut-down userspaces (e.g. using MUSL), and embedded devices often do care about startup time because they're not Always-On.
E.g. the VTech baby monitor I've just bought is generally pretty good, but spends >10 seconds at a splash screen when you turn it on. No idea if it's Linux under the hood, but an optimised boot time would be great.
In a previous work project, we need the Linux based software to be ready from low power state quickly (battery powered, only doing work occasionally). By getting the boot time down <1s, I could also avoid a load of sleep-state shenanigans - when we wanted to power save, we just turned off completely (there was already a supervisory micro to decide when to turn back on).
E: Also, Android uses the Linux kernel, but similarities with Linux based operating systems pretty much stop there.
Where are the posix utilities ? /s Where is man ? /s
I'm always super annoyed at the current state of smart appliances that take ages to power on because they run some half-assed linux on an underpowered processor that would give the apollo guidance computer a run for its money. And that's why I only have dumb appliances.
systemd to me isn't useful at all for the desktop and is a big contraption for firing off VM's and containers in a highly automated server environment. I dont miss it which means I have zero need for it.
If rootfs is immutable why copy to tmpfs.^1 Genuine question. Not Alpine or Linux-specific. For example, maybe it feels faster running binaries from tmpfs.
Immutable directories can be mounted from compressed files e.g., squashfs, etc., on the USB media. Alternatively one can copy only the binaries that one acually needs at a given time. Then delete them from tmpfs when not in use to free up memory.
1. I do this is so I can pull out the USB stick. But I use a much smaller rootfs that fits in the kernel ramdisk.
personally I use a custom alpine live-usb that is immutable and I fully shutdown and start-up all the time. openrc doesn't give me any grief, the bulk of my startup time is copying my 500mb rootfs into a tmpfs
systemd for me is solidly "at work" software, and not stuff I'm a big fan of either (journald, networkd and the silly dns resolver all have serious issues). so please, keep away from my alpine or I'll have to fork -again- :)