What about someone trying to use AI to make a new version of Qubes OS?
Similar to the problem described here, where someone used AI to rewrite Chardet and release it with a different license.
I don’t know if this is legal, but it does seem like something that has the potential to become problematic in the future.
I think Windows 11 uses AI and lacks sufficient testing and validation. However, if people contribute code after doing thorough testing, and if the acceptance process includes enough verification and testing, it probably wouldn’t cause too much negative impact. Besides, compared to mainstream Linux desktop environments, the number of people contributing code to Qubes OS is already quite small anyway.
Somewhat off topic, but given how many ways there are to contribute, the
number is very small.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I would just like to bring up a way in which using AI can actually increase the number of all code contributions, be it exclusively man-made or AI-augmented work. AI can be used to protect against supply chain attacks, along the lines of what socket.dev does. This would lower the burden that individual developers have to carry when it comes to securing their private keys and thus lower the barrier to entry to developing new software for Qubes OS, a situation that I find myself in.
This becomes more relevant as the user count and total value secured by Qubes OS goes up – but we saw very strong growth in the last couple of months already.
From a user that is from the project manager/operations areas and NOT a developer by trade. I think this is a area that cannot have an ostrich head in the sand mentality and it is best to get a policy/guidance out. I have no interest in more brain rot, AI slop ala youtube or the security/privacy dangers that come with it. The reality is AI is here and must be addressed. I for one struggled with Saltstack and in particular on Qubes and AI has help me personally in 4 days clarify my understanding and actually produce deliverable code that I have been struggling with for months.
Bottom line is it is all built on trust, a contributor that won’t disclose is in effect a malicious contributor. We all have areas we must trust to various degrees, DNS, Cerificate services, etc. The project has many areas of trust already, the hardware, firmware, Xen, Fedora, Debian,etc. and they have their process to evaluate this and in turn or they revoke trust. AI is a tool just as more advanced coding environments (IDE’s) are. Keeping a human in the pipeline keeps responsibility and accountability where it should be hopefully from the contributor side and the code review/approval side.
I fore one welcome the use of a tool, with proper safegaurds/guardrails that likely will help with backlogs of bugs, hardening the system, and possibly bring in more users by developing more and more ease of use.