bclemens

It appears to be "The Friendly Orange Glow: The Untold Story of the PLATO System and the Dawn of Cyberculture".

Of course! It's easy to forget he was a guard at one of America's most notorious concentration camps, Guantanamo Bay. It's foolish to think of him only as a Fox News personality.

They are not directly comparable. Nebula is a mesh VPN. Wireguard can be used as a building block for a mesh VPN (as it is in Tailscale), but it does not have that function organically.

I have tried Tailscale / Headscale and did not find the overhead worth it. Both can saturate a 10Gbps link and that's all I need right now. Nebula's much simpler to administer. The configuration's spelled out in the client configs and in the certificates you provision. If you're already using some form of configuration management, it's quite easy to make changes. If you require a Web UI, Tailscale / Zerotier / etc may be better. There is a company that provides a Nebula-based service with a Web UI but I haven't tried it.

Also consider Nebula: https://github.com/slackhq/nebula

ZeroTier does not use an OSI approved open-source license. It is under a freedom-restricting "Business Source License". Nebula is MIT licensed.

Nebula is much simpler and in most cases faster than ZeroTier.

Nope, it wouldn't have been in RHEL 10 or any of the rebuilds. CentOS Stream 10 already branched from Fedora / ELN. The closest it would have gotten is a Fedora ELN compose, and it's doubtful it would have remained undiscovered long enough to end up in CentOS Stream 11.

Ha, fun to see this again! Back before everything was HTTPS, it was fun to use the Browser Exploitation Framework (https://beefproject.com) which had a script included that did this. Though in those cases I wasn't in control of the gateway, so ARP spoofing was required to get other devices to route through me.

Rocky Linux has /etc/redhat-release as well. Reason being that some software checks that file for version / compatibility information, and we want to avoid breaking it. (They should be checking /etc/os-release, but it is what it is.)

It is not. openSUSE is a very different distro, though it does use RPM packages.

SuSE Liberty Linux is, I believe: https://www.suse.com/products/suse-liberty-linux/

The vagueness is not intentional, it's vague only because at the time it was written we hadn't decided on a particular source. For Rocky Linux, RHEL cloud instances are currently the primary source.

Not every RHEL binary is GPL licensed, but all the packages we distribute have an open source license permitting such redistribution. There are a few left out, for example some Red Hat proprietary artwork, tools, etc.

I often get a bit of a feel of the Monty Python "Nudge Nudge Wink Wink" sketch from talking with folks who think we're doing something legally dubious.

Happily surprised to see this hit the front page! If anyone is interested, I keep track of some statistics regarding Rocky Linux usage at https://rocky-stats.tiuxo.com/auto.html

Note that those statistics are only really useful for determining relative usage of Enterprise Linux distros as it's derived from EPEL logs. I haven't gotten around to attempting to derive statistics from the Rocky Linux logs because it's an intimidating amount of data.

(It's supposed to be automatic, but it seems the GitHub CI is having an issue with one of the dependencies for the past week. Guess now's a good time to fix it, and maybe make the page look more aesthetically pleasing...)

There's no mystery or secret about where we get sources: https://rockylinux.org/news/keeping-open-source-open/

TLDR: UBIs and cloud instances.

We aim to be as transparent as possible. The only information that we don't share publicly is the obvious stuff (PII, sensitive infrastructure information, etc). The information regarding source access / challenges / etc is available at https://rockylinux.org/news/keeping-open-source-open/.

We have a whole blog post about exactly that, here: https://rockylinux.org/news/keeping-open-source-open/

We thank our upstream often, in person, in social media, etc.

We sponsor the Fedora Flock conference, the only opportunity to fiscally support Fedora, and will continue to do so. Same with the CentOS Connect conference. Those checks get written directly to Red Hat, by the way.

Given you work for Red Hat, we can even say we've paid you a little! :)

Projects have always done this, as Red Hat has always been rather litigious and it's unwise to give them any unnecessary ground for legal complaints. The common euphemism has been "Prominent North American Enterprise Linux Vendor" since the early days of CentOS.

Back in 2007, CentOS's self-description was "CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendor's redistribution policy and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork.) CentOS is free".

This is adorable, it even shows Haneda air traffic!

Can you elaborate how the patches, bug reports, package maintenance, etc, do not benefit the "builders' community"? They all go to the same upstream.

And what exactly do you mean by "builders' community", do you actually mean "Red Hat"?

By "not participate in" do you mean "not pay your employer"? Which we do, actually. Just wired a good chunk of money to Red Hat the other day, ostensibly earmarked for supporting the Fedora project.

We do indeed. Adoption numbers are promising <https://rocky-stats.tiuxo.com/auto.html> but community size is enormous as well. 9071 folks on https://chat.rockylinux.org, ~300 folks on IRC, ~4100 folks on the forum, etc.

Adoption by many large organizations / businesses was also quite fast. And may have even caused us some trouble, I suspect the attention garnered by NASA's use of Rocky Linux had something to do with instigating Red Hat's recent antics.

We participate in the Enterprise Linux community just fine. Our community members report bugs and throw patches at upstream projects, run SIGs creating value for EL, maintain Fedora and EPEL packages, etc.

For the security part at least, there are a few efforts to combine all the errata in one place, for example https://osv.dev/list?ecosystem=Rocky+Linux

What are you trying to imply here Paolo?

Rocky Linux has a large selection of live ISOs in different flavor desktop environments / etc at https://rockylinux.org/alternative-images

Alma used CloudLinux's secure boot key (among other CloudLinux infrastructure / resources) for their first few releases.

Rocky Linux didn't have secure boot out the gate because we built everything from scratch, which included going through the long process of getting our own secure boot key approved / signed by Microsoft. See https://github.com/rhboot/shim-review/issues/194 (Alma didn't get their own until https://github.com/rhboot/shim-review/issues/235)

To be fair we (Rocky Linux) also have codenames, but we only added them because some software bugged out if it wasn't present in /etc/os-release. And that's the only reason it's there, it's not really referred to anywhere else. https://git.rockylinux.org/original/rpms/rocky-release/-/blo...

I'm not sure why Alma does a new one for every minor release though.

Rocky Linux has not teamed up with SUSE. The announcement from SUSE included that CIQ is teaming up with them. CIQ != Rocky Linux. CIQ != the Rocky Enterprise Software Foundation. We might use whatever they come up with to make an additional distro later.

Rocky Linux, as it is, will always be 1:1 with RHEL. We are dedicated to providing 1:1 "bug for bug" Rocky Linux, for both 8 and 9, for the full duration of their life cycles. Broken promises from CentOS are the reason we started Rocky Linux in the first place, we're not going back on anything we've already committed to.

I believe we (Rocky Linux) were pretty specific about how we're getting source in the announcement at <https://rockylinux.org/news/keeping-open-source-open/>. SRPMs from UBIs, cloud instances, etc. The only intentional omission are the additional legal loopholes we've discovered to get source, that we're keeping in our back pocket. We want to keep those backup methods to ourselves so that Red Hat doesn't close off too many at once, should they choose to try to screw over our community again in the future.

The RESF / Rocky Linux project does not sell support contracts. That is a contract for CIQ. Any company is free to sell support services for Rocky Linux (and many do, including OpenLogic, MontaVista, CIQ, TuxCare, etc).

Not to undermine what the man did, but the title is a bit of an overstatement. What saved North Carolina from nuclear disaster was not the guy who pulled the cores out after, but luck, safety mechanisms, and failures / damage sustained during impact: http://nuclearweaponsaccidents.blogspot.com/2013/03/goldsbor...

It doesn't seem misleading at all tbh. Misleading would by "liaison to the military", not "liaison in the military".

Rocky Linux has migration scripts available at https://github.com/rocky-linux/rocky-tools/tree/main/migrate...

An easy shortcut though, in case you have to hand type it out somewhere, is https://rockylinux.org/migrate2rocky.sh

No.

Alma Linux is done by CloudLinux, and still uses their infrastructure, secure boot certificate, etc (according to their page at https://web.archive.org/web/20221208102246/https://wiki.alma...). They have never had anything to do with CentOS.

Rocky Linux _is_ community oriented, and _is not_ beholden to a specific company, but it is not necessarily unpaid. The majority of the most active contributors to the project are being paid by their respective organizations (CIQ, OpenLogic / Perforce, etc) to do so.