Looking at Team | Qubes OS , it seems there are only 5 coders working on Qubes. This seems like a quite small amount for something as ambitious and complex as Qubes OS. Even Linux Mint which is just a fork of Ubuntu has more people working on it (at least what they officially state).
I can’t help but feel somewhat worried about the long-term future of Qubes OS, even more so that Xen itself also is not really used by any big player (last one was Amazon who switched to QEMU/KVM) which also may be bad for its long-term future.
The design means I’m much more comfortable with this project having a small development team than I would normally be. I hope they don’t all get in the same cars, though.
More people getting involved would be nice, but it’s a niche operating system and I think the entry barrier is quite high to get started, it is really complicated IMO and there are not much developer documentation for newcomers.
I do. I think that due to the huge room for improvement for such thing as OS and its complexity, the current development is not fast enough to even keep up the situation at the same level, to keep the OS stable.
Some things are inevitably drop off and stay unfixed for way too long to call the Qubes OS stable or average-user compatible. E.g. currently we lost QWT for Windows that was working from version R1.0 or something, and there are no man power to get it back, in R4.1 keyboard layout switching was not working properly, huge regression that was not fixed during R4.1 lifetime. Third-party contributions are not accepted for years, too, because even accepting third-party free help also requires work from the Team.
So, many things that require attention are not processed due to the lack of software developers, so I share your concerns.
Of course, not big. It’s even not a software “player” in the first place. And if they really have a lot of software-developers-resources, they can switch to KVM or something, too.
Don’t you agree, that Xen is not very “popular” nowadays, most virtualization cases, including hostings, are leaning towards other virt solutions?
Let’s start with the official Xen Project website - it’s stated that The Linux Foundation® has the copyright to it.
Furthermore, I wanted to address the messages that are to give the impression that “it’s just some no-name project that nobody uses”, despite the official endorsements at the Project’s website and the document I posted in my earlier message.
The choice of a hypervisor can mean different things to different people and I don’t feel like speaking on behalf of companies, which heavily utilize virtualization for their cases (among which could be hosting virtual servers), especially since I don’t work for them and don’t know, why the choice has been made.
Or maybe I’m missing the point and people are worried something I’m not aware of yet, when it comes to virtualization solutions and their popularity - If so, my first guess would be about some hypervisor functionality that is not yet implemented. However, if there’s a reasonable demand for that, I’d start with the following GitHub tickets:
and then either contacting Invisible Things Lab to ask, how much would such a huge effort cost, or setting up own team, who could then spend time developing such a solution.
There’s a fundamental misunderstanding here. The size of the team bears
no relationship to the number of people contributing to Qubes. It’s an
open source project that any one can fork, or to which any one can contribute, by
proposing improvements or by submitting PRs.
It’s not uncommon to have numerous contributors but only a few core
team. In some projects there are many contributors and only one
dictator, benevolent or not.
More people ready to make a contribution would be a good thing, but I
would not give up the oversight and judgements made by Marek et al.
Others have offered a correction on this. But note too that the link to
Xen is historical and not essential.
Perhaps. Not me.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
One could give money, the transparency reports include all expenses, some people are paid to work on some parts / features. See Qubes OS · Expenses - Open Collective
Yes, that’s definitely important, if one can donate they probably should!
Spark a discussion like this one. I’m curious what is the reason: do they think they have enough resources as it is? Does complexity scare newcomers away? Is the funding insufficient? Are there other organizational issues? Everyone could probably agree that the project would benefit from more manpower.
I agree regressions should always be #1 priority even during lifetime of a release. I never needed many keyboard layouts or even Windows VMs for that matter, but it does sound bad.
The OS is still even missing basic functionality one would expect from a desktop OS like: incremental backups, GPU acceleration (not just passthrough), or a proper dark theme that actually works…
Can you elaborate?
That’s what saddens me the most: that outside of security enthusiasts that care about their personal data, no one really cares for secure desktop computing. Everything seems to be focused on server security (like SELinux/AppArmor). Flatpaks are one half-assed attempt at desktop “security” but they are pretty bad because it fully trusts the app devs to create their own policies and too many of them simply come with filesystem=home. I wish Linux had a more secure app model like Android does.
A project like Qubes should gain a lot of traction and support from big players like Red Hat, hell, even hardware manufacturers that would avoid many hacks that Qubes does. But again, just no one really cares for desktops. Another “Qubes-lite” of sorts project is SpectrumOS, but it also seems to be just one-man small-house project with no real traction.
What is there about Qubes design that justifies smaller team?
Yeah, I thought about that too… but thought it inappropriate to mention here
It’s hard to motivate people to use a system where video conferencing barely works or requires a very powerful machine
It is also complicated to deploy Qubes OS in a corporate environment with remotely managed account, I suppose Invisible Labs business relies on this kind of setup though.
Spark a discussion like this one. I’m curious what is the reason: do they think they have enough resources as it is? Does complexity scare newcomers away? Is the funding insufficient? Are there other organizational issues? Everyone could probably agree that the project would benefit from more manpower.
If you think those are the issues, the only thing you can do is:
I’d love to have it. Preferably it should be available (optional) out of the box, with salt command or some package installation, not third-party solution. Because the lack of reliable and production-ready remote control (like VNC/RDP) stops Qubes OS from being used on PC-routers.
VPN chains, including shadowsocks, tor and other stuff, network virtualization solution (with cross-vms connections) that are available out of the box: all that are unique features of Qubes OS, that cannot be used in router-type PCs, because to change something user is required to connect keyboard, display and mouse each time.
Well, that is kind of a problem I see and raise from time to time: there is no actual long-term priority list, plan or roadmap. You cannot know what Qubes OS is expected to be in a 2 years or in 5 years. Only some vague things, like, probably it will support wayland eventually some day.
Which is not a roadmap, of course.
This worries me even more than the lack of software developers, because I see no picture of future of the only OS I love.
