On 7/12/17 5:20 AM, David Sommerseth wrote:
On 09/07/17 09:03, Bruce Ferrell wrote:
OK, before the flames start I KNOW it's not normal.
Has anyone have a method to upgrade glibc beyond 2.12?
Upgrading core system libraries, such as glibc usually requires a full
rebuild of all applications. Which then results in a brand new
distribution. An alternative is to "side-load" such libraries into an
/opt or /usr/local directory ... but that adds plenty of other
head-aches ensuring the software you want to use the newer glibc needs
proper library paths. In short, it's not worth the headache.
The least path of resistance is probably to do a 'yum install
--installroot' with a different set of yum .repo files from a newer
distro. Then you just chroot into the installroot and run your
applications from there.
I know sci 7 has 2.17, and except for the fact of it also having systemd
I'd consider a full on upgrade, but systemd is completely unacceptable.
Fighting against systemd these days will just make you an even more
miserable person in the coming years. Systemd have been adopted into
most actively and large Linux distributions. I used to be a systemd
sceptic, but I have converted and nowadays I am much more annoyed by how
upstart lacks features. Systemd isn't standing in my way any more. But
it took a bit of effort to learn the new tools and how it works; it is a
different way to solve system management.
So if you loathe and dislike systemd so much and rejects learning it,
FreeBSD is probably a far better choice these days - with the challenges
that brings along.
David,
I learned it and learned to dislike it even more in that learning.
After five years of dealing with it I'm still bumping into broken stuff
that is met with
"why do you want to do that?" for things that worked before, instead of
fixing the flaw.
The assumption that I either didn't bother or can't learn it is a bit
condescending...
Just as the previous response I mentioned is and THAT is the heart of
the problem with systemd.
Code is just code.
Inflexibility and inability to acknowledge that the kewl, shiny, new
idea breaks in places the "old, crufty" solution didn't is a core problem.
I see in another response to you, yet another "corner case" as it's
likely to be characterized... It worked before systemd and now,
doesn't. Not cool.
For me, it has introduced NEW problems and made it difficult to
troubleshoot them, broken working configurations, and given me no new
useful functions.
Everybody else is doing it, isn't really a good answer to that. When
this all started, "everybody else" was running DOS, Windows and/or
OS/2... That answer wasn't acceptable then either. Please explain why
should it be now?
