systemd discussion: agree to disagree

[axl]

and I have another post in me.

figuring out systemd was, for me, like figuring out open rc.

it's like the first time you meet someone. or some animal you are going to ride later. as we all know, it's nothing more satisfying than meeting a new untrained uncivilized undomesticated new beast and just subdue it to your will.

I love that. I'm pretty 99% sure you openrc die hard folk feel that way. a new beast to tame. have at it folks. have at it

Can either of you say that's not cool? have at it

[Naib]

So what is systemD trying to solve?

I mentioned this before... No, before going into what systemd is trying to solve, I want to say an anecdote. People can look it up on the forums. It happened like a month ago or so (bad memory with time - dont know when exactly).

Anyway. there was this thread... about systemd... and someone asked how to make systemd not reboot and finish a task before rebooting. That thread gave me pause. It was the right kind of thread/post/attitude/whatever. Made go look for man. documentation. 2 answers were in the end provided, which showed systemd CAN do that task. But man... when the question was asked... it was like: that's a hard question. Have to go look.

So what does systemd do?

Were gonna just not consider boot times and compatibility/overlays.

well, I often said and I'll say it again, binary logging. Might sound like a bad idea but it's freaking great. You get to do things like journalctl --list-boots and journalctl --boot #no.

Also the unified (finally) service manager (Are you guys gonna start with me?) systemctl.

and... this will be controversial... systemd IS controversial. and that is something that linux always had.

OK:) you can obviously ignore point 3. and point 1&2 could be easily interpreted as linux going windows way.

But I will ask again. HOW is systemd even remotely like windows. it's not. I can go into systemd sources and fark up my system. I cannot go into svchost.exe to... nothing. Truth be told I'm comfortable in either openrc or systemd environment. I loose myself and hate being in windows. It's just... no. dont like being there.

If I got the slightest whif of windows from systemd... i wouldn't have been using it.


PS. I know I mentioned point 1 & 2 before. but go lookup linux and gentoo linux on youtube. those 2 points make for a common vocabulary. not for you guru person reading. for new people. people who aren't old dogs like me & u.

"binary logs" that's just a buzzword, it doesn't actually state what problem it is solving and certainly doesn't mitigate the problems it brings and I know all too well the problems it brings... its like the old adage

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

you must fully understand the problem you are trying to solve to stand a chance of solving it concisely, without causing other problems.

What does binary logs solve? being able to query specific terms? but that is what grep can do EXCEPT this time round you are shackled to the interface exposed by the log interface... sometimes SOMETIMES being able to just less a log file and go line by line because you are unsure of what searchterm to use but you know something isn't right is worth its weight in gold "what is that?". You cannot do that with binary logs?

So what exactly do they bring? "easier" indexing? why couldn't this be achieved via the present syslog interface but a secondary sqlite file to provide events associated with line numbers? being able to then interrogate via some higher interface is viable but so is accessing the raw logs incase the system cannot boot.
tamperproof? blockchain aspects of the ancillary database and run a daemon to validate it periodically

so what exactly is systemd trying to solve, how does it expand use-cases and does it bring any regression in functionality?

[mv]

I'll say it again, binary logging. Might sound like a bad idea

It does not even sound bad, it is broken by concept from the very beginning, because it is exactly what logging should not be: It prevents easy access from an arbitrary remote system, it causes a complete loss of logs if certain problems occur, you lose the flexibility to edit the stored messages by a script and/or editor if you want that for whatever reason, ...

You get to do things like journalctl --list-boots and journalctl --boot #no.

There are a few options for administrators who are too incompetent to use grep and sed (or to write or copy from someone a tiny script for their purpose in their language of choice).
The price has to be paid by the harddisk and speed, because the competent administrators who want a non-broken logging need to setup this in addition to the broken binary logging they are forced to.

HOW is systemd even remotely like windows.

HOW can you ask this after you have given just a typical example?

I can go into systemd sources and fark up my system.

Non sequitur. Finding a similarity with one thing is unrelated to finding similarities with other things.
BTW, this similarity with free systems does not work in practice. For instance, trying to replace the broken binary logging concept by a sane logging only on the source-level is only theoretically possible but not in practice, because it would almost be a full-time job to keep the patches up-to-date. Actually, already even to keep any sane configuration up-to-date with the systemd-idiocy-of-the-week is already a full-time job.
Just as a simple example: In systemd-239 they now decided to remove the .include directive.
This shows the problems of the vendor lock-in: For an administrator this can mean to completely re-structure the logical basis of his configuration and file layout. For sane init systems (i.e. shell-based ones) such vendor lock-in can never happen, because shells do not suddenly remove commands. Even if a command would vanish, you could simply provide it externally.
Oh, you asked for similarities with windows. There you are...

[Morality124]

BTW, this similarity with free systems does not work in practice. For instance, trying to replace the broken binary logging concept by a sane logging only on the source-level is only theoretically possible but not in practice, because it would almost be a full-time job to keep the patches up-to-date. Actually, already even to keep any sane configuration up-to-date with the systemd-idiocy-of-the-week is already a full-time job...

Indeed, just take a look at what happened to a "minimized" fork of systemd, aka uselessd:

uselessd has entered the final stage of uselessness, its ultimate expression of nihilism - the state of deprecation and utter nonexistence. That's right - uselessd is dead.

The last release was uselessd-8 on November 16, 2014. An effort to revamp the IPC system away from D-Bus into using a byte stream-based fifodir protocol was staged for uselessd-9, but a growing lack of interest and realization that trying to mangle the systemd architecture into something more minimal was becoming increasingly fruitless and unwieldy lead to the project being orphaned. It was transferred to Tarnyko in January 2015, but no activity of any sort has been seen since then. For all practical purposes, it's over.

The author of uselessd has since been drafting plans and reading papers as part of a from-scratch design for a heterodox init system based on design principles from research OS and HPC that are uncommon to the Unix world. It will be released when it's done, which might take a while.

I remember all the talk of "well if you don't like systemd so much why not just make your own fork?", systemd being so "modular" etc. What a joke. When this was tried, the developer in question decides it is easier to make another init system from scratch.

[Anon-E-moose]

Trying to follow the original too closely will ALWAYS lead to grief and probably indigestion.

What needs to be done, is what do we take from the original (in the case of systemd)
1. Input criteria
2. How to handle the internals, reading service code, restarting, etc
3. End result, ie hand it over to system and go in background
How it handles things internally can be done in a clean way then.
Who cares if the original does it a certain way inside their code, quit chasing the donkey.
Decide what the criteria is and write to the criteria.

sysvinit works for what it does, if you want to emulate systemd then
modify something like openrc to handle service files (the systemd kind), handle starting/restarting the services, call yourself opensysd and go from there.

Logging, user logins, printing, etc are all different things and are not part of the init system proper.

As far as the login stuff, you care about 2 things
1. User credentials
2. The end point where you interface with gnome/kde/whatever, ie what do they expect, and give them that.
Everything in-between is up to the developer, who cares if it emulates the original twisted logic or not.

Just my thoughts on this.

[Dominique_71]

axl,

It’s fruitless to attempt to indoctrinate a superannuated canine with innovative manoeuvres.
and I'm one of those

More cynically, the functionality that systemd wants to replace has matured over 30 or 40 years. Some of it predates UNIX even.
When systemd reaches that level of maturity, maybe I'll give it a try, if I'm still around.

I fully agree. It is even more: I will never change a good working init system, even if it is not perfect, for an alpha stage software like systemd. Yes systemd is an alpha stage software, it is at least 2 reasons for it: 1) its constantly flowing bugs list, and 2) they are constantly removing, changing and adding new functionalities.

That can be great for corporations like RH, because they are sure to sell their services to infortunate users, but this will never convince me to use such a software. Also, 2) implies than to manage a systemd system, it is not just to learn it, but it is to learn it again and again and again. And seriously, I just have a lot of other and much more interesting things to do with my life, and time is sparse.

[axl]

It does not even sound bad, it is broken by concept from the very beginning, because it is exactly what logging should not be: It prevents easy access from an arbitrary remote system, it causes a complete loss of logs if certain problems occur, you lose the flexibility to edit the stored messages by a script and/or editor if you want that for whatever reason, ...

but in practice, systemd does both. or you could do both. could do one, or the other. there's a nice thing about storage systemd. you can set it to persist, or volatile, or none. and that's the 3 I remember. persist means keep binary logging through reboots. volatile means, you get binary logging, but, just the last reboot. none means... none. so in systemd you get you play how much binary logging you want, and on top of that, you get legacy log. with whatever log manager you want. what's wrong with that? how is this implementation wrong? All I see more choices. 3 for binary logging, and all the other old choices that were here before. simple math says it +3 more choices.

There are a few options for administrators who are too incompetent to use grep and sed (or to write or copy from someone a tiny script for their purpose in their language of choice).
The price has to be paid by the harddisk and speed, because the competent administrators who want a non-broken logging need to setup this in addition to the broken binary logging they are forced to.

did you read about the thick skin. yeah. I know how to use a pipe. can you for a second consider other people might be using this software that is not you or me? can anyone do that?

HOW can you ask this after you have given just a typical example?
Non sequitur. Finding a similarity with one thing is unrelated to finding similarities with other things.
BTW, this similarity with free systems does not work in practice. For instance, trying to replace the broken binary logging concept by a sane logging only on the source-level is only theoretically possible but not in practice, because it would almost be a full-time job to keep the patches up-to-date. Actually, already even to keep any sane configuration up-to-date with the systemd-idiocy-of-the-week is already a full-time job.
Just as a simple example: In systemd-239 they now decided to remove the .include directive.
This shows the problems of the vendor lock-in: For an administrator this can mean to completely re-structure the logical basis of his configuration and file layout. For sane init systems (i.e. shell-based ones) such vendor lock-in can never happen, because shells do not suddenly remove commands. Even if a command would vanish, you could simply provide it externally.
Oh, you asked for similarities with windows. There you are...

it's quite easy how i can say it. here, watch me do it again: systemd is an opensource software. svchost.exe i dont wtf is. need subtitles to that?

for the rest of your rant... i do need subtitles. no sure what exactly u're ranting about. people in openrc camp seem fine with the last few decades it took sysvinit to mature. and it's like ... no .. systemd doesn't deserve the same measure. it's not mature now, wasn't in 2013, will never be. kill it with fire.

remember. show me the source of svchost.exe. pls. context.


EDIT: THIS IS VERY SELFISH. AND STUPID.

you could say: hey man! I'm not gonna put systemd on my main servers. but here, this mercy system... i could invest in systemd. test it out. you know, pull my own weight. learn about it maybe.

yeah. that would make sense. remember, linux wasn't built on people just staying with the safe choice.

[axl]

What needs to be done

so take that list and get it done.

u're smart enough to know in the linux world, you want something done... u do it yourself. so.. do that.

[Anon-E-moose]

What needs to be done

so take that list and get it done.

u're smart enough to know in the linux world, you want something done... u do it yourself. so.. do that.

Save your trolling for someone else, I'm not impressed with your taking things out of context nor your "leet" speak.

[axl]

What needs to be done

so take that list and get it done.

u're smart enough to know in the linux world, you want something done... u do it yourself. so.. do that.

Save your trolling for someone else, I'm not impressed with your taking things out of context nor your "leet" speak.

come to the dark side and try systemd. no really man, if you invested this much energy in systemd... u wouldn't need this much energy.

just going against the current. up the stream we go... up the stream we try to go... up the stream ...

PS and why is this trolling? you say it's trolling. I don't feel like I'm trolling you. you want me to troll you?

[tld]

Save your trolling for someone else, I'm not impressed with your taking things out of context nor your "leet" speak.

While I understand how difficult it is to not let his BS go unchallenged, I sort of wich everyone would stop feeding this troll. His praise of systemd logging alone says all anyone needs to know about his lack of understanding, especially as to what has worked (text based logs) and what hasn't (cough...Windows event log) for the last half century.

Tom

[Jaglover]

Here is his picture.

[Yamakuzure]

axl, if you learned how to use the edit button, stopping your multi-posts, it wouldn't only be easier to ignore you, your trolling wouldn't at least be that unnerving.

tl;dr: Please just stop your attempts to proselytize us into using systemd.

I was almost on the verge of asking you whether you where a very young and inexperienced guy, then I noticed your registration date. So you are either a very young and inexperienced impostor of the true axl, or you went fully nuts over the years. And ignorant... very ignorant...

My patience is simply over. Sorry. Your statements are so wrong on so many levels, I do not know where to start. Just let me tell you, that maintaining elogind for over 18 months now left me with a lot of inside-out-knowledge of the systemd code basis.
So your propaganda only stirs one thing in me: The strong wish to tell you to stop blabbering about stuff you have no idea off.

It boils down to two simple propositions:

1. If you like to use systemd, just do so.
2. If someone else does not like to use systemd, just let them do so.

That's it, no magic involved, no mystery, nothing.

Remember: It isn't always shit just because you do not use it. And the reverse conclusion is, that is not always the one true thing everybody muist be urged into using, just because you like it.

Maybe you'd like to remember that "Someone Is Wrong On The Internet" is a valid reason for exactly nothing.
"The idea behind this meme is that people take Internet arguments too seriously and spend too much time trying to correct others online rather than spending time with their loved ones. However, there is another truth to the meme. The Internet is wrong.", Robert N Nash once wrote on hg.org.
I think he is right.

[axl]

ok. enjoy your ever growing overlay guys

[Naib]

ok. enjoy your ever growing overlay guys

what if I said I don't have an overlay and I don't use systemd

[John R. Graham]

Me either.

- John

[axl]

ok. enjoy your ever growing overlay guys

what if I said I don't have an overlay and I don't use systemd

Didn't they just say ... don't feed the troll? I'd love the conversation but... regardless how thick skin I am... some of the stuff said isn't very pleasant. and frankly I don't care about being right. The little I cared about fun is methodically being crushed. So yeah... Ima guess it's a minimal system without gui and with a highly complicated system of flags and masks in /etc/portage. or a different portage tree entirely. But that's just a guess for fun. Assuming the word is allowed.

[John R. Graham]

... Ima guess it's a minimal system without gui and with a highly complicated system of flags and masks in /etc/portage. or a different portage tree entirely. ...

Not in my case. Stable branch, standard Portage tree, running unpatched KDE/Plasma.

- John

[asturm]

@axl: So after all this it seems you are back to square one, of a completely uninformed opinion. That was time well spent...

[axl]

@axl: So after all this it seems you are back to square one, of a completely uninformed opinion. That was time well spent...

It's hard to get informed when some people have 18 months experience in something I never even heard of. Why would I?

[Naib]

ok. enjoy your ever growing overlay guys

what if I said I don't have an overlay and I don't use systemd

Didn't they just say ... don't feed the troll? I'd love the conversation but... regardless how thick skin I am... some of the stuff said isn't very pleasant. and frankly I don't care about being right. The little I cared about fun is methodically being crushed. So yeah... Ima guess it's a minimal system without gui and with a highly complicated system of flags and masks in /etc/portage. or a different portage tree entirely. But that's just a guess for fun. Assuming the word is allowed.

they are not me and I don't recall being unpleasant nor posting vitriolic statements.

likewise I do not have overly complex flags and masks in /etc/portage

Code: Select all

#cat /etc/portage/package.mask/*
=www-servers/tornado-5.0.2
=www-servers/tornado-5.1

These exist purely due to Jupyter

Code: Select all

# cat /etc/portage/package.use/user 
app-admin/conky apcupsd curl hddtemp iostats lua lua-cairo lua-imlib math moc mpd rss vim-synta weather-metar weather-xoap vim-syntax
app-portage/eix sqlite 
dev-lang/python sqlite tk doc
dev-libs/boost context
dev-python/irc examples
dev-python/matplotlib examples -gtk -gtk2 -wxwidgets tk latex
app-text/texlive-core xetex
dev-python/numpy lapack
dev-python/PyQt5 webkit network printsupport gui widgets
dev-python/spyder doc matplotlib numpy scipy sphinx
dev-qt/qtlockedfile qt5
dev-qt/qtmultimedia widgets
dev-qt/qtsingleapplication qt5
dev-vcs/git tk cgi
media-gfx/imagemagick postscript
media-libs/freetype static-libs cleartype_hinting 
media-libs/harfbuzz icu
media-video/ffmpeg dirac faac network rtmp v4l -samba vaapi theora vpx x264 openssl vdpau
media-video/vlc qt4 -svg -libnotify -xv lua vaapi  wma-fixed vlm mad egl omxil fontconfig matroska xv live httpd gnutls xcb postproc 
net-analyzer/scapy imagemagick pyx tcpreplay visual 
net-analyzer/wireshark qt4 -gtk2 -gtk3
net-fs/cifs-utils -caps caps-ng upcall ads
net-fs/samba swat winbind client -system-mitkrb5 -python
net-vpn/tor tor-hardening transparent-proxy
sci-electronics/kicad github webkit examples
sys-block/parted device-mapper
sys-boot/plymouth static-libs
sys-fs/eudev keymap hwdb
sys-kernel/dracut dracut_modules_plymouth
sys-kernel/gentoo-sources experimental
sys-libs/gpm static-libs
sys-libs/zlib static-libs minizip
virtual/ffmpeg vaapi theora
virtual/jpeg static-libs
virtual/postgresql server
www-plugins/adobe-flash vdpau 32bit
x11-base/xorg-server xvfb
x11-drivers/nvidia-drivers tools kms uvm
x11-misc/tint2 examples
x11-terms/rxvt-unicode 256-color fading-colors xft
x11-wm/openbox xdg
app-text/ghostscript-gpl cups
media-libs/libjpeg-turbo static-libs  -java
dev-qt/qtcore icu
dev-qt/qtwebkit printsupport
sys-apps/util-linux tty-helpers
app-crypt/pinentry -qt4
x11-libs/wxGTK tiff
#sys-devel/gcc graphite
sys-apps/lshw gtk
dev-lang/php fpm cgi curl gd imap mysql mysqli pdo zip json xcache apc zlib zip truetype -apache2
dev-libs/xmlsec nss
sys-libs/libcxx -libunwind 
sys-libs/libcxxabi -libunwind
media-video/mpv libmpv tools v4l vaapi vdpau 
dev-libs/libpcre2 pcre16
x11-misc/lightdm -gtk -introspection -qt4
media-libs/gst-plugins-bad egl
media-gfx/nomacs opencv

dev-qt/qtwebengine widgets
media-libs/libvpx svc
dev-qt/qtwebchannel qml
dev-qt/qt-creator designer
dev-libs/libxml2 icu
net-analyzer/nmap zenmap
media-video/vlc chromecast

media-gfx/feh curl
app-eselect/eselect-php fpm
media-libs/gd fontconfig

net-libs/zeromq drafts

I am not going to bother pasting my /etc/portage/package.use/py27 file

Code: Select all

 #cat /etc/portage/make.conf
AR="/usr/bin/gcc-ar" 
NM="/usr/bin/gcc-nm" 
RANLIB="/usr/bin/gcc-ranlib" 

#FLTO= "-flto=8"
#GRAPHITE="-fgraphite-identity -ftree-loop-distribution -floop-nest-optimize"

#CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native  -w ${FLTO} ${GRAPHITE}" #-march=znver1" #haswell" # -ggbd
CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -fno-lto -mindirect-branch=thunk"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,--as-needed -Wl,--hash-style=gnu"


MAKEOPTS="-j8"
CHOST="x86_64-pc-linux-gnu"
ACCEPT_KEYWORDS="~amd64"
EMERGE_DEFAULT_OPTS="--jobs 3"

PORTDIR="/usr/portage"
DISTDIR="${PORTDIR}/distfiles"
PKGDIR="${PORTDIR}/packages"

#PORTAGE_TMPDIR="..."
#BUILD_PREFIX=$PORTAGE_TMPDIR

USE="truetype type1 cleartype corefonts
aac -accessibility aiglx alsa -arts
bash-completion binddist branding -bluetooth
cairo cdr cleartype consolekit corefonts
-dbus dvd dvdr
-esd -eds evdev
-firefox ffmpeg
gegl gcc64 -gnome graphite gstreamer gtk2 gtk3
-hal
imlib introspection
java jpeg
-kde
-libav libnotify -ldap lto
mp3
nsplugin nptl nptlonly
opengl oss
pdf pgo png policykit python pulseaudio
-qt -qt3 qt4 qt5 -qt3support
samba smbclient spell svg -systemd
threads truetype type1
unicode usb
webkit
X xcb xulrunner"

LINGUAS="en en_GB uk"
L10N="en en-GB"
LANGUAGE="44"
INPUT_DEVICES="keyboard mouse evdev"
VIDEO_CARDS="nvidia vesa"
FEATURES="sandbox -ccache parallel-fetch metadata-transfer"

ABI_X86="64 32"
CPU_FLAGS_X86="f16c mmx mmxext popcnt sse sse2 sse3 sse4a ssse" # Ryzen specific

GRUB_PLATFORMS="efi-64"
CURL_SSL="gnutls"

RUBY_TARGETS="ruby23 ruby24 ruby25"


PYTHON_TARGETS="python3_6"
PYTHON_SINGLE_TARGET="python3_6" 
USE_PYTHON="3.6"


GENTOO_MIRRORS="..."

[axl]

... Ima guess it's a minimal system without gui and with a highly complicated system of flags and masks in /etc/portage. or a different portage tree entirely. ...

Not in my case. Stable branch, standard Portage tree, running unpatched KDE/Plasma.

- John

I don't know if you believe me but the only experience I have with anything even remotely Kde-ish is some CDE on AIX 4.2. So... frankly I have no idea how systemd and kde interact with each other. NONE. But good for you

[NeddySeagoon]

axl,

Everyone is doing it wrong except me. :)
I use an Old Fashioned Gentoo Install

It boots much faster than systemd too, not that boot speed was ever a selling point on systems that are never rebooted.

[axl]

axl,

Everyone is doing it wrong except me.
I use an Old Fashioned Gentoo Install

It boots much faster than systemd too, not that boot speed was ever a selling point on systems that are never rebooted.

thanks neddy. I'll give it a read.

Also, can I say? I have some machines, that regardless what init system u use, they still take 5 minutes to boot. damn bios takes around 4:30 to finish post. and yeah... those are the machines that you NEVER want to reboot.

[axl]

they are not me and I don't recall being unpleasant nor posting vitriolic statements.

Yes. Thank you.

likewise I do not have overly complex flags and masks in /etc/portage

By a n00b standards is a lot. It's complicated. What would happen if you delete your package.use by accident?:)

Now really think about that. How long would it take to figure out all the individual useflags again?