Conversation
[GRLC] le rouge vire au bleu marine et je dégueule leur doctrine
novenary@akko.wtf
im not sure whether this take is nuclear or glacial at this point
Show content
if systemd is too monolithic and centralized then the kernel is orders of magnitude worse
6
2
1
[GRLC] le rouge vire au bleu marine et je dégueule leur doctrine
novenary@akko.wtf
(this isn't pro-systemd, i hate both projects but mostly for political reasons, yet use them out of pragmatic choice)
1
0
1
[GRLC] le rouge vire au bleu marine et je dégueule leur doctrine
novenary@akko.wtf
but yeah: I am begging to stop shoving more and more things into kernel space, especially when they are trivially handled in userspace
2
0
1
Tired Bunny 
tiredbun@akko.wtf
re: im not sure whether this take is nuclear or glacial at this point
Show content
@novenary i just saw post in russian mentioning that many issues of flatpak are found in GNU, as in being hyperpopular while having non-standard stuff that makes it a pain people who don't want to use it because alternatives are not compatible.
And like GNU, systemd is more of a umbrella of interconnected intercompatible projects that all depend on few central components.
And like GNU, systemd is more of a umbrella of interconnected intercompatible projects that all depend on few central components.
1
0
2
[GRLC] le rouge vire au bleu marine et je dégueule leur doctrine
novenary@akko.wtf
re: im not sure whether this take is nuclear or glacial at this point
Show content
@tiredbun i'm making a slightly different point here tbh
my objections to systemd are primarily non-technical
but both technically and politically, the Linux kernel is significantly worse than systemd: it is far more irreplaceable and wholly non-modular; its governance structure and community are awful, and yet its architecture is such that if you need to have some code in kernel-space, you *have* to go through the painful and humiliating process of contributing to a project that ultimately has dubious quality standards at best, but still shits on everyone for no reason
my objections to systemd are primarily non-technical
but both technically and politically, the Linux kernel is significantly worse than systemd: it is far more irreplaceable and wholly non-modular; its governance structure and community are awful, and yet its architecture is such that if you need to have some code in kernel-space, you *have* to go through the painful and humiliating process of contributing to a project that ultimately has dubious quality standards at best, but still shits on everyone for no reason
0
0
1
Li ~ Crystal System
Li@tech.lgbt
re: im not sure whether this take is nuclear or glacial at this point
Show content
@novenary @LunaDragofelis the kernel being monolithic has been a complaint made about it since the beginning of the linux kernel.
0
0
2
إمي ❄️🏳️⚧️🇵🇸
emmy@transfem.social
re: im not sure whether this take is nuclear or glacial at this point
Show content
@novenary No you’re correct. The only problem with systemd is the LLM usage in development. I would still use it if not for that.
The kernel is also using LLM for some parts, but there are so many developers and the process is still standing up. But systemd fell pretty quickly once Lennart started using it.
1
0
1
re: im not sure whether this take is nuclear or glacial at this point
Show content
@novenary you're right, it is
1
0
0
re: im not sure whether this take is nuclear or glacial at this point
Show content
@novenary this is a problem most unix-likes just inherit from unix, would be better if we lived in a post-unix world where plan 9 or something else sensibly designed for the modern day was used instead
0
0
1
إمي ❄️🏳️⚧️🇵🇸
emmy@transfem.social@novenary Oh, I read your other post and understand your point better now. I can’t agree or disagree because I don’t know how difficult it is for the problems they’re solving to solve in a more modular way. I simply agree that they are indeed the same.
1
0
1
/Cinny 
re: im not sure whether this take is nuclear or glacial at this point
Show content
@novenary yea the reason i'm using linux is mostly because there's no microkernel alternative
i'm writing a microkernel but will it ever be functional enough to daily drive? probably not
i'm writing a microkernel but will it ever be functional enough to daily drive? probably not
1
0
1
[GRLC] le rouge vire au bleu marine et je dégueule leur doctrine
novenary@akko.wtf
re: im not sure whether this take is nuclear or glacial at this point
Show content
@navi I wanna make one too, but I have no illusion that it'll ever be more than a toy that only runs on simple hardware
0
0
0
Haelwenn /элвэн/ 
lanodan@queer.hacktivis.me
@novenary Yeah, feels kind of wild when Plan9 almost feels like a microkernel in comparison and AFAIK the Plan9 devs *hated* the microkernels that existed at the time.
0
0
1
[GRLC] le rouge vire au bleu marine et je dégueule leur doctrine
novenary@akko.wtf
@emmy this is in large part a policy issue
the kernel community and the cathedral-style monorepo favor the ability to make large-scale breaking changes internally over letting individual subprojects be developped independently like userspace components are
sometimes this is also for dumber reasons, for example there are a lot of things in the kernel tree that don't need to be part of the kernel at all, because they could be done in userspace just fine (like many drivers and services)
this is either because of bad design (for example, FUSE is atrocious) or poor decisions that have been cemented by tech debt (smaller drivers that wouldn't take a significant performance hit from running in userspace)
other aspects are more structural, some core components like the network stack and bigger, performance-critical drivers (like for GPUs) can't be userspace processes in linux's monolithic kernel architecture, but microkernels are perfectly capable of handling this (see e.g. genode, fuchsia and nintendo's horizon OS)
the current governance structure is so impossibly resistant to change that these major flaws are effectively unfixable without either a hard fork or a whole new kernel, but this would be a monumental effort
the kernel community and the cathedral-style monorepo favor the ability to make large-scale breaking changes internally over letting individual subprojects be developped independently like userspace components are
sometimes this is also for dumber reasons, for example there are a lot of things in the kernel tree that don't need to be part of the kernel at all, because they could be done in userspace just fine (like many drivers and services)
this is either because of bad design (for example, FUSE is atrocious) or poor decisions that have been cemented by tech debt (smaller drivers that wouldn't take a significant performance hit from running in userspace)
other aspects are more structural, some core components like the network stack and bigger, performance-critical drivers (like for GPUs) can't be userspace processes in linux's monolithic kernel architecture, but microkernels are perfectly capable of handling this (see e.g. genode, fuchsia and nintendo's horizon OS)
the current governance structure is so impossibly resistant to change that these major flaws are effectively unfixable without either a hard fork or a whole new kernel, but this would be a monumental effort
0
0
0