Personally, I don’t have any problems with systemd. Admittedly I haven’t completely mastered all of it either, yet. I suppose “Go with the flow” might be a good motto here as almost all distro’s have switched to systemd.
As I mistakenly brought this up in another section of the forum, it's a somewhat unfortunate truth that systemd has migrated to a basic requirement. Diverging from systemd means completely breaking off from the standard/future Debian updates & it likely not worth it from that perspective.
IMO we should stay with init,
also the dependent display servers are changing, so there is more trouble than good.
Am running both on my machines here and therefor I think that Systemd is something that Elive
should not deal with now.
Previously, extensive testing should precede a possible change, which Elive can not afford at the moment. = Result:
I'm not sure what you mean by that. What apt commands?
FWIW methinks systemd is a potential behemoth if it continues like it does now.
It potentially could become as big or even bigger than the kernel and a necessity to even run the kernel.
As to complexity I'm not to sure, I've just not needed it a lot (yet) and am used to init scripts.
Debian says in short:
*" Systemd is a system and service manager for Linux. It is the default init system for Debian since Jessie. Systemd is compatible with SysV and LSB init scripts. * It can work as a drop-in replacement for sysvinit. Systemd"
But e.g.:
$ ifconfig is on systemd
$ ip address
And: "Are you still using one of the following tools?
/bin/netstat (replaced by ss, for which I’ll dedicate another blog post entirely) /sbin/ifconfig /sbin/ipmaddr (replaced by ip maddress) /sbin/iptunnel /sbin/mii-tool (ethtool should appropriately replace it) /sbin/nameif /sbin/plipconfig /sbin/rarp /sbin/route /sbin/slattach If so and there is just no alternative to using them that comes from iproute2."
Sure.
It needs to support a wide range of new hardware like multi core processors and GPUs
which init (usually using a monolithic kernel) can not afford nowadays.
Probably the main reason for leaving init behind, I guess.
and thus risking a to become a monolithic extra layer on top of the kernel or a crude drop-in replacement for a more modular kernel.
Anyway, we don't have that much choice in the long run, do we?
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....
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
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
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!
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"
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.
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
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.
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
= 
Result: 
