5 ms·

There are a number of shops where it is advantageous to have a paid RHEL subscription, mostly when there are non-technically-focused management involved. When

There are a number of shops where it is advantageous to have a paid RHEL subscription, mostly when there are non-technically-focused management involved. When there is an issue I've had managers in the past say "Quit dicking around on the internet and get someone on the phone". For these shops, you don't need the paid enterprise offering across the board (dev, testing, etc) so that is where an EL rebuild is handy. In those cases you don't want too much different between prod and test/dev, but you don't need the paid support or priority patches on internal test hosts.

6c696e7578 3y ago
Do the managers think the person getting the ticket at RH will not be dicking around on the internet?
- ta1243 3y ago
  Managers think the blame parcel has been moved to a supplier
  - hestefisk 3y ago
    It’s called “risk management” in corporate speak.
    - ta1243 3y ago
      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.
  - 6c696e7578 3y ago
    Yeah, this does seem to be the prevailing way in management layers.
- op00to 3y ago
  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.
  - pookha 3y ago
    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.
  - zetta0 3y ago
    My RH support experience was bad enough for me to switch to Rocky Linux. I suppose people's experiences in life can be different?
- zzzeek 3y ago
  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.
  - linuxdude314 3y ago
    I'm kind of shocked the average HN user seems to be so incredibly ignorant on this matter. Is this an ego thing?
  - 6c696e7578 3y ago
    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.
    - zzzeek 3y ago
      > 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.
      - 3y ago
- throwaway173738 3y ago
  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.
adql 3y ago
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
- mistrial9 3y ago
  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 ?
  - dsr_ 3y ago
    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.

6c696e7578 3y ago

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

ta1243 3y ago
Managers think the blame parcel has been moved to a supplier
- hestefisk 3y ago
  It’s called “risk management” in corporate speak.
  - ta1243 3y ago
    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.
- 6c696e7578 3y ago
  Yeah, this does seem to be the prevailing way in management layers.
op00to 3y ago
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.
- pookha 3y ago
  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.
- zetta0 3y ago
  My RH support experience was bad enough for me to switch to Rocky Linux. I suppose people's experiences in life can be different?
zzzeek 3y ago
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.
- linuxdude314 3y ago
  I'm kind of shocked the average HN user seems to be so incredibly ignorant on this matter. Is this an ego thing?
- 6c696e7578 3y ago
  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.
  - zzzeek 3y ago
    > 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.
    - 3y ago
throwaway173738 3y ago
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.

adql 3y ago

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

mistrial9 3y ago
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 ?
- dsr_ 3y ago
  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.