hey,
i was looking on this page: http://fedoraproject.org/wiki/Releases/FeatureNewInit
it says: Targeted release: Fedora 7http://fedoraproject.org/wiki/Releases/7 so i`m wondering.. will fedora core 7 have a new init system? if i`m correct it`s not in at this moment (using beta 3)
Mark.
On 4/1/07, Mark markg85@gmail.com wrote:
hey,
i was looking on this page: http://fedoraproject.org/wiki/Releases/FeatureNewInit
it says: Targeted release: Fedora 7http://fedoraproject.org/wiki/Releases/7 so i`m wondering.. will fedora core 7 have a new init system? if i`m correct it`s not in at this moment (using beta 3)
no, we already passed the feature freeze, looks like F8 stuff ;)
Mark.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
oh.. sad to hear that.. will that be a new init stuff be in for FC8? (yea.. fedora can really use a startup boost :P default installation takes a full minute to start)
Mark.
2007/4/1, dragoran dragoran drago01@gmail.com:
On 4/1/07, Mark markg85@gmail.com wrote:
hey,
i was looking on this page: http://fedoraproject.org/wiki/Releases/FeatureNewInit
it says: Targeted release: Fedora 7http://fedoraproject.org/wiki/Releases/7 so i`m wondering.. will fedora core 7 have a new init system? if i`m correct it`s not in at this moment (using beta 3)
no, we already passed the feature freeze, looks like F8 stuff ;)
Mark.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, 2007-04-02 at 00:47 +0200, Mark wrote:
oh.. sad to hear that.. will that be a new init stuff be in for FC8? (yea.. fedora can really use a startup boost :P default installation takes a full minute to start)
It's a popular misconception that boot time can be "boosted" by just replacing SysVinit with something else. The biggest bang for the buck actually comes from fixing readahead so it reads all the files it needs, without making the disk seek; see [1] for some old experiments I did 2.5 years ago. The good news, however, is that the readahead maintainer is working on this; see fedora-devel-list archives for discussion.
David
[1] : http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01374.html
David Zeuthen wrote:
It's a popular misconception that boot time can be "boosted" by just replacing SysVinit with something else.
I recently tried both InitNG and Upstart and my impression was that both are very benefical.
By using dynamic dependencies and an event driven design, you avoid running most init scripts altogether. For istance, "bluetooth" is useless on systems without a blootooth dongle... and it should be launched by hotplug anyway. It can also makes some scripts simpler/shorter.
Upstart makes Ubuntu very fast to boot. I did no measurements, but it's clearly much faster than plain Debian and Fedora to bring up a similar environment.
InitNG is also interesting, probably even faster than Upstart, but more radical and a bit of a kludge in my humbling opinion. They replace those long shell scripts with an ad-hoc language to run daemons and simple commands. For complex stuff it may need a snippet of shell code, but it usually doesn't.
Also, MacOSX boot feels much faster since they switched from init to launchd. I don't think it has been ported to Linux, but it's just to show that it has real benefits.
I also liked the gdm early-login thing from FC5, but for some reason it has been abandoned.
The biggest bang for the buck actually comes from fixing readahead so it reads all the files it needs, without making the disk seek;
The wrong thing about readahead is that it's even less dynamic than sysvinit. On a system I use KDE by default, but readahead keeps wasting time preloading all the Gnome libraries.
I remember reading somewhere that MacOSX collects statistics during boot and creates some kind of boot cache. IIRC, Windows XP did something "smart" too.
Also, the old sequential init scripts even with readahead will waste lots of disk bandwidth while waiting for dhcp or video mode probing.
On Mon, 2007-04-02 at 22:27 +0200, Bernardo Innocenti wrote:
By using dynamic dependencies and an event driven design, you avoid running most init scripts altogether.
I'm just saying that don't expect that switching to Upstart will magically cut 10-15 seconds of your boot time. And, hey, it's not that I disagree that SysVinit sucks in various ways; I personally think Upstart is promising because it allows parallel execution plus it will make it possible to avoid launching a gazillon copies of /bin/sh by have a rule driven design. That alone is reason enough to switch I think.
For istance, "bluetooth" is useless on systems without a blootooth dongle... and it should be launched by hotplug anyway. It can also makes some scripts simpler/shorter.
There is no /etc/hotplug[.d] anymore, you probably mean udev. For the record I'm working with the Bluez people on launching bluez from hald for this and other reasons (Bluez will provide services as a HAL addon); won't make Fedora 7 though.
David
David Zeuthen david@fubar.dk writes:
On Mon, 2007-04-02 at 22:27 +0200, Bernardo Innocenti wrote:
By using dynamic dependencies and an event driven design, you avoid running most init scripts altogether.
I'm just saying that don't expect that switching to Upstart will magically cut 10-15 seconds of your boot time.
I'm glad I'm not the only one who thought that sounded like voodoo economics.
I think our problems are much more localized than that. In my personal environment, the single biggest boot-time problem is that netatalk takes friggin forever (~ 1 min) to sync with an existing Appletalk seed router. But I don't reboot my Fedora machines often enough to make it worth my time to track it down ...
regards, tom lane
On 4/3/07, Tom Lane tgl@redhat.com wrote:
David Zeuthen david@fubar.dk writes:
On Mon, 2007-04-02 at 22:27 +0200, Bernardo Innocenti wrote:
By using dynamic dependencies and an event driven design, you avoid running most init scripts altogether.
I'm just saying that don't expect that switching to Upstart will magically cut 10-15 seconds of your boot time.
I'm glad I'm not the only one who thought that sounded like voodoo economics.
I think our problems are much more localized than that. In my personal environment, the single biggest boot-time problem is that netatalk takes friggin forever (~ 1 min) to sync with an existing Appletalk seed router. But I don't reboot my Fedora machines often enough to make it worth my time to track it down ...
regards, tom lane
Maybe the current system should at least be modded to give logged, time information. So sysadmins can make more educated decisions.
On Tuesday, April 03, 2007 2:50 am Tom Lane wrote:
I think our problems are much more localized than that. In my personal environment, the single biggest boot-time problem is that netatalk takes friggin forever (~ 1 min) to sync with an existing Appletalk seed router. But I don't reboot my Fedora machines often enough to make it worth my time to track it down ...
Oh, God, THAT one...
Throws me back to my days on Debian, when I was pissed at every startup because of how insanely long netatalk took to initialize...
I think it's just part of the daemon.
Le Mar 3 avril 2007 08:50, Tom Lane a écrit :
David Zeuthen david@fubar.dk writes:
On Mon, 2007-04-02 at 22:27 +0200, Bernardo Innocenti wrote:
By using dynamic dependencies and an event driven design, you avoid running most init scripts altogether.
I'm just saying that don't expect that switching to Upstart will magically cut 10-15 seconds of your boot time.
I'm glad I'm not the only one who thought that sounded like voodoo economics.
Sure. But going event-driven and launching only what's needed when it's needed is going to win us more
i wasn`t expecting so much reactions on this topic.. the more the better though.
but i think that the boot time can be brought down alot just be providing some more options for the boot progress.. for example.. let the users choose which kernel modules should load.. things like that could make a change
2007/4/3, Nicolas Mailhot nicolas.mailhot@laposte.net:
Le Mar 3 avril 2007 08:50, Tom Lane a écrit :
David Zeuthen david@fubar.dk writes:
On Mon, 2007-04-02 at 22:27 +0200, Bernardo Innocenti wrote:
By using dynamic dependencies and an event driven design, you avoid running most init scripts altogether.
I'm just saying that don't expect that switching to Upstart will magically cut 10-15 seconds of your boot time.
I'm glad I'm not the only one who thought that sounded like voodoo economics.
Sure. But going event-driven and launching only what's needed when it's needed is going to win us more
-- Nicolas Mailhot
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mark wrote:
i wasn`t expecting so much reactions on this topic.. the more the better though.
but i think that the boot time can be brought down alot just be providing some more options for the boot progress.. for example.. let the users choose which kernel modules should load.. things like that could make a change
this does not make any sense... the kernel / udev should only load needed modules everything else is a bug
2007/4/3, dragoran drago01@gmail.com:
Mark wrote:
i wasn`t expecting so much reactions on this topic.. the more the better though.
but i think that the boot time can be brought down alot just be providing some more options for the boot progress.. for example.. let the users choose which kernel modules should load.. things like that could make a change
this does not make any sense... the kernel / udev should only load needed modules everything else is a bug
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
actually i am using und helping with development of initng since around a year now on my boxes and it wfm. i boot graphically into gdm in about 15 seconds with some basics and NetworkManager started.
initng currently has some dependency driven system. that means also that dependecys of services are started automatically once the system is up. services are parallel executed upon startup.
initng will also get an event plugin for event functionality and also has a nice modular design.
with the next release iteration there will also be a new init script system using posix compliant init scripts.
yet i only saw upstart running in compat mode and upstart in compat mode has exactly 0 benefits towards systemV because it still uses the systemV init scripts without parallel execution plus it adds yet another useless sleeping process in that state.
launchd doesent build on linux for me yet. if anyone has patches it would be great if he could make em public.
regards, Rudolf Kastl
Rudolf Kastl wrote:
actually i am using und helping with development of initng since around a year now on my boxes and it wfm. i boot graphically into gdm in about 15 seconds with some basics and NetworkManager started.
My experience was similar: initng brings up the system so quickly that I can't even *see* what's going on before X replaces the console.
initng will also get an event plugin for event functionality and also has a nice modular design.
This is IMHO a "must have" for next generation's Linux init system. It's not worth breaking a mature critical system such as SysVInit just to save a few seconds of boot time.
with the next release iteration there will also be a new init script system using posix compliant init scripts.
This is also important in my opinion: those .i files with their custom syntax are the reason why I said initg looked a bit kludgy in my original posting.
yet i only saw upstart running in compat mode and upstart in compat mode has exactly 0 benefits towards systemV because it still uses the systemV init scripts without parallel execution plus it adds yet another useless sleeping process in that state.
What do you mean by compatibility mode? I've only seen Upstart in Ubuntu Feisty. Booting was so fast that I assumed it was parallel already.
The nice thing about Upstart is that it looks and feels familiar to anybody who's used to sysvinit. Except that /etc/inittab is gone, but nobody will ever miss it ;-)
launchd doesent build on linux for me yet. if anyone has patches it would be great if he could make em public.
Maybe the APL could be a problem for such a core component.
The design of launchd also appears less orthogonal to me than the alternatives, altough I understand that crond and inetd should somehow coordinate with the init system to get a number of corner cases right.
Also, a radical approach such as launchd is less likely to become mature enough to replace sysvinit in the short term. You'd need massive coordination between hundereds of package maintainers.
And by the way: the init system is not something I'd like to see forked in every Linux distro. Ubuntu adopted Upstart early and Debian will most probably follow soon or later.
LSB had just finished standardizing the init scripts and now we're going to break things again. Users *are* going to complain. Analysts *are* going to say Linux is fragmented. Microsoft *is* going to publish studies saying that Linux has higher TCO because of multiple init systems ;-)
So maybe it would be wise if the remaining mainstream distros, including Fedora and SuSE, followed their lead quietly instead of starting a pointless init war.
This doesn't mean there should be a single codebase. Multiple systems could compete as long as they are 100% (or maybe just 99%) compatible config files and user interface.
On Wed, Apr 04, 2007 at 05:37:10PM +0200, Bernardo Innocenti wrote:
LSB had just finished standardizing the init scripts and now we're going to break things again. Users *are* going to complain. Analysts *are* going to say Linux is fragmented. Microsoft *is* going to publish studies saying that Linux has higher TCO because of multiple init systems ;-)
This doesn't mean there should be a single codebase. Multiple systems could compete as long as they are 100% (or maybe just 99%) compatible config files and user interface.
All the init systems should be parallel installable, so the choice is only for the default init system.
-- Pat
On 4/4/07, Patrice Dumas pertusus@free.fr wrote:
On Wed, Apr 04, 2007 at 05:37:10PM +0200, Bernardo Innocenti wrote:
LSB had just finished standardizing the init scripts and now we're going to break things again. Users *are* going to complain. Analysts *are* going to say Linux is fragmented. Microsoft *is* going to publish studies saying that Linux has higher TCO because of multiple init systems ;-)
This doesn't mean there should be a single codebase. Multiple systems could compete as long as they are 100% (or maybe just 99%) compatible config files and user interface.
All the init systems should be parallel installable, so the choice is only for the default init system.
if we go this route system-config-services should support multiple backends....
--
Pat
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dragoran dragoran wrote:
All the init systems should be parallel installable, so the choice is only for the default init system.
if we go this route system-config-services should support multiple backends....
...and many packages should contain multiple init scripts for those systems that dropped sysvinit compatibility (like initng).
On Thu, Apr 05, 2007 at 12:18:01PM +0200, Bernardo Innocenti wrote:
dragoran dragoran wrote:
All the init systems should be parallel installable, so the choice is only for the default init system.
if we go this route system-config-services should support multiple backends....
...and many packages should contain multiple init scripts for those systems that dropped sysvinit compatibility (like initng).
Sure, if there is somebody wanting to go that route, let's not stop them.
-- Pat
2007/4/5, Patrice Dumas pertusus@free.fr:
On Thu, Apr 05, 2007 at 12:18:01PM +0200, Bernardo Innocenti wrote:
dragoran dragoran wrote:
All the init systems should be parallel installable, so the choice is only for the default init system.
if we go this route system-config-services should support multiple backends....
...and many packages should contain multiple init scripts for those systems that dropped sysvinit compatibility (like initng).
Sure, if there is somebody wanting to go that route, let's not stop them.
actually i disagree.
as far as the current state goes its alot easier and more maintainable if the scripts are in a central package.
if you disagree not a problem. but id really expect then that you are going into the projects and fixing up the scripts individually then.
Generally i also think that we should have choice. Friendly competition among systems is a healthy thing. Think if you have multible systems with different scripts its unlikely upstream is going to maintain all of them. Especially considering you want clean and tidy scripts...
regards, Rudolf Kastl
p.s. its always easy to say something has to happen if you are not planning on doing it.
-- Pat
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, Apr 06, 2007 at 10:48:38AM +0200, Rudolf Kastl wrote:
as far as the current state goes its alot easier and more maintainable if the scripts are in a central package.
if you disagree not a problem. but id really expect then that you are going into the projects and fixing up the scripts individually then.
I am just saying that if somebody wants to do this we should not prevent it. I am not saying I'll do it. If new init systems are not accepted nobody will ever do the scripts, and so they will never be able to prove that they are better or not. If they are accepted it isn't sure that somebody would do the scripts, but it becomes possible.
p.s. its always easy to say something has to happen if you are not planning on doing it.
I am not saying that it is going to happen, I am saying that we shouldn't prevent it to happen.
-- Pat
2007/4/4, Patrice Dumas pertusus@free.fr:
On Wed, Apr 04, 2007 at 05:37:10PM +0200, Bernardo Innocenti wrote:
LSB had just finished standardizing the init scripts and now we're going to break things again. Users *are* going to complain. Analysts *are* going to say Linux is fragmented. Microsoft *is* going to publish studies saying that Linux has higher TCO because of multiple init systems ;-)
This doesn't mean there should be a single codebase. Multiple systems could compete as long as they are 100% (or maybe just 99%) compatible config files and user interface.
All the init systems should be parallel installable, so the choice is only for the default init system.
If I understand you right, you want Fedora to support all (or many) of the available init systems. I think this is a very bad idea. Creating a distribution is not about just shipping as many applications as possible, but to make some qualified choices so that the end user does not have to worry about every detail. After all, Fedora is not Gentoo. This only adds additional work on developers and packagers that could much rather have been spent on more useful things.
Dnia 05-04-2007, Cz o godzinie 12:33 +0200, Trond Danielsen napisał(a):
If I understand you right, you want Fedora to support all (or many) of the available init systems. I think this is a very bad idea. Creating a distribution is not about just shipping as many applications as possible, but to make some qualified choices so that the end user does not have to worry about every detail. After all, Fedora is not Gentoo. This only adds additional work on developers and packagers that could much rather have been spent on more useful things.
Save backward compatibility and provide parallel start/stop provides Solaris SMF .. so IMO best will be port this software to Linux.
kloczek
On Thu, Apr 05, 2007 at 12:33:23PM +0200, Trond Danielsen wrote:
If I understand you right, you want Fedora to support all (or many) of the available init systems. I think this is a very bad idea. Creating a distribution is not about just shipping as many applications as possible, but to make some qualified choices so that the end user does not have to worry about every detail. After all, Fedora is not Gentoo. This only adds additional work on developers and packagers that could much rather have been spent on more useful things.
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies. The default init system should be privileged, but all should be present, such that power users are able to test and use them. The directions that developers and packagers want to follow, how they spend their time is their business. If there are enough people interested in new init systems, lets have them. As a project we have to watch out the packaging quality, the integration in the distro and have good defaults. Our mandate should not to be in the way of initiatives.
-- Pat
On Thursday 05 April 2007 07:38:26 Patrice Dumas wrote:
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies. The default init system should be privileged, but all should be present, such that power users are able to test and use them. The directions that developers and packagers want to follow, how they spend their time is their business. If there are enough people interested in new init systems, lets have them. As a project we have to watch out the packaging quality, the integration in the distro and have good defaults. Our mandate should not to be in the way of initiatives.
At the same time, I don't want to stamp the Fedora name on something that has 6 half working init system choices, but none that work fully. It's the same reason we don't ship 6 different kernel compiles (other than xen or no xen, smp or no smp, these are because one won't work across all hardware sets/systems). Certain things in the distro have to be rock solid, the init system is one of those.
Now, I'm all for seeing development happen and initiatives. You can create a secondary repo around trying out a new init system. I just don't want to see them clutter up the main repos that every user gets access to.
On Thu, Apr 05, 2007 at 10:57:43AM -0400, Jesse Keating wrote:
At the same time, I don't want to stamp the Fedora name on something that has 6 half working init system choices, but none that work fully. It's the same
That's not what I am saying here. I am personnally rather retrograde and like to keep old stuff that work. I am all for a rock solid, well tested init system used as a default.
Now, I'm all for seeing development happen and initiatives. You can create a secondary repo around trying out a new init system. I just don't want to see them clutter up the main repos that every user gets access to.
That, however seems very wrong to me and, in my opinion, very different from the spirit of former fedora extras. Having exotic, in development, niche software in fedora is very important to foster rapid development and innovation. The developpers should be cautious as to avoid letting softwares that are too broken pass from the devel repo to the release, but I think that we shouldn't fear from shipping broken software if there is an interest among users, they are not the defaults, and they are represented as being in development.
An example along those lines is gnash, which is horribly broken still worth shipping in fedora.
-- Pat
On Thursday 05 April 2007 11:05:37 Patrice Dumas wrote:
That, however seems very wrong to me and, in my opinion, very different from the spirit of former fedora extras. Having exotic, in development, niche software in fedora is very important to foster rapid development and innovation. The developpers should be cautious as to avoid letting softwares that are too broken pass from the devel repo to the release, but I think that we shouldn't fear from shipping broken software if there is an interest among users, they are not the defaults, and they are represented as being in development.
This is fine, however what is in development automatically becomes the release. Perhaps we need better infrastructure around "skipping" packages for the release, but that is also bad form for those that are testing rawhide to see what will be in the release.
On Thu, Apr 05, 2007 at 11:19:53AM -0400, Jesse Keating wrote:
On Thursday 05 April 2007 11:05:37 Patrice Dumas wrote:
That, however seems very wrong to me and, in my opinion, very different from the spirit of former fedora extras. Having exotic, in development, niche software in fedora is very important to foster rapid development and innovation. The developpers should be cautious as to avoid letting softwares that are too broken pass from the devel repo to the release, but I think that we shouldn't fear from shipping broken software if there is an interest among users, they are not the defaults, and they are represented as being in development.
This is fine, however what is in development automatically becomes the release. Perhaps we need better infrastructure around "skipping" packages for the release, but that is also bad form for those that are testing rawhide to see what will be in the release.
It is already possible, and I already did this for ivman as I thought that te config system of ivman wasn't ready. I don't remember the details but it was along editing a wiki page (and of course, hidden behind somebody took action).
-- Pat
On Thursday 05 April 2007 11:45:08 Patrice Dumas wrote:
It is already possible, and I already did this for ivman as I thought that te config system of ivman wasn't ready. I don't remember the details but it was along editing a wiki page (and of course, hidden behind somebody took action).
If it was done, it was done completely by hand, which doesn't scale.
On Thu, Apr 05, 2007 at 11:51:50AM -0400, Jesse Keating wrote:
On Thursday 05 April 2007 11:45:08 Patrice Dumas wrote:
It is already possible, and I already did this for ivman as I thought that te config system of ivman wasn't ready. I don't remember the details but it was along editing a wiki page (and of course, hidden behind somebody took action).
If it was done, it was done completely by hand, which doesn't scale.
I don't mind if it is done by hand (maybe you do, since you actually do the work). Maybe we need some infrastructure then, even more importantly for EPEL, were skipping the release should be even more relevant (as it has been already discussed and I guess this is somewhere on the wiki).
-- Pat
Patrice Dumas schrieb:
[...] Maybe we need some infrastructure then, even more importantly for EPEL, were skipping the release should be even more relevant (as it has been already discussed and I guess this is somewhere on the wiki).
Not sure on this. EPEL has no own devel branch. So when we get closer to RHEL6 we could simply branch all EL-5 packages that are still active in Fedora (e.g. have no dead.packges file) and ask all the owners of new packages to ask manually for a EL-6 branch. Sounds like a easy solution for the problem and makes sure all packages in EPEL6 have a owner.
For stuff in the epel-testing repo it might be as easy to request a delete a package shortly before the testing stuff becomes stable with the next quarterly update. That's a bit manual work, but it hopefully should not happen that often.
CU thl
On Thu, Apr 05, 2007 at 06:03:28PM +0200, Thorsten Leemhuis wrote:
For stuff in the epel-testing repo it might be as easy to request a delete a package shortly before the testing stuff becomes stable with the next quarterly update. That's a bit manual work, but it hopefully should not happen that often.
That's what I was referring to.
-- Pat
On Thu, 2007-04-05 at 10:57 -0400, Jesse Keating wrote:
On Thursday 05 April 2007 07:38:26 Patrice Dumas wrote:
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies. The default init system should be privileged, but all should be present, such that power users are able to test and use them. The directions that developers and packagers want to follow, how they spend their time is their business. If there are enough people interested in new init systems, lets have them. As a project we have to watch out the packaging quality, the integration in the distro and have good defaults. Our mandate should not to be in the way of initiatives.
At the same time, I don't want to stamp the Fedora name on something that has 6 half working init system choices, but none that work fully. It's the same reason we don't ship 6 different kernel compiles (other than xen or no xen, smp or no smp, these are because one won't work across all hardware sets/systems). Certain things in the distro have to be rock solid, the init system is one of those.
Now, I'm all for seeing development happen and initiatives. You can create a secondary repo around trying out a new init system. I just don't want to see them clutter up the main repos that every user gets access to.
Are we going to unmerge Extras and Core for F8? ;-)
More seriously, I agree with Patrice that Fedora has a mandate to ship new and in-development things for users to try if they don't conflict with core components. Since init systems can be parallel installed, I think that they belong in the Fedora repository.
One thing that Patrice isn't stressing, however, is that using a different initsystem usually requires writing new initscripts. So we need to have some policy about initscripts in Fedora. Something like:
""" Packages that are to be started at system startup must provide an initscript for the default Fedora init system. Here are <link>details on writing an initscript</link> for SysVinit, our current default. In addition, other packagers may be interested in providing initscripts for alternate init systems. When this happens, the package should install the alternate init script [Guidance on how]. """
This is not a complete policy. How is a very big question. Subpackage? The same package that provides SysVinit? Who has responsibility for submitting the alternate init scripts to upstream? Should there be a SIG that helps add support for different init systems?
-Toshio
2007/4/5, Patrice Dumas pertusus@free.fr:
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies.
Free software is indeed about choices, but creating a distribution is also about making choices. If the distribution does not make them, but leave them to the user, then a distribution is nothing more than collection of packages bundled together.
The default init system should be privileged, but all should be present, such that power users are able to test and use them. The directions that developers and packagers want to follow, how they spend their time is their business. If there are enough people interested in new init systems, lets have them. As a project we have to watch out the packaging quality, the integration in the distro and have good defaults. Our mandate should not to be in the way of initiatives.
Power users are indeed welcome to test new things. That does not mean that everything has to be in the main repositories and thereby risking breaking things for many users.
I remember asking many years on #fedora why some cheezy window manager that I wanted to try wasn't available in Fedora. My question was exactly the same as yours: "Isn't free software about choices?". The answer I got was the same as the one I've given here. This lead me into a dark journey through many distributions, looking for the answer. But eventually I grew up, and wanted a distribution that made some sane decisions for me, and not forcing me to deal with every little detail of the system.
On Thu, Apr 05, 2007 at 05:30:05PM +0200, Trond Danielsen wrote:
2007/4/5, Patrice Dumas pertusus@free.fr:
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies.
Free software is indeed about choices, but creating a distribution is also about making choices. If the distribution does not make them, but leave them to the user, then a distribution is nothing more than collection of packages bundled together.
I also disagree. There is something between 'a collection of packages bundled together' and a distribution where all the choices are made for the user. To take the example of Fedora it is more than a collection of packages, but not because of the choice of packages bundled, but because
* there are some packaging standards * there are some defaults * the packages are integrated into the distribution
It was explicit in fedora extras that the only reason not to accept a package was a license issue, or a conflict with core. I hope that it hasn't changed.
Power users are indeed welcome to test new things. That does not mean that everything has to be in the main repositories and thereby risking breaking things for many users.
Breaking what? Theya re parallel installable and not installed.
I remember asking many years on #fedora why some cheezy window manager that I wanted to try wasn't available in Fedora. My question was exactly the same as yours: "Isn't free software about choices?". The answer I got was the same as the one I've given here. This lead me into a dark journey through many distributions, looking for the answer. But eventually I grew up, and wanted a distribution that made some sane decisions for me, and not forcing me to deal with every little detail of the system.
Maybe you are not using the right distribution then. Thanks to fedora extras, there are now plenty window managers, including fluxbox, wmx, blackbox, fvwm, icewm, mwm, twm, pekwm, windowMaker and many others. The only one I know about that I know isn't in fedora is rox.
I reviewed some of these (including icewm, fvwm and pekwm) and I always made sure that they were rightly integrated in fedora, by having the freedesktop menuu, an entry in /usr/share/xsessions/, using xdg-open to open files, htmlview instead of a random browser. That, is our packager work, not removing user choice.
-- Pat
2007/4/5, Patrice Dumas pertusus@free.fr:
On Thu, Apr 05, 2007 at 05:30:05PM +0200, Trond Danielsen wrote:
2007/4/5, Patrice Dumas pertusus@free.fr:
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies.
Free software is indeed about choices, but creating a distribution is also about making choices. If the distribution does not make them, but leave them to the user, then a distribution is nothing more than collection of packages bundled together.
I also disagree. There is something between 'a collection of packages bundled together' and a distribution where all the choices are made for the user. To take the example of Fedora it is more than a collection of packages, but not because of the choice of packages bundled, but because
- there are some packaging standards
- there are some defaults
- the packages are integrated into the distribution
It was explicit in fedora extras that the only reason not to accept a package was a license issue, or a conflict with core. I hope that it hasn't changed.
Power users are indeed welcome to test new things. That does not mean that everything has to be in the main repositories and thereby risking breaking things for many users.
Breaking what? Theya re parallel installable and not installed.
I remember asking many years on #fedora why some cheezy window manager that I wanted to try wasn't available in Fedora. My question was exactly the same as yours: "Isn't free software about choices?". The answer I got was the same as the one I've given here. This lead me into a dark journey through many distributions, looking for the answer. But eventually I grew up, and wanted a distribution that made some sane decisions for me, and not forcing me to deal with every little detail of the system.
Maybe you are not using the right distribution then. Thanks to fedora extras, there are now plenty window managers, including fluxbox, wmx, blackbox, fvwm, icewm, mwm, twm, pekwm, windowMaker and many others. The only one I know about that I know isn't in fedora is rox.
I reviewed some of these (including icewm, fvwm and pekwm) and I always made sure that they were rightly integrated in fedora, by having the freedesktop menuu, an entry in /usr/share/xsessions/, using xdg-open to open files, htmlview instead of a random browser. That, is our packager work, not removing user choice.
Ok, maybe it was a bad example. My point is that there is a distinction between low level stuff such as kernels, init system and other basic software, and applications such as wm's and mua's. There is not problem to provide two or more different email clients, as there affect each other very little. But something like the init system would have an impact on all packages that depend on it. That is why I think it is a bad thing to try to put everything into the repositories.
On Thu, Apr 05, 2007 at 06:21:14PM +0200, Trond Danielsen wrote:
Ok, maybe it was a bad example. My point is that there is a distinction between low level stuff such as kernels, init system and other basic software, and applications such as wm's and mua's. There is not problem to provide two or more different email clients, as there affect each other very little. But something like the init system would have an impact on all packages that depend on it. That is
Indeed, it is more risky, but once more it is the user responsibility to install and activate those init systems. I really can't see why a different init system than the default shouldn't be shipped. Now an init system may not be of enough quality to enter in fedora, but if it is not the case I really can't see the issue.
To come back at the example of gnash, at some point (because of some X bug) gnash crashed X almost systematically. Was it a reason not to provide it? We chosed to provide it in devel, add wordings of caution and cautiously add it to the releases when the nasty bug was solved. I can't see why other init systems shouldn't be treated like that.
Also this conversation is somehow pointless, because new init systems can already enter fedora (there is already initng) and there is nothing in the guidelines preventing that, so...
-- Pat
2007/4/5, Patrice Dumas pertusus@free.fr:
On Thu, Apr 05, 2007 at 05:30:05PM +0200, Trond Danielsen wrote:
2007/4/5, Patrice Dumas pertusus@free.fr:
I think this is a very wrong direction for fedora. Free software is about choice. And also being able to test innovative technologies.
Free software is indeed about choices, but creating a distribution is also about making choices. If the distribution does not make them, but leave them to the user, then a distribution is nothing more than collection of packages bundled together.
I also disagree. There is something between 'a collection of packages bundled together' and a distribution where all the choices are made for the user. To take the example of Fedora it is more than a collection of packages, but not because of the choice of packages bundled, but because
- there are some packaging standards
- there are some defaults
- the packages are integrated into the distribution
It was explicit in fedora extras that the only reason not to accept a package was a license issue, or a conflict with core. I hope that it hasn't changed.
Power users are indeed welcome to test new things. That does not mean that everything has to be in the main repositories and thereby risking breaking things for many users.
Breaking what? Theya re parallel installable and not installed.
I remember asking many years on #fedora why some cheezy window manager that I wanted to try wasn't available in Fedora. My question was exactly the same as yours: "Isn't free software about choices?". The answer I got was the same as the one I've given here. This lead me into a dark journey through many distributions, looking for the answer. But eventually I grew up, and wanted a distribution that made some sane decisions for me, and not forcing me to deal with every little detail of the system.
Maybe you are not using the right distribution then. Thanks to fedora extras, there are now plenty window managers, including fluxbox, wmx, blackbox, fvwm, icewm, mwm, twm, pekwm, windowMaker and many others. The only one I know about that I know isn't in fedora is rox.
I reviewed some of these (including icewm, fvwm and pekwm) and I always made sure that they were rightly integrated in fedora, by having the freedesktop menuu, an entry in /usr/share/xsessions/, using xdg-open to open files, htmlview instead of a random browser. That, is our packager work, not removing user choice.
there are around 20 wms i know offhand that arent in the distribution yet.
-- Pat
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, Apr 06, 2007 at 10:50:42AM +0200, Rudolf Kastl wrote:
there are around 20 wms i know offhand that arent in the distribution yet.
Ok, I am not a wm specialist, I am just saying that actually there is a large choice of wm thanks to fedora extras, and our job is to integrate them, not to reject because it is harder to maintain many wm and confusing for the users.
-- Pat
Patrice Dumas wrote:
On Fri, Apr 06, 2007 at 10:50:42AM +0200, Rudolf Kastl wrote:
there are around 20 wms i know offhand that arent in the distribution yet.
Ok, I am not a wm specialist, I am just saying that actually there is a large choice of wm thanks to fedora extras, and our job is to integrate them, not to reject because it is harder to maintain many wm and confusing for the users.
A window manager is very different from a init script system. We don't currently allow individual maintainers to put different kernels into Fedora repository. A init system is very similar.
For a alternatively init system to properly work with the system requires all packages that provide init scripts to also provide a different one for each different init system that we have in the repository unless they have a SysV init compatibility mode.
This is quite a large amount of integration work required which packagers not be interested in. Some sort of experimental version is ok for testers in the development branch but this wouldnt scale much for the "stable" branches that we have to maintain.
Do you see that as a problem? If so what is the solution that you are suggesting?
Rahul
Le Ven 6 avril 2007 11:35, Rahul Sundaram a écrit :
For a alternatively init system to properly work with the system requires all packages that provide init scripts to also provide a different one for each different init system that we have in the repository unless they have a SysV init compatibility mode.
multi-init would work if the init "script" syntax was purely declarative. This is the problem already discussed in "make init scripts %config" thread
Since SysV is badly designed, multi-init can only work if all the new projects agree on a common non implementation-adherent declarative syntax for services. And if Fedora dumps SysV
On Fri, Apr 06, 2007 at 03:05:21PM +0530, Rahul Sundaram wrote:
A window manager is very different from a init script system. We don't currently allow individual maintainers to put different kernels into Fedora repository. A init system is very similar.
I think that, if there existed kernels different from the linux kernel but providing the same interface, we should allow them. But I don't think it exists. It is the same for the libc and I am a big proponent of having alternative libc, and even use them when there is a gain. To me there is no fundamental difference between the fedora components, as long as they share the same interfaces and use the same norms, otherwise said are integrated. (wm use X, and freedesktop, libcs implement the same API, and so on and so forth).
Once more I am all for retrograde defaults, but also to let power users be able to test and use innovative stuff. Normal users won't install anything not in the default set.
For a alternatively init system to properly work with the system requires all packages that provide init scripts to also provide a different one for each different init system that we have in the repository unless they have a SysV init compatibility mode.
This is quite a large amount of integration work required which packagers not be interested in. Some sort of experimental version is ok
You cannot say that for packagers. Packagers may be interested in that work. If we forbid new init systems we prevent interested people to do the job.
for testers in the development branch but this wouldnt scale much for the "stable" branches that we have to maintain.
Why? If people are interested, they will make it scale. We have to accept new stuff, otherwise it won't get off. For example, for init systems, if we say 'this system is too new, it needs new init files/scripts' it will never get in because packagers and upstreams potentially interested will say 'this system is not packaged it is a waste of time to get interested in it'.
Do you see that as a problem? If so what is the solution that you are suggesting?
Let the new init systems packagers decide (as a community) when they can put new init systems in stable release, just like for normal components. If contributors cannot be trusted, things are wrong anyway.
-- Pat
Patrice Dumas wrote:
You cannot say that for packagers. Packagers may be interested in that work. If we forbid new init systems we prevent interested people to do the job.
Are you suggesting that all packagers would be interested in providing alternative versions of the required init scripts for all different init scripts systems?
Why? If people are interested, they will make it scale.
The problem happens when people are not interested. We would end up having init script systems which don't work properly because the packages dont provide init scripts except for the default init script system. When end users find more such packages in the repository (which do not know is experimental), the level of trust on the quality of the repository goes down. More choices without proper integration and testing is bad.
The question here is: What do you propose to guarantee better integration for all the different init scripts?
The critical difference between a package like the window manager and alternative init systems is that with window managers integration is centralized and can be done via proper generation of menus within the package itself.
With init systems, thousands of packages have to provide alternative versions of all their init scripts.
We have to
accept new stuff, otherwise it won't get off. For example, for init systems, if we say 'this system is too new, it needs new init files/scripts' it will never get in because packagers and upstreams potentially interested will say 'this system is not packaged it is a waste of time to get interested in it'.
If the goal here is just to experiment and ultimately find the "optimal" init system (within the constraints that nothing is optimal for everyone), the solution there is provide the alternative init system only for the development branch which helps packagers integrate with it and testers test it and provide feedback while not disrupting the end users and then only provide a single init system for the stable branches.
Let the new init systems packagers decide (as a community) when they can put new init systems in stable release, just like for normal components. If contributors cannot be trusted, things are wrong anyway.
Trust is not a black and white thing. Neither it is always a question of trust. If we can trust everyone we don't require ACL's in any packages. We have several cross checks in place, processes and guidelines precisely because we *cannot* trust all contributors all the time. As we scale to more contributors expect such processes to *increase*.
Rahul
On Fri, Apr 06, 2007 at 07:10:09PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
You cannot say that for packagers. Packagers may be interested in that work. If we forbid new init systems we prevent interested people to do the job.
Are you suggesting that all packagers would be interested in providing alternative versions of the required init scripts for all different init scripts systems?
Not all, but those that appear to be popular. But without competition you cannot know which one is the most popular.
Why? If people are interested, they will make it scale.
The problem happens when people are not interested. We would end up having init script systems which don't work properly because the packages dont provide init scripts except for the default init script system. When end users find more such packages in the repository (which do not know is experimental), the level of trust on the quality of the repository goes down. More choices without proper integration and testing is bad.
I may be wrong, but I don't think that any user will chose another init system than the default init system unknowingly. Maybe we could require for alternate packages that the user edits a file by hand and in this file there should be something like # beware, this is not the default init system.
But I don't think the users have expectations about non-default init systems. If they have wrong expectations, don't do proper investigation before changing such an important piece of fedora from the default, change defaults without being knowledgable enough, I don't think these are users we should care that much about. In any case they will certainly be free riders, if not worse.
The question here is: What do you propose to guarantee better integration for all the different init scripts?
The critical difference between a package like the window manager and alternative init systems is that with window managers integration is centralized and can be done via proper generation of menus within the package itself.
We could have guidelines explaining that the only required system is the default init. Then we could also provide explanation on how to integrate each of the init system shipped. It could even be a requirement for the inclusion in fedora that the maintainer adds a guideline on te wiki with hints on integration.
With init systems, thousands of packages have to provide alternative versions of all their init scripts.
I trust in the free software community to provide them for a new init system if the new init sysem is better or just different, and there is no entry barrier, like an init system not being packaged in big distros.
We have to
accept new stuff, otherwise it won't get off. For example, for init systems, if we say 'this system is too new, it needs new init files/scripts' it will never get in because packagers and upstreams potentially interested will say 'this system is not packaged it is a waste of time to get interested in it'.
If the goal here is just to experiment and ultimately find the "optimal" init system (within the constraints that nothing is optimal for everyone), the solution there is provide the alternative init system only for the development branch which helps packagers integrate with it and testers test it and provide feedback while not disrupting the end users and then only provide a single init system for the stable branches.
Having them in the development branch would be a must in my opinion. And for stable branch stable enough and widely enough covered init systems should be accepted. Maybe this could be a guideline.
Trust is not a black and white thing. Neither it is always a question of trust. If we can trust everyone we don't require ACL's in any packages. We have several cross checks in place, processes and guidelines precisely because we *cannot* trust all contributors all the time. As we scale to more contributors expect such processes to *increase*.
Ok, we could have guidelines, like what I suggest above, but just saying we use only one init system is wrong.
-- Pat
Patrice Dumas wrote:
I may be wrong, but I don't think that any user will chose another init system than the default init system unknowingly.
The problem is not that the user would unknowingly install a different init system (They could install any packages without understanding it but that is not a init system specific issue so we needn't discuss that in this thread).
The problem is that users wouldn't know that the init system they are installing wont work with several packages because these don't provide the init scripts that work with the alternative init system they just installed. If basic integration was not done, the alternative init system would result in non-functional packages, crashes or worse non booting systems.
But I don't think the users have expectations about non-default init systems.
Why not? If I was a end user I would definitely expect any package in Fedora to work with the rest of the packages in the repository properly. I would expect the project to put in the necessary checks to ensure that I get functional software.
If they have wrong expectations, don't do proper investigation
before changing such an important piece of fedora from the default, change defaults without being knowledgable enough, I don't think these are users we should care that much about. In any case they will certainly be free riders, if not worse.
You are expecting end users to investigate all the potential issues before they install a package. I think that's unreasonable. Maybe expecting software to just work is idealistic but how is it ever free riding?
Ok, we could have guidelines, like what I suggest above, but just saying we use only one init system is wrong.
I didn't suggest that. Propose the guidelines first and get them approved in place before getting alternative init systems into stable branches. This has potential for a lot of mess otherwise. If it's just for devel branch that's fine.
Rahul
On Fri, Apr 06, 2007 at 08:02:51PM +0530, Rahul Sundaram wrote:
The problem is that users wouldn't know that the init system they are installing wont work with several packages because these don't provide the init scripts that work with the alternative init system they just installed. If basic integration was not done, the alternative init system would result in non-functional packages, crashes or worse non booting systems.
In my opinion, a user who installs an alternate init system should know about it and understand what happens if it doesn't work. Of course the init system should basically work, otherwise it shouldn't be in the stable branch but I don't think that we should wait for all packages to be covered by the init system before letting it go in the stable branch.
Why not? If I was a end user I would definitely expect any package in Fedora to work with the rest of the packages in the repository properly. I would expect the project to put in the necessary checks to ensure that I get functional software.
Some packages need some work before they work, daemons need to be configured in general. In my opinion it is similar for a new init system. It should work for most of the packages, but for packages less used the user may have to do the init configuration himself.
You are expecting end users to investigate all the potential issues before they install a package. I think that's unreasonable.
I am not expecting end users to investigate all the potential issues, but know basically how it works and how it is configured if it is not the default system.
Maybe expecting software to just work is idealistic but how is it ever free riding?
What I am trying to say is that a user who expect new init systems to work perfectly and isn't using it to help ameliorating it is not doing the right thing.
Ok, we could have guidelines, like what I suggest above, but just saying we use only one init system is wrong.
I didn't suggest that. Propose the guidelines first and get them approved in place before getting alternative init systems into stable branches. This has potential for a lot of mess otherwise. If it's just for devel branch that's fine.
I am not very knowledgable with init systems. Maybe I could come with something, but I have a lot of other fedora related tasks in the queue with higher precedence.
-- Pat
Patrice Dumas wrote:
On Fri, Apr 06, 2007 at 08:02:51PM +0530, Rahul Sundaram wrote:
The problem is that users wouldn't know that the init system they are installing wont work with several packages because these don't provide the init scripts that work with the alternative init system they just installed. If basic integration was not done, the alternative init system would result in non-functional packages, crashes or worse non booting systems.
In my opinion, a user who installs an alternate init system should know about it and understand what happens if it doesn't work. Of course the init system should basically work, otherwise it shouldn't be in the stable branch but I don't think that we should wait for all packages to be covered by the init system before letting it go in the stable branch.
Right. I think then we are in agreement on that. The tricky question is what is the point at we allow a new init system into the stable repository. What % of services should be covered? We need to have some policies to ensure that a user doesn't end up with unbootable systems just because they install a new package. Last time I played with initng it required configuration changes and it had boot options to fall back to using the default init system. We need policies to ensure that similar things are in place for any other init systems we allow into the stable repo.
What I am trying to say is that a user who expect new init systems to work perfectly and isn't using it to help ameliorating it is not doing the right thing.
We have lots of end users who don't file bug reports when they come across brokeness. I haven't always done it methologically myself. Sometimes a workaround is just easier. I don't think that's free riding. Just different priorities.
I am not very knowledgable with init systems. Maybe I could come with something, but I have a lot of other fedora related tasks in the queue with higher precedence.
If you are advocating for alternative init systems I hope you take sometime to do that.
Rahul
On Sun, Apr 08, 2007 at 08:59:24PM +0530, Rahul Sundaram wrote:
If you are advocating for alternative init systems I hope you take sometime to do that.
I am not essentially advocating for alternative init systems, but I am advocating for diversity and not having artificial entry barriers. I have already seen people saying only one dm, only one libc, and so on and so forth. This, in general, comes with a preference for desktop users and for things that just work, even if they are not easy to customize. I'd like that power users (like myself) also keep on use, contribute and feel that fedora is right and welcoming for them.
-- Pat
2007/4/8, Patrice Dumas pertusus@free.fr:
On Sun, Apr 08, 2007 at 08:59:24PM +0530, Rahul Sundaram wrote:
If you are advocating for alternative init systems I hope you take sometime to do that.
I am not essentially advocating for alternative init systems, but I am advocating for diversity and not having artificial entry barriers. I have already seen people saying only one dm, only one libc, and so on and so forth. This, in general, comes with a preference for desktop users and for things that just work, even if they are not easy to customize. I'd like that power users (like myself) also keep on use, contribute and feel that fedora is right and welcoming for them.
_Nobody_ has suggested that only one desktop environment or a single window manager should be available in Fedora. Please stick to the facts.
The point that you seem to be missing is the fact that there is a huge difference between shipping two window managers and two different init systems. For each init system all packages that provide services would have to maintain different start-up scripts for each init system.
I think it is better to test and benchmark the different init systems outside of the main repositories, and when the time is right, and opinions backed by measured results, a new init system can be introduced into Fedora.
On Sun, Apr 08, 2007 at 07:40:54PM +0200, Trond Danielsen wrote:
2007/4/8, Patrice Dumas pertusus@free.fr:
On Sun, Apr 08, 2007 at 08:59:24PM +0530, Rahul Sundaram wrote:
If you are advocating for alternative init systems I hope you take sometime to do that.
I am not essentially advocating for alternative init systems, but I am advocating for diversity and not having artificial entry barriers. I have already seen people saying only one dm, only one libc, and so on and so forth. This, in general, comes with a preference for desktop users and for things that just work, even if they are not easy to customize. I'd like that power users (like myself) also keep on use, contribute and feel that fedora is right and welcoming for them.
_Nobody_ has suggested that only one desktop environment or a single window manager should be available in Fedora. Please stick to the facts.
I didn't said wm, but dm (display manager). It is there: https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00408.ht... For the one libc and no static linking against dietlibc, even if it is more efficient I could find the thread too, if you really want to.
The point that you seem to be missing is the fact that there is a huge difference between shipping two window managers and two different init systems. For each init system all packages that provide services would have to maintain different start-up scripts for each init system.
Right, I agree on that. But it doesn't change my point, although I agree that there should be init files for the main services, especially the system daemons before it goes in the stable releases.
I think it is better to test and benchmark the different init systems outside of the main repositories, and when the time is right, and opinions backed by measured results, a new init system can be introduced into Fedora.
I disagree. This adds a barrier for those who have the knowledge and the will to package and use different init systems.
-- Pat
On Fri, 2007-04-06 at 20:02 +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
I may be wrong, but I don't think that any user will chose another init system than the default init system unknowingly.
The problem is not that the user would unknowingly install a different init system (They could install any packages without understanding it but that is not a init system specific issue so we needn't discuss that in this thread).
The problem is that users wouldn't know that the init system they are installing wont work with several packages because these don't provide the init scripts that work with the alternative init system they just installed. If basic integration was not done, the alternative init system would result in non-functional packages, crashes or worse non booting systems.
che can correct me if I'm wrong but I believe the user of a new init system such as initng has to install the new init *and* manually configure the commandline in grub to boot with the alternate init. So I really think you're overstating the "non-functionalness" here. Moreover, since SysVinit is nearly impossible to remove from the system without pulling an esr, if I "break" it, all I have to do to unbreak it is edit the grub entry and remove the init= line.
-Toshio
Toshio Kuratomi wrote:
che can correct me if I'm wrong but I believe the user of a new init system such as initng has to install the new init *and* manually configure the commandline in grub to boot with the alternate init.
no the package creates the grub entry in %post using grubby so after installing initng from extras you will get a new option in grub called "initng boot"
we already have a alternative initsystem in fedora (initng), so why not allow others too?
On Mon, Apr 09, 2007 at 10:57:22AM +0200, dragoran wrote:
we already have a alternative initsystem in fedora (initng), so why not allow others too?
They are de facto allowed, because anybody can submit them for review. But Rahul point is right, allowing alternative initsystem in stable release if they don't work properly or don't cover the more used daemons is a bad idea.
-- Pat
On 4/6/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Patrice Dumas wrote:
You cannot say that for packagers. Packagers may be interested in that work. If we forbid new init systems we prevent interested people to do the job.
Are you suggesting that all packagers would be interested in providing alternative versions of the required init scripts for all different init scripts systems?
Why? If people are interested, they will make it scale.
The problem happens when people are not interested. We would end up having init script systems which don't work properly because the packages dont provide init scripts except for the default init script system. When end users find more such packages in the repository (which do not know is experimental), the level of trust on the quality of the repository goes down. More choices without proper integration and testing is bad.
The question here is: What do you propose to guarantee better integration for all the different init scripts?
I think the best way to attack this issue would be with a wrapper script. The packagers can still use their current init scripts, just have the wrapper script run after the package is installed and convert the packagers init script to the format of the installed init system.
Just a thought, this may seem like a crude hack, but it really would allow the most flexibility.
-- R/S --------------------------------- Derek Tracy tracyde@gmail.com ---------------------------------
2007/4/4, Bernardo Innocenti bernie@develer.com:
Rudolf Kastl wrote:
actually i am using und helping with development of initng since around a year now on my boxes and it wfm. i boot graphically into gdm in about 15 seconds with some basics and NetworkManager started.
My experience was similar: initng brings up the system so quickly that I can't even *see* what's going on before X replaces the console.
initng will also get an event plugin for event functionality and also has a nice modular design.
This is IMHO a "must have" for next generation's Linux init system. It's not worth breaking a mature critical system such as SysVInit just to save a few seconds of boot time.
with the next release iteration there will also be a new init script system using posix compliant init scripts.
This is also important in my opinion: those .i files with their custom syntax are the reason why I said initg looked a bit kludgy in my original posting.
yet i only saw upstart running in compat mode and upstart in compat mode has exactly 0 benefits towards systemV because it still uses the systemV init scripts without parallel execution plus it adds yet another useless sleeping process in that state.
What do you mean by compatibility mode? I've only seen Upstart in Ubuntu Feisty. Booting was so fast that I assumed it was parallel already.
actually what i mean is simply that if you use upstart with the backwards compat option all it does is exactly behave like systemV with no benefits at all.
if you are interested i could send you an upstart src rpm that should also install in parallel cleanly and boot up fedora. boot time is exactly the same as with sysV as in this mode it exactly behaves like sysV.
The nice thing about Upstart is that it looks and feels familiar to anybody who's used to sysvinit. Except that /etc/inittab is gone, but nobody will ever miss it ;-)
launchd doesent build on linux for me yet. if anyone has patches it would be great if he could make em public.
Maybe the APL could be a problem for such a core component.
The design of launchd also appears less orthogonal to me than the alternatives, altough I understand that crond and inetd should somehow coordinate with the init system to get a number of corner cases right.
Also, a radical approach such as launchd is less likely to become mature enough to replace sysvinit in the short term. You'd need massive coordination between hundereds of package maintainers.
And by the way: the init system is not something I'd like to see forked in every Linux distro. Ubuntu adopted Upstart early and Debian will most probably follow soon or later.
LSB had just finished standardizing the init scripts and now we're going to break things again. Users *are* going to complain. Analysts *are* going to say Linux is fragmented. Microsoft *is* going to publish studies saying that Linux has higher TCO because of multiple init systems ;-)
So maybe it would be wise if the remaining mainstream distros, including Fedora and SuSE, followed their lead quietly instead of starting a pointless init war.
its not about politics here... in my eyes it must be a plain technical evaluation and decision based on technical facts rather than looking at what other distros do. if i wanted exactly what other distros do id just use those.
all distros also have their own config tools... their own installer... their kernel flavour with their own patchsets etc etc. i dont see where this really hurts development. as someone else pointed out its a good idea to make it parallel installable (my upstart test package is parallel installable and initng in fedora-extras is aswell) and see where those systems go in the future. having 2 solutions ready is generally better than only one.
This doesn't mean there should be a single codebase. Multiple systems could compete as long as they are 100% (or maybe just 99%) compatible config files and user interface.
those need a new standard then or the existing standards need to be enhanced to reflect the additional functionality. from my current point of view the init scripts we use today are bash hacks with lots of workarounds in it and the current "standards" encourage to do those hacks instead of getting the things fixed upstream and the daemon functionality properly done.
that was one of the positive things about the .i files because it encourages upstream / maintainers to clean up the init script functionality actually and not to use workarounds scripted with bash.
regards, Rudolf Kastl
-- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bernardo Innocenti wrote:
What do you mean by compatibility mode? I've only seen Upstart in Ubuntu Feisty. Booting was so fast that I assumed it was parallel already.
Upstart does not run init scripts in parallel at all.
Rahul
On Wed, 2007-04-04 at 22:30 +0530, Rahul Sundaram wrote:
Bernardo Innocenti wrote:
What do you mean by compatibility mode? I've only seen Upstart in Ubuntu Feisty. Booting was so fast that I assumed it was parallel already.
Upstart does not run init scripts in parallel at all.
It does, but _Ubuntu_ doesn't utilize that functionality yet.
why? i have browsed through the kernel (with the "make menuconfig" thing) and i saw ALOT of stuff that i simply don`t need.. specially those annoying debugging messages at the start... they are turned on and can`t be turned off without changing it in the kernel.. (the boot quiet option doesn`t work).
and about the boot progress itself.. i understand that alot of stuff will needs to be loaded but does it really all have to start at once at boot? can`t the CORE ESSENTIALS be started together with gnome als often used programs pre cached so that the boot is fast and the desktop starts fast.
lets take bluetooth for example.. i don`t need to have that on all the time. i even SWITCHED back to wired mouses and keyboards because my bluetooth desktop set wasn`t even working (that was with FC6.. don`t know for FC7). just start the services when a user needs them and autostart it when a user often needs it... will require some coding but will work alot faster simply because there is less to start AND it`s really only starting what the user uses most.
would be cool :) Mark.
2007/4/3, dragoran drago01@gmail.com:
Mark wrote:
i wasn`t expecting so much reactions on this topic.. the more the better though.
but i think that the boot time can be brought down alot just be
providing
some more options for the boot progress.. for example.. let the users choose which kernel modules should load.. things like that could make a change
this does not make any sense... the kernel / udev should only load needed modules everything else is a bug
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
tir, 03 04 2007 kl. 23:04 +0200, skrev Mark:
why? i have browsed through the kernel (with the "make menuconfig" thing) and i saw ALOT of stuff that i simply don`t need.. specially those annoying debugging messages at the start... they are turned on and can`t be turned off without changing it in the kernel.. (the boot quiet option doesn`t work).
That is on purpose for the Development cycles, it helps locate problems when you report bugs. The patch is backed out for production releases.
- David Nielsen
On 4/3/07, Mark markg85@gmail.com wrote:
why? i have browsed through the kernel (with the "make menuconfig" thing) and i saw ALOT of stuff that i simply don`t need.. specially those annoying debugging messages at the start... they are turned on and can`t be turned off without changing it in the kernel.. (the boot quiet option doesn`t work).
you where talking about kernelmodules... there are no debug _modules_ that get loaded by default.
and about the boot progress itself.. i understand that alot of stuff will
needs to be loaded but does it really all have to start at once at boot? can`t the CORE ESSENTIALS be started together with gnome als often used programs pre cached so that the boot is fast and the desktop starts fast.
lets take bluetooth for example.. i don`t need to have that on all the time. i even SWITCHED back to wired mouses and keyboards because my bluetooth desktop set wasn`t even working (that was with FC6.. don`t know for FC7). just start the services when a user needs them and autostart it when a user often needs it... will require some coding but will work alot faster simply because there is less to start AND it`s really only starting what the user uses most.
again my reply was refering to the "only load kernelmodules that I need" statement.
would be cool :)
Mark.
2007/4/3, dragoran drago01@gmail.com:
Mark wrote:
i wasn`t expecting so much reactions on this topic.. the more the better though.
but i think that the boot time can be brought down alot just be
providing
some more options for the boot progress.. for example.. let the users choose which kernel modules should load.. things like that could make a change
this does not make any sense... the kernel / udev should only load needed modules everything else is a bug
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
sorry, my mistake. it`s indeed only loading the kernel modules that are needed. what i actuallt mean is that there are way more things compiled inside the kernel than i need but that`s just me.. someone else might need those things so i understand why they are compiled in.
and can someone tell us (atleast me ;)) about the new init methods and timings? because it sounds interesting to me (i would love to have a 10 second boot ^_^)
Mark
2007/4/3, dragoran dragoran drago01@gmail.com:
On 4/3/07, Mark markg85@gmail.com wrote:
why? i have browsed through the kernel (with the "make menuconfig" thing) and i saw ALOT of stuff that i simply don`t need.. specially those annoying debugging messages at the start... they are turned on and can`t be turned off without changing it in the kernel.. (the boot quiet option doesn`t work).
you where talking about kernelmodules... there are no debug _modules_ that get loaded by default.
and about the boot progress itself.. i understand that alot of stuff will
needs to be loaded but does it really all have to start at once at boot? can`t the CORE ESSENTIALS be started together with gnome als often used programs pre cached so that the boot is fast and the desktop starts fast.
lets take bluetooth for example.. i don`t need to have that on all the time. i even SWITCHED back to wired mouses and keyboards because my bluetooth desktop set wasn`t even working (that was with FC6.. don`t know for FC7). just start the services when a user needs them and autostart it when a user often needs it... will require some coding but will work alot faster simply because there is less to start AND it`s really only starting what the user uses most.
again my reply was refering to the "only load kernelmodules that I need" statement.
would be cool :)
Mark.
2007/4/3, dragoran < drago01@gmail.com>:
Mark wrote:
i wasn`t expecting so much reactions on this topic.. the more the better though.
but i think that the boot time can be brought down alot just be
providing
some more options for the boot progress.. for example.. let the
users
choose which kernel modules should load.. things like that could make a change
this does not make any sense... the kernel / udev should only load needed modules everything else is a bug
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
its a bit of a pity this thread is drifting a bit off the init system discussion from my point of view because the thread topic now is somewhat misleading.
i was hoping to get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora.
regards, Rudolf Kastl
than just ask it :)
can we please : "get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora."
2007/4/4, Rudolf Kastl che666@gmail.com:
its a bit of a pity this thread is drifting a bit off the init system discussion from my point of view because the thread topic now is somewhat misleading.
i was hoping to get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora.
regards, Rudolf Kastl
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
What's about "runit" from Gerrit Pape http://smarden.org/runit/index.html
It's small, fast - with dietlibc it has a very small memory footprint. Ok, it's very different from the sysv-init scheme but afaik it can be configured to be LSB compliant. I use it on some Fedora PCs for several daemons and system-config-services is also able to control this daemons.
best regards, Jochen
Mark wrote:
than just ask it :)
can we please : "get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora."
2007/4/4, Rudolf Kastl <che666@gmail.com mailto:che666@gmail.com>:
its a bit of a pity this thread is drifting a bit off the init system discussion from my point of view because the thread topic now is somewhat misleading. i was hoping to get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora. regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-list
i havent tried it myself but i will be going to make test packages for further evaluation. curious to see what benefits it has.
regards, Rudolf Kastl
p.s. there are various more unknown systems i yet just didnt consider worth investigating due to lack of upstream progress or incomplete featuresets etc.
2007/4/5, Jochen Schlick jochen.schlick@comsoft.de:
What's about "runit" from Gerrit Pape http://smarden.org/runit/index.html
It's small, fast - with dietlibc it has a very small memory footprint. Ok, it's very different from the sysv-init scheme but afaik it can be configured to be LSB compliant. I use it on some Fedora PCs for several daemons and system-config-services is also able to control this daemons.
best regards, Jochen
Mark wrote:
than just ask it :)
can we please : "get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora."
2007/4/4, Rudolf Kastl <che666@gmail.com mailto:che666@gmail.com>:
its a bit of a pity this thread is drifting a bit off the init system discussion from my point of view because the thread topic now is somewhat misleading. i was hoping to get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora. regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Jochen Schlick mailto:jochen.schlick_at_comsoft.de
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
i`ve tried initng on a updated FC7 T3 but it can`t seem to get passed udev.. i can just reboot fine with CTRL+ALT+DEL..
2007/4/5, Rudolf Kastl che666@gmail.com:
i havent tried it myself but i will be going to make test packages for further evaluation. curious to see what benefits it has.
regards, Rudolf Kastl
p.s. there are various more unknown systems i yet just didnt consider worth investigating due to lack of upstream progress or incomplete featuresets etc.
2007/4/5, Jochen Schlick jochen.schlick@comsoft.de:
What's about "runit" from Gerrit Pape http://smarden.org/runit/index.html
It's small, fast - with dietlibc it has a very small memory footprint. Ok, it's very different from the sysv-init scheme but afaik it can be configured to be LSB compliant. I use it on some Fedora PCs for several daemons and system-config-services is also able to control this daemons.
best regards, Jochen
Mark wrote:
than just ask it :)
can we please : "get a bit more constructive feedback about the current state of various init systems and/or help/patches/ideas about future init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora."
2007/4/4, Rudolf Kastl <che666@gmail.com mailto:che666@gmail.com>:
its a bit of a pity this thread is drifting a bit off the init
system
discussion from my point of view because the thread topic now is somewhat misleading. i was hoping to get a bit more constructive feedback about the
current
state of various init systems and/or help/patches/ideas about
future
init systems from a pure scientific/technical point of view from people with first hand experience with trying out those systems on fedora. regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Jochen Schlick mailto:jochen.schlick_at_comsoft.de
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thanx for that suggestion. i will give it a try
2007/4/5, dragoran drago01@gmail.com:
Mark wrote:
i`ve tried initng on a updated FC7 T3 but it can`t seem to get passed udev.. i can just reboot fine with CTRL+ALT+DEL..
thats a bug in the selinux startup scripts which I fixed upstream. (try a newer ifiles release)
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Once upon a time, Tom Lane tgl@redhat.com said:
I think our problems are much more localized than that. In my personal environment, the single biggest boot-time problem is that netatalk takes friggin forever (~ 1 min) to sync with an existing Appletalk seed router. But I don't reboot my Fedora machines often enough to make it worth my time to track it down ...
Yeah, I have one annoyance during boot (it isn't nearly as long though): nut takes something like 5-10 seconds to start talking to my UPS before boot can continue.
I think a big help would be some method of setting what needs to run before logins and what can be delayed. There is no reason for the whole system to stop while nut tries to find the UPS.
On Tue, Apr 03, 2007 at 08:31:16 -0500, Chris Adams cmadams@hiwaay.net wrote:
I think a big help would be some method of setting what needs to run before logins and what can be delayed. There is no reason for the whole system to stop while nut tries to find the UPS.
I could see not starting some applications/services until after nut is running, so that you know you aren't going to immediately shutdown again. (Or worse, run out of battery before the shutdown can complete.)