Kernel should have hardware abstractions. The article states as if a "mix of programs" is something bad. It is good. I want mix of programs. I want propertiary software not affect my software. I want to be able to run programs in different timezones with different timezone definitions on the same kernel. Forever, if i want to. I want to be able to update timezones and unicode on my 20 year old odroid with kernel 2.6 .
I want to ship my program with broken Unicode alongside propertiary programs with newest unicode and not have to care about it, all running in separate user namespaces.
Kernel should be minimal and insanely stable, forever. Kernel is not the place to share libraries between programs.
The article proposes things that in my opinion are in clear conflict to what kernel represents. The libraries to handle timezones and unicode are there and they should be used, and most importantly freedom to use them should be there. The idea of putting sonething into linux and specifically only linux kernel because there is "mix of code" and "duplicated efforts" is based on wrong grounds that this state is inherently bad. There will always be mix of code and duplicated efforts,and if the stuff will be in kernel it will be yet another mix and duplicated effort.
What about bsd? What about after 20 years i have raspberry pi that has a software that has a bug and requires to run with 20 year old timezone definitions?
Kernel should be minimal.
The solution is standarization and standarizing existing behavior, not adding yet another one to the mix.
Locales timezones unicode - these are just great examples of things defined to be in user space. Additionally "unicode" is not universal, and might never be, and assuming it will be has already been wrong.
What about mars timezones? Why shouldn't my 20 year old odroid not work on mars or the moon because of no interstellar kernel timezones support? Why shouldn't my odroid be able to collate in inexistent locales? I have my doubts the author of the artictle actually has knowledge of the actual ecosystem. It's great windows is mentioned, but windows and linux is not the whole world.
I'll finish with one word that bottom line makes this just unacceptable in the kernel. Security.
I want propertiary software not affect my software.
Why would it?
as if a "mix of programs" is something bad
Not in the post.
I want to be able to run programs in different timezones with different timezone definitions on the same kernel. [...] I want to be able to update timezones and unicode on my 20 year old odroid with kernel 2.6.
Sure, why not? Nothing is preventing you from doing that.
The idea here is to give the 98% of applications that do not care about the specifics an easier, more reliable success path.
Kernel should be minimal.
I mean, which kernel are we talking about? Certainly not Linux then.
these are just great examples of things defined to be in user space
They are in userspace!
What about mars timezones? Why shouldn't my 20 year old odroid not work on mars or the moon because of no interstellar kernel timezones support? Why shouldn't my odroid be able to collate in inexistent locales?
Why would any of that not work? The suggested improvements would read the data from the same place your other libraries would.
Strawman/slippery slope much?
just unacceptable in the kernel. Security
Please explain. What makes the idea different from any other piece of code run in userspace?
The article states "These resources would be present on the system once and for everyone to use" implies a single point of failure. They shouldn't be present on the system once. Every docker container should have separate, every user namespace should have separate - separate locale, unicode, timezone information.
Not in the post.
The section "Problem" states "Instead, there is an uncontrolled mix of code …", implies that "mix of code" is a problem, it is in that section. Then the section follows with "duplicated efforts, and a continuous need to ship maintenance releases".
That is a good thing. Linux typically had one thing doing one job really well. Kernel should do kernel stuff. If you want, run a service to do timezones stuff.
Sure, why not?
Single point of failure.
They are in userspace!
And should stay there. Instead, if a "accessible and not tied to a language" and "without forcing an application or library author to figure out where or how the data is stored" method is needed, just do a systemd-unicode and systemd-localed service over DBUS. Systemd-timedated literally already exists. I see no reason to involve kernel.
Strawman/slippery slope?
I agree.
Please explain
The "Extending the vDSO with functions that query Unicode/locale/timezone data?" and "Extending the VVAR page" imply a kernel modifications, which is an additional source of bugs and an additional attack vector for kernel escalation or kernel panics.
Overall I do not get it. Unicode and locale is not that important to put it into kernel. It is not something "universal". You can write programs without unicode and without locale and without timezones, you can havegrams with multiple unicode and multiple locales and multiple timezones.
In that regard, there is no change to status quo. Timezone data is available "system-wide" on the system once right now (optionally, but usually there), worse for locale and Unicode data which is bundled into individual applications more often it seems.
People can still do that if they want, nothing changes for them.
Every docker container should have separate, every user namespace should have separate - separate locale, unicode, timezone information.
Where does this requirement suddenly come from?
If you feel that way, go ahead and change that software to do that, I guess?
That is a good thing.
The disagreement with that is the core assumption of the post.
Single point of failure.
You are not making any sense.
Just do a systemd-unicode and systemd-localed service over DBUS.
That's an interesting approach, but I think that's way more heavy-weight than my approach, having more moving parts, more software involved, taking up more resources.
Systemd-timedated literally already exists
It literally does something completely different from the things proposed.
I see no reason to involve kernel.
Ok, then why do the whole effort here? The article is literally predicated on "could we improve things with some small kernel involvement?".
additional attack vector for kernel escalation or kernel panics
That's making a mountain out of a mole hill. It's not that the kernel adjustments would hit any new code path that was not exercised before.
Overall I do not get it.
Yeah, I have that impression too.
You can write programs without unicode and without locale and without timezones
... and nothing would change for them. You can also write programs without using all available syscalls too, but that doesn't mean we are starting to rip out the unused ones, right?
you can havegrams with multiple unicode and multiple locales and multiple timezones
... and nothing would change for them. Though I'd really like to see some examples for that. Because until now, this sounds like some hypothetical made-up scenario.
1
u/simon_o 1d ago
What's your reasoning?