Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Um, so... systemd?



Odd,  I've source packaged systemd as a second init side by side with simpleinit and spent less than 5 hours going from blank slate to a bootable minimal installation of systemd that I then proceeded to use with original init scripts as fallback.

The only issue I had was when I needed to set linear precedence of scripted operations.
as they usually began running in parallel which meant merging the scripts into something a bit monstrous.
it was easier to custom write systemd units modified from a template for me at least.

And all this was my first foray into dealing with init.

I've also been considering to do it again to build a custom stripped down virtual machine core for a minimal "systemd + python" only setup just to test a theory I have.

Would anyone find that useful?


On 17/01/2017 12:15 PM, "Kalin KOZHUHAROV" <me.kalin@example.com> wrote:
So far I avoid systemd as far as possible. I spent quite some time
reading about it when it first came out (and after something broke,
IIRR), then have read occasionally not only discussions but HOWTOs and
people who like it talking about it.

I put it in one basket with a bunch of other complex middlewarez (in
the middle of nowhere, trying to interface) that got introduced a few
(10?) years ago in a way to "smarten" the linux experience and
windoze-it more (for the lack of better wording), to make systems
behave "automagically". It may have started with udev (which I came to
terms with since it went in kernel).

Some people said debugging init.d problems is hard. Really? Then your
scrips (i.e. whoever wrote those init.d scripts) was not a good
developer, didn't document it, didn't make it debuggable. They use
"shell hacks"? Same problem. journald... yeah, logging is important!
But we had STDOUT (/proc/self/fd/0) since the beginning of time and
you can redirect it to anywhere since boot, even over the whole
Internet if you like.

"Fast booting", LoL! In 2017? On a bunch of VMs running who knows
where? Yes it was somewhat important when I had to boot RH5 on a
Pentuim 90MHz and 20GB ATA drive. May be. If you want fast boot, just
don't boot - start from booted state, rsync booted images (RAM
snapshots). And for your laptop/desktop? The longest is usually the
network/dhcp/wifi and it blocks many services anyway, so running in
parallel is not possible (yes, you can background those in any number
of ways, so you can type your (local) password before the network is
up, but only in the case of not needing to do a remote authentication
:-)

So, to sum up, it tries to solve a bunch of non-problems by
introducing new concepts in a fancy wrap-up, at the core of the OS and
set a new "standard". I don't know, really. I'll spend some more time
reading again, but the fact that I have spend already at least 20+
hours reading about it, 20+ hours trying to make it work/debug (for
clients) and I still don't remember what are its good sides bothers
me. (for those who don't know me, I work in incident response/digital
forensics/security, use exclusively Gentoo for 15+ years and spend an
average of 4h/day doing it for the last 16+ years).

Cheers,
Kalin.

--
To unsubscribe from this mailing list,
please see the instructions at http://lists.tlug.jp/list.html

The TLUG mailing list is hosted by ASAHI Net, provider of mobile and
fixed broadband Internet services to individuals and corporations.
Visit ASAHI Net's English-language Web page: http://asahi-net.jp/en/


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links