Re: [arch-general] [arch-dev-public] merging systemd back to a singular package
Am Sun, 26 Aug 2012 17:15:39 -0400 schrieb Dave Reisner <d@falconindy.com>:
I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage.
As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;)
"Nobody is forcing systemd on anybody." Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody? "Nobody has the intention to build a wall." Heiko
On Mon, Aug 27, 2012 at 07:59:52AM +0200, Heiko Baums wrote:
Am Sun, 26 Aug 2012 17:15:39 -0400 schrieb Dave Reisner <d@falconindy.com>:
I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage.
As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;)
"Nobody is forcing systemd on anybody."
Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody?
"Nobody has the intention to build a wall."
Heiko
I am pretty sure it said they will still work together, you still aren't forced to use it, you don't need udev etc... -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology
Op maandag 27 augustus 2012 07:59:52 schreef Heiko Baums:
Am Sun, 26 Aug 2012 17:15:39 -0400
schrieb Dave Reisner <d@falconindy.com>:
I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage.
As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;)
"Nobody is forcing systemd on anybody."
Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody?
"Nobody has the intention to build a wall."
Heiko
Ok: fact: - you will have all the systemd stuff installed on your system (you already had most of it on your system anyway) - initscripts is still working fine without interference of systemd so you are right, you are forced to install it. but you are wrong that you are forced to use it. and eventually only one init system will be left and now it is looking very much in favour of systemd. --Ike
Heiko Baums <lists@baums-on-web.de> wrote: Am Sun, 26 Aug 2012 17:15:39 -0400 schrieb Dave Reisner <d@falconindy.com>:
I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage.
As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;)
"Nobody is forcing systemd on anybody." Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody? "Nobody has the intention to build a wall." Heiko Up till now you didn't have a choice, you had to use initscripts and you liked it. Why don't you take over maintenance of them so people can keep using them?
On Mon, Aug 27, 2012 at 08:24:21AM +0200, Sven-Hendrik Haase wrote:
Heiko Baums <lists@baums-on-web.de> wrote:
Am Sun, 26 Aug 2012 17:15:39 -0400 schrieb Dave Reisner <d@falconindy.com>:
I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage.
As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;)
"Nobody is forcing systemd on anybody."
Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody?
"Nobody has the intention to build a wall."
Heiko
Up till now you didn't have a choice, you had to use initscripts and you liked it. Why don't you take over maintenance of them so people can keep using them? Systemd and sysvinit aren't the only inits out there, there is runit, upstart, openrc all of which are available in the aur
http://en.wikipedia.org/wiki/Init -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology
On Mon, Aug 27, 2012 at 7:59 AM, Heiko Baums <lists@baums-on-web.de> wrote:
"Nobody is forcing systemd on anybody."
Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody?
No one were forcing systemd on anybody. This packaging change still does not force systemd on anybody. It does "force" you to have the binaries installed, but it does not force you to actually boot with it. Since the above quoted statement was made, a decision was taken to move to systemd by default, so it clearly no longer applies. While you are still free to use initscripts, at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.). HTH, Tom
On Mon, 27 Aug 2012 09:48:48 +0200 Tom Gundersen <teg@jklm.no> wrote:
Since the above quoted statement was made, a decision was taken to move to systemd by default, so it clearly no longer applies. While you are still free to use initscripts, at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.).
Please support our traditional initscripts as long as possible, as I for one really don't look forwards to systemd, at least not at this point in time. Reasons excluded to avoid yet another flamefest...:(
On Aug 27, 2012 10:32 AM, "Joakim Hernberg" <jbh@alchemy.lu> wrote:
Please support our traditional initscripts as long as possible,
I will. I just don't know how long that will be, so people should prepare to move. Tom
On 27 August 2012 10:40, Tom Gundersen <teg@jklm.no> wrote:
On Aug 27, 2012 10:32 AM, "Joakim Hernberg" <jbh@alchemy.lu> wrote:
Please support our traditional initscripts as long as possible,
I will. I just don't know how long that will be, so people should prepare to move.
Tom
I can help (or at least try to) with support for initscripts if it's going to be a burden for you some day in the future. I won't give up using initscripts on my desktop so easily ;-). Lukas
On Mon, Aug 27, 2012 at 5:21 PM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
I can help (or at least try to) with support for initscripts
Anyone who wants to help, please join arch-projects@archlinux.org, review patches, use initscripts from git/testing and report problems.
if it's going to be a burden for you some day in the future.
As has been mentioned, the problems I foresee are (ordered from "currently a problem" to "a potential problem a long time from now": 1) not enough people testing initscripts. This would be easy to help out with :-) 2) third-party software (such as gnome/polkit/...) getting hard dependencies on booting with systemd (essentially everything that now depends on consolekit, and maybe more). If you don't use the affected software this does not matter, if you do it is not really easy to work around. 3) devs at some point no longer wanting to maintain the various rc scripts. If people are committed enough I guess an "rc scripts" package could be put in the AUR to deal with this case (if ever it becomes a problem, which it might not).
I won't give up using initscripts on my desktop so easily ;-).
:) -t
The 27/08/12, Tom Gundersen wrote:
As has been mentioned, the problems I foresee are (ordered from "currently a problem" to "a potential problem a long time from now":
1) not enough people testing initscripts. This would be easy to help out with :-) 2) third-party software (such as gnome/polkit/...) getting hard dependencies on booting with systemd (essentially everything that now depends on consolekit, and maybe more). If you don't use the affected software this does not matter, if you do it is not really easy to work around. 3) devs at some point no longer wanting to maintain the various rc scripts. If people are committed enough I guess an "rc scripts" package could be put in the AUR to deal with this case (if ever it becomes a problem, which it might not).
Notice that debian is working on a tool to automagically convert unit systemd files into initscripts. https://github.com/akhilvij/systemd-to-sysvinit-converter Might be worth giving it a try and contribute to get easier support of sysvinit in the long term. -- Nicolas Sebrecht
On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
Notice that debian is working on a tool to automagically convert unit systemd files into initscripts.
If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than "forking" (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious... -t
Op 28 aug. 2012 10:06 schreef "Tom Gundersen" <teg@jklm.no> het volgende:
On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht <nsebrecht@piing.fr>
wrote:
Notice that debian is working on a tool to automagically convert unit systemd files into initscripts.
If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than "forking" (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious...
Actually, that sounds like a fairly small issue... With most daemons i prefer to either start them at boot or not at all. In case any daemon requires socket activation, you can use xinetd for those. mvg, Guus
On Tue, Aug 28, 2012 at 10:24 AM, Guus Snijders <gsnijders@gmail.com> wrote:
Op 28 aug. 2012 10:06 schreef "Tom Gundersen" <teg@jklm.no> het volgende:
If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than "forking" (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious...
Actually, that sounds like a fairly small issue...
With most daemons i prefer to either start them at boot or not at all. In case any daemon requires socket activation, you can use xinetd for those.
I guess what I wrote was a bit misleading. Ignore socket/dbus activation (that is a side effect only). The point is that I don't see how to make daemons of Type=simple (the default), Type=dbus or Type=notify work without reimplementing much of systemd (regardless of when/how they are started). The point is that those kinds of daemons have moved functionality out of the daemon itself and into systemd, so the analogous must be done in the rc scripts. Hopefully the Debian guys have found a clever solution for this, I'd be interested to see it :) Cheers, Tom
The 28/08/12, Tom Gundersen wrote:
I guess what I wrote was a bit misleading. Ignore socket/dbus activation (that is a side effect only). The point is that I don't see how to make daemons of Type=simple (the default), Type=dbus or Type=notify work without reimplementing much of systemd (regardless of when/how they are started).
The point is that those kinds of daemons have moved functionality out of the daemon itself and into systemd, so the analogous must be done in the rc scripts.
Well, sd_notify looks pretty simplistic and I guess than writting a helper program to handle this function would not be hard, if ever needed. Now, the simple type of systemd pretends to do optimization: "if the process offers functionality to other processes on the system its communication channels should be installed before the daemon is started up [...] as systemd will immediately proceed starting follow-up units." While it's a good feature to get pallelism, it's not expected by historical sysVinit. So, it should be fine to start the required deamon and let it configure environment or whatever it has to. Once it is fully started or responding, continue the boot process. Yes, this "fully started or responding" is the tricky part but with a fully serialized starting process, it might be doable. Though, I wouldn't expect such converter to create shell scripts roughly equivalent to what systemd does. I think the main pitfall to such a tool would be to try to get equivalent features with shell scripts. Think another way: sysVinit serialize daemons startup. As a consequence, for a minimal working convertion you only need to get the correct order of the series. Advanced features of systemd should highly be ignored from the process. On top of that and for tricky parts of the conversion, it should not be very hard to have conversion tunning from a complementary static source. I mean, trying to convert everything /from unit files only/ in a smart enough way could be very hard. Instead, it would be easier to do the consersion from both unit files AND whatever other source or configuration files (of the convertion tool). IMHO, the best approach of this converter would be to turn it into a micro-framework with _very simple features_ like templating support for init scripts. That way: - simple unit files would not require a template; let the process go automagically; - more complex unit files would only require to write a little template with whatever static-and-dedicated code needed for a given section/function of the built target (the sysVinit script). The systemd-to-sysvinit-converter seems very hackable as a all-in-one python script with only 658 lines. ,-)
Hopefully the Debian guys have found a clever solution for this, I'd be interested to see it :)
I guess you meant "if the Debian guys have found". -- Nicolas Sebrecht
On Tue, Aug 28, 2012 at 12:06 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
"[...]its communication channels should be installed before the daemon is started up [...]"
This is the point. If a daemon has been customized for systemd (which some have, and hopefully more will), then it will expect systemd to set up its communication channels for it and pass them to the daemon on startup, it might also expect systemd to do many other tasks which daemons traditionally would do themselves. This is by no means impossible to reimplement, but it would be quite some work, so it is something to keep in mind. -t
The 28/08/12, Tom Gundersen wrote:
This is the point. If a daemon has been customized for systemd (which some have, and hopefully more will), then it will expect systemd to set up its communication channels for it and pass them to the daemon on startup, it might also expect systemd to do many other tasks which daemons traditionally would do themselves.
Daemons customized to require systemd will actually require systemd. Now, systemd is a Linux only platform tool and most upstream don't target their software to Linux only. I don't expect much daemons requiring systemd to be started. If they do, users who want such tool will use systemd and such daemons would naturally be out of the scope. -- Nicolas Sebrecht
On 27 August 2012 18:16, Tom Gundersen <teg@jklm.no> wrote:
On Mon, Aug 27, 2012 at 5:21 PM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
I can help (or at least try to) with support for initscripts
Anyone who wants to help, please join arch-projects@archlinux.org, review patches, use initscripts from git/testing and report problems.
if it's going to be a burden for you some day in the future.
As has been mentioned, the problems I foresee are (ordered from "currently a problem" to "a potential problem a long time from now":
1) not enough people testing initscripts. This would be easy to help out with :-)
For some reason I always find problems after some time when initscripts are already in core.
2) third-party software (such as gnome/polkit/...) getting hard dependencies on booting with systemd (essentially everything that now depends on consolekit, and maybe more). If you don't use the affected software this does not matter, if you do it is not really easy to work around.
I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd. I can maintain these in community if that time comes. But I can care about KDE only, making GNOME work without systemd would be a too difficult (I don't use it and they are much more likely to require systemd than KDE). Fortunately KDE currently uses only one library (polkit) that is likely to switch to systemd in near future. Lukas
On Tue, Aug 28, 2012 at 10:54 AM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd.
So far we see that whenever systemd is made optional, it is optional at compile-time rather than at run-time (which would have been ideal, and not much more difficult to code). That means our packages cannot support both scenarios at the same time. As to Ubuntu, remember that they lag quite far behind our packages, so while they probably will produce patches, don't expect it to happen in time for it to help us. Notice for instance that Ubuntu supposedly took over consolekit, but no release has happened and without backporting patches from git our consolekit package would be completely broken. In short: avoiding systemd will be a lot of work, and you will be more or less alone in doing it. -t
On 28 August 2012 11:05, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Aug 28, 2012 at 10:54 AM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd.
So far we see that whenever systemd is made optional, it is optional at compile-time rather than at run-time (which would have been ideal, and not much more difficult to code). That means our packages cannot support both scenarios at the same time.
That's why I'm think about maintaining such packages in community.
As to Ubuntu, remember that they lag quite far behind our packages, so while they probably will produce patches, don't expect it to happen in time for it to help us. Notice for instance that Ubuntu supposedly took over consolekit, but no release has happened and without backporting patches from git our consolekit package would be completely broken.
In short: avoiding systemd will be a lot of work, and you will be more or less alone in doing it.
-t
Unless there's going to be some major rewrite of the affected packages in the meantime I think I'll be able to handle that. During the years I'm using OSS, I learned one thing: If no one else wants to do something, you must do it yourself. Lukas
Hi, Apparently, Gentoo has recently forked udev. [1] I am not completely sure since the main poster is a n00b according to the gentoo forum ratings, but rest of the discussions seems legit. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On Tue, Aug 28, 2012 at 6:55 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote:
Hi,
Apparently, Gentoo has recently forked udev. [1] I am not completely sure since the main poster is a n00b according to the gentoo forum ratings, but rest of the discussions seems legit.
Actually, a guy forked it and announced it on Gentoo's forums; the distro itself currently has nothing to do with it, although as Gentoo is planning on using OpenRC over systemd any news about a udev fork is interesting to them [2]. I'm not sure I'd call the less than one page of discussion "legit" though - it looks to me like a little bit of building discussion and a lot of the same crap that's been infecting our own mailing list (plus consus' "advantages" are suspect - just going on the first one, a separate /usr not mounted in initramfs has been broken since long before systemd-udev, and in my quick look at commits I don't really see anything they've added that would change that esp. since it's not just udev that's the issue. If Gentoo devs get on board it might go somewhere, but until then I'm not that confident.) [1]https://forums.gentoo.org/viewtopic-t-934678.html [2]http://www.reddit.com/r/linux/comments/ywdpw/systemdudev_has_been_forked/c5z...
Ahh, I thought so. It was only forked yesterday, so there is not much to be expected in terms of changes right now. But going by the number of veterans and others who have commented on it, I thought that it is possible that this is legit. Also, the guys there are talking like they are the one going to be making the changes. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd. I can maintain these in community if that time comes. But I can care about KDE only, making GNOME work without systemd would be a too difficult (I don't use it and they are much more likely to require systemd than KDE). Fortunately KDE currently uses only one library (polkit) that is likely to switch to systemd in near future.
Personally I live happier without polkit but for others it may be if the build machines don't mind that arch could have kde-nosystemd packages? -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
Am 27.08.2012 10:32, schrieb Joakim Hernberg:
On Mon, 27 Aug 2012 09:48:48 +0200 Tom Gundersen <teg@jklm.no> wrote:
Since the above quoted statement was made, a decision was taken to move to systemd by default, so it clearly no longer applies. While you are still free to use initscripts, at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.).
Please support our traditional initscripts as long as possible, as I for one really don't look forwards to systemd, at least not at this point in time. Reasons excluded to avoid yet another flamefest...:(
If you search the archives, you will notice that longer initscripts support is already planned. But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come. That said, if you run a machine that does not depend on any of this (like a server), you will probably be able to keep using traditional initscripts for a while. Of course, this may change as the situation changes.
On Mon, 27 Aug 2012 10:48:32 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.
I don't run gnome, but kde is just as bad in this case :(
That said, if you run a machine that does not depend on any of this (like a server), you will probably be able to keep using traditional initscripts for a while.
I am primarily thinking of a few servers I've setup with archlinux. I really don't look forwards to run all the overhead that systemd will bring with it on those machines.. Will try to refrain from further comments now, since I don't want to pollute this list with flames... Thanks in advance for the time I still have left with arch :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, \begin{quote} But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.... \end{quote} Isn't it possible to start systemd daemon-like if one of those components is used...and stop it again after e.g. stopping Gnome? This won't avoid unnecessary overhead, but at least the boot process etc. could be kept unchanged. Cheers, Jakob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQO2doAAoJEOl7hkDId7YmpokP/0BCzKUjz/CelgwuAShBC27b Oa5pH73d2BN60mIBDCSvysgH0li8I6MQsDjKTP/QAN/tHFYAyWQGk594rP2jkrVv xCd6JsxQBTTj0Ud+hDdgQ7k63swemnuIBH2h84CLZq1xMXDzoZJVXrKc92/5ZB8m bM158+rT1Lylclh5wq4KXfSsKVjE3nNmAb6nEvyJbVqBZL25MNDEcmVlGqqF986r Aoy+Z2CNJrkbs86WUtH4slS5WZzzM/fPOSytSdAq5Us7eARiqbf9fE8d5QR9KNuW c2W2N1dUU0rDP0p6EAIbxgfEW3o7rZzCRGgking4nIiiLmnQf9XLFTzbqrX17VtF F5FT7MY6e7Lv+IjnMFhU8BtaTdGcN0nyMncyiok/Sp5b7wq9sFKjgCxIafQBLn16 7Y+WCb0rOTboBqoyUMbKAmFBZkzujbuCUsjMX4ga1ruMG3kOfgeUspFIPwloJxMM TOsSS47+g6njvpRtGqRFP2c72RidI/egIVA/1SZPpVJfEgsJU5DuJg1B+iz1yIgk IgPKvEZcB6pJ+gawIEaUheUsuWz8jFGXMPTH4f7gXV61hn7w+J+OAfMwoHTYPQj9 r1raAk1/FRLLN98C4jnu7Jk/iN583WBa3/tgBlqrtlIUPyvzVr/PlJRZrv9Ftb44 p1AnwcueNzojDqsRhtzm =hQlL -----END PGP SIGNATURE-----
Am Mon, 27 Aug 2012 11:30:46 +0200 schrieb Joakim Hernberg <jbh@alchemy.lu>:
I don't run gnome, but kde is just as bad in this case :(
Try Xfce. ;-) Heiko
Am Mon, 27 Aug 2012 11:30:46 +0200 schrieb Joakim Hernberg <jbh@alchemy.lu>:
I don't run gnome, but kde is just as bad in this case :( Try Xfce. ;-) http://www.archlinux.org/packages/extra/i686/consolekit/ would suggest
On 27/08/2012 9:39 AM, Heiko Baums wrote: that xfce is not safe in this regard. lxde is as long as you don't use a display manager iirc.
Heiko
On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote:
On Mon, 27 Aug 2012 10:48:32 +0200
Thomas Bächler <thomas@archlinux.org> wrote:
But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.
I don't run gnome, but kde is just as bad in this case :(
care to elaborate? I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific. GNOME OTOH forces you to use pulseaudio :P -- Regards Shridhar
On Tue, 28 Aug 2012 07:46:30 +0530 Shridhar Daithankar <ghodechhap@ghodechhap.net> wrote:
On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote:
On Mon, 27 Aug 2012 10:48:32 +0200
Thomas Bächler <thomas@archlinux.org> wrote:
But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.
I don't run gnome, but kde is just as bad in this case :(
care to elaborate?
I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific.
GNOME OTOH forces you to use pulseaudio :
$ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd. But who knows, I can imagine that there are so many old time linux users that would hate installing something like systemd even if they use kde as DE. With a bit of luck someone willl step up and maintain an alternative to consolekit/polkit that doesn't require systemd. --- Joakim -- Joakim Hernberg
On Tue, 28 Aug 2012 08:55:06 +0200 Joakim Hernberg <jbh@alchemy.lu> wrote:
$ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd.
Maybe I should add that I think this support is only needed by KDE for powermanagement and automounting of media. So conceivably one could live without it if necessary :) -- Joakim -- Joakim Hernberg
On 28 August 2012 16:01, Joakim Hernberg <jbh@alchemy.lu> wrote:
On Tue, 28 Aug 2012 08:55:06 +0200 Joakim Hernberg <jbh@alchemy.lu> wrote:
$ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd.
Maybe I should add that I think this support is only needed by KDE for powermanagement and automounting of media. So conceivably one could live without it if necessary :)
In fact, many Archers have lived without these things for years ever since they became mandatory for the masses. Especially those on WMs. These are the purists, so to say. I don't see systemd or anything like that becoming a problem. The purists will find their way to keep these things out. Having libpulse or systemd "live" on your system isn't going to do any harm while you're adapting to the change. There's always a way to do what you want, and there's always another KISS operating system. Given the resistance that I see, I'm almost sure a separate initscripits project (or a distro fork if necessary) is inevitable. -- GPG/PGP ID: C0711BF1
On Tue, 28 Aug 2012 23:45:04 +0800 Rashif Ray Rahman <schiv@archlinux.org> wrote:
Having libpulse or systemd "live" on your system isn't going to do any harm while you're adapting to the change. There's always a way to do what you want, and there's always another KISS operating system. Given the resistance that I see, I'm almost sure a separate initscripits project (or a distro fork if necessary) is inevitable.
A distro fork would be the absolute worst outcome imaginable (imo) of the initscripts vs systemd schism... --- Joakim
On Tue, Aug 28, 2012 at 06:36:22PM +0200, Joakim Hernberg wrote:
A distro fork would be the absolute worst outcome imaginable (imo) of the initscripts vs systemd schism...
Assuming you mean a fork of Arch, I agree. But consider ArchHURD downstream. They'll have no choice but to do something different.
On Wed, 2012-08-29 at 07:18 -0600, Anthony ''Ishpeck'' Tedjamulia wrote:
On Tue, Aug 28, 2012 at 06:36:22PM +0200, Joakim Hernberg wrote:
A distro fork would be the absolute worst outcome imaginable (imo) of the initscripts vs systemd schism...
Assuming you mean a fork of Arch, I agree. [snip]
And I agree with the following statement: On Wed, 2012-08-29 at 10:39 +0100, Peter Cannon wrote:
Oh and as a side note a rolling release means it rolls, http://www.thefreedictionary.com/roll if it stops because of a breakage or a change in file structure or manipulation that then means it is not rolling it has come to a halt. Just wanted to add that for those I keep seeing on the net saying "It's a rolling release what do you expect?" Judd Vincent meant "You'll never have to upgrade because every pacman- Syu gives you the most recent version." ergo 'It's rolled over to the latest. If a package breaks your system that's fair enough, if changing the file structure or core of your system breaks it that has nothing to do with 'rolling' that's called "I just ripped the wires out of your radio but hey you get to keep all the parts." just wanted to clarify that.
Is Arch a rolling release or isn't it?
On Wed, Aug 29, 2012 at 10:24 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Wed, 2012-08-29 at 10:39 +0100, Peter Cannon wrote:
Oh and as a side note a rolling release means it rolls, http://www.thefreedictionary.com/roll if it stops because of a breakage or a change in file structure or manipulation that then means it is not rolling it has come to a halt. Just wanted to add that for those I keep seeing on the net saying "It's a rolling release what do you expect?" Judd Vincent meant "You'll never have to upgrade because every pacman- Syu gives you the most recent version." ergo 'It's rolled over to the latest. If a package breaks your system that's fair enough, if changing the file structure or core of your system breaks it that has nothing to do with 'rolling' that's called "I just ripped the wires out of your radio but hey you get to keep all the parts." just wanted to clarify that.
Is Arch a rolling release or isn't it?
It's as rolling as a rolling distro can get. The fact that a rolling release system uses the word "rolling" doesn't qualify the release with every possible meaning of that word In the case of a distribution, it means that we don't get updates for old versions of software, just for the newest version some packager had the motivation to provide. So, it is very distant from the real meaning of "rolling". Unless we'll now receive our updates on a DVD down a hill and it comes rolling to the bottom... :P -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
But who knows, I can imagine that there are so many old time linux users that would hate installing something like systemd even if they use kde as DE. With a bit of luck someone willl step up and maintain an alternative to consolekit/polkit that doesn't require systemd.
In most cases there is no need. Consolekit controls sessions for xfce, the first thing I turn off and easily replaced. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
Am 28.08.2012 04:16, schrieb Shridhar Daithankar:
On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote:
On Mon, 27 Aug 2012 10:48:32 +0200
Thomas Bächler <thomas@archlinux.org> wrote:
But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.
I don't run gnome, but kde is just as bad in this case :(
care to elaborate?
I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific.
You can build polkit with either consolekit or systemd support, but not with support for both. consolekit is unmaintained for a while and thus we will switch to building polkit with systemd support instead. Once that happens, you need systemd for certain aspects of KDE to function properly (most prominently, mounting removable file systems).
On Monday 27 Aug 2012 11:30:46 Joakim Hernberg wrote:
I don't run gnome, but kde is just as bad in this case :(
I use KDE regularly. It works perfectly fine with/without pulseaudio. (Actually since archlinux does not install pulseaudio by default, I did not notice it was not installed for a long time, until it tried firing up pavucontrol and saw it was not installed and neither was any pulseaudio package.) Also, there is no systemd dependency in KDE. So, KDE might be bad for you in general, but in this case, it is definitely good. -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Thomas Bächler wrote:
Please support our traditional initscripts as long as possible, as I for one really don't look forwards to systemd, at least not at this point in time. Reasons excluded to avoid yet another flamefest...:(
If you search the archives, you will notice that longer initscripts support is already planned.
But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.
That said, if you run a machine that does not depend on any of this (like a server), you will probably be able to keep using traditional initscripts for a while.
This is good news ! I maintain a bunch of test-machines (about 10) in a lab and the prospect of moving all of them to a new init system is a bit scary - they are all in a remote place. My environment is openbox/emacs, so initscripts is a perfect fit. Having just moved all the machines to grub2 and resolved the /lib migration, embracing systemd right now appears to be a tiresome job. :-) And I have a server which I stopped upgrading a while ago. :) Sujith
at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.).
Do you mean the packages compiled for Arch with systemd enabled options like firefoxes with dbus? I don't see these packages removing more than half their userbase and I don't see systemd ever getting more than half the userbase. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
participants (21)
-
Anthony ''Ishpeck'' Tedjamulia
-
Daniel Wallace
-
Denis A. Altoé Falqueto
-
Guus Snijders
-
Heiko Baums
-
Ike Devolder
-
Jakob Herrmann
-
Jayesh Badwaik
-
Joakim Hernberg
-
Kevin Chadwick
-
Lukas Jirkovsky
-
Nicolas Sebrecht
-
Ralf Mardorf
-
Rashif Ray Rahman
-
Shridhar Daithankar
-
Stephen E. Baker
-
Sujith
-
Sven-Hendrik Haase
-
Thomas Bächler
-
Tom Gundersen
-
Zeke Sulastin