71–80 of 257 posts
What is so great about RH? When i had opportunity to use it, it look so bad mostly because lack of current/decent software in repo. Maybe their support is amazing?
The Red Hat retail to Enterprise shift still leaves a little bitter taste in my mouth. I remember when they shut down public access to the rhel binaries and the beginnings of Centos. All legit to the letter of the license and no more. I get it though. Anyone know how Centos under Red Hat is nowadays?
It was probably the best thing to happen to CentOS provided RedHat will continue letting them be an independent distribution.
Earlier quoted context omitted.
Yes, support and peace of mind. Packages that make it into their repository are fully tested and supported by RH. Almost all of them are old but they are pretty much guaranteed stable and Red Hat will support the software until the EOL of whichever RH version you are running, even if the developers of the package do not support a version of the package anymore.
Sometimes being old is a double edged sword. For instance, RHEL7 has a lot of problems on AWS because the kernel is too old to properly support many of the virtualisation features AWS provides. On bare metal RHEL7 is great, though.
We have no issues running RHEL7 under VMware.
Earlier quoted context omitted.
Back when Solaris 7 was a thing, dependency hell was very much a thing.
UNIX vendors didn't normally ship releases or updates that introduced dependency issues. Part of their job was doing testing and quality assurance, that's what you were paying good money for. Most such issues were introduced locally. A good sysadmin would know how to avoid dependency hell. For example this might include taking basic precautions such as testing changes in a chroot or development/testing environment, b…
Also, RedHat didn't ship with (relatively) much software (install everything was an option). Now you've got to configure; make; make install. Now you've got two parallel installations of libraries and software.
Oh. And the RPM database would die periodically (rpm anything would hang), requiring a reinstallation.
Since moving to Debian over a decade ago, I think I had to configure; make; make install something only once (it was an old and unmaintained Java library on SF.net). Almost everything (open source) is in the Repos.
Red Hat or the Microsoft of Linux is the face palm of linux distros, forget dependency hell, how on earth someone choose rpm over first class Superior Debian package system or distros like Ubuntu? People just buy it for the support even if the Red Hat they use is Gnome 2 and Firefox V.3.0. Then finally RHCA/RHCE courses, i should get certified from this distro to prove my Linux skills for the companies even though i…
What is so great about RH? When i had opportunity to use it, it look so bad mostly because lack of current/decent software in repo. Maybe their support is amazing?
In the Enterprise world, we typically don't want latest and greatest. We want stability for a long time. :)
Many enterprises want up to date and stable software, and since you are paying for stability, why shouldn't you get fairly recent and stable software
Most companies for example don't consider MS SQL 2016 as less stable than MS SQL 2008 or 2012, most users expect the same level of stability from the latest SQL Server than from earlier version, if not more because it's newer and more advanced, might as well be more stable
I didnt use RedHat in a while, so I dont know how bad the situation is , I hope it is not too bad
Earlier quoted context omitted.
Before yum and dnf, dependency hell is a serious issue indeed. After that it's still a problem if you use multilib (sometimes updates get pushed for x86_64 but the i686 packages are missing) but I wouldn't really call it a dependency hell anymore.
Seriously. Weekend long marathons of dependency chasing (in the snow, uphill both ways) to finally get config/make/make install to run were not only a thing but disturbingly commonplace. These kids don't know how good they've got it. God I feel old.
1) Identify a really interesting piece of software, like OpenFOAM, with (unbeknownst to me) lots of dependencies
2) Take a half hour walk to the local library with my shiny 4gb flash drive (89 dollars, a Christmas present to myself).
3) Download the .tar.gz of the software.
4) Walk home.
5) Unpack the .tar.gz and run ./configure. Watch it fail.
6) Walk back to the library to download the missing dependency. Walk home.
7) Goto 5.
I ended up very irritated that configure always fails on the first missing dependency, instead of comprehensively listing the missing requirements in one go. Things did get a bit easier when I learned to scour the documention for any libraries referenced, but of course reading the docs still often required a trip back home to unpack the tarball...
Earlier quoted context omitted.
Yes, support and peace of mind. Packages that make it into their repository are fully tested and supported by RH. Almost all of them are old but they are pretty much guaranteed stable and Red Hat will support the software until the EOL of whichever RH version you are running, even if the developers of the package do not support a version of the package anymore.
Sometimes being old is a double edged sword. For instance, RHEL7 has a lot of problems on AWS because the kernel is too old to properly support many of the virtualisation features AWS provides. On bare metal RHEL7 is great, though.
Disclaimer, I happily work for RH and today's blog has me ear-to-ear grinning.
Red Hat was primary reason it took me a lot longer to adopt Linux than it should have. Headbanging experiences with dependency hell and things not working as expected left me extremely discouraged. It wasn't until I dabbled a little with Solaris 7 and finally found Slackware that I realized that Linux could "just work". IMO Red Hat's success was primarily based on the critical mass of support behind it, not because i…
May be true, but they're given so much distribution independent code back, that I'm really glad they made it. It even seems that they contribute more to desktop Linux (GNOME, PulseAudio, systemd, kernel devs etc.), than Canonical does, (they seem to focus on Ubuntu-specific solutions mostly), which is pretty neat for a server vendor.