[HN Gopher] NASA secures contract with Rocky Enterprise Linux
___________________________________________________________________
NASA secures contract with Rocky Enterprise Linux
Author : InitEnabler
Score : 175 points
Date : 2023-06-21 13:07 UTC (9 hours ago)
(HTM) web link (sam.gov)
(TXT) w3m dump (sam.gov)
| Nifty3929 wrote:
| This headline reads backwards to me. While it would be true
| either way, it seems more intuitive to say "Rocky Enterprise
| Linux secures contract with NASA"
| activiation wrote:
| How new is sam.gov?
| linuxdude314 wrote:
| Very old.
| neilv wrote:
| Wikipedia:
|
| > _Rocky Linux is a Linux distribution developed by Rocky
| Enterprise Software Foundation, which is a privately owned
| benefit corporation that describes itself as a "self-imposed not-
| for-profit"._
|
| Is this only a structure set up to fund whatever needed to be
| done to rebrand RHEL? Or does anyone have shares that could be
| worth significant money?
| Luctct wrote:
| [flagged]
| 5e92cb50239222b wrote:
| I wonder why they didn't follow Fermilab and CERN and choose
| AlmaLinux.
|
| https://news.ycombinator.com/item?id=33904336
| leocrat wrote:
| Because Alma has ties to Russia.
| jaboutboul wrote:
| This is totally FUD
| zxspectrum1982 wrote:
| No, it's not. Alma was founded by CloudLinux, which is a
| Russian company with a Russian owner, mostly Russian and
| Eastern Europe developers and fake US address. As of today,
| CloudLinux still plays a critical role in Alma.
| aednichols wrote:
| How do I choose between Rocky and Almalinux? Or is it just not a
| big enough difference to worry about?
| bityard wrote:
| Last I looked, there was no real difference. I don't know if
| there would be any politics preventing it, but I would not be
| too surprised if they merged at some point.
| infinet wrote:
| Almalinux releases faster, and patches faster than Rocky.
| bongobingo1 wrote:
| They have different organisation structures, where Alma is a
| 501c Non-profit and Rocky is a backed by a B-Corp, so _in my
| head_ I read one of those as a community linux ie. Debian-
| feeling, and the other aims to make money ie: Ubuntu-feeling.
| That 's an extremely crude interpretation though, both need
| cash to support themselves, so both need to make money some
| how.
|
| Day to day they should be by design, interchangeable. Rocky has
| a nicer logo... This kind of ugly exchange on reddit[0] always
| sort of soured my impression of Rocky though, didn't really
| pass the lebowski test.
|
| 0.
| https://www.reddit.com/r/linux/comments/qv6mg2/were_the_alma...
| lockhouse wrote:
| Alma has been faster with releasing updates and security
| patches from what I've seen.
| senknvd wrote:
| This seems to be true. However, looking at
| https://rockylinux.org/news/rocky-linux-9-2-ga-release:
|
| _9.2 Release for PowerPC (ppc64le) architecture held back
|
| During testing, we discovered an architecture-specific issue
| on ppc64le systems with the bundled version of Python 3.9.
| This issue not only prevents installing, but may break
| existing installations.
|
| This issue is reproducible on CentOS Stream 9 and RHEL 9.2.
| We have opened a bug report upstream at rhbz#2203919 and are
| working to fix the issue._
|
| Seems like they hold back releases to do additional testing.
| In this case, they avoided a bug that was present on RHEL
| (and presumably AlmaLinux).
| jaboutboul wrote:
| https://bugzilla.redhat.com/show_bug.cgi?id=2203919
| jmclnx wrote:
| What I find interesting is all the bureaucracy needed to get 3
| licenses for a "Free" RHEL Clone.
|
| I wonder of Rocky got some real $ from NASA ?
| tssva wrote:
| They didn't get 3 licenses for a "Free" RHEL Clone. You can't
| purchase licenses for Rocky Linux. What they purchased was
| support.
| aardvarkr wrote:
| Out of curiosity, what makes this notable?
| candiddevmike wrote:
| If Red Hat hadn't sunset CentOS/RHEL parity, none of this would
| have happened, maybe. Rocky wouldn't exist.
| Covzire wrote:
| Would this have happened if IBM hadn't bought Redhat?
| away271828 wrote:
| Probably. Red Hat acquiring and then maintaining a failing
| CentOS was one of those solved a problem at a couple times
| things that just didn't make a lot of sense in the long run
| (and was almost certainly a mistake).
| axus wrote:
| CentOS was great and I'm still using CentOS 7 until EOL.
| I learned a lot from "the mouse" in the CentOS support
| forum, and I hope the CentOS people made a living from
| the deal. I've got no bad feelings towards Red Hat, as
| long as they weren't coercing anyone against their will.
| For new systems I use both Red Hat and Rocky.
| spicyusername wrote:
| It's another link in the Red-Hat-CentOS-drama chain.
|
| I think many IT employees have a vested interest in Red Hat and
| the direction of "enterprise Linux". Seeing an organization
| like NASA show a willingness to use a Red Hat alternative gives
| credibility to that alternative.
| [deleted]
| osigurdson wrote:
| Of course, if we do get an established leader, it will
| ultimately see the same fate as Centos.
| _joel wrote:
| It's by the guy who setup CentOS originally, no?
| dralley wrote:
| Giving users the ability to have a choice in the direction of
| "enterprise linux" is a large part of the reason that CentOS
| Stream exists. Previously if you wanted some bug fixed or
| some feature added you needed to beg Red Hat for it or hope
| that a paying customer needed it too. Now external parties
| can contribute to the future release of RHEL (and Rocky,
| Alma, etc.)
|
| So let's say that some Rocky or Alma Linux user or developer
| wants to make a change. They are RHEL clones, so they can't
| do that. But they can now contribute the change to CentOS
| Stream, which is the upstream for both RHEL and their own
| distro. That change can be reviewed and tested by the
| community + Red Hat, and then land in RHEL a few months
| later.
|
| This isn't theoretical, to use one example, Facebook uses
| CentOS Stream in production and contributes back a
| significant amount.
|
| Disclosure: I do work for Red Hat. But it never made sense to
| me why people say that the "CentOS community was destroyed"
| when it didn't really have much of a community, it had
| _users_, which is different. It has more of a "community" now
| than it did previously, because the development is actually
| open as opposed to Android-style "throwing bundles of code
| over the wall".
| adql wrote:
| > Giving users the ability to have a choice in the
| direction of "enterprise linux" is the entire reason CentOS
| Stream exists.
|
| Pretty sure it's just for free beta testing
| freedomben wrote:
| More than one thing can be true at a time. GP's
| explanation is one of the reasons. IMHO it's not the
| _primary_ reason, but it is a legit entry in the "pro"
| column
| [deleted]
| Atreiden wrote:
| I think this is notable because in the wake of RedHat changing
| CentOS model changing from stable to bleeding-edge, there has
| been a niche to fill in the enterprise-grade Linux space. Esp
| for people running on-prem infra e.g. HPC. Do we settle on
| Rocky? Alma? Amazon Linux2?
|
| NASA seems to be taking the lead here and saying "we're going
| with Rocky". I think this move will encourage others on the
| fence to do the same, and build more of a community around the
| product not owned/maintained by Amazon.
| dralley wrote:
| >bleeding-edge
|
| CentOS Stream is not "bleeding edge". Every update that goes
| into CentOS Stream has already gone through the Red Hat QA
| process, and the updates are restricted to only the kinds of
| things which previously would have gone into RHEL. That is,
| mostly security updates and bugfixes.
|
| It's a little bit ahead of RHEL, but it's not like Fedora,
| much less Rawhide.
| anyoneamous wrote:
| > Esp for people running on-prem infra e.g. HPC. Do we settle
| on Rocky? Alma? Amazon Linux2?
|
| Given the stage of the lifecycle, you'd be pretty silly to
| adopt AL2 on-prem at this point. AL2023 probably won't be
| appropriate either. Rocky is the way to go.
| freedomben wrote:
| > _in the wake of RedHat changing CentOS model changing from
| stable to bleeding-edge_
|
| CentOS is now bleeding edge? Would you describe Debian Stable
| as bleeding edge also? On your contiunuum, where would you
| place Arch and Fedora?
| tkuraku wrote:
| I don't understand why they don't buy RHEL. Rocky is essentially
| RHEL. If RHEL isn't supported there is no Rocky.
| p_l wrote:
| It's probably an evaluation in preparation for removing CentOS
| in ways other than buying RHEL.
|
| Federal agencies can't really use CentOS after 2024-06-30, so
| everyone dealing with federal clients is working on an upgrade
| path (CentOS was a major solution due to piggy backing on RHEL
| certifications )
| dralley wrote:
| There is no Rocky Linux 7, and CentOS 8 is already EOL, so I
| think it's a valid question.
| p_l wrote:
| There's a lot of CentOS 7 in various USGOV and adjacent
| (suppliers/service providers) who are stuck facing purchase
| of RHEL8/9 licenses or migrating to other distros - as
| CentOS 7 going EOL on 2024-06-30 means you can't use it for
| federal systems without each federal client getting a
| waiver.
|
| You have to either go with another distro or provide your
| own support (essentially your own fork).
|
| Those who want to stay with RHEL-like but not deal with
| actual RHEL licensing are often going with Alma or Rocky.
| mrweasel wrote:
| There's also the question: If I buy support from Rocky Linux
| and they provide a fix for something, then they'd need to
| upstream it, or how much can they allow Rocky to drift from
| RHEL, and for how long?
|
| What if they surplant RedHat, can they afford to undermine
| RedHat long term, or is there a point where they fork?
|
| Rocky Linux, and CentOS before it, is a strange product for
| people who want the benefits of RHEL, but don't want to pay for
| RedHat work. If you don't want support, then I think is fine,
| that the cost RedHat pays to be an open source company, but
| when you then turn to another company who rebadge RHEL and
| charge for support, it gets a little weird.
| brewdad wrote:
| Is this the software equivalent of buying a generic drug?
| It's the same basic product but the details may make it work
| just as well or less well for any specific user. If it works
| for NASA and they save money, it seems like a win.
| mrweasel wrote:
| No quite, the generic drug makers can produce the product
| from scratch without the help of original manufacturer.
| Also RHEL is contentiously being developed, once a drug has
| been designed, there's no requirement to keep it updated
| (ruffly speaking). Rocky Linux is dependent on RedHat
| staying in business.
|
| The problem will only manifest itself if RedHats business
| is sufficiently underminded. Losing a few customers isn't
| an issue, and many of the users of Rocky Linux probably
| wasn't going to buy a RHEL licens anyway.
| jabl wrote:
| Wonder if the timing of this is a coincidence, considering that
| RedHat just announced they're stopping releasing RHEL sources
| except to paying customers:
| https://www.redhat.com/en/blog/furthering-evolution-centos-s...
|
| Link submitted by someone at
| https://news.ycombinator.com/item?id=36417070
| whatyesaid wrote:
| Well, they killed CentOS so I would expect nothing less. What
| would the recourse of Rocky/Alma be then?
| totallywrong wrote:
| I'd been wondering when that was going to happen. There's got
| to be a point when you grow tired of Oracle, Rocky and the like
| taking customers from you using your very own sources. That
| said, it didn't seem to be a major issue before the CentOS mess
| they created all by themselves.
| omniglottal wrote:
| It's important to be accurate when considering the actual
| situation. With that in mind, please elaborate on the phrase
| describing "sources" as though they are Red Hat's "very own".
| Is this honestly the case, or are you forgetting something
| truly relevant about the sources which Red Hat uses to build
| its products, and the legal obligations which apply to any
| users of those sources?
| totallywrong wrote:
| "Very own" as in you've put in the work to curate, test,
| and bundle together a ton of disparate software to create a
| cohesive final product. Let's not pretend that there isn't
| a ton of value in that which these other companies are
| taking advantage of.
| edgyquant wrote:
| You have to pay RedHat to use its software. Only giving
| source code to paying customers doesn't violate the GPL
| because of this. You only have to release sources to the
| users of your software.
|
| RedHat has been giving them away to everyone; but they are
| not legally obligated to do so
| Phrodo_00 wrote:
| As an interesting addition, Red Hat can't stop their
| customers from sharing GPL and LGPL package sources.
| jacooper wrote:
| But oracle or rocky can just subscribe to RHEL and continue
| having access to the source code, right?
| totallywrong wrote:
| I suspect that republishing the sources will be against the
| terms you agree to in your subscription.
| jacooper wrote:
| They can't add more terms on the GPL and call it GPLv3.
| pavon wrote:
| Yes they must abide by the terms of the licenses of the
| software they redistribute. But they could start
| licensing the parts they write more restrictively, like
| RPM spec files. I don't think this will happen given how
| much back and forth there is between RHEL and Fedora, but
| IBM is in charge now.
| m463 wrote:
| I believe the GPL - which redhat must agree to when
| redistributing binaries - prevents redhat from creating
| that sort of restriction.
| dralley wrote:
| I don't believe the terms of service restrict (or even
| could restrict, see GPL) the redistribution of _sources_.
| Compiled binaries are another matter.
| saltcured wrote:
| The game that has been spelled out elsewhere is that the
| subscription can be terminated for this violation of the
| subscription terms of service (which is not the same
| thing as the software license). This termination would
| prevent you from receiving future versions of binaries or
| sources.
|
| So, RedHat can satisfy the letter of the law regarding
| licensing, where source is distributed under GPL to those
| who received the binaries. With each incremental binary
| distribution they satisfy the GPL rules and makes source
| available to the recipient of binaries, but they may cut
| off a customer as soon as they detect that the customer
| is actually exercising their full GPL rights. So that
| customer loses access to future binaries and
| corresponding sources.
|
| This attitude violates the experience many of us take for
| granted about free software and the GPL, where we expect
| a community to be engaging as an equivalence class of
| members sharing the same rights. But the GPL started with
| provisions enabling this narrower sense. The source
| distribution could be offered individually to each
| recipient of binaries _or_ made generally available to
| the public independent of any existing exchange of
| binaries between two parties. So the GPL allowed the
| recipient to transitively distribute the sources they
| have received, but does not actually obligate the
| original distributor to also provide sources to other
| unrelated parties.
| mananaysiempre wrote:
| > So the GPL [...] does not actually obligate the
| original distributor to also provide sources to other
| unrelated parties.
|
| It seems important to note that the Debian Free Software
| Guidelines as applied by the Debian project specifically
| exclude any software that requires providing source to
| unrelated people this way (the "desert island" and
| "dissident" tests[1]). In practice, the "unrelated"
| people in license terms of that kind are usually the
| original copyright holders.
|
| [1] https://people.debian.org/~bap/dfsg-faq.html
| mananaysiempre wrote:
| They can't, I think, but nothing prevents your _support
| contract_ (and thus access to subsequent updates in any
| form) from terminating when you release the source. You
| can do it, IBM will just refuse to do any more business
| with you from that point on.
|
| This kind of GPL not-a-workaround always made me feel a
| bit queasy, but open access to RH code (even if a bit
| stale and hard as hell to get to build) alleviated that
| feeling somewhat. I guess it no longer does.
| op00to wrote:
| What a weird way to spend federal money. I say it's weird because
| NASA almost certainly has its own internal Linux support paid
| through overhead in one form or another, and again the
| incremental cost of adding "developer" support from Red hat is
| way, way cheaper than Rocky.
|
| Finally, I doubt Rocky's support can perform as well as Red
| Hat's. No, I'm not talking about the people who talk on the phone
| when you break something. If you find a bug in a package, will
| Rocky be able to quickly and effectively upstream the fix, or
| will Rocky end up maintaining you on a custom patchlevel forever?
|
| I doubt Rocky has the ability to truly fulfill 24/7 support. It's
| difficult to build a deep bench for support, and nearly
| impossible to make sure you're keeping up 24/7 capability for
| other Maintenance Engineering type tasks.
|
| And if none of these reasons are important enough to stop you
| from paying them, maybe the thing you're doing isn't important
| enough to warrant paying for support anyway.
| aaomidi wrote:
| Honestly I suspect rocky support to be faster than red hat.
| Kaytaro wrote:
| What makes you think a company with 89 employees that just
| clones Red Hat's source code would be faster than Red Hat
| with 19,000?
| josephcsible wrote:
| On multiple occasions, I've had Red Hat take 6 months to
| resolve a paid support case to fix something that already
| had a fix plus test cases committed upstream, and that
| could be cherry-picked into their version with no
| conflicts.
| bonzini wrote:
| "Take 6 months" sounds a lot like "distribute the fix on
| the next minor update rather than doing so
| asynchronously".
| [deleted]
| johnklos wrote:
| Precisely because it has 89 employees instead of 19,000, it
| can be MUCH faster.
|
| Have you ever tried to get support from Red Hat? Honestly?
| The first couple of tiers are often people who are barely
| computer literate. I've talked with several people who -
| I'm not kidding - had no idea what the Power architecture
| is and had no clue that there are architectures aside from
| x86.
| Kaytaro wrote:
| Not sure who you were talking to but Red Hat support
| doesn't use tiers, cases go directly to SMEs on the
| feature and from there the only escalation point is the
| actual engineers working on the lines of code affected.
| linuxdude314 wrote:
| Have you tried getting support from RedHat as an actual
| enterprise customer rather than an SMB?
|
| Obviously if you pay for the lowest level of support,
| that's what you are going to get. Serious businesses pay
| for dedicated account resources. This typically includes
| a Technical Account Manager (TAM) and a dedicated support
| resource that works along side Professional Services to
| take care of your install.
|
| When done _properly_ you will have nearly instant support
| from an excellent engineer.
| axus wrote:
| Red Hat is supporting a lot more subscribers, I'd think? I
| have no experience with Red Hat phone support, their
| product has always been great and their online resources
| answered any question I had.
|
| My impression from access.redhat.com is that much of the
| written material comes from support given to actual
| customers.
| op00to wrote:
| Red Hat (any many other companies) follows "knowledge
| centered support". [1] Essentially the knowledge base is
| the "workspace" or scratch paper of the support case, and
| as information comes in the case, the information should
| be organized in the knowledge base solution such that by
| the end, you've got the bones of a solid solution other
| customers can follow.
|
| It's a whole Thing that People charge huge sums to
| implement, but the idea itself is pretty solid.
|
| [1] https://www.serviceinnovation.org/kcs/
| aaomidi wrote:
| The mythical man month.
|
| More people can very easily lead to nothing getting done.
| op00to wrote:
| This doesn't really apply to support. With support, there
| is generally 1 engineer assigned to one customer for the
| life of the case. If a patch is needed, a software
| maintenance engineer may be added. You can't throw extra
| people at a support case and expect it to complete
| faster. You can, however, throw more people at a support
| TEAM and handle more cases.
| aaomidi wrote:
| So Rocky needs to assign a single engineer to NASA
| support then. How does 19,000 people help with that?
| linuxdude314 wrote:
| That's typically what RedHat does...
|
| If you're a big account you get your own Technical
| Account Manager (TAM) and a dedicated support engineer.
|
| This is like bread and butter for anyone with any
| experience in enterprise.
|
| How is HN so green in this regard?
| aaomidi wrote:
| No I'm saying if you're assigning *a person to a
| contract* Rocky can easily do that too.
| edgyquant wrote:
| Because surely they have other customers than these three
| workstations.
| leocrat wrote:
| It's not 3 workstations, it's 3x per person support.
| edgyquant wrote:
| Point still stands, when you have an 80 man team you
| can't have many customers who require your undivided
| attention.
| leocrat wrote:
| Did you watch the movie 300? Then you know
| ozr wrote:
| Price's law, for one. Experience with the general
| effectiveness of large companies, especially their support
| teams, for another.
| op00to wrote:
| If Price's law is at play, then there will still be more
| competent people doing the work in Red Hat's support team
| than Rocky's.
|
| How likely is it that there's someone on Rocky's staff of
| 80 who...
|
| a. is an expert in the code, and has worked on it on
| customers behalf before
|
| b. is able to effectively support a customer in addition
| to fixing a bug
|
| c. is awake at the time you need them
|
| d. isn't totally underwater with other issues
|
| How likely is it that there's someone in Red Hat's staff
| of 20,000 (or whatever) who fit the same criteria?
|
| You'll need experts in kernel, services, storage,
| networking, filesystems, virtualization / containers.
| Enterprise support shouldn't be done by generalists, it
| should be done by someone who has depth in the particular
| problem space.
| freedomben wrote:
| > _No, I 'm not talking about the people who talk on the
| phone when you break something. If you find a bug in a
| package, will Rocky be able to quickly and effectively
| upstream the fix, or will Rocky end up maintaining you on a
| custom patchlevel forever?_
|
| I'm intrigued. What makes you think Rocky will be faster than
| Red Hat? How does Rocky handle that situation? Do they have
| COPR repos or similar that you add to your system? What do
| they do if the patch gets rejected upstream?
| omniglottal wrote:
| Is your car dealership faster at changing the tires and oil
| on your car than a tire or oil-changing company would be?
|
| RHEL is effectively a bunch of FOSS bundled and rebranded.
| Rocky is effectively RHEL with another paint job. If a
| patch gets rejected upstream, Red Hat is known to reject
| the author/maintainer's rationale for this rejection and,
| over years, may then extend, embrace, and extinguish that
| community, replacing and repainting it as their product.
|
| Sometimes this is a community-serving change (i.e., docker
| -> (OCI+) -> podman), and sometimes it's a community-
| replacing change (i.e., Kubernetes -> Origin/OKD ->
| Openshift). In all cases, it's a redeclaration of who
| actually is the most knowledgeable expert. Management re-
| assigning experts is not necessarily as aligned as the
| merit of an original engineering team/community providing
| their solution.
|
| I'd rather Rocky's solution than the walled-garden in a
| cathedral courtyard approach. If something cannot be pushed
| upstream (i.e., user-hostile defaults, vendor lock-in, or
| arbitrary rebranding), this blockage is sometimes a feature
| we all want for FOSS, even while it may not give privileges
| to those who can throw more money at the problem under the
| condition it will then be able to extract more profit.
| linuxdude314 wrote:
| The purpose of Rocky is to be bug-for-bug compatible with
| RHEL. What makes you think they would ever attempt to
| upstream something?
| nhanlon wrote:
| We do all the time.
| op00to wrote:
| I suspect Rocky support is three people in Europe somewhere
| with maybe one or two others in North America. I also suspect
| Rocky has no Support Engineering group, so their own product
| engineering resources must be redirected every time a
| customer needs a patch.
|
| If Rocky does have a Support Engineering group, they aren't
| regular committers to the kernel, and so most common bugs
| found will take much longer to be upstreamed. This increases
| the load on Engineering because they'll have to carry that
| fix until it makes it into upstream and the customer
| upgrades.
|
| I have seen no indication that Rocky has a robust QA
| infrastructure for customer patches.
|
| Note the Rocky support model allows each "person" to only
| have two cases open at a time. This indicates they're forced
| to limit capacity.
|
| Let's say I'm wrong about all of this. Let's say Rocky
| support is better than Red Hat. I've seen what happens when
| support scales from a small company to a large one. If ever
| you got good support, those days are over if Rocky sees
| success and the support group scales.
| omniglottal wrote:
| It takes a lot to design and build a car and manage its
| dealerships. It takes orders of magnitude less effort for a
| mechanic to maintain it, and even less to simply paint and
| clean it. Red Hat builds this car - Rocky repaints it and
| acts far more like Jiffy Lube than like a dealership. Have
| you ever seen how long it takes, and how much more it
| costs, to have your oil changed by the dealership? Those
| focusing on the specialty are able to deliver on it more
| efficiently and with less expense to all involved.
| op00to wrote:
| I've seen what happens when you take your car to Jiffy
| Lube and the minimum wage oil tech they hire doesn't
| tighten the oil drain plug all the way.
| sixothree wrote:
| Or strips it.
| totallywrong wrote:
| The difference is with RH you can often get escalated up to
| the engineer writing the thing. I know I did when working for
| companies paying for that support. There's usually a few
| layers of rather useless L1 and L2 though.
| omniglottal wrote:
| Those lower layers are a significant anti-feature for a
| customer needing quick, effective support, and it is only
| occasionally/rarely the case that a key author or
| maintainer is actually employed by Red Hat.
|
| Most things delivered by Red Hat were not written by Red
| Hat and where they are, that delivery tends to be a
| rewritten, renamed project which went from community-driven
| (FOSS made to serve the user) into a corporate-driven model
| (gate-kept software which serves primarily as a profitable
| subscription-dependant product).
|
| The trade-off is effectively for legal liability
| transference more than for genuine supportability. I would
| rather get eventual real support from the bazaar of people
| who wrote a thing (knowing, intimately and technically why)
| than liability-waving support (assuming successful
| escalation) from those who rewrote it in the cathedral with
| divergence intentionally created for corporate control and
| profit.
| johnklos wrote:
| To be honest, you sound more like a Red Hat fanboi than someone
| who is making persuasive arguments.
|
| For one, you're implying that Red Hat can fix bugs and can
| upstream them more quickly than Rocky. Have you seen the amount
| of time it takes Red Hat to move fixes in to sources? That
| alone is silly to even mention. I don't know how long Rocky
| would take, but in the entire world, hardly any companies take
| as long as Red Hat.
|
| Two, do you think Red Hat "truly fulfill(s) 24/7 support"?
| Sure, you can get someone on the phone, but how many hours will
| it take before you can get someone who knows anything? All that
| navigation and escalation is time consuming. I'd rather wait
| for an expert who knows the area of my problem intimately to be
| woken up to contact me after an hour than be appeased by being
| on the phone for three hours explaining a problem to person
| after person who won't directly escalate and wants to hear the
| problem explained.
|
| "maybe the thing you're doing isn't important enough to warrant
| paying for support anyway." Huh? That's just ridiculous.
| depereo wrote:
| > Have you seen the amount of time it takes Red Hat to move
| fixes in to sources?
|
| They will _absolutely_ cut you a patch to use on your
| systems. Upstreaming does take time, yes, but that doesn 't
| mean the person experiencing the problem has to wait to get
| their issue resolved.
| linuxdude314 wrote:
| To be honest, you sound more like recent college graduate
| with minimal (no) experience working in enterprise.
|
| You probably don't realize this given your lack of
| experience, but when you are running FOSS powered/adjacent
| enterprise equipment (think storage systems and compute
| fabrics) the bugs you encounter are often not things that
| simply show up on the first page of google.
|
| There often isn't anyone to "wait" for (other than the
| resources you pay for), which is why if you value uptime and
| availability, you PAY for a support contract.
|
| I was a staff level systems engineer at a major movie studio
| in California (owned a 24+PB tape library and a few petabytes
| of fast storage), and I can confidently say all of our
| dedicated support assets were valuable members of our broader
| team (first name basis, ask questions/raise issues with a
| text message, etc...).
|
| In the rare occasion an engineer wasn't cutting it we would
| have our TAM get us a new one. Typically you are literally
| paying these people's salary as part of your contract so
| these are decisions that you as a customer actually have a
| lot of input into.
|
| If you'd rather wait for someone to answer you on
| StackOverflow that's a decision you can make, but if you pull
| that move in any serious enterprise you will terminated
| pretty quickly.
|
| The whole point of Rocky is to be bug-for-bug compatible with
| RHEL; your opinion on who can fix bugs faster is completely
| orthogonal to this discussion.
| johnklos wrote:
| I'm flattered that I sound like a recent college graduate
| :) I've been a Unix systems administrator for more than a
| quarter of a century.
|
| Wild generalization: Red Hat is mostly bullshit. Their
| support is good at handling the myriad quirks and bull
| they've intentionally added to their OS to differentiate
| their product, but they're not so good at things beyond
| that, in my experience. I'm generalizing, of course, but in
| too many instances Red Hat has been unique in having issues
| that other common OSes don't. In many environments I've set
| up proper servers with other OSes for comparison so I'd
| know when something is a Red Hat-ism.
|
| If you're somehow authoritative because you've worked for a
| major movie studio with petabytes of storage, then I
| suppose I'm authoritative, too. I have and still work for
| major movie studios and I handle petabytes of storage, too
| :) Perhaps we know each other.
|
| Red Hat couldn't get their OS to see all the zones of a
| StorNext, while at the very same moment identical hardware
| next to that Red Hat system running SuSE worked fine.
| Drives were swapped between the systems, and the problem
| followed Red Hat. It was a clean install. Red Hat support
| told us they couldn't do anything and said it was a
| StorNext problem. We contacted StorNext, and they were even
| willing to work with Red Hat. Red Hat required us to have a
| three way phone call to include the StorNext people and
| wouldn't answer their emails. I had to create email
| accounts for the StorNext people. It was extremely
| unprofessional and nothing moved on this until the company
| threatened to cancel Red Hat support entirely.
|
| Unfortunately, my other experiences were more reminiscent
| of dealing with AT&T than dealing with an organization that
| wants to make things work.
| adastra22 wrote:
| > I say it's weird because NASA almost certainly has its own
| internal Linux support paid through overhead in one form or
| another
|
| Why do you presume this?
|
| (Former NASA contractor here: they don't.)
| jvanderbot wrote:
| Former NASA/JPL employee. I can say with gusto that Linux was
| never really supported by overhead. Projects pay directly for
| cloud services, servers, computer time, equipment for field
| testing, etc. Those are where rocky Linux would be used. At
| least in my experience, the usual burden funds are used for
| vanilla windows desktops or laptops for employees, which works
| fine for 90% of the org. The rest write proposals to get non
| standard equipment in one form or another. This drastically
| reduces overhead costs and allows results driven grants to buy
| only necessary equipment. Same as any other gov funded
| research-related capital purchase. At least in theory.
| prpl wrote:
| Again, like large corporations, this doesn't mean much. NASA is
| big and diverse, and each facility is unique and mostly
| independent, with lots of unrelated projects within a facility.
| spicyusername wrote:
| Out of curiosity what do others see as viable Red Hat Linux
| alternatives?
|
| If I was choosing a server OS today, I personally would probably
| pick Debian.
| tapoxi wrote:
| Professionally, I'm running everything on Debian because it's
| always been around, always rock solid, isn't going to make any
| stupid decisions for profit, and containerizes well. If I'm at
| a place that's willing to pay for RHEL I will go RHEL, because
| the support doesn't hurt and they do a great job contributing
| to upstream projects.
|
| For personal machines, I don't mind Fedora Server (or CentOS
| Stream) because I can handle the more frequent upgrade cycle.
| adql wrote:
| Debian is relatively problem-free compared to RHEL; and update-
| in-place also works.
|
| Sooo much less fuckery, packages are _just there_ and don 't
| require installing/buying some random addon just to have
| DRBD+pacemaker cluster (that RHEL for some reason put into
| separate repo and subscription).
| Mikhail_K wrote:
| Devuan and Void Linux are systemd-free alternatives. The first
| one is a Debian fork, so should be very familiar to anyone with
| Debian/Ubuntu experience.
| mirekrusin wrote:
| popOS - it really surprised me after long time Ubuntu, before
| Debian user.
| leonheld wrote:
| popOS as a server operating system? That doesn't make much
| sense.
| mirekrusin wrote:
| My bad, somehow I missed server part.
| frantathefranta wrote:
| AlmaLinux is being heavily floated as an option in my place of
| work. We have RHEL7 and 8 licenses but due to pricing might
| switch.
| derekp7 wrote:
| 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.
| adql wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| Do the managers think the person getting the ticket at RH
| will not be dicking around on the internet?
| ta1243 wrote:
| Managers think the blame parcel has been moved to a
| supplier
| 6c696e7578 wrote:
| Yeah, this does seem to be the prevailing way in
| management layers.
| hestefisk wrote:
| It's called "risk management" in corporate speak.
| ta1243 wrote:
| 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.
| zzzeek wrote:
| 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.
| 6c696e7578 wrote:
| 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 wrote:
| > 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.
| linuxdude314 wrote:
| I'm kind of shocked the average HN user seems to be so
| incredibly ignorant on this matter.
|
| Is this an ego thing?
| op00to wrote:
| 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.
| zetta0 wrote:
| My RH support experience was bad enough for me to switch
| to Rocky Linux. I suppose people's experiences in life
| can be different?
| pookha wrote:
| 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.
| throwaway173738 wrote:
| 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.
| mikae1 wrote:
| For business? https://www.suse.com/solutions/business-critical-
| linux/
|
| For home server use: Tumbleweed, Leap or MicroOS depending on
| your personality. :)
| akvadrako wrote:
| Go with an immutable distribution, something like CoreOS. Then
| run everything in containers.
|
| Major version upgrades have less risk of breaking, while
| rollbacks become an option. And the attack surface is lower.
| oneshtein wrote:
| Attack surface will be sum of CoreOS surface and surface of
| containers. It can be lower only if surface of containers
| will be negative. :-/
| bombcar wrote:
| I went with Ubuntu because the long-term support Debian at the
| time would have required me to hand-compile or add package
| sources for the version of whatever it was (php?) I needed.
|
| Ubuntu LTS is long enough for me, and seems to work without
| complaints.
|
| At home I run Gentoo because I like to fomit and funroll.
| PlutoIsAPlanet wrote:
| There isn't really any, only Debian/Ubuntu gets close.
|
| RHEL and its clones are supported with updates for 10 years,
| often ship with "more modern" server software than Debian does
| (e.g. firewalld, podman, systemd etc) and DNF, whilst slower,
| still blows apt in terms of feature set (e.g. transcriptional,
| roll-backs, history, offline upgrades)
|
| There's also SUSE.
| count wrote:
| RHEL saying '8' or '9' is supported for 10 years is
| misleading af. Each 'minor version' (which are, in fact,
| sometimes large changes!) is supported for it's own specific
| time period. Odd numbered (8.5, 8.7) for example are only
| supported for 6 months. https://access.redhat.com/sites/defau
| lt/files/images/337_rhe...
|
| It's terrifying actually.
| axus wrote:
| Yep, the "10 year support" for 8.8 means that you'll
| upgrade to 8.10 (to-be-released) and then that will be
| supported for the rest of the duration.
| sofixa wrote:
| > often ship with "more modern" server software than Debian
| does
|
| That's not really true. They often ship with Red Hat specific
| software (like Podman is) replacing widely used software
| (e.g. Docker, to which Podman _still_ isn 't feature complete
| even though it has been shoved in everyone's throats for a
| couple of years now), but "more modern" will vary wildly
| based on the release date.
| mikae1 wrote:
| _> There isn 't really any, only Debian/Ubuntu gets close._
|
| _> There 's also SUSE._
|
| So, why doesn't SUSE get close?
| count wrote:
| The Marketing Gap. Also the unfortunate detour with Novell
| and MicroFocus for a few years...
| pestaa wrote:
| Give them a few more. They acquired Rancher, k3s, have
| MicroOS, and ALP in the pipeline. I'm rooting for them.
| traceroute66 wrote:
| > RHEL and its clones
|
| My understanding is that the problem with RHEL clones is just
| that, that they are clones.
|
| From what I've read, the problem is that RHEL will often make
| changes to suit their various enterprise customers, for
| example I seem to recall reading somewhere that OpenSSL was
| one of many things "touched" in that way.
|
| I hear many good things about DNF vs apt, but I'm too worried
| by the skeletons in the clone cupboard.
| totallywrong wrote:
| Fedora, especially one of the recent immutable versions.
| mrmattyboy wrote:
| Looking at the "statement of work", unless I'm misunderstanding -
| it's 3 user (workstation?) licenses?
|
| To me, it's more like 3 engineers at NASA are interested in it
| and got their boss to get them 3 licenses? As opposed to "NASA
| moves all RHEL licenses to Rocky after Redhat destroys CentOS
| community"?
|
| Edit: I know nothing of how govournment agencies (and certainly
| not US ones) work.. I assume all purchases go through some
| process where they're all made public?
| jaimehrubiks wrote:
| That seems very likely, either for personal preference or for
| testing the distribution
| tssva wrote:
| They didn't purchase licenses. They purchased support.
| imachine1980_ wrote:
| Yes for 3 workstation, they are probably testing the support
| tssva wrote:
| Or possibly a project installed Rocky Linux because it was
| easier, faster and cheaper than procuring RHEL licenses. It
| was found in an audit and now they had to procure and
| switch to RHEL or procure support for Rocky Linux. A
| complete wild ass guess but I have seen it happen at other
| agencies with open source software.
|
| Since I retired on Friday, my experience with government IT
| and procurement is slightly out of date but based upon my
| knowledge of it until that point I would consider it a
| better wild ass guess than NASA procured 3 Rocky Linux
| workstation support contracts to test it before making some
| agency wide switch.
| tyingq wrote:
| The pdf mentions renewal, so maybe not even that. Just 3
| people renewing a support contract.
|
| _" The item described in the table below is for the FY23
| CIQ Rocky Enterprise Linux Renewal."_
| jvanderbot wrote:
| Here's how it works (POV NASA/JPL PM of 8 years):
|
| * The institution has a slush / IT fund that provides basic
| windows laptops or MACs, right off the shelf with lots of
| security add-ons
|
| * For any non standard equipment or software, the engineers on
| a project must seek money from the project's budget and justify
| that cost to the project manager. (not their long-term boss).
|
| * Project managers have a fixed budget based on the proposal
| they wrote to the funding agency, usually US GOV, with a fixed
| cost for these kinds of purchases, agreed upon at the time the
| proposal was funded
|
| * The limited project funds are used to purchase whatever is
| needed to satisfy the project's objectives. If the project's
| objectives are not satisfied, the funding agency can stop, or
| even pull back funding from the project manager
|
| * The approvals for equipment purchases are, at least in
| theory, given based on merit, which is very often weighed using
| prior successful proposals. New types of purchases are
| scrutinized more. If it's traditional to buy CENTOS, then
| buying ROCKY would be more difficult.
|
| * That precedent is key. Once it becomes clear that ROCKY is
| being used by successful teams, then the approval process is
| _much_ easier.
|
| That's why this is a big-ish deal (not huge, but nice to see).
| Now, people writing proposals and working on projects can point
| to this as _precedent_. The best outcome is when funding
| agencies see "ROCKY is better and more cost effective for the
| teams we've been funding", then you might get a funder to
| request that teams use ROCKY as part of the proposal
| requirements. This is almost nonexistent in federal contracts,
| but is quite common when dealing with military or commercial
| contracts.
|
| That, and ROCKY can probably now have a NASA logo on their
| website under "customers", which adds a bunch of credibility to
| the project, honestly, whether it's necessarily deserved or not
| based on 3 desktops.
| mrmattyboy wrote:
| Ah okay, thank for the that :)
|
| I sort-of assumed that for big purchases it would be a big
| procedure, as you've stated.
|
| I had it in my mind, there'd be like a lower threshold (i.e.
| licenses for one or two things), which would go under the
| radar and just be purchased when someone requested it (or end
| of year "budget needs to be spend" - you know, that sort of
| old school "budget per department - spend it or you lose it"
| sort of thing.) :D
|
| This also went with the idea that the "3 x CIQ Rocky
| Enterprise Linux Per Person Advanced - Annual Subscription
| Service Period" would be a small purchase - though of course,
| I don't _really_ have any idea what this means - could be a
| massive 24x7 support with 3 Rocky Linux support staff on-call
| - who knows :)
|
| > That, and ROCKY can probably now have a NASA logo on their
| website under "customers", which adds a bunch of credibility
| to the project, honestly, whether it's necessarily deserved
| or not based on 3 desktops.
|
| This on the other hand is verry interesting!! Thanks for
| pointing this out :)
|
| Edit: sorry, I misread your comment :( Thought you said their
| logo _was_ on the Rocky site :P
| depereo wrote:
| Is this potentially the reason RH won't be providing public
| sources for RHEL any more? RH's bread and butter is USGOV.
| NASA using a direct competitor that can only exist by
| rebuilding RHEL sources, and this use becoming easier isn't
| great for them.
| peplee wrote:
| I've been hearing lately that "buy what you can, build what
| you must" is the approach to procurement for orgs like NASA
| and SDA. If it is the case, one would hope this means more
| folks like ROCKY can get over that initial hump and grow
| within those orgs. Would be interesting to hear if that
| mirrored your experience or not.
|
| I'm not so convinced based on my experience. Seems like that
| could be the ideal, but in practice for such a large
| institution it seems difficult to implement. Sharing the word
| that this team over here is using XYZ and seeing good results
| to that team over there is challenging.
| prpl wrote:
| That sounds a bit more rigid than what I knew to be the case.
| I think every one I worked with from Goddard had a mac -
| unless - they specifically asked for something else. That
| includes both the civil servants and contractors.
|
| Purchases were hard because acquisition was hard but I don't
| think the bar requires previous use. Usually getting a vendor
| to accept a PO was the hard part IIRC
| jvanderbot wrote:
| Yeah, as I mentioned below, "Standard" equipment did
| include macs, and I had a mac myself. I'll edit for
| clarity.
___________________________________________________________________
(page generated 2023-06-21 23:02 UTC)