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.