📼 "systemd-ifying postmarketOS, our immutable future, and why Alpine is cooler than you thought"

Because people at @mediacccde are absolutely amazing, the talk is already up!

https://media.ccc.de/v/all-systems-go-2024-278-systemd-ifying-postmarketos-our-immutable-future-and-why-alpine-is-cooler-than-you-thought

#systemd #allsystemsgo #linuxmobile

@postmarketOS @mediacccde interesting comment at the end: «musl is probably not for embedded devices»

Due to the lack of malloc_trim

@postmarketOS
Even though alpine packages multiple init systems openrc is the only supported one. I have been working on making others easier to use but this doesn't mean any official support by alpine.

@sertonix @postmarketOS yes. I don’t think we want support more than one init system. We don’t mind anyone packaging other init systems but you are pretty much on your own if you do.

@sertonix @postmarketOS also, we use OpenRC not because it is great but because we started with it decades ago and no good alternatives that officially supports musl has popped up since then.

@sertonix @postmarketOS “No good alternatives” was bad wording. Of course there are good alternatives. What I meant was alternatives that are so much better than OpenRC that it justifies the cost of switching

@ncopa @sertonix @postmarketOS I think that's fair enough as long as efforts of using alternative init systems are not hampered either. Simple things that would help would be shipping init-specific subpackages to split out service files for example, e.g. -systemd or -dinit. It would be lovely if those things could be in Alpine rather than in separate repos, it makes maintaining alternatives easier and shouldn't hurt OpenRC.

@ncopa @postmarketOS @mediacccde LMAO I've gotta read this.

Should we add a no-op malloc_trim? Because that's exactly the correct and optimal implementation for mallocng. 😂

@dalias @ncopa @postmarketOS @mediacccde i read through some references to malloc_trim() on musl-devel and saw this same sentiment. is there somewhere i could read more about why this is the case?

the no-op method would probably make sense imo if that is the right implementation

@sertonix @postmarketOS ya what I meant was that Alpine doesn't prevent you from running other init systems, openrc isn't a hard coded default. "support" was probably the wrong word 🤷‍♂️

@cas @ncopa @postmarketOS @mediacccde It was kinda a joke. If someone is seeing a need for a malloc_trim, it's an indication they're trying to work around some bad behavior in malloc in the implementation they're using: either a model that doesn't admit returning the memory not in use (in which case malloc_trim wouldn't help) or an implementation choice to trade large memory usage for potential performance (in which case it, i.e. glibc, it probably not a good choice for embedded).

@dalias @ncopa @postmarketOS @mediacccde right, what I'm trying to understand is what makes musl malloc different such that in a memory pressure situation (for example) malloc_trim() doesn't apply.

i guess reading the top answer to this makes things a bit clearer, since i assume mallocng isn't use the same implementation.

https://stackoverflow.com/questions/38644578/understanding-glibc-malloc-trimming