Do the managers think the person getting the ticket at RH will not be dicking around on the internet?

I once had a vendor support tech tell us to add build configuration variables like ARCH and CROSS_COMPILE to our .bashrc. This is a terrible idea for a variety of reasons I won’t get in to.

Red Hat employee here. They most certainly are not. The people on the phone have been through a lot of training, they are all whizzes on the command line, we have an enormous in-house knowledge base that's updated continuously, and there's a clear escalation chain as well (as an engineer, I get customer cases that resist known resolutions, so I will be the one "on the internet", searching for known MariaDB issues, things like that).

RH would not be of much value if the support staff were not any more effective than the average end user.

I'm kind of shocked the average HN user seems to be so incredibly ignorant on this matter.

Is this an ego thing?

That's my point, the guy who had the issue in the first place is doing the same thing you are.

It's only the boss that wants to pay for a safety net, forcing the issue of raising a ticket is their validation of money well spent I highly suspect. We're all human beings who are quite technical on this forum, you work for RH, the other guy works for someone else.

I have a suspicion that RH support is what the boss pays for as a backup should their employees be unable to solve a problem or decide to go to pastures new, as people do from time to time.

> That's my point, the guy who had the issue in the first place is doing the same thing you are.

they're not, because they have no idea what they're looking for, they lack the subject knowledge and expertise, and they werent involved with directly producing a lot of the open source components they are having problems with.

By "engineer" I mean, "we are the people that wrote the actual open source components they are having a problem with". It would not be in their interests to hire us directly because 95% of the time the regular support people can do everything they need without things escalated to engineering.

I very much doubt you have all the authors, some components are RH creations, but not all. In any case, a company hiring one or two open source contributors covers a lot of gaps as they're the type of people who can do deep investigations. For systemd, for sure, there's inhouse development there.

My gripe about the original thread was bosses interrupting that investigation and telling the onsite staff to open a case elsewhere, IMO, that's disruptive behaviour.

> My gripe about the original thread was bosses interrupting that investigation and telling the onsite staff to open a case elsewhere, IMO, that's disruptive behaviour.

I dont think this really happens, when we get these customer issues and the people who have tried to fix the problem are on the phone, they are lost / panicked / at a dead end. They are not like, "yeah we think it's ABC but our boss told us to call you". that's not really a thing. if customers can fix the problem, they do. they are not in a hurry to call redhat for things they can do themselves and they're not really supposed to since their support minutes are a finite resource.

Nobody would do that when logging a ticket because it shows internal company disagreement which often doesn't show the company in a great light. Nobody does that.

What typically happens in this situation is the chap logging the ticket gets pissed off and says to the boss, "ticket logged it's with $vendor, I guess it doesn't need babysitting so I'm working on other tickets now".

The boss in this case is happy as it shows their earlier investment was a fine idea. The employee though is disgruntled as their toys were taken away and things it's not such a fine place to work.

Managers think the blame parcel has been moved to a supplier

It’s called “risk management” in corporate speak.

Risk management is nothing to do with removing the risk from the company, indeed increasing risk is often acceptable. It's about removing risk from your department.

Yeah, this does seem to be the prevailing way in management layers.

Generally no, based on past experience with RH support, they're not just dicking around on the internet to find the answer. Most of the folks I know at RH support have been there 5+ years, and are life-long users and community participants in the project they're supporting.

I once worked in a large open-air office that had on-site support from VMWare (this was over ten years ago). The VMWare guy was a doofus and some of the 20 something year old IT staff appeared to know more about his product than he did. Provided no-value except for "knowing people"...One day he wasn't there and I asked if they finally fired this useless bozo and I was informed that he went to work with Redhat-support and that a new VMWare guy was inbound. Shook my faith in RHEL for years. Honestly I'm still not sure I trust Redhat after they hired such a loathsome fraud.

My RH support experience was bad enough for me to switch to Rocky Linux. I suppose people's experiences in life can be different?

There is definitely a value if you don't have a bunch of Linux nerds on board or desire to be the one that tracks why some random bug happens.

For just ease of management and customization can't beat vanilla Debian

last I knew, Debian requires config setup, not optional, not guided. There is no "defaults that work" for a network server. Is this still true in 2023 ?

Your question seems to be presupposing a bunch of things.

If you run the standard installer from a vanilla USB image, you will be asked questions about the config, most of which produce reasonable results if you just hit <enter>. Some of them will fail in certain environments. (No DHCP server? You will need to enter IP networking details.)

If you want to install a fleet of Debian machines (or VM images), you set up a PXE server and a set of answers to the installation questions, or you build an image for direct deployment, or you use the Debian VM image, or... whatever: there are a lot of possibilities that will work.

Most of this has been true for at least 3 Stables.