Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat is pretty good at being Red Hat

redmonk.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Red Hat is pretty good at being Red Hat

#51

Post by jacques_chester »

cat199 wrote: post #50
jacques_chester wrote: post #47

Earlier quoted context omitted.

> but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend. They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. Owning your own bespoke platform is a giant money hole. The arguments in favour of doing so are plug interchangeable with "let's write ou…

> They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. yet strangely these sorts of straw-man organizations adamantly refuse to open source any such projects even if they have nothing to do with their business because of the perceived loss of intellectual property value..

Because strangely, it's really expensive to audit your code, it's really expensive to get sued if you flub it, it's expensive to replace all the bits you can't opensource and it buys you approximately nothing in return except a comment on Hacker News accusing you of some ulterior motive.

Re: Red Hat is pretty good at being Red Hat

#52

Post by zzzeek »

cat199 wrote: post #50
jacques_chester wrote: post #47

Earlier quoted context omitted.

> but just impossible to pay 100x less to someone in-house who could add a couple of features into existing in-house software on a weekend. They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. Owning your own bespoke platform is a giant money hole. The arguments in favour of doing so are plug interchangeable with "let's write ou…

> They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. yet strangely these sorts of straw-man organizations adamantly refuse to open source any such projects even if they have nothing to do with their business because of the perceived loss of intellectual property value..

if you're a business with capital-M-Money, and you put "hello world" up on github, if someone wipes out their machine running it they're going to sue you. Doesn't matter what license you put on it, you're going to need the lawyers and they cost more money than you would have theoretically gained by putting your crappy "hello world" with the accidental "rm -fr" command in it up on github.

Re: Red Hat is pretty good at being Red Hat

#53

Post by cyphar »

cat199 wrote: post #48
cyphar wrote: post #31

Earlier quoted context omitted.

Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux, and has gotten a lot of work in recent years. eBPF (both for seccomp and tracing) is also quite exciting in terms of its applications. User namespaces are also allowing for developments such as rootless containers. There's also some interesting stuff for trusted computing that are happening with IMA and TPM developments…

> Checkpoint-restore of processes (CRIU) is a fairly cool technology that is quite unique to Linux DragonFlyBSD has had process checkpointing for more than 10 years. https://www.dragonflybsd.org/cgi/web-man?command=checkpoint&... While the functionality is admittedly & unfortunately quite limited, there are no technological reasons this couldn't have been furthered in the meantime given sufficient funding/dev time, e…

CRIU has so many more features and is so much more powerful that I don't think it's a fair comparison at all to make. You might argue that you could have implemented all of the features on another system like DragonFlyBSD (and in fact I would argue it would've been easier than doing it on Linux) but I don't see why that statement matters. What makes CRIU "unique" is that it does have those features and it is used on production systems for live migrations. I remember there used to be very old Linux tools that did the same thing in the same timeframe as checkpt, but they weren't widely used either because they didn't support any of the things CRIU does.

For example, not being able to restore sockets of any form (such as TCP sockets) is a massive limitation that CRIU doesn't have. userfaultfd allows for CRIU to have a slave process that is used as a source of lazy page loading from another machine (allowing for viable cross-host checkpoint/restore with on paper no downtime). And you can use CRIU to checkpoint/restore entire containers (DragonFlyBSD doesn't have Jails, but it looks like you can't even checkpoint process trees).

Re: Red Hat is pretty good at being Red Hat

#54

Post by cyphar »

throw2016 wrote: post #38
StillBored wrote: post #19

Earlier quoted context omitted.

Redhat supports the community by providing tons of maintainers/maintenance of projects. So, they may not support $PROJECT with dollars, but for a few thousand projects they base their business on, they provide hundreds of thousands of dollars in year in engineering time fixing bugs, or updating things which are bothering their customers. Particularly on all the unsexy portions of the OS that everyone else has moved o…

'Maintenance' sounds like a takeover without compensation. Surely with $3 billion in revenues Redhat should have a open source fund to sustain people whose code they use? Shouldn't some money find its way back to all the open source projects?

Red Hat (and SUSE, Canonical, etc) also employ a lot of upstream maintainers to continue doing their job. That's a much more sustainable model than having companies donate to upstream.

Re: Red Hat is pretty good at being Red Hat

#55

Post by hyperbovine »

raverbashing wrote: post #9
StillBored wrote: post #3

I've been hearing the "boring" comment a lot lately, and I totally agree. I don't want the exciting filesystem (btrfs which just took me for a ride), or the exciting programming language/library that will strand me in 6 months with multiple man-years of work. No, what I want is boring. That means everything works as I expect it too, and it doesn't create drama every few months when the cool kids decide that the old w…

Also people don't remember how the old proprietary Unixes were very boring Few things changed between versions and they would tell you exactly what would change between versions so you could be prepared. (however I have much less trust in a distro running SystemD, it is not stable or reliable)

I thought the same thing. RedHat has become the open source Solaris. I guess that's not such a bad thing. Solaris had some truly astounding engineering -- dtrace and ZFS felt like using software products that had been shipped to me from the future.

Re: Red Hat is pretty good at being Red Hat

#56

Post by breser »

cyphar wrote: post #36
breser wrote: post #8

Earlier quoted context omitted.

A fork can imply many things, but all supersets are forks. I realize that RedHat doesn't like calling OpenShift a fork, but it fundamentally is. The only people that will maintain their additional functionality is RedHat themselves. If you manage to avoid all of their added functionality then you can avoid the vendor lock in. But you can't avoid the delays in getting upstream features/bug fixes. If Kubernetes was sup…

I don't understand why people are so fork-a-phobic, and anti-patching these days. Distributions (like Red Hat and SUSE, but also Debian, Ubuntu, Fedora, openSUSE, etc) have been doing this for decades. Forking a project is something that is unique to the free software community, and we're doing ourselves a disservice by not taking advantage of this freedom. Forking a fast-paced project like k8s is fairly ambitious, a…

I'm against forks like OpenShift because as an upstream maintainer on a major open source project, distribution patches caused us nothing but headaches. Their well meaning patches almost always caused problems. Users routinely ended up at our doorstep with the issues they caused. We then either told the user to go bug their distribution, spent time digging into the issue, or got lucky and the distribution maintainers actually paid attention to our lists. The latter one was actually pretty rare.

You presume I don't have experience with open source projects and don't understand why things might not be accepted, which isn't really true. I used clout as short hand for doing the work to actually get changes into upstream. I'll admit I probably chose a poor word there.

I really can't fathom why Routes wasn't just adopted into Kubernetes directly instead of a complete rewrite of Ingress being added. I don't know all the details, but when I went digging what I found was RedHat folks explaining what they did and Google engineers writing Ingress.

Please also understand, I totally agree that RedHat and other packagers are fully within their rights to patch things. I think they really shouldn't. They cause at least as many problems as they solve in my experience. But it's also my right to say that I don't want to use their patched stuff.

I don't see the situation with the Linux Kernel as a success story. I see it as a failure. It's downright impossible to tell someone if something is going to work with their kernel because the version numbers are utterly meaningless since the distributions patch all sorts of things in and out. I have been running Linus' mainline kernels for the last several years and I've been broken exactly once and even then only very slightly.

I tend to think that if distributions avoided patching unless absolutely necessary and worked with upstream to get things included first we'd all be a lot better off. Those reasons why the patches weren't accepted quicker would get dealt with before things were in the hands of users.

But frankly the distributions incentive is to create value for themselves. Not help the project along. Helping the project is utterly secondary to any value creation they are doing for themselves. In fact you give an excellent example. You say that upstream is terrible at release engineering. So rather than just applying a patch to a distribution, it's really beyond me why distros don't work with the upstreams to improve their release processes if that's the problem with staying with a pure upstream.

That's not to say that distros don't create any value for the overall community. It's just my opinion that they don't create as much value as I think they should. These companies are taking in massive amounts of money off the open source projects. Sure, in some cases they have maintainers/contributors to upstream projects on their staff. But those are usually the cases where what I'm talking about isn't what is happening.

Now all of that sounds like I don't think distros should ever patch. Which is probably an exageration of my position. I think there are times when it's needed. Security fixes, unresponsive upstreams, etc...

But adding completely distinct functionality. I don't want to touch that with a 10 foot pole.

Edit: Forgot to say, your comment about the migration to upstream feature bit. I flat out asked RedHat how they planned to get people to migrate to Ingress. Their answer was they didn't have a plan.

Re: Red Hat is pretty good at being Red Hat

#57

Post by breser »

smarterclayton wrote: post #25
dasil003 wrote: post #15

Earlier quoted context omitted.

You're sort of twisting GP's point by saying that because K8s is not super stable, Red Hat will provide stability via OpenShift. I mean yes, Red Hat will certainly provide a more stable version, but it's a double-edged sword, because K8s might leave OpenShift in the dust with some incompatible change, and then a few years down the line you could end up with serious buyer's remorse when K8s is an order of magnitude be…

I can assure you that openshift will always be Kube++. It's just a Kube distro. The fact that today you need to compile in those extensions is a detail that we and others spend most of the time addressing. Odds are, most of the things you use in Kubernetes were because someone working on OpenShift wrote, tested, performance tested, and stress tested in production. When LTS OpenShift is a thing, there will still be an…

You've got a mighty big crystal ball there then.

Sarcasm aside. A major part of the allure of Kubernetes is that it's not a single vendor project. It's unlikely to die if something happens to RedHat. Say someone like Oracle comes along and buys you guys. But that's not the case with OpenShift.

Maybe you're right that things will continue as is and OpenShift will always be better and that RedHat will always maintain it.

But not particularly a risk that I think is worth taking.

Re: Red Hat is pretty good at being Red Hat

#58

Post by dankohn1 »

breser wrote: post #5

OpenShift is a fork of Kubernetes. Case in point. OpenShift has functionality called a Route. That isn't in Kubernetes. Kubernetes of course went and added something similar called ingress. This means that anytime Kubernetes does a release that RedHat has to manage merging all those changes in with their local changes that aren't part of their project. This is exactly the same sort of thing that RedHat does with thei…

You might be interested in CNCF's Kubernetes Software Conformance Working Group, which has been working closely with the Kubernetes's architecture and testing SIGs and providers of most of the Kubernetes distributions (including Red Hat) to ensure interoperability.

https://www.cncf.io/certification/software-conformance/

Re: Red Hat is pretty good at being Red Hat

#59

Post by cpitman »

jacques_chester wrote: post #46
snuxoll wrote: post #39

Earlier quoted context omitted.

CRIU looks amazing, live-migration of LXC containers :)

There are rough edges to be worked out before we arrive at solidly productionised systems, but I believe Red Hat and Docker are both heading in that direction. Mind you, ask yourself: why do you need it? If it's for apps, isn't the point of these platforms to not need to care about individual instances? If it's for data, don't you have an existing way to manage HA or parallelism?

Yep, every time I hear people get excited about live migration of containers I have to give them a sideways look. If you are running only one instance, than availability must not have mattered that much to you.

Re: Red Hat is pretty good at being Red Hat

#60

Post by cpitman »

zzzeek wrote: post #52
cat199 wrote: post #50

Earlier quoted context omitted.

> They don't spend more money for fun. They do it because they've had experiences of many on-a-weekend projects become critical-path nightmares. yet strangely these sorts of straw-man organizations adamantly refuse to open source any such projects even if they have nothing to do with their business because of the perceived loss of intellectual property value..

if you're a business with capital-M-Money, and you put "hello world" up on github, if someone wipes out their machine running it they're going to sue you. Doesn't matter what license you put on it, you're going to need the lawyers and they cost more money than you would have theoretically gained by putting your crappy "hello world" with the accidental "rm -fr" command in it up on github.

Has this ever happened? There are plenty of companies that are not software companies releasing open source software.
Post reply on HN