Hey all, I just wanted to share my experience with you. I follow closely the changes and discussion about systemd and I have to say that in the first I was worried also that taken away the basic configuration from rc.conf will be complicated and will cause more pain. I usually enjoy breaking my computer into a point that I have to spend 2 hours reading the wiki or forums to fix it. Now days though I don't have much time mainly due to work. Thus I wanted to get ahead of the migration of initscripts to systemd. I recently made an Archlinux installation on my laptop so the system was quite clean. It was the perfect target for systemd migration. I just installed the systemd and opened up wiki page. I started making configuration changes to the files replacing entries in rc.conf with new files. It was quite straight forward if you know your system and refer back to your rc.conf. When done I removed the intescripts and rebooted. It was that simple. Had a bit of glinches as I didn't enable networkmanager from the start and reboot from inside the gnome didn't work, but now it's all fixed. I recommend to all to try at least once the systemd migration and then express opinions. It's really easy. Maybe it's just my idea but I think the system is somewhat faster on the booting now. Just my opinion but as I see initscripts are abandoned and Archlinux is a bleeding edge distro, it's natural solution to adopt systemd. +1 from me :) Disclaimer: this was done on a laptop a very recent installation, maybe on other more complicated installations it's harder. Leonidas -- Caution: breathing may be hazardous to your health. #include <stdio.h> int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
Hi everyone! My experience with systemd is a +1 as well. I use it in my laptop and it provides a nice experience for a desktop user. Starting services on demand, suspend support and all other features gives a nice experience for an end user.
Maybe it's just my idea but I think the system is somewhat faster on the booting now. True for me as well. From grub to kdm in around 5sec.
Nevertheless, this overall good opinion can't hide certain (or significant I might say) worries. Your system now relies in a bunch of binary code that might not be posible to workaround if something goes wrong. Scripts may not be as efficient but they are great in order to skip,modify or run them in case of emergency. Logging using systemd infrastructure provides a very pleasent usage experience for me as you can very easily select the relevant records you're interested in without a lot of grep magic. But I've already suffered the downside of relying on binary stored records. In case of system crash/forced shutdown or power failure log files might end up corrupted. Which is a pretty nasty thing you don't want to happen and it opens a big door to atacks. I would recomend systemd for interactive users but I don't wan't it in a server that much. I can't give an opinion on wether initscripts should be dropped or not. Aitor Pazos Ibarzabal Instant Messaging (Jabber, GTalk): aitor@aitorpazos.es Web: http://aitorpazos.es PGP Public Key: http://aitorpazos.es/publickey.asc
On Wed, Jul 25, 2012 at 4:34 PM, Aitor Pazos <mail@aitorpazos.es> wrote:
Hi everyone!
My experience with systemd is a +1 as well. I use it in my laptop and it provides a nice experience for a desktop user. Starting services on demand, suspend support and all other features gives a nice experience for an end user.
Maybe it's just my idea but I think the system is somewhat faster on the booting now. True for me as well. From grub to kdm in around 5sec.
Nevertheless, this overall good opinion can't hide certain (or significant I might say) worries. Your system now relies in a bunch of binary code that might not be posible to workaround if something goes wrong. Scripts may not be as efficient but they are great in order to skip,modify or run them in case of emergency.
Right, because /sbin/init isn't binary and none of the scripts relied on a interpreter that wasn't binary code? Cheers, Sander
Right, because /sbin/init isn't binary and none of the scripts relied on a interpreter that wasn't binary code?
They are indeed, but it's a matter of size. The size of /sbin/init is 40.592B and /usr/lib/systemd/systemd 866.576B, which is a huge difference. Init responsabilities are much more specific than systemd's and the binary doesn't change much. All systemd's features implies it will be updated frequently and every change introduces some kind of risk. Interpreters are binaries as well, but if one fail you might use another one, if systemd fails you might not be able to get even a rescue console.
On Thu, Jul 26, 2012 at 12:31 AM, Aitor Pazos <mail@aitorpazos.es> wrote:
Right, because /sbin/init isn't binary and none of the scripts relied on a interpreter that wasn't binary code?
They are indeed, but it's a matter of size. The size of /sbin/init is 40.592B and /usr/lib/systemd/systemd 866.576B, which is a huge difference. Init responsabilities are much more specific than systemd's and the binary doesn't change much. All systemd's features implies it will be updated frequently and every change introduces some kind of risk.
Interpreters are binaries as well, but if one fail you might use another one, if systemd fails you might not be able to get even a rescue console.
i think the likelihood of this is extremely low -- if your binary is so borked it can't run at all, methinks none of your binaries will run (since you have probably messed up the dynamic linker or something). not really an issue IMO, and comparing two images on size alone garners no real information. ultimately, you can always just bypass systemd with `init=/bin/bash` or, if dynamic libs were fuxxed, `init=/bin/busybox`, or even `init=/usr/lib/initcpio/busybox` ... which will get you a root shell. ... and if you can't get that far then you need a rescue image anyway, and systemd coundn't have prevented that. -- C Anthony
On Thu, Jul 26, 2012 at 7:44 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
i think the likelihood of this is extremely low -- if your binary is so borked it can't run at all, methinks none of your binaries will run (since you have probably messed up the dynamic linker or something).
I'd have thought that /sbin/init would be a statically linked program. As it happens, I'm wrong. /bin/systemd is a dynamic program too.
ultimately, you can always just bypass systemd with `init=/bin/bash` or, if dynamic libs were fuxxed, `init=/bin/busybox`, or even `init=/usr/lib/initcpio/busybox` ... which will get you a root shell.
Now that I'm checking... /bin/busybox is statically linked, but /usr/lib/initcpio/busybox is not. That is a good incentive to have the busybox package installed by default. Just in case. If the system is so borked and you dont have the busybox around, you can also delete the root=whatever from the kernel command line and you will get a (initramfs) prompt. Then you can use it as a quick'n'dirty rescue system. -- Rodrigo
If the system is so borked and you dont have the busybox around, you can also delete the root=whatever from the kernel command line and you will get a (initramfs) prompt. Then you can use it as a quick'n'dirty rescue system.
This assumes the user is knowledgeable too. If a script fails chances are they can still access the internet. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
Nevertheless, this overall good opinion can't hide certain (or significant I might say) worries. Your system now relies in a bunch of binary code that might not be posible to workaround if something goes wrong. Scripts may not be as efficient but they are great in order to skip,modify or run them in case of emergency.
Right, because /sbin/init isn't binary and none of the scripts relied on a interpreter that wasn't binary code?
Do you really think that's a good point. We want valid opinion here not bashing. Bash even is smaller than systemds core binary and think of everything it can do which wouldn't be used even and how much more peer review it has had and will always get than systemd. Unified scripts would get the same as systemd, perhaps more because more eyes would understand or even bother to look and report problems or improvements. Some of which may be due to time saving silly edits by users but I'd say that is a good thing. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Thu, Jul 26, 2012 at 11:19 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk>wrote:
... We want valid opinion here not bashing.
Bash even is smaller than systemds core binary...
At this point in the discussion it is clear that Bash has been written for bashing. Just try not to take everything so seriously... -- Rodrigo
Am Mittwoch, den 25.07.2012, 20:42 +0100 schrieb Leonidas Spyropoulos:
Maybe it's just my idea but I think the system is somewhat faster on the booting now.
Just my opinion but as I see initscripts are abandoned and Archlinux is a bleeding edge distro, it's natural solution to adopt systemd. +1 from me :)
Disclaimer: this was done on a laptop a very recent installation, maybe on other more complicated installations it's harder.
+1 I've "converted" two Arch installations from initscripts to systemd. After some fiddling about my nfs-mounts systemd works fine, and I didn't get any problem with it so far. I hardly understand people who only read about systemd and complain all the time. Is it just the fear of new things? Maybe systemd will make things easier for arch-newbies, because they have not to care about the order of the DAEMONS in rc.conf (networkmanager after dbus etc.). And I hardly believe that people are using Arch only because of "simplicity" of one single config file. regards bjo -- xmpp: bjo@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de
On Thu, Jul 26, 2012 at 5:58 PM, Bjoern Franke <bjo@nord-west.org> wrote:
Am Mittwoch, den 25.07.2012, 20:42 +0100 schrieb Leonidas Spyropoulos:
Maybe it's just my idea but I think the system is somewhat faster on the booting now.
Just my opinion but as I see initscripts are abandoned and Archlinux is a bleeding edge distro, it's natural solution to adopt systemd. +1 from me :)
Disclaimer: this was done on a laptop a very recent installation, maybe on other more complicated installations it's harder.
+1
I've "converted" two Arch installations from initscripts to systemd. After some fiddling about my nfs-mounts systemd works fine, and I didn't get any problem with it so far. I hardly understand people who only read about systemd and complain all the time. Is it just the fear of new things? Maybe systemd will make things easier for arch-newbies, because they have not to care about the order of the DAEMONS in rc.conf (networkmanager after dbus etc.). And I hardly believe that people are using Arch only because of "simplicity" of one single config file.
Perhaps it is not fair to compare Arch directly with another distribution but I have been a Fedora user for many years, and only in the past year converted to Arch due to the strong appeal of arch's rolling release system - but I still have a few machines which run Fedora 16 where systemd is there by default - and I have to say that I have not had a single issue related to systemd in Fedora 16. I have not installed Fedora 17 but presumably the number of bug reports concerning systemd is small now for the most recent stable version. One has to learn how to stop and start daemons and a few still have no service files and use the old way of starting them up, but once "enabled" daemons start up and run at boot without any problem, and have not caused any packages to fail or stop working in Fedora 16. At present systemd is still being "honed" in arch, but once the preparation and testing are complete hopefully then I guess once people have run their systems using systemd for real for a while without significant problems them maybe resistence to this way of starting up daemons will fade somewhat? Of course there are some bigg'ish changes in Arch at the moment - glibc, /usr move, grub2, systemd - and dare I mention that possibly some work is being done on selinux - the nitty gritty details of the implementation are where the problems lie but with work as bugs arise and get fixed maybe all these will stabilise and move slowly into the install media - and with new install media planned to be released at more regular intervals I guess any residual bugs will emerge as people use the new systems more. I had great fun on a laptop last week trying to increase the post-MBR gap on the hard drive from 32kiB to 2MiB on a system that had a Dell diagnostic partition between the MBR and the root arch partition - I won't go into the gory (and scary) details of going from an unbootable system back to a running arch system after removing the Dell diagnostic partition! Back to systemd... We are all still learning as new features come into play! -- mike c
participants (8)
-
Aitor Pazos
-
Bjoern Franke
-
C Anthony Risinger
-
Kevin Chadwick
-
Leonidas Spyropoulos
-
mike cloaked
-
Rodrigo Rivas
-
Sander Jansen