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?