SCIENTIFIC-LINUX-USERS Archives

July 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Thu, 13 Jul 2017 01:49:24 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (135 lines)
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.

> 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.

> 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.

> 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.

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.


-- 
kind regards,

David Sommerseth

ATOM RSS1 RSS2