Systemd VS Sysvinit

aahmmm, let me think for a moment......
:sniff::sleep::studying::sniff::wow:

No. :open_mouth:

You're a fast thinker, sir. :smiley14:

2 Likes

To get back to the topic from the top -

means the 32bit edition should stay with init and a well equiped mono kernel
but for the 64bit edition should be targeted systemd
this must be done anyway because Debian will not develop or support the other
services for 64bit anymore (not officially).
The only good thing is that it's under the hood then anyway.

In other words:
Thanatermesis has to rip his ass off - for
to maintain the 32-bit edition
annnnd
bring the 64bit edition to life
plus
to maintain the 64bit edition

OK, obviously we need a better challenge for him,
otherwise am afraid he gets bored with this small challenges too soon....
:coding::coding::coding::coding::coding::coding::coding::coding::coding::coding::coding::coding:
:typing::work::typing::work::work::work::work::typing::typing: :laugh:

2 Likes

The integration / support is harder since more and more applications depends on it (or stops depending of sysvinit), but to still support it is possible, but it should be done specially from debian, I mean, they should be interested on keep this compatibility, I'm pretty sure there's a good amount of people that wants that

After that point being said, Elive could try to do 'what is possible' to have it as an option, and with a bit of luck we could select this option in the installation, from the installer is something very good since then, Elive can work in both systemd & sysvinit modes, satisfying everybody needs :slight_smile:

lol

@triantares @Rebel450 actually a funny (nope, not funny) thing about systemd is that you cannot "ping" as a user, for me it is really annoying to prepend "sudo" everytime i need to ping a machine, and I don't know yet how to make this working (is ping really an insecurity thing to be run from the users? hum, i think that if this insecure, the problem is in another place!), and in a curious way, the user from the Live mode can use ping

Well, the biggest problem of systemd is that "it wants to be everything", a replacement to controlling and managing everything... and this can sounds good, but is bad, we are losing modularity, the ram usage is bigger, the security issues are much increased giving all the control & power to that, and it's simply against the unix philosophy (which made linux* and new apple* so good)

32bit is a good reason to still use sysvinit instead of systemd, but in any case it doesn't matter if you can just select which one to use from the installer :slight_smile:

Actually I just tested to replace systemd by sysvinit, and the result is that to reach that, these packages will be removed:

  • ligthdm: our used login manager, pretty annoying to not being able to have it!
  • network-manager: since it can be replaced by 'wicd' is not a major problem, but we will lack extra features
  • gdebi: tool to install debian packages from user (like opening them in the filemanager)
  • dbus-user-session: it can be a major problem (functionality removed on desktops)
  • policykit, udisks2, gvfs: major problems, features removed for desktop and filesystems management
  • synaptic: the graphical package manager (can be used an alternative)

Conclusion: mmh, pretty hard to remove it, unless we want to have these things removed! :sniff: :disbelief:

BTW to install sysvinit is better to check this https://devuan.org/ , they already works for make debian being sysvinit, maybe we can just add the repos and install a few modified packages, the actual status for buster says "in development"

well documented debate about the topic for debian: Debate/initsystem/sysvinit - Debian Wiki

1 Like

Strange thing is that Ububtu 18.04 allows the user to "ping" (and ifconfig) without prepending "sudo", as IMO it should. "ifconfig"does require installing net-tools tho.
I've got a few apps and scripts that rely on a ping first to check for connectivity. :thinking:

It "feels" to Windowsy, I agree and alas, I think Linux is slowly but surely heading down that path up to the point that hopefully a new contender will arise. Already made a mental note to go BSD or QubesOs if need be or ........ Elive3.0.x :idea:

Stay with Xenial better.
And not on Ubuntu's DE - better chose a nice distro that you like.
Forget Bionic, they are not finished yet...

:omfg:

We would need to know how it is configured, for example the value of $PATH (to access ifconfig, where it is located?: 'which ifconfig'), and the sudo configurations, and ls -la to the executables

That's thing, it's /sbin/ifconfig and set as world executable, both are 100755 can't actually see any difference. :thinking:
antares@antares-ThinkPad-X1:~$ ls -la /sbin/ifconfig
-rwxr-xr-x 1 root root 78960 jan 10 2017 /sbin/ifconfig

there's the extra line for the admin group in sudoers that does the trick, methinks:
%admin ALL=(ALL) ALL

mmh, not very clear for me, if im not wrong this setting should ask for password, and maybe it still needs to be prepended by "sudo", the way to not ask for password should be something like:

thana ALL=NOPASSWD: ALL

is there more files in /etc/sudoers.d/ ?

what about "alias | grep ping" ?

It could be some complex configuration by the new systemd / policies stuff that sets permissions

[quote="Thanatermesis, post:19, topic:959"]
is there more files in /etc/sudoers.d/ ?

Nope, only the compulsory README.

what about "alias | grep ping" ?

Nothing there, no ifconfig either.

Mmh, maybe you found something from:

cd /etc ; grep -Rne ping

But this will probably give you a lot of matches :slight_smile:

Too many indeed, but "ifconfig" is not too bad and shows the solution:

avahi/avahi-autoipd.action:60:elif [ -x /bin/ifconfig -o -x /sbin/ifconfig ] ; then
avahi/avahi-autoipd.action:62: # We have the old ifconfig tool
avahi/avahi-autoipd.action:66: ifconfig "$2:avahi" inet "$3" netmask 255.255.0.0 broadcast 169.254.255.255 up
avahi/avahi-autoipd.action:72: ifconfig "$2:avahi" down

seems like this makes it working back:

sudo dpkg-reconfigure iputils-ping

Improving the installer to automatically fix the ping thing (when you'll install, it will be updated and then your installed system should have it working)

1 Like

Any idea why that works?
Or better said: Why the initial configuration didn't?

read the install script (called when reconfigure):

 /var/lib/dpkg/info/iputils-ping.postinst

Seems like it adds the missing configuration (setcap), but I don't know why its not done by default, maybe because something in the system changed (when installed) and then the setcap validation was removed (no idea how setcap works atm), which required to set it again. For example, the ssh keys of the host machine are newly generated on install, it would be insecure to use the same keys as the live mode (but even these, are regenerated on boot time), so who knows...

Note: after to grep for other "setcap" calls, I have added a few other packages in the installer to be reconfigured just in case they needs the new setcap setting :slight_smile:

Systemd and pulseaudio can due to wrong design consume alot of cpu and memory resurses.

Best way to solve this, specially for embedded systems is to remove then or shorten then out.

I have used many other Linux and -BSD system and there specially for Linux (latest CentOS7 or RedHat) systemd and pulseaudio has misbehaved in normal, suspend or hibernate or from resume, even from power up. It's not normal action to loop forever and consume too much cpu resources as the do today if wrong configuration. This can kill any embedded with battery support. Best solution is to do as MX linux (wrapper around) or better AntiX Linux (removed) do today. Then this wrong behavior is also removed. Previous versions of Elive did not used systemd or pulseaudio. There are also problems with pulseaudio usage with increased latency dependent of audio source, my audio mixing software also misbehave and results will be trash.

Firefox has also made wrong decisions about using pulseaudio due to its DRM requirement.
As I wrote, MX linux and AntiX linux had made a solution around this.

Debian and many other distribution make a wrong decision when the integrate pulseaudio and systemd, most due to other ie Gnome took wrong way due to they are not engineer for embedded targets.

Now many distributions leaves embedded market behind, consider that smartphones are embedded targets with limited battery usages.

3 Likes

Exactly

Thanks, I will need to do some research and tests in MX linux and AntiX to see how / what they did :slight_smile:

Actually Elive has been fully integrated to not use / depend on pulseaudio in the 3.0 stable version, but entirely Alsa (without the need of pulseaudio), this means that in the theory, you can remove pulseaudio and everything should still work (except e16 sound themes which uses pulseaudio, and skype if you use it)

Systemd is more complicated to remove, debian buster depends more on it, in fact it will remove thunar and network-manager, so will be needed to use alternatives then

You (or anybody) can experiment with these things and do some tests, like resources usage, by removing them :slight_smile:

I have did a small experiment in a virtual machine and removed systemd, the OS can run with "wicd" (instead of network-manager) and with "slim" instead of lightdm (login-manager)

In a 32-bit based system, the memory usage is reduced to only consume between 100 and 150 MB (depends of if you use the dock, etc...), similar optimizations can be obtained by removing eventually pulseaudio

By other side you cannot shutdown / reboot from desktop anymore, the login manager doesn't has these options too, and probably you could encounter more issues...

It's just an experiment for now, but maybe in the future we could have the option to remove it entirely from our systems :thinking:

2 Likes