On Fri, 22 Jun 2012 09:02:44 +0200 (CEST)
Wojciech Puchar wrote:
> >> why adding solaris style command to add a line in text file. just edit a
> > text file.
> >>
> >
> > Scripting?
>
>
>
> echo newserviceline >>file
>
> grep -v servicetoberemoved file >file.new;mv file.new file
>
Why have
why adding solaris style command to add a line in text file. just edit a
text file.
Scripting?
echo newserviceline >>file
grep -v servicetoberemoved file >file.new;mv file.new file
___
freebsd-hackers@freebsd.org mailing list
http://lists.free
On Jun 22, 2012 7:33 AM, "Wojciech Puchar"
wrote:
>>>
>>> separate and optional program.
>>> that's acceptable, except i have no idea why this fscadm enable/disable.
>>> editing config is enough.
>>
>>
>> I don't think I understand
>> "i have no idea why this fscadm enable/disable. editing config
separate and optional program.
that's acceptable, except i have no idea why this fscadm enable/disable.
editing config is enough.
I don't think I understand
"i have no idea why this fscadm enable/disable. editing config is enough."
and would ask you elaborate for me. Thanks,
why adding solar
On Thu, 21 Jun 2012 18:20:44 +0200 (CEST)
Wojciech Puchar wrote:
> >> should not be done, or at least not default.
> >
> > http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc)
> > http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Servi
On 06/21/2012 06:49 PM, Atte Peltomäki wrote:
> On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote:
>> There's no need to do a wholesale replacement of the RC system in
>> FreeBSD to support this concept. What you are describing are "service
>> profiles". And we already have a single fi
On 2012-Jun-21 00:17:11 +0200, Wojciech Puchar
wrote:
>> - Lack of dependency handling for manual start/stop
>
>which is not really a problem and often an adventage.
In your opinion. IMO, "runlevels" are a mostly a work-around to hide
the lack of proper dependency handling.
One obvious use for
On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote:
> There's no need to do a wholesale replacement of the RC system in
> FreeBSD to support this concept. What you are describing are "service
> profiles". And we already have a single file that describes the
> default "service profile" f
On 2012-Jun-21 10:09:01 -0700, Doug Barton wrote:
>On 06/21/2012 05:28 AM, Peter Jeremy wrote:
>> 32.0s - rc scripts ("mounting root" through VTY login prompt)
>
>I think that there is some confusion about what I wrote originally, so
>let me clarify. From the time that /etc/rc starts through the t
manage if you're doing something pre-configured (like
starting/stopping an existing service), but if you want to do
something custom you have to do a *lot* of digging to figure out how
to make it work. Some of the new stuff (like NWAM network
configuration) is not even configurable without a GUI.
On Thu, Jun 21, 2012 at 5:13 AM, Chris Rees wrote:
> Your arrogance is astounding.
>
> Did you read man hier? Unfamiliarity does not make it incomprehensible.
There's more going on than just unfamiliarity. Earlier versions were
unfamiliar to someone used to Linux or BSD, but easy to understand
b
z>
my point is that if you put new startup system in place of old, nothing
will change with your existing rc.conf!
Also true in the counter proposal.
so i miss something about the counterproposal.
please point me out
___
freebsd-hackers@freebsd.org
On Thu, 21 Jun 2012 20:01:41 +0200 (CEST)
Wojciech Puchar wrote:
> >> 1) "runlevels" with arbitrary names. runlevel change would start and stop
> >> right services.
> >
> > With a couple of additions:
> > - it should be easy to see which services are on at a given runlevel.
>
> already propo
1) "runlevels" with arbitrary names. runlevel change would start and stop
right services.
With a couple of additions:
- it should be easy to see which services are on at a given runlevel.
already proposed in rc.conf
- it should be easy to see which runlevels a service is on at.
sam
On Thu, 21 Jun 2012 12:22:08 +0200 (CEST)
Wojciech Puchar wrote:
> Lets make a summary.
>
> What functionality would be good to have in FreeBSD that doesn't exist:
>
> 1) "runlevels" with arbitrary names. runlevel change would start and stop
> right services.
With a couple of additions:
On 06/21/2012 05:28 AM, Peter Jeremy wrote:
> 32.0s - rc scripts ("mounting root" through VTY login prompt)
I think that there is some confusion about what I wrote originally, so
let me clarify. From the time that /etc/rc starts through the time that
the prompt appears almost all of the time is sp
On Thu, Jun 21, 2012 at 05:19:27PM +0100, Chris Rees wrote:
> On Jun 21, 2012 5:15 PM, "Jason Hellenthal" wrote:
> >
> >
> >
> > On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote:
> > > Lets make a summary.
> > >
> > > What functionality would be good to have in FreeBSD that doesn'
should not be done, or at least not default.
http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc)
http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control
separate and optional program.
that's acceptable, except i have no i
On Jun 21, 2012 5:15 PM, "Jason Hellenthal" wrote:
>
>
>
> On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote:
> > Lets make a summary.
> >
> > What functionality would be good to have in FreeBSD that doesn't exist:
> >
> > 1) "runlevels" with arbitrary names. runlevel change would st
Try something like the following...
service_runlevels="1 2 3 4 5"
And provide a way to say...
Well - i agree with you.
just invent a syntax to define service runlevels as "all except ...".
___
freebsd-hackers@freebsd.org mailing list
http://lists.f
On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote:
> Lets make a summary.
>
> What functionality would be good to have in FreeBSD that doesn't exist:
>
> 1) "runlevels" with arbitrary names. runlevel change would start and stop
> right services.
> 2) exploit startup parallelism.
Hello,
Just picking a random message related to this issue. Maybe Tom might
update us a bit with the status of his project ;-)
Citát Wojciech Puchar :
- monitor running services and restart them if they crash
should not be done, or at least not default.
http://www.freebsd.org/news/statu
On Thu, 21 Jun 2012 17:10:06 +0200
Daniel Gerzo wrote:
> Hello,
>
>
> Just picking a random message related to this issue. Maybe Tom might
> update us a bit with the status of his project ;-)
Oh, put me on the spot, thanks Daniel! :)
>
> Citát Wojciech Puchar :
> >>> - monitor running ser
On 2012-Jun-18 19:18:57 -0400, Brandon Falk wrote:
>As the original poster of this thread, I can also say that Doug is
>correct. The issue is not rc, it is the actual kernel boot process.
I've videoed my netbook rebooting and gone through the video in slow
motion and that definitely doesn't mat
On Jun 20, 2012 11:03 PM, "Wojciech Puchar"
wrote:
>>>
>>> scripts, i deleted most of it and put startup sequence in single file.
>>>
>>> It was plain horror.
>>
>>
>> You would weep if you saw Solaris's SMF, then. Everything is
>
>
> i don't really know what i've seen. i've installed latest sola
Am 21.06.2012, 12:56 Uhr, schrieb Wojciech Puchar
:
ifconfig_em0="inet ..." ( default (or unknown) runlevel )
ifconfig_em0_foolevel="inet ..." ( foolevel runlevel )
ifconfig_em0_maintenance="inet ..." ( maintanence runlevel )
too ?
well - possible BUT... but well.
this will not requir
Am 21.06.2012, 12:22 Uhr, schrieb Wojciech Puchar
:
Lets make a summary.
What functionality would be good to have in FreeBSD that doesn't exist:
1) "runlevels" with arbitrary names. runlevel change would start and
stop right services.
2) exploit startup parallelism.
What we do not want
ifconfig_em0="inet ..." ( default (or unknown) runlevel )
ifconfig_em0_foolevel="inet ..." ( foolevel runlevel )
ifconfig_em0_maintenance="inet ..." ( maintanence runlevel )
too ?
well - possible BUT... but well.
this will not require only changing "launcher" script for rc.d/* things
but
Lets make a summary.
What functionality would be good to have in FreeBSD that doesn't exist:
1) "runlevels" with arbitrary names. runlevel change would start and stop
right services.
2) exploit startup parallelism.
What we do not want to change:
- file structure which is simple. one file in
All that's missing is a way to tell the RC system to use a different
rc.conf file (like rc.conf.mobile, or rc.conf.wireless or
rc.conf.whatever), and to run through the RC setup based on that file.
... and to be able to switch between two configurations at runtime,
without taking down services l
Am 20.06.2012, 23:42 Uhr, schrieb Freddie Cash :
On Wed, Jun 20, 2012 at 1:28 PM, Daniel Robbins
wrote:
On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins
wrote:
This doesn't change the "hard" runlevel (3) but it changes the OpenRC
logical runlevel. Basically, this convenient system is compa
# rc maintenance
# rc online
this functionality seems useful.
That's... not the word I'd have used.
I'm sort-of-emulating this using custom scripts quite often,
true. custom script that do lots of start or stops are good.
But with N>2 "runlevels" without this subsystem you would need
to
The more different projects can share common code, the better.
as long as we share good code and good ideas.
Boot time is an issue for some people - even people with "never
rebooted" servers need fast boot times when they _do_ need to reboot
speeding up anything is always good.
I think the
To create a separately-managed runlevel, you would just:
# mkdir /etc/runlevels/maintenance
# rc-update add maintenance svc1
# rc-update add maintenance svc2
# rc-update add maintenance svc1
seems already not nice. Cannot i just edit one file to do this using my
favourite text editor?
__
scripts, i deleted most of it and put startup sequence in single file.
It was plain horror.
You would weep if you saw Solaris's SMF, then. Everything is
i don't really know what i've seen. i've installed latest solaris demo
downloaded from oracle. After nearly an hour of installation over w
On 2012-Jun-20 09:05:05 -0600, Daniel Robbins wrote:
>I see a great potential for collaboration here between Gentoo, Funtoo
>(my current project, a derivative/fork of Gentoo), FreeBSD and OpenRC
>(which is now an independently-managed project, distinct from the
>upstream distros)
The more differe
On Wed, Jun 20, 2012 at 1:28 PM, Daniel Robbins wrote:
> On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins wrote:
>>
>> This doesn't change the "hard" runlevel (3) but it changes the OpenRC
>> logical runlevel. Basically, this convenient system is compatible with
>> traditional linux numerical runl
Am 20.06.2012, 22:29 Uhr, schrieb Wojciech Puchar
:
# rc maintenance
# rc online
this functionality seems useful.
That's... not the word I'd have used.
I'm sort-of-emulating this using custom scripts quite often,
and especially with the stacked runlevel variety, this is something I
real
On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins wrote:
>
> This doesn't change the "hard" runlevel (3) but it changes the OpenRC
> logical runlevel. Basically, this convenient system is compatible with
> traditional linux numerical runlevels but does depend on them.
>
Meant to type: "does NOT dep
On Wed, Jun 20, 2012 at 8:51 AM, Wojciech Puchar
wrote:
> Some time ago i had to use linux (fortunately no longer needed). As i don't
> use it normally i just took debian installer that i remembered it WAS
> usable.
>
> After seeing the incredible complexity of /etc structure, not just rc
> script
On Wed, Jun 20, 2012 at 1:52 PM, Michael Ross wrote:
>
> Just to clarify:
> In OpenRC I can have *arbitrary* runlevels?
> Not like as I remember from years ago when I used Linux, "runlevel 1 2 3 4
> 5",
> but any number of "default" "online" "maintenance",
> and thus I'd have *sets* of services I
# rc maintenance
# rc online
this functionality seems useful.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
I think our current system for OpenRC is pretty elegant. Initscripts
go in /etc/init.d. Runlevels are defined as directories in
/etc/runlevels. The default runlevel is /etc/runlevels/default.
in FreeBSD you must handle /etc/* and /usr/local/etc/* - one for base
system rest for ports.
runlevels
So, if Mr Puchar, in his comment, changes complex for complicated, then
I think we can all agree with the wish that it does not add complication.
right. i mean complicated or overcomplex.
If anyone still don't know what i mean, i recommend installing any of
those trendy new cool flashy linux di
Am 20.06.2012, 18:13 Uhr, schrieb Daniel Robbins :
To add a service to a runlevel, you type "rc-update add
".
To start/stop all services according to runlevel, you type "rc".
To switch runlevels, you type "rc ", like "rc mobile".
Just to clarify:
In OpenRC I can have *arbitrary* runlevels?
On Wed, Jun 20, 2012 at 9:51 AM, Wojciech Puchar
wrote:
>
> actually i am happy with current system, but maybe others.
>
> My most important ideas are:
>
> - any new system should not be more complex - ability to keep all flags and
> main config in single file (/etc/rc.conf) must persist. I don't
On Jun 20, 2012, at 11:43 AM, Daniel Robbins wrote:
> On Wed, Jun 20, 2012 at 9:28 AM, Wojciech Puchar
> wrote:
>>
>> Whatever benefits are, and for sure they are think of this:
>>
>> 1) can it be compatible with 2 ports already made for FreeBSD, where
>> many of them install rc.d script
On 06/20/2012 11:28 AM, Wojciech Puchar wrote:
>> Hi all, I wanted to jump in here. My name is Daniel Robbins and I'm
>> the creator of Gentoo Linux and the original designer of the Gentoo
>> initscripts, which now exist in rewritten form as OpenRC. FreeBSD
>> inspired many of the concepts in Gento
On Wed, Jun 20, 2012 at 3:23 PM, Mark Felder wrote:
> On Wed, 20 Jun 2012 04:27:09 -0500, Fernando Apesteguía
> wrote:
>
>> Also, in embedded systems, boot time is an important factor.
>
>
> If you're designing a very specific embedded product based on FreeBSD why
> aren't you writing your own st
On Wed, Jun 20, 2012 at 05:51:10PM +0200, Wojciech Puchar wrote:
> >So let me know if you have any ideas for anything that would be
> >considered more than just a slight improvement, that would make you go
> >"OK, now it's seriously worth considering OpenRC as this is more than
> >just a nominal i
On Wed, Jun 20, 2012 at 9:28 AM, Wojciech Puchar
wrote:
>
> Whatever benefits are, and for sure they are think of this:
>
> 1) can it be compatible with 2 ports already made for FreeBSD, where
> many of them install rc.d scripts in CURRENT format.
OK. This will clearly be needed, and shouldn'
So let me know if you have any ideas for anything that would be
considered more than just a slight improvement, that would make you go
"OK, now it's seriously worth considering OpenRC as this is more than
just a nominal improvement in functionality."
actually i am happy with current system, but
On Wed, Jun 20, 2012 at 8:19 AM, Wojciech Puchar
wrote:
>>> That is already done in Gentoo FreeBSD, or do you want me to do the
>>> work for you to integrate OpenRC in the base system?
>>
>> We want you to do the work to prove that it is an improvement. Otherwise
>> it's "just another claim."
>
>
That is already done in Gentoo FreeBSD, or do you want me to do the
work for you to integrate OpenRC in the base system?
We want you to do the work to prove that it is an improvement. Otherwise
it's "just another claim."
rc subsystem is fine. Changing it would be another mess.
On Wed, Jun 20, 2012 at 04:17:52PM +0300, Vitaly Magerya wrote:
> The last time concurrent rc patches where proposed I measured boot time
> on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from
> power on to login prompt, 20-25 where spent in rc, and parallel
> execution of it shaved
Hi all, I wanted to jump in here. My name is Daniel Robbins and I'm
the creator of Gentoo Linux and the original designer of the Gentoo
initscripts, which now exist in rewritten form as OpenRC. FreeBSD
inspired many of the concepts in Gentoo Linux.
I see a great potential for collaboration here b
Also, in embedded systems, boot time is an important factor.
If you're designing a very specific embedded product based on FreeBSD why
aren't you writing your own startup system? Why would anyone expect a general
what i not only already proposed, but did myself doing my own FreeBSD set
for
The last time concurrent rc patches where proposed I measured boot time
on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from
power on to login prompt, 20-25 where spent in rc, and parallel
execution of it shaved off 7 seconds from boot time.
I'm also seeing similar breakdown on Vi
On 06/20/2012 03:39 AM, Mark Linimon wrote:
> fwiw, from previous discussions on FreeBSD boot time, ISTR that there
> are other places where more time is spent. Some analysis to prove that
> indeed the rc subsystem is the dominant term would be a good starting
> place.
I neither claimed that it w
On Wed, 20 Jun 2012 04:27:09 -0500, Fernando Apesteguía
wrote:
Also, in embedded systems, boot time is an important factor.
If you're designing a very specific embedded product based on FreeBSD why
aren't you writing your own startup system? Why would anyone expect a
general purpose "ou
Mark Linimon wrote:
> fwiw, from previous discussions on FreeBSD boot time, ISTR that there
> are other places where more time is spent. Some analysis to prove that
> indeed the rc subsystem is the dominant term would be a good starting
> place.
While I don't want to proliferate this thread or ad
Wojciech Puchar wrote:
Personally I think that the kernel boot time is the killer here and
the work should go there and second on the rc system.
exactly what i wrote. rc.d subsystem is quick, and anyway in special
cases just delete in and write all needed startup in /etc/rc
i assume it is embed
The problem is deeper, I'm using minimalized kernel without USB and greatest
hang is 3 or so seconds after "Timecounters tick every 1.000 msec" just
before ada0 appears.
And I have already tried modularized ada - results are the same.
Did you tried to add printk within freebsd kernel now and
I was working on a reply along similar lines, but instead I'll say that
i agree 100% with what Mark said, and thanks to him for saving me a lot
of time. :)
Richard, with all that said if you still are interested in specs for a
test program, I'm still willing to help with that. Just let me know.
D
On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote:
> That is already done in Gentoo FreeBSD, or do you want me to do the
> work for you to integrate OpenRC in the base system?
We want you to do the work to prove that it is an improvement. Otherwise
it's "just another claim."
You seem t
Personally I think that the kernel boot time is the killer here and the work
should go there and second on the rc system.
exactly what i wrote. rc.d subsystem is quick, and anyway in special cases
just delete in and write all needed startup in /etc/rc
i assume it is embedded system - in which
On Wed, Jun 20, 2012 at 11:36 AM, Wojciech Puchar <
woj...@wojtek.tensor.gdynia.pl> wrote:
> Improving boot times can be done in two ways:
>>
>> 1) Implement proper service dependency handling framework
>> 2) Implement ad-hoc service dependencies
>>
>
> ZERO) Speed up kernel startup
>
> With custo
Improving boot times can be done in two ways:
1) Implement proper service dependency handling framework
2) Implement ad-hoc service dependencies
ZERO) Speed up kernel startup
With custom kernel containing only needed devices it is still a bit long.
rc.d/* things take trivial amount of time co
On Wed, Jun 20, 2012 at 10:59 AM, Atte Peltomäki wrote:
> On Mon, Jun 18, 2012 at 03:53:26PM -0700, Doug Barton wrote:
>> It's unfortunate that this thread evolved into a discussion about
>> replacing rc.d, since that's almost certainly not relevant to the
>> original topic of improving the overal
On Mon, Jun 18, 2012 at 03:53:26PM -0700, Doug Barton wrote:
> It's unfortunate that this thread evolved into a discussion about
> replacing rc.d, since that's almost certainly not relevant to the
> original topic of improving the overall boot time.
Improving boot times can be done in two ways:
1
On Jun 20, 2012, at 12:45 AM, Doug Barton wrote:
> I was working on a reply along similar lines, but instead I'll say that
> i agree 100% with what Mark said, and thanks to him for saving me a lot
> of time. :)
>
> Richard, with all that said if you still are interested in specs for a
> test prog
On Tue, 19 Jun 2012 11:03:31 -0700
Garrett Cooper wrote:
> On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar
> wrote:
> >>> grep sleep /etc/rc.d/* usr/local/etc/rc.d/*
> >>
> >> Sleeps in /etc tend to be there for good reasons, and new ones are
> >> vigorously scrutinized. If you see any that you
On Tue, Jun 19, 2012 at 3:45 PM, Richard Yao wrote:
> On 06/19/2012 06:17 PM, Garrett Cooper wrote:
>> On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao wrote:
>>> On 06/19/2012 04:12 PM, Garrett Cooper wrote:
On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote:
> On 06/19/2012 12:50 PM, Dou
On 06/19/2012 06:17 PM, Garrett Cooper wrote:
> On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao wrote:
>> On 06/19/2012 04:12 PM, Garrett Cooper wrote:
>>> On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote:
On 06/19/2012 12:50 PM, Doug Barton wrote:
> On 6/18/2012 4:05 PM, Richard Yao wro
On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao wrote:
> On 06/19/2012 04:12 PM, Garrett Cooper wrote:
>> On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote:
>>> On 06/19/2012 12:50 PM, Doug Barton wrote:
On 6/18/2012 4:05 PM, Richard Yao wrote:
> Doug, we already have OpenRC implemented.
On 06/19/2012 04:12 PM, Garrett Cooper wrote:
> On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote:
>> On 06/19/2012 12:50 PM, Doug Barton wrote:
>>> On 6/18/2012 4:05 PM, Richard Yao wrote:
Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD
in a jail, install regu
On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao wrote:
> On 06/19/2012 12:50 PM, Doug Barton wrote:
>> On 6/18/2012 4:05 PM, Richard Yao wrote:
>>> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD
>>> in a jail, install regular FreeBSD in another jail and do your own
>>> perf
On 06/19/2012 12:50 PM, Doug Barton wrote:
> On 6/18/2012 4:05 PM, Richard Yao wrote:
>> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD
>> in a jail, install regular FreeBSD in another jail and do your own
>> performance comparisons.
>
> Bt! Thanks for playing. :)
sorry i was wrong /etc/rc.d/defaultroute use sleep to wait for dhclient
only.
On Tue, 19 Jun 2012, Garrett Cooper wrote:
On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar
wrote:
grep sleep /etc/rc.d/* usr/local/etc/rc.d/*
Sleeps in /etc tend to be there for good reasons, and new ones are
v
On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar
wrote:
>>> grep sleep /etc/rc.d/* usr/local/etc/rc.d/*
>>
>> Sleeps in /etc tend to be there for good reasons, and new ones are
>> vigorously scrutinized. If you see any that you think are dubious, feel
>> free to mention them on freebsd-rc@.
>
> I
grep sleep /etc/rc.d/* usr/local/etc/rc.d/*
Sleeps in /etc tend to be there for good reasons, and new ones are
vigorously scrutinized. If you see any that you think are dubious, feel
free to mention them on freebsd-rc@.
I don't say they are not needed but that they exist.
anyway i don't unders
On 6/18/2012 4:05 PM, Richard Yao wrote:
> Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD
> in a jail, install regular FreeBSD in another jail and do your own
> performance comparisons.
Bt! Thanks for playing. :) You're the one proposing the change,
YOU get to do
On 6/18/2012 9:39 PM, Wojciech Puchar wrote:
>> The latter item is the only place where making changes to rc.d is going
>> to help, and only then by parellelizing, and even then you are not
>> really going to gain much since most things at boot time are serial.
>
> grep sleep /etc/rc.d/* usr/local
On 06/19/2012 07:20 AM, Garrett Cooper wrote:
> On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao wrote:
>> On 06/19/2012 12:39 AM, Wojciech Puchar wrote:
>>> - delay at rc.d scripts - there are some delays inserted.
>>>
The latter item is the only place where making changes to rc.d is going
On Tue, 19 Jun 2012 01:04:47 -0400
Richard Yao wrote:
> On 06/19/2012 12:39 AM, Wojciech Puchar wrote:
> > - delay at rc.d scripts - there are some delays inserted.
> >
> >> The latter item is the only place where making changes to rc.d is
> >> going to help, and only then by parellelizing, and e
On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao wrote:
> On 06/19/2012 12:39 AM, Wojciech Puchar wrote:
>> - delay at rc.d scripts - there are some delays inserted.
>>
>>> The latter item is the only place where making changes to rc.d is going
>>> to help, and only then by parellelizing, and even th
On 06/19/2012 12:39 AM, Wojciech Puchar wrote:
> - delay at rc.d scripts - there are some delays inserted.
>
>> The latter item is the only place where making changes to rc.d is going
>> to help, and only then by parellelizing, and even then you are not
>> really going to gain much since most thin
On Tue, Jun 19, 2012 at 6:39 AM, Wojciech Puchar
wrote:
>> replacing rc.d, since that's almost certainly not relevant to the
>> original topic of improving the overall boot time.
>
>
> indeed.
>
>
>>
>> If you analyze the boot process thoroughly you should see that out of
>> the total time taken t
replacing rc.d, since that's almost certainly not relevant to the
original topic of improving the overall boot time.
indeed.
If you analyze the boot process thoroughly you should see that out of
the total time taken to boot, nearly 0 is spent by rc.d actually doing
something. Almost all of th
On 06/18/2012 06:53 PM, Doug Barton wrote:
> It's unfortunate that this thread evolved into a discussion about
> replacing rc.d, since that's almost certainly not relevant to the
> original topic of improving the overall boot time.
>
> If you analyze the boot process thoroughly you should see that
As the original poster of this thread, I can also say that Doug is
correct. The issue is not rc, it is the actual kernel boot process.
Maybe I could see rc becoming an issue in a massive server environment
where there are a lot of userland processes to start, but that delay
would most likely be
It's unfortunate that this thread evolved into a discussion about
replacing rc.d, since that's almost certainly not relevant to the
original topic of improving the overall boot time.
If you analyze the boot process thoroughly you should see that out of
the total time taken to boot, nearly 0 is spe
On 06/18/2012 01:12 PM, Vincent Hoffman wrote:
> On 18/06/2012 09:11, Atte Peltomäki wrote:
>> On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote:
>>> On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki
>>> wrote:
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
> Also
On 18/06/2012 09:11, Atte Peltomäki wrote:
> On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote:
>> On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki
>> wrote:
>>> On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
Also, I am certain that the OpenRC developers would be thr
Replacing rc(8) has a lot of risks and not many benefits. Current system
if you make single-use system (for eg. X11 terminal) just delete most of
files from /etc including /etc/rc and write your own - the simplest
possibe, just put command to run all needed things. that's all.
___
On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote:
> On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki wrote:
> > On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
> >> Also, I am certain that the OpenRC developers would be thrilled if
> >> FreeBSD adopted OpenRC. If FreeBSD c
On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki wrote:
> On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
>> Also, I am certain that the OpenRC developers would be thrilled if
>> FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel
>> free to contact the OpenRC and/or
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
> Also, I am certain that the OpenRC developers would be thrilled if
> FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel
> free to contact the OpenRC and/or the Gentoo FreeBSD developers. We
> would all love to see Ope
On 2012-Jun-13 21:55:22 +0200, Hans Petter Selasky wrote:
>Try setting:
>
>sysctl hw.usb.no_boot_wait=1
Note that this is a tunable and will need to be specified in /boot/loader.conf
to have any effect.
--
Peter Jeremy
pgpojiOBCDYfk.pgp
Description: PGP signature
That is a fairly common response. I would appreciate suggestions on how
I can convey that OpenRC is a good init system.
Also, I am certain that the OpenRC developers would be thrilled if
FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel
free to contact the OpenRC and/or the Gen
1 - 100 of 134 matches
Mail list logo
