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:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Tue, 11 Jul 2017 10:38:10 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
On Sun, Jul 09, 2017 at 12:03:02AM -0700, 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?

You could create a mongrel el6 system with a newer glibc, but surely
there will be bad side effects, some programs will not run
or will misbehave. Still worth a try, you may get lucky.

As first step, I would replace the stock libc.so with your new special one
and see if the system can boot, then dance from there.

As step zero, I would setup a network-bootable system with NFS-Root,
as it is much simpler to tweak the mongrel userland on the NFS server,
then reboot; as opposed to rebooting the physical machine between
the mongrel os (does not boot, crash) and the stock OS to deit the mongrel image.


> 
> I know sci 7 has 2.17
>

But el7 glibc is old hat, too, if you want new, go Ubuntu.

el6: 2.12
el7: 2.17
ubuntu 16.10: 2.24
ubuntu 17.10: 2.24
current: 2.25

>
> systemd is completely unacceptable.
> 

I, too, expected the world to end when el7 went with systemd,
but it turned out to be more a wimper than a bang:

a) systemd is better documented compared to the el6 mongrel mix of SysV and upstart (el5 was pure SysV was much better)
b) everything works pretty much as expected and as documented
c) syslog works same as before, I can ignore the "this is simpler than grep /var/log/messages" journalcrl crud.
d) even on a small machine like RaspberryPi3, systemd does not seem to be any bother, no resource hog.
e) of course I do not use any "advanced" systemd functions, no "systemd dns", no "systemd boot", etc.

One big downside is "too many binary blobs" that cannot be trivially hacked
for special situations.

For example, I was never was able to convince systemd to boot in the presense
of a degraded BTRFS filesystem. One of the binary blobs "did not want to do it",
waited forever for who knows what and that was it. If it all were shell scripts, it would
have been a 5 minute hatchet job to get past this problem.

And this brings the bigger problem with the current state of Linux,
the development is dominated by strange people. On the systemd side we have
the guy saying "posix rules for valid user names do not apply, I set
my own rules" (if you read a recent discussion); on the BTRFS side say "but you should
never have degraded raid sets" (arguments about "but I cannot undegrade my BTRFS filesystem,
one disk is dead, gone, kaput" get no traction). And when there is a bad interaction
between the two, they just point fingers at each other, write copious bug reports,
nothing gets done.

Luckily some people want to have nothing to do with all this, so
watch the systemd-free fork of Debian, watch the BSDs and watch the direction
of "embedded linux" (people who build IoT machines count every byte of ram,
every milliwatt of power love systemd? yea, right).


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2