Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
The future with Systemd
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: The future with Systemd
The article was discussed on HN as well. The HNers were not terribly impressedgolinux wrote:This posted on the debian-user list under the subject "embrace, extend, extinguish". The future looks bleak . . .
https://news.ycombinator.com/item?id=8251288
Don't worry about The Future, it has a way of sorting itself out. Work out Jessie then start working what options are available on the Sid after Jessie.
-
- Posts: 459
- Joined: 2012-02-24 18:36
Re: The future with Systemd
you would need to emulate systemd if running software that requires systemd and you are not wanting to use systemdedbarx wrote:...one must find a way to emulate systemd
whereas if you currently use software that doesnt require systemd, and it doesnt require it in the future, that software should continue to be usable with sysv init
and in those cases apt-get should work to do the switcheroo assuming sysv is packaged in the future and I suspect it will be for a while
Re: The future with Systemd
My post makes sense only when one considers the fact that programs are essentially a collection of interelated subroutines. These need not reside in the same executable module. Therefore, considering a program requiring systemd subroutine X, that program must somehow interface with that routine, meaning it must somehow find it somewhere. The latter is the reason for emulation. However, emulation wouldn't go as far as replacing the init system. It would only impose an additional layer to act as an interface for init to appear like systemd.adenukolnis wrote:you would need to emulate systemd if running software that requires systemd and you are not wanting to use systemdedbarx wrote:...one must find a way to emulate systemd
While I am all ears to listen to all valid criticism about this, I think, it avoids having to modify all software that uses systemd.
Since this is a discussion forum, I am not posting how I will get rid of systemd, but I am proposing ideas as to how it can be done. Yes, I am ready to offer my time developing an interface, but that is a task not to be done by one person alone and it needs more expertise than I currently have. I wrote C++ code in the near past and it was assessed by a university academic as excellent. So, hopefully, I can offer a hand, and definitely, it will be a pleasure to pay back for the good service GNU/Linux software has given to me.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
-
- Posts: 459
- Joined: 2012-02-24 18:36
Re: The future with Systemd
Yea its called a shim - https://packages.debian.org/jessie/systemd-shimedbarx wrote:It would only impose an additional layer to act as an interface for init to appear like systemd.
I did, I will avoid any software that requires systemd and should the base system include it I will use apt-get to replace it with sysv.I am not posting how I will get rid of systemd,
Re: The future with Systemd
Anyone can continue to use apt-get, my preferred package manager, to get rid of systemd at present and until Jessie goes Old Stable, but it is not guaranteed by the Debian DDs that such a possibility will continue to exist beyond that point.adenukolnis wrote:I did, I will avoid any software that requires systemd and should the base system include it I will use apt-get to replace it with sysv.edbarx wrote:I am not posting how I will get rid of systemd,
If you found a way that is escaping us, please share.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: The future with Systemd
Well, here is the result of my first try at doing just that this morning on a fresh install of Jessie from CD-1 of the beta 1 installer (http://cdimage.debian.org/cdimage/jessi ... 86/iso-cd/). As I enabled wifi during install, updated packages were installed. I ended up with an XFCE4 desktop (default during testing, will no doubt get reverted to Gnome for release like it did in Wheezy).edbarx wrote:Anyone can continue to use apt-get, my preferred package manager, to get rid of systemd at present...
I then did these commands from a root prompt
Code: Select all
apt-get install sysvinit systemd-
apt-get install systemd-shim
Code: Select all
apt-get install sysvinit-core
apt-get install network-manager-gnome
Code: Select all
keith@teacup:~$ pstree
init─┬─NetworkManager─┬─dhclient
│ ├─{NetworkManager}
│ ├─{gdbus}
│ └─{gmain}
├─acpid
├─applet.py───{gmain}
├─at-spi-bus-laun─┬─dbus-daemon
│ ├─{dconf worker}
│ ├─{gdbus}
│ └─{gmain}
├─at-spi2-registr───{gdbus}
├─atd
├─avahi-daemon───avahi-daemon
├─bluetoothd
├─cgmanager
├─cron
├─cups-browsed
├─cupsd
├─4*[dbus-daemon]
├─3*[dbus-launch]
├─dconf-service─┬─{gdbus}
│ └─{gmain}
├─exim4
├─2*[gconfd-2]
├─6*[getty]
├─2*[gnome-keyring-d─┬─{dconf worker}]
│ ├─{gdbus}]
│ ├─{gnome-keyring-d}]
│ └─{timer}]
├─2*[gpg-agent]
├─lightdm─┬─Xorg
│ ├─lightdm─┬─x-session-manag─┬─Thunar
│ │ │ ├─ssh-agent
│ │ │ ├─xfce4-panel─┬─mousepad───{gmain}
│ │ │ │ ├─panel-2-actions
│ │ │ │ ├─panel-6-systray
│ │ │ │ └─{gmain}
│ │ │ ├─xfdesktop───{gmain}
│ │ │ ├─xfwm4
│ │ │ ├─{gdbus}
│ │ │ └─{gmain}
│ │ ├─{gdbus}
│ │ └─{gmain}
│ ├─{gdbus}
│ └─{gmain}
├─nm-applet─┬─{dconf worker}
│ └─{gdbus}
├─polkitd─┬─{gdbus}
│ └─{gmain}
├─rpc.idmapd
├─rpc.statd
├─rpcbind
├─rsyslogd─┬─{in:imklog}
│ ├─{in:imuxsock}
│ └─{rs:main Q:Reg}
├─su───bash───nm-applet─┬─{dconf worker}
│ ├─{gdbus}
│ ├─{gmain}
│ └─{pool}
├─systemd-logind
├─systemd-shim───{gdbus}
├─udevd
├─upowerd─┬─{gdbus}
│ └─{gmain}
├─wpa_supplicant
├─x-www-browser─┬─2*[{Analysis Helper}]
│ ├─{Cache I/O}
│ ├─{Cache2 I/O}
│ ├─{Cert Verify}
│ ├─3*[{DOM Worker}]
│ ├─{Gecko_IOThread}
│ ├─{HTML5 Parser}
│ ├─{Hang Monitor}
│ ├─{Image Scaler}
│ ├─{JS GC Helper}
│ ├─{JS Watchdog}
│ ├─{MediaManager}
│ ├─{Network Seer}
│ ├─{Proxy R~olution}
│ ├─{Socket Thread}
│ ├─{Timer}
│ ├─{URL Classifier}
│ ├─{dconf worker}
│ ├─{gdbus}
│ ├─{gmain}
│ ├─{localStorage DB}
│ ├─{mozStorage #1}
│ ├─{mozStorage #2}
│ ├─{mozStorage #3}
│ ├─{mozStorage #4}
│ ├─{mozStorage #5}
│ ├─{mozStorage #6}
│ ├─{mozStorage #7}
│ └─{mozStorage #8}
├─xfce4-notifyd
├─xfce4-power-man───{gdbus}
├─xfce4-terminal─┬─bash───su───bash
│ ├─bash───pstree
│ ├─gnome-pty-helpe
│ ├─{gdbus}
│ └─{gmain}
├─xfce4-volumed─┬─{gdbus}
│ ├─{task0}
│ └─{task1}
├─2*[xfconfd]
├─xfsettingsd───{gmain}
└─xscreensaver
Packages that apt-get wants to remove
Code: Select all
root@teacup:/home/keith# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically installed and are no longer required:
colord-data gdebi-core gdisk gvfs-common gvfs-libs hplip-data libart-2.0-2
libcolorhug2 libelfg0 libglib2.0-bin libgusb2 libsane-hpaio libudisks2-0
packagekit-backend-aptcc python-imaging python-pexpect python-renderpm
python-reportlab python-reportlab-accel python3-apt python3-chardet
python3-dbus python3-debian python3-gi python3-packagekit
python3-pkg-resources python3-six
Use 'apt-get autoremove' to remove them.
Done
The following packages have been kept back:
base-passwd
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
-
- Posts: 459
- Joined: 2012-02-24 18:36
Re: The future with Systemd
nor is it written that sysv shall be removed from the repo as soon as jessie goes oldstableedbarx wrote:... but it is not guaranteed by the Debian DDs that such a possibility will continue to exist beyond that point.
Systemd was chosen as default, it doesnt mean that all other choices are going to disappear.
The choices exist and I suspect will still exist until we are all dead and gone
Debian packages do not magically disappear from the repos. As long as sysv is maintained there is no reason for it to be removed. Even if it was to be removed I suspect a 3rd party repo would quickly appear.
Re: The future with Systemd
Learning that init will continue to be supported, at least until Jessie is Old Stable, I first installed init and removed systemd. The only problem I found was with udev complaining about legacy wireless drivers I don't use. It pauses the booting sequence for a few second but then it continues normally. Jessie is now using init.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: The future with Systemd
Another good analysis of the systemd takeover from the debian-user list. Why doesn't Linus DO something?!
May the FORK be with you!
Re: The future with Systemd
Poettering's view of the future of Linux:
http://0pointer.net/blog/revisiting-how ... stems.html
Tim
http://0pointer.net/blog/revisiting-how ... stems.html
Tim
Re: The future with Systemd
The invasion of systemd of GNULand is similar to what happened in WWII. Back in those times, many politicians with the exception of Winston Churchill didn't realise that Hitler's Germany was dangerously arming itself. When the war started, it was too late for no lives to be lost and around 60 million people died.
In my analogy above, I am saying that it will be painful to get away from systemd and its claws but it will happen. As long as there is open source and a liberal license, there is hope.
Added Later:
People who want a stable system, nowadays do not need to go away from MS Windows as the latter is stable and reliable for most purposes. The type of Linux users who will be attracted by systemd's similarity to MS Windows are clueless newbies who will ultimately realise that their new choice is nothing new at all. This dissatisfaction will make them search for more freedom as it did to many of us who use GNU/Linux and who are worried about the unjustified grip systemd is having on other seemingly unrelated packages.
Liberty aware GNU/Linux users, whether they happen to be newbies or ripe, will ultimately face the reality of systemd and will despise it for raping GNU/Linux stealing its verginity. GNU/Linux was created with the value of total freedom as its central value rejecting any attempt at manipulative packages that impose too many restrictions. This hidden agenda will sometime surface and will be despised for the manipulations it is attempted to accomplish.
In my analogy above, I am saying that it will be painful to get away from systemd and its claws but it will happen. As long as there is open source and a liberal license, there is hope.
Added Later:
People who want a stable system, nowadays do not need to go away from MS Windows as the latter is stable and reliable for most purposes. The type of Linux users who will be attracted by systemd's similarity to MS Windows are clueless newbies who will ultimately realise that their new choice is nothing new at all. This dissatisfaction will make them search for more freedom as it did to many of us who use GNU/Linux and who are worried about the unjustified grip systemd is having on other seemingly unrelated packages.
Liberty aware GNU/Linux users, whether they happen to be newbies or ripe, will ultimately face the reality of systemd and will despise it for raping GNU/Linux stealing its verginity. GNU/Linux was created with the value of total freedom as its central value rejecting any attempt at manipulative packages that impose too many restrictions. This hidden agenda will sometime surface and will be despised for the manipulations it is attempted to accomplish.
Last edited by edbarx on 2014-09-02 17:17, edited 1 time in total.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: The future with Systemd
Care to share the actual commands you used? And the pstree output? And which desktop env/WM?edbarx wrote:Learning that init will continue to be supported, at least until Jessie is Old Stable, I first installed init and removed systemd.
I'm having an interesting time with permissions for network manager and the desktop on my second test install of Jessie, this time using a base install, sysvinit install and then adding the desktop.
Re: The future with Systemd
With pleasure!keithpeter wrote:Care to share the actual commands you used? And the pstree output? And which desktop env/WM?edbarx wrote:Learning that init will continue to be supported, at least until Jessie is Old Stable, I first installed init and removed systemd.
I'm having an interesting time with permissions for network manager and the desktop on my second test install of Jessie, this time using a base install, sysvinit install and then adding the desktop.
This is the sequence I used:
Note that Jessie was always booted up in single user maintenance mode.
Code: Select all
417 apt-get update
418 apt-get upgrade
419 apt-get install sysvinit
420 top //to confirm the presence of systemd running
422 apt-get install systemd-shim
430 apt-get install sysvinit-core
433 apt-get remove systemd
434 locate init
440 apt-get -f install
441 reboot
Due to two critical bugs sysvinit-core may not be installed properly. To make sure everything is properly done, I executed the following command after booting with init.
Code: Select all
apt-get install --reinstall sysvinit sysvinit-core systemd-shim
Code: Select all
init-+-acpi_fakekeyd
|-acpid
|-at-spi-bus-laun-+-{dconf worker}
| `-{gdbus}
|-cgmanager
|-console-kit-dae-+-62*[{console-kit-dae}]
| |-{gdbus}
| `-{gmain}
|-cron
|-2*[dbus-daemon]
|-dbus-launch
|-2*[dhclient]
|-6*[getty]
|-privoxy
|-rsyslogd-+-{in:imklog}
| |-{in:imuxsock}
| `-{rs:main Q:Reg}
|-slim-+-Xorg
| `-x-session-manag-+-Thunar-+-{gdbus}
| | `-{gmain}
| |-xfce4-panel-+-iceweasel-+-{Cache I/O}
| | | |-{Cert Verify}
| | | |-{DNS Resolver #6}
| | | |-{DOM Worker}
| | | |-{Gecko_IOThread}
| | | |-{HTML5 Parser}
| | | |-{Hang Monitor}
| | | |-2*[{JS GC Helper}]
| | | |-2*[{JS Sour~ Thread}]
| | | |-{JS Watchdog}
| | | |-{Socket Thread}
| | | |-{Timer}
| | | |-{URL Classifier}
| | | |-{XPCOM CC}
| | | |-{gmain}
| | | |-{mozStorage #1}
| | | |-{mozStorage #2}
| | | |-{mozStorage #3}
| | | |-{mozStorage #4}
| | | |-{mozStorage #5}
| | | |-{mozStorage #6}
| | | |-{mozStorage #7}
| | | `-{mozStorage #8}
| | |-panel-6-systray
| | |-panel-8-mixer---{task0}
| | `-{gmain}
| |-xfdesktop---{gmain}
| |-xfwm4
| `-{gmain}
|-syndaemon
|-udevd
|-upowerd-+-{gdbus}
| `-{gmain}
|-wpa_supplicant
|-xfce4-power-man---{gdbus}
|-xfce4-power-man
|-xfce4-terminal-+-bash---pstree
| |-gnome-pty-helpe
| |-{gdbus}
| `-{gmain}
|-xfce4-volumed-+-{gdbus}
| `-{task0}
|-xfconfd
|-xfsettingsd---{gmain}
`-xscreensaver
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: The future with Systemd
Thanks for posting this chunk of the history file!edbarx wrote: This is the sequence I used:
Note that Jessie was always booted up in single user maintenance mode.
Make sure /sbin/init exists after you remove systemd.Code: Select all
417 apt-get update 418 apt-get upgrade 419 apt-get install sysvinit 420 top //to confirm the presence of systemd running 422 apt-get install systemd-shim 430 apt-get install sysvinit-core 433 apt-get remove systemd 434 locate init 440 apt-get -f install 441 reboot
Same result as before I'm afraid. The apt-get remove systemd step results in a dpkg error as it decides it can't remove a running init system. The locate init step failed because I had not installed the command . The apt-get -f install step completes aspects of the installation of console kit and a few other bits and pieces that I recognise. Rebooting (Ctrl-Alt-Del as the 'reboot' command no longer works at that stage) results in a functioning desktop session that can't run anything needing root permissions, e.g. network manager or shutting down from the XFCE4 menus. Lightdm, slim makes no difference (using slim at present).
My user is in netdev and plugdev
More googling later in the week as time allows! It could just be that Jessie is in an inconsistent state at present, perhaps policy kit type default files not being set up or something.
Re: The future with Systemd
Don't be discouraged. The trick lies in either pulling in the installation of init with other packages as I did or explicitly installing init as in apt-get install init. Once you have init together with its other two or three dependencies, you can try to force a boot with init. You have to look that up, but I am sure, you should then be able to remove systemd as it wouldn't be loaded.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: The future with Systemd
Discouraged? Me? Nope.edbarx wrote:Don't be discouraged. The trick lies in either pulling in the installation of init with other packages as I did or explicitly installing init as in apt-get install init. Once you have init together with its other two or three dependencies, you can try to force a boot with init. You have to look that up, but I am sure, you should then be able to remove systemd as it wouldn't be loaded.
Init is definitely installed and running the show, unless pstree is telling lies. The apt-get -f install step did report the removal of systemd (27Mb or so), so I think it has gone. More research as time allows.
The problem is one of the desktop itself running with reduced permissions. The functions affected (nm-applet, 'reboot' and 'shutdown' commands &c) all run from a *root* terminal. Something somewhere has either changed the permissions that xfce4 programs and lightdm/slim run under or removed permissions previously granted and failed to re-grant them.
PS: if you build your systemd emulator for future releases, you do realise that you will gain very detailed and thorough knowledge of the systemd api and mode of operation? Far more than most practicing sysadmins will ever need. Loving the irony of the whole situation.
Re: The future with Systemd
Oops, I didn't remember correctly. That issue is described in this thread:keithpeter wrote:The problem is one of the desktop itself running with reduced permissions. The functions affected (nm-applet, 'reboot' and 'shutdown' commands &c) all run from a *root* terminal.
http://forums.debian.net/viewtopic.php?f=5&t=114412
It can be corrected by downgrading the mentioned three packages.
Last edited by edbarx on 2014-09-02 20:48, edited 1 time in total.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: The future with Systemd
Today, all the initial installations of Jessie with systemd have shown expected behavior, e.g. being able to use nm-applet from the toolbar to connect to wifi and being able to use the XFCE4 menu to shutdown and restart. It is when I replace systemd with init that I see the unexpected behaviour. It could be that the (always expected in testing) bugs are fixed in systemd but not yet in systemd-shim or other dependencies.edbarx wrote:You are on the wrong track with that. Those reduced permissions are not a symptom of reinstalling init but of systemd itself. I remember I had those exact issues when I was still running systemd and I am still having them. But I am satisfied of ridding myself of the loathed monster.keithpeter wrote:The problem is one of the desktop itself running with reduced permissions. The functions affected (nm-applet, 'reboot' and 'shutdown' commands &c) all run from a *root* terminal.
Which is a good reason for giving this a rest for a day or two to see what the updates bring, and to research a little more on those critical bugs and the patch timeline.
Thanks for replies, I am learning a lot from all this.
PS: as a general comment, I think we should perhaps present this issue in bug reports and in arenas where developers will actually read what is said as a purely technical one: e.g. monitoring and preserving the sysvinit functionality while the packages remain in Debian and raising bugs as needed. Anything else is playing into the hands of some very sophisticated corporate operators.
Last edited by keithpeter on 2014-09-02 20:56, edited 1 time in total.
Re: The future with Systemd
Please see my previous post again as the previous one was incorrect. That behaviour is due to three packages, downgrading them may solve the issue.
P.S.
However, downgrading these three important packages would be mixing Stable with Testing and is definitely asking for trouble. I think it is better to configure sudo to allow a normal use to execute the required commands.
P.S.
However, downgrading these three important packages would be mixing Stable with Testing and is definitely asking for trouble. I think it is better to configure sudo to allow a normal use to execute the required commands.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.