Sorry, patch now as an attachment
On Thu, Jun 21, 2012 at 3:55 AM, Eitan Adler wrote:
> On 20 June 2012 16:48, Stanislav Zaharov wrote:
> > Hi all!
> > I changed the sockstat.c, function display() - added a resize of fields,
> > depending on the length of the data. Can I suggest you look at the
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
On 20 June 2012 16:48, Stanislav Zaharov wrote:
> Hi all!
> I changed the sockstat.c, function display() - added a resize of fields,
> depending on the length of the data. Can I suggest you look at the
> resulting source
> code?
no patch is attached. Can you resend or upload somewhere and give th
Hello;
This year the European Space Agency will have it's
second Summer of Code in Space:
http://sophia.estec.esa.int/socis2012/
This may be a good opportunity to get FreeBSD in
yet-another interesting field, plus one of our
projects in the "Ideas Page" seems to be ideal
to get some funding from
# 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
Hi.
I have the problem with different behavior of snd_hdspe(4) sound card
driver initialization.
If I load the driver by hand using kldload everything works fine,
but in case of loading driver at boot time (loader.conf) or compile
in kernel the driver can't initialize propertly.
The snd_hdspe(
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, 2012-06-20 at 03:00 -0700, rank1see...@gmail.com wrote:
> >From 3 machines with that type of cutom kernels, only 1 suffers from
> this (and problem is gone, as soon as I revert to GENERIC)
Please post your "custom kernel config" somewhere so we can see what is
different.
Sean
___
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
So, I have this problem, through all versions, from 8.* to 9.0
It happens when I build a custom kernel, which has ONLY 'device' lines, of
machine's hardware.
From 3 machines with that type of cutom kernels, only 1 suffers from this (and
problem is gone, as soon as I revert to GENERIC)
This delay
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
Ian Lepore wrote:
Using the 'prepend' or 'supercede' keywords in /etc/dhclient.conf is
pretty much the standard way of handling a mix of static and dhcp
interfaces where the static config needs to take precedence. I'm not
sure why you dismiss it as essentially good, but somehow not good
enough.
Hi
Looks like FreeBSD one of the few modern OS which have the maximum
length of username less than 255.
Windows: http://technet.microsoft.com/en-us/library/cc783323.aspx (255)
Linux: getconf LOGIN_NAME_MAX = 256
MacOSX: getconf LOGIN_NAME_MAX = 255
FreeBSD: getconf LOGIN_NAME_MAX = 17
Any plan
49 matches
Mail list logo
