Non-goals
Does not have to support the runtime installation of kernel modules. This will prevent the out-of-the-box installation of, for example:
- Proprietary NVIDIA kernel driver (NVIDIA GPUs must either be new enough to use the open-source kernel modules that can be distributed in-tree, or else use Nouveau)
- VirtualBox (requires out-of-tree modules; QEMU/KVM probably do a better job anyway)
- Vendor-specific VPNs that require custom out-of-tree kernel modules that cannot be redistributed with the kernel due to license incompatibility
Does not have to support the use case of developing low-level system components like the kernel, drivers, systemd, etc., as this can be troublesome with an immutable base OS.
Does this part mean there will also be no support for ZFS?
If they’re not including the proprietary Nvidia driver, they’re definitely not including ZFS.
Fun idea but it’s just a 2 page design document.
It’s already in use on a dozen or more physical devices as a usable OS…
although this is cool, i’m a little on the fence, as i’m still not sure if it’s the job of application/desktop developers to create an os.
also, last i heard, nouveau doesn’t get commits for about a year now. support is pretty hit or miss. my graphics card is one of the best supported by nouveau and it works pretty well but it will freeze at least once a day, which is why i had to stick to the proprietary driver
Which GPU?
01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])pretty old gpu, but some cheapo graphics cards, especially in brazil, are still being sold brand new with gpus around the same age.
Ah yes. I used to have a GTX 1060 and was pretty pissed off when they said the new open source driver would only support from 1660 onwards (or is it 1630)…
Yah, nobody with 5 minutes of KVM under their belt would bother with Virtualbox.
Hmm, Arch-based.
Hmm as in good?
Or hmm as in you are apprehensive?
Neutral. I’m just curious how it will work. Comparing with Debian/Ubuntu as a base.
Debain/Ubuntu are always a little behind on library and Qt versions etc. For example with KDE Neon on an LTS they had to overlay/patch many libraries which ended up breaking most of the Qt applications that users could install from the Ubuntu repo. Arch is almost always up to date with the latest stable releases of libraries and Qt making it an ideal base for KDE Plasma which is a fast moving desktop.
Arch is almost always up to date with the latest stable releases of libraries and Qt making it an ideal base for KDE Plasma which is a fast moving desktop.
are you involved in this project? i have a little bit of a gripe with this approach. unless your idea is to aim this os at enthusiasts instead of the general public, the user should not have to worry about large upgrades that might leave the system in a broken state. this is why debian is always a little behind: making sure a bunch of different components in a million possible different combinations all work well together is hard work and it takes time. i’m not even saying it’s not possible to use a rolling release model and have a user friendly distro (opensuse tumbleweed does it pretty well), but reliability comes before software recency imo.
edit: btw this is why i said i’m unsure making an os is the job of application developers. what’s ideal for the developers might not be ideal for users.
Yes I am involved in the project. As for not worrying about large system upgrades, things break, no matter how much testing you do on them. For running KDE I prefer to run the latest, it has the least bugs and the newest features.
There will be at minimum 3 editions of this OS, one for developers and those who love to live on the bleeding edge, one for enthusiasts and one for general users. The one for general users will be well tested and aim to have zero showstopping bugs.
deleted by creator
For whatever it’s worth, I use (up until fairly recently) KDE Plasma on Arch, and it’s pretty much fine. There’s some hiccups especially after a big update such as KDE Plasma 6, but it’s a smooth ride so far.
If the KDE Plasma developers support an Arch-based distro of their own, and package stuff for this distro with care, I think it’d be a better experience, but I am guessing not by much compared to KDE Plasma on base Arch.
I think dropping loadable module support would severely limit what users can do when a driver misbehaves or doesn’t handle a particular device as well as an (in-tree) alternative.
Also, I wonder how they expect to achieve being “The KDE operating system” or “doesn’t break” when their existing distro has been more than a little rocky so far. Who do they think will do the long-term work of raising and maintaining the quality bar?
It would be kool to have a solid reference distro where Plasma could shine, especially for organisations and newer users who don’t know how to replace GNOME on existing distros. But this proposal gives me the impression that they underestimate the effort required, so I am skeptical.
The existing distro Neon has issues generally because of their choice to use Ubuntu LTS as a base. This is because KDE Plasma needs newer libraries usually than Ubuntu LTS can provide so they add newer libraries in their repository which often breaks existing apps in the Ubuntu repository. Having to patch and bring newer libraries all the time takes its toll. Basing it on Arch means they’ll almost always have the latest libraries ready to go.
The existing distro Neon has issues generally because of their choice to use Ubuntu LTS as a base. This is because KDE Plasma needs newer libraries usually than Ubuntu LTS can provide
In other words, they don’t have enough resources dedicated to doing it well. This is part of the problem I described.
Basing it on Arch means they’ll almost always have the latest libraries ready to go.
That could reduce the work required in one area, but would increase it in another. Arch fails the “doesn’t break” goal on its own, which means someone would have to do more work if they want to achieve it.
In other words, they don’t have enough resources dedicated to doing it well.
No they’re resourced quite fine, trying to mash old with new is never going to smooth.
That could reduce the work required in one area, but increase it in another. Arch fails the “doesn’t break” goal on its own, which means someone would have to do more work to achieve it.
And that’s why they have each release as it’s own btrfs subvolume, if it breaks, you roll back, done. There will be 3 (maybe 4) variants and users will be encouraged to run the “stable” variant which is managed as a snapshot in time deployment where KDE Linux and KDE devs together agree that the system is stable and has 0 critical/showstopper bugs.
Good luck. :)
deleted by creator
