#4

To be honest, I would look into the original concept of modularity again and target it as original goal. The idea to have stable platform and build modules on top of it is the ideal state for me. There are many challenges with this, like installing multiple streams of same thing is MUST (I can’t really modularize Rust stuff because 1) MBS/Koji is too slow 2) Installing multiple streams is not a thing). We need some transition period which would allow us having modular platform but also use it in buildroot (this is where I’m still waiting for Ursa Major).

However, this would definitely require help from all maintainers, not just few geeks from Modularity WG.

If we reach this state, we will be allowing users to choose some stable Platform (CentOS one, for instance) and still having apps built on top of that. And if we make it easy to deploy build infra outside of Fedora, people will build their own platforms as they need.

1 Like
#5

Igor can you elaborate on why installing multiple streams in parallel is crucial?

#6

For Rust or in general?

In former case you mind end up with 2 (or even 3-4) versions of same crate in buildroot (usually because dependencies are not ported to latest version while your app does). Sometimes it is essential because depending on same version breaks your binary — https://github.com/rust-lang/cargo/issues/2589.

And in general, just simple example:

⋊> ~/P/u/rust2rpm on master ⨯ rpm -qR beignet | grep LLVM                                                                           14:56:33
libLLVM-6.0.so()(64bit)
libLLVM-6.0.so(LLVM_6.0)(64bit)
⋊> ~/P/u/rust2rpm on master ⨯ rpm -qR mesa-dri-drivers | grep LLVM                                                                    14:56:42
libLLVM-7.so()(64bit)
libLLVM-7.so(LLVM_7)(64bit)

If I want to use beignet, that would mean that I need to uninstall mesa-dri-drivers which would result in broken system (I mean no graphics).

Another example might be python interpreters, right now we allow all python2 and python3 versions to be installed at the same time which helps developers to run tox and test their library against all python versions. It is essential to support their workflow.

I understand that we don’t want to allow all streams of all modules enabled at the same time (because it is insane), but we should allow doing so in easy way for case by case (not creating llvm6:6, llvm7:7 modules and such.

#7

That brings up another question in my mind. It used to be the case that packages moved from Fedora into RHEL and then got recompiled to make CentOS. IIRC RHEL 7 was built from the packages in Fedora 19, and then evolved independently from there.

That was something like five years ago. RHEL / CentOS 7 are still going strong in their user base, but Fedora seems to have diverged significantly. There are many more versions of Fedora than RHEL. I don’t know anyone who runs a RHEL or CentOS desktop. And for a while there were three versions of Atomic Host, RHEL, CentOS and Fedora.

I wonder if one can fully contemplate the future / direction of Fedora without knowing at least a little bit about the road map for RHEL. Is RHEL 8 going to show up based on Fedora 30 or a later version? There’s some good stuff in Fedora that’s not in RHEL.

#8

Hi. The question is intended/destined to Silverblue group? or the whole community? because this is a closed group focused on Silverblue; we should change the name to “Fedora Silverblue discussion”; I am sorry but it is the reality … I will try not to mix several disagreements and avoid mistreat them.

Well; I will to be objective; Fragmentation destroys; We are guinea pigs; or are we users?

The efforts could be exploited in a “Rolling Release” model; to reduce resources and improves the product. LTS is a good idea, but not the panacea; Fedora will support outdated packages? then modularity is a good option, hand in hand with COPR. Similar to the distribution of a popular philanthropist.

The point is; Is useful maintain various versions of a package? it is a waste of time even for maintainers … therefore a “Rolling Release” is a way to avoids fragmentation and waste of time. People wants install a cloud version, well, install “dnf install group cloud” The people want to experiment as Silverblue, well, install “dnf group install silverblue”; easy no?

For me; flatpaks, with all due respect, I am not a follower of it. Filling my PC with the same software, software with errors not existing in rpm packages … I do not find it useful… But everyone is free to choose their destiny.

Other. the kernel release model should change; maintain an LTS model. When I detect a kernel update; I sweat like a dog in a Chinese restaurant, because my “broadcom dkms” driver could fail; like my nvidia video card in my job. I hope someone does not jump, but Manjaro has a good option to choose the desired kernel and maintain a compatibility rhythm… Returning to the main point, Rolling Release is a model that even makes Google successful.

#9

Hi. The question is intended to Silverblue group? or the whole community? because this is a closed group focused on Silverblue; we should change the name to “Fedora Silverblue discussion”; I am sorry but it is the reality … I will try not to mix several disagreements and avoid mistreat them.

Errr, what? No. This is a general site for Fedora discussion. There is a Silverblue category. This post is in the “Project Conversations” category and is not specific to Silverblue.

#10

The Discourse web interface can be very confusing, so it is certainly
understandable for this mistake to be made.

#11

Probably also because this discussion platform is primarily advertised on the Silverblue site thus far?

1 Like
#12

Silverblue is a completely different way of managing your base system, so a command like this wouldn’t really work…

If you’re referring to Chrome OS, it’s a very different beast from a standard Linux distro…

#13

There are three main true rolling releases: Gentoo and its derivatives, which is mostly built from source on your machine, Arch Linux and its derivatives, and openSUSE Tumbleweed. I don’t know of anyone who runs a bare-metal server using Arch or a derivative of Arch, or using openSUSE Tumbleweed. I’m sure there are people, but the economics don’t pencil out.

There are people who run Gentoo on bare-metal servers, although not a large number. So if you’re looking for a model of successful servers on a rolling release, I’d hunt down a Gentoo shop.

I don’t think there’d be much of a market for a Fedora rolling release server; people want a long-term support model like Ubuntu LTS, RHEL / CentOS, and Debian Stable. They want something that’s popular, so they can easily find solutions to problems with Google and easily hire experienced DevOps engineers.

It costs time and money to test upgrades, and scheduled interruptions are another cost for deployment. So unless there’s a newly-patched security hole, there’s little incentive to upgrade a server.

#14

I think you’ve moved a little away from the subject, relating Silverblue, that’s not the case.

I am speaking about the fragmentation and waste of time with multiple versions of Fedora and packaging; and the focus on a rawhide model …

“A different way of managing your base system” Sure, then what can said you about these question ¿ H264 codecs on Chromium? if you are using rpm thirdparty repositories. The project still dependent on rpms and the use of dnf …

rpm-ostree is a hybrid image/package system. It uses libOSTree as a base image format, and accepts RPM on both the client and server side, sharing code with the dnf project; specifically libdnf.

We should take a look at Nix; and see their maturity; what I imagine Silverblue wants.

Other, In Silverblue are trying to replace critical parts of the system with a few commands; Wen you update/replace “A” program you must recompile dependent packages (b, w…z), if there is a jump in a “.so” or the path was changed. In rpm packaging some times a package requires a massive rebuild. It is inevitable even in “Silverblue”

I do not see differences; simply an adequate graphical interface; where the user only has access to some parts, unless you enable root . I mention Google because the Rolling release model works for them. If, it is not a standard linux; It is other discussion.

In the end, what it all comes down to is this:

The rolling release model makes our life a little bit easier.

This is because the less time it takes to maintain your operating system, the more time we have for things in life that matter.

#15

You could give Rawhide two branches, which modularity would make easier to achieve.

There’d be a developmental branch which includes pre-release releases of the kernel (e.g. 4.20.0-0.rc2.git0.1.fc30 is what my Rawhide install is presently using) and GNOME (e.g. 3.31.2 is what my Rawhide install is using), which is what Rawhide presently does, and a bleeding branch, which features largely the same software, except without pre-release (or developmental) releases of software like the kernel and GNOME, only the latest stable releases (e.g. 4.19.2 is the latest stable kernel, 3.30.2 is the latest stable GNOME).

Keeping the software up-to-date could be automated using bots/scripts, with humans only getting involved when a package fails to build or a runtime bug is encountered. Given the number of packages in Fedora’s repos, I’d imagine something like this is already going on (correct me if I’m wrong).

The bleeding branch would be for people like me, that like rollers, but don’t want the level of bugs that comes with developmental software. The developmental branch would be largely for Fedora developers and the odd courageous and curious person. Those that wish a mixture of bleeding-edge software with a little extra stability would go for stable Fedora releases. If they want a pinch more bleeding-edge, without taking the leap to rawhide, they can enable ‘testing’ repositories.

As for LTS releases, well frankly I suggest people should go look at CentOS/Oracle Linux/RHEL/Scientific Linux for that. Fedora is pretty much synonymous with cutting-edge software, which I think might be why so many developers (including Torvalds) seem to use it.

#16

$ rant begin
I know this is a cliche, but how is a 36-48-month life cycle for Fedora “skating where the puck is going to be?” How would a 36-48-month Fedora be better than RHEL/CentOS?

You want a vendor to ship Fedora on a laptop? Have the IBM CEO close a sale with the CEO of a hardware vendor! Have it be a priority with a bonus attached for getting it done. Have attorneys and accountants to show it’s a win-win.

Get marketers to show why it’s better than a Dell XPS with Ubuntu. Get enough feedback from real paying customers to know there’s a market and then get a team of engineers to fit the product to that market. The reason there’s a Dell XPS with Ubuntu on it is that Canonical and Dell executives agreed there was a business case to build and market it, not that Ubuntu is “better” than Debian or RHEL or Fedora or any flavor of SUSE.

I think “where the puck is going to be” is Silverblue / podman / Kubernetes / CoreOS / Flatpak. The only thing that’s keeping me off of Silverblue now is two devices - a USB WiFi adapter and an NVidia GPU - that don’t work yet.

I deployed a Docker app on Digital Ocean with the Atomic Host image they have and it was a slam-dunk. Everything just worked. I’m so fed up with the Docker for Windows unfixed bugs and terrible documentation that I’m seriously considering learning enough PowerShell to make the equivalent using Atomic Host in Hyper-V. That’s where the puck is going to be.
$ rant end

#17

[quote=“mattdm, post:1, topic:690”]
But there are some good cases for a longer lifecycle. For one thing, this
has been a really big blocker for getting Fedora shipped on hardware.
Second, there are people who really could be happily running Fedora but
since we don’t check the tickbox, they don’t even look at us seriously. I’d
love to change these things. To do that, we need something that lasts for
36-48 months.
[/quote]

$ rant begin
I know this is a cliche, but how is a 36-48-month life cycle for
Fedora “skating where the puck is going to be?” How would a
36-48-month Fedora be better than RHEL/CentOS?

You want a vendor to ship Fedora on a laptop? Have the IBM CEO close a sale
with the CEO of a hardware vendor! Have it be a priority with a bonus
attached for getting it done. Have attorneys and accountants to show it’s a
win-win.

Get marketers to show why it’s better than a Dell XPS with Ubuntu. Get
enough feedback from real paying customers to know there’s a market and
then get a team of engineers to fit the product to that market. The reason
there’s a Dell XPS with Ubuntu on it is that Canonical and Dell executives
agreed there was a business case to build and market it, not that Ubuntu is
“better” than Debian or RHEL or Fedora or any flavor of SUSE.

I think “where the puck is going to be” is Silverblue / podman / Kubernetes
/ CoreOS / Flatpak. The only thing that’s keeping me off of Silverblue now
is two devices - a USB WiFi adapter and an NVidia GPU - that don’t work
yet.

I deployed a Docker app on Digital Ocean with the Atomic Host image they
have and it was a slam-dunk. Everything just worked. I’m so fed up with the
Docker for Windows unfixed bugs and terrible documentation that I’m
seriously considering learning enough PowerShell to make the equivalent
using Atomic Host in Hyper-V. That’s where the puck is going to be.
$ rant end

[Visit
Topic](https://discussion.fedoraproject.org/t/fedora-lifecycles-imagine-lon
ger-term-possibilities/690/16) or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click
here](https://discussion.fedoraproject.org/email/unsubscribe/84384b1267ec65
76aeca682b7ff15af948b7afca3a7e93556ac17c7211d6c0f5).

Indeed. Additionally, longer lifecycles wouldn’t help to get hardware vendors
to pick up Fedora. They’d just need to update the images they’re throwing out
once every 6 months. That’s not a lot to ask. Does that mean there would be
systems out there with old versions of Fedora? Probably, almost definitely.

EOL only occurs nearly a year after a release, and at those point those
systems can certainly still be updated, even through those GUIs the DEs have.

#18

I don’t know for a fact that Red Hat or SuSE didn’t try to sell Dell on the idea of a supported Linux laptop as a product for sale to end users. Nor do I know for a fact that Dell didn’t say, “Let’s make a Linux laptop”, do a little research on popularity, discover that Ubuntu was far and away the most popular, pick up the phone to Canonical and initiate discussions of a partnership.

What I do know is that there must be some kind of partnership between the “brands” for the XPS with Ubuntu to exist as a commercial product. You at least have to do all the trademark legwork and market viability assessment if nothing else.

You can buy laptops with Linux on them - some prefer to ship one distro but most will load any Linux you want on them and will also load Windows if you pay for it. But they aren’t Dell.

But you know what? They aren’t IBM, either. Red Hat is part of IBM now, and I think IBM could sell a really top-notch laptop with “36-48-month-life-cycle-Fedora Workstation” on it, but with Red Hat or IBM branding. Or create a new brand. I don’t think an open source / foundation-governed Linux distro can compete with a Dell / Ubuntu XPS. IBM / Red Hat probably can.

#19

We already have an LTS. At least two of them. RHEL and CentOS.
A rolling release would be fantastic, but redundant with Fedora’s regular point-realease/upgrade cycle;;; that’s okay, the current release cycle is silly and may as well be rolling.

#20

If you want rolling release, you can run Rawhide. It’s actually fairly stable.

#21

@mattdm: The Fedora LTS version is a good idea regarding the kernel (long-term), when a user of a Fedora flavour can choice a kernel with long-term-support. For older hardware it is often sufficient enough to run with a older long-term-support kernel. On the other hand a LTS version will bind manpower to maintain a LTS version. All other amazing things like actual software etc. should remain. A rolling release I would only offer, if a high-quality testing team is available, otherwise it would be a disaster for many user when they get a broken system and they have no help from Linux-professionals. Today I would wish to have an automatic system-upgrade every release-point with a self-maintaining OS supported by Artificial Intelligence in the background to avoid obsolete packages and digital “waste” caused by updates and other user/system activities. This options should be standard on all Fedora systems to guarantee a smooth running and well performing system. The software install options should prevent that a user can do system-destroying actions. That is my vision of things that are usefully and realisable and do not destroy the spirit of Fedora being a cutting-edge and always modern OS. For Microsoft Windows there are also plans to build a self-repairing and maintaining system. I am sure, that this will broaden the user-base of Fedora. I hope my ideas will have practial effects for Fedora.

#22

@mattdm: The Fedora LTS version is a good idea regarding the kernel
(long-term), when a user of a Fedora flavour can choice a kernel with
long-term-support. For older hardware it is often sufficient enough to run
with a older long-term-support kernel. On the other hand a LTS version will
bind manpower to maintain a LTS version. All other amazing things like
actual software etc. should remain. A rolling release I would only offer,
if a high-quality testing team is available, otherwise it would be a
disaster for many user when they get a broken system and they have no help
from Linux-professionals. Today I would wish to have an automatic
system-upgrade every release-point with a self-maintaining OS supported by
Artificial Intelligence in the background to avoid obsolete packages and
digital “waste” caused by updates and other user/system activities. This
options should be standard on all Fedora systems to guarantee a smooth
running and well performing system. The software install options should
prevent that a user can do system-destroying actions. That is my vision of
things that are usefully and realisable and do not destroy the spirit of
Fedora being a cutting-edge and always modern OS. For Microsoft Windows
there are also plans to build a self-repairing and maintaining system. I
am sure, that this will broaden the user-base of Fedora. I hope my ideas
will have practial effects for Fedora.

[Visit
Topic](https://discussion.fedoraproject.org/t/fedora-lifecycles-imagine-lon
ger-term-possibilities/690/21) or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click
here](https://discussion.fedoraproject.org/email/unsubscribe/f04a4d09d4cebe
037de4025a53dbe9d6f1b79866ffd4ddc119b3dcc1addc315b).

What problems would the use of an old kernel solve? I have systems from 2004
that run Fedora 29 today. The only systems I use a different kernel on are my
own X200 tablet and T400 laptop, but even then it’s only because I put my
kernel in cbfs on those.

Why have all of the wasted effort for a LTS kernel?

The software install options should prevent that a user can do system-
destroying actions.

Of course, and dnf does that already. You’d have to be trying to break your
system, if you’re using only the package manager.

#23

I believe the usual idea is that kernel upgrades can break things, which is relatively rare but pretty bad when it does happen, and in certain uses/workflows you can’t really afford that risk.