Companies do exist to try and hammer Linux into a good desktop/laptop product. I would say that it's just not easy to do given the lack of vertical integration. Redhat centralizing everything into systemd has probably gone the longest way towards improving things. Of course that is odds with the perceived benefits of having many competing options to perform the job of any given piece of software.
Indeed. Also remember that android supports multiple form factors and pixel at best served as. reference only for phones. Auto, watches, and tablets were ill served. Cuttlefish, the replacement, works for all form factors.
Does gnome officially support non Linux kernels? It's possible to implement the systemd APIs gnome is taking dependencies on without strictly using systemd itself.
What's interesting here isn't a strict dependency on systemd, but dependencies on some APIs it provides. Given the ability and existence of things which implement those APIs outside of systemd, it's worth considering that the APIs themselves should be the focus. Perhaps they should be spun out of systemd itself. It seems sensible to that gnome would want to move to a better API which is almost defacto a standard these days anyways. Versioning the API and allowing more folks outside of the systemd organization to participate in its continued evolution should be the focus imo.
The problem is that those APIs are not well documented, so reading the convolute source code may be the only documentation in some cases.
Perhaps there is some documentation, but it is well hidden.
Just these days, after being hit by the fact that the Xorg server has become dependent on systemd, I have begun to search for what elogind is really doing to simulate the login services of systemd. I have not found any easy way to discover that, except by reading the source code, which is not simple at all.
I would not care if GNOME or any other package would add systemd dependencies, but these were accompanied by a document describing precisely the protocols or APIs they use for accessing systemd services, so that it would be easy to write alternative implementations.
The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals. This is why I hate when such new dependencies are added.
> The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals.
The blog post subject of the thread literally links to the documentation. If you can't even be bothered clicking on the provided links, what are you even doing commenting on such a thread. But by all means, don't let facts get in the way of a good baseless rant.
syscalls are just a fraction of the surface area. There are many files in many different vfs you need to implement, things like selinux and ebpf, iouring, etc. It's also a constantly shifting target. The VM API is much simpler, relatively stable, and already implemented.
Emulating Linux only makes sense on devices with constrained resources.
On a non Linux OS that should be offset by being able to allocate RAM separately to each container instead of the current approach in Docker Desktop where a static slice of your system memory is always allocated to the Docker VM.
This a feature targeting developers or perhaps apps running on end-user machine where page cache sharing between applications or container does not typically get much of RAM saving.
Linux kernel overhead itself while non-trivial is still very manageable in those settings. AWS Nitro stripped down VM kernel is about 40 MB, I suppose for Apple solution it will be similar.
go is ill suited for many systems programming environments. It works well on servers and larger iot devices with 512+ mib off ram, but not great on things with tighter constraints. We tried to use it for our netstack implementation for years and ultimately came to the conclusion we needed to switch to a language with greater control. Storage, RAM, and CPU usage were all improved with the switch. I don't consider it a systems programming language but rather something approaching systems programming.
std vs nostd is another big one. Within nostd there are a ton of tiny fragmented worlds. For example, the Linux kernel ecosystem will likely development its own flavor of rust, especially when it comes to memory model. Old Linux distributions will end up with fairly ancient compiler versions that require code to stick to older conventions. I doubt well end up with people stuck on targeting c89 sort of situations, but things may trend in that general direction.
If you develop that for servers or mobile/desktop applications it might look more homegenous, but their are a lot of segments beyond those out there.
reply