Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rocky Linux shares how they may continue to obtain the RHEL source code

phoronix.com

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#31

Post by maffydub »

tsimionescu wrote: post #26
Twirrim wrote: post #20

Earlier quoted context omitted.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

It should be noted, as many businesses are finding out, that you can't redistribute Ubuntu binaries or sources as-is, since they contain registered trademarks of Canonical. So, if you want to ship Ubuntu-based systems, you actually have to maintain your own version of all of their software stripped of the trademarks and re-compiled, or pay them. It seems Canonical is getting more interested in actually enforcing this…

Do you have any other references on this?

It seems that it all hinges on what a "modified version" of Ubuntu is. Is redistributing their packages outside of a full disk image a modified version?

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#32

Post by drumhead »

The days of community and cooperation are coming to an end. Reddit ditches the relationship it had with it's users, and now Red Hat is turning into more of a proprietary software company. Did we take the spirit of the old internet for granted? Who's next I wonder.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#33

Post by markfeathers »

cramjabsyn wrote: post #28
Twirrim wrote: post #20

Earlier quoted context omitted.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

I tend to agree, if Debian embraced a longer term support model it would attract a lot of enterprise deployments. RHEL is something like 10 years while Debian is more like 2, 3 if you push it.

Stock debian is 5 years with their LTS project, but they have a paid "ELTS" project that adds an additional 5 years. So 5 years for free, 10 total years as a paid support option. https://wiki.debian.org/DebianReleases

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#34

Post by brnt »

Twirrim wrote: post #20
traceroute66 wrote: post #7

Earlier quoted context omitted.

And now with the release of Debian 12 ("bookworm"), Debian is now sufficiently up-to-date for most users.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

> You get about a 12-24 months at most of security patches, and that's effectively it

What if all that effort on CentOS forks was spent on this?

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#35

Post by brnt »

verdverm wrote: post #3

Not sure these "options" are going to satisfy business risk analysis. We are looking into moving away from all things CentOS, RHEL, or projects like Rocky. It was going to be Rocky, but no more. Red Hat got blue washed and is now ruining their reputation

I don't understand all these CentOS forks: you're still dealing with Red Hat and reinforcing their ecosystem for free. What if those forks poured the effort behind Debian? A truly democratic distro that cannot pull rugs from under your feet.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#36

Post by _ea1k »

drumhead wrote: post #32

The days of community and cooperation are coming to an end. Reddit ditches the relationship it had with it's users, and now Red Hat is turning into more of a proprietary software company. Did we take the spirit of the old internet for granted? Who's next I wonder.

In many respects, I feel like it already ended.

- How many companies still offer free APIs for access to their data? This used to be amazingly common. Now, even my garage door wants a paywall. - Google bragged about not selling search placement. But is what they are doing now really any different than the old keyword buying engines? - How many people still use email? And of those, how many just use gmail, effectively giving Google a near-monopoly - It used to be that MS Office competed with other office suites and there was a lot of talk pushing for long term interoperability. But all of that seemingly died with the shift to online services.

Free as in speech is in worse shape now than it was 20 years ago.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#37

Post by _ea1k »

verdverm wrote: post #3

Not sure these "options" are going to satisfy business risk analysis. We are looking into moving away from all things CentOS, RHEL, or projects like Rocky. It was going to be Rocky, but no more. Red Hat got blue washed and is now ruining their reputation

I'm not sure that the old model did either, tbh. The clones were never a great choice if you needed to satisfy business concerns.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#38

Post by wazoox »

Twirrim wrote: post #20
traceroute66 wrote: post #7

Earlier quoted context omitted.

And now with the release of Debian 12 ("bookworm"), Debian is now sufficiently up-to-date for most users.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

That's simply not true. All Debian releases have been LTS since 2014, for the following architectures : i386, amd64, armhf and arm64.

All Debian releases get 1 year of full updates after the new release, and at least 5 years of updates in total from their initial publication.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#39

Post by wazoox »

cramjabsyn wrote: post #28
Twirrim wrote: post #20

Earlier quoted context omitted.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

I tend to agree, if Debian embraced a longer term support model it would attract a lot of enterprise deployments. RHEL is something like 10 years while Debian is more like 2, 3 if you push it.

No, all Debian releases are completely supported 3 years (1 full year after the release of the new stable release) and are LTS for 5 years.

Re: Rocky Linux shares how they may continue to obtain the RHEL source code

#40

Post by darkr »

brnt wrote: post #34
Twirrim wrote: post #20

Earlier quoted context omitted.

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit. Cano…

> You get about a 12-24 months at most of security patches, and that's effectively it What if all that effort on CentOS forks was spent on this?

CentOS (and it's forks) never backported security fixes for old software versions; it was always RedHat that took on this grunt work.

Even within that 12-24 month timeline, security fixes are commonly only backported where there is a significant enough security risk in a significant enough package. More resource on this mundane but important task is sorely needed

Post reply on HN