21–30 of 308 posts
Earlier quoted context omitted.
In the embedded world, BSP/driver support is the main thing that matters. Linux is undefeated in that area for embedded purposes.
In embedded you should choose hardware that works. Should is key, all too often the, hardway guys don't ask they just give software something.
I've never seen it approached with that kind of incompetence, in my professional life. Embedded is a system thing, not a hardware thing. You pick the system that will work. Ignoring the software side of things is ignoring the majority of the problem in embedded work. I would have agreed with you 20 years ago, but it's 2024, and why RPI is so often used for prototyping.
Earlier quoted context omitted.
it's also why corporate software is so shit - it's shiny in all the ways it needs to be shiny for management to make the decision, but it's a pain for the actual users. the trick in both cases is to know your customers!
Turns out, many people use systemd after what, 15? years of doomsday predictions :-)
This is anti-systemd FUD. Implying that applications which work without systemd are going to stop doing so. Suggesting that Linux distributions adopted systemd because it's good for distributors and not because users actually want it. We are "forced" to use systemd's udev implementation. Please.
All of those things are trivially true. What are you disagreeing with?
Earlier quoted context omitted.
I thought there was a compatibility layer available that made it possible to run Linux drivers on at least FreeBSD.
That's for userland, not drivers. Linux doesn't have a stable interface for drivers so a compatibility layer would be a nightmare to maintain.
Container startup ordering, startup dependency management, socket handling and all things timing and network related are frankly a complete mess in modern infrastructure. Even, surprisingly in well maintained projects like k8s. I find myself shaking my head at problems solved by systemd a decade ago far too often.
Earlier quoted context omitted.
it's also why corporate software is so shit - it's shiny in all the ways it needs to be shiny for management to make the decision, but it's a pain for the actual users. the trick in both cases is to know your customers!
Turns out, many people use systemd after what, 15? years of doomsday predictions :-)
How many people eat McDonalds? Or buy in to countless other things that can be trivially demonstrated to be against their own interests.
I don't know about anyone else but I never heard the critiques of systemd to be based on any doomsday predictions.
Everyone knew it would function, and that it even serves one use case better than before.
The critique was only ever that it serves one purpose better at the expense of all others, and is a downgrade in flexibility and functionality from what already existed.
Earlier quoted context omitted.
i don't notice anything good systemd does for me, just where it interferes, and that's a constant annoyance, a few days a week.
Can you link some upstream issues you raised about the big annoyances?
This is a common pattern by the way. But easily the most irritating thing for me is the simple issue that you used to be able to just go to /var/log/lastlog to see what failed during the last boot and that just the other day I had to spend hours figuring what broke in the system that made journalctl not log properly. In the end I had to reinstall all currently installed packages.
https://www.reddit.com/r/archlinux/comments/zczdnq/systemctl...
Come fucking on. I ran systemd on a 32Mb MIPS board (RouterBoard from Mikrotik) just fine.
The RES column is incredibly misleading in this case, because systemd is the first app in the system. So it gets charged for loading the entire glibc and the supporting cast of libraries.
If you want to look at the true usage, check the RssAnon value:
> root@kmipsrv:/proc/1# cat /proc/1/status | grep RssAnon
> RssAnon: 3220 kB
You can also pare this down a bit.
Similarly for journald:
> root@kmipsrv:/proc/1# cat /proc/231/status | grep RssAnon
> RssAnon: 640 kB
So in reality, systemd works just fine for the vast majority of embedded platforms. If you can spare 3Mb of RAM, then you can run a full-blown dependency management system with reliable recovery, logging integration, and event-driven device management. Soon with support for verified boot with hardware root-of-trust.