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

71–80 of 81 posts

Re: Red Hat is pretty good at being Red Hat

#71

Post by smarterclayton »

breser wrote: post #56
cyphar wrote: post #36

Earlier quoted context omitted.

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…

Hrm, we've had a plan for a while, so whoever told you that may have been misinformed (sorry about that, not everyone always catches up).

https://github.com/openshift/origin/blob/master/pkg/cmd/infr...

Is in 3.6, and other improvements will continue to be added. The one downside is that you have to grant the router proxies access to secrets, which means if someone compromises your edge ingress controller they can root your cluster unless you are very careful about only giving the routers access to exactly the secrets they need. That's partially why Routes contain their own secrets, so that you can't accidentally expose yourself to a cluster root.

This sort of stuff is the details the OpenShift team spends most of its time on. Kube will eventually get most of this. But most people are running single tenant Kube clusters and so in Kube we spend more time focusing on making that work just right. It's pretty difficult to build a fully multitenant Kube setup without making choices that we're just not ready to do in Kube yet.

Re: Red Hat is pretty good at being Red Hat

#72

Post by yesiamyourdad »

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…

Preach it!

Current job shows all the scars of this, every 6 months people hate the current system and want to rewrite something using some framework/lang/library that will really make everything better. The one positive aspect is that my resume now has every single buzzword. The downside is that the current team inherited 5+ years of failure to focus and address the problem at hand and instead try to run away from their problems.

Re: Red Hat is pretty good at being Red Hat

#73

Post by snuxoll »

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?

You’re making assumptions that I’m thinking of Docker, which couldn’t be further from the case. I’m looking at using LXC/LXD to replace full-fat VM’s for highly stateful, single-instance services - game servers. Being able to live-migrate a LXC container to drain a host for maintenance is indeed a useful feature to have.

Re: Red Hat is pretty good at being Red Hat

#74

Post by jwmullally »

mac01021 wrote: post #20
digi_owl wrote: post #14

Earlier quoted context omitted.

Amen. Sadly it seems in a sense RH is funding both sides at the same time, as many of their employees are the very source of the "exciting" developments happening in the Linux ecosystem these days. Thing is though that in a sense the Linux community has painted itself into a corner. Thanks to the likes of RHEL, Ubuntu LTS and Debian Stable, there is little reason for the upstream to be anything but "exciting".

Out of curiosity, what are the exciting developments happening in the Linux ecosystem these days?

Flatpak is pretty damn awesome - a layered container-like attempt at tackling application distribution and Dependency Hell.

Re: Red Hat is pretty good at being Red Hat

#75

Post by jacques_chester »

snuxoll wrote: post #73
jacques_chester wrote: post #46

Earlier quoted context omitted.

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?

You’re making assumptions that I’m thinking of Docker, which couldn’t be further from the case. I’m looking at using LXC/LXD to replace full-fat VM’s for highly stateful, single-instance services - game servers. Being able to live-migrate a LXC container to drain a host for maintenance is indeed a useful feature to have.

I usually assume all sorts of things[0]; I've become accustomed to living in a world where strict division between state and logic is assumed, even for relatively intensive stuff like trading platforms and very large ticketing systems.

Kubernetes has been more open to absorbing sticky, less-factored workloads than more opinionated platforms are. Red Hat have definitely made that point to folk whenever we and they are competing for business.

I had occasion to look at CRIU relatively closely in recent times. It is, as I said, early days, with annoying corner cases that need someone to patiently fix and polish (we ran into problems with networking, environment variables and process IDs).

In your case it will probably become attractive in the next year or two, because both Red Hat and Docker Inc (which is why I mentioned Docker) are touting checkpoint migration as a feature and I expect both will devote engineering effort to productionise it.

As an aside, if you're using the JVM, there was a really clever paper on coordinating the JVM G1GC and CRIU to greatly improve migration time: http://www.gsd.inesc-id.pt/~rbruno/publications/rbruno-middl...

edit: [0] Which is why as usual I am a dimwit for starting with answers instead of questions.

Re: Red Hat is pretty good at being Red Hat

#76

Post by uiri »

SkyMarshal wrote: post #4
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…

Agreed. I would add a second question to your first: What are the risks of implementing this into production? Get them thinking as a matter of habit about both of those in tandem - what's the customer benefit, and what are the risks of doing it, and does the former justify the latter? Also, all programmers have a burning desire to build stuff from scratch, which is part of what's driving yours to incorporate cool new…

Also, all programmers have a burning desire to build stuff from scratch,

I don't think this is true at all. 80%+ of software work is maintenance related. People who have a burning desire for green field development won't last long so they are few and far between. In fact, this is one of the biggest differences between real projects in industry and fake projects in CS undergrad education.

Re: Red Hat is pretty good at being Red Hat

#77

Post by StillBored »

cyphar wrote: post #33
harryf wrote: post #21

Earlier quoted context omitted.

Programming is based on hero worship. Anyone who makes even half an effort to better themselves as a software developer will encounter famous names from the past - those that "made a difference" by creating languages, operating systems and algorithms. Keyword here is "create". This is not an industry that celebrates maintence programmers. There's no glory for the guy that spent 20 years keeping the system that your b…

As a fairly young programmer, I think it's not necessarily hero worship (though that does play a part). I think it's because a lot of young programmers define their identities in terms of what they do. This is especially prevalent in the free software community. If you're going to define yourself by what you work on, it doesn't seem very fulfilling to just keep an existing project running without having the freedom t…

The "boring" comment isn't meant to denigrate people's work. Rather, it should be taken as a complement for a job being done well. In fact I've heard the "boring" comment from a couple RH employees myself. So, I think they understand what is being said, rather than taking it in a derogatory manner.

Re: Red Hat is pretty good at being Red Hat

#78

Post by exikyut »

cyphar wrote: post #35
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…

The thing that makes distributions like Red Hat and SUSE "boring" is not that we only do maintenance work, it's that we've effectively solved the problem of maintenance and release engineering -- though of course there's still improvements to be made (and on the SUSE side, openSUSE Leap and the plans for SLE15 are quite interesting developments). We do a lot of work on exciting and interesting projects, some of which…

> The thing that makes distributions like Red Hat and SUSE "boring" is ...that we've effectively solved the problem of maintenance and release engineering

Hmm.

There are a lot of developers that could probably really do with some exposure to this kind of environment.

I could definitely see myself hugely appreciating, say, a 6 month stint doing... something relating to the nitty-gritty of keeping a distribution going, learning what the pitfalls are, what the unintuitive stuff is, etc. Basically being some key point-person's assistant (the one who deals with major disasters), or something.

It would be even better if some of this work could involve direct enterprise support: learning what customer requirements are, getting a sense of scale, etc. I can see this kind of information (enterprise support) being the most valuable - actual bespoke software would likely be a major focus of such training, and this would tech would-be developers about the disasters that can happen 5 years or 10 years on from "I have an awesome idea" "wow it's so elegant" etc etc. (Continuing from the previous point, perhaps there could also be an opportunity to be the assistant to the on-call person who sometimes wakes up at 3AM.)

You could position this as something for people looking for DevOps jobs, and maybe make some kind of cert for it as well (this would likely help with/create traction for/be needed for enterprise-level interaction).

I personally would have zero issues with signing a small book of NDAs to get this type of training myself. The NDAs would just cover how I learned, not what I learned, and in this context the how would be largely irrelevant (but at the same time incredibly invaluable). FWIW, I'd personally greatly benefit from a good debrief at the end of the course to help me find all the little ways I might accidentally leak something (eg a few too many words fall out before I stop myself etc) and learn to catch myself quickly.

Re: Red Hat is pretty good at being Red Hat

#79

Post by snaky »

dsfyu404ed wrote: post #40
snaky wrote: post #32

Earlier quoted context omitted.

There are some wannabe-heroes, but they aren't so widespread. The vast majority is just being pragmatic. Trendy toys and 'designed and implemented new X' in resume looks so much better for career than 'maintained something old so customers were happy'. Of course, there are some technologies that helps to make pretty good money even being ancient, like COBOL, APL, AS/400 and IMS. But for how long? So it seems rational…

That said, if you've got COBOL, Fortran, etc on your resume you're pretty much guaranteed to get asked about it in an interview.

Maybe discussion on mainframes transaction processing and COBOL features helping to implement it the way we know it thesedays as 'Cloud Functions' or 'AWS Lambda' might be a little bit more fruitful than reversing linked list pointers on a blackboard.

Re: Red Hat is pretty good at being Red Hat

#80

Post by organsnyder »

snaky wrote: post #29
organsnyder wrote: post #2

My company (20,000+ employees) just started an engagement with Red Hat this week. We went with them for exactly what the article describes: open source software, packaged in an enterprise (i.e. expensive) fashion to make it palatable. We could have implemented these tools ourselves, but the executives appreciate the support contract and training, and I'm already seeing how we can benefit from the consultants' knowled…

That's funny how things are done in big shops. It's pretty much okay to spend a good six digit sum for some tool done by 3rd party, 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.

You got downvoted for the hyperbole, but there's a lot of truth to this, in my experience. I don't think this is limited to big shops, either. There is a psychological phenomenon where people tend to place more value on things that have cost them more; I've experienced this myself when I've purchased a new vehicle—all of a sudden, it's the best vehicle on the market (it must have been, since I made the decision to buy it). The same thing happens with large business contracts.

As an in-house employee, it is incredibly frustrating when a vendor is automatically more credible than me, even though I've spent years building knowledge of my own company's business and systems. But I have experienced this both at my current 20,000+ employee enterprise, and a previous company where there were 5 employees.

Post reply on HN