Live data from Hacker News

The Red Hat model only worked for Red Hat

opencoreventures.com

211–220 of 222 posts

Re: The Red Hat model only worked for Red Hat

#211
post #92

Earlier quoted context omitted.

They can just use Alma Linux now, Red Hat does not see anything wrong with that.

For now. That may well change soon, who knows? They saw nothing wrong with CentOS until a year or two ago, for years.

Disclaimer: I work for Red Hat, but not as a spokesperson

I may be off, but hey. As I understood it at the time, the reason wasn’t “OMG there are folks not paying us for the bits” but rather “we have this number of engineers, they can work either on CentOS Linux or on Stream” and Stream is more of a benefit to Red Hat as an upstream for RHEL.

Re: The Red Hat model only worked for Red Hat

#212
post #12

> If Red Hat tried to force people to pay too much, everyone would switch to the freely distributed versions (AlmaLinux, Rocky Linux, etc.). Not if they need a long term supported and certified OS with various compliance checkmarks associated with it.

Check out https://www.resf.org/ and https://ciq.co/ (founded by Greg Kurtzer) for support and compliance.

Re: The Red Hat model only worked for Red Hat

#213
post #145

Earlier quoted context omitted.

I work for a company that ships safety-certified software. We, or often our customers, have discovered bugs in that software. We do not fix the bugs because one single small bugfix means re-certifying the entire software , a process that takes months of producing proof of matching the safety case plus many more months of updating and approving accompanying documentation and going through an audit. Everything has to b…

We have discovered a critical bug in QNX 6 kernel in a networking scenario. There is no workaround, since the bug was in the core of their message passing infrastructure - a non-blocking by design kernel call, SendPulse(), sometimes blocks. It took me 9 months talking to them about this problem until I managed to reproduce it on just two nodes and half a page of code, and record kernel logs that clearly showed a race…

There is no safety-certified Linux. As far as I know there was no safety-certified QNX 6 either (QOS 1.0 was based on QNX 6.5 SP1, which is not the same as QNX 6 despite the numbers looking eerily similar).

With a safety-certified system, you do not receive a patch because it violates the safety certification. Of course, you can get a patch and use it but then you're responsible for safety-certifying the entire stack including the closed-source vendor code, and best of luck.

Re: The Red Hat model only worked for Red Hat

#214
post #101

Earlier quoted context omitted.

SUSE are probably the closest company to following Red Hat's business model (with a more European/German focus). The other ones are the cloud vendors who are getting around to realising now that without certification there are many government orgs, large companies, the military etc who simply cannot use their cloud services.

Which raises the question: Why doesn't Red Hat have a cloud offering yet?

IBM has a cloud offering, and IBM owns Red Hat

Re: The Red Hat model only worked for Red Hat

#215
The article describes, almost perfectly, the condition of being a productive enterprise within a capitalist free-market in which you are subject to competition.

What is striking is how, for observers within the tech-industry, this is perceived as a peculiar and inexplicable state of affairs, almost as if an alien creature has materialized through a portal into an alternate universe.

Re: The Red Hat model only worked for Red Hat

#216

I find it hilarious they are saying VCs wont invest in redhat style business because it's growth is not "hyper". These same VCs who are so fundamentally incompetent at the basics of capitalism, like risk management 101 of interest rates, that they had to get bailed out by the government, by the FDIC randomly deciding to rewrite the entire rule book that the rest of us normies have to live by.

It is no secret that VC's are not interested in productive enterprises which produce a reliable and fair return on investment through revenue-generating activities.

As you point out, They are obviously interested in concentration of vast amounts of wealth, which requires a completely different set of tactics. Cornering markets and establishing monopolies, regulatory capture, pump and dumps and other forms of grift and large-scale antisocial behaviour.

It should be completely obvious to any onlooker that they have no interest in innovation or technology :)

Re: The Red Hat model only worked for Red Hat

#217

The biggest reason why we don’t see support and services companies achieving hyper-growth is that they are uninvestable. Annual revenues are low and nonrecurring, and margins are tight. VCs are looking for 80%+ gross margins and hockey stick growth. In other words, Red Hat's model doesn't work for Wall St and VCs looking to make quick easy money riding out the next tech 'unicorn'. Red Hat has survived and thrived for…

I don't think this can be overstated enough. The incentives for vc-backed companies these days don't align with this model, hence the reason it's not more widely in use.

And a very good argument for taxing that money out of their hands and investing it into productive enterprises that spur actual innovation and gainful employment.

Re: The Red Hat model only worked for Red Hat

#218
post #165
post #98

Earlier quoted context omitted.

SUSE are very much still around, and they have the same successful model as Red Hat, with a more European (specifically German) focus.

In fact they have a new CEO who ran Asia Pacific for Red Hat.

oh this is new, really new, thanks for the hint.

Re: The Red Hat model only worked for Red Hat

#219
post #131
post #108

Earlier quoted context omitted.

because compliance is mostly about documentation. glorified checklists. but checklists work (you might have heard about surgeons leaving medical tools in patients, and checklists eliminating this problem, seemingly the dumbest simplest technology, yet it's very powerful compared to the default of nothing) of course the quality of answers matter, but that's on the environment (auditors, regulators, industry best pract…

>but checklists work (you might have heard about surgeons leaving medical tools in patients, and checklists eliminating this problem, seemingly the dumbest simplest technology, yet it's very powerful compared to the default of nothing) These glorified checklists also backfire all the time. With the surgeon it's indeed simple. With software what I see is that certification and process often lessens quality. Why you as…

All true! The checklist is only as good as the system that produced it, and that was basically the largest sentence/paragraph in the comment.

Having a forward-looking industry working in symbiosis with its top-notch quality high-functioning regulatory environment is the ideal state. It's rare. (I would say it's apprecition is academic only today. State-capability (or "state capacity") is getting to be a buzzword now for pundits[0][1][2][3]. But it's not that surprising that these problems seem to be cropping up now, in the Internet era, and not during the Cold War.)

My theory is that having a basic regulatory environment allows for increasing industry-wide quality effectively and quickly. For example the CDC is bad at counting COVID cases[2], but catching blindness causing eye drops with "just" ~70 cases countrywide[4] is a good example of the basic safety net.

Similarly, the whole aviation industry's safety process and context was what allowed the MCAS fuckup to come to light fast.

"Fun fact" regarding MCAS. If I recall correctly Boeing argued that the MCAS malfunction was covered by the runaway stabilizer procedure (checklist!), the astronomically bad UX of MCAS itself is what made pilots confused. (Because it activated for 10 sec every minute or something WTF like that, so they had no idea they need to get the runaway stabilizer checklist.) And that's exactly what you're saying. It wasn't sufficiently 737-like.

The workaround is to add UX to these type similarity checks done by the FAA and other regulatory bodies. And, again, exactly as you have mentioned, the cost-benefit discontinuity led to this bad trade off. And while we can't magically smooth over all of them, but at least (and that's my argument) we have good frameworks to start looking at them, detect, recognize, analyze and workaround them. (And checklists are the level 1 of these tools.)

[0] https://marginalrevolution.com/marginalrevolution/2020/01/wh...

[1] https://www.youtube.com/watch?v=zT-McydDEx4

[2] https://www.slowboring.com/p/the-cdcs-vaccine-data-is-all-wr...

[3] https://en.wikipedia.org/wiki/Why_Nations_Fail (but see also "The Narrow Corridor")

[4] https://www.nbcnews.com/health/health-news/recalled-eyedrops...

Re: The Red Hat model only worked for Red Hat

#220
post #208

Earlier quoted context omitted.

We have discovered a critical bug in QNX 6 kernel in a networking scenario. There is no workaround, since the bug was in the core of their message passing infrastructure - a non-blocking by design kernel call, SendPulse(), sometimes blocks. It took me 9 months talking to them about this problem until I managed to reproduce it on just two nodes and half a page of code, and record kernel logs that clearly showed a race…

This is exactly my point. Also, even if there is a workaround, more often than not the complexity of the mountain of workarounds just creates the next set of certified bugs.

It's a valid point, but the solution is not obvious. It's a trade-off in a big design space. (Of course with software it seems "trivial" to make sure the certification can be done quickly and cheaply. Just automate it! Unfortunately we're not there yet. :/ )

See also this comment: https://news.ycombinator.com/item?id=35589690

Post reply on HN