Fedora AI Developer Desktop Initiative (updated)

Project Discussion
1

Continuing the discussion from Fedora AI Developer Desktop Objective:

AI Developer Desktop Initiative

Status

This proposal is a request for comment. Please suggest changes, and express interest if you would like to work on any of the issues described below.

Introduction

The Fedora “AI Developer Desktop Initiative” aims to build a thriving community around AI technologies with a focus on three key areas: equip developers with the necessary platforms, libraries, and frameworks; ensure users experience painless deployment and use of AI applications; and build communities to foster mutual support with upstream projects and to solve the problems that have limited participation in the past.

Community building and effective outreach are skilled endeavors, often distinct from a developer’s core expertise. This initiative will bridge this gap, help developers find an audience for their work and ensure that their users can easily run and engage with their applications.

Outputs of this Initiative are expected to work on all platforms, from ARM, AMD, Intel, and NVIDIA accelerators. We also hope to provide hardware optimized experiences that go beyond the baseline outputs. We want to prioritize and promote Free Software in Fedora, but we also want to demonstrate that interested third parties can build on top of Fedora systems.

In short, the Initiative will focus on developer tools, community building, and platforms and packaging. Its intent is to determine what barriers to participation exist, and to resolve them through demonstration, documentation, fixing bugs, and improving tools.

Current Issues

Fedora’s “Four Foundations” suggest a project that actively engages with emerging technologies, but when we look at software development in the AI/ML field, we often see documentation, development pipelines, and software delivery streams (such as container images) that feature competing platforms.

The purpose of this initiative is to demonstrate ways that Fedora can be used by third parties and to identify the ways that Fedora might be hard to use and to smooth out rough edges.

Complex initial setup turns away prospective users

Fedora provides applications and an operating system on which to run them. A great deal of the work we do to package applications is to ensure that they require minimal post-install configuration in order to be usable. This isn’t always the case with AI tools, and local setup complexity varies significantly across hardware vendors. The ideal operating system is built and tested before users deploy it on hosts; we would like to minimize the amount of build and configuration that happens at the deployed system, and therefore the amount of expertise required to install, configure, and use AI tools and workflows.

Kernel and modules

The purpose of the stable release process is to allow users to test a new release and upgrade on asynchronous schedules, by continuing to support previous releases.

Reliable systems generally follow a pattern of build, test, deploy, but many users today use software that requires a deploy, build, test pattern (i.e. akmods). Users frequently disrupt the build because it doesn’t provide enough feedback, and if an update doesn’t work properly there may not be an obvious rollback process.

The post-install build system is also a challenge for Atomic systems, and at odds with the fundamental motivation for those systems. For the security-minded, the status quo supports Secure Boot only through the use of a local signing key, which offers only the illusion of security, since malware can use the officially supported module install infrastructure to install itself.

Packaging

Complex applications can be very difficult to build in Fedora. Some applications include deep integration with their dependencies, and often use private interfaces. The ability to integrate deeply with dependencies is an advantage of Open Source software, and it encourages a development approach in which components are not siloed. But the cost of that integration is that an application may require very specific release streams of its dependencies. As Fedora is structured today, this places a responsibility on the dependency maintainer, for a benefit expected by the application maintainer.

There have been several attempts to solve this problem or similar problems in the past. Modularity, Software Collections, and containers all approach this problem in different ways. In a general sense, they provide some form of isolation in which an application can be built with its dependencies, and that isolation reduces the friction inherent in the attempt to build one coherent collection of components.

Addressing this is essential to building applications like vLLM (a library for LLM inference and serving), and similarly complex applications in the future. I expect this to be the most complex of the problems to solve, and probably the last deliverable goal. Delivering vLLM may be a sign that we have made progress in this area, if we believe that the approach that enabled its delivery will be generally applicable to complex applications in the future.

No specific solution to this problem is presented as a part of this proposal. Above all, this proposal is an invitation to participate in resolving a problem, not a directive to deploy a finished solution.

Logistical

Many upstream projects lack documentation for Fedora, in part because the OS requires configuration that varies from one hardware vendor to another. When an application developer sees the need for documentation that varies across distributions, and further across hardware vendors, they may choose to focus on the systems that require the least variation in configuration before the user is able to install and use their application.

This can become a self-reinforcing loop, where the appearance that Fedora is not supported causes users to select another platform, which leads to a user base that exclusively uses another platform, which reduces the motivation for documenting software use on Fedora.

Legal / Policy

Fedora is dedicated to Free and Open Source Software. We build and distribute software that users are free to modify to suit their needs and to share with others. While Fedora can’t deliver non-Free software directly, we can build relationships with developers who want to provide users with complete systems that include their software. Those partnerships can expand the community to include users and developers who rely on low-level APIs that are not Free Software.

Deliverables

This initiative will demonstrate ways that Fedora can be used by third parties and to identify the ways that Fedora might be hard to use and to smooth out rough edges. Producing the following deliverables will help us discover the challenges and measure progress (whereas uptake is a goal that is more difficult to measure and may develop over a longer period of time.)

1. Document and demonstrate the process of building kernels and modules outside of the project for use by Fedora users. For example, build an LTS kernel as a third-party to deliver the benefit of a stable release process consistently, across the release. These builds may be used in a Remix.

2. Build and sign the NVIDIA out-of-tree Open Source kmod, OpenRM (until the Nova driver is ready), as a third party to eliminate the need for signing keys on the device where the keys are used, to provide a standard best practice build-test-deploy sequence, and to enable an Atomic system Remix to support NVIDIA hardware. (Fedora will not sign the certificates or builds involved.)

3. Publish an Atomic system image focused on support for accelerated AI workloads, composed of only Fedora artifacts, as a Fedora Spin.

3.1 Publish a variant of that Atomic system image with third party kernels or modules, as a Fedora Remix.

4. Include user-friendly tools common to various AI back-ends, such as Goose CLI and Podman Desktop.

5. Provide a contribution guide and invite community developers to directly improve the image rather than writing post-installation configuration guides.

6. Document the installation and use of Free Software projects on Fedora systems, either as contributions to the documentation provided by upstream projects, or within Fedora’s documentation.

7. Publish optimized Fedora container images for machine learning applications, aimed at AI developers.

8. Improve Fedora’s support for complex applications, which often require very specific dependency streams.

Timeframe

  • Platform work, Deliverables 1-4 by F45 release

  • Community work, Deliverables 5-6 by F46 release

  • Developer tools, Deliverables 7-8 by F47 release

Outreach

Fulfillment of this initiative will require outreach both inside Fedora and beyond. Specifically contemplated contacts include:

  • Universal Blue: Are there common objectives in our work and if so, could we work together to help both efforts?

  • NVIDIA: Is there an interest in a Fedora Remix for their developer community?

  • AMD/ARM/Intel: Provide first-class acceleration where there is upstream support

Feedback

We’ve talked to Fedora’s kernel maintainers and others to clarify that during this initiative, we intend to build kernel and module packages outside of Fedora, and we do not expect those binaries and packages to be signed with Fedora certificates. Furthermore, the longterm kernel package is one possible path to deliver out of tree modules, but not the end goal itself. The end goal is a module packaging process that works reliably without akmods/dkms.

Interested People

Máirín Duffy

Tom Rix

Initiative Lead

Gordon Messmer gmessmer@redhat.com

History

May 19 - Narrow the scope of Remix characteristics, clarify the intent and process of kernel and kernel module builds, expand on the work required for packaging

Notes

A preview of the desktop Remix is here: https://quay.io/repository/gordonmessmer/atomic-desktop/silverblue

The ostree config for that remix is here: https://pagure.io/fork/gordonmessmer/workstation-ostree-config/tree/

The longterm kernel with nvidia module used in that remix is here: https://copr.fedorainfracloud.org/coprs/gordonmessmer/kernel-longterm-6.18-plus/

Non-goals:

The system image will not be pre-configured with applications that inspect or monitor how users interact with the system or otherwise place user privacy at risk.

Tools and applications included in the AI Desktop will not be pre-configured to connect to remote AI services.

AI tools will not be added to Fedora’s existing system images, Editions, etc, by the AI Desktop initiative.

Planned work is not expected to change the kernel or kernel module policies, binary content policies, allowed licenses, or the AI contributions policy. Any changes within Fedora will follow the standard changes processes

2 Likes
Fedora AI Developer Desktop Objective
Fedora AI Developer Desktop Objective
Fedora Initiative for a Potential AI Ecosystem
F44 FESCo Elections: Interview with Michel Lind (salimma)
F44 Council Elections: Interview with Akashdeep Dhar (t0xic0der)
2

The revised draft above addresses some of the feedback from the earlier discussion thread. If you have concerns that are not addressed by this revision, please re–state them here in this thread.

3 Likes
3

I’ll start off by revising my own opinion.

I am not personally fond of AI-heavy operating systems, like MS Windows, and the idea of integrating AI into every workflow. And I doubt that the Fedora community would like the integration of NVIDIA’s open source kernel driver portion of the blob, or whatever you call it, either.

The members likely take that initiative as an attack against their sovereignty, since it allows for a possible open pathway, or justification, for NVIDIA’s proprietary blobs to be included as well.

However, if the proposal is to build an alternate AI stack or something similar, like NVIDIA’s, than I would be 100% behind that, and I’m sure the Fedora community would be behind that, as well. I’m sure many developers, engineers, and various other individuals who work with AI, would appreciate it.

1 Like
4

I do think it is also important to note that collaboration with NVIDIA shouldn’t be off the table. I think it would be best for Fedora to have a healthy rivalry against NVIDIA, with each group having their own ways of managing their stacks, while also knowledge sharing. It would be better for both groups.

All in all, in my opinion, the best option for Fedora right now, is for them to open communication channels, to developers, executives, and other people who may use AI in their daily work. And most importantly, figure out what works, and what doesn’t.

5

Regarding #2 is it possible to get clarification on whether the intent is for those pre-signed kernel modules to be trusted by default, or is it just that a mechanism for semi-automated mokutil --import will be provided with a pre-shared key (akin to how, for example, Bazzite works) that still requires user intervention?

6

Neither the certificate nor the objects will be signed by Fedora, so more like Bazzite from the user’s point of view. However, the intent is to avoid akmods and use an HSM for signing.

I’ve updated the proposal to clarify that point.

7

Thanks for the revised proposal.

IMO, these parts should be removed from the official initiative, since they are not happening within Fedora and don’t follow Fedora policies.

I assume you’re aware of this, but Podman Desktop is nontrivial, since it depends on electron which is a big undertaking to package and has not been done in Fedora yet.

Just pointing out that this will require coordination with the FPC and the relevant language SIGs. For our part, the Go SIG has made some strides in simplifying packaging, and I know that ollama takes advantage of the new Go packaging tooling.

vllm looks like it’s written in Python with C++ extensions. Is there a particular problem that makes it difficult to package vllm for Fedora?

1 Like
8

Hey @gordonmessmer! First off, I want to share my appreciation and gratitude for the work you are putting in to revise the Initiative. I think the Feedback section is a great addition in this draft. :+1:

More specific feedback and comments below.

Minor detail, but the proposal says “this objective”, “the Objective”, etc. in a few places. For consistency, we should use the updated name: Community Initiatives.

These are reasonable goals. Many of them are potentially easy to measure too, which helps us know if we are successful or not. From my perspective, the proposal allows room for experimentation without forcing changes on other maintainers or contributors. I like it!

To make sure I understand the proposal right, are you proposing to work on solutions to each of these current issues? Or are you building the context for why this work is needed? Either is fine; I want to make sure I am reading your intent correctly.

Perhaps it is worth hinting to the idea of leaning into Fedora Remixes and the Fedora Remix trademark here? Obviously, this is a core concern for a lot of people, but we also don’t want to shut the door on anyone willing to show up and do the hard work to make a great Linux desktop experience. We cannot compromise on our values for the core project, but the Fedora Remix trademark is perhaps the right vehicle to encourage those extending proprietary software and libraries on Fedora without creating a lot of friction in the core community, if it feels like proprietary bits being hoisted into Fedora. (Which is not what I am reading here.)

The deliverables seem well-scoped and achievable. :+1:

I personally appreciate the distinction about the Fedora kernel bits. It is much more obvious to me now that the Fedora kernel policy is not being revised, but we are trying a new approach to do something different, without changing the status quo too much. (If this is wildly successful, then we may need to think again on Fedora kernel packaging, but that can come much, much later.)

Ambitious, but I like it.

These are great questions. If we can involve other partners in our ecosystem into the fold, this feels like how we do it the Open Source Way in Fedora. From what I can tell, there is an interest to collaborate here too.

I am happy with what I am seeing so far. I am aware that you are also working on the logic model too, which I think will present a helpful visual format to everything you are mapping out here.

I am not seeing anything in this proposal that feels like AI is getting integrated into userspace. The emphasis is heavily on the developer use case, for people who want to work on these tools and stacks, but have a difficulty in doing so today on Fedora.

I read the non-goals as very clear distinctions of what is not being done here, and I think that addresses this consideration?

I think in order for anything like this to happen, we need to first be able to use the hardware and tools we have today to drive more FOSS into other places. If we cannot use it, it is hard to build it!

Sounds to me like this is what is mapped out in the proposal. Do you agree?

So, per the previous discussion topic, it is good to ask clarifying questions. And Gordon already answered here too. But I also think that some of this will be figured out iteratively. The goal is not to have a fully-completed Gantt chart with firm, rigid ideas of what has to be done. The right way to do this in Fedora is to do it openly, collaboratively, and with room to participate as things move forward.

I am seeing this in Phase 2 of the existing, proposed timeline.

Hmm, I disagree. I think they should be part of the Initiative. It might not be happening in Fedora, but I think doing it as a third-party with Council and community input is valuable. In fact, I would rather have someone do this together with us than go off in their own world and do it in a vacuum. (TBH, this is the reason I voted in favor of the Initiative the first time. I want people to work with us on doing this in a way that is sensible and not creating more busy work for others.)

Sounds like part of the challenge to me. :grinning_face:

I bet @gordonmessmer has an idea on how to answer this, but per my above point, I also think our goal right now is to focus on the top-level stuff and the big picture. It is fine to discuss this, but I also want to make sure from a Fedora Council point-of-view, we are focused on the big picture ideas and issues, and leave room for the detailed, technical bits to flow their way through FESCo via the Changes Process.

In effect, this is how I see Fedora having “oversight” on the technical changes. When bigger things need to come along and be changed, it should be driven through conversation and debate at the FESCo level.

4 Likes
9

The very broad answer is that Fedora packages tend to be built for one combination of release streams or for a very small number of combinations of release streams, and those aren’t necessarily the right combination for every application.

So, vLLM might need PyTorch, but it might need PyTorch for Python 3.12, while Fedora is building PyTorch for Python 3.14.

In my opinion, if there is a group of developers who want to build vLLM in or for Fedora, we should empower them to do that, and we shouldn’t put more maintenance burden on the people maintaining PyTorch. I think this is one of the class of problems that Modularity intended to solve, but now we need some other approach.

3 Likes
10

I’m not quite sure what you mean here. People can buy their own hardware, if they wish. If people wish to use the stack, than they will use it.

For the most part. However, the slippery slope problem may still come up if we accept the proposal as-is. Fedora members, from what I’ve read, don’t appreciate proprietary user space software, and they don’t want a hint that this is where this proposal will end up.

For all intents and purposes, it would be safer to exclude the signing of the NVIDIA kernel module. It is important to keep the Fedora community’s wishes in mind, here.

Again, if Fedora collaborates with NVIDIA, and they are able to open source major parts of the NVIDIA stack (like CUDA), then the signing of the NVIDIA KMod would be more acceptable, since a larger part of NVIDIA’s stack is now open source.

My point regarding the KMod signing is that there are better ways to tackle this problem.

11

Thanks, I’ve updated the proposal.

I think that there’s at least one deliverable that’s relevant to each of the “current issues.”

That’s my thinking, too. I want to make sure that developers know this is an option and provide examples of how it can be done. And as much as possible, I want to make sure that all options work, whether a developer wants to build a new layer on one of the images that Fedora builds, or they want to build a base layer from scratch, etc.

How would you rephrase the proposal to lean in further? (I can think about this more if you don’t have a suggestion.)

2 Likes
12

A question I have is, if a Fedora remix can be created by anyone in the community, than why is the signing of NVIDIA kernel modules being proposed by the council in the first place?

A community member could just remix Fedora with full blown CUDA, and nobody would even bat an eyelid. Counter to this, integrating CUDA into Mainline Fedora is obviously not feasible, given the rules.

Assuming that an initiative to bring the community together is made, is it really necessary for the initiative itself to contain the quote below?

Couldn’t a community initiative council separate from Fedora be established, where this is decided? Wouldn’t the people who act to make the initiative happen, decide by their own merit that the NVIDIA kernel module should be signed by a given Remix maintainer?

I am all for playing the drums. However, the drums must be played right. If you play the drums in a manner that sows discord, than it will go against the goals of the initiative. Again, I ask you to sincerely reconsider and think about what you’re trying to accomplish.

13

accelerators covers a lot of ground. ex/ Intel GPU or NPU or Gaudi ? list the accelerators.

If there work, list the other accelerators in the deliverables, otherwise remove mentioning them.

I would like to see Fedora native packages in the deliverables.

This looks like a lot of work to do an oot driver, remix, make containers, but nothing for base fedora. Is this correct ?

14

People can buy their own hardware, but using the hardware with existing userspace tools and libraries is hard on Fedora. If it is hard to use the tools to be a builder of new things, people will go and build new things elsewhere.

I personally disagree. From my read on the proposal and various places where this has come up (e.g., mailing lists, Matrix rooms, The Register, LWN, etc.), this does not feel like part of the plan. Fedora users and contributors are understandably concerned, but there is very little to this proposal which is actually focused on the userspace at all.

I am willing to rethink, but the original post seems clear to me. Having an ideological debate on whether anyone could or should do this work is not helpful, in my humble opinion.

The Fedora community is vast, and neither you or I can individual speak as the entire Fedora community. There are also several people who want to see this work move forward and have Fedora be a comfortable place to build and hack using the latest hardware, tools, and libraries. After all, one of the key Four Foundations of Fedora is First! This feels like a call-to-action for us to get ahead of the curve and bring Free Software into AI, instead of playing catch-up after everyone else already influenced the future.

Perhaps so, but given that the actual Fedora kernel update policy is not being changed or amended here, why is it a problem for them to try and experiment? Maybe there are better ways, or maybe not. But I think the folks doing the work deserve the benefit of the doubt.

I would feel different if this proposal was advocating to change how Fedora ships and updates its kernel, but this is not what is being proposed here.

Hmm, good question. Perhaps you could unify the individual deliverables around the united deliverable of a Fedora Remix. I think all of the things you are proposing are logical, and some of them would more easily fit within the existing values and policies we have in Fedora today. However, emphasizing that the first general deliverable could be a Fedora Remix installable image with third-party repositories (or something like that) could help bring it all together.

I see the Fedora Remix as being the thing that glues all of your deliverables together. Maybe each deliverable could touch on how it fits into a Fedora Remix? I’m not totally sure either here, but I think it is okay to say that some details will be figured out iteratively, and a Fedora Remix provides the framework for doing this work in a non-disruptive way without forcing anything into Fedora that could go against our values and principles.

  1. The signing of the Nvidia kernel modules is not being proposed by the Fedora Council.
  2. A Fedora Community Initiative is being proposed to the Fedora Council.
  3. @gordonmessmer is bringing the proposal to the Fedora Council as a community member.
  4. Essentially what is being proposed is a Fedora Remix with more guidance and input from Fedora leadership, instead of going off on a lone-wolf journey. We are better when we go together!

I am not sure I understand you correctly, but it seems like you are proposing an altogether new governance body in Fedora? A council to review Community Initiatives? This feels duplicative of the existing role of the Fedora Council, which shepherds Initiatives. It also feels duplicative of FESCo, which is where the real technical leadership of Fedora lies. Not only would creating a brand-new governance body come with a lot of added work to maintain, but I see it as being harmful to the existing authority already delegated to the existing leadership bodies.

Your second question here did not make sense to me. If I did understand it right, then this would already be how it works?

I am trying my best to walk in your shoes here, but I am not seeing the proposed plan as being a route to sow discord. I see an approach that leans into the Open Source Way of building on top of Fedora Linux, extending our packages and software into a new Fedora Remix, trying out some interesting ideas which may or may not work, and then reflecting on what worked well, what didn’t, and where we go next from here.

I believe we should consider the role of the First Foundation in the Fedora Four Foundations. From the official project docs:

We are committed to innovation.

We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution.

At any point in time, the latest Fedora platform shows the future direction of the operating system as it is experienced by everyone from the home desktop user to the enterprise business customer. Our rapid release cycle is a major enabling factor in our ability to innovate.

We recognize that there is also a place for long-term stability in the Linux ecosystem, and that there are a variety of community-oriented and business-oriented Linux distributions available to serve that need. However, the Fedora Project’s goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first.

So, I think this proposal is fully aligned with the spirit of what the First Foundation is all about. Let’s advance the the future, first, and not wait to let everyone else do all the heavy-lifting. Additionally, in the spirit of the Friends Foundation, I have observed real, genuine work by @gordonmessmer to address community feedback into the proposal since the original discussion and Fedora Council ticket vote.

The reason I changed my original vote to -1 was because I felt we were moving too fast to incorporate all of the feedback that was coming our way. It is a hard thing to do, actually. Fedora Discussion/Discourse can be great, but also, it can be really hard to keep up with the pace at which our community voices their opinions. I think we needed more time to consider all feedback. I am seeing a positive change from my perspective of making sure we are incorporating feedback from the community, while also being careful to avoid any changes which might cause significant disruption to the wider community.

And as far as technical changes go, that is up to FESCo to review and decide on the System-Wide and Self-Contained Changes. The role of the Fedora Council here, in the context of submitting Changes to FESCo, would be to facilitate the Initiative lead and their team to send a quality Change proposal to the FESCo desk.

15

FYI: I closed the previous Fedora Discussion topic about the Initiative and redirected folks to engage here to share feedback and input on the current state of the proposal.

16

Again, I must state that by including this excerpt in the proposal:

– you risk fragmenting the community. I’m sure that the very developers and package maintainers who can help build an amazing distribution, are the ones who advocate for Fedora’s long standing policies the most.

Admittedly, I don’t really have a say in whatever decision gets made. I can’t really consider myself a community member. However, those rules were placed there for a reason, and it is to protect Fedora’s sovereignty. There is something to be said about the spirit of those rules.

Why do you think they state specifically at Making sure you're not a bot! that:

– ?

They could’ve simply stated that packagers are not allowed to package closed-source code. Yet they went the extra mile, and stated that no module that requires code/packages from third-party sources are acceptable for inclusion. This is in spite of whether or not the module itself is open.

Again, I am not a Fedora community member. I don’t claim that I know what the community as a whole, wants. However, I think the spirit of the quoted statement above is clear. Members don’t seem to want to put their direct efforts towards an initiative that may possibly result in a large part of the user space ending up closed-source down the line. It doesn’t matter if the current initiative is proposing to allow a partially closed-source user space.

It would be better to simply scrap the idea of building and signing the NVIDIA KMod altogether. The community fragmentation risks are very real, and I’m sure you guys don’t want things to get ugly down the line. A divided community is far less powerful and influential, than even a community that follows some arcane law set down by god knows who (who was very much perceptive and wise, by the way). This is a great community, and I wouldn’t want to see it go to waste.

18

I want to take a step back and clarify the intent behind using the “Fedora Remix” model for this Initiative, as it is central to addressing the concerns raised about fragmentation and proprietary modules.

A Fedora Remix is deliberately designed to allow experimentation outside of core Fedora infrastructure and policies. By structuring the AI Developer Desktop as a Remix, the team is explicitly protecting Fedora’s long-standing policies, not changing them. A Remix provides a sandbox where developers can try new things, like building out-of-tree modules, without forcing those choices onto the main Fedora Editions, Spins, or Labs. We have seen this model work successfully with community downstream projects like those under the Universal Blue umbrella, which experiment heavily while leaving upstream Fedora untouched.

It is also important to emphasize that this is an entirely voluntary, opt-in initiative. No Fedora maintainer or contributor is being mandated to dedicate their time, infrastructure, or efforts to this if it does not align with their interests or values. We need a place where the folks driving this work can safely experiment, succeed, and especially fail, without making those experiments mandatory for everyone else.

Finally, I need to address this comment:

I understand there are strong feelings about proprietary software and AI. Passionate debate is a core part of how we build Fedora. However, ultimatums, accusations of malicious intent, and language that can be perceived as threatening cross the boundaries of our Code of Conduct.

We need to ensure that our discussions are collaborative and respectful, even amid disagree on the technical direction. Let’s keep the focus on constructive feedback regarding the proposal itself.

19

Many others, including myself, have stated that Vulkan and OpenGL are viable alternatives for an AI-ready stack. And at the current moment, I am personally working on a new Graphics/GPGPU specification, which may appear in the coming years.

Assuming that members utilize Vulkan as the base, competent developers will have no issues at all making the lives of other developers easier. Some may even pride themselves on it. Even if Fedora is as unmanageable of a platform as you say, it would be fairly easy for developers to hop on board, and help out.

There is something to be said about NVIDIA’s stack, and the fact that they essentially have a monopoly on various AI tooling. So why not hit two birds with one stone, and build our own stack with this initiative? Number one, no signing of kernel modules will be required. And number two, we will get to drum up a possibly very fun rivalry against NVIDIA, and possibly break their monopoly.

I think it will be far easier to get developers to get on board with the proposal I’ve made above, and it won’t risk fragmenting the community.

Replying to what you’ve said

I am speaking for some community members here, who may remain silent for various reasons. I agree that we shouldn’t be throwing accusations, however, I still stand behind what I said.

There is something to be said about attention, and focus. What if the focus of the whole community is narrowly placed on the KMod remixes, or what if the remixes themselves replace Fedora itself as the primary focus, and thus Fedora itself is no longer being maintained?

Again, this proposal has a chance of usurping Fedora’s sovereignty down the line, and as such, this particular issue cannot be ignored. It would be foolish for community members to do so, since it would put their own survival on the line…

I think that the question I outlined above has much to be answered for.

20

I’ll read through this more in depth later but it might be wise to move the “non-goals” section to the top of the post just to clear any idea people might have when they see the AI Developer Desktop name.

It’s important to me that people come into the discussion without assuming this proposal is about shipping AI tooling in official Fedora deliverables :slightly_smiling_face:

To that end you might want to put:

AI tools will not be added to Fedora’s existing system images, Editions, etc, by the AI Desktop initiative.

At the absolute top of it all.

1 Like