Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Daniel Robbins
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 depend on them".

Here is a bit more info:

Runlevel-specific conf.d files:

http://www.funtoo.org/wiki/Funtoo_Linux_Networking#Alternate_Configs

Stacked runlevels (this is a more sophisticated feature than just
creating a duplicate, separately-managed runlevel):

http://www.funtoo.org/wiki/Stacked_Runlevels

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

You could then switch by typing:

# rc maintenance

Anything not in the maintenance runlevel that is currently running
would be stopped, and any new services in maintenance that are not
running would be started.

Regards,

Daniel
___
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"


Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Daniel Robbins
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 could conveniently start and stop
> together?

Yes, this is what OpenRC offers. You can even have one runlevel be a
child of another runlevel. All runlevels have logical names. By
default, the system boots into "default". These are mapped to
old-school 1 2 3 4 5 runlevels under linux since we are still using
sysvinit, 3 maps to "default". But you can change after boot:

# rc maintenance
# rc online

etc.

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.

> But there is no possibility of separating base system /etc and ports
> /usr/local/etc?
> The separation between the two is something I'd not want to loose.

I don't think it would be a very huge leap at all to map in both
system and ports scripts. It would likely be a relatively
straightforward patch if it is not already supported.

Regards,

Daniel
___
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"


Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Daniel Robbins
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 want mess.
> And for sure not only me.
>
> - once again - the less files, the better.
>
> 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
> scripts, i deleted most of it and put startup sequence in single file.
>
> It was plain horror.

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.

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".

> yes i am. but that joke is clear suggestion that we have already tens of
> thousands better or worse made ports!

Well, if ports maintenance is the much bigger problem we can also look
at coordinating efforts there in the future.

> if you have idea how to improve existing rc.d AND make ports working as is
> then go on.

I think that if FreeBSD used OpenRC (maybe initially with a
compatibility layer for existing initscripts) then it would make it
easier for us all to transition to a  compatible ports format, since
we could use the same ports initscripts. Then, an nginx port could
contain an initscript that could work on both FreeBSD and
Gentoo/Funtoo Linux. This could definitely open up the possibility of
collaborating more easily in the future on ports maintenance.

But collaborating on ports is such a big topic, and initscript
compatibility is a relatively minor issue in the grand scheme of
things.

Is the maintenance of ports a huge issue for FreeBSD, and would you be
interested in looking into working with Gentoo and Funtoo on sharing
build scripts?

> For me it is OK.

You know, I often wonder why so much effort in the Linux world is
spent on the first few seconds of a system's uptime. So I definitely
understand and appreciate that you are not ready to make reckless
changes to your boot process.

>From my perspective, the upstart/launchd/systemd/udev mess in Linux is
ugly, and we are promoting OpenRC as a sane alternative. So it helps
us to have other distributions and operating systems using it. Because
for Gentoo and Funtoo, OpenRC *is* our standard design, and we want to
promote something more "normal" than the other stuff coming from
Linux. It helps us to fight that battle when we have a broader base of
users.

I think that is one of the motivations of reaching out to FreeBSD --
the Gentoo and Funtoo user-base is more aligned with the sensibilities
of FreeBSD than the other Linux distros moving to upstart/launchd,
etc.

I think that may be a major benefit of FreeBSD using OpenRC -- that
you will be treated as a respected and listened-to member of the
OpenRC community. I don't know if you have been following some of the
politics in Linux recently, but a lot of this service management stuff
has been almost shoved down our throats with the justification that
it's necessary for Linux dominating the desktop. (!)

Best Regards,

Daniel
___
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"


Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Daniel Robbins
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't take too much time to
investigate.

> 2) is the problem 1 worth of slight improvement over already good, but
> certainly not perfect rc.d subsystem.

Yes, clearly OpenRC will need to offer significant improvements to
make it worthwhile to justify migrating over to it.

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."

> If someone would like to make new ports subsystem from scratch then it would
> be great. Would you like to ? ;)

I know you are joking, but in all seriousness, this is another area of
potential collaboration, because at some point I will be looking to
significantly improve Portage. And Gentoo and Funtoo have the same
challenging of upgrading ports systems -- there's so much stuff that
already uses our *existing* ports system that needs to be moved over.
There are creative solutions to this problem that I have found. So
it's a good idea to stay in touch :)

> when i would have million dollars handy call me and find these 20 people ;)

I have some ideas that should make it possible to transition ports
systems with less effort than this. But this isn't related to the
current thread :)

Best Regards,

Daniel
___
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"


Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Daniel Robbins
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."
>
> rc subsystem is fine. Changing it would be another mess.

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 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)

There has been some suggestion of a boot-time shoot-out, and it makes
perfect sense to me that the OpenRC team would need to demonstrate the
benefits of OpenRC first, before FreeBSD devs devote time to looking
at OpenRC.

But if boot time isn't a huge priority, then maybe it is the wrong
place to focus. I think the big benefit of OpenRC to FreeBSD is that
we are looking to continually improve it and include you in the
requirements-gathering process for future development efforts. This
means that we are able and willing to incorporate functionality that
has been on your wish-list for some time, alleviating the burden of
you having to do this work. Gentoo and Funtoo would also be able to
benefit from any improvements that are made to OpenRC, so it is likely
that you would see support from other OpenRC-using distros.

So in this spirit, I would be interested in shifting the conversation
to an effort to gather a list of semi-formal functional and
non-functional requirements for a future FreeBSD initscript system.
This would give the OpenRC team insight into what features would make
OpenRC desireable to you and a serious candidate for inclusion in
FreeBSD at some point in the future.

Solaris SMF has already been mentioned. I would like to get a better
understanding of your needs in this area. In 1999, Gentoo 0.99 was
originally using supervise to ensure service availability (but was
removed due to licensing quirks,) and we never quite got around to
adding this functionality back in, so I would be interested in having
similar functionality integrated into OpenRC as well.

If there are any other things you would like to see in a future
FreeBSD initscript system, please let us know.

Note that I contribute to OpenRC but do not run the project. But I
have a personal attachment to the system since it was originally my
baby :) And of course I am willing to help where I can.

Best Regards,

Daniel Robbins
___
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"