mattdm

Note that your existing system will not be migrated to BTRFS.

I'm sorry to lose your trust. I think that comes from a misunderstanding about expectations. We want to provide a functional, usable system -- but we also are going to change things in new releases, and while we do weigh user impact, we're tilted towards bringing upstream innovation to users. That means we're likely to bring you things like cgroupsv2 sooner rather than later.

If you have these expectations, I hope we're holding to them pretty well. See our mission and foundations page at https://docs.fedoraproject.org/en-US/project/, and hopefully that will make things more clear.

Yes. That's the "simultaneously too fast and too slow" that all distros have to grapple with.

For me, it's not that Windows is bad, or even that Linux is somehow technically better.* The cool thing about Linux (Fedora or whatever else!) is that it's the operating system that belongs to us, the people. That's amazing.

I have no judgment at all against people who have other priorities and, like, just need to get their job done.

(* I mean, it is, obvious,y but that's not the point)

Good news! The people we are working with at Lenovo have no interest in this either. We don't have any special deal here: they're shipping Fedora under the standard open source licenses and https://fedoraproject.org/wiki/Legal:Trademark_guidelines#OE..., which means there's nothing added (except their docs in /opt/lenovo).

This is going to be stock Fedora Workstation, with no proprietary drivers. (You can install the Nvidia binary drivers after the fact if you need or want them.)

We follow the upstream kernel closely and generally do not include out-of-tree drivers (with a few historic exceptions). So, everything that works here should eventually benefit everyone.

The Lenovo engineers I spoke with are concerned about firmware updates for these things too, and will be working with their vendors to make sure they're in the LVFS.

No -- lack of Fedora LTS is because doing LTS with actual _S_ is a huge amount of work, and our volunteer community is not super-excited about doing that work.

This is to be worked out, but I don't think so. I think there might be a frozen branch internally for that but the Stream branch should continue (and therefore might end up ahead of the beta).

Sure. That became Container Linux. Now we have Fedora CoreOS, which combines tech and ideas from both Atomic Host and CoreOS/Container Linux. It uses Fedora packages but through rpm-ostree, not with the yum/dnf system you might be used to.

Since CentOS Stream and Fedora brances will exist in the same git system, I can see future Fedora CoreOS making use of slower-moving CentOS Stream branches where useful. But that's all to be worked out.

Right now, after RHEL branches from Fedora, it's disconnected — basically a fork more than a branch. This provides a public upstream for the RHEL 8.y branches.

Atomic Host is being retired.

CoreOS has two branches, one which is part of OpenShift (RHCOS) and Fedora CoreOS. That's very different from the RHEL model, so it doesn't directly map.

Well, see below. Dag wants to just move on; the "real" dstat program is now defunct even if it wasn't before. So, we'll just keep things as they are for now.

Okay. Again, I'm sorry it came out like this. I would like us to do better.

Well, we do try to do better than the Cottington planning department. Like all changes, it was posted to devel-announce (https://lists.fedoraproject.org/archives/list/devel-announce...) to get more visibility than just a devel-list post (or a random wiki page).

In retrospect, it would have been nice for the devs working on this to contact you directly and explicitly about the proposed change. I'm sorry that didn't happen.

But here we are now -- at this point, what outcome would you like?

Well, I am at least. I care about when things like this happen, including figuring out how we can do better.

So, from a Fedora Project point of view, I'm not really sure how we could have done this better. This change was properly announced and publicized as https://fedoraproject.org/wiki/Changes/MergeDstatAndPerforma... and approved by FESCo (the Fedora Engineering Steering Committee) in August 2018 (https://pagure.io/fesco/issue/1956).

The change page says "The original dstat utility has reached end of life - it does not support python3 and there are no plans to update it." This may not have been right after all, but I don't think it's in bad faith. Perhaps FESCo should have dug a little deeper, but there aren't really any particular red flags indicating that that's warranted.

I'm open to suggestions, though -- we do want to continually improve our processes, and we do want to work well with upstreams. And, y'know, be better to long-time Fedora ecosystem friends.

Eh. Although we don't always do things perfectly, Fedora has a pretty strong policy of working with upstreams first.

By contrast in my personal experience as a developer of something that got packaged in Debian, I discovered later that that package had a bunch of patches added, a man page written (!) and so on, none of which was bad, but also none of which was fed back to me at all.

(In case not obvious: I work for Red Hat on Fedora.)

Are you a RHEL customer? If so, telling your salespeople this would not hurt. Just sayin' :)

You know, the Wikipedia page for Fedora could really use some help. Both

https://en.wikipedia.org/wiki/Fedora_(operating_system)

and

https://en.wikipedia.org/wiki/Fedora_Project

There _is_ a lot of interesting history, both technical and in the project structure and culture.

I'd update the page myself, but, you know. :)

Yeah, help wanted on the docs team :)

I hope there hasn't been much blood in all of that. Sometimes we err on that side, but overall, the intention is to provide an integrated operating system that leads but doesn't actually cause injury!

Former sysadmin here: conserving disk space was never a major concern. The issue is with security updates. There was one nightmare period where every single program in existence seemed to have a bundled copy of zlib, each with a slightly different version of the same gaping security vulnerability. Things like disk (and network and RAM) savings are really the icing on that cake.

It was also the case that each bit of free / open source software had its own ideas of a good user experience. The distro building all all the software allowed the application of consistent policies. As a user, this was a huge step forward.

But that said, yes, things have changed and distros need to too.

Note that Fedora distributes metalinks to mirrorlists via https, and the main mirror at https://dl.fedoraproject.org/pub/ also uses https. We don't mandate that for our (volunteer!) mirror network, but many mirrors _are_ https. (See https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora... for the current list.)

We really try to avoid being a "bleeding edge" distro, and prefer to focus on leading edge. We don't always do every thing absolutely before anyone else; we try to be the first to provide integrated, tested, usable versions of innovative open source.

Although... Fedora Core predates them all....

One way you can help is by sponsoring someone's travel to Flock, our annual contributor conference. I don't think we have the details on how to do that yet for this year, but watch https://flocktofedora.org/

I'm curious why you think this is sad. As a desktop user myself, I generally find it a good thing. It's settled into "get out of my way and let me do my work" and makes upgrades generally non-disruptive.

13 months, not 6-12, but, yes, this is _exactly_ the point of the modularity initiative we're launching with F28.

There is a Copr for it — https://copr.fedorainfracloud.org/coprs/rhawalsh/dm-vdo/. (Looks like not yet built for F28, but I expect that to be updated shortly.)

This is good feedback. I'll bring it to the Fedora docs team.

This page is really full of errors. Please don't spread it.