- bonziniThat's your distro, not systemd. systemd only does what the configuration files tell it to do.
- I have checked three smaller machines.
On one (coreelec) systemd has 7M of resident data, of which 5.5M are shared libraries; by comparison, the numbers for sshd are respectively 6M and 3.5M.
On an OpenWRT machine without systemd (it's using procd) there are 700k of resident data. So the "cost" of systemd seems to be ~5M. Certainly I wouldn't run systemd on an old router with 16MB of RAM, but the cost is two orders of magnitude less than 1G-300M.
- That was almost 15 years ago and the support is evidently not as useful.
Also it's entirely contained within a program that creates systemd .service files. It's super easy to extract it in a separate project. I bet someone will do it very quickly if there's need.
- Technically that's part of podman, not systemd. But it's the same architecture that was used to support sysvinit scripts.
(In fact, nothing prevents anyone from extracting and repackaging the sysvinit generator, now that I think of it).
- > Why wouldn't you want unit files instead of much larger init shell scripts which duplicate logic across every service?
Indeed, that criticism makes no sense at all.
> It also enabled a ton of event driven actions which laptops/desktops/embedded devices use.
Don't forget VMs. Even in server space, they use hotplug/hotunplug as much as traditional desktops.
- As I wrote in another comment, just check out /run/systemd/system. You'll find the wrapper units that systemd creates for your sysvinit scripts.
- Thanks!
- It is, but my point is that these entries are more historical oddities than a sign of particularly high population density of Spanish cities. There are similarly dense suburbs in most cities/countries, they just happen not to have a local government.
- Not only it's easy, the exact contents of the systemd unit can already be found in /run/systemd/system.
- > (#2 and #3 are both in Spain at https://en.wikipedia.org/wiki/List_of_European_Union_cities_... in "density per km2" for example, 50% of top 10 on that list is in Spain!)
That list does not make much sense, because it mostly consists of small municipalities that have been engulfed by growing metropolitan areas. Four of the five Spanish entries are like that, three in Valencia and one in Barcelona; and most other entries in the top 20 are suburbs of Paris, Athens or Naples.
- Sanctions in the 1950s?
- Three-four years is a lot of time for these companies to face the harsh reality.
- Only to later add switches that chose between x87 and SSE? :)
- > Forget the bells-and-whistles and answer this: does the use of Rust generate a result that is more performant and more efficient than the best result using C?
These are the performance results for an NVMe driver written in Rust: https://rust-for-linux.com/nvme-driver
It's absolutely on par with C code.
- That was way way blown out of proportion. https://lwn.net/Articles/991062/ has a much less somber quote from just three months later:
> Ted Ts'o said that the Rust developers have been trying to avoid scaring kernel maintainers, and have been saying that "all you need is to learn a little Rust". But a little Rust is not enough to understand filesystem abstractions, which have to deal with that subsystem's complex locking rules. There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn
- There are devices that do not have access to memory, and you can write a safe description of such a device's registers. The only thing that is inherently unsafe is building DMA descriptors.
- You can absolutely write drivers with zero unsafe Rust. The bridge from Rust to C is where unsafe code lies.
- Converting to RPN is, roughly speaking, the easiest way to generate code for either register or stack architectures.
Once you have a parse tree, visiting it in post order (left tree, right tree, operation) produces the RPN.
- Yep. It can refactor very well but that's it. For complex code bases it cannot even build boilerplate that makes sense; at most it saves some typing.
- I did find some benefit in lowering the cost of exploratory work, but that's it—certainly worth 20€/month, but not the price of any of the "ultimate" plans.
For example today I had to write a simple state machine (for a parser that I was rewriting so I had all the testcases already). I asked Claude Code to write the state machine for me and stopped it before it tried compiling and testing.
Some of the code (of course including all the boilerplate) worked, some made no sense. It saved a few minutes and overall the code it produced was a decent first approximation, but waiting for it to "reason" through the fixes would have made no sense, at least to me. The time savings mostly came from avoiding the initial "type the boilerplate and make it compile" part.
When completing the refactoring there were a few other steps like where using AI was useful. But overall the LLM did maybe 10% of the work and saved optimistically 20-30 minutes over a morning.
Assuming I have similar savings once a week, which is again very optimistic... That's a 2% reduction or less.