Re: [arch-general] [arch-dev-public] Migration to systemd
On 14 August 2012 10:57, 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
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them - I know I can't order anyone to do it, and my comment doesn't effect the outcome, but I would really like to see a good explanation of the advantages in an unbiased (aka not by LP) explanation of why it is better for arch. Is systemd suckless? is it easy to maintain? is it going to around for several years? have we considered Upstart? what about OpenRC? before Arch jump ship, I would love to see some good details. I have been trying to keep up Tom's posts on the general, so maybe I should revisit them. Calvin
On 08/14/12 17:55, Calvin Morrison wrote:
On 14 August 2012 10:57, 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
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them - I know I can't order anyone to do it, and my comment doesn't effect the outcome, but I would really like to see a good explanation of the advantages in an unbiased (aka not by LP) explanation of why it is better for arch. Is systemd suckless? is it easy to maintain? is it going to around for several years? have we considered Upstart? what about OpenRC?
before Arch jump ship, I would love to see some good details. I have been trying to keep up Tom's posts on the general, so maybe I should revisit them.
Calvin
Tom has listed the advantages a couple of times in arch-general. -- Jelle van der Waa
On 14 August 2012 11:58, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On 08/14/12 17:55, Calvin Morrison wrote:
On 14 August 2012 10:57, 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
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them - I know I can't order anyone to do it, and my comment doesn't effect the outcome, but I would really like to see a good explanation of the advantages in an unbiased (aka not by LP) explanation of why it is better for arch. Is systemd suckless? is it easy to maintain? is it going to around for several years? have we considered Upstart? what about OpenRC?
before Arch jump ship, I would love to see some good details. I have been trying to keep up Tom's posts on the general, so maybe I should revisit them.
Calvin
Tom has listed the advantages a couple of times in arch-general.
-- Jelle van der Waa
I remember seeing the comparisons against SysV but not at all against upstart or OpenRC
I remember seeing the comparisons against SysV but not at all against upstart or OpenRC
Comparison of systemd features vs upstart and sysv: note this is from lennart's site... http://0pointer.de/blog/projects/why.html
On 14 August 2012 12:20, Brandon Watkins <bwat47@gmail.com> wrote:
I remember seeing the comparisons against SysV but not at all against upstart or OpenRC
Comparison of systemd features vs upstart and sysv: note this is from lennart's site... http://0pointer.de/blog/projects/why.html
This table looks like a bad advert "only our product includes all of the features". of course I'm sure he made sure to only include those ones that were yes for systemd... and quite a few are BS. one "yes" is a graphical UI... sigh. One thing about upstart I like is that it has good documentation, a good development team, is also being adopted readily, and has good unit testing in place. It also has a clear development direction. Calvin
On Tue, Aug 14, 2012 at 12:25 PM, Calvin Morrison <mutantturkey@gmail.com>wrote:
On 14 August 2012 12:20, Brandon Watkins <bwat47@gmail.com> wrote:
I remember seeing the comparisons against SysV but not at all against upstart or OpenRC
Comparison of systemd features vs upstart and sysv: note this is from lennart's site... http://0pointer.de/blog/projects/why.html
This table looks like a bad advert "only our product includes all of the features". of course I'm sure he made sure to only include those ones that were yes for systemd... and quite a few are BS. one "yes" is a graphical UI... sigh.
One thing about upstart I like is that it has good documentation, a good development team, is also being adopted readily, and has good unit testing in place. It also has a clear development direction.
Calvin
Yep, thats what the disclaimer was for :) there's definitely some silly stuff on the chart like the bzr vs svn vs bzr thing at the end lol, so of course take it with a grain of salt.
On Tue, 14 Aug 2012 11:55:28 -0400 Calvin Morrison <mutantturkey@gmail.com> wrote:
On 14 August 2012 10:57, 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
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them - I know I can't order anyone to do it, and my comment doesn't effect the outcome, but I would really like to see a good explanation of the advantages in an unbiased (aka not by LP) explanation of why it is better for arch. Is systemd suckless? is it easy to maintain? is it going to around for several years? have we considered Upstart? what about OpenRC?
One advantage of systemd which people seem to overlook is its suspend support, bypassing pm-utils. The latter is broken, has a looooong list of open bugs and looks unmaintained. So +1 from me.
before Arch jump ship, I would love to see some good details. I have been trying to keep up Tom's posts on the general, so maybe I should revisit them.
Well, arch-general is a treasure troff... if you can search through 1000+ posts on the subject.
Calvin
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 08/14/2012 12:55 PM, Calvin Morrison wrote:
On 14 August 2012 10:57, 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
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them - I know I can't order anyone to do it, and my comment doesn't effect the outcome, but I would really like to see a good explanation of the advantages in an unbiased (aka not by LP) explanation of why it is better for arch. Is systemd suckless? is it easy to maintain? is it going to around for several years? have we considered Upstart? what about OpenRC?
before Arch jump ship, I would love to see some good details. I have been trying to keep up Tom's posts on the general, so maybe I should revisit them.
Calvin
I, for one, congratulate Arch developers for this. They don't need to give reasons. Remember that *Arch is a meritocracy*, not a democracy, if the developers choose to do this, that is it. Trying to push your ideas on others while not doing anything at all but giving your opinions is completely useless for everyone involved, developers and users alike. Developers have their own ideas that they actually want to implement for free and share, they don't need your ideas unless they ask for it. *They didn't ask for it.* I just hope Arch developers would make this clearer, without fearing losing users, and these guys, maybe, would stop spamming the mailing lists with nonsense. :D Cheers, Hilton
On Tue, Aug 14, 2012 at 11:55 AM, Calvin Morrison <mutantturkey@gmail.com>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
On 14 August 2012 10:57, Stéphane Gaudreault <stephane@archlinux.org> wrote: 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'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them - I know I can't order anyone to do it, and my comment doesn't effect the outcome, but I would really like to see a good explanation of the advantages in an unbiased (aka not by LP) explanation of why it is better for arch. Is systemd suckless? is it easy to maintain? is it going to around for several years? have we considered Upstart? what about OpenRC?
before Arch jump ship, I would love to see some good details. I have been trying to keep up Tom's posts on the general, so maybe I should revisit them.
Calvin
Systemd isn't going anywhere anytime soon, its going to be adopted by RHEL (which means it would also be adopted by RHEL derivatives like CentOS), and its being adopted by major distros like fedora, opensuse, mageia etc...
From what I've read systemd seems to have more active development and have a more modern design than upstart that allows for more parallelism during boot (even driven vs socket driven) I'm sure there's someone that can explain that better than me though.
On the developer side, I'm sure it will make things easier for the arch devs using the upstream "standard" init system, because it wil be well tested across many distros. Also from what I've heard the systemd developers have been quite friendly making fixes to systemd so that it better supports arch. On the user-side I find systemd much easier to maintain my system with than sysvinit. I find the service files a lot cleaner and easier to understand than initscripts (service files are also portable so they can be included with upstream packages).
Am 14.08.2012 18:19, schrieb Brandon Watkins:
Systemd isn't going anywhere anytime soon, its going to be adopted by RHEL (which means it would also be adopted by RHEL derivatives like CentOS), and its being adopted by major distros like fedora, opensuse, mageia etc...
What are those "major distributions"? 1) Debian, Ubuntu, Mint and derivatives 2) Fedora and derivatives 3) openSuSE 4) Arch 5) Mandriva / Mageia 6) Slackware 7) Gentoo That's about it. As you see, I included Arch up there. As far as I can see, after Debian, Ubuntu, Mint, Fedora and openSuSE (in no particular order), Arch has been number 6 on the list of "major Linux distributions" (excluding professional stuff like SLES or RHEL) for several years. What I am trying to say is: It no longer suffices to say "we follow the major distributions" when making a decision, as Arch itself is a major distribution now. Still, your point stands: Redhat will be funding systemd development for quite a while.
2012/8/15 Thomas Bächler <thomas@archlinux.org>:
Am 14.08.2012 18:19, schrieb Brandon Watkins:
Systemd isn't going anywhere anytime soon, its going to be adopted by RHEL (which means it would also be adopted by RHEL derivatives like CentOS), and its being adopted by major distros like fedora, opensuse, mageia etc...
What are those "major distributions"?
1) Debian, Ubuntu, Mint and derivatives 2) Fedora and derivatives 3) openSuSE 4) Arch 5) Mandriva / Mageia 6) Slackware 7) Gentoo
That's about it. As you see, I included Arch up there. As far as I can see, after Debian, Ubuntu, Mint, Fedora and openSuSE (in no particular order), Arch has been number 6 on the list of "major Linux distributions" (excluding professional stuff like SLES or RHEL) for several years.
What I am trying to say is: It no longer suffices to say "we follow the major distributions" when making a decision, as Arch itself is a major distribution now.
Still, your point stands: Redhat will be funding systemd development for quite a while.
As a rolling release, Arch is usually the leader of adopt new technology. But now, Arch is falling behind Debian now. So sad. Chao
On Aug 14, 2012 6:52 PM, "Leon Feng" <rainofchaos@gmail.com> wrote:
2012/8/15 Thomas Bächler <thomas@archlinux.org>:
Am 14.08.2012 18:19, schrieb Brandon Watkins:
Systemd isn't going anywhere anytime soon, its going to be adopted by
RHEL
(which means it would also be adopted by RHEL derivatives like CentOS), and its being adopted by major distros like fedora, opensuse, mageia etc...
What are those "major distributions"?
1) Debian, Ubuntu, Mint and derivatives 2) Fedora and derivatives 3) openSuSE 4) Arch 5) Mandriva / Mageia 6) Slackware 7) Gentoo
That's about it. As you see, I included Arch up there. As far as I can see, after Debian, Ubuntu, Mint, Fedora and openSuSE (in no particular order), Arch has been number 6 on the list of "major Linux distributions" (excluding professional stuff like SLES or RHEL) for several years.
What I am trying to say is: It no longer suffices to say "we follow the major distributions" when making a decision, as Arch itself is a major distribution now.
Still, your point stands: Redhat will be funding systemd development for quite a while.
As a rolling release, Arch is usually the leader of adopt new technology. But now, Arch is falling behind Debian now. So sad.
Chao
I admit I miss some news but last i read debian was NOT moving to systemd because it only supports Linux... So how are we falling behind them?
As a rolling release, Arch is usually the leader of adopt new technology. But now, Arch is falling behind Debian now. So sad.
Arch Linux is also about simplicity. For me, this is more important than the rolling-releaseness and bleeding-edgeness. If Arch lags behind Debian, that is fine by me; some things that Debian does by default I don't like because of their complexity. Also keep in mind, once upon a time, Debian was the bleeding edge distro; if Debian wants to reclaim that title then more power to Debian. I like both Debian and Arch, and I say, let's not get too stressed if Debian is occasionally more cutting edge. It's all still Linux, and Arch can only thrive on a little competition of this nature.
On Tue, Aug 14, 2012 at 8:21 PM, Timothy Rice <t.rice@ms.unimelb.edu.au>wrote:
As a rolling release, Arch is usually the leader of adopt new technology. But now, Arch is falling behind Debian now. So sad.
Arch Linux is also about simplicity. For me, this is more important than the rolling-releaseness and bleeding-edgeness. If Arch lags behind Debian, that is fine by me; some things that Debian does by default I don't like because of their complexity. Also keep in mind, once upon a time, Debian was the bleeding edge distro; if Debian wants to reclaim that title then more power to Debian.
I like both Debian and Arch, and I say, let's not get too stressed if Debian is occasionally more cutting edge. It's all still Linux, and Arch can only thrive on a little competition of this nature.
Arch is still a simple system that you can still build from the ground up (and in fact the installer has gone 'back to the roots' recently). I don't think this change makes arch any less KISS, IMO.
2012/8/15 Timothy Rice <t.rice@ms.unimelb.edu.au>:
As a rolling release, Arch is usually the leader of adopt new technology. But now, Arch is falling behind Debian now. So sad.
Arch Linux is also about simplicity. For me, this is more important than the rolling-releaseness and bleeding-edgeness. If Arch lags behind Debian, that is fine by me; some things that Debian does by default I don't like because of their complexity. Also keep in mind, once upon a time, Debian was the bleeding edge distro; if Debian wants to reclaim that title then more power to Debian.
I like both Debian and Arch, and I say, let's not get too stressed if Debian is occasionally more cutting edge. It's all still Linux, and Arch can only thrive on a little competition of this nature.
For me, simple means use upstream vanilla package. When most other linux distro switch to systemd. Still use initscripts will make people comes from other distro harder to adapt. In the past, there is no upstream for initscripts, so every distro duplicate their effort to write ugly bash scripts which are hard to maintain. With systemd as a good upstream now, Arch can stop wasting time maintain those ugly scripts.
On Wed, Aug 15, 2012 at 07:51:25AM +0800, Leon Feng wrote:
As a rolling release, Arch is usually the leader of adopt new technology. But now, Arch is falling behind Debian now. So sad.
On Wed, Aug 15, 2012 at 3:48 AM, Anthony ''Ishpeck'' Tedjamulia < archlinux@ishpeck.net> wrote:
On 16 August 2012 11:08, Rodrigo Rivas <rodrigorivascosta@gmail.com> wrote:
On Wed, Aug 15, 2012 at 3:48 AM, Anthony ''Ishpeck'' Tedjamulia < archlinux@ishpeck.net> wrote:
please don't continue this OT thread here. respect Arch ML policies this is not an arch related general support request take it to a forum or use the email addresses of those taking part & make a personal thread. -- Regards Thomas Rand
On Thu, Aug 16, 2012 at 11:08:50AM +0200, Rodrigo Rivas wrote:
I do not argue that software is good because it is old. I argue that software which is correct does not need to be changed.
On Thu, Aug 16, 2012 at 5:52 PM, Anthony ''Ishpeck'' Tedjamulia < archlinux@ishpeck.net> wrote:
On Thu, Aug 16, 2012 at 11:08:50AM +0200, Rodrigo Rivas wrote:
I do not argue that software is good because it is old. I argue that software which is correct does not need to be changed.
But you linked to the "Appeal to novelty" fallacy, suggesting that other people argue that systemd is better just because it is new. Fallacies usually come in pairs, thus my link: changing for change's sake makes no sense; nor does not changing for tradition's sake. Anyway, the fact that SysV is good enough doesn't mean that it cannot -or should not- be changed. Whether systemd is the right answer is yet to be seen, though. The world changes, and the opposite of evolution is stagnation. And I, for one, moved to Arch to see the change happen! Regards -- Rodrigo
On Fri, Aug 17, 2012 at 01:02:45AM +0200, Rodrigo Rivas wrote:
But you linked to the "Appeal to novelty" fallacy, suggesting that other people argue that systemd is better just because it is new. Fallacies usually come in pairs, thus my link: changing for change's sake makes no sense; nor does not changing for tradition's sake.
Okay. Fair enough.
Anyway, the fact that SysV is good enough doesn't mean that it cannot -or should not- be changed. Whether systemd is the right answer is yet to be seen, though.
If you check the list's history, you'll find that I hate sysv more than systemd. I have been trying to use this opportunity to get people to consider better alternatives. (*cough* http://cr.yp.to/daemontools.html *cough*)
The world changes, and the opposite of evolution is stagnation. And I, for one, moved to Arch to see the change happen!
After looking at other distros, reading more of the upstream material, I am convinced that Arch really needs to go with systemd. Not because it is good software but because the other adequate software that this community depends on is going to require it. Arch can't afford to fork all those packages just to have a superior startup system. The value of code correctness is not that high.
Not because it is good software but because the other adequate software that this community depends on is going to require it.
Let me know so I'm aware what the software you have in mind is if it hasn't been mentioned please. Debian and Ubuntu plus the BSDs make up far more of the user base than the rest put together and has Redhat switched yet?, so when I think about it, I find this unlikely. Programs may need compiling to work with or without systemd which will be annoying as I don't agree with wasting resources building everything in the Gentoo style, though it would be handy. -- _______________________________________________________________________ '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) _______________________________________________________________________
On Fri, Aug 17, 2012 at 03:11:16PM +0100, Kevin Chadwick wrote:
Not because it is good software but because the other adequate software that this community depends on is going to require it.
Let me know so I'm aware what the software you have in mind is if it hasn't been mentioned please.
It has been mentioned. http://smarden.org/pape/djb/daemontools/noinit.html That argument is pretty thorough. But again, I don't know if it applies to Arch. The needs of this distro may include requirements beyond just a good, elegant startup system.
On Fri, Aug 17, 2012 at 03:11:16PM +0100, Kevin Chadwick wrote:
Not because it is good software but because the other adequate software that this community depends on is going to require it.
Let me know so I'm aware what the software you have in mind is if it hasn't been mentioned please.
Debian and Ubuntu plus the BSDs make up far more of the user base than the rest put together and has Redhat switched yet?, so when I think about it, I find this unlikely. Programs may need compiling to work with or without systemd which will be annoying as I don't agree with wasting resources building everything in the Gentoo style, though it would be handy.
-- _______________________________________________________________________
'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) ______________________________________________________________________ If I recall correctly I don't believe you would have to modify any program to work with systemd, the only thing you'd have to do is create a unit for it. (Though I could be wrong please correct me if I'm wrong.)_
Not because it is good software but because the other adequate software that this community depends on is going to require it.
Let me know so I'm aware what the software you have in mind is if it hasn't been mentioned please.
Debian and Ubuntu plus the BSDs make up far more of the user base than the rest put together and has Redhat switched yet?, so when I think about it, I find this unlikely. Programs may need compiling to work with or without systemd which will be annoying as I don't agree with wasting resources building everything in the Gentoo style, though it would be handy.
-- _______________________________________________________________________
'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) ______________________________________________________________________ If I recall correctly I don't believe you would have to modify any program to work with systemd, the only thing you'd have to do is create a unit for it. (Though I could be wrong please correct me if I'm wrong.)_
That's for sure because unless systemd is rewritten I won't ever be using it. Looks like the reply confused you as the response did me, the original mail was saying what software will break without running systemd and that's what I was interested in. Some have mentioned consolekit but that's not even close to a requirement for 99% of users except maybe enterprise. Note, udisks removed highly used by almost all functions for enterprise functions no one used as a priority. Some others like polkit have been mentioned, none of which have been allowed to have any extra rights on my systems for a while. -- _______________________________________________________________________ '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) _______________________________________________________________________
On 08/17/2012 04:37 PM, Justin Strickland wrote:
If I recall correctly I don't believe you would have to modify any program to work with systemd, the only thing you'd have to do is create a unit for it. (Though I could be wrong please correct me if I'm wrong.)_
It is better if programs are willing to log to stdout/stderr, so the output can be captured through systemd's journal process. Apache and Postfix are the two examples I encountered where this seemed impossible. Also, it is better, and this will be a problem familiar to users of DJB's daemontools, if programs have a way of not forking and can simply run without what I know from my old PDP-11 RSTS/e days as "detaching," although systemd is better able to handle programs that do than daemontools is. -- David Benfell benfell@parts-unknown.org
On Wed, Aug 15, 2012 at 12:39 AM, Thomas Bächler <thomas@archlinux.org> wrote:
That's about it. As you see, I included Arch up there. As far as I can see, after Debian, Ubuntu, Mint, Fedora and openSuSE (in no particular order), Arch has been number 6 on the list of "major Linux distributions" (excluding professional stuff like SLES or RHEL) for several years.
Reminds me of some of the sports in the Olympics (or even the major football leagues in Europe). The gap between the top X (in this case, the threesome of Debian, Ubuntu, and Fedora) and the rest is VERY large. Based on number of users, number of developers, FULL-TIME and paid developers, and brand recognition.
What I am trying to say is: It no longer suffices to say "we follow the major distributions" when making a decision, as Arch itself is a major distribution now.
Depends on your definition of 'major'. As a 'true' community-driven ie. no consistent funding and volunteer-operated distro Arch will probably never be in the position to define the terms of conversation.
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part A good design would make the init process which is always running and everyone must run. 1./ Be a small simple binary 2./ Have no dependencies 3./ Be easy to follow, fix and lockdown, best fit being interpreted languages. 4./ be as fast as possible systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better -- _______________________________________________________________________ '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) _______________________________________________________________________
On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
2./ Have no dependencies
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
4./ be as fast as possible
systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better
I agree in general, but systemd doesn't meet #4; we are supposed to believe that's the case, but does it really? -- Felipe Contreras
[2012-08-15 12:27:33 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
4./ be as fast as possible
systemd meets 4.
I agree in general, but systemd doesn't meet #4; we are supposed to believe that's the case, but does it really?
Are you trying to play smart by ass throwing random rhetorical questions around, or just plain stupid not having the slightest beginning of sound technical evidence to back up your claims? -- Gaetan
On Wed, Aug 15, 2012 at 1:01 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-08-15 12:27:33 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
4./ be as fast as possible
systemd meets 4.
I agree in general, but systemd doesn't meet #4; we are supposed to believe that's the case, but does it really?
Are you trying to play smart by ass throwing random rhetorical questions around, or just plain stupid not having the slightest beginning of sound technical evidence to back up your claims?
How is that rhetorical? If you are making the claim that systemd is faster, you should have clear undeniable evidence at hand, where is it? If you are not making that claim, then you agree with me that #4 is not proven. I'm afraid you will be asking me for evidence (even though I'm not making a claim, so I shouldn't need it; it's the one making the claim that has the burden of proof), but here evidence for the contrary in my case (systemd is slower): http://people.freedesktop.org/~felipec/systemd/bootchart_sysd.png http://people.freedesktop.org/~felipec/systemd/bootchart_sysv.png Cheers. -- Felipe Contreras
[2012-08-15 13:31:10 +0200] Felipe Contreras:
If you are making the claim that systemd is faster, you should have clear undeniable evidence at hand, where is it?
Everywhere: https://encrypted.google.com/search?q=systemd+boot+time Stop looking at your belly button for a minute and please realize that you are the only one trying to push this nonsense of yours...
here evidence for the contrary in my case (systemd is slower)
Too bad for you. Thank god the rest of the world is fine. -- Gaetan
On Wed, Aug 15, 2012 at 2:23 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-08-15 13:31:10 +0200] Felipe Contreras:
If you are making the claim that systemd is faster, you should have clear undeniable evidence at hand, where is it?
Everywhere:
You call that evidence? Did you even click on that link? Most of those results are of "fast" boot times, but not "faster" than typical init scripts. Do your homework and show me evidence of *before* and *after*.
Stop looking at your belly button for a minute and please realize that you are the only one trying to push this nonsense of yours...
Ad populum fallacy. -- Felipe Contreras
[2012-08-15 15:03:21 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 2:23 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
Everywhere:
You call that evidence? Did you even click on that link? Most of those results are of "fast" boot times, but not "faster" than typical init scripts.
Do your homework and show me evidence of *before* and *after*.
How about opening your eyes to the evidence everyone has been pointing you towards?
Stop looking at your belly button for a minute and please realize that you are the only one trying to push this nonsense of yours...
Ad populum fallacy.
Please, you're not Galileo. Quit being so arrogant as not to question your own judgement when everybody disagrees with you. -- Gaetan
On Wed, Aug 15, 2012 at 5:05 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-08-15 15:03:21 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 2:23 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
Everywhere:
You call that evidence? Did you even click on that link? Most of those results are of "fast" boot times, but not "faster" than typical init scripts.
Do your homework and show me evidence of *before* and *after*.
How about opening your eyes to the evidence everyone has been pointing you towards?
There isn't such evidence (for improved boot times). No amount of wishful thinking can be constituted as evidence.
Stop looking at your belly button for a minute and please realize that you are the only one trying to push this nonsense of yours...
Ad populum fallacy.
Please, you're not Galileo. Quit being so arrogant as not to question your own judgement when everybody disagrees with you.
Fallacies are fallacies. If you are not going to follow basic rules of reasoning, then there's no point in discussing with you. I will not reply to you any more. Cheers. -- Felipe Contreras
On Wed, 15 Aug 2012 12:27:33 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
2./ Have no dependencies
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
4./ be as fast as possible
systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better
I agree in general, but systemd doesn't meet #4; we are supposed to believe that's the case, but does it really?
So... on my c2d (1.8ghz) machine a reboot with initscripts takes about 40s. With systemd it will either take (1) < 40s (2) > 40s. But probably the deviation will not exceed ~5s. Given that... why should I care about speed at all? Again your problem with 300 MHz kernel timer may be real, but is it relevant when talking about an init system? Does it overweigh such pros as deprecation of ck and pm-utils, or ability to lock a user in a cgroup? -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Aug 15, 2012 at 6:11 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Wed, 15 Aug 2012 12:27:33 +0200 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 11:21 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
2./ Have no dependencies
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
4./ be as fast as possible
systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better
I agree in general, but systemd doesn't meet #4; we are supposed to believe that's the case, but does it really?
So... on my c2d (1.8ghz) machine a reboot with initscripts takes about 40s. With systemd it will either take (1) < 40s (2) > 40s. But probably the deviation will not exceed ~5s.
Given that... why should I care about speed at all? Again your problem with 300 MHz kernel timer may be real, but is it relevant when talking about an init system? Does it overweigh such pros as deprecation of ck and pm-utils, or ability to lock a user in a cgroup?
I am merely replying to what Kevin said. Using Kevin's list systemd has in reality no advantage. Of course you can add items to that list, such as the ones you mentioned. I care nothing about those items you mentioned, while I care about speed. Different people have different opinions, but having an *official* list of advantages/disadvantages can only help. specially if/when shit hits the fan, and tons of users experience fundamental problems with systemd (which is a real possibility); they will this is an imposition without a good reason. -- Felipe Contreras
Am 15.08.2012 11:21, schrieb Kevin Chadwick:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs. Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
4./ be as fast as possible
systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better
Where are your AUR packages that provide OpenBSD's init? I haven't seen them.
On Wed, Aug 15, 2012 at 1:15 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 11:21, schrieb Kevin Chadwick:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear: 2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell. -- Felipe Contreras
Am 15.08.2012 13:34, schrieb Felipe Contreras:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear:
2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
Okay, where exactly does systemd violate that?
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux). And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear:
2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
Okay, where exactly does systemd violate that?
d-bus, for starters.
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted). -- Felipe Contreras
Am 15.08.2012 14:01, schrieb Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
What argument? You _claim_ that it isn't simple, but you do not give any proof for that claim.
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear:
2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
Okay, where exactly does systemd violate that?
d-bus, for starters.
Dependencies that are * used widely - check * in most systems - check * have few dependencies themselves - check * are simple themselves - ahemm So, dbus almost qualifies. You said "for starters", what others are there.
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Ah, you mean those. You do realize that we now used many of those tools in our initscripts, and I don't see you complaining about that. There's probably plenty of reasons why they are in C, I don't know them. In any case, I don't see how making something in a scripting language is simpler - in contrast, I always find that writing a small C program for a task is easier and the result is more robust than a script. I'll stop discussing with you now, as this will lead nowhere. The fact remains that all you do is complain, instead of providing an alternative. The decisions are being made by the people who actually _maintain_ this stuff inside Arch.
On Wed, Aug 15, 2012 at 2:16 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 14:01, schrieb Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
What argument? You _claim_ that it isn't simple, but you do not give any proof for that claim.
It is general knowledge that scripting languages are generally simpler than compiling languages. But fine, compare a few lines of rc.sysinit: # mount the API filesystems # /proc, /sys, /run, /dev, /run/lock, /dev/pts, /dev/shm mountpoint -q /proc || mount -t proc proc /proc -o nosuid,noexec,nodev mountpoint -q /sys || mount -t sysfs sys /sys -o nosuid,noexec,nodev mountpoint -q /run || mount -t tmpfs run /run -o mode=0755,nosuid,nodev mountpoint -q /dev || mount -t devtmpfs dev /dev -o mode=0755,nosuid mkdir -p /dev/{pts,shm} mountpoint -q /dev/pts || mount -t devpts devpts /dev/pts -o mode=0620,gid=5,nosuid,noexec mountpoint -q /dev/shm || mount -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev To their equivalent in systemd: --- #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <string.h> #include <sys/stat.h> #include <sys/wait.h> #include <mntent.h> #include "log.h" #include "util.h" #include "path-util.h" #include "set.h" #include "mount-setup.h" #include "exit-status.h" /* Goes through /etc/fstab and remounts all API file systems, applying * options that are in /etc/fstab that systemd might not have * respected */ int main(int argc, char *argv[]) { int ret = EXIT_FAILURE; FILE *f = NULL; struct mntent* me; Hashmap *pids = NULL; if (argc > 1) { log_error("This program takes no argument."); return EXIT_FAILURE; } log_set_target(LOG_TARGET_AUTO); log_parse_environment(); log_open(); umask(0022); f = setmntent("/etc/fstab", "r"); if (!f) { if (errno == ENOENT) { ret = EXIT_SUCCESS; goto finish; } log_error("Failed to open /etc/fstab: %m"); goto finish; } pids = hashmap_new(trivial_hash_func, trivial_compare_func); if (!pids) { log_error("Failed to allocate set"); goto finish; } ret = EXIT_SUCCESS; while ((me = getmntent(f))) { pid_t pid; int k; char *s; /* Remount the root fs, /usr and all API VFS */ if (!mount_point_is_api(me->mnt_dir) && !path_equal(me->mnt_dir, "/") && !path_equal(me->mnt_dir, "/usr")) continue; log_debug("Remounting %s", me->mnt_dir); pid = fork(); if (pid < 0) { log_error("Failed to fork: %m"); ret = EXIT_FAILURE; continue; } if (pid == 0) { const char *arguments[5]; /* Child */ arguments[0] = "/bin/mount"; arguments[1] = me->mnt_dir; arguments[2] = "-o"; arguments[3] = "remount"; arguments[4] = NULL; execv("/bin/mount", (char **) arguments); log_error("Failed to execute /bin/mount: %m"); _exit(EXIT_FAILURE); } /* Parent */ s = strdup(me->mnt_dir); if (!s) { log_oom(); ret = EXIT_FAILURE; continue; } k = hashmap_put(pids, UINT_TO_PTR(pid), s); if (k < 0) { log_error("Failed to add PID to set: %s", strerror(-k)); ret = EXIT_FAILURE; continue; } } while (!hashmap_isempty(pids)) { siginfo_t si; char *s; zero(si); if (waitid(P_ALL, 0, &si, WEXITED) < 0) { if (errno == EINTR) continue; log_error("waitid() failed: %m"); ret = EXIT_FAILURE; break; } s = hashmap_remove(pids, UINT_TO_PTR(si.si_pid)); if (s) { if (!is_clean_exit(si.si_code, si.si_status, NULL)) { if (si.si_code == CLD_EXITED) log_error("/bin/mount for %s exited with exit status %i.", s, si.si_status); else log_error("/bin/mount for %s terminated by signal %s.", s, signal_to_string(si.si_status)); ret = EXIT_FAILURE; } free(s); } } finish: if (pids) hashmap_free_free(pids); if (f) endmntent(f); return ret; } --- If you think the second one is simpler, then I don't you know what 'simple' means.
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear:
2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
Okay, where exactly does systemd violate that?
d-bus, for starters.
Dependencies that are * used widely - check
Not as widely as shell, and libc, and util-linux. Some Arch Linux users don't use D-Bus, in fact, and it's not by default added to rc.conf precisely for that reason.
* in most systems - check
Less than the Arch Linux systems that use initscripts.
* have few dependencies themselves - check
libx11 is a cheap dependency for you?
* are simple themselves - ahemm
D-Bus is extremely complicated. It's more than 100k likes of code.
So, dbus almost qualifies. You said "for starters", what others are there.
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Ah, you mean those. You do realize that we now used many of those tools in our initscripts, and I don't see you complaining about that.
That is dangerous, but not as dangerous as going full systemd. But anyway, I am merely explaining what #3 means IMO.
There's probably plenty of reasons why they are in C, I don't know them. In any case, I don't see how making something in a scripting language is simpler - in contrast, I always find that writing a small C program for a task is easier and the result is more robust than a script.
And I find completely the opposite to be the case. Scripts are easier to write, read, and debug.
I'll stop discussing with you now, as this will lead nowhere. The fact remains that all you do is complain, instead of providing an alternative. The decisions are being made by the people who actually _maintain_ this stuff inside Arch.
The alternative is simple: stay with initscripts *at least* until the problems with systemd are sorted out. I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems. Cheers. -- Felipe Contreras
On Aug 15, 2012 3:32 PM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 2:16 PM, Thomas Bächler <thomas@archlinux.org>
wrote:
Am 15.08.2012 14:01, schrieb Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
> 1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
What argument? You _claim_ that it isn't simple, but you do not give any proof for that claim.
It is general knowledge that scripting languages are generally simpler than compiling languages.
But fine, compare a few lines of rc.sysinit:
# mount the API filesystems # /proc, /sys, /run, /dev, /run/lock, /dev/pts, /dev/shm mountpoint -q /proc || mount -t proc proc /proc -o nosuid,noexec,nodev mountpoint -q /sys || mount -t sysfs sys /sys -o nosuid,noexec,nodev mountpoint -q /run || mount -t tmpfs run /run -o mode=0755,nosuid,nodev mountpoint -q /dev || mount -t devtmpfs dev /dev -o mode=0755,nosuid mkdir -p /dev/{pts,shm} mountpoint -q /dev/pts || mount -t devpts devpts /dev/pts -o mode=0620,gid=5,nosuid,noexec mountpoint -q /dev/shm || mount -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
To their equivalent in systemd:
--- #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <string.h> #include <sys/stat.h> #include <sys/wait.h> #include <mntent.h>
#include "log.h" #include "util.h" #include "path-util.h" #include "set.h" #include "mount-setup.h" #include "exit-status.h"
/* Goes through /etc/fstab and remounts all API file systems, applying * options that are in /etc/fstab that systemd might not have * respected */
int main(int argc, char *argv[]) { int ret = EXIT_FAILURE; FILE *f = NULL; struct mntent* me; Hashmap *pids = NULL;
if (argc > 1) { log_error("This program takes no argument."); return EXIT_FAILURE; }
log_set_target(LOG_TARGET_AUTO); log_parse_environment(); log_open();
umask(0022);
f = setmntent("/etc/fstab", "r"); if (!f) { if (errno == ENOENT) { ret = EXIT_SUCCESS; goto finish; }
log_error("Failed to open /etc/fstab: %m"); goto finish; }
pids = hashmap_new(trivial_hash_func, trivial_compare_func); if (!pids) { log_error("Failed to allocate set"); goto finish; }
ret = EXIT_SUCCESS;
while ((me = getmntent(f))) { pid_t pid; int k; char *s;
/* Remount the root fs, /usr and all API VFS */ if (!mount_point_is_api(me->mnt_dir) && !path_equal(me->mnt_dir, "/") && !path_equal(me->mnt_dir, "/usr")) continue;
log_debug("Remounting %s", me->mnt_dir);
pid = fork(); if (pid < 0) { log_error("Failed to fork: %m"); ret = EXIT_FAILURE; continue; }
if (pid == 0) { const char *arguments[5]; /* Child */
arguments[0] = "/bin/mount"; arguments[1] = me->mnt_dir; arguments[2] = "-o"; arguments[3] = "remount"; arguments[4] = NULL;
execv("/bin/mount", (char **) arguments);
log_error("Failed to execute /bin/mount: %m"); _exit(EXIT_FAILURE); }
/* Parent */
s = strdup(me->mnt_dir); if (!s) { log_oom(); ret = EXIT_FAILURE; continue; }
k = hashmap_put(pids, UINT_TO_PTR(pid), s); if (k < 0) { log_error("Failed to add PID to set: %s", strerror(-k)); ret = EXIT_FAILURE; continue; } }
while (!hashmap_isempty(pids)) { siginfo_t si; char *s;
zero(si); if (waitid(P_ALL, 0, &si, WEXITED) < 0) {
if (errno == EINTR) continue;
log_error("waitid() failed: %m"); ret = EXIT_FAILURE; break; }
s = hashmap_remove(pids, UINT_TO_PTR(si.si_pid)); if (s) { if (!is_clean_exit(si.si_code, si.si_status, NULL)) { if (si.si_code == CLD_EXITED) log_error("/bin/mount for %s exited with exit status %i.", s, si.si_status); else log_error("/bin/mount for %s terminated by signal %s.", s, signal_to_string(si.si_status));
ret = EXIT_FAILURE; }
free(s); } }
finish:
if (pids) hashmap_free_free(pids);
if (f) endmntent(f);
return ret; } ---
If you think the second one is simpler, then I don't you know what 'simple' means.
> 2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear:
2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
Okay, where exactly does systemd violate that?
d-bus, for starters.
Dependencies that are * used widely - check
Not as widely as shell, and libc, and util-linux. Some Arch Linux users don't use D-Bus, in fact, and it's not by default added to rc.conf precisely for that reason.
* in most systems - check
Less than the Arch Linux systems that use initscripts.
* have few dependencies themselves - check
libx11 is a cheap dependency for you?
* are simple themselves - ahemm
D-Bus is extremely complicated. It's more than 100k likes of code.
So, dbus almost qualifies. You said "for starters", what others are
> 3./ Be easy to follow, fix and lockdown, best fit being interpreted > languages.
So, init should be a small binary in an interpreted language? Am I
Please stop spreading misinformation. libx11 is not an (indirect) dependency of systemd. there. the
only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Ah, you mean those. You do realize that we now used many of those tools in our initscripts, and I don't see you complaining about that.
That is dangerous, but not as dangerous as going full systemd.
But anyway, I am merely explaining what #3 means IMO.
There's probably plenty of reasons why they are in C, I don't know them. In any case, I don't see how making something in a scripting language is simpler - in contrast, I always find that writing a small C program for a task is easier and the result is more robust than a script.
And I find completely the opposite to be the case. Scripts are easier to write, read, and debug.
I'll stop discussing with you now, as this will lead nowhere. The fact remains that all you do is complain, instead of providing an alternative. The decisions are being made by the people who actually _maintain_ this stuff inside Arch.
The alternative is simple: stay with initscripts *at least* until the problems with systemd are sorted out.
I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems.
Cheers.
-- Felipe Contreras
On Aug 15, 2012 3:32 PM, "Felipe Contreras" <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 2:16 PM, Thomas Bächler <thomas@archlinux.org>
Am 15.08.2012 14:01, schrieb Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
> 1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
What argument? You _claim_ that it isn't simple, but you do not give any proof for that claim.
It is general knowledge that scripting languages are generally simpler than compiling languages.
But fine, compare a few lines of rc.sysinit:
# mount the API filesystems # /proc, /sys, /run, /dev, /run/lock, /dev/pts, /dev/shm mountpoint -q /proc || mount -t proc proc /proc -o nosuid,noexec,nodev mountpoint -q /sys || mount -t sysfs sys /sys -o nosuid,noexec,nodev mountpoint -q /run || mount -t tmpfs run /run -o mode=0755,nosuid,nodev mountpoint -q /dev || mount -t devtmpfs dev /dev -o mode=0755,nosuid mkdir -p /dev/{pts,shm} mountpoint -q /dev/pts || mount -t devpts devpts /dev/pts -o mode=0620,gid=5,nosuid,noexec mountpoint -q /dev/shm || mount -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev
To their equivalent in systemd:
--- #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <string.h> #include <sys/stat.h> #include <sys/wait.h> #include <mntent.h>
#include "log.h" #include "util.h" #include "path-util.h" #include "set.h" #include "mount-setup.h" #include "exit-status.h"
/* Goes through /etc/fstab and remounts all API file systems, applying * options that are in /etc/fstab that systemd might not have * respected */
int main(int argc, char *argv[]) { int ret = EXIT_FAILURE; FILE *f = NULL; struct mntent* me; Hashmap *pids = NULL;
if (argc > 1) { log_error("This program takes no argument."); return EXIT_FAILURE; }
log_set_target(LOG_TARGET_AUTO); log_parse_environment(); log_open();
umask(0022);
f = setmntent("/etc/fstab", "r"); if (!f) { if (errno == ENOENT) { ret = EXIT_SUCCESS; goto finish; }
log_error("Failed to open /etc/fstab: %m"); goto finish; }
pids = hashmap_new(trivial_hash_func, trivial_compare_func); if (!pids) { log_error("Failed to allocate set"); goto finish; }
ret = EXIT_SUCCESS;
while ((me = getmntent(f))) { pid_t pid; int k; char *s;
/* Remount the root fs, /usr and all API VFS */ if (!mount_point_is_api(me->mnt_dir) && !path_equal(me->mnt_dir, "/") && !path_equal(me->mnt_dir, "/usr")) continue;
log_debug("Remounting %s", me->mnt_dir);
pid = fork(); if (pid < 0) { log_error("Failed to fork: %m"); ret = EXIT_FAILURE; continue; }
if (pid == 0) { const char *arguments[5]; /* Child */
arguments[0] = "/bin/mount"; arguments[1] = me->mnt_dir; arguments[2] = "-o"; arguments[3] = "remount"; arguments[4] = NULL;
execv("/bin/mount", (char **) arguments);
log_error("Failed to execute /bin/mount: %m"); _exit(EXIT_FAILURE); }
/* Parent */
s = strdup(me->mnt_dir); if (!s) { log_oom(); ret = EXIT_FAILURE; continue; }
k = hashmap_put(pids, UINT_TO_PTR(pid), s); if (k < 0) { log_error("Failed to add PID to set: %s", strerror(-k)); ret = EXIT_FAILURE; continue; } }
while (!hashmap_isempty(pids)) { siginfo_t si; char *s;
zero(si); if (waitid(P_ALL, 0, &si, WEXITED) < 0) {
if (errno == EINTR) continue;
log_error("waitid() failed: %m"); ret = EXIT_FAILURE; break; }
s = hashmap_remove(pids, UINT_TO_PTR(si.si_pid)); if (s) { if (!is_clean_exit(si.si_code, si.si_status, NULL)) { if (si.si_code == CLD_EXITED) log_error("/bin/mount for %s exited with exit status %i.", s, si.si_status); else log_error("/bin/mount for %s terminated by signal %s.", s, signal_to_string(si.si_status));
ret = EXIT_FAILURE; }
free(s); } }
finish:
if (pids) hashmap_free_free(pids);
if (f) endmntent(f);
return ret; } ---
If you think the second one is simpler, then I don't you know what 'simple' means.
> 2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
No need to overreact, the meaning is clear:
2. Have as few dependencies as possible, preferably dependencies that are used widely in most systems and that have few dependencies themselves, and are simple themselves
Okay, where exactly does systemd violate that?
d-bus, for starters.
Dependencies that are * used widely - check
Not as widely as shell, and libc, and util-linux. Some Arch Linux users don't use D-Bus, in fact, and it's not by default added to rc.conf precisely for that reason.
* in most systems - check
Less than the Arch Linux systems that use initscripts.
* have few dependencies themselves - check
libx11 is a cheap dependency for you?
* are simple themselves - ahemm
D-Bus is extremely complicated. It's more than 100k likes of code.
So, dbus almost qualifies. You said "for starters", what others are
> 3./ Be easy to follow, fix and lockdown, best fit being interpreted > languages.
So, init should be a small binary in an interpreted language? Am I
wrote: there. the
only one who notices you are contradicting yourself.
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Ah, you mean those. You do realize that we now used many of those tools in our initscripts, and I don't see you complaining about that.
That is dangerous, but not as dangerous as going full systemd.
But anyway, I am merely explaining what #3 means IMO.
There's probably plenty of reasons why they are in C, I don't know them. In any case, I don't see how making something in a scripting language is simpler - in contrast, I always find that writing a small C program for a task is easier and the result is more robust than a script.
And I find completely the opposite to be the case. Scripts are easier to write, read, and debug.
But you are not the one writing or debugging our initscripts.
I'll stop discussing with you now, as this will lead nowhere. The fact remains that all you do is complain, instead of providing an alternative. The decisions are being made by the people who actually _maintain_ this stuff inside Arch.
The alternative is simple: stay with initscripts *at least* until the problems with systemd are sorted out.
I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems.
Please read the discussions that happened regarding systemd before you joined. You are repeating old arguments. Tom
Am 15.08.2012 15:31, schrieb Felipe Contreras:
What argument? You _claim_ that it isn't simple, but you do not give any proof for that claim.
It is general knowledge that scripting languages are generally simpler than compiling languages.
Here I wanted to stop discussing with you, but I can't let this BULLSHIT mail stand without a reply. An argument that starts with "It is general knowledge that ..." is no argument at all. I will disregard this.
But fine, compare a few lines of rc.sysinit:
[ short snippet of shell code ]
To their equivalent in systemd:
[ long snippet of C code ]
The problem with shell code is that you work with an abstraction of the actual interfaces that is made for interactive usage. Most of the error handling is done via human-readable messages, there is only a single error code for each command. This makes proper error handling in non-interactive situations a nightmare. Input is done with arguments that are shell-parsed, which is very error-prone and limits the programmer's ability to pass what he wants to. The added overhead of repeated parsing and string-converting makes shell scripts slower. Shell code is checked for correctness on runtime instead of build-time. This makes it very complicated to write functioning shell scripts for complex tasks. You might notice that our initscripts are unable to handle most errors gracefully, they just keep going if something goes horribly wrong.
If you think the second one is simpler, then I don't you know what 'simple' means.
You are again comparing apples with oranges. First you talk about 'init' being simple, your example shows our initscripts, which is not part of 'init'. Then you show a code snippet from systemd that does much more than the initscripts snippet and claim it is not as simple. By only reading a few lines in this short code example, I already found another feature in systemd that people always wanted for initscripts, but was too hard to implement, because writing shell scripts for advanced functionality is not simple at all. So what are you comparing now? Our initscripts to systemd, or sysvinit to systemd?
Dependencies that are * used widely - check
Not as widely as shell, and libc, and util-linux. Some Arch Linux users don't use D-Bus, in fact, and it's not by default added to rc.conf precisely for that reason.
* in most systems - check
Less than the Arch Linux systems that use initscripts.
You cannot remove dbus from the Linux ecosystem. It's in there, everything uses it. Period. If you don't use it now, then you don't have bluetooth and you need root privileges to (u)mount removable devices. And lots more. Most importantly, dbus has been stable for years. It hasn't crashed for me in years.
* have few dependencies themselves - check
libx11 is a cheap dependency for you?
And now we make up imaginary dependencies. Do your homework.
* are simple themselves - ahemm
D-Bus is extremely complicated. It's more than 100k likes of code.
No argument here.
And I find completely the opposite to be the case. Scripts are easier to write, read, and debug.
Feel free to replace those binaries with shell scripts that perform the same task. Once you're finished, I'd be happy to congratulate you on wasting your time.
I'll stop discussing with you now, as this will lead nowhere. The fact remains that all you do is complain, instead of providing an alternative. The decisions are being made by the people who actually _maintain_ this stuff inside Arch.
The alternative is simple: stay with initscripts *at least* until the problems with systemd are sorted out.
Isn't that what we are currently doing? We still provide initscripts and sort out systemd bugs.
I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems.
80% of the posts are random FUD about systemd. The other 20% are posts that address issues with systemd, which is part of the "sorting out systemd bugs". So, what exactly are you ranting about?
I already found another feature in systemd that people always wanted for initscripts, but was too hard to implement,
After posting so much pointless and wrong text aside from systemd can do some things a little quicker which we all know. Why haven't you told us this feature which would be worth posting.
You cannot remove dbus from the Linux ecosystem. It's in there, everything uses it. Period.
Absolute rubbish. Though it is certainly over used and depended upon. Like firefox having it as a compilation rather than runtime option making firefox harder to chroot well. That's quite relevent to systemdif you think about it.
If you don't use it now, then you don't have bluetooth and you need root privileges to (u)mount removable devices. And lots more.
More rubbish
Most importantly, dbus has been stable for years. It hasn't crashed for me in years.
Despite dbus being designed with security in mind, securing dbus even with selinux has proved difficult due to back channels etc.. IPC is even more used on Windows causing major security and other problems. Can I reiterate and unfortunately have to get personal. Despite the FUD lennart has made about systemd being required in the future, that simply isn't going to happen. At best he will make swathes of code difficult to use on some systems and give headaches to major distributions. The biggest of which has just moved to xfce by default from Gnome which is no longer the most used GUI. It seems it is often the questionable code that will require systemd and polkit so far too. -- _______________________________________________________________________ '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 15.08.2012 16:47, schrieb Kevin Chadwick:
I already found another feature in systemd that people always wanted for initscripts, but was too hard to implement,
After posting so much pointless and wrong text aside from systemd can do some things a little quicker which we all know. Why haven't you told us this feature which would be worth posting.
So, with initscripts, we mount all the API file systems manually. When you put them in fstab as well, things fail. But when you want special options for those file systems, you won't get them. This very short systemd snippet showed that systemd is capable of parsing fstab and remounting the API file systems such that all your options are respected. We tried this with initscripts before, and we couldn't make it work, as it was too complicated with shell scripts.
Despite the FUD lennart has made about systemd being required in the future, that simply isn't going to happen.
He didn't even say that. He said that he is not willing to spend his time making sure that future udev versions will work without systemd. I'm really tired of this discussion, so I deleted all my answer to the rest of your post.
On 2012-08-15 17:11, Thomas Bächler wrote:
So, with initscripts, we mount all the API file systems manually. When you put them in fstab as well, things fail. But when you want special options for those file systems, you won't get them.
This very short systemd snippet showed that systemd is capable of parsing fstab and remounting the API file systems such that all your options are respected.
We tried this with initscripts before, and we couldn't make it work, as it was too complicated with shell scripts.
As I always watch arch mailing list with interest (systemd adventures in particular) this grabbed my attention (not arch user anymore, but irrelevant). Leaving whole systemd vs. sysv discussion aside - it's perfectly doable. Not a trivial few-liner, but actually something barely bigger and not really complex - with help of some bash features. Important thing is how mount behaves depending if both the "device" (irrelevant with api mounts, but the rules stand) and the mountpoint are specified - or - only the mountpoint. That is - assuming the logic you need is essentially: 1) if in fstab, use its options, else use standard/manual options 2) if mounted (e.g. initramfs handover), remount, else mount Below is a fragment of bash (generally v4+ required, but can be toned down easily) function which is also responsile for handling basic mounts. For the record - shegrep(), ismnt() are in-bash few-liners to avoid dependency on external commands - short loops over input and /proc/self/mountinfo (inc. \040 conversion) respectively. The snippet below even checks if the required stuff is compiled in the kernel (though these days it can be just removed, hard to imagine system without tmpfs of devtmpfs ...). Either way, maybe this approach will be of use for you. local _fstab _x # $1 mount point to check against pre-read fstab function infstab() { local _i for ((_i = 0; _i < ${#_fstab[@]} ; i++)); do [[ ${_fstab[_i]} =~ ^[^#][^[:blank:]]*[[:blank:]]+([^[:blank:]]+) ]] || continue [[ ${BASH_REMATCH[1]} = "${1// /\040}" ]] && return 0 done return 1 } # $1 comma separated fs to try in turn # $2 opts # $3 dir function vmnt() { local _fs _opt _dev _x [[ -d $3 ]] || return # comma separated list is a bit paranoid, we should just assume # that stuff is properly compiled in kernel, API stuff in particular IFS=, eval _fs='( $1 )' for _x in "${_fs[@]}" ""; do shegrep -q "[[:blank:]]$_x$" </proc/filesystems && break done [[ -z $_x ]] && return # /paranoid # use options and "device" only if not in fstab infstab "$3" || { _opt=$2; _dev=$_x; } if ismnt "$3"; then _opt="-o remount${_opt:+,$_opt}" unset _fs else _opt="${_opt:+-o $_opt}" _fs="-t $_x" fi mount $_fs $_opt $_dev "$3" } # set proper time w.r.t. tz (this does not access rtc !) # this requires /etc/localtime to make sense (file or symlink+/usr # mounted) if [[ $HWCLKMODE = localtime && -r /etc/localtime ]]; then hwclock --localtime --systz --noadjfile fi # we assure /proc mount, then vmnt handles it (fstab opts and crap) # hard to live without proc :) and we have stuff depending on it [[ -d /proc/self ]] || mount -t proc -o "nosuid,noexec,nodev" proc /proc # preread fstab(s) mapfile -t _fstab < <(shopt -s nullglob; for _x in /etc/fsta[b] /etc/fstab.d/*; do echo "$(< "$_x")"; done) # early mounts # - might be handed over from initramfs, might be not # - might have sane mount options, might have not # - might be in fstab, might be not vmnt proc "nosuid,noexec,nodev" /proc vmnt sysfs "nosuid,noexec,nodev" /sys vmnt devtmpfs,tmpfs "mode=0755,nosuid" /dev mkdir -p -m 0755 /dev/{pts,shm} vmnt tmpfs "mode=1777,nosuid,nodev" /dev/shm vmnt devpts "mode=0620,gid=tty,nosuid,noexec" /dev/pts vmnt tmpfs "mode=0755,nosuid,nodev,exec" /run vmnt tmpfs "mode=0755,nosuid,nodev,exec" /sys/fs/cgroup ... and so on, whatever might be needed There're also few other things that are often claimed as hard/impossible with bash scripts - e.g. resilience against broken (hanging) rc scripts with banal help of mkfifo or full device detach with help of pivot_root - doing it in the same way systemd does (certainly it requires proper initramfs generator leaving necessary stuff in /run/initramfs to pivot to - or - something analogous or hell - even created in fly by shutdown script).
On 15 August 2012 21:31, Felipe Contreras <felipe.contreras@gmail.com> wrote:
I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems.
Felipe, I understand where you're coming from, and I can feel you. But, the fact remains that your conclusion is merely the result of these so-called problems with systemd that you yourself haven't experienced (assumption). I am not a systemd user myself, but I like what it wants to achieve, and I _will_ make the move sooner or later. You must also understand that there are bugs at http://bugs.archlinux.org/ as well, including bugs and feature requests related to initscripts. Systemd having its own problems - like all other software - is nothing out of the ordinary. Only when most of the fundemental issues are attended to can a move be realised. And that's exactly what we're doing with systemd. Nobody's giving you a half-assed init. Please think of systemd as the freedesktop.org specs for desktop files or graphical interoperability between distributions (X11, d-bus). It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take. We would've kept both if it were possible. It is obvious that we have to trade out old stuff to usher in the new. We just want to get rid of maintenance burden, and new stuff allow for that to happen. I'm sure there will be a separate project for those who religiously prefer to stick to the old ways. -- GPG/PGP ID: C0711BF1
On Wed, Aug 15, 2012 at 11:25 AM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
[...]
Please think of systemd as the freedesktop.org specs for desktop files or graphical interoperability between distributions (X11, d-bus). It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'.
^^^^ i think this is great point/perspective; one that i don't recall being mentioned as of late. -- C Anthony
On Wed, Aug 15, 2012 at 6:25 PM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
On 15 August 2012 21:31, Felipe Contreras <felipe.contreras@gmail.com> wrote:
I just subscribed to this list, and 80% of the traffic I'm seeing is problems with systemd. That should tell you something; systemd has problems.
Felipe, I understand where you're coming from, and I can feel you. But, the fact remains that your conclusion is merely the result of these so-called problems with systemd that you yourself haven't experienced (assumption). I am not a systemd user myself, but I like what it wants to achieve, and I _will_ make the move sooner or later.
Don't use the adjective 'so-called' problems, and I have experienced problems myself: 1) When Fedora switched, my system failed to boot 70% of the time 2) When I tried in Arch Linux it was twice as slow So your sentence would be: "But, the fact remains that your conclusion is merely the result of these problems with systemd". Well yeah! systemd has problems, and that's a problem.
You must also understand that there are bugs at http://bugs.archlinux.org/ as well, including bugs and feature requests related to initscripts. Systemd having its own problems - like all other software - is nothing out of the ordinary. Only when most of the fundemental issues are attended to can a move be realised. And that's exactly what we're doing with systemd. Nobody's giving you a half-assed init.
Have you been looking at arch-general? People are experiencing problems where their system doesn't boot. That's a half-assed init. Initially I liked systemd, but that was in theory, in practice it has too many problems, not only the real problems the people experience (not only in Arch Linux but in other distributions as well), but their development practices and philosophies. Sure all software has bugs, but some software has more bugs than others, and the bigger the changes the more possible bugs. And changing from initscripts to systemd is a *HUGE* change. And as any big change, there should be clear good reasons for it, but most importantly; you have to be *careful* while doing this migration. Fedora was careful (more than Arch Linux; by doing it step-by-step), and they still hit a lot of problems. And remember, not being able to boot is not "just another bug"; it's *big*. So, if you *already* know that there are problems, why not wait? What's wrong with waiting another year, and see if you don't see so many problems then? What's the hurry to break people's systems? Cheers. -- Felipe Contreras
On 16 August 2012 01:21, Felipe Contreras <felipe.contreras@gmail.com> wrote:
So, if you *already* know that there are problems, why not wait? What's wrong with waiting another year, and see if you don't see so many problems then? What's the hurry to break people's systems?
Felipe, we've been doing that all along. This _is_ in the process of 'another year', and we there was never any hurry. We have had a TODO list for the unit files for some time, and now we have made it a priority to complete it. In the meantime, we expect bugs will be reported from testers, and they will be fixed. I think you have misunderstood the situation; nobody's making any kind of 'move' tomorrow. -- GPG/PGP ID: C0711BF1
On Wed, Aug 15, 2012 at 8:18 PM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
On 16 August 2012 01:21, Felipe Contreras <felipe.contreras@gmail.com> wrote:
So, if you *already* know that there are problems, why not wait? What's wrong with waiting another year, and see if you don't see so many problems then? What's the hurry to break people's systems?
Felipe, we've been doing that all along. This _is_ in the process of 'another year', and we there was never any hurry. We have had a TODO list for the unit files for some time, and now we have made it a priority to complete it. In the meantime, we expect bugs will be reported from testers, and they will be fixed. I think you have misunderstood the situation; nobody's making any kind of 'move' tomorrow.
So if this is the 'another year' does that mean this *must* go in this year? No. If systemd is still not ready, why force it? Wait another year. And if the next year it's still not ready, then the next one. Why break systems *now*? Clearly there are problems with systemd (I see a lot of them in arch-general). Even if you were not seeing problems now, you should expect problems when deploying (as the machines affected would be many more). So if you are seeing problems *now*, that's a good sign that you shouldn't go forward, even if you manage to fix all the currently known problems. Cheers. -- Felipe Contreras
On Thu, Aug 16, 2012 at 9:08 AM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 8:18 PM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
On 16 August 2012 01:21, Felipe Contreras <felipe.contreras@gmail.com> wrote:
So, if you *already* know that there are problems, why not wait? What's wrong with waiting another year, and see if you don't see so many problems then? What's the hurry to break people's systems?
Felipe, we've been doing that all along. This _is_ in the process of 'another year', and we there was never any hurry. We have had a TODO list for the unit files for some time, and now we have made it a priority to complete it. In the meantime, we expect bugs will be reported from testers, and they will be fixed. I think you have misunderstood the situation; nobody's making any kind of 'move' tomorrow.
So if this is the 'another year' does that mean this *must* go in this year? No. If systemd is still not ready, why force it? Wait another year. And if the next year it's still not ready, then the next one.
Why break systems *now*? Clearly there are problems with systemd (I see a lot of them in arch-general).
Even if you were not seeing problems now, you should expect problems when deploying (as the machines affected would be many more). So if you are seeing problems *now*, that's a good sign that you shouldn't go forward, even if you manage to fix all the currently known problems.
Cheers.
-- Felipe Contreras
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most people systemd seems to work fine and is production ready (also evidenced by the fact that some other major distros have already made the switch some time ago). of course you will see people posting to the mailing list/bbs/irc with systemd issues, because *those are the places people go for help*. People post about issues with sysvinit/initscripts too. "I saw some a few people post with issues with systemd on the mailing list" is hardly a valid metric of whether its production ready or not. Systemd has already undergone a fair amount of testing in arch, many people were using it when it was in the aur, and many more when it made it to the repos. The experience has already smoothed out significantly. Teething issues will happen and will be dealt with.
On Thu, Aug 16, 2012 at 3:43 PM, Brandon Watkins <bwat47@gmail.com> wrote:
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most people systemd seems to work fine and is production ready (also evidenced by the fact that some other major distros have already made the switch some time ago).
It is best to do it sooner? Why? In order to maximize the breakage? No. It is best to do it later; to minimize the problems. Cheers. -- Felipe Contreras
On Thu, Aug 16, 2012 at 9:47 AM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:43 PM, Brandon Watkins <bwat47@gmail.com> wrote:
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most people systemd seems to work fine and is production ready (also evidenced by the fact that some other major distros have already made the switch some time ago).
It is best to do it sooner? Why? In order to maximize the breakage?
No. It is best to do it later; to minimize the problems.
Cheers.
-- Felipe Contreras
Doing it later does not necessarily "minimize" problems, in fact it can sometimes exacerbate problems.
On Thu, Aug 16, 2012 at 4:15 PM, Brandon Watkins <bwat47@gmail.com> wrote:
Doing it later does not necessarily "minimize" problems, in fact it can sometimes exacerbate problems.
No it doesn't, quite the opposite actually. Here, I'm going to do something that you are not doing, not just make an unsupported statement, but actually show an argument: the more mature a piece of software is, the less likely it is you are going to hit a bug. Can you do the same? Not just say "X is true", but "X is true because Y", if you don't, then there's no value in your statements. -- Felipe Contreras
On Thursday 16 Aug 2012 22:37:25 Felipe Contreras wrote:
On Thu, Aug 16, 2012 at 4:15 PM, Brandon Watkins <bwat47@gmail.com> wrote:
Doing it later does not necessarily "minimize" problems, in fact it can sometimes exacerbate problems.
No it doesn't, quite the opposite actually.
Here, I'm going to do something that you are not doing, not just make an unsupported statement, but actually show an argument: the more mature a piece of software is, the less likely it is you are going to hit a bug.
Can you do the same? Not just say "X is true", but "X is true because Y", if you don't, then there's no value in your statements.
@Felipe Brandon is saying from a developers perspective and you are saying from a user perspective. But, in case of ArchLinux and other distributions, its all the same. In commercial software which people are using and testing, adopting later is a good move because most of the bugs would have been ironed about by either the testing team or by the team of early testers. In a community like ArchLinux when compared to the bigger ecosystem of linux, the complete archcommunity is a tester. Earlier they test, earlier the problem can be found. Of course, you are free to adopt as late as possible, especially on your production system, and hence Tom has shown his intent to maintain initscripts as long as udev works with it. So, while you may not want to shift completely. you can try testing systemd everytime you have maintainance on your servers. Or if you have a desktop, you can try testing systemd once in a while and report errors, which can then be resolved. With the variety of computers existing, it is possible that every case reported here will be unique. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Of course, you are free to adopt as late as possible,
We are free to adopt never just with a lower chance of any support. It may be difficult to keep a thousand packages in check, it should not be difficult to keep the few each person uses in check and there will always be other distros without systemd which means it is splitting not unifying Linux and Unix-like systems in multiple ways. I run a grsecurity kernel and if I choose I can disable some security to run pulseaudio and flash, I work around it. I don't like the design of polkit and have no trust in it or it's author for various reasons that I won't start flames or spend time discussing. It's now powerless without any issue for me or my users. I wouldn't touch Avahi with a barge pole either. People stop mis-informing the community that systemd is something we have no choice but to use and better start learning it today. The powerful message of the Giants which had to be taller in those days and the code that Linus and others have built Linux upon of freedom and ***COMPLETE*** control is here to stay. It's a beautiful thing. Thankyou AT&T and especially it's companions who left us good rules to follow (some of which are no longer with us), the government at the time preventing a monopoly and the University of Berkely for re-writing and creating BSD and going to court, stopping AT&T and anyone else from ever controlling the code. -- _______________________________________________________________________ '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) _______________________________________________________________________
Hi, +1 for your post. I am really happy for the freedom too. But what I feel is either systemd, GNOME and stuff would takeover linux and drown. Or they will take over linux and flourish or they will be separated into their own Linux space and isolated. I have got a big feeling that they will not co-exist with other competing distributions. And if other distribution really do not like systemd then they would develop some other methods and it will be great for everyone. Here, is my analysis. Now on for something. First [1]. There Poettering says " I'd like to propose systemd (GPL2+,http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. Currently the interfacing between GNOME and systemd is minimal. Bastien has been implementing a UI for changing the host name via a configuration UI in the control center which uses a tiny mechanism daemon included in systemd as backend. GLib already exposes g_get_user_runtime_dir() which is a frontend for XDG_RUNTIME_DIR whose only implementation I know right now is in systemd." Okay, now according to fd.o specs, the XDG_RUNTIME_DIR can be set by any init process, so why should GNOME set systemd as a dependency, just because right now systemd is the only one who does the job? (Not Cool) He goes on more about how can systemd and GNOME interface more, but still just because GNOME can use systemd does not mean it should have it as its dependency, right? The dependency is init. Systemd is just filling the role of init. Doing a pacman -Qi on sysvinit gives initscripts depending on sysvinit and doing pacman -Qi on initscripts give no package depending on initscripts. Why should a package then depend on systemd? And now if Ubuntu does not like systemd, and if GNOME makes it a dependency, you will have a Unity-like fork. I am sure, there must be some similar discussion with GNOME and PulseAudio people and hence the problem we are not facing. If GNOME, systemd and pulseaudio pull out more stuff like that, the guys are either going to be isolated or have their way. Time will answer. Now for some rant. Next, we analyze LP's blog [1]. There he says "systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike." Why should we standardize? Ans by LP: adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. Balkanization in what space? It is not as if I could not use an app in ArchLinux but could use it in fedora because fedora used a different init system. I have not noticed this effect as an end-user, but probably developers did. If yes, I would like to know and I will take back my complaint. But people must remember the cost of throwing away the diverse efforts at the cost of reduced work. "Redefining what Linux platform is all about. " Linux platform is all about diversity of different systems which can be used as needed by a person. If systemd satisfies the multi-dimensional requirement, then great. Else, no. And only time will tell the future, so leave space for other init systems in future by not doing that dependency stuff I just described at top. How do you expect someone to develop a better init system that systemd if the person has to first be compliant to all systemd things before even getting started. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html [1] https://mail.gnome.org/archives/desktop-devel-list/2011- May/msg00427.html [2] http://0pointer.de/blog/projects/why.html
<offtopic> On Fri, Aug 17, 2012 at 01:25:46PM +0100, Kevin Chadwick wrote:
I wouldn't touch Avahi with a barge pole either.
Unfortunately I don't see any alternative to it. Can you point one out, if any? I use it for bonjour protocol support. </offtopic>
2012/8/17 Kevin Chadwick <ma1l1ists@yahoo.co.uk>:
Of course, you are free to adopt as late as possible,
We are free to adopt never just with a lower chance of any support. It may be difficult to keep a thousand packages in check, it should not be difficult to keep the few each person uses in check and there will always be other distros without systemd which means it is splitting not unifying Linux and Unix-like systems in multiple ways.
If their are 1000 users, for example. This is a split: 100 use Arch init script, 200 use Fedora init script, 300 use Debian init script, 400 use Megeia init script This is a unify: 980 use Systemd and the same service files, 20% Arch users chose to stay with initscripts. You can see the clear difference. Leon
-- _______________________________________________________________________
'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) _______________________________________________________________________
If their are 1000 users, for example. This is a split: 100 use Arch init script, 200 use Fedora init script, 300 use Debian init script, 400 use Megeia init script This is a unify: 980 use Systemd and the same service files, 20% Arch users chose to stay with initscripts.
You can see the clear difference.
I want some of whatever you are on. I guess you meant 800 use systemd. Except Systemd is a fraction of Unix users and likely always will be. -- _______________________________________________________________________ '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) _______________________________________________________________________
On Thu, Aug 16, 2012 at 10:47 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:43 PM, Brandon Watkins <bwat47@gmail.com> wrote:
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most people systemd seems to work fine and is production ready (also evidenced by the fact that some other major distros have already made the switch some time ago).
It is best to do it sooner? Why? In order to maximize the breakage?
You see, that's the attitude that really enfuriates me. Why post in such a provocative tone? He gave his arguments, you didn't reply. You just bitch cause you don't want to spend the time to fix your problems. I sent you some hints to debug systemd boot process and you ignored it. And now I will send you another one (see, I'm in a pacifist mood today): https://fedoraproject.org/wiki/How_to_debug_Systemd_problems I've found it in the bottom of the Arch wiki page for systemd. So, it's not hard to find information on how to solve problems. And remember, Arch is not about holding hands of any user. We should be competent enough to deal with our own problems. If you have to ask for help, you should be competent at it too, asking politely, doing your part, etc. -- 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 -------------------------------------------
On Thu, Aug 16, 2012 at 4:16 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Aug 16, 2012 at 10:47 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:43 PM, Brandon Watkins <bwat47@gmail.com> wrote:
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most people systemd seems to work fine and is production ready (also evidenced by the fact that some other major distros have already made the switch some time ago).
It is best to do it sooner? Why? In order to maximize the breakage?
You see, that's the attitude that really enfuriates me. Why post in such a provocative tone? He gave his arguments, you didn't reply.
No, he didn't, he made a totally unsupported claim with no evidence, and not even an argument "Its best to do it soon and get the teething issues over with.". The rest of his arguments are irrelevant, and in order to tackle them one would need to understand that it's impossible to prove a negative, but you seem to be unable to understand that, so I'm not going to try to explain it. But there's no point in even trying, because even if we assume he is right for the sake of argument (systemd is quite ready (it's not)), that still doesn't invalidate the first argument: the later the move, the safer.
You just bitch cause you don't want to spend the time to fix your problems. I sent you some hints to debug systemd boot process and you ignored it. And now I will send you another one (see, I'm in a pacifist mood today):
https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
I've found it in the bottom of the Arch wiki page for systemd. So, it's not hard to find information on how to solve problems.
Please. Not even Lennart was able to help me with my problem. Stop assuming there was/is an easy solution. Cheers. -- Felipe Contreras
On Thu, Aug 16, 2012 at 5:43 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:16 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Aug 16, 2012 at 10:47 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:43 PM, Brandon Watkins <bwat47@gmail.com> wrote:
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most people systemd seems to work fine and is production ready (also evidenced by the fact that some other major distros have already made the switch some time ago).
It is best to do it sooner? Why? In order to maximize the breakage?
You see, that's the attitude that really enfuriates me. Why post in such a provocative tone? He gave his arguments, you didn't reply.
No, he didn't, he made a totally unsupported claim with no evidence, and not even an argument "Its best to do it soon and get the teething issues over with.".
The rest of his arguments are irrelevant, and in order to tackle them one would need to understand that it's impossible to prove a negative, but you seem to be unable to understand that, so I'm not going to try to explain it.
But there's no point in even trying, because even if we assume he is right for the sake of argument (systemd is quite ready (it's not)), that still doesn't invalidate the first argument: the later the move, the safer.
You just bitch cause you don't want to spend the time to fix your problems. I sent you some hints to debug systemd boot process and you ignored it. And now I will send you another one (see, I'm in a pacifist mood today):
https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
I've found it in the bottom of the Arch wiki page for systemd. So, it's not hard to find information on how to solve problems.
Please. Not even Lennart was able to help me with my problem. Stop assuming there was/is an easy solution.
Yeah, I'm a realy stupid guy, trying to help a very smart one. I should know better. -- 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 -------------------------------------------
On Thu, Aug 16, 2012 at 3:50 PM, Denis A. Altoé Falqueto < denisfalqueto@gmail.com> wrote:
On Thu, Aug 16, 2012 at 4:16 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Thu, Aug 16, 2012 at 10:47 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:43 PM, Brandon Watkins <bwat47@gmail.com> wrote:
A big switch like this will have problems regardless of when you do it. Its best to do it soon and get the teething issues over with. For most
systemd seems to work fine and is production ready (also evidenced by
On Thu, Aug 16, 2012 at 5:43 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote: people the
fact that some other major distros have already made the switch some time ago).
It is best to do it sooner? Why? In order to maximize the breakage?
You see, that's the attitude that really enfuriates me. Why post in such a provocative tone? He gave his arguments, you didn't reply.
No, he didn't, he made a totally unsupported claim with no evidence, and not even an argument "Its best to do it soon and get the teething issues over with.".
The rest of his arguments are irrelevant, and in order to tackle them one would need to understand that it's impossible to prove a negative, but you seem to be unable to understand that, so I'm not going to try to explain it.
But there's no point in even trying, because even if we assume he is right for the sake of argument (systemd is quite ready (it's not)), that still doesn't invalidate the first argument: the later the move, the safer.
You just bitch cause you don't want to spend the time to fix your problems. I sent you some hints to debug systemd boot process and you ignored it. And now I will send you another one (see, I'm in a pacifist mood today):
https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
I've found it in the bottom of the Arch wiki page for systemd. So, it's not hard to find information on how to solve problems.
Please. Not even Lennart was able to help me with my problem. Stop assuming there was/is an easy solution.
Yeah, I'm a realy stupid guy, trying to help a very smart one. I should know better.
+1
Perhaps you're on the wrong distribution, Mr. Contreras. Based on the wikipages on ArchLinux' philosophy, it's all about being simple, but bleeding-edge, ahead-of-the-curve. According to one of the posts I've come across, Systemd seems to be what other less-aggressive distributions are using. Also, Arch has expressed clearly that it doesn't plan on being user-friendly. Besides being explicitly stated in the wiki, it is quite strongly implied at installation, with its lack of a user interface. If you want something stable, you could probably go with Debian. I recall reading that it isn't shifting to Systemd, and that its EXTREMELY stable.
So, if you *already* know that there are problems, why not wait? What's wrong with waiting another year, and see if you don't see so many problems then? What's the hurry to break people's systems?
Fedora still has grub2-beta which breaks multi-boot installs (a documented problem!). I'll just move on or maintain my section of init scripts if need be but If I was an arch dev. I'd expect less pain waiting until RedHat takes the plunge in it's stable OS. They have lots of money, why do the work for them but I guess many are using already? -- _______________________________________________________________________ '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) _______________________________________________________________________
On Thu, Aug 16, 2012 at 12:25:05AM +0800, Rashif Ray Rahman wrote:
Please think of systemd as the freedesktop.org specs for desktop files or graphical interoperability between distributions (X11, d-bus).
I'm trying to attach some meaning to that sentence, but so far I can't.
It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take.
That is completely upside down. Blindly accepting truth 'fom above'. in this case freedesktop.org, is a religious attitude. Refusing to do that certainly is not. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On 16 August 2012 03:46, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Thu, Aug 16, 2012 at 12:25:05AM +0800, Rashif Ray Rahman wrote:
Please think of systemd as the freedesktop.org specs for desktop files or graphical interoperability between distributions (X11, d-bus).
I'm trying to attach some meaning to that sentence, but so far I can't.
No problem. It is an analogy, though not meant to be a good one. 'Desktop files' and 'X11 interoperability' are indeed far away from 'core functionality' and 'init'. However, the point stands that it refers to freedesktop.org standards that distributions do follow.
It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take.
That is completely upside down. Blindly accepting truth 'fom above'. in this case freedesktop.org, is a religious attitude. Refusing to do that certainly is not.
Sorry, I do not recall anyone blindly accepting any kind of truth. It is simply a new way to do something, one that proposes to aid better in maintaining a GNU/Linux distribution. We simply realise its potential and adopt it, instead of fearing and comdemning it for its flaws. I do not see how this is a religious position. Rather, it is a rational one. -- GPG/PGP ID: C0711BF1
On Thu, Aug 16, 2012 at 04:12:58AM +0800, Rashif Ray Rahman wrote:
On 16 August 2012 03:46, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Thu, Aug 16, 2012 at 12:25:05AM +0800, Rashif Ray Rahman wrote:
It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take.
That is completely upside down. Blindly accepting truth 'fom above'. in this case freedesktop.org, is a religious attitude. Refusing to do that certainly is not.
Sorry, I do not recall anyone blindly accepting any kind of truth.
See above: "It is a new 'upstream' that we can rely on". s/upstream/god/ Haven't seen anything as close to blind faith as that recently. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Thu, Aug 16, 2012 at 04:12:58AM +0800, Rashif Ray Rahman wrote:
On 16 August 2012 03:46, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Thu, Aug 16, 2012 at 12:25:05AM +0800, Rashif Ray Rahman wrote:
It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take.
That is completely upside down. Blindly accepting truth 'fom above'. in this case freedesktop.org, is a religious attitude. Refusing to do that certainly is not.
Sorry, I do not recall anyone blindly accepting any kind of truth.
See above: "It is a new 'upstream' that we can rely on".
s/upstream/god/
Haven't seen anything as close to blind faith as that recently.
Ciao,
-- FA
A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
No one said they are blindly accepting anything upstream does without any
On Wed, Aug 15, 2012 at 4:33 PM, Fons Adriaensen <fons@linuxaudio.org>wrote: thought, you should stop putting words in people's mouths and making ridiculous accusation of 'religious fundamentalism'.
2012/8/16 Fons Adriaensen <fons@linuxaudio.org>:
On Thu, Aug 16, 2012 at 04:12:58AM +0800, Rashif Ray Rahman wrote:
On 16 August 2012 03:46, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Thu, Aug 16, 2012 at 12:25:05AM +0800, Rashif Ray Rahman wrote:
It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take.
That is completely upside down. Blindly accepting truth 'fom above'. in this case freedesktop.org, is a religious attitude. Refusing to do that certainly is not.
Sorry, I do not recall anyone blindly accepting any kind of truth.
See above: "It is a new 'upstream' that we can rely on".
s/upstream/god/
Haven't seen anything as close to blind faith as that recently.
Fellow upstream means: 1. Different distro join in effort to do one thing. Maybe systemd is indeed complex then initscript. Add If Arch is the only maintainer, the effort will be high. But the reality is all distro use systemd can debug it and improve it so Arch only need someting like a packager. 2. Services files will be upstreamd to their package, ie. networkmanager provide its own networkmanager.services file which can be used by all distro. So this is why Arch try to follow upstream as close as possible. Leon
Ciao,
-- FA
A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Wed, Aug 15, 2012 at 10:46 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
It is a new 'upstream' that we can rely on for running our GNU/Linux systems. It so happens that this time it's a core part of the system that's being 'standardised'. If you're not a fan of freedesktop.org, then I'm afraid that's a religious position you choose to take.
That is completely upside down. Blindly accepting truth 'fom above'. in this case freedesktop.org, is a religious attitude. Refusing to do that certainly is not.
You might think you're being sarcastic. But no, you are correct. Arch Linux is religious to upstreams. Arch tries to patch software as little as possible. When necessary, patches are applied only temporarily and sent to upstreams to make sure the software works on Arch. systemd is one step closer in that direction: vanilla systemd already does most of the Arch-specific init logic which is currently shipped in the "initscripts" package, and probably does it better. Upstream packages like postfix, udisks, smartmontools etc. already include systemd service files, so Arch developers don't need to maintain their own scripts. This means less fragmentation between Linux distribution and less maintenance burden on Arch developers. If you're looking for a distribution that's hell-bent on doing their own stuff to the detriment of upstreams, please try Ubuntu. Regards, Marti
According to Felipe Contreras: #It is general knowledge that scripting languages are generally simpler #than compiling languages. # #But fine, compare a few lines of rc.sysinit: # ## mount the API filesystems ## /proc, /sys, /run, /dev, /run/lock, /dev/pts, /dev/shm #mountpoint -q /proc || mount -t proc proc /proc -o #nosuid,noexec,nodev #mountpoint -q /sys || mount -t sysfs sys /sys -o #nosuid,noexec,nodev <snip> #To their equivalent in systemd: I do believe the C code is indeed simpler. I can't believe that a shell script that calls a compiled binary, i.e. mountpoint, is any more simple than the C code without an interveening script. So in the case of rc.sysinit, we have a shell script that calls compiled binaries, while also requiring an instance of Bash. In the case of systemd, we have a restrictive configuration format that is specifically designed to boot a system by calling compiled binaries when necessary. This is no different from calling these compiled binaries in a shell script, except for the fact that no shell is required to run systemd units, and the format of unit files is strictly designed for making the boot sequence work correctly, and therefore is much more simple. And if you needed to debug or patch the mountpoint binary as used in the snippit from rc.sysinit, you would find it just as simple or as difficult as debugging or patching systemd's C code that performs the same operations but doesn't need to be called over and over, since the loop is already in the systemd code. ~Kyle -- Kyle is a droid. The whole world knows it. This e-mail shows it.
On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
Here are my two cents about that: * I don't care about having a faster boot if the sequence is incorrect or buggy (or, worse, leaves me with an unbootable system) * I don't care about having a simpler boot if it doesn't work * I don't care about systemd or bash scripts as long as it is maintained and bug-fixed. The situation is: * I hate bash * I don't think bash scripts are simple at all * The current initscripts do not do what I expect them to do (being able to start services, notably when a dependency is not up). * I don't think we have enough manpower to maintain bash scripts like Debian folks do * I don't think we are looking for a replacement to /sbin/init, but we are definitely looking for a boot sequence that works I am personnally open to having something else than systemd but I do not see anyone showing an alternative. Rémy.
On Wed, Aug 15, 2012 at 2:17 PM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
Here are my two cents about that: * I don't care about having a faster boot if the sequence is incorrect or buggy (or, worse, leaves me with an unbootable system) * I don't care about having a simpler boot if it doesn't work * I don't care about systemd or bash scripts as long as it is maintained and bug-fixed.
Well, systemd is known to cause problems that render the system unbootable: https://www.google.com/search?q=systemd+unbootable -- Felipe Contreras
On Wed, Aug 15, 2012 at 9:11 AM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 2:17 PM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
> 1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
Here are my two cents about that: * I don't care about having a faster boot if the sequence is incorrect or buggy (or, worse, leaves me with an unbootable system) * I don't care about having a simpler boot if it doesn't work * I don't care about systemd or bash scripts as long as it is maintained and bug-fixed.
Well, systemd is known to cause problems that render the system unbootable: https://www.google.com/search?q=systemd+unbootable
-- Felipe Contreras
Are you serious? This post amounts to flame-bait at best. Almost all of the results from that search are about windows. You can google the same thing with sysvinit or initscripts and get bug reports too, so what is this supposed to prove?
On Wed, Aug 15, 2012 at 3:35 PM, Brandon Watkins <bwat47@gmail.com> wrote:
On Wed, Aug 15, 2012 at 9:11 AM, Felipe Contreras < felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 2:17 PM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
>> 1./ Be a small simple binary > > The systemd main binary is not very large (larger than sysvinit's > /sbin/init, but not by much).
But that binary alone is useless, and certainly not *simple*.
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
Here are my two cents about that: * I don't care about having a faster boot if the sequence is incorrect or buggy (or, worse, leaves me with an unbootable system) * I don't care about having a simpler boot if it doesn't work * I don't care about systemd or bash scripts as long as it is maintained and bug-fixed.
Well, systemd is known to cause problems that render the system unbootable: https://www.google.com/search?q=systemd+unbootable
-- Felipe Contreras
Are you serious? This post amounts to flame-bait at best. Almost all of the results from that search are about windows. You can google the same thing with sysvinit or initscripts and get bug reports too, so what is this supposed to prove?
Your settings must be screwing the results: Showing results for system unbootable Search instead for systemd unbootable <- Click here *Sigh* -- Felipe Contreras
/sbin/init from sysvinit alone is useless. What is your point?
The rest are rather simple scripts (in the case of Arch Linux).
And you are still ignoring the fact that systemd is anything but *simple*. How convenient to ignore that argument.
Those "simple scripts" are written in a Turing complete language for doing whatever, while unit files are much more constrained in what they can do and have been engineered to specify boot and daemon dependencies. It's surprising to see people calling shell scripts "simple." They are common, not simple. The basic idea behind systemd, as I understand it, *is* simple: specify only what needs to be specified about the boot process and daemon start-up and management. -- John K Pate http://jkpate.net/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
[2012-08-15 14:01:16 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Please just shut up when you obviously have no clue what you are talking about. -- Gaetan
On Wed, Aug 15, 2012 at 2:26 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-08-15 14:01:16 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Please just shut up when you obviously have no clue what you are talking about.
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup-g... http://cgit.freedesktop.org/systemd/systemd/tree/src/fsck/fsck.c http://cgit.freedesktop.org/systemd/systemd/tree/src/hostname/hostnamed.c http://cgit.freedesktop.org/systemd/systemd/tree/src/random-seed/random-seed... http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-ana... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-col... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-com... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-rep... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead.c http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/sd-readahead.... http://cgit.freedesktop.org/systemd/systemd/tree/src/shutdownd/shutdownd.c Do you need more? -- Felipe Contreras
[2012-08-15 15:08:21 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 2:26 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-08-15 14:01:16 +0200] Felipe Contreras:
On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.08.2012 13:34, schrieb Felipe Contreras:
No. The "services" (in systemd lingo) should be in an interpreted language: e.g. shell.
Why should they be? As far as I understand, they're human-readable text files. One might say this is an "interpreted language".
No, they are compiled binaries. The code is in C (not interpreted).
Please just shut up when you obviously have no clue what you are talking about.
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup-g... http://cgit.freedesktop.org/systemd/systemd/tree/src/fsck/fsck.c http://cgit.freedesktop.org/systemd/systemd/tree/src/hostname/hostnamed.c http://cgit.freedesktop.org/systemd/systemd/tree/src/random-seed/random-seed... http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-ana... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-col... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-com... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-rep... http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead.c http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/sd-readahead.... http://cgit.freedesktop.org/systemd/systemd/tree/src/shutdownd/shutdownd.c
Do you need more?
More random links? You were talking about '"services" (in systemd lingo)'; here is what this word means (hint: it's unrelated to your random links above): http://www.freedesktop.org/software/systemd/man/systemd.service.html -- Gaetan
Am 15.08.2012 11:21, schrieb Kevin Chadwick:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
Just 26 times as large and who knows how many times more complicated.
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
No it has the potential and freedom to do anything or nothing without the overhead of copying a much larger binary when forking processes or imposing any limitations.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
Twisting my words yet again like so many other posts which are pro systemd. Without a C library which was invented as the heart of UNIX you wouldn't have a UNIX-like OS or any general OS including Windows. Here's a list of dependencies for you. There are likely many kernel CONFIG options and modules required than the couple listed here and likely growing. cgroups, dbus, ipv6, udev, kmod, pam, libcap I'll respect the devs wishes now no matter how wrong any posts about this subject are or how compelled I am to correct the record. -- _______________________________________________________________________ '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) _______________________________________________________________________
On 2012/8/15 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Am 15.08.2012 11:21, schrieb Kevin Chadwick:
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
Just 26 times as large and who knows how many times more complicated.
systemd has not the same purpose that /sbin/init. You are comparing completely different things.
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
No it has the potential and freedom to do anything or nothing without the overhead of copying a much larger binary when forking processes or imposing any limitations.
Forking processes does not copy binaries.
Twisting my words yet again like so many other posts which are pro systemd. Without a C library which was invented as the heart of UNIX you wouldn't have a UNIX-like OS or any general OS including Windows.
Here's a list of dependencies for you. There are likely many kernel CONFIG options and modules required than the couple listed here and likely growing.
cgroups, dbus, ipv6, udev, kmod, pam, libcap
These dependencies just enumerate basic system administration tools in the form of libraries. A boot procedure relying on shell scripts would have the same dependencies as commands, that doesn't make any difference. I am not pro-systemd at all, I'm even rather for alternatives. Please don't make the pro-alternative arguments ridiculous. Rémy.
On Wed, Aug 15, 2012 at 5:40 PM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
cgroups, dbus, ipv6, udev, kmod, pam, libcap
These dependencies just enumerate basic system administration tools in the form of libraries. A boot procedure relying on shell scripts would have the same dependencies as commands, that doesn't make any difference.
I am not pro-systemd at all, I'm even rather for alternatives. Please don't make the pro-alternative arguments ridiculous.
You don't *need* cgroups or dbus if you don't use them in Arch Linux. -- Felipe Contreras
Forking processes does not copy binaries.
Pulled out of silence for the very very last time. It copies the parent which is much larger is what I meant. A real problem for embedded where memory fragmentation matters to the point that Google had code written just to handle it. The smaller the device, the greater the issue tends to be.
Twisting my words yet again like so many other posts which are pro systemd. Without a C library which was invented as the heart of UNIX you wouldn't have a UNIX-like OS or any general OS including Windows.
Here's a list of dependencies for you. There are likely many kernel CONFIG options and modules required than the couple listed here and likely growing.
cgroups, dbus, ipv6, udev, kmod, pam, libcap
These dependencies just enumerate basic system administration tools in the form of libraries. A boot procedure relying on shell scripts would ^^^^
have the same dependencies as commands, that doesn't make any difference.
may or may not have the same dependencies as commands -- _______________________________________________________________________ '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) _______________________________________________________________________
On Wednesday 15 Aug 2012 18:54:24 Kevin Chadwick wrote:
Forking processes does not copy binaries.
Pulled out of silence for the very very last time.
It copies the parent which is much larger is what I meant. A real problem for embedded where memory fragmentation matters to the point that Google had code written just to handle it. The smaller the device, the greater the issue tends to be.
I don't think this is true. If I understand correctly, the code segment of the executable image is shared between forks, meaning that the binary size is irrelevant. http://en.wikipedia.org/wiki/Fork_%28operating_system%29 Paul
On Wednesday 15 Aug 2012 18:54:24 Kevin Chadwick wrote:
Forking processes does not copy binaries.
Pulled out of silence for the very very last time.
It copies the parent which is much larger is what I meant. A real problem for embedded where memory fragmentation matters to the point that Google had code written just to handle it. The smaller the device, the greater the issue tends to be.
I don't think this is true. If I understand correctly, the code segment of the executable image is shared between forks, meaning that the binary size is irrelevant.
http://en.wikipedia.org/wiki/Fork_%28operating_system%29
Paul
Thanks for the link. I understand a little more. I'm not completely clear yet but it seems that it is not as significant as I thought for Android assuming the speed increase of parallelism is greater than the extra work in COW which may be on slow memory though Google have made a custom far more memory efficient init than SysV even, so I can't see it happening. http://www.netbsd.org/docs/kernel/vfork.html For deep/true embedded systems with only vfork and no COW it seems you are right and the simple explanation of vfork is actually inaccurate these days however the parent has to be blocked to utilise the parents memory but once the exec has happend which could be quick the parent is unblocked so maybe systemd could be made compatible with a kind of parallelism. I guess it would take a lot more work and absolutely required memory usage would have to be reduced significantly in any case. Lennart said systemd will only ever run on Linux and is only designed for a full fledged Fedora but is useful on embedded too. However I don't think he realised what level the Linux embedded world could expand to. -- _______________________________________________________________________ '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) _______________________________________________________________________
On 2012/8/16 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Lennart said systemd will only ever run on Linux and is only designed for a full fledged Fedora but is useful on embedded too. However I don't think he realised what level the Linux embedded world could expand to.
As far as I know, Archlinux does not target non-x86 embedded devices. Some derived projects like ArchlinuxARM may do so, but their decisions are totally independent from the desktop Archlinux team. Rémy.
Lennart said systemd will only ever run on Linux and is only designed for a full fledged Fedora but is useful on embedded too. However I don't think he realised what level the Linux embedded world could expand to.
As far as I know, Archlinux does not target non-x86 embedded devices. Some derived projects like ArchlinuxARM may do so, but their decisions are totally independent from the desktop Archlinux team.
Yes but there is an effort to bring it all closer not further apart for the benefit of all including arch which is why the linux kernel supports embedded devices. Great effort has been made to make the extremely complex kernel extremely configurable and some userland will now be letting the side down because of code that has come from somewhere where financial/enterprise multi-seat desktop interests are paramount. -- _______________________________________________________________________ '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) _______________________________________________________________________
heh I don't believe they fully understand how things work. On Wed, Aug 15, 2012 at 7:15 AM, Thomas Bächler <thomas@archlinux.org>wrote:
Am 15.08.2012 11:21, schrieb Kevin Chadwick:
I'd love to see the overall advantages and disadvantages of each of those fleshed out on a page where I can read them
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
The systemd main binary is not very large (larger than sysvinit's /sbin/init, but not by much).
2./ Have no dependencies
That is pure BS. If something has no dependencies, it has to do everything in the binary itself. You either end up with no features, or potential for tons of bugs.
Having NO dependencies also means you have to bypass the C library and implement everything from scratch - that is the worst idea ever.
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
So, init should be a small binary in an interpreted language? Am I the only one who notices you are contradicting yourself.
4./ be as fast as possible
systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better
Where are your AUR packages that provide OpenBSD's init? I haven't seen them.
On Wed, Aug 15, 2012 at 10:21:25AM +0100, Kevin Chadwick wrote:
Here's one part
A good design would make the init process which is always running and everyone must run.
1./ Be a small simple binary
2./ Have no dependencies
3./ Be easy to follow, fix and lockdown, best fit being interpreted languages.
4./ be as fast as possible
systemd meets 4. Sysvinit meets 1-3 well but OpenBSDs init meets 1-3 better
And daemontools satisfies all of the above!
participants (32)
-
Anthony ''Ishpeck'' Tedjamulia
-
Brandon Watkins
-
C Anthony Risinger
-
Calvin Morrison
-
cesar de padua
-
David Benfell
-
Denis A. Altoé Falqueto
-
Felipe Contreras
-
Fons Adriaensen
-
Gaetan Bisson
-
gt
-
Hilton Medeiros
-
Jayesh Badwaik
-
Jelle van der Waa
-
John K Pate
-
Justin Strickland
-
Kevin Chadwick
-
Kyle
-
Leon Feng
-
Leonid Isaev
-
Marti Raudsepp
-
Michal Soltys
-
Nicholas MIller
-
Oon-Ee Ng
-
Paul Gideon Dann
-
Rashif Ray Rahman
-
Rodrigo Rivas
-
Rémy Oudompheng
-
Thomas Bächler
-
Thomas Rand
-
Timothy Rice
-
Tom Gundersen