rc.d
David Brownlee
> > * Monolithic /etc/rc is gone, it won't be back. Deal.
>
> Ain't gone noplace on my systems. Never will, not as long as I'm
> running anything UNIXish.
>
I believe there are more people who want the finer granularity of
individual startup and shutdown systems than those who want
the ease (for them) of maintenance of a single script.
Luke's work has an option to spit out a single large rc script,
which indicates the latter set has not been forgotten. I agree
Frank could have phrased it less bluntly.
> > * As I've said before, please don't start about the "BSD way"
> > of doing things.
>
> Why not? *You* don't care about it, so those who do have to shut up?
>
On that path lies Michael Sokolov's Quasijarus
http://minnie.cs.adfa.edu.au/Quasijarus/
Seriously - rc.conf, posix compatibility, scsipi, bus_space,
pcmcia/usb with the ability to detach devices, IPv6, 64bit support
and a bunch more are all items that were not 'original BSD', but
they are aspects that make NetBSD a better system.
rc.conf is no more 'the BSD way', than splitting up rc into
individual subsystem controlling files, but they both intended
to ease administration.
> Indeed, it may be the SysV shard that finally drives me away from
> Net"BSD". I don't know yet.
>
I see a distinct lack of directories full of S93bob and K23alfred
in this new scheme (though I understand they could be generated
as an option). So it is no more SysV than it is 'traditional' BSD.
Instead it hopes to be a better system that has learned from both.
> You mean like how the Project just screwed over everyone who dares to
> run a system in any way other than "run sysinst, run pkg_add"? Or is
> that not an issue for you, just for the admins in question?
>
In what way - are you no longer able to control your systems with
rc.conf and add your magic to rc.local?
If you run the script that converts evrything into one large
rc file and leave it that way, how has it screwed you?
> Yes, I'm angry. Angry, disappointed, sad, abandoned. I was foolish
> enough to let myself think that NetBSD actually cared about the last
> three letters of its name. This led me to invest a lot of dedication
> and caring in it, because I care about BSD...and now the Project has
> taken another step, and a very big one, away from it. I can't really
> expect the Project to care about one lone gadfly's opinion, but that
> doesn't make it any easier to take its suddenly turning around and
> telling me "screw you".
I'm sorry you feel like that. From one perspective BSD 'died' when
the CSRG closed up shop. Frrom another its grown into something
better, in places of which the original could never have thought
(mips handhelds IPv6 with IPSEC mounting NFS wireless), and still
plays a good /usr/games/rogue...
The new rc system is not perfect. To my mind it seems to be a good
solution with some issues that need to be resolved, such as:
a) Package rc scripts. Should either be enabled
automatically, or require manual rc.conf x=YES. Since
both are wanted we should probably have a per machine
switch.
b) Those who just want one rc file
Maybe we can get away with a command that converts a
system back to this for the supplied scripts. Maybe
not - we need to know.
c) Too much Magick
I think we should ship with an /etc/rc.README file
that gives a good enough overview for a knowledgeable
{NetBSD-1.4,SysV} sysadmin to add or disable a startup
script. Again, maybe this will be enough
d) Everything else
There are bound to be others. People should speak up
and enumerate them.
David/absolute
Wolfgang Rupprecht
I can't believe that I am the only person here that keeps a half-dozen
systems in sync with rdist. Right now I have a few symlinks in /etc
for files that absolutely need to be different. These symlinks are
the only thing not rdisted. The rest of the per-machine
individualization is limited to a few hosname-based if's stuck into
the /etc/rc{,local} files.
if [ $(hostname) = foo ] then
...
fi
I'm not exactly sure what the right thing is for an /etc/rc.d world.
Do I really have to maintain 6 copies of /etc/rc.d ??? Yuk.
-wolfgang
--
Wolfgang Rupprecht <wolfga...@dailyplanet.wsrcc.com>
http://www.wsrcc.com/wolfgang/
DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
der Mouse
> individual startup and shutdown systems than those who want the ease
> (for them) of maintenance of a single script.
There are even more people yet who want Windows. Shall we therefore
start shipping Windows?
That sounds flippant, and I suppose to an extent it is, but there's a
serious point behind it. NetBSD has been very well suited to a niche
"market", the individual OS-hacker type for whom "untar tarballs, edit
/etc/*" is all the install instructions necessary.
Recently (= approximately this past year), it seems, someone has
decided that a larger user base is a sufficiently good thing to be
worth dropping the niche people for, and this has resulted in things
like the package system and /etc/rc.d, things designed to make life
easy for the "I don't know computers and don't want to have to" crowd,
the people whose idea of complicated system administration is having to
actually type pkg_add at a shell prompt instead of clicking in a GUI.
Yes, there are hell of a lot more of them than there are of the
hardcore hacker types.
But they're already very well served by Windows, Linux, etc. Perhaps
FreeBSD as well; they seem to have gone farther towards catering
towards that crowd than we have, from what little I know of them.
I don't want to see NetBSD trying to compete with Linux and Windows on
their own ground, both because I believe it will lose and because it
will mean that NetBSD will then no longer suit the niche I am part of.
Yet that seems to be where it's headed.
>>> * As I've said before, please don't start about the "BSD way"
>>> of doing things.
>> Why not? *You* don't care about it, so those who do have to shut
>> up?
> On that path lies Michael Sokolov's Quasijarus
> Seriously - rc.conf, posix compatibility, scsipi, bus_space,
> pcmcia/usb with the ability to detach devices, IPv6, 64bit
> support and a bunch more are all items that were not 'original
> BSD', but they are aspects that make NetBSD a better system.
"BSD way" != "only what came out of CSRG", at least to me. It's a very
fuzzy sort of thing; that's why I haven't been able to provide a clear,
coherent, logical statement of what I dislike about the departures from
it.
> rc.conf is no more 'the BSD way', than splitting up rc into
> individual subsystem controlling files, but they both intended
> to ease administration.
And they do...for some people. The trouble is, *which* people?
>> Indeed, it may be the SysV shard that finally drives me away from
>> Net"BSD". I don't know yet.
> I see a distinct lack of directories full of S93bob and K23alfred in
> this new scheme (though I understand they could be generated as an
> option). So it is no more SysV than it is 'traditional' BSD.
Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec". The
rc.d scheme, as I understand it, has the same basic problems that real
SysV startup scripts do: they make human understanding and manipulation
of the startup sequence significantly harder, for the sake of making
mechanical ditto easier.
>> You mean like how the Project just screwed over everyone who dares
>> to run a system in any way other than "run sysinst, run pkg_add"?
> In what way - are you no longer able to control your systems with
> rc.conf and add your magic to rc.local?
Will there *be* rc.conf and rc.local? I saw "rc.conf must die" and
discussion of /etc/rc.d.local/ vs /etc/rc.local.d/, which means either
there won't be any rc.conf and rc.local, or the new scheme is being
grossly misrepresented.
> If you run the script that converts evrything into one large rc file
> and leave it that way, how has it screwed you?
Quite possibly it hasn't. Frank said monolithic rc was gone and
wouldn't be back; I jumped to the (not unreasonable, I think)
conclusion that it was so. Now it appears it might not be. I'll
probably set up a crash-&-burn machine and try bringing it up to
-current sometime soon, see how alien the new system feels when I do
ask it for a single startup script.
der Mouse
mo...@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Jaromir Dolecek
> worth dropping the niche people for, and this has resulted in things
> like the package system and /etc/rc.d, things designed to make life
Don't touch the package system, please. There was period in time
when I enjoyed getting all the software I need to use to compilable
state on NetBSD. That period is over and I'm happy I can just
pick up the software I want and install it via simple
make in pkgsrc.
Package system is great thing. It saves my time enormously and I can enjoy
doing my staff instead of fighting with software to build
and install on some sane place.
> But they're already very well served by Windows, Linux, etc. Perhaps
> FreeBSD as well; they seem to have gone farther towards catering
> towards that crowd than we have, from what little I know of them.
They have done also quite a lot of cool staff.
> I don't want to see NetBSD trying to compete with Linux and Windows on
> their own ground, both because I believe it will lose and because it
> will mean that NetBSD will then no longer suit the niche I am part of.
> Yet that seems to be where it's headed.
Well, I don't thing thing that popularity is necesarily bad thing.
More users means more resources to solve problems, too. People
tend to not spend time on things, which they consider as "dead",
even when it's good.
> Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec". The
> rc.d scheme, as I understand it, has the same basic problems that real
> SysV startup scripts do: they make human understanding and manipulation
> of the startup sequence significantly harder, for the sake of making
> mechanical ditto easier.
I always though the problem with SysV-type startup script was the
runlevel shit and no clear dependencies, no clear way when exactly
is what called (i.e. what kill/start scripts to call when changing
runlevels). Figuring out what services need to run before given
service can be started is non-trivial in SysV.
Those problems are just not present in what we have now.
Nice things about the scripts in /etc/rc.d is that dealing
with individual daemons/services is much more easier.
They do all the work you would have to do
(e.g. ps ax | grep myproc; kill it; start with appropriate
flags), plus they manage dependencies.
It provides you with much more flexible way to define
what depends on what, way to define subsytems so that
when you kill a service, all services depending on it
are killed, too. Or if you start a service which
needs other services to run, they are also started.
Very nice.
Jaromir
--
Jaromir Dolecek <jdol...@NetBSD.org> http://www.ics.muni.cz/~dolecek/
@@@@ Wanna a real operating system ? Go and get NetBSD, damn! @@@@
der Mouse
> Don't touch the package system, please.
I don't argue for touching it. Unlike the rc changes, the package
system is a case where people who don't like it can just ignore it and
it won't cause them any grief. The only price for me is a half-dozen
executables I never use...and if that bothered me, I'd be yammering
about a bunch of other stuff too, like bind, uucp, sendmail, MIDI and
USB goop, etc.
The only danger I saw in the package system was that it would lead to
exchanges like
User: I'm trying to build Foo V3.8 and I'm having such-and-such
a problem....
NetBSD person: Why aren't you using the Foo package?
(as opposed to actually addressing the problem, which simply happens to
be tickled by Foo V3.8). Fortunately this doesn't seem to have
materialized.
>> I don't want to see NetBSD trying to compete with Linux and Windows
>> on their own ground, both because I believe it will lose and because
>> it will mean that NetBSD will then no longer suit the niche I am
>> part of. Yet that seems to be where it's headed.
> Well, I don't thing thing that popularity is necesarily bad thing.
Me neither. Additional user base *per se* is not something I mind.
But when that additional user base is seen as a good enough thing in
its own right that it's worth breaking things for the niche people,
well, as one of that niche, I feel..abandoned.
>> Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec".
>> The rc.d scheme, as I understand it, has the same basic problems
>> that real SysV startup scripts do: they make human understanding and
>> manipulation of the startup sequence significantly harder, for the
>> sake of making mechanical ditto easier.
> I always though the problem with SysV-type startup script was the
> runlevel shit and no clear dependencies,
That's another problem with SysV startup.
> no clear way when exactly is what called (i.e. what kill/start
> scripts to call when changing runlevels). Figuring out what services
> need to run before given service can be started is non-trivial in
> SysV.
> Those problems are just not present in what we have now.
True. But just because one of two big problems with SysV startup was
not introduced, that's no reason to overlook the one that was.
> Nice things about the scripts in /etc/rc.d is that dealing with
> individual daemons/services is much more easier. They do all the
> work you would have to do (e.g. ps ax | grep myproc; kill it; start
> with appropriate flags), plus they manage dependencies.
They..may try. They will get it wrong too often.
ps ax | grep myproc is *not* suitable for automated use. When human
intelligence is applied to the output before it's fed into kill, it's
fine. Without that, it's an invitation to disaster. (Which of those
pppd processes is the one I want to kill? Or both? And what about my
watch-pppd script, why did it kill that?)
> It provides you with much more flexible way to define what depends on
> what, way to define subsytems so that when you kill a service, all
> services depending on it are killed, too.
...assuming that's what I want, rather than to kill it, move the new
config into place, and bring it back up, letting the dependent services
retry a time or two rather than restrting them too.
And if shutting down Foo shuts down everything currently running which
depends on Foo, where does it record what those are so that when I
restart Foo a moment later they're brought back up?
> Or if you start a service which needs other services to run, they are
> also started. Very nice.
...for turnkey production systems.
A disaster when, say, I'm trying to run an experimental replacement for
one of those services and the start script notices the stock one isn't
running and tries to start it, not able to tell that my replacement is
running instead.
Remember what I said about the OS-hacker niche? Guess what perspective
this message is being written from. :-)
Greg A. Woods
> Subject: Re: rc.d
>
> On Wed, Mar 15, 2000 at 08:00:03AM +0100, Bernd Ernesti wrote:
>
> > > Dropping in scripts currently does mean editing rc.conf, which
> >
> > You never need to edit rc.conf. /etc/rc.local.conf is enough.
>
> You don't seem to get it... editing ANY file is a Lose.
I'm not sure exactly what you mean there. Making changes to the content
of a file means that those changes can be very easily tracked using
existing simple tools, such as RCS.
Hopefully you didn't mean the obvious alternative that comes to my mind,
which is to move files around, create links, and so on (which is the
*only* problem I've ever had with the SysV /etc/init.d scheme :-). Such
things are a lot harder to track because doing so requires adding
another layer above which allows the changes to be recorded within the
body of one or more files.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Greg A. Woods
> Subject: Re: rc.d
>
> A disaster when, say, I'm trying to run an experimental replacement for
> one of those services and the start script notices the stock one isn't
> running and tries to start it, not able to tell that my replacement is
> running instead.
>
> Remember what I said about the OS-hacker niche? Guess what perspective
> this message is being written from. :-)
I think you're over-reacting -- a lot. Just because scripts exist to
manage the startup and shutdown of daemons doesn't mean you have to use
them.
Your example of wanting to start a new test process that works in
concert with a number of other dependent processes is certainly not a
scenario where I would use the rc.d script (unless of course the entire
subsystem did have to be shut down and restarted to effect some
initialisation required). Just kill the damn process and start your new
one!
Where such problems would require different solutions is if the program
was running under a SysV-style "init" or SAC monitor. Obviously in such
a scenario you'd probably want to either shuffle around some binaries or
edit the monitor config file before manually killing the desired process
and thus allowing the monitor system to restart the appropriate test
program.
Note that inetd isn't much different than a SysV init in this respect....
David Brownlee
> > Nice things about the scripts in /etc/rc.d is that dealing with
> > individual daemons/services is much more easier. They do all the
> > work you would have to do (e.g. ps ax | grep myproc; kill it; start
> > with appropriate flags), plus they manage dependencies.
>
> They..may try. They will get it wrong too often.
>
> ps ax | grep myproc is *not* suitable for automated use. When human
> intelligence is applied to the output before it's fed into kill, it's
> fine. Without that, it's an invitation to disaster. (Which of those
> pppd processes is the one I want to kill? Or both? And what about my
> watch-pppd script, why did it kill that?)
>
I agree here - it should only target processes whos final
pathname component exactly matches the specified string.
(that avoids the watch-pppd issue). I haven't checked that is
does (offline right now).
As for which pppd it kills - all of them as it is shutting down
pppd as the system is going down. If that is not what you want,
then you do not manually run '/etc/rc.d/pppd stop'.
> > It provides you with much more flexible way to define what depends on
> > what, way to define subsytems so that when you kill a service, all
> > services depending on it are killed, too.
>
> ...assuming that's what I want, rather than to kill it, move the new
> config into place, and bring it back up, letting the dependent services
> retry a time or two rather than restrting them too.
>
> And if shutting down Foo shuts down everything currently running which
> depends on Foo, where does it record what those are so that when I
> restart Foo a moment later they're brought back up?
>
If the ordering is not what you want in the case of a system not
shutting down, you do not manually run the 'xxx stop' script.
If you just want traditional 'init kills the world, shutdown
behaviour, you ensure rc.shutdown does not call the stop scripts.
> > Or if you start a service which needs other services to run, they are
> > also started. Very nice.
>
> ...for turnkey production systems.
>
> A disaster when, say, I'm trying to run an experimental replacement for
> one of those services and the start script notices the stock one isn't
> running and tries to start it, not able to tell that my replacement is
> running instead.
>
The start script is only going to be run when you bring the system
up, or when _you_ manually decide to run it. In the former case you
need to tweak the script, but you would have needed to do that with
a monlithic rc script anyway?
> Remember what I said about the OS-hacker niche? Guess what perspective
> this message is being written from. :-)
There are three areas of behaviour I see affected:
(Note I'm not addressing configuration at this point, to
try to simplify this section :)
a) Manual start/stop of individual services:
This is what some of us really like. If you know what
it does, and are happy with the action, you use it. If
not, you don't.
b) Shutdown:
Currently init just kills things. Giving subsystems the
option to cleanup in their own way (database shutdown)
and shutting things down _in the right order_ seems like
a very good thing. Particularly if the rc system can
run them in parallel to speed things up. If someone is
really adverse to this, they can throw some comments in
rc.shutdown.
I do not see the above two as issues (please correct me if
I'm wrong :)
c) Startup
If you wanted something run at a particular point, you
added it to the appropriate place in rc.local (or
netstart.local, or rc, or netstart). In the new world
order you would add a comment to the top of a script if
it needs to happen after something else and drop it in
the rc.d directory. If you want to take advantage of
all the rc.subr help you can, but you do not have to.
--or-- you convert the entire rc.d into an old style
rc, and tweak to taste. I agree, not as convenient for
you as the old system, but it allows a lot of us to
get some of the new features we want.
I can understand this would be less than ideal for some people,
but we're looking for a solution that fits two conflicting goals.
- monolithic rc, vs individual start/stop scripts.
On Wed, 15 Mar 2000, der Mouse wrote:
> Recently (= approximately this past year), it seems, someone has
> decided that a larger user base is a sufficiently good thing to be
> worth dropping the niche people for, and this has resulted in things
> like the package system and /etc/rc.d, things designed to make life
> easy for the "I don't know computers and don't want to have to" crowd,
> the people whose idea of complicated system administration is having to
> actually type pkg_add at a shell prompt instead of clicking in a GUI.
I'm no guru, but I know my sysadmin-way around NetBSD pretty well,
and am reasonably familiar with the SysV startup mush on IRIX and
Solaris (exceeded by the nightmare which is redhat rc.d)
"I know computers, and I'm very happy doing so, I just want
the computer to be able to do more repetitive things, so
I can get on with other work".
On my NetBSD systems I install skill. I have no difficulty
in finding paths and process IDs without it, but I'd rather
spend my cycles fixing a problem, than mechanically typing
extra mush, particularly over a sluggish link
If I had and /etc/rc.d/sendmail, I'd use it when it would
prove useful to me.
> Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec". The
> rc.d scheme, as I understand it, has the same basic problems that real
> SysV startup scripts do: they make human understanding and manipulation
> of the startup sequence significantly harder, for the sake of making
> mechanical ditto easier.
>
It makes individual process startup easier to understand
(they all happen the same way), and the dependencies between
them explicit (rather than just a sequential list, which while
easier to understand, implies a while bunch of dependencies
that are just not needed).
That ordering could be made easir to see by having an
'rcorder -v' which would list the order and dependencies in
a clear 'for human consumption' fashion.
> Will there *be* rc.conf and rc.local? I saw "rc.conf must die" and
> discussion of /etc/rc.d.local/ vs /etc/rc.local.d/, which means either
> there won't be any rc.conf and rc.local, or the new scheme is being
> grossly misrepresented.
>
I would also be unhappy if rc.conf or the option to have
an rc.local was taken away. I should really check but the
only spare time I have right now is sitting on a train, and
my rather aged laptop is out of disk right now :(
> > If you run the script that converts evrything into one large rc file
> > and leave it that way, how has it screwed you?
>
> Quite possibly it hasn't. Frank said monolithic rc was gone and
> wouldn't be back; I jumped to the (not unreasonable, I think)
> conclusion that it was so. Now it appears it might not be. I'll
> probably set up a crash-&-burn machine and try bringing it up to
> -current sometime soon, see how alien the new system feels when I do
> ask it for a single startup script.
It has to be somewhat alien, but maybe with some changes to the
way things are generated we can find something that will satisfy
(if not please) everyone...
David/absolute
Greywolf
# Recently (= approximately this past year), it seems, someone has
# decided that a larger user base is a sufficiently good thing to be
# worth dropping the niche people for, and this has resulted in things
# like the package system and /etc/rc.d, things designed to make life
# easy for the "I don't know computers and don't want to have to" crowd,
# the people whose idea of complicated system administration is having to
# actually type pkg_add at a shell prompt instead of clicking in a GUI.
You know, actually, I consider myself to be something of an OS hacker/
hardcore admin type. (You should know this -- I sent you my version
of an interactive archiver, inefficient as it was!)
But I *like* the pkg system. It saves me *time*. Yes, I know how to
configure things, and yes I know how to just do format/boot/untar/
"edit /etc/*". In most cases it's faster.
But after my system is skrogged to the point that all I can do is nod,
smile, wave and upgrade, the ability to use the pkg system to restore my
system to a stable state (for prog in $list; do (cd $prog; make && make
install); done) and then just walk away from it to come back after
work, well, that's just cool.
I'm not entirely sure of the rc.d business, just yet, actually.
If it looks too much like sysV or Linux, well, yes, I'm going to
be somewhat bitter about it.
On the other hand, as much as I am used to the thought of 'ps, kill,
/sbin/whatever -opts args', and I still do that, I have written more
than one instantiation of a script which could be used to stop/start
individual processes. namedc doesn't always cut it, for example.
If the scripts are there, that actually can make life a bit easier
(I have to rewrite it now because the one copy I had was zorched when
I had to reinstall...)
I'm one of those OS/admin types who is actually looking forward
to the system getting pkgized. If I had the time, I'd blow it out
that way myself.
#
# Yes, there are hell of a lot more of them than there are of the
# hardcore hacker types.
#
# But they're already very well served by Windows, Linux, etc. Perhaps
# FreeBSD as well; they seem to have gone farther towards catering
# towards that crowd than we have, from what little I know of them.
But NetBSD will run on more platforms IN SYNC than will Windows, Linux,
FreeBSD.
# I don't want to see NetBSD trying to compete with Linux and Windows on
# their own ground, both because I believe it will lose and because it
# will mean that NetBSD will then no longer suit the niche I am part of.
# Yet that seems to be where it's headed.
Don't count it out yet -- if there's options to be had, the niche will
probably invent them (/usr/src/pkg/niche?).
# > rc.conf is no more 'the BSD way', than splitting up rc into
# > individual subsystem controlling files, but they both intended
# > to ease administration.
#
# And they do...for some people. The trouble is, *which* people?
For people who _don't_ have that much time on their hands, for example.
I think I'm getting this. I don't think it's an intentional slight toward
the hackers as much as it's making it easier to start the system up.
In defense, though: rc.conf strikes me as more of what _would have been_
the BSD approach.
# Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec". The
# rc.d scheme, as I understand it, has the same basic problems that real
# SysV startup scripts do: they make human understanding and manipulation
# of the startup sequence significantly harder, for the sake of making
# mechanical ditto easier.
Uh, not all that much, come to think of it, save that the init levels
(please don't tell me we're going _there_!) really take one through
some twisty passages, depending on how init is set up to run (i.e.
level 2 runs level 2 and then level 3 on some machines; on others
it runs levels S, 2 and 3, and on yet others it just runs level 3).
But on a single level, it's not that hard to follow...
--*greywolf;
--
BSD, stupid.
der Mouse
> You know, actually, I consider myself to be something of an OS
> hacker/ hardcore admin type.
> But I *like* the pkg system.
I have nothing against the package system, except possibly that it's
draining off developer cycles that could go to IMO-better uses - though
developer cycles are not a fungible commodity, doubly so for a
volunteer project.
You see, the package system has the property that if you don't like it,
you can ignore it and it will never bother you.
/etc/rc.d doesn't.
> But after my system is skrogged to the point that all I can do is
> nod, smile, wave and upgrade, the ability to use the pkg system to
> restore my system to a stable state (for prog in $list; do (cd $prog;
> make && make install); done) and then just walk away from it to come
> back after work, well, that's just cool.
Yes. Having something of the sort is valuable. I have something of
the sort, developed independently of the package system. I have no
problems with packages; the one fear I had about them has, so far,
proven unfounded.
> I'm not entirely sure of the rc.d business, just yet, actually. If
> it looks too much like sysV or Linux, well, yes, I'm going to be
> somewhat bitter about it.
I'm not especially bitter about what was done, not yet (I haven't
"upgraded" to an rc.d OS, yet). I'm much more concerned about how it
was done.
The subject of split-up startup scripts has been brought up on the
lists multiple times. Every time, it produces many opinions, widely
disparate and strongly held.
Yet this time, rather than taking from that the lesson that has been
taken the other times - that no such scheme has enough consensus behind
it to succeed - someone decided to go ahead and ram it down everyone's
throat regardless.
*That* is what *really* bothers me: the Project telling me (and others
who, like me, don't like the new way) "we know better than you do
what's a step forward; here's what you're going to use". This, much
more than the mere fact of having split-up boot scripts, is what I've
been referring to when I've written of my feelings that the Project has
just decided to give me and my needs the finger.
> On the other hand [...], I have written more than one instantiation
> of a script which could be used to stop/start individual processes.
I've written such support myself, on occasion.
I use it when I judge it is appropriate, and don't when I don't.
NetBSD is no longer giving me that choice. If I want anything but this
brave new startup system, I have to roll it completely alone.
Worse, this slap in the face leaves me with far less certainty that I
will like - or even be able to tolerate - any *other* change the
Project may decide to impose on its OS's users without discussion, or
(as in this case) in the face of much dissension.
> For people who _don't_ have that much time on their hands, for
> example. I think I'm getting this. I don't think it's an
> intentional slight toward the hackers as much as it's making it
> easier to start the system up.
Starting up a stock system has never been the least bit difficult.
And this does make it easier to mechanically add stuff to the startup
sequence.
The price that it exacts is that it is now significantly harder to do
anything outside of the "what the vendor provides" box. If I didn't
mind being restricted to what some vendor thinks I need, I'd be running
a commercial vendor OS - and getting full support for all my hardware,
instead of having to hack on drivers myself.
*That* is the sense in which it is a slight towards the hacker types,
the sense in which I feel the Project is kicking sand in my face.
Greywolf
# You see, the package system has the property that if you don't like it,
# you can ignore it and it will never bother you.
#
# /etc/rc.d doesn't.
Ah. I see your point.
# I'm not especially bitter about what was done, not yet (I haven't
# "upgraded" to an rc.d OS, yet). I'm much more concerned about how it
# was done.
AAHHH! I see your _other_ point.
#
# The subject of split-up startup scripts has been brought up on the
# lists multiple times. Every time, it produces many opinions, widely
# disparate and strongly held.
#
# Yet this time, rather than taking from that the lesson that has been
# taken the other times - that no such scheme has enough consensus behind
# it to succeed - someone decided to go ahead and ram it down everyone's
# throat regardless.
#
# *That* is what *really* bothers me: the Project telling me (and others
# who, like me, don't like the new way) "we know better than you do
# what's a step forward; here's what you're going to use". This, much
# more than the mere fact of having split-up boot scripts, is what I've
# been referring to when I've written of my feelings that the Project has
# just decided to give me and my needs the finger.
I agree with this, wholeheartedly. just couldn't put my...um...pencil
on the problem.
I will second the opinion that this was done without a consensus,
and that was *really* rude, guys. And then to take the attitude of
"well, tough, deal". Fine. And the horse you rode in on.
# Starting up a stock system has never been the least bit difficult.
Yes, but you take my point (I hope).
# And this does make it easier to mechanically add stuff to the startup
# sequence.
#
# The price that it exacts is that it is now significantly harder to do
# anything outside of the "what the vendor provides" box. If I didn't
# mind being restricted to what some vendor thinks I need, I'd be running
# a commercial vendor OS - and getting full support for all my hardware,
# instead of having to hack on drivers myself.
Again: I don't have an issue with rc.d outside of the system.
But I -do- take issue with my stock system being done like that.
# *That* is the sense in which it is a slight towards the hacker types,
# the sense in which I feel the Project is kicking sand in my face.
#
--*greywolf;
--
BSD: What were we thinking?
Greg A. Woods
> Subject: Re: rc.d
>
> The price that it exacts is that it is now significantly harder to do
That's just plain not true.
Greywolf
# [ On Thursday, March 16, 2000 at 11:00:22 (-0800), Greywolf wrote: ]
# > Subject: Re: rc.d
# >
# > But I *like* the pkg system. It saves me *time*. Yes, I know how to
# > configure things, and yes I know how to just do format/boot/untar/
# > "edit /etc/*". In most cases it's faster.
#
# While saving time is good, the real benefit of the pkg is that it's good
# housekeeping and much closer to proper systems configuration management
# (which of course ultimately saves even more time, long run).
Greg, you're up WAY too late again. :-)
The benefits I see to pkg*:
- registration of packages and their dependencies
- saves time when rebuilding binaries to match current kernel/
lib setup (especially nice when a.out -> elf happened (SPARC,
IA32).
The benefits I see to /etc/rc.d:
The benefits I see to /etc/rc.d with a naming convention a la SysV
[all that [KS][0-9]+ crap]:
What we're trying to achieve could be done, I bet, with a different
approach which would preserve our current rc while allowing the
starting/stopping of individual services.
I came up with something that jumped through quite a few hoops in
order to do things correctly. Yes, its first move was to source
/etc/rc.conf. Yes, it depended heavily on what it found in /var/run.
I probably could have made it depend upon what it found in ps, to
a degree.
One thing I could see doing was to echo the command to be run to
/var/run/${command}.cmd, thus resulting in a (.pid, .cmd) pair. If one
wished to restart, one would kill the pid and then run the command found in
the .cmd file. A 'stop' would kill the pid and delete the .cmd file.
A 'start' would, through some magic, arrive at the right command
and args and run it.
This could be made to work. One could even inject stuff into /etc/rc,
although my method for doing that is admittedly considered fragile by
a few people, but not off by much in comparison to /etc/rc.d/some-funky-
script-name-with-lame-ascii-ordering.
There's gotta be a better way. Shoehorning it in amid much dissent in
an incomplete discussion was a very rude thing to do.
# --
# Greg A. Woods
#
# +1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
# Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
#
--*greywolf;
--
NetBSD, Net Improvement.
Lucio De Re
>
> Recently (= approximately this past year), it seems, someone has
> decided that a larger user base is a sufficiently good thing to be
> worth dropping the niche people for, and this has resulted in things
>
system actually operates, I was convinced it was a bad idea.
And the crunch here is that the new RC stuff is not of the same caliber
as the PKG stuff (perhaps? this is not meant to shaft Luke), and more
sensibly, perhaps we should package Luke's stuff instead of providing it
as the default. That would certainly appeal to me, I am not speaking for
other die-hards.
++L
Robert Elz
From: der Mouse <mo...@Rodents.Montreal.QC.CA>
Message-ID: <2000031701...@Twig.Rodents.Montreal.QC.CA>
| You see, the package system has the property that if you don't like it,
| you can ignore it and it will never bother you.
|
| /etc/rc.d doesn't.
This isn't really true, the two are pretty similar. In each case either
you just use what is provided, and don't bother about it too much, or you
have to maintain your own alternatives (there aren't many NetBSD systems
around that will be running only a base installed system with nothing added
on at all - though such a system could just possibly totally ignore the
pkg system and do nothing of its own).
A major difference between this system, and Sys V, is that /etc/rc is
maintained, and init still runs /etc/rc when the system boots, and that
controls everything thereafter (as opposed to the mess that is inittab).
If you want a monolith /etc/rc you can do that, and you get to maintain it
for yourself, including upgrading it as necessary, etc. That's just the
same as if you want your own ssh or bash or emacs, ignoring the pkg versions
of those. You get to do things in your own way, no real constraints, but
you have to keep on doing that every time you do a system upgrade (unless
you eventually decide it is too much work, and just allow the people building
the systems to do it their way).
You get a clear choice here - either you do things the system way, or you
do things your own way. The choice that you don't get is to force the
system way to be your way, just because you perfer it, and your life is
easier.
| Yet this time, rather than taking from that the lesson that has been
| taken the other times - that no such scheme has enough consensus behind
| it to succeed - someone decided to go ahead and ram it down everyone's
| throat regardless.
I thought you were complaining about this all not being the BSD way?
What you wrote there was *exactly* the BSD way - find something that looks
to be better (in the opinion of the small group deciding such things),
implement it, and ship it. That happened over and over again. How much
discussion do you think there was of the (then) new getty (along with
gettycrap)? That one I did, shipped it to Sam Leffler, he fixed a few
bugs, and a couple of weeks later 4.2BSD was being shipped with a totally
different getty than had been there before (including in the beta releases)
(and which amazingly still seems to be the basis of the BSD systems getty
to this day). But it was exactly as you described it, I thought it was an
improvement, so it was implemented, and then shoved down everyone's throats,
regardless.
How many people do you think it was who decided that the autoconfig code
should get done, and included?
In hindsight now both of those might seem like obvious improvements, but
they were certainly both changes, and (in their different scopes) quite
major ones, and at the time, people who were used to what had been there
before, and found that adequate for their purposes, didn't all like
the changes and would have preferred that they hadn't been made.
If you want a system than responds to market pressures, attempts to
do everything in a way that will suit everyone, and will take a lot of
notice of whether people decide not to run it any more or not, then
Sys V is what you want.
| The price that it exacts is that it is now significantly harder to do
| anything outside of the "what the vendor provides" box.
There's some truth in that, though I'm not sure about "significantly".
If you want to add your own stuff, it will be harder than it was before.
On the other hand, if you get something from elsewhere, and just want to
drop it in, it will now be significantly easier -- I've seen the effects
of some systems that attempt to edit /etc/rc and install their startups
and have not been pleased at all (and I have adopted the practice of always
making sure there is an explicit (but hidden) exit at the end of the part of
the script I want to run, to attempt to defeat those rc editing systems
(they'll usually find the "exit 0" that is normally at the end of the
script and insert their noise before that ... but if one adds something
like
. /etc/done
several lines earlier, where /etc/done is just "exit 0", the scripts
will usually just go and fiddle after that, before the (now irrelevant)
exit 0 that ends the script.
On the balance, I think that far more people just drop things in, and
would prefer not to have to bother learning how it should be done. And
furthermore, the people who like to just edit rc for themselves, are the
kinds of people who can also manage to live in the new environment fairly
easily (or if they really don't like that, they can replace it). This
looks to be a clear win. Further the only arguments against it seem
to me anyway to amount to not much more than "I don't like it" or perhaps
"It will make things a bit more difficult for me", I don't recall seeing
anything at all which amounts to a specific problem, outside the area of
taste.
Before I finish I should state my biases - I have been using (and manually
adding) rudimentary startup script support in NetBSD since I first started
using that, and before that on other systems. That is, on my (still) 1.3
system you'll find a "runscripts" function in /etc/rc.subr and a couple of
calls to that in /etc/rc (I didn't do all the work to split out all of
/etc/rc into separate scripts, so I needed to be able to run some scripts
early in the boot process, and others later). In ages past (4.3 on a vax...)
I still had script support, and then needed one almost as the first line in
/etc/rc as I had hardware I had to init before much other stuff was done
(my driver back then didn't load its own microcode into the device the way
drivers seem to do these days - rather it just provided an interface to allow
user code to load the microcode, and then start things running).
So, in general, I think this is a definite step forward, and probably I
regret not pushing for the distribution BSDs to correct this 15 years ago.
(Certainly the BSD distributed rc.local was a total farce).
On the other hand, I don't much like "rc.d" as a name, I'd much prefer
/etc/scripts or something like that. But that's just a trivial noise
matter, upon which anyone can have an uninformed opinion, and as I didn't
do the work to implement this, I'm not about to complain (well, not too
much anyway) about the names chosen.
kre
Kevin P. Neal
> One thing I could see doing was to echo the command to be run to
> /var/run/${command}.cmd, thus resulting in a (.pid, .cmd) pair. If one
> wished to restart, one would kill the pid and then run the command found in
> the .cmd file. A 'stop' would kill the pid and delete the .cmd file.
> A 'start' would, through some magic, arrive at the right command
> and args and run it.
What about programs that have multiple processes which need to be
killed?
Case in point: Infoseek's Ultraseek server.
--
Kevin P. Neal http://www.pobox.com/~kpn/
"You're a slacker if you only give 90% 'cause you are afraid of the \
other 10%." -- Ross Smith Apr 22 1999 2:29am
Christos Zoulas
Kevin P. Neal <kpn...@pobox.com> wrote:
>
>What about programs that have multiple processes which need to be
>killed?
>
>Case in point: Infoseek's Ultraseek server.
Usually killing the parent process kills all the children, or the software
has a command to kill the jobs.
christos
Jones, Carrie (Bowen)
I personally come down on the side of monolithic rc, but that's not what is
bothering me now.
der Mouse and Greywolf have now repeated their main complaint *3* times.
There has been no response that I can see.
The main complaint is that amid diverse and strongly held opinions, the
project decided that they were going to shove one of them down everyone
else's throat.
It has been generally agreed that this is *rude*. (I don't believe that this
is considered rude in the commercial os industry because we expect it, but
open source is something else altogether and the violation of the
expectation that we are a valued part of a community is what is rude. IMHO.)
But the only reply is "It's a step in the right direction!" and "You don't
need to know what is going on!" and in response to what I feel are
legitemate questioning of technical details, "That's just not true."
There have been some emails that contain intelligent disscussion of
technical pros and cons, but they are becoming more and more rare.
Why is this happening? Why is there a general refusal on the part of the
project to say "Ok, we rammed this down your throats, sorry." It's not that
big of a thing to admit. You can even omit the "sorry" part, so long as you
admit it!
As for short responses, maybe if you're up really late, it would be better
to respond to them in the morning when you aren't fuzzy. (This is a wild
assumption on my part. I know that when I'm up really early/late in the
morning, I get fuzzy and can't think well, so I'm applying this idea to
everyone else. If it doesn't apply, disregard the comment.)
I do want to restate that I appreciate the time and effort put into
maintaining the project. I simply think that dictation of os to the user
base is rude, and counterproductive thing to do.
I've survived on Win 3.1 for many years now, and I'm certainly not going to
upgrade that half of my computer to anything more evil anytime soon. If
NetBSD continues this trend of shoving things in people's faces, I will
continue to run 1.4.1 and not ever upgrade, though it will cost me the use
of Staroffice, with which I had hoped to sever myself from the evil
Microsoft influence forever. I'm sorry to say this. But I hope that people
will *listen* to the message:
You are going to lose user base if you continue in this fashion.
And the user base you lose, will be the future developers.
Give us a sign that someone is *listening*.
Appologies if this was more a flame than I intended,
Carrie Jones
[ On Thursday, March 16, 2000 at 20:43:42 (-0500), der Mouse wrote: ]
> Subject: Re: rc.d
>
> The price that it exacts is that it is now significantly harder to do
> anything outside of the "what the vendor provides" box.
That's just plain not true.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
der Mouse
> There have been considerable substantive responses so far. Since the
> opponents of the change are just repeating themselves, there's really
> no point in repeating the responses.
Except that what's going on is that when we (me, greywolf, etc) say
"but this change breaks foo!", the responses we see are either "deal"
or "it does bar!". Neither of which addresses the breakage of foo.
And most particularly, I have seen no responses, substantive or
otherwise, to the point that the change was rammed through without even
a vague approximation to consensus, without even so much as "we're
sorry had to do this, here's why". It's been just "this is the way it
will be. deal".
Regardless of what the change under consideration is, that sort of
attitude is a major problem.
> The primary advantage of an rc.d-style system is that it enables
> fail-safe addition and deletion of daemons and other boot-time
> activities as part of packages.
*Mechanical* addition and deletion etc. And I'm not sure I'd go so far
as to call it fail-safe, just somewhat less failure-prone.
Yes, it provides that. I don't think any of the monolithic-rc
proponents have tried to argue it doesn't. I'm fairly sure I haven't.
> Some of the more vocal opponents of rc.d seem to prefer that we
> continue to require that people hack their /etc/rc.local file by hand
> whenever they want to add services.
They seem to prefer that because those are the color of the glasses
with which you're reading what they're writing. In a sense it's even
true. What you don't seem to be seeing is *why* they want that. It
seems to me that it's more like "your way loses this other thing that
we consider more important; yes it'd be nice to have that mechanical
ease, but losing this other thing is too high a price". That's
certainly *my* position.
> I'd rather put my effort into improving NetBSD rather than
> administering my growing herd of netbsd boxes.
So would I. And that's why I don't want split-up rc, because in *my*
experience, a split-up rc makes administration a stressful,
frustrating, and time-consuming experience instead of a smooth,
pleasant, and quick one.
Manuel Bouyer
> I have nothing against the package system, except possibly that it's
> draining off developer cycles that could go to IMO-better uses - though
> developer cycles are not a fungible commodity, doubly so for a
> volunteer project.
It actally saves me a lot of time, by providing already-tested sources
and automatically compiling dependancies. I can spend this time on other
NetBSD stuffs.
For sure a lot of time get spent on the package system, but don't get it
backward: all in all, the package system allows NetBSD developers to spend
more time on other stuffs.
--
Manuel Bouyer <bou...@antioche.eu.org>
--
Manuel Bouyer
>
> > The primary advantage of an rc.d-style system is that it enables
> > fail-safe addition and deletion of daemons and other boot-time
> > activities as part of packages.
> >
> > continue to require that people hack their /etc/rc.local file by hand
> > whenever they want to add services.
>
> written?
>
> The problem with the current bogus hack is that it DOES NOT do what
> you say. It's still necessary to edit rc.conf to make daemons
> actually run.
>
> If we had at least done the /etc/config/ thing, as was suggested...
What he said. I'm all for a rc.d style system, but the one which has been
commited seems to have the cons of both monolitic scripts and rd.d systems.
Several of us have said that, if I remember rigth.
der Mouse
> At that point, you can only come to the conclusion that, if you want
> something new, which we do,
What "we" are you speaking for here?
> So, a decision was made
By whom, and why was nobody even warned?
> to bring in Luke's work, and hopefully work out some remaining issues
> with the input from the users on this list. Some useful input was
> given, but unfortunately it all lead to just another one of these
> long-winded, religiously-flavoured threads.
I trust this is hardly surprising, in view of what's happened every
other time the issue has come up.
> Call it whatever you like, but a decision has been taken about the rc
> system.
Anyone for Yet Another fragmentation?
Greywolf
As much as (Hey, FRANK!) WE SHOULD HAVE BEEN WARNED!!!, and the process
is still absolutely insolent, I must respond to your take of Yet Another
Fragmentation with a resounding NO. Theo went off and did OpenBSD because
core at the time left him no other choice -- he was banned from here due
to highly unacceptable and unprofessional social behaviour which was
apparently having a tremendously negative impact on the Project.
To go and fragment over this issue, as much as even I dislike the material,
and as much as I think the process is still a bit flawed, would be folly.
It's not something I need that badly to fragment.
Not that I disagree with your arguments, mind you. But think about it.
There's how many sects of Paganism, Christanity, Islam, Linux, UNIX already.
We're still ahead of the game -- we only have four distributions (soon to
be three): BSDi, FreeBSD, NetBSD, OpenBSD. To fragment again, I think,
would sink the ship, and seeing as I have a hell of a lot of effort and time
invested in NetBSD, as you do, I'm not willing to take that step (yet).
I will again restate for the record, though: Those of you who think that
the UI doesn't have anything to do with what is a BSD system are quite
WRONG. The UI, the API and the kernel are all very much linked into the
definition of an OS.
Now, onward...
On Sat, 18 Mar 2000, der Mouse wrote:
frank-> [...rc.d hashed out multiple times, to no clear conclusion...]
frank-> At that point, you can only come to the conclusion that, if you want
frank-> something new, which we do,
der Mouse> What "we" are you speaking for here?
I can only assume that Frank is part of core; if he's not, speaking "we"
includes a small majority.
frank-> So, a decision was made
der Mouse> By whom, and why was nobody even warned?
...and I will agree with this...
frank-> to bring in Luke's work, and hopefully work out some remaining issues
frank-> with the input from the users on this list. Some useful input was
frank-> given, but unfortunately it all lead to just another one of these
frank-> long-winded, religiously-flavoured threads.
der Mouse> I trust this is hardly surprising, in view of what's happened every
der Mouse> other time the issue has come up.
In short, that should have been a clue that it's not ready for prime-time
yet!
frank-> Call it whatever you like, but a decision has been taken about the rc
frank-> system.
Without consideration for probably about 47% of the user community (if you
have numbers that differ from this, anybody, please post them).
Could we even get an open poll on this as for pro vs. con, one vote per
person? I'm willing to be open-minded on this as much as I have bitched
about it, so I'm not going to condemn anyone who thinks it is A Good Thing.
Please don't do runlevels, at least not in the braindead way that SysV/Linux
do them </shudder>.
der Mouse> Anyone for Yet Another fragmentation?
NO! I don't think it would be particularly conducive to either party.
--*greywolf;
--
BSD: The Power of Code.
Kimmo Suominen
those of others) I very much want to be able to both control and verify
(preferably at a glance) what gets run at boot automatically. The fact
that someone installs a pkg should not automatically start new services.
One example being when you develop a package -- you probably don't want
it run until you are fully done with it -- and the machine may need to
be rebooted before you are done.
Please, let's also improve NetBSD for us admins.
+ Kim
somme...@orchard.arlington.ma.us (Bill Sommerfeld) writes:
| Some of the more vocal opponents of rc.d seem to prefer that we
| continue to require that people hack their /etc/rc.local file by hand
| whenever they want to add services. I really have better things to do
| with my time; I'd rather put my effort into improving NetBSD rather
| than administering my growing herd of netbsd boxes.
|
| - Bill
--
Kimmo Suominen
k...@tac.nyc.ny.us
Kimmo Suominen
stuff helps me maintain uniform installations at multiple locations
with minimal effort (especially after the initial effort of creating
each package). Overall I consider it saving a lot of time and effort.
I also thing that my developer cycles are best spent on the package
system. I really don't see myself adding tagged queuing to the SCSI
drivers... :-)
+ Kim
P.S. Oh, why am I wasting time responding to mailing list messages?
Well, I don't always feel like spending my time the most effective
way possible to begin with... :-)
bou...@antioche.lip6.fr (Manuel Bouyer) writes:
| --
| Manuel Bouyer <bou...@antioche.eu.org>
| --
--
Kimmo Suominen
k...@tac.nyc.ny.us
Greg A. Woods
> Subject: Re: rc.d
>
> I will again restate for the record, though: Those of you who think that
> the UI doesn't have anything to do with what is a BSD system are quite
> WRONG. The UI, the API and the kernel are all very much linked into the
> definition of an OS.
Temporally speaking that's a very narrow view of the world of Unix.
Perhaps you should boot the V7 emulator on your fastest machine and do
all your work from within V7 for a few days. Then, if you can, jump all
the way forward to something like the most recent AIX release. I think
you'll come to appreciate that "unix" in general has a far deeper
meaning that transcends all the SysV vs. BSD nonsense. Taking a
"rascist" view about what's best and trying to lump a bunch of nebulous
things into far too few categories isn't very productive in terms of
building an even better system. To paraphrase what's been stated
several times already, "If you don't like improvements and modernisation
then go find yourself a VAX and boot 4.2BSD." Saying that "cat doesn't
have -v so it isn't *my* unix" (or vice versa) isn't really very
meaningful -- there are far to many variations on all sides of the
many-dimentional unix fence to allow anyone to be very successful at
saying that any one collection of features is "BSD" and all the rest are
not. Heck why not go back and see what 2BSD was (it'll boot on the
PDP-11 emulator) before you try and say what "BSD" is and isn't.
As kre said BSD died a while ago and the unique collection of people who
made BSD what it was have dispersed and there can be no "BSD way" any
more without being stuck on the past and living with nostalgia.
BTW, if you want a cold hard factual way to define what's BSD and what
isn't I'd suggest looking at the book that best defines it, i.e. "The
Design and Implementation of the 4.4BSD Operating System" and maybe
doing something like counting the percentage of pages that talk about
innards and APIs vs. the percentage of pages that talk about which
getty, init, and su you have on top of the system. Looks like about
0.1% is in the administrative interface if you ask me....
> Now, onward...
Yes, exactly! ;-)
der Mouse
> Fragmentation with a resounding NO.
I'm not really surprised.
Well, it's probably going to produce much-needed change in my life, so
it's not all bad.
And of course I may prove unable to break the addiction anyway. :-(
> It's not something I need that badly to fragment.
For me, it's either that or stop having computers as a hobby as well as
a career. If I'm running computers for a hobby, they *will* be running
something I enjoy playing with.
And as I've said several time, split-up rc files don't qualify.
Your suggestion (in another message) of maintaining a separate rc
script is a possibility, but see my next point.
> [S]eeing as I have a hell of a lot of effort and time invested in
> NetBSD, as you do,
Yeah, but NetBSD has just evidenced a willingness to totally screw me
over without even so much as a by-your-leave - or even a we're-sorry,
despite having the lack of such repeatedly pointed out. Why should I
throw good time-and-effort after bad? Admittedly, I'm not a major
contributor, and logically I can't expect the Project to care much
about me. But this willingness to completely ignore my desires,
unsurprising though it may be, severely dismotivates me to sink any
further effort into NetBSD.
Logically, I know I'm simply a casualty of being far from the norm, and
everyone going for the numbers and niche markets be damned. This is
really whence my suggestion of yet another fragmentation: an attempt to
find out if the niche I fit in is large enough to support such a
fragment. It appears not; there's only one person who's spoken up here
in support of my position, and not even that one is interested in such
a fragment. (NetBSD used to fit it well. The fit has been getting
worse and worse.)
To pull a later message fragment up here to be more cohesive,
>> Anyone for Yet Another fragmentation?
> NO! I don't think it would be particularly conducive to either
> party.
It would help me, in that it would mean I'd have a system I could enjoy
running.
Of course, I mostly have that now. The question is really wondering
whether that niche I've talked about is large enough to support
maintaining an OS that fits it. I probably have the skill and
knowledge (or at least ability to acquire the knowledge) to do so
alone, but it would mean sacrificing too much of the rest of my life,
including most of my paying work. And it's not clear that even then
I'd have enough time to use the result as the base for playing that is
the reason I want it in the first place.
> I will again restate for the record, though: Those of you who think
> that the UI doesn't have anything to do with what is a BSD system are
> quite WRONG. The UI, the API and the kernel are all very much linked
> into the definition of an OS.
If I might digress for a moment to reply to Greg Woods' response
< Temporally speaking that's a very narrow view of the world of Unix.
< [...try using V7, AIX, whatever...] I think you'll come to
< appreciate that "unix" in general has a far deeper meaning that
< transcends all the SysV vs. BSD nonsense.
Yes, it does. That has little to nothing to do with what greywolf was
saying: that "BSD", whatever it means, definitely includes UI aspects.
I entirely agree with this statement.
>> Call it whatever you like, but a decision has been taken about the
>> rc system.
> Without consideration for probably about 47% of the user community
> (if you have numbers that differ from this, anybody, please post
> them).
Personally, I am hoping that major howls will be heard promptly after
the first release that includes this stuff.
I don't really expect that to happen.
Todd Whitesel
> the first release that includes this stuff.
>
> I don't really expect that to happen.
Well: if there isn't a good transition tutorial, and a 'misc' script that
I can dump stuff into until I learn how to do things with the new system,
then you can be sure I am going to howl real loud until that is fixed. I
just need a crutch to lean on while I get my bearings, but other than that
I have no problems with giving the new system a chance.
FWIW Mouse, I agree 100% with your philosophy that you gave when explaining
why you prefer monolithic scripts.
However, I do not agree that rc.d efforts are all fundamentally doomed. I
really would like to see one succeed. I still have faith that rc.d _can_
be done right, and if anybody can manage it, I figure the NetBSD guys can.
I think the "stealth" would not have been necessary if the previous debates
had not always ended up as religious wars. Convincing the other guy that you
will never yield, no matter what, is not exactly the best way to get your
own way, when everyone else is a volunteer just like yourself.
Todd Whitesel
toddpw @ best.com
der Mouse
> debates had not always ended up as religious wars. Convincing the
> other guy that you will never yield, no matter what, is not exactly
> the best way to get your own way, when everyone else is a volunteer
> just like yourself.
Indeed, it appears that the correct way to get your way is to just go
ahead and commit it, disagreements be damned.
Ramming your idea of the right way down everyone's throat is not
exactly an ideal way to make converts either.
As I remarked recently in private mail, I'm not even sure that rc.d
itself is necessarily that bad; I don't expect it to be pleasant, but I
might have been willing to try it and see. But when NetBSD evidences
this much willingness to ditch what I used to think it stood for and
lunge precipitously in the direction of supporting the masses at the
expense of the niche they used to satisfy so well, I have no reason to
think it will stop here. Indeed, I fully expect it to continue until
it's just another point-and-drool free unix variant, distinguished from
FreeBSD largely by the hardware it supports, and Linux by that and the
GPL.
Todd Whitesel
> > debates had not always ended up as religious wars. Convincing the
> > other guy that you will never yield, no matter what, is not exactly
> > the best way to get your own way, when everyone else is a volunteer
> > just like yourself.
Note that my wording above suggests I know more than I'm telling. Actually
I don't. The situation just really smells to me as if those involved felt
it was necessary. I knew Luke was working on something from reading it on
these lists, but I didn't know it would be committed until that happened.
> Indeed, it appears that the correct way to get your way is to just go
> ahead and commit it, disagreements be damned.
>
> Ramming your idea of the right way down everyone's throat is not
> exactly an ideal way to make converts either.
Hold it. Whose throat is being rammed here? Certainly not "everyone's".
If the recent postings are representative, yours and a couple others.
While you can claim the moral high ground in this affair, that is mainly
because of the unwritten (and therefore unenforceable) rules of consensus
that TNF tries rather hard to operate under. Blaming TNF for not enforcing
an unenforceable policy seems somewhat futile to me. After all, there is
no evidence to support the notion that this was done lightly.
> As I remarked recently in private mail, I'm not even sure that rc.d
> itself is necessarily that bad; I don't expect it to be pleasant, but I
> might have been willing to try it and see. But when NetBSD evidences
> this much willingness to ditch what I used to think it stood for and
> lunge precipitously in the direction of supporting the masses at the
> expense of the niche they used to satisfy so well, I have no reason to
> think it will stop here. Indeed, I fully expect it to continue until
> it's just another point-and-drool free unix variant, distinguished from
> FreeBSD largely by the hardware it supports, and Linux by that and the
> GPL.
"this much willingness" ?? After how many false starts, floundered debates,
and other political stalemating? How hard did they try to reach a consensus
before finally doing this? I think they deserve a heckuva lot more credit
than you're giving them here.
I understand you're disillusioned, but your arguments are really reaching
now. Taking things to the logical extreme as if it is going to wake up the
fencesitters; come on.
I think you'd be better off focusing on getting a formal statement like:
"Yes, we realize that there are dissenting opinions, however we have decided
that it is in the best interests of the Project to forge ahread and make the
best of this." Actually I would like to see this too. The distinct lack of
one bothers me, as if giving any sort of ground whatsoever would open the
doors to reversing the decision.
Cripes. The whole thing just keeps getting more and more childish. WTF.
Frank van der Linden
> I think you'd be better off focusing on getting a formal statement like:
> "Yes, we realize that there are dissenting opinions, however we have decided
> that it is in the best interests of the Project to forge ahread and make the
> best of this." Actually I would like to see this too. The distinct lack of
> one bothers me, as if giving any sort of ground whatsoever would open the
> doors to reversing the decision.
See my previous mail.. you can consider that to be such a statement.
Some people have said that the way it was (not) announced wasn't good.
I do understand that reaction. The intention was to bring it into the
tree and work out some remaining issues with input from this list,
but in hindsight a clearer announcement and the availabilty of docs
and examples right from the start would have been better. Live and
learn, I guess.
- Frank
Greywolf
# On Sun, Mar 19, 2000 at 02:23:26AM -0800, Todd Whitesel wrote:
# > I think you'd be better off focusing on getting a formal statement like:
# > "Yes, we realize that there are dissenting opinions, however we have decided
# > that it is in the best interests of the Project to forge ahread and make the
# > best of this." Actually I would like to see this too. The distinct lack of
# > one bothers me, as if giving any sort of ground whatsoever would open the
# > doors to reversing the decision.
#
# See my previous mail.. you can consider that to be such a statement.
Someone (Frank? Greg? Whom?) seemed to want to issue a statement about
"Oh, those details [in rc.subr], you don't need to concern yourself with
them."
I would like to see an amendment or retraction of that statement. It's
not up to the vendor (in this case, NetBSD) to decide what needs to be
or doesn't need to be seen. We're mostly technical types here (I hope!),
so please don't try to close a gaping chest wound with a styptic pencil.
# Some people have said that the way it was (not) announced wasn't good.
# I do understand that reaction. The intention was to bring it into the
# tree and work out some remaining issues with input from this list,
# but in hindsight a clearer announcement and the availabilty of docs
# and examples right from the start would have been better. Live and
# learn, I guess.
Thank you. It's appreciated!
# - Frank
--*greywolf;
--
NetBSD, Net Profit.
der Mouse
>> exactly an ideal way to make converts either.
> Hold it. Whose throat is being rammed here?
Those who use -current, and presumably as of next mainline release,
everyone.
> Certainly not "everyone's". If the recent postings are
> representative, yours and a couple others.
No; *everyone* is getting "this is the way it will be. deal.". Just
because some people like the taste doesn't mean it isn't being shoved
down their throats.
>> As I remarked recently in private mail, I'm not even sure that rc.d
>> itself is necessarily that bad; I don't expect it to be pleasant,
>> but I might have been willing to try it and see. But when NetBSD
>> evidences this much willingness to ditch what I used to think it
>> stood for and lunge precipitously in the direction of supporting the
>> masses at the expense of the niche they used to satisfy so well, I
>> have no reason to think it will stop here.
> "this much willingness" ?? After how many false starts, floundered
> debates, and other political stalemating? How hard did they try to
> reach a consensus before finally doing this?
It doesn't matter, for the purposes of my point in this paragraph, why
or how the Project took this step. It is still a step - or, as I see
it, more like a vertiginous lunge - away from the niche I feel a part
of and towards, well, being Just Another OS catering to the mindless
masses. As of now, it's still also trying to be of some use to people
with clues. I fully expect that within a few years it'll be saying
things like "sysinst does it right, so we don't need to document this
install gotcha"; the "you don't need to know" statements greywolf and I
have made so much noise about strike me as the first visible signs
thereof.
> I think they deserve a heckuva lot more credit than you're giving
> them here.
Credit for what? I believe they are doing a good job of serving the
clientele they want to serve. The problem is, that isn't the clientele
I'm part of, the clientele I saw them as trying to serve when I first
found NetBSD and thought it was a good OS for me. (Perhaps this was
nothing more than wishful thinking on my part back then; I don't know.
I've never seen any sort of overt statement of what clientele NetBSD is
trying to serve, so it's hard to tell whether it's changed.)
I don't, on the other hand, credit them with doing anything for "my"
niche, because I don't think they *are* doing anything for it.
>> Indeed, I fully expect it to continue until it's just another
>> point-and-drool free unix variant, distinguished from FreeBSD
>> largely by the hardware it supports, and Linux by that and the GPL.
> I understand you're disillusioned, but your arguments are really
> reaching now. Taking things to the logical extreme as if it is going
> to wake up the fencesitters; come on.
I'm not trying to wake up the fencesitters. I'm actually not sure why
I'm still discussing the issue.
It's quite clear to me by now that the Project *doesn't* want to serve
that niche, which doesn't leave me much reason to stick around. I
suppose I've still got some slight hope left that I'm wrong in my
inference that the Project has decided to head in a direction I will
not enjoy following. And there's probably also the desire to be
understood; there seem to be a few people who are still trying to
understand why this is such a big issue for me. And, too, it's not
easy to let go of something that I've put this much dedication and
energy into for so long, even when shown that's what I have to do.
And I am quite, quite through with trying to trim and twist myself to
fit into the Project somewhere. I used to be willing to do that,
because NetBSD gave me much and I was trying to fit in enough to give
back. I've now been shown clearly that the Project doesn't care about
that, which, while logically unsurprising (I am not a major contributor
of anything but iconoclastic comments), does mean I no longer see any
point in myself caring, in trying to fit in or give back.
Gods, it's lonely being different.
> [...] as if giving any sort of ground whatsoever would open the doors
> to reversing the decision.
...and heaven knows we couldn't risk *that*.
Greg A. Woods
> Subject: Re: rc.d
>
> Someone (Frank? Greg? Whom?) seemed to want to issue a statement about
> "Oh, those details [in rc.subr], you don't need to concern yourself with
> them."
>
> I would like to see an amendment or retraction of that statement. It's
> not up to the vendor (in this case, NetBSD) to decide what needs to be
> or doesn't need to be seen. We're mostly technical types here (I hope!),
> so please don't try to close a gaping chest wound with a styptic pencil.
I said that it was now no longer important to know the inner workings of
rc.subr, rcorder, et al, for the average person who only needs to tweak
one or two subsystems, and indeed it isn't.
I don't speak for NetBSD.
I also pointed out the obvious and said that if you do want to learn
about the innards then you're more than welcome to do so.
Greywolf
# I said that it was now no longer important to know the inner workings of
# rc.subr, rcorder, et al, for the average person who only needs to tweak
# one or two subsystems, and indeed it isn't.
#
# I don't speak for NetBSD.
Oh, I know _that_ :-)
# I also pointed out the obvious and said that if you do want to learn
# about the innards then you're more than welcome to do so.
It's kind of hard to distinguish those two statements (the first and the
last), I suppose, no matter how they're phrased. The fact that docs
are forthcoming does indicate a bit of light at the end of the tunnel.
I'm just hoping that the light is not
- an oncoming train
- a mirror
- New Jersey
--*greywolf;
--
BSD: exercised any daemons lately?
Kevin P. Neal
Usually. Not always.
Case in point: Infoseek's Ultraseek server.
Plus, in the Ultraseek case, the parent *must* be killed before the
child.
Christos Zoulas
-- Subject: Re: rc.d
| Usually. Not always.
|
| Case in point: Infoseek's Ultraseek server.
|
| Plus, in the Ultraseek case, the parent *must* be killed before the
| child.
so then you can use something like:
runserver
echo $! > /var/pid/foo.pid
then in the stop script
kill first the parent from foo.pid
then the children.
christos
Greywolf
# On Fri, Mar 17, 2000 at 02:16:54PM +0000, Christos Zoulas wrote:
# > In article <2000031708...@tome.neutralgood.org>,
# > Kevin P. Neal <kpn...@pobox.com> wrote:
# > >
# > >What about programs that have multiple processes which need to be
# > >killed?
# > >
# > >Case in point: Infoseek's Ultraseek server.
# >
# > Usually killing the parent process kills all the children, or the software
# > has a command to kill the jobs.
#
# Usually. Not always.
#
# Case in point: Infoseek's Ultraseek server.
#
# Plus, in the Ultraseek case, the parent *must* be killed before the
# child.
Then the software is broken. Any software that depends on a special script
to handle the process flow is Broken As Designed.
--*greywolf;
--
BSD: Multi-platform OS
Frank van der Linden
> Someone (Frank? Greg? Whom?) seemed to want to issue a statement about
> "Oh, those details [in rc.subr], you don't need to concern yourself with
> them."
>
> I would like to see an amendment or retraction of that statement. It's
> not up to the vendor (in this case, NetBSD) to decide what needs to be
> or doesn't need to be seen. We're mostly technical types here (I hope!),
> so please don't try to close a gaping chest wound with a styptic pencil.
I was the one who made it, and I think you misunderstood (maybe I wasn't
being very clear). Some people appeared to be judging the whole new rc.d
system by the contents of rc.subr, which were not immediately clear
to them. I thought this was unfair, because rc.subr is basically just
a helper library of functions, and it's not required to write scripts.
So that's why I said "you don't need to see that part", i.e. you don't
have to be aware of rc.subr to use the system.
Of course people should see the source, we're an open source OS.. that's
the whole point.
- Frank
John Nemeth
}
} Ok, a few things:
}
} * As I've said before, please don't start about the "BSD way"
Why not? We are running NetBSD, not NetSYSV. And, one of the
major factors in the decision for running NetBSD for many of us, is
because it is BSD (or a very close derivative of it).
} of doing things. You are free to run your own setup,
} use another OS, or go find yourself a VAX to run 4.2BSD on.
I don't consider BSD to be a particular release, but rather a
philosophy. I also don't consider 4.2BSD on a VAX 11/780 to be
particularly practical or useful today.
} developer, and no new rc system. You can't please everyone, you
} have to move forward.
Just on general principles, in answer to this statement, I must
say "Why?" I'm not a nochangenik, but at the same time, I don't
believe in change, just for the sake of change. There must be clear
advantages to the change before it goes in, and it mustn't break or
cause other problems. Purely experimental stuff should be done on the
developers own machine, or if it is a really big project, then on a
branch.
} I'd hoped that, once people started using it, more constructive and
} practical suggestions would come up, but unfortunately there is
} already a tendency towards loudness rather than content.
Although I may make suggestions, at this point I'm going to stick
to generalities. I'll wait until I see the final product before I
"scream bloody murder".
} What are the open issues? The main one is that there should be an
} easy, well-documented way to drop in scripts for 3rd-party packages.
} Documentation is lacking, yes, but Luke said he will write it.
} Dropping in scripts currently does mean editing rc.conf, which
} isn't the easiest way. So one can either split up the config
} files or write an automated tool that deals with rc.conf. Either
Personally, I would prefer to see a single rc.conf with an
automated tool that deals with it (probably as some kind of library
routine). As shipped, rc.conf easily lends itself to being modified by
automated tools. Perhaps a compromise for those that prefer it not be
modified by automated tools, those people could add a line like "#@ NO
AUTOMATION" to the top of the file, which would tell the automated
tools to keep its grubby hands off of it. Presumably in this case, a
warning message would be spit out advising the sysadmin that a change
is necessary. The sysadmin could then decide what to do.
} one would work for me. Then there's pkg and local scripts, but
} that just seems a matter of picking an option.
I would suggest that pkg scripts get lumped in with the system
stuff. There should be an easy way of "activating" a pkg which is NFS
mounted. As for local scripts, well they are local scripts and the
sysadmin can do anything they want.
}-- End of excerpt from Frank van der Linden
John Nemeth
} On Tue, 14 Mar 2000, der Mouse wrote:
}
} > > * As I've said before, please don't start about the "BSD way"
} >
} > Why not? *You* don't care about it, so those who do have to shut up?
}
} rc.conf is no more 'the BSD way', than splitting up rc into
} individual subsystem controlling files, but they both intended
} to ease administration.
I would disagree. As I said already, I believe that BSD is more a
philosophy than a static version. I feel that rc.conf is more in tune
with that philosophy then splitting up rc is.
}-- End of excerpt from David Brownlee
der Mouse
>> practical suggestions would come up, but unfortunately there is
>> already a tendency towards loudness rather than content.
> Although I may make suggestions, at this point I'm going to stick to
> generalities. I'll wait until I see the final product before I
> "scream bloody murder".
The biggest problem with this is that by that time there's no way it's
ever going to come back out even if it *is* seriously broken. (Of
course, in this case it doesn't matter anyway; it's clearly in and
going to stay, anyone who doesn't like it be damned.)