The best way, I think, to reduce the need for usecase distros is to flatten distribution structures. Void is a great example, in a way, of how to ensure your distro is good for anything the...
The best way, I think, to reduce the need for usecase distros is to flatten distribution structures. Void is a great example, in a way, of how to ensure your distro is good for anything the community needs: They community picks the additional available packages, with teams maintaining important parts and maintainers approving additions and modifications. The other side I've seen is how Fedora has its core devs, SIGs, etc, but it doesn't seem possible as somebody relatively new to it to get things like simple package fixes pushed for minor packages in a timely manner, even if they're packaged poorly according to stated norms. I can have the same fixed in Arch with a simple bug report, and make the PR myself to Void or Nix, with no prior contribution to either project.
A flattened structure, similar to what Void or Nix utilize, benefits everybody: You don't need the audio guy, the KDE guy, the GNOME guy. You'll want maintainers for these to guide them and make final approvals and ensure assholes don't mess things up.
The blog post talks a big game about GNOME developing Software in such a way that it'll allow easy installation of software using AppStreams, but that infrastructure only works when you've got sufficient packages for a use case. If you don't, and your distro can take years to be able to contribute to because you have to network and rub elbows to be able to get anything done, you're going to see people spinning up a repo server, pre-installing a bunch of stuff, and creating a new distro.
The reason for that approach is that for the vast majority of these things, they are available for the larger distro, but configuring them for that takes extra work. If you look at Nobara, most of...
The reason for that approach is that for the vast majority of these things, they are available for the larger distro, but configuring them for that takes extra work. If you look at Nobara, most of it is just enabling rpmfusion and preinstalling and configuring a bunch of stuff. They're right, if Fedora made enabling that and finding the software easy enough (post-installation presets for different use cases?), there would be little need for something like this. It's not a problem of availability like it was 10 years ago, it's more about presentation and ease of configuration.
The issue is still packaging, which is largely a political issue. RPMFusion is not Fedora, so somebody in the Fedora Games SIG also couldn't just throw Steam into a gaming-desktop metapackage and...
The issue is still packaging, which is largely a political issue. RPMFusion is not Fedora, so somebody in the Fedora Games SIG also couldn't just throw Steam into a gaming-desktop metapackage and have it included. A few things done by Nobara could be reasonably packaged, like the fsync patch. Even using a distro that provides these in its base, like Ubuntu or Arch, would still lead to the issue of linux-fsync, which would be easier to get into Arch than Ubuntu, but would still take a longer time because of the organizational structure.
The blog post pretty much talks about building better infrastructure to make it easier to do, but not the variety of software provided by that infrastructure. GNOME Software and AppStreams would make it easier to serve software, but that infrastructure can't serve packages that aren't in a distribution. If it is more difficult to add packages to a distribution, somebody will just do it themselves with third party repos and ISO-building tools.
That's what they mean about having it easy to enable these things, like Fedora has actually done with Steam and is expanding. RPMfusion is being treated more like Debian's nonfree packages except...
That's what they mean about having it easy to enable these things, like Fedora has actually done with Steam and is expanding. RPMfusion is being treated more like Debian's nonfree packages except that they're trying to make it easier to access them. They've taken the route of free software by default but making it easy to enable whatever you want. That's their point: more things like they've done with Steam, where you simply press a button and have access to it. That allows them to make the experience easier without abandoning their principles.
They are willing to promote usage of RPMfusion and treat it as an extension of Fedora itself, the issue is making that accessible from a user perspective.
The best way, I think, to reduce the need for usecase distros is to flatten distribution structures. Void is a great example, in a way, of how to ensure your distro is good for anything the community needs: They community picks the additional available packages, with teams maintaining important parts and maintainers approving additions and modifications. The other side I've seen is how Fedora has its core devs, SIGs, etc, but it doesn't seem possible as somebody relatively new to it to get things like simple package fixes pushed for minor packages in a timely manner, even if they're packaged poorly according to stated norms. I can have the same fixed in Arch with a simple bug report, and make the PR myself to Void or Nix, with no prior contribution to either project.
A flattened structure, similar to what Void or Nix utilize, benefits everybody: You don't need the audio guy, the KDE guy, the GNOME guy. You'll want maintainers for these to guide them and make final approvals and ensure assholes don't mess things up.
The blog post talks a big game about GNOME developing Software in such a way that it'll allow easy installation of software using AppStreams, but that infrastructure only works when you've got sufficient packages for a use case. If you don't, and your distro can take years to be able to contribute to because you have to network and rub elbows to be able to get anything done, you're going to see people spinning up a repo server, pre-installing a bunch of stuff, and creating a new distro.
The reason for that approach is that for the vast majority of these things, they are available for the larger distro, but configuring them for that takes extra work. If you look at Nobara, most of it is just enabling rpmfusion and preinstalling and configuring a bunch of stuff. They're right, if Fedora made enabling that and finding the software easy enough (post-installation presets for different use cases?), there would be little need for something like this. It's not a problem of availability like it was 10 years ago, it's more about presentation and ease of configuration.
The issue is still packaging, which is largely a political issue. RPMFusion is not Fedora, so somebody in the Fedora Games SIG also couldn't just throw Steam into a gaming-desktop metapackage and have it included. A few things done by Nobara could be reasonably packaged, like the fsync patch. Even using a distro that provides these in its base, like Ubuntu or Arch, would still lead to the issue of linux-fsync, which would be easier to get into Arch than Ubuntu, but would still take a longer time because of the organizational structure.
The blog post pretty much talks about building better infrastructure to make it easier to do, but not the variety of software provided by that infrastructure. GNOME Software and AppStreams would make it easier to serve software, but that infrastructure can't serve packages that aren't in a distribution. If it is more difficult to add packages to a distribution, somebody will just do it themselves with third party repos and ISO-building tools.
That's what they mean about having it easy to enable these things, like Fedora has actually done with Steam and is expanding. RPMfusion is being treated more like Debian's nonfree packages except that they're trying to make it easier to access them. They've taken the route of free software by default but making it easy to enable whatever you want. That's their point: more things like they've done with Steam, where you simply press a button and have access to it. That allows them to make the experience easier without abandoning their principles.
They are willing to promote usage of RPMfusion and treat it as an extension of Fedora itself, the issue is making that accessible from a user perspective.