[HN Gopher] Rocky Linux: A CentOS replacement by the CentOS founder
___________________________________________________________________
Rocky Linux: A CentOS replacement by the CentOS founder
Author : andyjpb
Score : 452 points
Date : 2020-12-16 17:50 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mongol wrote:
| I have not used CentOS but I have considered it. If OpenSUSE did
| not exist, that is probably what I would use. Or perhaps now,
| Rocky Linux
| anonymousiam wrote:
| I have not seen much mention of alternatives to RHEL besides
| Oracle Linux. Another excellent alternative exists here:
| https://scientificlinux.org/
| kbenson wrote:
| Scientific Linux/Fermilab did not release a version 8, and
| instead opted to install CentOS 8 on their clusters instead of
| roll their own version.[1]
|
| 1: https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-
| LINUX...
| joana035 wrote:
| I hope they make a comeback or join Rocky efforts
| paulryanrogers wrote:
| There is also Springdale Linux
| mmrezaie wrote:
| I am really interested to know why should anyone go with this
| when Debian or Ubuntu LTS exist. The two later have not changed
| their policies in the last decade, and they have a clear path for
| upgrading. CentOS was always a clear choice for device drivers
| support, but I never understood the stability claims.
| theevilsharpie wrote:
| > I am really interested to know why should anyone go with this
| when Debian or Ubuntu LTS exist.
|
| There is a large world of proprietary enterprise software that
| is tested, developed, and supported solely on RHEL. CentOS (and
| theoretically, Rocky Linux) can run these applications because
| they are essentially a reskin of RHEL. Debian and Ubuntu LTS
| cannot (or at least not in a supported state) because they are
| not RHEL.
| itsjustjoe wrote:
| rpm. If your systems are built around rpm already that alone is
| a good enough reason.
| paul_f wrote:
| If you're using Cpanel, you have no choice but to use Redhat,
| CentOS or Fedora.
| syshum wrote:
| That is changing, they are going to Support CloudLinux, and
| Ubuntu now
|
| https://blog.cpanel.com/centos-8-end-of-life-announcement/
| mmrezaie wrote:
| By understanding the stability I mean the other two are as
| stable as far as I have experienced them in the last decade.
| em500 wrote:
| To system administrators and people managing large fleets of
| servers "stability" usually means "doesn't change much"
| rather than "doesn't crash". In that sense, RHEL tended to be
| more stable than Debian / Ubuntu. Though that may change
| somewhat with Ubuntu's recent 10 year LTS plans.
| jpalomaki wrote:
| Not an expert, but I've understood CentOS was interesting for
| people who run RedHat for production, but want something free
| for non-prod hosts.
| dmix wrote:
| For me it's always been about stability and the long term
| support of a 'free' distribution. That has also historically
| been their bread and butter which got them wide-adoption.
|
| The branding stuff was a plus to the sys-admins and Linux die
| hards.
| StillBored wrote:
| RHEL and its derivatives are the only linux distribution which
| maintains binary compatibility over 10+ years while getting not
| only security updates but feature additions when possible.
|
| This is something I don't think the wider community
| understands, nor do they understand the incredible amount of
| work it takes to back-port major kernel/etc features while
| maintaining a stable kernel ABI as well as userspace ABI. Every
| single other distribution stops providing feature updates
| within a year or two. So LTS, really means "old with a few
| security updates" while RHEL means, will run efficiently on
| your hardware (including newer than the distro) with the same
| binary drivers and packages from 3rd party sources for the
| entire lifespan.
|
| AKA, its more a windows model than a traditional linux distro
| in that it allows hardware vendors to ship binary drivers, and
| software vendors to ship binary packages. That is a huge part
| of why its the most commonly supported distro for engineering
| tool chains, and a long list of other commercial hardware and
| software.
| pak9rabid wrote:
| Drivers for hardware that were only ever intended to work with
| RHEL (EMC's PowerPath drivers, for example).
| [deleted]
| throwaway201103 wrote:
| Agreed. I've used and advocated for RHEL/CentOS at work since
| version 5 because it was stable and predictible. That's gone
| now, and many of my users would prefer Ubuntu anwyay because
| it's what they use on their personal machines. So I'm making
| plans to move all our compute resources to Ubuntu LTS.
| effie wrote:
| I'm wary of doing that, because in near future, Microsoft is
| likely to take over Canonical. You don't put all eggs into
| one basket. Always plan for escape, always have a plan B.
| Preferably one not relying on crystal-balling whims of a for-
| profit corporation. Rocky Linux, Alpine Linux, Debian,
| Gentoo, BSD, etc.
| jessaustin wrote:
| Moving a server from Ubuntu to Debian doesn't seem a very
| arduous task? I've got a box in a rack that came from the
| factory with Ubuntu installed, but there are Debian
| addresses in /etc/apt/sources.list.d
|
| Besides isn't that pretty much the exemplar of FUD?
| dharmab wrote:
| Debian's package policies can be challenging for rapidly
| updating packages: https://lwn.net/Articles/835599/
| jcastro wrote:
| Both Debian and CentOS have the same problem here, you're not
| going to install kubernetes from a default repo on any
| traditional distro.
| mmrezaie wrote:
| For packages like Kubernetes or big data packages one should
| not use anyone else's builds. I have been finding problems in
| Cray's modules and eventually we are using our own builds we
| can reproducibly support using Spack.
| symlinkk wrote:
| I would say for any piece of software, if the vendor
| themselves provide a package for your distro, use that, not
| the distro version.
|
| In fact I'll go a step further and say Windows and macOS
| got this right, in that third party developers should do
| the work to "package" their apps.
|
| It would be insane for Microsoft to maintain packages for
| every piece of software that ships on Windows, but somehow
| that's the situation we're in with Linux.
|
| Hopefully Snap or Flatpak changes this!
| yjftsjthsd-h wrote:
| > It would be insane for Microsoft to maintain packages
| for every piece of software that ships on Windows, but
| somehow that's the situation we're in with Linux.
|
| And this is why installing ex. Filezilla on Linux is safe
| and easy, and doing the same on Windows is neither.
| tw04 wrote:
| Rocky is going to be exactly what CentOS was: a free version of
| RHEL. The reason you would use this vs. Debian or Ubuntu is
| because you've got systems that need to mirror your production,
| but you don't want/need enterprise support on them.
|
| When I worked for a hardware vendor we had customers who ran
| hundreds of CentOS boxes in dev/test alongside their production
| RHEL boxes. If there was an issue with a driver, we simply
| asked that they reproduce it on RHEL (which was easy to do). If
| they had been running debian or ubuntu LTS the answer would
| have been: I suggest you reach out the development mailing list
| and seek out support there.
|
| Whether you like it or not, most hardware vendors want/require
| you to have an enterprise support contract on your OS in order
| to help with driver issues.
| hitpointdrew wrote:
| I am simply not a fan of Debian/Ubuntu's utilities, with the
| big one being the package manager (I like yum/dnf way better),
| but also other things like ufw vs firewalld.
| tijuco2 wrote:
| same here
| viraptor wrote:
| Apart from the long support, RHEL based distros also give you
| built in selinux support. Apparmor exists, but it's not
| comparable in features and existing policies.
| throwaway092835 wrote:
| selinux is provided by Debian as well and it's hardly a
| popular (or very useful) feature compared to daemon and
| application sandboxing.
| viraptor wrote:
| The module itself is provided, yes. The policies are not
| really integrated into Debian systems. You can adjust them
| to work, but it's way more work than using ready ones on a
| RHEL-like system.
| tmoravec wrote:
| Debian offers around three years of support. Ubuntu LTS around
| five. Both pale in comparison with Red Hat and, by proxy,
| CentOS.
| unethical_ban wrote:
| Arguably, no one should be running a server that long in
| 2020.
|
| I would say a better reason is that while both are Linux
| distributions, they are distinct dialects and ecosystems. It
| isn't impossible to switch, but for institutions that have
| complex infrastructure built around the RHEL world, it is a
| lot of work to convert.
| NotHereNotThere wrote:
| OK I'll bite..
|
| How would I run our SAP ERP apps/databases without "running
| servers that long"?
| unethical_ban wrote:
| Of course there are use cases, but _ideally_, most
| workloads are staged, deployed, and backed up in such a
| way that it is a documented, reproducible procedure to
| tear down an instance of a server, rebuild, and redeploy
| services.
|
| And while it may be cumbersome or cause some downtime or
| headaches if that isn't the case, I find the very need of
| doing it once every 1-3 years forces your hand to get
| your shit together, rather than a once per decade affair
| of praying you migrated all your scripts manually and
| that everything will work, as your OS admins threaten
| your life because audit is threatening theirs.
| effie wrote:
| How many simultaneously running machines can you keep
| updating with this method? If you run non-trivial
| workloads for hundreds of customers, this becomes high
| maintenance system already with two machines. It takes
| ages to upgrade all applications, then validate
| everything works, then actually migrate with no downtime.
| petepete wrote:
| Run them on Kubernetes in GCP with a containerised DB2!
| joana035 wrote:
| > Arguably, no one should be running a server that long in
| 2020
|
| The main reason people choose Linux is due to its
| stability.
|
| It is totally ok to run servers in 2020.
|
| Also your statement seems the default cloud vendor lingo
| used to push people to adopt proprietary technology with
| high vendor lock-in.
| mdeeks wrote:
| I think they only meant "that long". In other words, not
| for 5+ years without an upgrade. Not that you shouldn't
| run them at all.
|
| Not everything can be highly ephemeral or a managed
| service, so running servers yourself is totally okay like
| you said.
| joana035 wrote:
| You are right, I misunderstood his message.
| that_guy_iain wrote:
| Honestly, 10 years is a long time for a server. I would
| be honestly surprised if a server lasted 10 years.
|
| But I agree I also get the tone of "servers should be
| cattle and not pets, just kill them and build a new one".
| Which can also be done on bare metal if you're using
| vms/containers. It seems like most people forget these
| cloud servers need to run on bare metal.
| bcrosby95 wrote:
| Really? We've colocated our servers for the past 18 or so
| years.
|
| We have about 40. The oldest is around 17 years old. Our
| newest server is 9 years old. Our average server age is
| probably around 13 years old.
|
| The most common failure that completely takes them out of
| commission is a popped capacitor on the motherboard.
| Never had it happen before the 10 year mark.
|
| Never had memory failure. Have had disk failures, but
| those are easy to replace. Had one power supply failure,
| but it was a faulty batch and happened within 2 years of
| the server's life.
| that_guy_iain wrote:
| The last time I worked with a ~8 year old server, it used
| to go through hard drives at a rate of 1 every 2 months.
| While we could replace them easily and it was RAID so
| there wasn't any data loss, I personally would've got fed
| up of replacing HDDs every couple of months.
|
| Also, most of my experience is with rented dedicated
| servers and they just give me a new one completely so I
| never really see if they're fully scrapped.
| chousuke wrote:
| It's not really about running _servers_ for 10 years. It 's
| about having a platform to build a product on that you can
| support for 10 years. RHEL software gets old over time, but
| it's still maintained and compatible with what you started
| on.
|
| Consider an appliance that will be shipped to a literal
| cave for some mining operation. Do you want to build that
| on something that you would have to keep refreshing every
| year, so that every appliance you ship ends up running on a
| different foundation?
| deckard1 wrote:
| The "don't touch it if it's not broken" philosophy is
| fundamentally at odds with an internet-connected machine.
|
| You either need to upgrade or unplug (from the internet).
|
| There are still places out there that are running
| WindowsNT or DOS even. Because they have applications
| which simply won't run anywhere else or need to talk to
| ancient hardware that runs over a parallel port or some
| weird crap like that. These machines will literally run
| forever, but you wouldn't connect it to the internet.
| Your hypothetical cave device would be the same.
|
| Upgrading your OS always carries risk. Whether it's a
| single yum command or copying your entire app to a new
| OS.
|
| Besides, if you're on CentOS 8 then wouldn't you also be
| looking at Docker or something? Isn't this a solved
| problem?
| effie wrote:
| "don't touch it if it's not broken" is not a philosophy,
| it is a slogan. Some people say it, because it is
| preferable to them to run old unpatched vulnerable
| systems rather than spend resources on upgrades. That's
| just a reality. Some care about up-to-date, some don't.
| Most people don't _really_ care about security, and some
| of those don 't care even about CYA security theatre. If
| they did care about security, they wouldn't run
| unverified software downloaded from the Internet.
|
| Why Docker has anything to do with this discussion?
| dmix wrote:
| I'm assuming this involve upgrading the application often
| as well?
| brandonmenc wrote:
| > Consider an appliance that will be shipped to a literal
| cave
|
| This.
|
| A decade ago I was technical co-founder of a company [0]
| that made interactive photo booths and I chose CentOS for
| the OS.
|
| There are some out in the wild still working and powered
| on 24/7 and not a peep from any of them.
|
| We only ever did a few manual updates early on - after
| determining that the spotty, expensive cellular wasn't
| worth wasting on non-security updates - so most of them
| are running whatever version was out ten years ago.
|
| Rock solid.
|
| [0] https://sooh.com
| effie wrote:
| I think it is mostly about running servers (standard
| services that don't change much) for 10 years (and more).
| You don't need 10 year LTS distribution for building a
| product. You take whatever version of OS distribution you
| like, secure local copy should the upstream disappear,
| and vendor it into your product and never deviate from
| it.
| moonbug wrote:
| >Arguably, no one should be running a server that long in
| 2020.
|
| That's mental.
| Karunamon wrote:
| My read on that is that you should be treating your
| servers as disposable and ephemeral as possible. Long
| uptimes mean configuration drift, general snowflakery,
| difficulties patching, patches getting delayed/not done,
| and so forth.
|
| Ideally you'd never upgrade your software in the usual
| way. You'd simply deploy the new version with automated
| tooling and tear down the older.
| cat199 wrote:
| > automated tooling
|
| the 'usual way' _is_ automated tooling
| NDizzle wrote:
| "Ideally" - that's the problem. I have half a dozen long
| tail side projects running right now on Centos 7, and a
| few still on Centos 6.
|
| Do you have any idea how much effort it is to change
| everything over to "treating your servers as
| disposable"?! It's going to eat up a third (to half) of
| my "fun time" budget for the foreseeable future!
| effie wrote:
| Exactly, young devs here are completely out of touch with
| operations. Of course ideally something like standard 1TB
| HDD+32GB RAM system would be upgraded to newer OS and
| apps version by a central tool in 2hours, but we don't
| such FM technology yet.
| hibbelig wrote:
| I don't get this. If there are many servers, sure. But if
| it's something that runs on a single box without problem,
| why on earth should I tear it down?
|
| Also, "running a server for ten years" does not need to
| mean that it has ten years of uptime. I think that wasn't
| meant.
| moonbug wrote:
| Ten years of uptime seems neither an unreasonable nor
| unattainable requirement. There's more to computers than
| mayfly web startups.
| uep wrote:
| Do you know something I don't? A few years back, Debian
| changed their LTS policy to 5 years in response to Ubuntu.
|
| > Debian Long Term Support (LTS) is a project to extend the
| lifetime of all Debian stable releases to (at least) 5 years.
| Debian LTS is not handled by the Debian security team, but by
| a separate group of volunteers and companies interested in
| making it a success.
|
| > Thus the Debian LTS team takes over security maintenance of
| the various releases once the Debian Security team stops its
| work.
|
| https://wiki.debian.org/LTS
| goodpoint wrote:
| This is false. Debian provides LTS with a 5-years timespan.
| [1]
|
| And there is even commercial support for Extended LTS now [2]
|
| Also, it's worth noticing that Debian provides security
| backports for a significantly larger set of packages and CPU
| architectures than other distributions.
|
| [1] https://wiki.debian.org/DebianReleases
|
| [2] https://wiki.debian.org/LTS/Extended
| antoncohen wrote:
| Do you trust Debian LTS? As much as RHEL? The documentation
| about Debian LTS always made me think it is not a fully
| fledged thing. I've always felt like Debian releases
| reached EOL on their EOL date, not their LTS EOL date.
|
| > Debian LTS is not handled by the Debian security team,
| but by a separate group of volunteers and companies
| interested in making it a success.
|
| https://wiki.debian.org/LTS
| tmoravec wrote:
| Good catch, I stand corrected. But the point still holds -
| five (or even seven) years is still not match for Red Hat.
| geofft wrote:
| Debian eLTS offers 7 years:
| https://wiki.debian.org/LTS/Extended
|
| That said, if you're really in the position of depending on a
| _free_ project for _over five years_ of security support, you
| probably will be totally fine with just ignoring the fact it
| 's out of support. Just keep running Debian 6 for a decade,
| whatever. The code still runs. Pretend you've patched. Sure,
| there are probably some vulnerabilities, but you haven't
| actually looked to see if the project you're actually using
| right now has patched all the known vulnerabilities, have
| you?
|
| (Spoiler, it hasn't: https://arxiv.org/abs/0904.4058)
| mmrezaie wrote:
| Honestly that support is meaningless for some areas I know.
| In our Data Center we have hit problems with old packages and
| at the end you will end up with a lot of your own packages.
| In the end I find Debian to be a good base, and you build the
| rest by yourself. Even though I use Fedora for Desktop, I
| always have a feeling Debian is the server choice which I can
| extend further.
| joana035 wrote:
| Right, but the price one pays are outdated packages.
|
| CentOS 8 was released few days ago with kernel 4.18, which
| not even LTS is, and is older than the current Debian stable
| kernel(!).
|
| If you need to install anything besides the base distro you
| need elrepo, epel, etc which I'm not sure can be counted as
| part of the support.
| CoolGuySteve wrote:
| The patch delta for security fixes must get larger over
| time as these packages age further and further away from
| top of tree.
|
| I always wonder how many major vulnerabilities are
| introduced into these super old distros due to backporting
| bugs.
| jtl999 wrote:
| Documented cases don't seem to be common, but what comes
| to mind is the Debian "weak keys" scandal (2008), and the
| VLC "libeml" vulnerability (2019)[1]
|
| [1]: https://old.reddit.com/r/netsec/comments/ch86o6/vlc_
| security...
| joana035 wrote:
| OpenSSL upstream was almost abandoned during those days.
|
| Software are always gonna have bugs, it's written by
| humans after all. The important thing is to acknowledge
| and work towards an ideal outcome.
| bonzini wrote:
| It's the opposite. Plenty of subsystems in the RHEL 8.3
| kernel are basically on par with upstream 5.5 or so, as
| almost all the patches are backported. The source code is
| really the same to a large extent, and therefore security
| fixes apply straightforwardly.
| CoolGuySteve wrote:
| That's great but what about all the other packages?
| citiguy wrote:
| Agreed, the packages in Centos / RHEL are all super old.
| The RHEL license structure changes all the time and
| depending on which one you get it may or may not include
| the extended repos.
| syshum wrote:
| if you need epel, or quicker life cycles then CentOS Stream
| should be just fine for you as well
|
| People that run CentOS in prod are normally running ERP
| systems, Databases, LoB Apps, etc, and the only thing we
| need is the base distro and the the vendor binaries for
| what ever is service/app that needs to be installed, and
| probably an old ass version is JDK...
|
| We need every bit of that 10 year life cycle, and we glad
| that we will probably only have to rebuild these systems 2
| or 3 times in our career before we pass the torch to the
| next unlucky SOB that has to support an application that
| was written before we were born...
|
| that is CentOS Administration ;)
| dralley wrote:
| RHEL kernel versions are basically incomparable with
| vanilla kernel versions. They have hardware support and
| occasionally entire new features that have been backported
| from newer kernels in addition to the standard security &
| stability patches.
|
| This means that RHEL 7 using a "kernel version" from 2014
| will still work fine with modern hardware for which drivers
| didn't even exist in 2014.
| the8472 wrote:
| That is not a good thing. RH frankenkernels can contain
| subtle breakage. E.g. the Go and Rust standard libraries
| needed to add workarounds because certain RH versions
| implemented copy_file_range in a manner that returns
| error codes inconsistent with the documented API because
| patches were only backported for some filesystems but not
| for others. These issues never occurred on mainline.
|
| And for the same reasons that the affected users chose a
| "stable" and "supported" distro they were also unable to
| upgrade to one where the issue was fixed.
| [deleted]
| dralley wrote:
| True, but it is a matter of weighing risks. I can't find
| it now, but I remember a few years ago there was a news
| story about how an update to Ubuntu had caused hospitals
| to start rendering MRI scan results differently due to
| differences in the OpenGL libraries. For those sorts of
| use cases, stable is the only option.
| smarx007 wrote:
| I think this is a perfect use case for CentOS/RHEL as
| opposed to Ubuntu when the machine has only one job and
| nothing shall stand in its way, ie when you expect
| everything to be bug-for-bug compatible. But I fail to
| understand why a vendor of an MRI machine charging tens
| of thousands for installation/support cannot provide a
| supported RHEL OS which costs $180-350/yr in the cheapest
| config [1].
|
| [1]: https://www.redhat.com/en/store/linux-platforms
| houseofzeus wrote:
| The kind of people that are up in arms that CentOS 8 isn't
| going to be supported through to 2029 are using it
| _because_ it has outdated packages.
| naniwaduni wrote:
| That's not a price, that's a feature.
|
| If your use case _doesn 't_ consider avoiding noncritical
| behaviour changes for a decade to be a feature, you have
| other options.
| shawnz wrote:
| You may need to develop or test software for RHEL and
| CentOS/Rocky are bug-for-bug compatible.
| ernst_klim wrote:
| > when Debian or Ubuntu LTS exist
|
| I'm not familiar with Debian, do they have same infrastructure
| and documentation quality as RHEL? For example do they have
| anything like Koji [1] for easy automated package building?
|
| [1] https://koji.fedoraproject.org/koji/
| Shorel wrote:
| Switching distributions is an uphill fight when the company has
| used a version of RedHat for 20 years.
|
| Most developers use Ubuntu in their laptops. Virtualized on
| Windows, but Ubuntu nonetheless.
| area51org wrote:
| Debian/Ubuntu are great. However, there are people and
| companies that prefer the Red Hat way. That's also great.
| loop0 wrote:
| Because CentOS on enterprise hardware is way more stable than
| Debian. I've worked for 6 years as a sysadmin for 300+ servers
| and we migrated everything from Debian to CentOS and our
| hardware related issues just went away. Overall we had much
| less trouble in our systems.
| pak9rabid wrote:
| That's probably because lots of enterprise hardware is only
| ever tested and certified to work with RHEL, and in many
| cases only provided drivers in an RPM format that's intended
| to be installed in a RHEL-like environment.
| nycticorax wrote:
| Which is a good reason someone might choose a RHELish
| distro over Debian, no?
| citiguy wrote:
| Lately it seems to me Debian and Ubuntu have made some strange
| package decisions. They have morphed into a desktop oriented
| build with snap packages and auto-updates enabled by default
| (among other strange decisions). There's a ton of stuff we
| always end up disabling in the new release because it's super
| buggy and doesn't work well (I work at a small MSP). I'm not
| sure who replaced Ian Jackson, but Debian seems rudderless.
|
| Centos was the rational other free choice, not that Red Hat
| hasn't made other equally strange decisions.
|
| Sometimes I think we'd be better off rolling our own, like
| Amazon does.
| vbezhenar wrote:
| I'm using Debian and I don't use snap packages. I guess it's
| optional? I just installed Minimal and installed few packages
| I needed.
| sjellis wrote:
| Snap is an Ubuntu thing. It's basically a client for the
| Canonical app store.
| bserge wrote:
| Great, _another_ Linux distro... I am trying to use _something_ ,
| but I just can't.
|
| Spending my time fixing problems instead of doing actual work is
| fun, for a while.
|
| Every damn time I start this one laptop with Linux, trying to get
| away from Windows 10, there's something to fix.
|
| Oh, the undervolt is not being applied, time to build the whole
| thing again.
|
| Oh, restart causes it to wank the hard drive indefinitely for
| some reason.
|
| Oh, shutdown is _still_ not working, glad I got a power button.
|
| Nouveau glitches.
|
| Bluetooth has disconnected and just refuses to work again.
|
| Audio recording is not working again.
|
| Video encoding is not working again.
|
| Video _playback_ is not working again...
|
| And it runs so well in a virtual machine.
|
| Why can't people just band together and create one good Linux
| distro for the desktop. Rhetorical question, I guess.
| joana035 wrote:
| Because of hardware manufacturers, closed/proprietary
| firmwares, Microsoft standards...
| xrisk wrote:
| This... is not the place to rant about Linux? Desktop
| compatibility is not the goal of CentOS style distros.
| reggegg wrote:
| Fortunately this is a server distro, and there definitely
| aren't enough of those around (stable trustworthy ones).
|
| While your experiences with the desktop are unfortunate, on
| most common laptops (cheap and expensive ones) most Linux
| distros run well, even if some very specific devices have
| issues with the kernel drivers
| orev wrote:
| This distro is meant for servers, or maybe long term stable
| desktops you'd want in a classroom or something like that.
| People running servers don't need any of the stuff you
| mentioned.
| 2OEH8eoCRo0 wrote:
| CentOS was free RHEL. RHEL is not intrinsically a "server"
| OS. I developed on a RHEL workstation at my previous job.
|
| I'm not sure where the idea that CentOS is for servers came
| from.
| orev wrote:
| I didn't say you can't use it on a desktop, just that it's
| not really what it's meant for. The issues outlined above,
| like sleep, Bluetooth, etc. aren't the main things focused
| on.
| 2OEH8eoCRo0 wrote:
| Difficult to say. I think there is a bad mix of talent,
| freedom, and pride.
|
| You don't like my design choices? I'll leave the project and
| make my own. You end up with lots of talented people
| reinventing the same thing forever.
| spijdar wrote:
| Rocky Linux is, I would say, emphatically not a Linux distro
| for the desktop. This is unrelated to your rhetorical question,
| but I think your exasperation at "yet another OS" is a bit
| undeserved here.
|
| This fills a specific need for "enterprise" customers,
| specifically, being very slow and very stable. It's not
| supposed to be a consumer OS for doing normal desktop
| activities on, although there's nothing stopping you from using
| it as such.
|
| This isn't yet another slightly tweaked fork of Ubuntu or Arch
| Linux or some such, where maybe that attitude is more deserved.
| sp332 wrote:
| The solution is not to have _one_ distro for laptop linux, but
| to use the distro provided by the manufacturer for each.
| bonzini wrote:
| Right, the one that is full of crap proprietary drivers and
| therefore cannot be upgraded freely to new versions of the
| kernel.
| sp332 wrote:
| Yes, that's what they asked for.
| jolmg wrote:
| > Why can't people just band together and create one good Linux
| distro for the desktop.
|
| Different users, different needs. Ubuntu and Archlinux
| definitely appeal to different people, for example.
|
| One person might also use different distros depending on the
| intended use of a particular machine.
| symlinkk wrote:
| So tired of reading about people using hardware that isn't
| supported by Linux and then acting surprised when it doesn't
| work.
|
| You never hear anyone install macOS on a Dell and wonder why it
| isn't working.
|
| So why are you doing this for Linux?
|
| Lenovo, Dell, and other manufacturers ship products that are
| fully supported by Linux. Use those. If you don't, you're on
| your own.
| SquareWheel wrote:
| What does any of that have to do with an LTS server
| distribution?
| madars wrote:
| As many people can attest, popular Linux distributions (like
| Ubuntu or Fedora) work just fine on select hardware, like
| ThinkPad X series, or Dell XPS. But Linux on desktop is
| fundamentally a tinkerer's OS: great if you like tinkering and
| flexible when you need it but otherwise a waste of time for a
| lot of people :) I like tinkering and use Linux ~exclusively
| but don't recommend it to most of my friends.
| IshKebab wrote:
| I agree it is a problem. I think there are several reasons:
|
| 1. It's a mountain of work and loads of people involved are
| doing it in their limited spare time.
|
| 2. It's even more of a mountain of work because Linux
| developers have to write all the hardware drivers themselves
| too. On Windows drivers tend to be written by device
| manufacturers but that rarely happens on Linux because it's
| very difficult to write closed source drivers and they have
| fewer Linux users anyway.
|
| 3. A large proportion of Linux users and developers have drunk
| the Unix kool-aid and think that everything should stay exactly
| as it was in the 70s. Text based config files, services
| controlled by Bash scripts, etc. It's pretty much impossible to
| make a reliable modern system with Bluetooth, WiFi, external
| displays, hotplugging, etc. with that attitude.
|
| 4. Hardware makers only test on Windows so _some_ of the bugs
| in stuff like suspend are probably hardware bugs that Windows
| happens not to trigger.
| mkl wrote:
| Text-based config files are one of the best features of
| Linux. Duplicating and managing Windows software
| configurations is a nightmare by comparison. Making a
| reliable modern Linux system is pretty easy; usually you
| don't need to do anything much beyond installing, but if you
| do, the solid reliable text config and service management
| files make it easier than any other OS I've used.
| taxcoder wrote:
| 1. How others prioritize their time and how limited it is is
| an interesting call to make. Are you familiar enough with any
| of the contributors to know how much "spare" time they have
| and how they use it?
|
| 2. See above.
|
| 3. I am locked to a Windows desktop for work, but support
| Centos servers for backups and such. What is wrong with text-
| based config files? Are GUI checkboxes a better option? They
| may be more discoverable, but seem to me to be less
| configurable. Have you read the Unix Haters Handbook? Unix's
| greatest flaw and greatest strength are its flexibility.
|
| 4. I can't speak much to this, but aren't some manufacturers
| testing on Linux?
| josefx wrote:
| > Great, another Linux distro...
|
| It is less a standalone distro and more a free version of Red
| Hat Enterprise Linux.
|
| > Nouveau glitches.
|
| Then why are you using it? As much work as people are putting
| into nouveau, they have to work more often than not against
| NVIDIA instead of with. If you want a system that works just
| use the proprietary driver.
|
| > Why can't people just band together and create one good Linux
| distro for the desktop.
|
| In this case? commercial interest, people used CentOS in
| production instead of buying Red Hat Enterprise. So the people
| in charge decided to make it useless for that. Now we have
| Rocky to do the same, just with people in charge that are not
| financially connected to Red Hat.
| himujjal wrote:
| To be honest I can feel you.
|
| In terms of DE. More focus and hard work is on building
| something "cool" than something stable and less buggy. I would
| have been happy with Gnome if the base OS is stable. Yes KDE
| turned out to be better, but that was the least important of
| all cases. Lots of work hours have gone into making XFCE, LXQT,
| KDE, Gnome, Guix, Cinnamon, XFCE, Mate etc etc. The choice
| argument is futile if I or someone cannot be productive in it
| and spends time in linux forums. 100 Choices will never make
| open source more popular. You just need 1 damn good choice that
| "just works". Time and energy is precious.
|
| As much as Windows is criticised, you will rarely have any
| issues with it in terms of hardware compatibility.
|
| Coming to Rocky-Linux, this is server side offering. Plus its
| model is different to general desktop linux you use for day-to-
| day.
| kondbg wrote:
| Devil's advocate: why should I choose this yet-to-exist
| distribution over something already existing, such as Oracle
| Linux?
|
| The most common argument (Oracle is evil and litigious.
| Therefore, using Oracle Linux will result in me being sued)
| honestly seems like FUD.
|
| All RHEL downstream distributions rebuild the same SRPMs that
| RHEL provides. Doing a quick comparison over some common packages
| (kernel, httpd, openssl, etc.) between CentOS 8.3
| (https://vault.centos.org/8.3.2011/BaseOS/Source/SPackages/)
| Oracle Linux 8.3
| (https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x8...)
| shows that they are indeed byte identical (with the exception of
| certain spec files including debranding patches).
|
| What is the value of having a separate RHEL derivative? It isn't
| as if the "community" can propose/submit any changes, since any
| changes will cease to make the downstream distribution a "bug for
| bug" compatible RHEL derivative. If I actually wanted to
| participate in the larger RHEL-derivative community, I would need
| to actually submit my changes to the CentOS stream project.
| that_guy_iain wrote:
| > Devil's advocate: why should I choose this yet-to-exist
| distribution over something already existing, such as Oracle
| Linux?
|
| Because you want what CentOS was and this is basically going to
| be what CentOS was. Different name, different people, but same
| prinicple.
| DarkmSparks wrote:
| Theoretically Oracle Linux and CentOS are identical except
| the branding, except CentOS has been abandoned and Oracle is
| just getting started with OL.
| that_guy_iain wrote:
| But Oracle Linux has a different principle really, no? I
| never think of Oracle and think "Making the paid software
| free".
| em500 wrote:
| In an earlier thread, some Oracle guy (not in the Oracle Linux
| team) mentioned that Oracle 8 actually builds from CentOS 8,
| rather than RHEL 8. I was a bit skeptical, since OL 8 usually
| releases much earlier than CentOS 8, but couldn't verify things
| either way. Someone else mentioned that RH actually _only_
| releases RHEL8 sources through CentOS8 sources. Again, I don 't
| know how to verify, but if true they raise a lot of new
| questions about Oracle Linux 8 given the recent CentOS 8
| announcement.
| teknopaul wrote:
| RHEL is open source and always will be.
| haolez wrote:
| Oracle Linux might change the rules in the future. It kind of
| just happened with CentOS :)
| ajsfoux234 wrote:
| Well, the same thing might happen with Rocky Linux as well :)
| galaxyLogic wrote:
| Yes but then somebody would make Rocky-2
| hnarn wrote:
| "Anything _can_ happen" is not an argument. It's about
| quantified risk.
| emayljames wrote:
| Yes, and the 2 parties have very different motivates.
| shawnz wrote:
| It's unlikely they would sabotage their only competitive
| advantage though, whereas Oracle has lots of reasons to
| maintain an enterprise linux distribution besides just
| succeeding CentOS.
| bayindirh wrote:
| > Devil's advocate: why should I choose this yet-to-exist
| distribution over something already existing, such as Oracle
| Linux?
|
| Because there's a whole ecosystem (HPC and Scientific computing
| to be exact) which depends on CentOS (not RHEL, not Oracle, not
| Ubuntu, not Debian) primarily. A CentOS compatible distribution
| is not some FOSS pride thing.
|
| IBM and RH really blew a sucker punch in this regard.
| niea_11 wrote:
| When you say that they depend on CentOS, are they using
| something CentOS-specific. Centos is supposed to be
| compatible with RHEL (minus the logos/trademarks) and
| shouldn't have additional fixes or features. ("bug for bug,
| feature for feature" <= centos wording :)). No?
| bayindirh wrote:
| CentOS don't have to have a _specific feature_ to be
| preferred over RH. Being free in both beer and speech is
| important enough. People (incl. us) install 1000+ server
| clusters with CentOS. The absence of licensing fee allows
| us to buy more servers. The absence of licensing fee allows
| "small researchers" to have a verified platform to work
| with. If you don't have a verified platform, you cannot
| trust your results.
|
| CentOS carries a legacy from Scientific Linux (which was RH
| compatible too) and has a lot of software packages
| developed for/on it. It might be a regular .tar.gz or RPM
| distribution but, they're _validated and certified_ on
| CentOS. This is enough. Some middlewares used in
| collaborative projects (intentionally or unintentionally)
| search for CentOS signature. Otherwise installations fail
| spectacularly (or annoyingly, it depends).
|
| I have to run my own application on every platform with a
| relatively simple test suite which checks results with 32
| significant digit ground truth values. If these tests fail
| for a reason, then I can't trust my application's results
| for a particular problem. My code runs fast and it's
| relatively simple (since it's young). Some software
| packages' tests can run for days. It's not feasible to re-
| validate a software every time after compilation on a
| different set of libraries, etc. CentOS provides this
| foundation for free.
| niea_11 wrote:
| Thanks for your explanation.
|
| I think I understand a little better your point of view.
| CentOS became so important for the HPC community that
| most software is now validated against it. So even if
| RHEL itself were to become free (as in beer), people
| won't switch to it (or at least be reluctant).
| bayindirh wrote:
| Exactly.
|
| My all personal systems are Debian, however when I
| install something research related, it's always CentOS.
| There's no question. I even manage a couple of research
| servers at my former university. They're CentOS as well.
|
| Moreover service (web, git, documentation, etc.) servers
| are CentOS too to keep systems uniform even if there's no
| requirement. So it powers the whole ecosystem, not the
| compute foundation. That's a big iceberg.
| mrtweetyhack wrote:
| People like you who make a profit but refusing to pay for
| a license is exactly why Redhat shut down CentOS.
| _jal wrote:
| > Devil's advocate: why should I choose this yet-to-exist
|
| Devil's response: nobody cares if you do. A lot of people know
| why they want it; the answer will in many cases be that it will
| fill the same niche and not be controlled by a shitty company.
| (If you think calling Oracle shitty is FUD, unprofessional or
| similar, that's fine: see 'Devil's response', above.)
|
| It will stand or fall on its own, as a result of many different
| peoples' choices. For now, it is enough that something is
| growing in the niche from which Centos was uprooted.
| nasalgoat wrote:
| The branding here I think is a big issue. The name "Rocky Linux"
| sounds too homebrew and unprofessional. CentOS sounds Enterprise-
| ish. I find it hard to believe any corporate client would take it
| seriously.
| varbhat wrote:
| _" Thinking back to early CentOS days... My cofounder was Rocky
| McGaugh. He is no longer with us, so as a H/T to him, who never
| got to see the success that CentOS came to be, I introduce to
| you...Rocky Linux"_
|
| -- Gregory Kurtzer, Founder of Rocky Linux and Co-founder of
| CentOS
|
| It's written in Repo's README
| asutekku wrote:
| No matter how good the intentions are, the name is pretty
| bad.
| [deleted]
| phoronixrly wrote:
| They should rename it to something like zpermutator.io
| GNU/Linux. I swear, this thread is peak HN with this name
| bikeshedding.
| bigbubba wrote:
| That is your _subjective_ opinion, one lots of people in
| this thread happen to disagree with.
| bigbubba wrote:
| The only reason you think 'Rocky Linux' sounds unprofessional
| is because you are unaccustomed to hearing it in a professional
| context. Before I read where the name came from, I assumed it
| was named after the mountain range. Would that really be so
| strange, considering CPUs get named after lakes or MacOS
| releases named after cats or regions of California?
| whytaka wrote:
| The biggest public company in the world is named after a fruit.
| _jal wrote:
| Right, just how like corporations would never take a company
| called 'Google' seriously.
|
| Ignore the peanut gallery, it is a fine name.
| rovr138 wrote:
| _they couldn 't even fix they typo!_
| stan_rogers wrote:
| Googol.com was older, and in the early days of Google
| featured a prominent "you're probably looking for _these
| guys_ , not this site" on their front page. (It was, at the
| time, a math site dedicated mostly to the number.)
| 1-6 wrote:
| You can get far with bad branding. Case: Ubuntu
| tokai wrote:
| or java
| jolmg wrote:
| Why is Ubuntu bad branding? Seems short, memorable, good
| meaning, original, etc.
| colesantiago wrote:
| the naming makes it sound like unstable version of linux.
| [deleted]
| joana035 wrote:
| Ubuntu is a Nguni Bantu term meaning "humanity". It is
| often translated as "I am because we are", or "humanity
| towards others", or in Zulu "umuntu ngumuntu ngabantu" or
| in Xhosa, "umntu ngumntu ngabantu" but is often used in a
| more philosophical sense to mean "the belief in a
| universal bond of sharing that connects all humanity"
|
| Taken from
| https://en.m.wikipedia.org/wiki/Ubuntu_philosophy
|
| But yes, Ubuntu is based on Debian's Unstable branch.
| jolmg wrote:
| When they replied, what I originally had written was "Why
| is it bad branding?". I thought it would be obvious from
| the parent comment that I was talking about Ubuntu, but I
| think they thought I was talking about "Rocky Linux".
| nasalgoat wrote:
| I suppose it seems like a juvenile name to me.
| cgb223 wrote:
| Ubuntu doesn't literally mean "a bumpy ride" or "a
| relationship that's got some trouble in it"
| smnrchrds wrote:
| Oh, that's what you thought of! I was confused as why
| people take offence at Rocky.
|
| As a Calgarian, the first thing I thought of was Rocky
| Mountains. Due to their proximity, you see the name is so
| many things and places here. For example, the area
| surrounding Calgary is called Rocky View County.
| _jal wrote:
| I think only monolingual English speaker feel this way.
| tremon wrote:
| Ubuntu doesn't seem a bad word choice to me:
| https://historyplex.com/ubuntu-african-philosophy
|
| _Ubuntu, a Bantu word, defines what it means to be truly
| human._
| pmarin wrote:
| I remember when the BSD mascot was too demonic for some
| cultures. , ,
| /( )` \ \___ / |
| /- _ `-/ ' (/\/ \ \ /\ /
| / | ` \ O O ) / |
| `-^--'`< ' (_.) _ ) /
| `.___/` / `-----' / <----. __ /
| __ \ <----|====O)))==) \) /==== <----' `--'
| `.__,' \ | | \
| / ______( (_ / \______ (FL) ,' ,-----'
| | \ `--{__________) \/ "Berkeley
| Unix Daemon"
| nobody9999 wrote:
| >The branding here I think is a big issue. The name "Rocky
| Linux" sounds too homebrew and unprofessional. CentOS sounds
| Enterprise-ish. I find it hard to believe any corporate client
| would take it seriously.
|
| That seems a pretty specious argument for not using a product.
|
| Especially since the name was used to honor one of the founders
| of CentoS who is now dead.
|
| That seems like a pretty good reason for a name to me.
|
| What's more, I'd be more concerned about _functionality_ than a
| name. But that 's just me.
| lisper wrote:
| If Duck Duck Go hasn't been destroyed by its silly name I can't
| imagine "Rocky Linux" being an issue.
| asutekku wrote:
| I'm quite sure some users have not adopted DDG because of the
| name. "I'm just going to duckduck the [search term]" does not
| roll that well from the tongue when compared to "I'm just
| going to google the [search term]". Google for most does not
| mean the word googlplex, but duck for sure refers to the
| bird.
| moonbug wrote:
| you do the work, you get to pick the name.
| hnarn wrote:
| The reputation behind a name is earned, not given. CentOS
| sounds fine to you because it's been around for years and years
| and has built a solid reputation, it didn't become what it was
| because of a "good name". I don't care if the distro is called
| Bubblegum Naruto as long as it's stable and reliable.
| shawnz wrote:
| I actually think CentOS sounds pretty unprofessional (although
| familiar), while Rocky Linux sounds unfamiliar although at
| least has a meaningful inspiration. I would bet it could come
| to be equally as esteemed as a product called "CentOS" (or even
| "Red Hat") eventually.
| nasalgoat wrote:
| CentOS is Community Enterprise OS. Enterprise is right in the
| name.
|
| I just imagine going to the big boss and saying, "We're
| moving to Rocky Linux" is going to be a tougher sell based on
| the somewhat juvenile nature of someone's first name with a Y
| on the end of it.
| eecc wrote:
| no, the tough sell is telling your boss that you'll have to
| switch to paying Microsoft-range licenses for your server
| farm to an IBM subsidiary, whose name and logo are -
| literally - references to some random guy's clothing.
|
| We're arguing about a frigging name. Rocky Linux; you know
| what Madrake sounds to an Italian?
| https://www.youtube.com/watch?v=KguscIm8N0Y
| slim wrote:
| Try "we're moving to Pink Pants Linux"
| _jal wrote:
| If your "big boss" chooses infrastructure by the name, it
| is time for a new company.
| nasalgoat wrote:
| Lots of decisions are made for arbitrary and, frankly,
| obtuse reasons. Often on a whim. I would just like to
| give the new distro the best chance to succeed.
|
| Clearly I seem to be in the minority, however. I guess
| time will tell.
| shawnz wrote:
| True, but is that really such an advantage? Consider
| telling the big boss: "We're moving to CentOS, but don't
| worry, the 'ent' actually stands for Enterprise".
|
| And regardless I am not really sure how I feel about the
| professionalism of backronyms in general.
| morvita wrote:
| I've been using CentOS for at least a decade and only
| learned today that it was short for Community Enterprise
| OS.
|
| I think, especially around Linux and open source projects,
| people care much less about naming than we tend to believe.
| Product reputation and the endorsement of IT/developers
| matters far more, in my experience, than a name.
| Teckla wrote:
| _CentOS is Community Enterprise OS. Enterprise is right in
| the name._
|
| "Enterprise" isn't right in the name. "ent" is.
|
| Until a few weeks ago, I didn't know what the "Cent" part
| of "CentOS" meant, mostly because I didn't care. I somewhat
| assumed it meant the same as "penny".
|
| Rocky Linux actually sounds good to me. Like a solid, rocky
| foundation on which to build your house.
| numpad0 wrote:
| CentOS sounds amateur enough to me, and besides, that's only a
| problem for cheap businesses that take CentOS as RHEL with a
| piracy waiver. Go pay for RHEL if you are looking for something
| professional.
| [deleted]
| DoreenMichele wrote:
| Would PetrOS work better for you as a _serious_ name?
| TMWNN wrote:
| >The branding here I think is a big issue. The name "Rocky
| Linux" sounds too homebrew and unprofessional. CentOS sounds
| Enterprise-ish. I find it hard to believe any corporate client
| would take it seriously.
|
| I agree. I mean, who would take something called "Red Hat"
| seriously?
| paul_f wrote:
| I've never had to explain why we use GoDaddy as our domain
| registrar. I don't think Rocky Linux will be a problem.
| [deleted]
| kevin_thibedeau wrote:
| The registrar who used Christian values as an excuse to deny
| registrants and then turned around and ran ads with salacious
| content.
| jjice wrote:
| Unrelated to the conversation of naming.
| lock-free wrote:
| If I've learned anything from cloud services, it's that product
| names mean nothing.
| 1-6 wrote:
| Like Snowflake?
| mulmen wrote:
| I always associated that with a snowflake schema. Seems
| like a good, simple, descriptive name.
| Karunamon wrote:
| Or CockroachDB
| mulmen wrote:
| It is as resilient as cockroaches? I don't see the
| problem. Postgres uses an elephant as a mascot because
| "elephants don't forget". What's the difference?
|
| We are literally on the _web_. Look out for spiders!
| Karunamon wrote:
| I agree, don't get me wrong. But look up every single
| thread on CockroachDB to hit HN, and there's an
| inevitable subthread of people whinging about the name.
| Aperocky wrote:
| The name sounds perfectly fine to me.
| murat124 wrote:
| What is the vision for Rocky Linux? A solid, stable,
| and transparent alternative for production environments,
| developed by the community for the community.
|
| Hence the name Rocky Linux, I suppose? Solid as a rock.
|
| Although I'll be inclined to think of it as series of movies.
| Perhaps even split wood before installing Rocky 5?
| lowtech wrote:
| RSLinux sounds like a good replacement.
| GordonS wrote:
| > Hence the name Rocky Linux, I suppose
|
| Hmm, to me, "rock" has connotations of "solid", but that ending
| "y" changes the the connotations completely - "rocky" makes me
| think of uncertainty, risk and peril.
| dfdz wrote:
| I really think someone needs to convince them to change the
| name to something like "Rock Solid Linux". Is there anyway to
| try to make this happen?
| sreevisakh wrote:
| As others have pointed out, the name is a tribute to a late
| CentOS cofounder Rocky McGaugh. It would be sad if it had
| to be changed. We should perhaps emphasize the CentOS
| lineage in the name instead.
| GordonS wrote:
| I didn't know about the "Rocky" tribute, but IMHO it
| would still work as a great nod to Rocky McGaugh with
| "Rock" instead of "Rocky".
| endymi0n wrote:
| ...and Rocky's Solid Linux it is!
| [deleted]
| Darmody wrote:
| "Thinking back to early CentOS days... My cofounder was Rocky
| McGaugh. He is no longer with us, so as a H/T to him, who never
| got to see the success that CentOS came to be, I introduce to
| you...Rocky Linux"
|
| -- Gregory Kurtzer, Founder
| deelowe wrote:
| This project just oozes good-heartedness. I wish him all the
| best.
| joana035 wrote:
| I wish all the best for Rocky Linux, it is Linux after all.
|
| Is always good to have diversity and a community driven
| project.
| emayljames wrote:
| Maybe even a naming convention like Ubuntu: Rocky "Adrian"
| Linux I, then Rocky "Balboa" Linux II.
|
| Seriously though, I am very happy about the name and its
| creation.
| throwaway201103 wrote:
| I think of Rocky the moose from Rocky and Bullwinkle. Not a
| confidence-inspiring name.
|
| Edit: actually Rocky was the flying squirrel.
| zdw wrote:
| And definitely the smarter member of the pair.
| Minor49er wrote:
| I think of the Rocky Mountains myself
| hitpointdrew wrote:
| Welp...that didn't take long. I expected something like this
| would happen in light of the recent changes over at CentOS.
| macintux wrote:
| Took even less time than you think. I remember the original
| Rocky announcement was the same day (or maybe next) as IBM's.
| igotroot wrote:
| Looking forward to give this a spin at home to see if it'll be
| the future of non-RH based linux servers, although it'll take a
| long time before people are willing to throw it in prod like they
| do with CentOS. No way to change that except time.
|
| Also it's interesting that some people defined Rocky as being
| 'unstable' when others read it as being 'solid as a rock'.
| basilgohar wrote:
| But it is a RH-based - it's just like CentOS used to be. It's
| just not owned nor operated by RH.
| soperj wrote:
| This is the best case scenario here.
| CoconutPilot wrote:
| Whats missing is an analysis of why CentOS failed. I think Rocky
| Linux needs to put out a plan how they will make themselves
| financially viable as we've had 3 high profile RHEL respins go
| down in the last 10 years.
|
| CentOS failed twice, it ran out of money in 2014 and was rescued
| back then by Redhat sponsership. Again in 2020. Another widely
| used RHEL respin was Scientific Linux which mothballed when RHEL
| 7 was released.
|
| There seems to be lots of potential users but not lots of
| potential money for a RHEL respin.
| 29athrowaway wrote:
| This project name makes me feel better than "Debian".
|
| Debian = Deb + Ian.
|
| Ian Murdoch broke up with Deb, and later he hanged himself.
| electrotype wrote:
| Someone care to explain _why_ did CentOS switch from downstream
| to upstream builds? I guess there is a reason.
| gvb wrote:
| Money.
|
| RHEL requires expensive licenses. CentOS was RHEL without the
| RedHat branding and without the expensive licensing.
|
| By design, there was a nearly complete overlap between RHEL and
| CentOS. By "repurposing" CentOS into a "rolling release",
| RedHat (IBM) has broken the overlap so CentOS (free licensing)
| no longer competes directly against RHEL (expensive licensing).
| Spivak wrote:
| This is so misinformed it's funny. CentOS and RHEL will now
| be down to the compiler flags compatible since RHEL minor
| releases will now just be point-in-time forks of CentOS with
| security fixes and backports from, you guessed it, CentOS.
| gvb wrote:
| CentOS and RHEL will _only_ be exactly the same at the
| moment when RHEL is a point-in-time fork of CentOS. As soon
| ad RHEL forks from CentOS, CentOS will roll forward and
| will no longer be exactly the same as RHEL.
|
| Previously, CentOS was a rebuild of RHEL. In between RHEL
| releases, CentOS was exactly the same as RHEL. When RHEL
| had a release/fix/backpoint, CentOS trailed until it was
| rebuilt from the new RHEL source.
|
| The "old" CentOS was exactly the same nearly always (nearly
| perfect overlap) and the "new" CentOS is exactly the same
| nearly never (almost no overlap).
| Spivak wrote:
| You act like RHEL 7.1 is a fixed artifact -- it's
| constantly receiving updates, security patches, and
| backports. And CentOS always trails behind on those
| updates so it's never exactly the same as RHEL either.
|
| This change makes CentOS so much closer to RHEL that it's
| weird that people are acting like the opposite is
| happening.
| digitalsushi wrote:
| Right but I use CentOS cause it's the Cyberpunk from April
| 2021, not December 2020.
| hnarn wrote:
| To make people pay for RHEL.
| Spivak wrote:
| The old model went something like this.
|
| - Fedora does its thing informed by but somewhat independently
| of RHEL.
|
| - Red Hat chooses a Fedora release to be the base of RHEL,
| forks it, and starts working on it.
|
| - This eventually becomes RHEL X.
|
| - Red Hat then _forks RHEL X_ to create the RHEL X.0 Beta and
| eventually the RHEL X.0 release. RHEL X keeps getting work done
| on it which eventually lead to another fork which creates RHEL
| X.1 Beta and RHEL X.1.
|
| - After each RHEL X.y is released CentOS starts the process of
| rebuilding it from the sources and tracking upstream changes.
|
| The new model puts CentOS where RHEL X is and so RHEL X.y are
| actually forks of CentOS.
|
| This change matters a lot to you if you care a lot about the
| difference between the minor releases of RHEL because there
| won't be CentOS 7.1 CentOS 7.3 but just CentOS 7. If you just
| yum update on CentOS then you probably don't care since by
| default it will move you up minor versions. You have to try to
| stay on a specific minor version.
|
| What's nice about this change is that anyone can peel off
| releases from CentOS the same way Red Hat will do to make RHEL
| and new features become available when they're ready instead of
| being batched.
| [deleted]
| AntiImperialist wrote:
| I doubt how successful this will turn out to be because of the
| following reasons:
|
| - The old CentOS had a brand value, which Rocky Linux has to earn
| back all over again.
|
| - The old Red Hat was nice to CentOS or at least wasn't
| particularly hostile. That does not mean IBM will be nice too.
|
| - It may be too short a notice for current CentOS users to wait
| for Rocky Linux to come through. They may already move away to
| other alternatives like Debian or Ubuntu or Amazon Linux or
| whatever fits their use case.
|
| - If because of some miracle, Rocky Linux turns out to be just as
| successful as CentOS, there is a chance that either Red Hat or a
| competitor will end up taking control of it too. Corporate
| sponsorship is too lucrative to decline. So, it will end up with
| the same fate as CentOS.
| soperj wrote:
| Just like mysql had value, but much of the open source world
| has just moved on to MariaDB instead.
|
| CentOS users by nature want to stay on their current systems as
| long as possible. Many would have still been on CentOS 7. I
| doubt any will have moved away from CentOS already.
| kubanczyk wrote:
| > So, it will end up with the same fate as CentOS.
|
| Same fate as CentOS, let me think... Can I replace a few system
| packages to convert it to a binary-compatible, patchable,
| community-supported distro, just differently branded? Okay,
| count me in.
| LeoPanthera wrote:
| CentOS had no "brand value" when it was new.
|
| Red Hat was not nice to CentOS when it was new.
|
| The "same fate" as CentOS would mean surviving for 16 years.
| albru123 wrote:
| I don't see how it would be too short a notice for current
| CentOS users really. At least for majority of users running
| CentOS in their production systems and relying on a long-term
| support. It's not like they just go and trash their production
| setup the very moment its running distro lifespan is shortened.
| I'd expect the opposite actually, since you're looking for
| something well supported.
| houseofzeus wrote:
| Agree, I'd imagine most of them are also still on 7, which
| the lifecycle _didn 't_ change for and goes to 2024 even if
| they just stay where they are.
| based2 wrote:
| https://rocksdb.org/ from fb
| nps1 wrote:
| The next CentOS will be where the core developers who are
| actually contributing to project will move. However, branding
| does matter if you want enterprise following. Rocky does sound
| unprofessional.
| bonzini wrote:
| Core developers and infrastructure is moving to CentOS Stream.
| However the software that is running on said infrastructure is
| all open source.
| sp332 wrote:
| Good. That means it's less likely to sell out to some suit farm
| and get cancelled like CentOS did.
| effie wrote:
| > _suit farm_
|
| I love new language gems. Thanks!
| macspoofing wrote:
| What's the point of keeping the CentOS brand at this point? Why
| not have RHEL and RHEL Stream?
| hnarn wrote:
| The fact that a majority of the comments are whining about the
| name really shows you the worst part about open source: the non-
| contributing but highly entitled part of the community.
|
| If you don't like the name, launch your own CentOS replacement.
| There's no better time than now. If there's one thing this
| project does not need right now, it's armchair marketing experts.
|
| If you do care about a viable CentOS replacement, do something.
| Contribute code, money or expertise. The last thing any new and
| vulnerable project needs is another "idea guy" or a new logo.
| jeremymcanally wrote:
| "The loudest mouths are often attached to the idlest hands." -
| ancient open source software proverb
|
| (It's not ancient. I made it up. But it's sadly true.)
| goodpoint wrote:
| It's very true and for a basic reason - one minute spent
| doing is one minute taken away from talking/writing.
|
| This is the reason why many excellent projects remain obscure
| while marketing-driven products become famous... and often
| take credit for other people's ideas.
| nps1 wrote:
| Or it just means the name does matter to vast user community.
| And you are hell bent on not listening to user community and
| not taking valid criticism.
| macksd wrote:
| I think this is one of those cases where one might say the
| customer (or user, in this case) is always right. But there
| are always customers who will just find something to complain
| about, and often (like when the product is a free community
| service) they're simply not worth having as customers.
|
| edit: Personally, I've been a heavy user and supporter of
| CentOS but I've almost never referred to it as CentOS.
| Because the point is to be binary compatible with RHEL, and
| it's then naturally almost the same thing as Oracle Linux and
| Scientific Linux, etc. So I would simply refer to "EL5" or
| "EL6" in code or other places. This probably won't be any
| different.
| dvt wrote:
| No, @hnarn is right. And you don't really "get" this until
| you start maintaining an OSS repo (I speak from experience).
| For _years_ , I was very critical of Linus Torvalds and his
| brusque attitude. Then I started a few moderately-popular OSS
| projects, and the entitled masses started pouring in.
|
| After a while, it's hard to refrain from telling people to
| just screw off.
| mkovach wrote:
| Don't know if it has been mentioned, but the name Rocky is from
| Rocky McGaugh, co-founder of CentOS. He passed away and they
| named the new effort after him.
| ignoranceprior wrote:
| I'd just like to interject for a moment.
|
| I'm confused why everyone is complaining about the "Rocky"
| part, which is a nice tribute and sounds pretty decent, when
| the actual problem is the "Linux" part. It should really be
| called "Rocky GNU/Linux", or "Rocky GNU+Linux", because the
| Linux kernel is only one component of a complete GNU-based
| operating system compatible with the POSIX standard.
| anonunivgrad wrote:
| I literally spat my coffee out. Thanks for the laugh.
| awill wrote:
| I guess we found Richard Stallman's hacker news account.
| sabas_ge wrote:
| It's part of the notorious copypasta
| https://wiki.installgentoo.com/wiki/Interjection
| na85 wrote:
| I'm so tired of this drivel.
|
| It's called Linux because GNU is awful at naming things. The
| name "Gahnoo" is too awkward to pronounce and "Gahnoo plus
| Linux" is too long.
|
| People shorten names for convenience. Deal with it or come up
| with a better name than GNU.
| throwawaygulf wrote:
| Whoosh!
|
| https://stallman-copypasta.github.io/
| boomboomsubban wrote:
| First, obvious troll is obvious. Second, complaining that
| the "GNU" part is awkward to pronounce when it's a regular
| English word unlike Linux amuses me. Linus Unix to Linux
| will forever haunt free software.
| _hyn3 wrote:
| Right, infamous copypasta... forgive the pedantry, but
| the English word "gnu" (referring to the mammal) is
| pronounced "noo", while the non-English word "GNU" is
| pronounced "gah-noo"[0], as OP correctly pointed out.
|
| 0. https://www.gnu.org/gnu/pronunciation.en.html
| [deleted]
| em500 wrote:
| I share your disappointment. Out of 150+ comments so far, I
| believe there has not been a single technical comment about the
| actual work involved in building a version-pinned RHEL clone.
|
| Without any experience myself (beyond some kernel build maybe
| 10 years ago), I gathered (from
| https://wiki.centos.org/About/Building_8) that the majority of
| work involves manually de-branding the RHEL sources. This
| apparently can't be automated, as it requires human judgement
| in which packages/files de-branding is required and in which it
| might actually break something.
|
| Between major version jumps, e.g. from RHEL/CentOS 7->8 there's
| apparently also lots of work in getting the build environment
| up to date.
|
| This raises numerous interesting questions, such as:
|
| 1. Where do the upstream RHEL sources live? CentOS sources are
| in https://vault.centos.org/8.3.2011/BaseOS/Source/SPackages/,
| but where do they get them upstream? I believe they're only
| available to RHEL subscribers, does this give RH a way to block
| clones?
|
| 2. Where / what are CentOS's actual build scripts / tools? Is
| there some howto or writeup how to make a CentOS iso (or cloud-
| image) on my own PC after downloading the source tree?
|
| 3. Do CentOS devs go through the entire manual de-branding
| exercise with every minor/major update? Presumably they are
| using _some_ sort of automation /scripting/diffing somewhere.
| Are these processes/tools available or documented anywhere?
|
| I hope at some point someone with some actual knowledge about
| this can chime in.
| joseph wrote:
| RHEL source RPMs can be downloaded from
| http://ftp.redhat.com/pub/redhat/linux/enterprise. According
| to your link, CentOS doesn't use the source RPMs since 7 but
| uses git repos instead. I don't know where the git repos are
| located, however, or if it is still possible to build the
| whole OS from just the SRPMs.
| soperj wrote:
| >1. Where do the upstream RHEL sources live? CentOS sources
| are in
| https://vault.centos.org/8.3.2011/BaseOS/Source/SPackages/,
| but where do they get them upstream? I believe they're only
| available to RHEL subscribers, does this give RH a way to
| block clones?
|
| How'd they used to do it then? I assume they just became a
| subscriber?
|
| Edit: just thought about it, couldn't they get them from
| CentOS? Would be pretty funny.
| em500 wrote:
| From what I understand[1], up to RHEL6, Red Hat released
| their sources on public ftp, but after that they became
| customer/subscriber-only.
|
| I would have thought that the GPL ensures that the customer
| can then freely redistribute them, but I've read that
| companies can still make that option very unattractive
| through other means (e.g. terminating the customer
| contract, mingling sources with proprietary stuff and
| making them hard to disentangle). I don't know if RH is
| playing such games, but the complete lack of non-gated
| RHEL7 and 8 source code on the web gives some strong hints.
|
| edit: relevant thread: https://github.com/rocky-
| linux/rocky/issues/4
|
| [1] https://lwn.net/Articles/603865/
| macksd wrote:
| >> I would have thought that the GPL ensures that the
| customer can then freely redistribute them
|
| I'm actually surprised Red Hat has typically shipped
| SRPMS in bulk to it's customers. I think it's rare that
| customers would use them, and the GPL allows Red Hat to
| be far less accomodating. It allows you to charge for
| each copy of the source code you convey, it doesn't need
| to be in such a convenient form, it doesn't need to be
| available on-demand, it just needs to be available on-
| request.
|
| Once a customer has it, yes - the GPL allows them to hand
| it to Rocky Linux and let them run with it. But I think
| the community has been fortunate so far just to get the
| distro sources they have in the way they've gotten them.
|
| edit: Perhaps "fortunate" isn't the right word, since Red
| Hat benefits from the community and owes the community
| some reciprocation. I'm just saying that legally, if Red
| Hat wanted to be bigger douche bags, the GPL gives them
| some space to do so. And I'm glad they haven't fully
| taken advantage of that before.
| netzvieh wrote:
| > 1. Where do the upstream RHEL sources live? CentOS sources
| are in
| https://vault.centos.org/8.3.2011/BaseOS/Source/SPackages/,
| but where do they get them upstream? I believe they're only
| available to RHEL subscribers, does this give RH a way to
| block clones?
|
| Red Hat publishes it's sources on https://git.centos.org.
| Those are then used to build CentOS Linux packages.
|
| In the future they'll do their development there, and build
| CentOS Stream and Red Hat Packages from there.
|
| See also: https://crunchtools.com/before-you-get-mad-about-
| the-centos-...
|
| > Remember, the source code at git.centos.org is basically
| read only, downstream code from RHEL. That's how Red Hat
| complies with the GPL. Technically we go above and beyond
| because we are only legally required to provide code to
| customers, and not required to provide code for
| BSD/Apache/etc licensed code, only attribution.
|
| Regarding question 2, CentOS has a somewhat custom build
| system for each major version afaik, for 8 this would be
| https://koji.mbox.centos.org/koji/
| em500 wrote:
| > Red Hat publishes it's sources on https://git.centos.org.
| Those are then used to build CentOS Linux packages.
|
| Have you checked if this repo actually works as intended?
| Because I was wondering if the git repo has RHEL or CentOS
| sources (or both). So I tried to find out myself instead of
| just throwing the question out there. It went roughly as
| follows:
|
| - Let me check the sources of dracut (the RHEL installer)
| in https://git.centos.org/rpms/dracut. Files: empty,
| Commits: empty, Forks: empty, Branches and Releases:
| judging by the names they seem to be CentOS, not RHEL
| sources. And they're using git.centos.org just as a code
| dump, not for development. Fair.
|
| - Let's see the actual code. git clone
| https://git.centos.org/rpms/dracut.git Cloning into
| 'dracut'... remote: Counting objects: 1673, done.
| remote: Compressing objects: 100% (1632/1632), done.
| remote: Total 1673 (delta 82), reused 1446 (delta 0)
| Receiving objects: 100% (1673/1673), 1.60 MiB | 2.08 MiB/s,
| done. Resolving deltas: 100% (82/82), done.
| warning: remote HEAD refers to nonexistent ref, unable to
| checkout.
|
| ??? There's nothing there.
|
| - Back to the web interface,
| https://git.centos.org/rpms/dracut/tree/c8 Reading
| .dracut.metadata, I guess the source is in
| SOURCES/dracut-049.tar.xz. But browsing the directory
| https://git.centos.org/rpms/dracut/blob/c8/f/SOURCES lists
| only patches, not the presumed source dracut-049.tar.xz
|
| - Maybe it's under Releases? Let's check
| imports/c8/dracut-049-95.git20200804.el8 Clicking the
| source tree gets me back to the SOURCES dir with only
| patches, not good. Maybe the floppy-save button? https://gi
| t.centos.org/rpms/dracut/archive/imports/c8/dracut... ->
| 404-Not-Found. https://git.centos.org/rpms/dracut/archive/i
| mports/c8/dracut... -> 404-Not-Found.
|
| I'm not a professional dev, maybe I just don't understand.
| But is there a way to actually see/browse/download the
| dracut source code from CentOS 8.3 (let alone RHEL 8.3)
| from git.centos.org?
| [deleted]
| duxup wrote:
| It maybe shouldn't but it always amazes me by how much
| developers (assuming that is who they are) will subject other
| developers to the same bikeshedding and minutia type hassles
| ... that suck for everyone.
|
| It's all grounded human nature I'm sure, but man it is
| terrible.
|
| We all are frustrated by that behavior ourselves, why do it to
| other people?
| mumblemumble wrote:
| It's even more fundamental than human nature. Bikeshedding is
| better understood as an emergent behavior of groups of people
| than it is a thing that individuals do.
|
| Bikeshedding-type comments come to dominate conversations
| because they take less time and effort to compose and
| express, and therefore tend to get in ahead of and
| (especially in a synchronous communication medium) crowd out
| more substantive contributions. While the expertise and
| temperament of the individual conversation participants may
| be contributing factors, the dominant one is simply the size
| of the group.
| duxup wrote:
| Yeah the effort issue is huge.
|
| I was reading some discussion where someone was writing
| some part of a website for a product. They chose a
| framework and the whole thing was spammed with 'why does it
| have to be x' type contributions. No help, no technical
| discussion, just these empty one off sentiments spewed at
| the person who has to actually do the thing. It was just
| sad.
| wayneftw wrote:
| Pffft. Imagine coming to a forum where people commonly give
| their opinions only to accuse them of "whining" and
| "entitlement" when they simply give an opinion that you don't
| like.
|
| As if questioning whether a project name is any good suddenly
| equates to an application to be an "idea guy" or a logo
| designer.
|
| If you don't like the majority opinion about something as
| trivial as a name, stop visiting this forum. Does that advice
| sound familiar? Perhaps it doesn't feel fair for someone to
| offer you only one of 2 extremes? Hmmmm.
|
| The last thing this forum needs is another open source warrior
| patronizing everyone for participating here.
| goshx wrote:
| how meta
| boogies wrote:
| Down to death your comment goes. That's what you get for
| complaining about complaining about complaining about the
| name. Because _obviously_ complaining about complaining adds
| much to the discussion, while complaining about those
| complaints about complaining draw away from it[?]
| anonunivgrad wrote:
| First impressions and names matter. As much as we don't like
| it, human beings are irrational and emotionally driven. There's
| nothing wrong with discussing a name.
| tus88 wrote:
| What's wrong with the name? It seems fairly uncontroversial to
| me.
| eggman314 wrote:
| In some contexts rocky is synonymous with unstable or
| unreliable, so I assume that's the issue some people have.
| CivBase wrote:
| Really? My first thought was the "Rocky Mountains" which
| seem like an apt metaphor for something slow, stable, and
| rock-solid. The logo even looks like a mountain peak.
|
| My second thought was Rocky Balboa... but I figured that
| probably wasn't right.
| mongol wrote:
| I think if you are not native English-speaking, your
| first thought will be the Italian stallion. At least,
| that is what I first think of.
| b0rsuk wrote:
| It can also be associated with a 'rocky ride'. The name
| doesn't bother me in the slightest.
| nertzy wrote:
| It's pretty funny that anyone would complain about a Linux
| distribution being named after a developer's given name.
|
| I mean, it's _Linux_.
| wwright wrote:
| Debian also did this.
| jabbany wrote:
| I feel like this is a fact that's much less well known :)
|
| (Debian is actually a portmanteau of Deb(ra) + Ian...)
| [deleted]
| Fnoord wrote:
| Irony being they (Ian and Deborah) split up, Ian quit
| Debian and worked for Sun (arguably a competitor back
| then), Docker, ..., and unfortunately committed suicide.
|
| The good news? Debian's still going strong.
| gremlinsinc wrote:
| This sounds like a Halt and Catch Fire spinoff.
| tux wrote:
| I think the name and the logo is good. Don't listen to the people
| who just keep talking and not helping! Good to see that CentOS
| cofonder picked this up and now became a founder of Rocky Linux.
| This shows dedication and rock solid background. Rocky Linux will
| be a project to follow, help and use in production environment.
| Thank you for all your hard work!
| CivBase wrote:
| I knew what CentOS was, but never followed it because I've never
| personally had use for it. Still, I appreciate what it did and
| was glad to have it as an option should I ever need a super
| stable distro in the future.
|
| That said, I think the FAQ is missing an answer for a critical
| question: What ultimately drove CentOS to its regrettable fate
| and what will Rocky Linux do to avoid a similar misfortune?
| teknopaul wrote:
| IBM. Rocky will not be be IBM.
| CivBase wrote:
| I don't think CentOS ever intended to be IBM either.
| flatline wrote:
| I always thought it was more than a little incestuous for
| RH to acquire and maintain the RH clone, but it did fill a
| niche.
| nickysielicki wrote:
| The most frustrating thing about this is that Redhat was
| making a profit before IBM bought them. They had existed for
| 20 some years on a business model that business people didn't
| understand, and they were able to do that because they
| understood what open source would become and how they could
| play a role in that.
|
| One of the things that YC is always talking about is that
| founders looking for ideas should look to identify situations
| where most people think it's going to turn out one way, but
| most people are wrong and it's actually going to turn out
| another way. In the context of the late 90s, where virtually
| all software was proprietary, they bet on open source
| software and support plans, and made a sustainable company on
| it. They contributed to open source so that they would have
| the expertise, gave all the software away for free, and then
| sold the expertise through support plans.
|
| And then the business people came along and they're showing a
| deep misunderstanding of why Redhat was able to sell support
| plans in the first place. People on RHEL are going to stay on
| RHEL, but people on CentOS -- the market of people who are
| not paying customers but could theoretically become
| customers, are almost certainly going to go to Canonical.
| This will kill Redhat.
| syshum wrote:
| No the most frustrating part is all the Red Hat employees
| attempting
|
| 1. Claim "IBM has no influence, this was all our own
| independent action, honest, believe use guys....
|
| 2. Red Hat employees instance that "CentOS 8 was never
| officially supported until 2029 so we did not go back on
| anything"
|
| if people believe either of those I really need to get in
| real estate and start selling bridges
| strenholme wrote:
| >CentOS 8 was never officially supported until 2029 so we
| did not go back on anything
|
| The thing though is that RedHat _is_ responsible for that
| impression. Every previous version of CentOS before 8 has
| been supported until the upstream RHEL pulled the plug.
| CentOS's official page said it would be supported until
| 2029 ( https://archive.is/7Qmtw ).
|
| A reasonable person would infer that CentOS (now
| controlled by RedHat, so, yes, RedHat) made the same
| promise that they made (and kept) with every previous
| version of CentOS: That it would be supported for 7-10
| years. _Not_ just over 2 years.
|
| I definitely inferred a decade of support. If I knew that
| CentOS 8 would be cut off at the end of 2021, I would not
| had installed it. I would had installed Ubuntu 20.04 LTS.
|
| Indeed, replacing my CentOS 8 installs with Ubuntu 20.04
| is _exactly_ what I have been spending all last week
| doing.
| Shorel wrote:
| Hopefully. Canonical needs the profit.
| thr0w3345 wrote:
| Redhat acquired it, then ibm acequired redhat and then game
| over.
| em500 wrote:
| Obvious next question: what drove the CentOS devs to sell to
| Redhat. From previous discussions, I understood that it came
| down to lack of resources / devs to maintain and support it.
| So OP's question is on point: what will Rocky Linux do to
| avoid a similar misfortune?
| circularfoyers wrote:
| There isn't any evidence that I'm aware of that this decision
| was influenced by IBM (correlation doesn't equal causation).
| e40 wrote:
| Anyone believe that I will, at some point, be able to point my
| CentOS 8.x configuration at the Rocky Linux repo and just upgrade
| to it? That would be ideal. I realized GPG keys will need to be
| replaced, etc.
| charliebrownau wrote:
| Maybe its finally time to walk away from
|
| Cloud
|
| Centralisation
|
| Corporations
|
| and invest time, money and energy into a different Linix eco
| system
| geraldcombs wrote:
| Setting up shop under a new name can be stomach-churningly
| daunting. Best of luck to Gregory and the rest of the team.
| nycticorax wrote:
| Does anyone know what exactly what were the legal/financial
| mechanics of RedHat 'absorbing' CentOS in the first place? Is
| "CentOS" a trademark? Is the CentOS logo trademarked? Who exactly
| owned the servers that CentOS was distributed from? Did CentOS
| have people on the payroll who took jobs at RedHat? (Did CentOS
| have a payroll in the first place?)
| tcldr wrote:
| Rocky makes me think 'unstable' and 'uncertain' which seems at
| odds with the stated vision of the distribution. Might make for a
| tough sell.
| einarfd wrote:
| It's named in tribute after a guy called Rocky McGaugh. I don't
| think they want to change it.
| ravi-delia wrote:
| Probably not, apparently it was named after Rocky McGaugh, who
| after helping to found CentOS has died. It's a pretty cool way
| to honor him.
| bserge wrote:
| Well, it's a really accurate name, so at least they're honest.
| vbezhenar wrote:
| What do you think about CentOS? Cheap OS?
| jolmg wrote:
| In my head, that idea kind of balances with looking like
| "Central" OS. Something at the center of anything is more
| likely to be solid.
| Aperocky wrote:
| As someone who's named Rocky, reading this thread is amusing.
| Every comment feels personal.
| dfdz wrote:
| I got the same impression. Do you think it would be too late to
| change the name to "Rock Linux" or "Rock Solid Linux"?
|
| Since branding is so important this really seems like something
| that should go through focus groups or crowd sources somehow?
| Maybe a poll on hacker news? Unfortunately, I really think
| changing the name would be critical to the success of the
| project. Imagine you are a technical lead and you have to
| convince your boss to switch from RHEL to Rocky Linux...
|
| Edit: I know the name is in tribute to Rocky McGaugh, but I
| still think "Rock Solid Linux" "named in tribute to CentOs co-
| founder Rocky McGaugh" would make the project more successful
| shawnz wrote:
| One disadvantage of "Rock Solid Linux" is that it shortens
| poorly. I think "Rock Solid" or "RSL" would be ambiguous. On
| the other hand I think "Rocky" sounds nice and unique (at
| least in this space).
|
| Also I feel naming it "Rock Solid Linux" would be a bit gaudy
| or arrogant.
| cat199 wrote:
| there was a now-defunct 'rock linux' already:
|
| https://distrowatch.com/table.php?distribution=rock
| dimitrios1 wrote:
| Given we are talking of branding, did you both completely
| miss the logo? To me it's clear the name is in reference to
| mountains, as in the Rocky Mountains.
| tcldr wrote:
| No, I didn't - and neither will many others!
|
| That's the point.
|
| It's a great tribute to one of the late Cent OS founders,
| but it comes with unfortunate marketing hurdles.
| simonh wrote:
| I first thought of Rocky Balboa, the plucky underdog. I'd not
| heard of Mr McGaugh before, but it seems a fitting tribute.
| Alupis wrote:
| > The CentOS project recently announced a shift in strategy for
| CentOS. Whereas previously CentOS existed as a downstream build
| of its upstream vendor (it receives patches and updates after the
| upstream vendor does), it will be shifting to an upstream build
| (testing patches and updates before inclusion in the upstream
| vendor.
|
| Wow, I haven't been following this very closely - but isn't that
| Fedora they're describing? At least... traditionally...
|
| Fedora was upstream, RHEL was stabalized in the middle, and
| CentOS was downstream - regarding patch releases and features,
| etc.
|
| Is Fedora going away too?
| smnrchrds wrote:
| Fedora is desktop-focused. RHEL and CentOS are server-focused.
| I think there is a place for both. But who knows, maybe IBM
| will discontinue one, or both.
| LinuxBender wrote:
| RHEL and CentOS are both server and desktop. The desktop is
| just not flashy or shiny or bleeding edge. The default
| install is/was Gnome 3 shell.
|
| I am not sure if this is still the case, but Redhat used to
| require 100% of its employees to use RHEL Workstation as the
| desktop.
| bayindirh wrote:
| > Is Fedora going away too?
|
| Nope. - Fedora is cutting edge/desktop. -
| CentOS Stream is testing/RC area for RHEL patches. - RHEL
| is the stable server for enterprise.
|
| This is what I understood from a reply to another comment of me
| in a similar thread.
___________________________________________________________________
(page generated 2020-12-16 23:00 UTC)