Chapman Flack wrote:
> Garrett D'Amore wrote:
>> Do we really need this bogus symlink?
>> Can the admin just symlink /netbsd if /netbsd is not the real name of
>> the kernel.  Creating another hack like a magic symlink seems silly
>> to me.
>> I think this whole thing is a non-solution to a non-problem.

The proposed solution is, IMO, still not right for a few significant
reasons:

1) it will continue to require system administrator intervention (at
least to configure initially)
2) it creates a permanent API (the new symlink) which presumably will
need to be maintained in perpetuity
3) because of #2 above, it encourages implicitly the creation of even
more grovelers
4) it doesn't solve the problem for a large class of machines that
simply won't have the kernel image in a mounted filesystem.

Therefore, if folks want to override and go ahead with this, so be it. 
But don't expect me to call this hack anything else -- its a band-aid
that is ill-conceived and more like something I'd expect the PeeCee-ish
crowd in Linux-land to come up with than the normal high quality
engineering that has characterized most of the other stuff that the
NetBSD group has come up with.

I'm sorry if this opinion offends people.  I've given the opinion, and
I've even offered to help rewrite some of the grovelers to *not*
grovel.  I'll shut up about it now, but I am not likely to change my
opinion.

    -- Garrett
>>
>
> What you think has never been unclear in this thread, but what's
> been striking is the degree to which you haven't even followed
> the discussion as it unfolded.  To hold that the thread is about a
> "non-problem" is to have somehow not grasped any of the actual
> substantive problems explained in the last couple of days.
>
> Sure, the admin can create a symlink pointing to the real kernel.
> And recreate it every time a different kernel is booted. Is that
> what you pay an admin for, or could it be automated somehow? My
> proposal was one way, Steve Bellovin's rc script was another, which
> he first proposed very early in this thread, and IIRC you objected to
> both. He has gone further and actually drafted up a script, which
> comes in at 30 lines of shell in one file. My proposal was likely
> to need about 8 lines of C in one file, vfs_lookup.c, in the
> existing magic-symlink switch near @osrelease, @kernel_ident, and
> @domainname.  Your objection seemed to be that 8 to 30 lines of
> C or shell would be too much to spend on improving the usability
> of the OS while tackling the longer term project of implementing
> new interfaces for the groveling programs, an amount of effort
> which you seemed to think would be somehow comparable.
>
> Pretty much everyone else participating in the discussion has
> posed thoughtful questions or answers, gathered information or
> supplied new proposals that clarified the issues and the space
> of usable solutions. As it turns out, a closer look at savecore
> has convinced me that Steve's proposal is superior to mine for
> that purpose, and just as good for the other grovelers (as long
> as they run /after/ the script). If that is offered as a
> consensus I will support it, and the symlink proposal will be
> dropped, as you seem to prefer. But it's worth seeing that the
> consensus, if such it be, has been reached through the constructive
> efforts of a number of people other than you to understand and
> contribute to the discussion.
>
> By calling other proposals "bogus," "silly," "garbage," "half-
> solution to one-third of the problem," and so on, you've left
> no doubt about /what/ you think, and that doesn't bother me as
> long as it doesn't embarrass you. But wouldn't it show you in a
> better light not to stop at just reiterating /what/ you think,
> but to join in the reasoned exchanges over /why/, which usually
> entails trying to follow the trains of thought other than one's own,
> and in fact responding to them? It really helps the conversation
> get somewhere.
>
> Others in this thread have done that. At your off-the-cuff guess
> at how many groveling programs there were, someone else actually
> looked, and contributed that information to the discussion. At
> your off-the-cuff estimate of how long it would take to rework
> them all, several somebody elses actually put in the effort to
> look in the code and think about what would be involved. Against
> that backdrop, one person has been kind of sounding like a broken
> record, and I'm sure that's not really what you want, right?
>
> -Chap


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191