601–610 of 642 posts
Earlier quoted context omitted.
Consider downgrading to CentOS 7. It should work for 4 more years.
Can we take RedHat's word for it, though? CentOS 8 was supposed to be supported until 2029 before this bombshell announcement. https://web.archive.org/web/20201101131417/https://wiki.cent...
Earlier quoted context omitted.
Right, so: for this case, CentOS Stream will be virtually identical to the CentOS Linux RHEL rebuild.
We will certainly try. Need to mirror a repo, freeze it and update our installation infra so it looks to the local repo rather than the national mirror. All repo settings will look to local repo so we'd have no dependency problem or version creep if we need to install an additional package. Didn't completely think how to handle the occasional emergency update though. Also, we need to compile in some packages. Hope th…
Earlier quoted context omitted.
Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.
There is alien[1], but I'm not sure if it is flawless, because of slightly different ways of doing things across distros like /etc/default vs /etc/sysconfig for example. Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh…
It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work.
For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
I have a feeling they are going to switch RHEL to the same model that Ubuntu follows, where it’s free to download and use, with no license to worry about or anything, and then there’s an optional support contract you can add to it if you want paid support.
Earlier quoted context omitted.
Change is scary.
Come on, be serious. You think people who standardized their infrastructure on CentOS 8 under the assumption that they will have 10 years of stable support, are negative about this because they are afraid of change? And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being…
* Use cases which actually despite the fears will be covered just fine by Stream * Use cases which will be covered by the upcoming expanded no-cost/low-cost RHEL programs * Use cases which, yeah, aren't covered
It's my estimation that the first two are actually the vast majority. I don't mean to be flippant (it was a long day). understand that people who are mostly in the third case are angry and disappointed, but from what I've seen in talking to people both when Stream was launched and after this announcement, at least some large number who are worried that that's their situation are going to be actually getting something better when the dust settles.
Earlier quoted context omitted.
> What we need are top level JIT, AOT and GC implementations, anything else is just going backwards. Not always. As I aforementioned in another thread, we also need C/C++, Python, Perl, etc. as is since they fill different roles and attack different problems. I've written Java, C, C++, Python, Perl, PHP. Had to abuse some of them to fit roles which they're not designed to do. At the end of the day, these languages sa…
C and C++ development is sponsored by the corporations of Apple, Microsoft, IBM, Oracle, Google.... PHP was mostly driven by Facebook needs. None of them is any different from Oracle. And apparently you fail to understand who has contributed to state of the art implemetnations of AOT compilation to toolchains like LLVM, hint the companies that HN loves to hate, it weren't weekend and late night coders.
I'm pretty aware that nearly all clang/LLVM development is driven by apple.
On the other hand you apparently fail to understand my point of view about Oracle and Java ecosystem. I'm neither against Oracle nor Oracle's development of Java or Java's development in the interest of Oracle mainly.
I'm only against Oracle's motives about making Java a walled garden and usage of this programming language to extort license money from others.
On the other hand, I personally use OpenJDK runtime countless times every day, knowingly or unknowingly. I'm written Java in the past and have no reservations or bad things to say about it. Contrary to your view about other programming languages, I'm pretty neutral against every other programming language.
> C and C++ development is sponsored by the corporations of Apple, Microsoft, IBM, Oracle, Google.... PHP was mostly driven by Facebook needs.
There are no news for me here either. Development of a programming language or any tool with input from its users is a non-issue. Also, every user has needs from the products they use, so they will provide feedback and communicate their needs.
The difference, I want to highlight and highlight again, none of these corporations can use C++ or PHP or Python to extort license money from their customers. PHP is owned by Zend, so they may try. C++ is almost public domain now. LLVM is under apache license. Either way I use GCC which is GPL. Python is 20+ years old and is also almost public domain.
Contributing to a tool to get what you want is different from owning a tool and to use it to extort licensing money is different.
Either way, as aforementioned, I have nothing against Java, contrary to your views against other programming languages.
Earlier quoted context omitted.
Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.
>Java , postgres and tomcat That's his stack... >So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, It's not magic, just alien.
> That's his stack...
What’s your point and when did I ever mention Java?
> It's not magic, just alien.
Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.
Earlier quoted context omitted.
I'm wondering, what ties you so strongly to a single OS? Nay, to a single Linux distribution? I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire. I'm sure I'm missing something. Enlighten me?
Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.
Though my experience with package manager is that dependency management is hell (rife with potential conflicts), so I do see the problem a bit better.
Still, it shouldn't take that long to fix? Like a few days of sprint to setup Nix or something like that?
To me this news is at once shocking, and blindingly obvious in hindsight. Shocking, because I'd never imagined they'd kill off CentOS 8 so early. CentOS 8.0 dates from Sept 2019, so it's killed in just the 3rd year of its presumed 10 year lifespan. I could read the tea leaves when they announced this Stream thingy recently, but I'd thought they would at least hold off till RHEL9 to pull the lever. Blindingly obvious,…
if I remember right technically centos didn't really exist as an entity that could be bought, Red Hat just hired all the developers (there were only ever 3-4 people working on centos). I would guess they are now working on Centos Streams, or have moved on to other things entirely. Its not like Centos has been killed off either, so it didn't cost a lot and this wont really save anything, it's "just" a change of focus.
Microsoft buying ubuntu would be an interesting (and not impossible) move though.
Earlier quoted context omitted.
Red Hat didn't make CentOS they acquired it. This is very similar to a large corporation acquiring a smaller competitor, promising to continue supporting it, creating a new, different product using the brand, then dropping the original product.
Centos was always a free alternative to Redhat. I and many other people used it because it was a way to get the benefits of Redhat without paying for it. This is a really smart more on their part to get people to stop doing precisely this, and getting them to pay money for RH. Pepople who are not willing to pay (me included) are now rightly annoyed, but we were never their customers in the first place, so we don't re…