Yeah, I'd like a good answer here too. :)

Half-baked thought: on the VARIANT_CLASS label, what if we used ID_LIKE=atomic? From the spec:

It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from.

Or, if not that, I think probably VARIANT_LIKE matches the standard ID_LIKE field more closely.

would the delineation here be classic vs ostree. Since Silverblue/IoT/CoreOS all use ostree that might be the term to use.

Over time, I'd like to see the existing editions essentially be based on Fedora CoreOS. I don't want it to simply be equal, I want it to be the foundation for what we consider the future of Fedora. Call me crazy in my aspirations if you want but that is what I'd like to see.

With that in mind, I'm fine with "classic" to describe the non-CoreOS/ostree editions.

would the delineation here be classic vs ostree. Since Silverblue/IoT/CoreOS all use ostree that might be the term to use.

That's a pivot point for sure; one that came up often in the "Ostree Workstation" vs "Atomic Workstation" discussion. It's do we take "containers+immutable-style OS" as a unit, or separately? I've talked about these as "peanut butter and jelly" or "bread and butter" - things that go well together but are conceptually separate.

I personally spent a whole lot of time on package layering, but I definitely view it as a transitional thing to be used sparingly, and we should strongly emphasize containers. Not everyone is going to agree, particularly not until we beef up our "pet container" pattern.

So...saying the differentiator is ostree doesn't capture the containerization aspect, which is why I was leaning towards coreos. But there are a lot of discussions that are actually just about ostree; certainly thing like bootloader discussions, etc. So IMO it's totally valid and accurate to talk about classic vs ostree systems, but I think we want coreos which rolls up ostree + "emphasizes containers" in some way.

but I think we want coreos which rolls up ostree + "emphasizes containers" in some way.

The fundamental problem there is that CoreOS is an edition so things start to get confusing quick if Silverblue and Fedora IoT are also coreos. I think associating ostree with "emphasizes containers" wouldn't be bad. If we did that could we just re-use ostree ?

I'm okay with either of these suggestions. I suggested atomic because it has the "more than just ostree" connotation while not also being an edition. But I'm not strongly attached to that.

I'm okay with either of these suggestions. I suggested atomic because it has the "more than just ostree" connotation while not also being an edition. But I'm not strongly attached to that.

after f29 I think atomic will probably (should probably) be associated with EOL and not carry any future meaning

I guess that's fair. R.I.P., the second time ever we had a good name for something. :)

+1 to ostree (not atomic). I wonder if we should have some additional hints that can be deployed, like a hierachy to guide installation/etc. choices. This way we can have containers/flatpak, ostree (presumably with unlock and rpm install), ostree (no unlock), package managed (today's Fedora).

I do not like the use of the word "classic" and "traditional" as they seem pejorative in the other direction. Can we just use "package-managed"? That feels like the opposite of "ostree"

Can we just use "package-managed"? That feels like the opposite of "ostree"

It is...until rpm-ostree is involved, particularly package layering. The analogy I make is that it's like a hybrid car. I've seen many people e.g. say "RPM-based" system to mean "not rpm-ostree" which I find funny given that it has RPM in the name.

However, it's definitely the case that the way we handle packages is pretty different; we also don't support every existing package. That's why I say "traditional" vs "rpm-ostree". RPM is still involved.

And remember that ostree itself has absolutely nothing to do with RPM - there are people using it with e.g. Debian. (There's no other software equivalent to rpm-ostree for Debian though). "ostree" doesn't install RPMs.

Can we just use "package-managed"? That feels like the opposite of "ostree"

It is...until rpm-ostree is involved, particularly package layering.

I understand your point. I was thinking about dnf/yum == package managed versus and ostree call or containers.

I'd like to find a word that doesn't equate non-ostree systems with "old"

There was a similar discussion at FESCo regarding naming the Everything directory on the mirrors: https://pagure.io/fesco/issue/1878

I also blogged about it and there are a only a few comments so maybe most people do not care or do not read my blog: https://blog.till.name/2018/04/13/fedora-classic-or-is-it-traditional/

I'd like to find a word that doesn't equate non-ostree systems with "old"

Do you mean to have a better name for the non-ostree systems than old but still use a time scale to compare them or to avoid comparing them in a time context at all? I guess if it should not be time-related, it needs to be technology-related or it can be just a unrelated, made-up name.

I'd like to find a word that doesn't equate non-ostree systems with "old"

Do you mean to have a better name for the non-ostree systems than old but still use a time scale to compare them or to avoid comparing them in a time context at all? I guess if it should not be time-related, it needs to be technology-related or it can be just a unrelated, made-up name.

Exactly, the order of development seems to be not to be relevant here since we are doing a hard-cut. I'd therefore like a non-timebased word.

There was a similar discussion at FESCo regarding naming the Everything directory on the mirrors:

I agree with a comment in that thread that the Everything name is only really known by Fedora "insiders". However the concept that there's a single rpm-md repo that contains a big set of packages - that is definitely known.

Anyways, we can just use two terms depending:

• ostree-based (or rpm-ostree based)
• coreos-based (ignition, toolbox container)

(Though what gets messy here is that in a lot of contexts there will be a need to disambiguate Container Linux (original CoreOS) vs Fedora CoreOS, and saying "fedora-coreos-based" starts to get unwieldy)

And I'd like to push for the idea that Silverblue in particular is CoreOS-based, and make that at a reality at a technical level. For Fedora IoT it's a bit more complex, but anyways I suspect the two terms are going to work OK there.

That may simplify this discussion in that we could avoid saying "classic". But in the end if no one has any better ideas I'm probably going to keep doing that.

We should make a distinction between Fedora — which is a project — and Fedora release artifacts like Fedora Workstation or the, ahem, classic Fedora OS.

To that end, @walters, I'm taking the liberty of editing the title of this question to reflect that.

We should make a distinction between Fedora — which is a project — and Fedora release artifacts like Fedora Workstation or the, ahem, classic Fedora OS.

I'm in favor of what you're trying to do there. It makes sense. But I think we should bear in mind that trying to change things here is going to take years. People are fundamentally lazy, and there's massive amounts of inertia.

Can you imagine the Ars Technica article titled "Review of the Fedora Workstation operating system composition"?

And how would you change the Wikipedia page?

Basically, unless we give people something convenient to type e.g. on IRC and in email, I'd say that basically everyone who exists in the community today is just going to keep saying "Fedora" to (usually) mean "Fedora Workstation" or the "Fedora rpm-md repository".

I feel like Wikipedia is actually in good shape here because they do already have https://en.wikipedia.org/wiki/Fedora_Project as distinct from Fedora (Operating System). :)

But yeah, to be clear, this isn't an attempt to dodge the question and I think that we do need better nomenclature.

The Council discussed this and decided on "rpm" and "rpm-ostree". This reflects the management methodologies.