On 07/12/2017 04:49 PM, David Sommerseth wrote:
On 12/07/17 18:12, Bruce Ferrell wrote:
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...
My experience with others having issues is that they expect systemd to
behave like upstart or Sys-V init script. Systemd is different. It
needs a different mindset. And my experience going all back to
Slackware 3.4, via lots of various distributions since that time to
todays Fedora and RHEL (including clones) have taught me the hard way
that these old approaches are mostly horrific when considering today's
scenarios and challenges, not to forget what new hardware introduces of
dependencies and expectations. This goes for both server and client side.
My first Slackware was 0.99 on a 386 and 256M of RAM and a 100M SCSI hard drive
on an adaptec controller
Slackware 3 was a HUGE step forward. It had a mixed init system, using a both
BSD and SYS-V
Just as the previous response I mentioned is and THAT is the heart of
the problem with systemd.
Code is just code.
That's too simplistic. Because the code runs within in a specific
environment with a specific set of dependencies. If you have code
running which have no dependencies on other libraries (libc included),
then you can practically talk about code being just code - but it still
have a dependency then on the kernel.
To be strictly correct on the "code is just code" statement, the code
would need to run directly on the CPU, not being affected by any type of
external code running on the hardware. Since this is practically close
to impossible to achieve on general purpose systems, you do need to have
some OS dependencies.
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 don't like systemd because it is "kewl, shiny, [with] new ideas". I
like it because it makes my sysadmin tasks generally far easier. It
gives me easier control of services and managing the system. I more
easily spot when something is not running correctly. Yes, you could do
that before the systemd days too, by adding additional dependencies
which would monitor and act upon events. For me, systemd resolves those
challenges far more elegant with less efforts to debug when things go
wrong. And the documentation is just superior to what I've had to dive
through
I have also "fought" against systemd earlier on (even initiated an
internal flame war involving Lennart Poetering with the subject "systemd
- one daemon to rule them all?"). But I got my facts and misconceptions
set straight, then I got some good experience and started to understand
systemd better. Since then, systemd works best for my systems.
But YMMV.
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.
No, it's not cool. But to be fair, you haven't exactly explained how or
why things breaks with systemd - just stating you don't like it. With
that as a starting point, it is really hard to tell what the issues are.
You've just told that you want a far newer glibc to run your
application, but I don't see why systemd is causing in that perspective
issue here.
OK, directly connected, they aren't. However, someone suggested to get the glibc, maybe SL7 might be an answer. Because my experiences with systemd, that's a non-starter. The
specifics of those experiences aren't important.
One that I had was an update upgraded dbus... That caused systemd to decide that because it lost communication to dbus, to unexpectedly reboot the system. To be fair, I'm not
certain it wholly a systemd issue... It MIGHT have been the way the distro set it up. Again, never a problem under other init systems.
Now, to move onto a really current issue.
By now, I'm certain we've all seen it: *User=0day considered harmful in systemd. Is it a bug? I'd certainly say so however Mr *Poetering adamantly says not... In spite
systemd being caught improperly deciding to run processes as root instead of the intended user.
Bugs happen. We all know that and accept them just so they get fixed. When developers start doing Pee Wee Herman impressions ("I meant to do that!!!") to the detriment of systems
management and creating a monstrous vulnerabilities... If you say that makes your job easier... I'm not sure what to say.
For me, it has introduced NEW problems and made it difficult to
troubleshoot them, broken working configurations, and given me no new
useful functions.
I am _not_ saying systemd is perfect and without flaws. Not at all!
I'm just saying that my experience is that it works far better than any
other init and basic system management tools I've used over the last 20
years. And my experience since the early EL7 days and Fedora 19+ days
are that if things which worked under Sys-V/upstart doesn't work with
systemd, it may very much likely be that systemd is not utilized
correctly. Systemd is a paradigm shift within the Linux world. It
requires a different mindset.
First, systemd *may* be a change in the LInux world, but in the larger world,
it *looks* a lot like launchd on OS X.
As to mindset shifts, It sure is. From my perspective that shift is "I know better than everyone else who has ever done this and I'm going to force this through come hell or high
water".
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?
>From my experience, having used OS/2, I did find that being a far more
reliable OS than DOS and Win95 ever was - but again YMMV. Regardless,
there's something called market share and market control too. The
history is full of a better XYZ solution which lost over a far worse
ZWQ solution.
I took care of a couple hundred OS/2 desktops and OS/2 LAN-Server in the mid 90's. They "replaced DOS6 and Windows 3.11. Initially, I kept a box of 3.5 inch floppies at my desk
to do re-installs for the desktops... About 10 a week and well over an hour per. But OS/2 was supposed to be the big savior and make my job easier. In this environment, the
workstations has a nasty habit of doing a thing I called "Swallowing the desktop"... All the icons would swirl to the center and disappear with no way to recover except to
re-install. For whatever reason, when it happened, three or four would do it all at once. This would cause the floor manager to call me over urgently as these people had to be
working and we had no "spare" systems to drop in.. that's how things ran back then. This was an issue I'd NEVER had with DOS/Windows and I ran a quad networking stack; IPX/SPX,
DEC-Net, SNA and raw netbios (aka netbuei).... Not netbios over TCP.
Then I went to LAN Server training where they taught network installs... And the fact that if you did from LAN Server, if you had better dedicate more than one server if you needed
more that two installs at a time. If you had a Novell server available, you could do ten. Fortunately for me, I had "legacy" Novell 3.12 servers available to me so I was able to
put that box of floppies away.
OS/2 went away, so did Novell... Now what do we have? Yes, modern Windows is somewhat more stable and Linux is starting to resemble Windows. Improvement, I think not. As you
say, YMMV.
> Life moves on regardless of what individuals prefers. If you can't get
> enough influence to change the direction early enough, you will sooner
> or later be forced to follow along - regardless of your opinion.
And change for change's sake is bad, and sometimes bad change needs to be
resisted vigorously.
