SCIENTIFIC-LINUX-USERS Archives

January 2021

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:
Mon, 25 Jan 2021 15:50:59 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
On Mon, Jan 25, 2021 at 11:31:08PM +0000, Miles ONeal wrote:
> 
> | For me, the issues are not policital, but technical:
> 
> Agreed. One of mine is that the surety of being able to drop a lower runlevel and back up is gone. ...
>


If you ask me, systemd was designed and built to solve one and only one problem,
boot it's author's personal 1 core 300 MHz laptop as fast as possible. Today,
with 4 core 3000 MHz laptops and 16 core 4000 MHz "servers", many features
of systemd look quaint. ("waiting for USB devices to settle", really?).

Benchmarks that report "old" and "slow" SysV initscripts boot as fast as systemd
tend to support this viewpoint.

Each time I look at the systemd boot sequence trace, I see things like
"waiting 10 sec for disks that are not needed for booting" and
"waiting 10 sec for network not needed for booting". If unlucky, also see
"waiting forever for disk that failed and was removed" (hello, booting from degraded btrfs raid array).

How this stuff got into "E" linux and why paying customers put up with this,
is a mystery to me. Perhaps said paying customers "never reboot" and never
see systemd shortcomings (and get no benefit from "systemd fast booting").


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