Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
On 15/08/12 00:57, Stéphane Gaudreault wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
+1 - this move needs done now. Delaying it longer will just be painful.
Allan
On Wednesday 15 August 2012 01:04:48 Allan McRae wrote:
+1 - this move needs done now. Delaying it longer will just be painful.
I couldn't agree more. Go for it.
On di, 2012-08-14 at 10:57 -0400, Stéphane Gaudreault wrote:
Any objections to start the migration process ?
Go ahead. Maintaining 2 systems is a lot of duplicate work. Besides the duplicate work, you'll get covered in patches trying to support setups that avoid installing something new.
Polkit is an example of this: we have a patch to make systemd optional at runtime, we request users to test it, and instead of testing it we end up with a 300+ posts thread about how bad Lennart is, with nearly no-one trying to investigate what is wrong about the patch and in which situations it doesn't work.
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault stephane@archlinux.org wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
A big +1 from me.
As to the future of initscripts: I am (as I keep saying) committed to maintaining it as long as it is part of our repos (at some point I expect it will not be any more). We'll make sure that the transition to systemd is such that initscripts can still be installed for the time being if that is desired. However, I expect that third-party packages (gnome, NetworkManager, polkit, etc.) at some point will stop working well without systemd, so that is something to consider if you stick with initscripts.
Cheers,
Tom
Am 14.08.2012 17:15, schrieb Tom Gundersen:
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault stephane@archlinux.org wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
A big +1 from me.
As to the future of initscripts: I am (as I keep saying) committed to maintaining it as long as it is part of our repos (at some point I expect it will not be any more). We'll make sure that the transition to systemd is such that initscripts can still be installed for the time being if that is desired. However, I expect that third-party packages (gnome, NetworkManager, polkit, etc.) at some point will stop working well without systemd, so that is something to consider if you stick with initscripts.
I also prefer taking the slow route here. As someone who is yet to migrate to systemd, I don't know what kind of quirks it still has.
My plan:
1) Tell people to migrate to systemd. 2) Make new installations use systemd by default. 3) Stop holding back packages because of systemd. For example: polkit requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.
I guess it will take lots of time before we do 4).
Another point: Someone on the so-called "official" G+ stated:
"Arch will move to systemd only boot process..."
As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because
1) Something untrue and/or unprecise is being posted on the "official" G+. 2) There are claims that this G+ is official. Neither our website, nor any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+.
This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.
On Wed, Aug 15, 2012 at 5:56 PM, Thomas Bächler thomas@archlinux.org wrote:
My plan:
- Tell people to migrate to systemd.
- Make new installations use systemd by default.
- Stop holding back packages because of systemd. For example: polkit
requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.
I guess it will take lots of time before we do 4).
I agree wholeheartedly (assuming all the needed things such as unit files are in place before we do (1), as discussed earlier in the thread). I suppose what will trigger initscripts being dropped is people getting sick of maintaining rc scripts for our packages, which will probably happen long before udev stops working (but even that should be a long time into the future).
As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because
- Something untrue and/or unprecise is being posted on the "official" G+.
That is indeed imprecise, but I'll admit that I didn't notice myself...
- There are claims that this G+ is official. Neither our website, nor
any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+.
This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.
Yeah, we should probably discuss that (though I'm personally overall happy with the G+ page).
-t
Le 2012-08-15 12:11, Tom Gundersen a écrit :
On Wed, Aug 15, 2012 at 5:56 PM, Thomas Bächler thomas@archlinux.org wrote:
My plan:
- Tell people to migrate to systemd.
- Make new installations use systemd by default.
- Stop holding back packages because of systemd. For example: polkit
requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.
I guess it will take lots of time before we do 4).
I agree wholeheartedly (assuming all the needed things such as unit files are in place before we do (1), as discussed earlier in the thread). I suppose what will trigger initscripts being dropped is people getting sick of maintaining rc scripts for our packages, which will probably happen long before udev stops working (but even that should be a long time into the future).
I agree with the proposed plan. The schedule could looks like this
(1) and (2) could be done after the missing unit files rebuild is over. They should probably be announced at the same time as I expect that some users will prefer a fresh install instead of "upgrading". (3) Maybe this could be done in preparation of the gnome 3.6.0 release scheduled at the end of September. (4) There is no rush to do that, but users need to know that it _will_ happen.
Am 15.08.2012 18:41, schrieb Stéphane Gaudreault:
(4) There is no rush to do that, but users need to know that it _will_ happen.
That is still questionable:
Assuming that udev keeps working, a server system that has no polkit (or not even dbus) installed may keep working just fine. It's just the "modern" fd.o things and desktops that start relying on systemd.
Le 2012-08-15 12:46, Thomas Bächler a écrit :
Am 15.08.2012 18:41, schrieb Stéphane Gaudreault:
(4) There is no rush to do that, but users need to know that it _will_ happen.
That is still questionable:
Assuming that udev keeps working, a server system that has no polkit (or not even dbus) installed may keep working just fine. It's just the "modern" fd.o things and desktops that start relying on systemd.
Your are right. As Tom mentionned the decision to drop the support on initscript will probably based more on the priority of work.
On Wed, Aug 15, 2012 at 6:41 PM, Stéphane Gaudreault stephane@archlinux.org wrote:
(1) and (2) could be done after the missing unit files rebuild is over. They should probably be announced at the same time as I expect that some users will prefer a fresh install instead of "upgrading". (3) Maybe this could be done in preparation of the gnome 3.6.0 release scheduled at the end of September.
That would be nice, if we are ready by then. Let's see what sorts of problems crop up and how fast we are at adding service files.
(4) There is no rush to do that, but users need to know that it _will_ happen.
I think the important point is that (3) will happen. I.e., that "fancy" stuff will certainly stop working without systemd at some point (soon). The eventual fate of initscripts we could get back to (no promises made in either direction). Though, we should make it very clear that people _should_ prepare for its eventual demise. By that I mean, have a look at systemd at some point, and if it does not work for you, report a bug so it can be fixed in good time before initscripts is dropped.
-t
On Wed, Aug 15, 2012 at 12:11 PM, Tom Gundersen teg@jklm.no wrote:
On Wed, Aug 15, 2012 at 5:56 PM, Thomas Bächler thomas@archlinux.org wrote:
My plan:
- Tell people to migrate to systemd.
- Make new installations use systemd by default.
- Stop holding back packages because of systemd. For example: polkit
requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.
I guess it will take lots of time before we do 4).
I agree wholeheartedly (assuming all the needed things such as unit files are in place before we do (1), as discussed earlier in the thread). I suppose what will trigger initscripts being dropped is people getting sick of maintaining rc scripts for our packages, which will probably happen long before udev stops working (but even that should be a long time into the future).
That also looks like agood plan to me.
I suppose that developpement of initscripts will stop, i.e. no more new features or bug fixes. That should gently push users to systemd and it might become the reason to remove it from the repo (step 4).
As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because
- Something untrue and/or unprecise is being posted on the "official" G+.
That is indeed imprecise, but I'll admit that I didn't notice myself...
- There are claims that this G+ is official. Neither our website, nor
any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+.
This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.
Yeah, we should probably discuss that (though I'm personally overall happy with the G+ page).
-t
Am 15.08.2012 17:56, schrieb Thomas Bächler:
Another point: Someone on the so-called "official" G+ stated:
"Arch will move to systemd only boot process..."
As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because
- Something untrue and/or unprecise is being posted on the "official" G+.
- There are claims that this G+ is official. Neither our website, nor
any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+.
This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.
Yes, I see the same problem here. Due to this it's announced all over the media that we replace initscripts by systemd before it's even discussed on this list. No idea who created this, and I don't mind if there are "fanpages" on some social networks, but we should ask to remove the "official" from the title here as it is misleading and just not true.
Greetings,
Pierre
On Wednesday 15 August 2012 19:36:55 Pierre Schmitz wrote:
Yes, I see the same problem here. Due to this it's announced all over the media that we replace initscripts by systemd before it's even discussed on this list. No idea who created this, and I don't mind if there are "fanpages" on some social networks, but we should ask to remove the "official" from the title here as it is misleading and just not true.
Sorry, but what are you saying isn't true. None talked about the systemd replacement in the google+ page until that post was written and, since it links to the arch-dev-public thread, it has been written after the discussion. Just to dot your I's and cross your T's'.
On Wednesday 15 August 2012 17:56:00 Thomas Bächler wrote:
Another point: Someone on the so-called "official" G+ stated:
"Arch will move to systemd only boot process..."
As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because
- Something untrue and/or unprecise is being posted on the "official" G+.
- There are claims that this G+ is official. Neither our website, nor
any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+.
This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.
Well, I created that page on January and since then _we_ (managers' page: me, Ionut, Ray, s, Daniel) never write something which wasn't announced by our website. Until today.
I don't know who write that (neither I wanna know), but you pointed out something true, so I already removed the "official" suffix from our page and "fixed" the post about systemd. I hope this is ok now.
Am 15.08.2012 20:26, schrieb Andrea Scarpino:
I don't know who write that (neither I wanna know), but you pointed out something true, so I already removed the "official" suffix from our page and "fixed" the post about systemd. I hope this is ok now.
Thank you.
On Tue, Aug 14, 2012 at 10:57:42AM -0400, Stéphane Gaudreault wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
At this point, I've had a _lot_ of people give the same feedback -- the transition is more or less seamless. As you mention, we're simply lacking the unit file coverage to make this the default.
+1 to finishing off what we're obviously sitting in the middle of.
A few things to encourage this which were discussed on IRC:
- merge systemd back to a single package (aside from sysvcompat) - split off some of the tools from sysvinit (pidof, last, ...)
For the future:
- drop rc.conf compat for systemd. - finish the /usr migration. Not strictly related, but this makes writing unit files easier imo. Also lets us drop a local patch against systemd.
In parallel, I'd love to see a working install media with systemd on it. I've got some changes planned for arch-install-scripts (and devtools) to use systemd-nspawn instead of all this manual chroot business (though the manual fallback will remain) as its sooooo much cleaner and easier Note that this also requires some changes that will be in systemd 189.
d
On Tue, Aug 14, 2012 at 5:17 PM, Dave Reisner d@falconindy.com wrote:
A few things to encourage this which were discussed on IRC:
- merge systemd back to a single package (aside from sysvcompat)
- split off some of the tools from sysvinit (pidof, last, ...)
For the future:
- drop rc.conf compat for systemd.
- finish the /usr migration. Not strictly related, but this makes writing unit files easier imo. Also lets us drop a local patch against systemd.
Another big +1 from me on this too.
-t
Am 14.08.2012 17:17, schrieb Dave Reisner:
For the future:
- drop rc.conf compat for systemd.
For me it actually caused some trouble that systemd reads rc.conf as well.
- finish the /usr migration. Not strictly related, but this makes writing unit files easier imo. Also lets us drop a local patch against systemd.
In parallel, I'd love to see a working install media with systemd on it. I've got some changes planned for arch-install-scripts (and devtools) to use systemd-nspawn instead of all this manual chroot business (though the manual fallback will remain) as its sooooo much cleaner and easier Note that this also requires some changes that will be in systemd 189.
I'll definitely have a look at this when 189 is released. I am not sure if we can use nspawn in ais at we might actually want to see the chroot the real devices etc..
There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here. E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.
We also might need to add a little force to push the migration process. E.g. at some point a missing unit file is a bug and might result in the package being dropped.
Greetings,
Pierre
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.
Did I miss something or did you miss the Jan's todo list[1]?
E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.
Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
[1] https://www.archlinux.org/todo/178/
On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.
Did I miss something or did you miss the Jan's todo list[1]?
E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.
Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.
d
On Tuesday 14 August 2012 12:57:37 Dave Reisner wrote:
So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.
Ok, so since there's no standard I'm fine with Pierre's idea to write the default parameters in the service files and drop the conf.d*whatever files.
On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner d@falconindy.com wrote:
On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.
Did I miss something or did you miss the Jan's todo list[1]?
E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.
Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.
What does the non-standard think about distro-provided updates to the units? Seems like with overriding the whole thing rather than small pieces in a separate config file, it isn't obvious to the user when they need to merge updates to the unit files.
-Dan
On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote:
On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner d@falconindy.com wrote:
On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.
Did I miss something or did you miss the Jan's todo list[1]?
E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.
Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.
What does the non-standard think about distro-provided updates to the units? Seems like with overriding the whole thing rather than small pieces in a separate config file, it isn't obvious to the user when they need to merge updates to the unit files.
-Dan
It's possible to include unit files (.include /lib/systemd/....), though in practice, I haven't seen how well this works.
On Aug 14, 2012 7:17 PM, "Dave Reisner" d@falconindy.com wrote:
On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote:
On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner d@falconindy.com wrote:
On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
There are still a lot of unit files missing; we should create a
todo
list. It would also be helpful to write down a simple wiki page
with
some guidelines here.
Did I miss something or did you miss the Jan's todo list[1]?
E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these
as
the user should override unit files in /etc.
Indeed, I was wondering if we should adapt our packages to the
layout used by
the upstream systemd services files. E.g. the upstream proftpd
service sources
/etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
So there is no standard for this, and the general recommendation is
that
if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.
What does the non-standard think about distro-provided updates to the units? Seems like with overriding the whole thing rather than small pieces in a separate config file, it isn't obvious to the user when they need to merge updates to the unit files.
-Dan
It's possible to include unit files (.include /lib/systemd/....), though in practice, I haven't seen how well this works.
There its also systemd-delta, which makes this much easier to deal with.
Tom
On Tue, Aug 14, 2012 at 6:57 PM, Dave Reisner d@falconindy.com wrote:
On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.
Did I miss something or did you miss the Jan's todo list[1]?
E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.
Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.
d
This approach would also necessitate educating our users about running systemd-delta after upgrades. Users might end up having overridden units that got updated, and as a result, break.
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault stephane@archlinux.org wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
+1 from me. I want to be able to start getting rid of ConsoleKit where possible.
[2012-08-14 10:57:42 -0400] Stéphane Gaudreault:
I would suggest to replace iniscript by systemd
Let's do it. It's about time we lose these ML trolls.
Am 14.08.2012 16:57, schrieb Stéphane Gaudreault:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
+1 I use systemd on all my machines.
greetings tpowa
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault stephane@archlinux.org wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
+1
Ronald
On Tue, Aug 14, 2012 at 10:57 AM, Stéphane Gaudreault stephane@archlinux.org wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
+1.
I don't use systemd or know how it works or compare to initscripts but I am aware that we'll need to switch to it eventually as more and more projects will depends on it. So the sooner the better.
Eric
On 15 August 2012 07:32, Eric Bélanger snowmaniscool@gmail.com wrote:
On Tue, Aug 14, 2012 at 10:57 AM, Stéphane Gaudreault stephane@archlinux.org wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
+1.
I don't use systemd or know how it works or compare to initscripts but I am aware that we'll need to switch to it eventually as more and more projects will depends on it. So the sooner the better.
Eric
Exactly the same position, +1.
On 08/14/2012 05:57 PM, Stéphane Gaudreault wrote:
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
I wonder if we manage to do the switch before gnome 3.6 comes out. I'm sick and tired of supporting ck and seats and become harder to do so.
I plan to drop consolekit support from gnome and compile it with systemd full support.
Le 2012-08-14 10:57, Stéphane Gaudreault a écrit :
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.
Any objections to start the migration process ?
Cheers,
Stéphane
I started a draft unordered TODO list on a wiki page. Contributions are welcome.
https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd
Cheers,
Stéphane
arch-dev-public@lists.archlinux.org