From my understanding (not part of the SF tech bubble), S.A. had his shot as the CEO of a company that came to prominence because of a GREAT product (and surely not design, manufacturing or marketing). Just consider WHEN MS invested in OpenAI. He probably went too far for reasons only a few know, but still valid ones to fire him...
His previous endeavor was YC partner, right? So a rich VC turning to a CEO. To make even more money. How original. If any prominent figure was to be credited here beyond Ilya S., well that would probably be Musk. Not S.A. who as a YC partner/whatever played Russian roulette with other rich folks' money all these years... As for MS hiring S.A., they are just doing the smart thing: if S.A. is indeed that awesome and everyone misses the "charisma", he'll pioneer AI and even become the next MS CEO... Or Satya Nadela will have his own "Windows Phone" moment with SamAI ;)
Was Sutskever really that instrumental to OpenAI's success, if it was at all possible for him to be surprised at the direction the company is taking. It doesn't seem that he is that involved in the day-to-day operations.
Anyone asking this question has never gone through Ilya's achievements. He is quite brilliant, and clearly instrumental here. And Sam is amazing in his own way too, for sure.
I understand that we was instrumental in the earlier days, but does it seem like he is involved in the day-to-day work on the technology, today? When the new CEO advocates for a near-pause in AI development, does he mean operations?
I have a hard time understanding how regular people in need of "security/privacy" would pay 1200+ USD for this device. I'm not even touching on specs etc. The only ones I can think of needing such "security/privacy" would probably make a great sidestory in Breaking Bad or get their own post-mortem show on Netflix.
Kudos for using Linux, but that alone (and the hardware gimmicks) is really not enough to justify the cost.
P.S. For comparison the (somewhat) similarly spec'ed PinePhone costs 150-200 USD.
> Kudos for using Linux, but that alone (and the hardware gimmicks) is really not enough to justify the cost.
Much of that cost went into Linux driver/app/phosh development. It made libhandy happen, which become libadwaita. Future Linux-based mobile OSes will be able to stand on the shoulders of all that.
So it’s really more of a donation, plus I got a Linux phone on top of that.
Besides, if I’m lucky and the hardware and battery last long enough, I’ll be using the Librem 5 as a daily driver for a decade, which would help amortize the cost even more. During those years, I won’t have to worry much about software obsolescence. All the drivers have been mainlined into Linux so I’ll always get to use the latest kernel version – even if something happened to Purism.
I could have written this same comment in 2008 about my OpenMoko. It certainly did some useful low-level work (especially when Maemo/Meego/etc. increased the importance of standardisation), but its biggest own-goal was repeatedly throwing away the user-facing stuff (jumping from GTK, to EFL; when QtMobile/Qtopia was actually the most usable!).
Still, that did last me a decade; although I replaced it with a PinePhone rather than a Librem ;)
People in need of security and privacy would be far better off with GrapheneOS. For the Breaking Bad crowd there are specialized crimephones like Anom that are pre-compromised by law enforcement. Librem is more for people who want to run traditional GNOME/KDE on a phone instead of Android.
This was primarily built after realizing that the official Google RSS plugin for Chrome was never gonna be updated and was "stuck" to that annoying layout while displaying a page's feed.
As YouTuber Chris Titus would very eloquently say, "it's pointless". Chrome with a bunch of plugins could probably replicate the same experience.
It's also kinda patronizing to say "here's how the browser should work" as if people are morons in 2023 and have no clue how to use a browser, let alone their supposed target audience. I'm not even touching the "sign up to continue" issue others mentioned...
The news should actually be they got $18M in funding for this (FFS).
So AlmaLinux decides to stick to CentOS Stream (which "sits" between RHEL and Fedora in terms of "stability" as I understand). Basically what RHEL wanted these clones to do.
Rocky Linux on the other hand seems to take a more adventurous path by teaming up with SUSE on the new RHEL fork, whenever that comes. In the meantime it's not 100% clear how Rocky will continue working (they referenced some workarounds but not specifically how they'll get the source code from RHEL).
Oracle and Rocky say they will continue to duplicate RHEL exactly ( though Oracle never duplicated the RHEL kernel ).
SUSE says they will “fork” RHEL with it being a bit unclear if this will be a “bug for bug” copy or not.
Alma will base off CentOS Stream to create a distro that is RHEL ABI compatible.
Of all these, I think the Alma path best reflects the community values that everybody has been on about. The others are driven more by commercial interests than “community values”. That is ok, as long as you are honest about it.
> The others are driven more by commercial interests than “community values”.
The first time I read this line, it didn't sit right with me... but after thinking on it, you're not wrong. I don't think Rocky's choice to stay bug-for-bug is necessarily driven by commercial interest, at least not overtly.
One of the big benefits of "bug-for-bug compatibility" with a support-licensed "Enterprise Linux" is the fact that you end up with an incredibly broad user base running the same systems code everywhere, whether or not they're paying for support. This means that non-licensed systems are helping to uncover bugs and incompatibilities, and it also means that issues reported by enterprise customers and fixed by RedHat get filtered out to everyone else as a matter of course.
At the end of the day, yes: commercial interest is the common factor underpinning this mechanism. However in Rocky's case (as with the original CentOS before being EEE'd by RH/IBM) the conscious motivation is to build something that brings a maximum number of people together in pursuit of a stable, production-ready Linux distribution. And even if the result is "we do this because it helps our users make or save money," as you said -- that's okay.
> (which "sits" between RHEL and Fedora in terms of "stability" as I understand).
There is no meaningful upstream link between Fedora and RHEL after a RHEL release has been forked off, so it doesn't make any sense to say that CentOS Stream sits between Fedora and RHEL.
Basically: Red Hat takes a Fedora release, heavily tweaks it, and makes a new version of CentOS Stream. After hardening, that version of CentOS Stream then becomes the basis for a new major version of RHEL. Thereafter, that version of CentOS Stream is the upstream for "minor" releases of RHEL.
Patches which are destined to land in that release of RHEL, go through the standard testing process, and land in CentOS Stream (aside from embargoed security fixes that hit RHEL first, then Stream). It's the one and only "direct" upstream of RHEL, and it's a very close upstream. Closer than, say, Debian Testing and Debian Stable. It's more like if you had Debian Stable and then there was some additional variant of Debian which just ensured that everything apart from security fixes was held back until fixed-interval point releases.
This isn't true. Firstly Fedora is always the start of the next version of RHEL. Secondly even for the current RHEL all changes go upstream first, which means they go into Fedora. Thirdly there are some packages which are rebased to Fedora every minor RHEL release (I know of the mingw packages, and a lot of the virt stack, but there are others too).
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.
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.
The charts really look impressive. I didn't expect such an uptake. The funny thing is, people have tried it first (ephemeral instances), then started to migrate.
Fascinating. No wonder why Red Hat got a little irritated.
The difference was painfully obvious about 3-4 months in, this only confirms it. Everyone here keeps asking why would one pick AlmaLinux over literally anything else, while I'm sitting here asking myself how would anyone risk running his business on a distribution built on such a shady foundation, from sources obtained in a metaphorical back alley. Feels like a lawsuit waiting to happen, I wouldn't want to be on the receiving side of that for sure.
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.
You're talking about the users' community (and I have nothing to complain about that) and generic upstream; however I am talking about the builders' community instead.
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.
The builders community is where the next EL is built. It's Fedora ELN and CentOS Stream. You made your choice to keep focusing on "bug-for-bug" downstream instead, that's fine but I like it less than working together with Red Hat, Alma, Facebook, Intel and others.
Red Hat's action didn't screw over the builders community. It did complicate things in the short term for part of the users community, but at the same time it showed a clear way forward for builders that would not screw over users. Red Hat's intention is to stick to what they have been saying for three years and coalesce builders around Fedora ELN and CentOS Stream; not to screw over users.
Hence my original remark: if you think all Red Hat wants is to screw over communities again and again, your definition of community is not the same as mine.
> ostensibly earmarked for supporting the Fedora project.
Thanks for that. I never said you don't support the rpm-/Fedora-based ecosystem as a whole, and I appreciate that you also do so monetarily.
This is the dichotomy it pains me to see. Users who contribute are builders. That's the open source way. You don't have to be on a SIG or involved in the monthly meetings of an advisory council to contribute value to open source projects.
Maybe this dichotomy prompted the whole "hackers and hobbyists" imagined threat.
By builders I mean specifically those users that work with the full set of RPMs of the distro. It's not a badge of honor, it's a specific and very specialized way to consume what a distro offers.
In the case of EL, Fedora and CentOS Stream are communities that office both users and builders, but the two groups congregate in different places. For example EPEL is targeted at the user community but it is outside the focus of the builder community. ELN is of interest to builders but it is outside the focus of the user community.
All users can choose to contribute (with bug reports, code, whatever) at either the upstream or the distro level; or they can just be users. Builders are a (very small) subset of the people who consume a distro, and like all users they can choose how much to participate in the community and whether to be contributors or not.
But that ship sailed, the good of the downstream users' contributions are not enough to cancel out the negative net value of the builders' bad behavior.
I absolutely haven't said I consider builders bad and I also was careful not to say rebuilders! I am being very careful with my words. Please don't put things I didn't say in my mouth.
However: unfortunately part of what you said is true. Red Hat apparently took this decision because of some new facts that caused the negative from the "rebuilders" to increase, and the decision had the potential of hurting the users of the rebuilds.
Fortunately it's clear now that there are multiple ways for the downstreams to adapt[1]. Users will be able to keep their distros and—if they wish—contribute in a number of ways to the community. And builders and Red Hat will be able to collaborate in a shared place which is ELN for major released and Stream for minor releases. In a sense this removes excuses from Red Hat and should make everyone feel safer.
[1] you could say despite Red Hat's change, and I accept that. But it's also thanks to Red Hat going overall beyond the requirements of the open source licenses, with things such as Stream and the UBI source container.
I know reading is hard, but the Rocky Linux project and SUSE have not teamed up. That is an entirely CIQ endeavor. The project's blog post from some time ago also explains the two avenues they're going down for their clone.
P.S. for other commenters. A fork is NOT a distro. If someone forks a project (as the shape of a fork implies), they go their own way. So if Oracle and SUSE fork RHEL, good luck on standardizing "enterprise" Linux.
Fedora and regular CentOS Stream aren't ABI compatible with RHEL. With AlmaLinux being based on the equivalent upstream RHEL release, most software should work like on RHEL. (That's because small differences in security fixes don't usually impact whether programs work (that's the entire point of them).)
At least that's my understanding fromwhat I've read.
CentOS Stream is ABI compatible with RHEL. It has to be, because RHEL minor releases are produced from CentOS Stream. Nothing can go into Stream that wouldn't go into RHEL.
> In the meantime it's not 100% clear how Rocky will continue working (they referenced some workarounds but not specifically how they'll get the source code from RHEL).
Weren't they spinning up virtual machines on public clouds, running their scripts, and getting the source from those VMs?
His previous endeavor was YC partner, right? So a rich VC turning to a CEO. To make even more money. How original. If any prominent figure was to be credited here beyond Ilya S., well that would probably be Musk. Not S.A. who as a YC partner/whatever played Russian roulette with other rich folks' money all these years... As for MS hiring S.A., they are just doing the smart thing: if S.A. is indeed that awesome and everyone misses the "charisma", he'll pioneer AI and even become the next MS CEO... Or Satya Nadela will have his own "Windows Phone" moment with SamAI ;)