Fedora is bleeding edge. It is not a production stable distribution by design and definition
I don't know who told you that, but that is not the position of the Fedora organization. Fedora is intended to be a reliable OS, with 13 months of interface stability. It's production stable for many workloads.
Think of it as a beta of the next RHEL point release
Well, except that it's not a beta. CentOS Stream is intended to be production-stable, and bugs in Stream are regarded as bugs in RHEL. Packages get all the same testing and QA before release in Stream that they traditionally have got before release in RHEL.
Packages are released in CentOS Stream when they're ready for RHEL. (However, in order to provide extended support for RHEL minor releases, Red Hat has to delay release of some types of updates until the next minor release.) There *is* a chance that a bug will it Stream, but it's no greater than the chance of a bug hitting RHEL in the past.
Very interesting. And odd. I didn't think Fedora devs would ever roll out a new major compiler version with an ABI change without updating everything that might depend on it at the same time, including the kernel.
That's because we don't.
Those sorts of changes can only be released in a new Fedora release, not during one.
I mean... Stratis stands out as an RHEL-first tech. It's available for Fedora, of course, but with Fedora focusing on btrfs and moving more spins to btrfs-by-default, it's *real* hard to portray Stratis as being tested in Fedora.
With new releases every 6 months and a 13-month support lifetime, Fedora is fast-paced compared to LTS distributions. But Fedora, the org, prefers not to describe the distribution as "bleeding-edge". It's intended to be a stable distribution (in both common senses of that word).
If Amazon's choice were dictated by the changes to CentOS, you'd have seen Amazon adopt CentOS Stream, just like Facebook had. Fedora's a better base if they want to do most of their work upstream (in Fedora) directly, and minimize changes present within their fork.
"Those who do not understand Unix are condemned to reinvent it, poorly." --Henry Spencer
The problem with advocating simplicity is that it tends to over-simplify the actual problem.
Suggesting that complex platforms are poor reinventions of Unix implies that the POSIX API is sufficient to solve all problems, and quite simply, it isn't. The POSIX API isn't even sufficient, on its own, for software that runs on individual hosts. Applications for that scale are absolutely going to rely on libraries that extend the basic API.
But this discussion isn't about applications at that scale. It's about global-scale software development, where the platform isn't an individual host, it's a single computer composed of hundreds of thousands of heterogeneous machines operating in separate data centers around the world. Every part of the API needs to be extended to provide a suitable development platform for applications that run on that computer.
I'd argue that there should be a parallel right-to-maintain movement.
"Should be?"
Gosh, if only someone had thought of this sooner. Why isn't anyone advocating that people who buy hardware should also get the source code required to operate it, and the right to modify that software?
At the time it was introduced, Chrome was technically superior
I think that's the real reason, and a point that I make really frequently: Reputation matters. Chrome developed a reputation for being faster and smaller than Firefox early on, and many people believe that it still is.
However, reputation has a way of becoming a myth. Firefox has been smaller (in its download, its installation/disk footprint, and its RAM footprint) than Chrome for a *long* time, and hasn't been slower than Chrome for a long time, either.
Firefox is a really good browser. I use Firefox personally, and Chrome on my work laptop where it's required. I *much* prefer Firefox, especially because its address bar makes it a lot easier to navigate by keyboard. Chrome seems to prioritize search engine-provided suggestions much too aggressively. Mozilla has made huge improvements to Firefox, but the technical work isn't translating to an improved reputation, and I'm not really sure what they can do in that area.
On mobile Safari provides quicker access to my bookmarks, so I use that. Firefox could definitely improve on mobile
Probably not. I'm not sure if you're aware, but Apple won't allow Mozilla to implement its own web engine on iOS, so Firefox for iOS is just a wrapper around WebKit. It exists mostly to allow you to sync your data with your other Firefox installations through Mozilla Sync.
Mozilla's ability to improve on mobile (iOS) is artificially limited by Apple.
- Firefox is slower than Chromium-based browsers
Honest question: by what metric?
Years ago, I could name specific web apps that were faster in Chrome than in Firefox. Today, I can't.
It's compelling hundreds if not thousands of customers to set up their own internal mirrors with locked release versions.
I could spend *all day* refuting various points here, but I'll just pick one for now.
CentOS has never, *ever*, provided the capability of building reproducible systems from its yum repos. If you need reproducible builds, then you have various options. You can run a local mirror with stable or controlled changes, possibly with Katello, but maybe with more rudimentary tools if you prefer. You can build deployable images (such as AMI or VM images). You can build container images.
You can't, however, rely on the public mirror system, because that has *always* been just a stream of updates. The move to CentOS Stream isn't really a big change in that regard, and it's alarming how many CentOS users haven't realized this until now. If you need reproducible images, the process for getting them from CentOS Stream is exactly the same as it is for CentOS.
And if you don't need reproducible images, then the good news is that CentOS Stream gets exactly the same class of updates that CentOS does, it just gets them without a useless 6-month delay on a subset of updates. That delay actually has a function in RHEL, where some point releases are supported for 2 years. RHEL users make a trade-off between timely updates and point-release longevity. But in CentOS, it has no function. Users get updates later than necessary without getting the benefit of LTS point releases. It's all cost and no benefit.
A cargo cult is described as a group who imitates the superficial aspects of a system, without understanding how the system actually work, and expect to get the same benefits. Point releases in CentOS look like something that RHEL provides, and thus CentOS should too, but that's a superficial view of the system. Point releases aren't a benefit in and of themselves. They're actually the down side of providing LTS sub-releases within a major release of RHEL. CentOS Stream is a much better system for doing away with them.
In reality, unless Linux blesses it it's going nowhere. Didn't he kind of recently say that he was skeptical of using Rust in the kernel?
Not exactly, no.
It's tempting to lump JS in with other inefficient interpreted languages, because as a group they do tend to be rather slow and inefficient. But, that's a naive point of view. JavaScript is actually one of the most efficient languages you can choose. For all its warts, JavaScript engines are built on many years of academic research on compiler design, and produce extremely fast and efficient code. It's not going to match C for most algorithms, but it's not unusual for JavaScript to beat Go, for example.
CentOS was a good distro and it is a shame that they managed to kill it
Personally, I think they made CentOS *much* better by getting rid of the point releases.
Lawrence Radiation Laboratory keeps all its data in an old gray trunk.
