[opensuse-factory] new package: upstart
Hi, I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows. For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Stephan Kulow <coolo@novell.com> [2010-02-12 12:32]:
I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
If speeding up the bootup process is a concern, considering that the execution of bootup scripts is already parallelized, wouldn't it be more productive to switch to a faster shell for init scripts? Quoting https://wiki.ubuntu.com/DashAsBinSh: The boot speed improvements in Ubuntu 6.10 were often incorrectly attributed to Upstart, which is a fine platform for future development of the init system but in Ubuntu 6.10 was primarily running in System V compatibility mode with only small behavioural changes. These improvements were in fact largely due to the changed /bin/sh. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason. Karsten Am Freitag, 12. Februar 2010 14:22:42 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@novell.com> [2010-02-12 12:32]:
I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
If speeding up the bootup process is a concern, considering that the execution of bootup scripts is already parallelized, wouldn't it be more productive to switch to a faster shell for init scripts?
Quoting https://wiki.ubuntu.com/DashAsBinSh:
The boot speed improvements in Ubuntu 6.10 were often incorrectly attributed to Upstart, which is a fine platform for future development of the init system but in Ubuntu 6.10 was primarily running in System V compatibility mode with only small behavioural changes. These improvements were in fact largely due to the changed /bin/sh.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Feb 12, 2010 at 02:31:21PM +0100, Karsten König wrote:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
Are there any statistics about the effects? Not only faster booting but also the side effects like required chnages on third party scripts and even the side effects on using the (g)libc system standard function call system(3). Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag, 12. Februar 2010 14:44:29 schrieb Dr. Werner Fink:
On Fri, Feb 12, 2010 at 02:31:21PM +0100, Karsten König wrote:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
Are there any statistics about the effects? Not only faster booting but also the side effects like required chnages on third party scripts and even the side effects on using the (g)libc system standard function call system(3).
Werner
Uh I don't know about any, I was hoping somebody frequenting the Debian Community might know about them =) As coolo outlined debian worked quite some time on their initscripts to remove bashisms, I think they had a script to check all their initscripts and autofile a bugreport if it found a bashonly script. Still it'd be nice to see if they had any advantage after doing the switch, if this is about 3% less boot time it's propably not worth the effort for 11.3. Btw., it looks to me like most distributions ship their own init scripts for all the daemons, even when they use the same init system, couldn't this effort be unified? Karsten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 12 février 2010, à 14:44 +0100, Dr. Werner Fink a écrit :
On Fri, Feb 12, 2010 at 02:31:21PM +0100, Karsten König wrote:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
Are there any statistics about the effects? Not only faster booting but also the side effects like required chnages on third party scripts and even the side effects on using the (g)libc system standard function call system(3).
Note that Debian using dash as /bin/sh by default probably helps upstream people to fix the shell scripts, so I would expect we wouldn't have too many changes to do (we'd still have to fix things, but Debian really did the big part of the work) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Dr. Werner Fink <werner@suse.de> [2010-02-12 14:47]:
On Fri, Feb 12, 2010 at 02:31:21PM +0100, Karsten König wrote:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
Are there any statistics about the effects? Not only faster booting but also the side effects like required chnages on third party scripts and even the side effects on using the (g)libc system standard function call system(3).
Here are the changes that were necessary in Debian: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-release@lists.debian.org&tag=goal-dash A summary of the side effects can be found here: http://www.mail-archive.com/debian-devel@lists.debian.org/msg274568.html -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 12 February 2010 21:02:03 Guido Berhoerster wrote:
* Dr. Werner Fink <werner@suse.de> [2010-02-12 14:47]:
On Fri, Feb 12, 2010 at 02:31:21PM +0100, Karsten König wrote:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
Are there any statistics about the effects? Not only faster booting but also the side effects like required chnages on third party scripts and even the side effects on using the (g)libc system standard function call system(3).
Here are the changes that were necessary in Debian: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-release@lists.deb ian.org&tag=goal-dash
A summary of the side effects can be found here: http://www.mail-archive.com/debian-devel@lists.debian.org/msg274568.html
Are there any volunteers to drive such an effort for openSUSE? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 13 February 2010 10:27:23 Stephan Kulow wrote:
Are there any volunteers to drive such an effort for openSUSE? There is not even a dash package in all the build service.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Stephan Kulow <coolo@novell.com> [2010-02-13 10:40]:
There is not even a dash package in all the build service.
I'll package it. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Stephan Kulow <coolo@novell.com> [2010-02-13 10:40]:
There is not even a dash package in all the build service.
There is now a preliminary package of dash 0.5.5.1 at project home:gberh:Extra. It does not use update-alternatives yet as the bash package would need to be changed first. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 13 February 2010 13:33:49 Guido Berhoerster wrote:
* Stephan Kulow <coolo@novell.com> [2010-02-13 10:40]:
There is not even a dash package in all the build service.
There is now a preliminary package of dash 0.5.5.1 at project home:gberh:Extra. It does not use update-alternatives yet as the bash package would need to be changed first.
Please submit it to shells and I'll add you as maintainer, then you can push it to factory. Changing it to update-alternatives can be done later - for now you need to have an easy way to switch and ln -sf is easy enough for alpha testers :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag 12 Februar 2010 schrieb Karsten König:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
Debian also has a long history of providing alternatives for /bin/sh - when I did debian packages in '99 I got plenty of bug reports when a KDE script used /bin/sh and was using bash syntax. If you have that, worrying about the default is less of a pain - SUSE used /bin/sh as bash for years and changing that will make many people cry I'm afraid. So first step would be: volunteers to run their system with ash as /bin/sh and provide bug reports for shells using bash syntax. I once did it myself, but my time is limited, but e.g. see hal.changes: Fri Jan 23 14:53:21 CET 2009 - coolo@suse.de - init script should work with strict /bin/sh too Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Karsten König <remur@gmx.net> [2010-02-12 14:32]:
Debian switched to dash in Unstable/Testing a in Summer 2009, maybe they have produced some statistics about the effects? They aren't usually doing such intrusive changes without good reason.
You can find the rationale here: http://www.mail-archive.com/debian-release@lists.debian.org/msg18400.html http://www.mail-archive.com/debian-devel@lists.debian.org/msg274568.html Here is the empirical data that is referred to: http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/deliverable3.html http://wiki.debian.org/DebianEeePC/Dash -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Feb 12, 2010 at 02:22:42PM +0100, Guido Berhoerster wrote:
* Stephan Kulow <coolo@novell.com> [2010-02-12 12:32]:
I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
If speeding up the bootup process is a concern, considering that the execution of bootup scripts is already parallelized, wouldn't it be more productive to switch to a faster shell for init scripts?
Quoting https://wiki.ubuntu.com/DashAsBinSh:
The boot speed improvements in Ubuntu 6.10 were often incorrectly attributed to Upstart, which is a fine platform for future development of the init system but in Ubuntu 6.10 was primarily running in System V compatibility mode with only small behavioural changes. These improvements were in fact largely due to the changed /bin/sh.
AFAIK dash is not POSIX fully complied nor compatible with /bin/bash its self ... and IMHO it is a myth that dash in comparision with bash would speed up the boot process a lot. E.g. this because I've start up of the bash a lot by using a larger runtime linker cache and also removed the -PIE linker option ... in fact the bash starts up faster but this was not visible in the boot process its self. The bottlenecks are normally given by I/O load of the system its self and the numbers of required fork()/execve() pairs. Beside this many scripts have to be rewritten in case of using dash as /bin/sh ... even third party scripts. We're already booting scripts in parallel even with the old sysvinit. But, nevertheless, one advantage of upstart over the old sysvinit is the possiblity to define event driven actions. This enables us to move statically boot scripts into the event driven bay to be able to enable a resource on runtime demand. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
"Dr. Werner Fink" <werner@suse.de> wrote:
AFAIK dash is not POSIX fully complied nor compatible with /bin/bash its self ... and IMHO it is a myth that dash in comparision with bash would speed up the boot process a lot. E.g. this because I've start up of the bash a lot by using a larger runtime linker cache and also removed the -PIE linker option ... in fact the bash starts up faster but this was not visible in the boot process its self.
I cannot speak for dash but bash-3.x is absolutely not POSIX, bash-4.x has become better. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Feb 12, 10 17:13:41 +0100, Joerg Schilling wrote:
I cannot speak for dash but bash-3.x is absolutely not POSIX, bash-4.x has become better.
Please don't say 'absolutely not POSIX' where the package has a dedicated POSIX mode. This is misleading. I am certain, I can find at least one POSIX feature. :-)= cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Dr. Werner Fink <werner@suse.de> [2010-02-12 14:42]:
AFAIK dash is not POSIX fully complied nor compatible with /bin/bash its self ... and IMHO it is a myth that dash in
dash is actively maintained and SUSv3 incompatibilities are being fixed, see the Debian bugtracker. At least bash 3.x is far from SUSv3 compliant.
comparision with bash would speed up the boot process a lot. E.g. this because I've start up of the bash a lot by using a larger runtime linker cache and also removed the -PIE linker option ... in fact the bash starts up faster but this was not visible in the boot process its self.
The bottlenecks are normally given by I/O load of the system its self and the numbers of required fork()/execve() pairs.
On Debian it does speed up the boot process but its scripts are not executed in parallel.
Beside this many scripts have to be rewritten in case of using dash as /bin/sh ... even third party scripts.
Much work on this has already been done in Ubuntu and Debian. Using /bin/sh and expecting bash is simply a bug and should be fixed upstream. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Feb 12, 2010 at 08:58:00PM +0100, Guido Berhoerster wrote:
* Dr. Werner Fink <werner@suse.de> [2010-02-12 14:42]:
AFAIK dash is not POSIX fully complied nor compatible with /bin/bash its self ... and IMHO it is a myth that dash in
dash is actively maintained and SUSv3 incompatibilities are being fixed, see the Debian bugtracker. At least bash 3.x is far from SUSv3 compliant.
comparision with bash would speed up the boot process a lot. E.g. this because I've start up of the bash a lot by using a larger runtime linker cache and also removed the -PIE linker option ... in fact the bash starts up faster but this was not visible in the boot process its self.
The bottlenecks are normally given by I/O load of the system its self and the numbers of required fork()/execve() pairs.
On Debian it does speed up the boot process but its scripts are not executed in parallel.
AFAIK Debian the package insserv and also the tool startpar is already known ;) Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Dr. Werner Fink <werner@suse.de> [2010-02-15 14:36]:
AFAIK Debian the package insserv and also the tool startpar is already known ;)
It is being worked on, however it is disabled and not working on Lenny, in fact I just checked on my server running Lenny that insserv is not even in the default install. It is a release goal for Squeeze, but then it used to be one for Lenny. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag 12 Februar 2010 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@novell.com> [2010-02-12 12:32]:
I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
If speeding up the bootup process is a concern, considering that Who said speeding the boot process has _anything_ to do with this? I surely didn't.
the execution of bootup scripts is already parallelized, wouldn't it be more productive to switch to a faster shell for init scripts?
Quoting https://wiki.ubuntu.com/DashAsBinSh:
The boot speed improvements in Ubuntu 6.10 were often incorrectly attributed to Upstart, which is a fine platform for future development of the init system but in Ubuntu 6.10 was primarily running in System V compatibility mode with only small behavioural changes. These improvements were in fact largely due to the changed /bin/sh.
Guido, it's a wiki - everyone can claim things in there. Let's say we start 30 init scripts during boot that will all do similiar things as the nscd script that I used for testing (things they do on top are hardly interesting as this will be very likely not be written in shell). With bash you get: coolo@desdemona#~>time /bin/bash -c "/etc/init.d/nscd status > /dev/null 2>&1" real 0m0.028s user 0m0.006s sys 0m0.009s Now let's assume there was a shell that would run the same in 1ms instead of 28 (I once had a dash compiled, but somehow I lost it - ash runs it in 38ms), then you would gain 30 * 27 ms - 810ms. More realistically you would cave 0-200ms. Now say how that is effective? Of course if we have init scripts that are program too much stuff in a language not made for speed (shell), then these should be changed - not to perl and python programs as often done but into small compiled programs. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stephan Kulow wrote:
Of course if we have init scripts that are program too much stuff in a language not made for speed (shell), then these should be changed - not to perl and python programs as often done but into small compiled programs.
There are also ways to speed up shell scripts. Like e.g. using bash builtins instead of using several fork/exec to be compatible with an ancient /bin/sh... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag 12 Februar 2010 schrieb Ludwig Nussel:
Stephan Kulow wrote:
Of course if we have init scripts that are program too much stuff in a language not made for speed (shell), then these should be changed - not to perl and python programs as often done but into small compiled programs.
There are also ways to speed up shell scripts. Like e.g. using bash builtins instead of using several fork/exec to be compatible with an ancient /bin/sh...
And it should be noted that this is fine and also used in Debian: just with a #! /bin/bash line Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Stephan Kulow <coolo@novell.com> [2010-02-12 14:49]:
of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
If speeding up the bootup process is a concern, considering that Who said speeding the boot process has _anything_ to do with this? I surely didn't.
No, but that was a major topic at https://features.opensuse.org/305690
Guido, it's a wiki - everyone can claim things in there. Let's say we start
Debian is switching as well for speed reasons, see http://www.mail-archive.com/debian-release@lists.debian.org/msg18400.html http://www.mail-archive.com/debian-devel@lists.debian.org/msg274568.html There is empricical data to back this up on Debian: http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/deliverable3.html http://wiki.debian.org/DebianEeePC/Dash This may not be applicable to opnsSUSE though as Debian init scripts do AFAIK not in parallel.
30 init scripts during boot that will all do similiar things as the nscd script that I used for testing (things they do on top are hardly interesting as this will be very likely not be written in shell). With bash you get:
coolo@desdemona#~>time /bin/bash -c "/etc/init.d/nscd status > /dev/null 2>&1" real 0m0.028s user 0m0.006s sys 0m0.009s
Now let's assume there was a shell that would run the same in 1ms instead of 28 (I once had a dash compiled, but somehow I lost it - ash runs it in 38ms), then you would gain 30 * 27 ms - 810ms. More realistically you would cave 0-200ms. Now say how that is effective?
I don't think that is an adequate benchmark. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 12 February 2010 20:31:04 Guido Berhoerster wrote:
Now let's assume there was a shell that would run the same in 1ms instead of 28 (I once had a dash compiled, but somehow I lost it - ash runs it in 38ms), then you would gain 30 * 27 ms - 810ms. More realistically you would cave 0-200ms. Now say how that is effective?
I don't think that is an adequate benchmark.
I invite you to do your own benchmarks. I'm claiming debian numbers do not apply to openSUSE. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 13 February 2010 09:39:00 Stephan Kulow wrote:
On Friday 12 February 2010 20:31:04 Guido Berhoerster wrote:
Now let's assume there was a shell that would run the same in 1ms instead of 28 (I once had a dash compiled, but somehow I lost it - ash runs it in 38ms), then you would gain 30 * 27 ms - 810ms. More realistically you would cave 0-200ms. Now say how that is effective?
I don't think that is an adequate benchmark.
I invite you to do your own benchmarks. I'm claiming debian numbers do not apply to openSUSE.
Having said that: I'm not opposed to change /bin/sh default if it makes sense. But if boot speed is the only argument, I question the sense of it unless someone provided numbers/bootcharts. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 12 Feb 2010 12:32:36 +0100 Stephan Kulow <coolo@novell.com> wrote:
Hi,
I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
Is it only me, or does upstart's init need 10 times more RAM than sysvinit's init? Does not seem to be a good alternative... strolchi:~ # ps u 1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 1984 136 ? Ss Mar22 0:01 init [5] vs. linux-vovj:~ # ps u 1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.2 0.1 2752 1412 ? Ss 16:41 0:01 /sbin/init Both machines are pretty similar: current FACTORY, i586, 1G of RAM, Dothan 1.7GHz -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Dienstag 23 März 2010 schrieb Stefan Seyfried:
On Fri, 12 Feb 2010 12:32:36 +0100
Stephan Kulow <coolo@novell.com> wrote:
Hi,
I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows.
For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives.
Is it only me, or does upstart's init need 10 times more RAM than sysvinit's init? Does not seem to be a good alternative...
I never said upstart is a 100% replacement of sysvinit. It has a completely different feature set and we're not using many of it yet. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (9)
-
Dr. Werner Fink -
Guido Berhoerster -
Joerg.Schilling＠fokus.fraunhofer.de -
Juergen Weigert -
Karsten König -
Ludwig Nussel -
Stefan Seyfried -
Stephan Kulow -
Vincent Untz