A modest proposal for better errno values...
Jordan Hubbard
I'm about to raise is prime bike-shed material of the first order. It
is a matter so trivial that it's not at all unreasonable to expect
every man and his dog in this project to have a strong opinion on it,
so in the name of bandwidth conservation and all that's holy I merely
ask you to honestly ask yourself "do I really, truly care about this?"
before sending off your personal 500 word screed on the subject that's
to follow. Finally, and just for the record, I'll note that two of my
dogs pretty much agree with me on this and the third, a small white
poodle with an attitude problem, honestly doesn't give a damn and
indicated as much by merely showed me his teeth when I asked him about
it.
With all that out of the way, I'll get on with it. Here at Apple we've
been merging this and that from FreeBSD, as is our usual custom, and
today several engineers saw something go across in a cvs merge commit
which raised more than a few eyebrows and led to various queries as to
the origin of the following new errno in FreeBSD:
jkh@freebsd-> grep DOOFUS /usr/include/sys/errno.h
#define EDOOFUS 88 /* Programming error */
Doing a little digging, I also see that a certain Dane is responsible
for both the original commit on 2002/08/09 and a spelling fix to it on
2002/08/21 (I guess the OED is pretty clear on the spelling of
"doofus"). Most of you who know me at all will also know that I'm
hardly the most reverent or humor-impaired person you'll ever meet and
I certainly got a chuckle out of this when I first saw it, just as I've
gotten a chuckle out of various man pages and function names in FreeBSD
which showed that the programmer responsible for them was at least
enjoying his or her work at the time. I'm all for that, particularly
in situations where a developer or user has to go well out of their way
to get offended by something and therefore isn't exactly an object of
sympathy.
This, however, is a little more in-your-face than something like the
infamous "die_you_gravy_sucking_pigdog()" function in shutdown (which I
successfully defended when it came up) since it sort of makes an
implied statement about the developer's competence, rightly or wrongly,
and is far more likely to propagate into other code since if there's an
errno value returned by something then it also needs to be checked by
the client code. From the corporate perspective, and corporations are
infamous for not being particularly inclined towards humor, this is one
particular little "easter egg" in FreeBSD that sticks just a little too
far above the ground to lend a professional image.
So, to make a long story short, this is one small area where Apple's
going to have to gratuitously diverge from FreeBSD if it remains this
way and I frankly hate that idea since it just makes diffing things
that much more annoying and for reasons which could be best and most
accurately described as "silly." That said, I'm sure the reactions
of the various people reading this will still vary between "who gives a
damn what Apple thinks of our errno values?! Get a life, Apple!" and
"yeah, that's a pretty silly errno value and in rather colloquial
english at that, let's pick a more descriptive name like ``EUSERERR''
or something which makes any code using it more clear."
I'm naturally hoping that more people will be of the latter opinion and
we can just change it and move on, one more gratuitous and unnecessary
code fork thus averted, but if the group consensus is that we should
get bent and simply change our own value to one which potentially
offends our developers less (or remove it entirely) and not bother the
FreeBSD project with such requests, I'm willing to live with that too.
I had to at least ask, however, rather than just making the change
unilaterally on our side... Thanks, and let the bikeshed building
begin!
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Bob Bishop
At 09:57 13/5/03, Jordan Hubbard wrote:
>[stuff]
>#define EDOOFUS 88 /* Programming error */
>[more stuff]
Before the noise becomes unbearable, I have a question:
Why isn't EINVAL appropriate to the case in question?
--
Bob Bishop +44 (0)118 977 4017
r...@gid.co.uk fax +44 (0)118 989 4254
Poul-Henning Kamp
tes:
>#define EDOOFUS 88 /* Programming error */
My first reaction was to check the Received headers, to see if this
email had accidentally gotten held up for about six weeks, but no
such luck.
I also know that you personally have stared with disbelief at the
person who brough this up to you, and probably checked your calendar
as well.
And having worked at a big US company, I know from personal experience
how much tiny details can become big issues, so I am sure that
you are not making this up: Somebody at Apple probably are worried
that they will get sued for insulting programmers, or get unfavourable
press because some silly journalist needs to fill 4" in column 3
and cant find a picture of potato which looks like Lincoln.
So we have to deal with it...
This error is currently used exactly one place in our kernel, where
it indicates that somebody with a FreeBSD commit bit or similar
level of clue has goofed up some code in such a way as to seriously
put users disk content at risk.
Traditionally, we have used panic(8) in such circumstances, but
there is no need to panic in this case, the system is perfectly
fine, there is no inconsistency, there is no risk, because the
kernel spotted the mistake and stopped before things got dangerous.
(We need to get away from using panic in situation where the system
can survive without risk, this is my little contribution to that
goal).
You will by now have noticed that the user will never see the EDOOFUS
text, it will always be presented as "Programming error", so the
only people to be offended are people reading source code, so I think
the risk of Samuel B. User being offended by accident is nil.
In my mind, "EUSERERR" as you propose, _would_ actually be insulting
for the user, because there is nothing the user can do to avoid
this error return, until the programmer fixes his mistake.
So far, I have gotten no feedback which indicates that anybody was
offended, or knew anybody who might get offended or even could think
of anybody who might get offended by this. I have however received
a fair bit of feedback which show that those people appreciated a
little joke here and there.
And while I do think there is a limit to what our source-code should
contain this is not over that limit.
So I seriously think that somebody at Apple needs to get a life.
Next thing you know, they'll want me to add a softdrink option to
the beer-ware license in order to not encourage DUI and alcoholism.
_If_ there had been substantial traffic of kernel source from Apple
to FreeBSD, I _might_ have been a lot easier to persuade, since the
diff might one day be on my screen, trying to integrate something
from Apple.
But as it is now I am not at all interested in selling our freedom
to have a bit of fun to Apples sensibilities when I see little or
no tangible returns for me or the project for such concessions.
So it will take a direct edict from core@ or a well-documented
concensus amongst our developers to convince me that there is a
problem and that we need to fix it in FreeBSD.
And should that happen it will add another grain of sand on the
side of the balance which says "FreeBSD is not fun anymore". (And
it goes without saying that I would not at all accept that some
hot-head just changes it before such a quorum is documented).
And you are perfectly spot on in your assumption that this is likely
to lead to a 500+ mail bikeshed, which will get into the deeper
subjects about programmer psychology, 1st ammendment rights, political
correctness, needlessly being offensive, needlessly being an
anal-retentive idiot, needlessly lacking basic genes for humour
recognition, how this was no problem at Novell when Terry invented
UNIX there, only to finally fizzle out when nobody but the arm-chair
generals are left and even they get tired of it, and the get revived
a couple of months later when somebody reads the mail-archives and
reignites the entire thing again.
So I might be tempted to suggest we just skip all that noise and
discussion, and go straight to a referendum on developer@, based
on your email stating the "pro" and this reply stating the "contra".
Either way, this is my only email on the subject.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Robert Klein
> This error is currently used exactly one place in our kernel, where
> it indicates that somebody with a FreeBSD commit bit or similar
> level of clue has goofed up some code in such a way as to seriously
> put users disk content at risk.
mm, if the programmer "goofed up", why not name it
EGOOFUP ? sounds kinda more descriptive than "DOOFUS"...
(jumping into shelter...)
Robert
Gary Jennejohn
Bob Bishop writes:
> Hi,
>
> At 09:57 13/5/03, Jordan Hubbard wrote:
> >[stuff]
> >#define EDOOFUS 88 /* Programming error */
> >[more stuff]
>
> Before the noise becomes unbearable, I have a question:
>
> Why isn't EINVAL appropriate to the case in question?
>
If you look at the 4 places where it's in the tree it's pretty clear that
returning EDOOFUS is meant to rub the programmer's nose in a coding error
(recursive malloc() calls, etc).
At least the error string ("Programming error") is reasonable.
I agree that the name isnt' too happily chosen and should be changed to
something more neutral before it shows up in more places in the tree.
---
Gary Jennejohn / ga...@jennejohn.org g...@freebsd.org g...@denx.de
Thomas David Rivers
>
>
> On Tuesday 13 May 2003 12:05, Poul-Henning Kamp wrote:
> > This error is currently used exactly one place in our kernel, where
> > it indicates that somebody with a FreeBSD commit bit or similar
> > level of clue has goofed up some code in such a way as to seriously
> > put users disk content at risk.
>
> mm, if the programmer "goofed up", why not name it
> EGOOFUP ? sounds kinda more descriptive than "DOOFUS"...
>
> (jumping into shelter...)
>
> Robert
I think Robert is "on to" something here...
But - EGOOFUP isn't descriptive enough for the situation
Poul-Henning writes about...
How about
EKERNERR /* A programming error in the kernel */
Wouldn't that be descriptive of the situation without insulting
anyone?
- Just a thought -
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Colin Percival
>How about
>
> EKERNERR /* A programming error in the kernel */
>
>
>Wouldn't that be descriptive of the situation without insulting
>anyone?
If I understand the purpose of this error code, it deals with cases
where data is in an invalid state. In that case, why not make the error code
EASSERT /* An assertion has failed */
Colin Percival
Jaron Omega
> So, to make a long story short, this is one small area where Apple's
> going to have to gratuitously diverge from FreeBSD if it remains this
> way and I frankly hate that idea since it just makes diffing things
> that much more annoying and for reasons which could be best and most
> accurately described as "silly." That said, I'm sure the reactions
> of the various people reading this will still vary between "who gives a
> damn what Apple thinks of our errno values?! Get a life, Apple!" and
> "yeah, that's a pretty silly errno value and in rather colloquial
> english at that, let's pick a more descriptive name like ``EUSERERR''
> or something which makes any code using it more clear."
Apple became a corporation, May 25th 1998. Not technically ofcourse, but
in spirit.
> I'm naturally hoping that more people will be of the latter opinion and
> we can just change it and move on, one more gratuitous and unnecessary
> code fork thus averted, but if the group consensus is that we should
> get bent and simply change our own value to one which potentially
> offends our developers less (or remove it entirely) and not bother the
> FreeBSD project with such requests, I'm willing to live with that too.
> I had to at least ask, however, rather than just making the change
> unilaterally on our side... Thanks, and let the bikeshed building
> begin!
I personally have no problems with this modest request. So, this is my
vote cast in your favor. This is largely due to my respect of Apple, and
appreciation of Apple efforts past and present. It's just a vote though,
not much weight by itself.
Omega
northern snowfall
Why not: EEEEEEEEEEK
Aled Morris
> If I understand the purpose of this error code, it deals with cases
>where data is in an invalid state. In that case, why not make the error code
> EASSERT /* An assertion has failed */
EDONTPANIC /* a panic has been averted */
Aled
Ceri Davies
Picking one of these mails at random:
On Tue, May 13, 2003 at 07:43:06AM -0500, northern snowfall wrote:
> > EASSERT /* An assertion has failed */
>
> Why not: EEEEEEEEEEK
Why not stop suggesting other silly names on hackers, and take that bit
to chat, so that this thread doesn't get noisier than it's likely to already?
Ceri
--
Terry Lambert
> Robert Klein <RoK...@roklein.de> wrote:
> I think Robert is "on to" something here...
>
> But - EGOOFUP isn't descriptive enough for the situation
> Poul-Henning writes about...
>
> How about
>
> EKERNERR /* A programming error in the kernel */
>
> Wouldn't that be descriptive of the situation without insulting
> anyone?
It appears in both the libc malloc code, and in the GEOM code
under the bde subtree in the kernel, so it is not kernel
specific for "programming errors"; by a ratio of 3:1, it's a
user space programming error.
Personally, I am partial to "EPROGERR"; it matches the error
text, if it needs to change. It has the advantage of leaving
it ambiguous whether we meant "programming", "programmer", or
"program", too.
-- Terry
Greg Shenaut
>#define EDOOFUS 88 /* Programming error */
#define ESUFOOD 88 /* Programming error */
Greg Shenaut
Frank Mayhar
>
> Bob Bishop writes:
> > Hi,
> >
> > At 09:57 13/5/03, Jordan Hubbard wrote:
> > >[stuff]
> > >#define EDOOFUS 88 /* Programming error */
> > >[more stuff]
> >
> > Before the noise becomes unbearable, I have a question:
> >
> > Why isn't EINVAL appropriate to the case in question?
> >
> If you look at the 4 places where it's in the tree it's pretty clear that
> returning EDOOFUS is meant to rub the programmer's nose in a coding error
> (recursive malloc() calls, etc).
>
> At least the error string ("Programming error") is reasonable.
>
> I agree that the name isnt' too happily chosen and should be changed to
> something more neutral before it shows up in more places in the tree.
Um, no. If it were "EFUCKHEAD" or "EIDIOT" maybe, but EDOOFUS is about
as inoffensive as it comes.
But I have a better idea: Why doesn't the committer in question actually
fix the problem, so that instead of four places, there are no places? Seems
like this would eliminate the error as well as the reason _for_ the error.
In other words, this bikeshed is aimed at absolutely the wrong target.
Sigh.
--
Frank Mayhar fr...@exit.com http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
Tim Kientzle
> #define EDOOFUS 88 /* Programming error */
EINTERNAL
would seem appropriate for a detected bug within FreeBSD
code, whether kernel or userland.
Tim Kientzle
Andrew Kinney
> Now, before I start here, let me just acknowledge up-front that what
> I'm about to raise is prime bike-shed material of the first order.
This entire issue will require a committee of 100, a summer
conference, and a winter tech retreat with lots of doh!nuts.
FWIW, I happen to agree that, while funny as heck, it won't
promote widespread acceptance of FreeBSD in the humor-anemic
of the world. Humor-anemia seems to generously afflict those
great-white-never-seen-the-sun-shine-rear-ends of the business
world inclined.
But, like I said, FWIW. My opinion probably means squat around
here since I've never done anything of substance and only ever
generate to-do lists for those that work on the VM system of
FreeBSD. ;-)
Sincerely,
Andrew Kinney
President and
Chief Technology Officer
Advantagecom Networks, Inc.
http://www.advantagecom.net
Garance A Drosihn
>... and "yeah, that's a pretty silly errno value and in rather
>colloquial english at that, let's pick a more descriptive name
>like ``EUSERERR'' or something which makes any code using it
>more clear."
I think it is fine to change the name, but EUSERERR is certainly
not right. The bikeshed is then picking an appropriate name.
EBADCOMMIT(ER) ESKIPDISASTER EAVERTWOE EAVOIDABYSS
seem like some plausible names, given the description of the
history behind the name, and what error is used for. I'm sure
another hundred could be thought of after about 15 minutes with
a thesaurus.
--
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
Leo Bicknell
> EBADCOMMIT(ER) ESKIPDISASTER EAVERTWOE EAVOIDABYSS
>
> seem like some plausible names, given the description of the
> history behind the name, and what error is used for. I'm sure
> another hundred could be thought of after about 15 minutes with
> a thesaurus.
Given the history of this thread perhaps "EAPPLE" would add a nice
bit of history. :) It would give future generations a reason to
google for this thread.
--
Leo Bicknell - bick...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-lis...@tmbg.org, www.tmbg.org
Michael Meltzer
#define E370HSSV 88 /* Programming error */
I think this one keeps the orinigal sprite of EDOOFUS, I will now crawl back into my cave :-)
MJM
PS. For the non dyslexics try reading it upsidedown.
Jordan Hubbard
EDONTPANIC suggestion someone made earlier. :)
- Jordan
Wes Peters
>
> jkh@freebsd-> grep DOOFUS /usr/include/sys/errno.h
> #define EDOOFUS 88 /* Programming error */
I think your tie is knotted a bit too snugly, it's cutting off the flow
of blood into your brain.
If Apple wants to import FreeBSD code (it has been a very one-way
street, hasn't it?) and wants to avoid having an EDOOFUS in their
system, Apple can certainly devote a few minutes of programmer time to
writing an import filter that automagically converts EDOOFUS to the
Apple approved errno that does not marginalize stupid programmers. (It
does make one wonder why Apple would be so touchy about this particular
problem, doesn't it?) I want to suggest EWORM but that obviously won't
do in the corporate humorless environment.
It really is too bad that Apple has never quite recovered from Tim's
warped sense of humor, in re: Butthead Astronomer.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters w...@softweyr.com
Wes Peters
> On Tue, May 13, 2003 at 01:57:13AM -0700, Jordan Hubbard wrote:
> > So, to make a long story short, this is one small area where
> > Apple's going to have to gratuitously diverge from FreeBSD if it
> > remains this way and I frankly hate that idea since it just makes
> > diffing things that much more annoying and for reasons which could
> > be best and most accurately described as "silly." That said, I'm
> > sure the reactions of the various people reading this will still
> > vary between "who gives a damn what Apple thinks of our errno
> > values?! Get a life, Apple!" and "yeah, that's a pretty silly
> > errno value and in rather colloquial english at that, let's pick a
> > more descriptive name like ``EUSERERR'' or something which makes
> > any code using it more clear."
>
> Apple became a corporation, May 25th 1998. Not technically ofcourse,
> but in spirit.
So change it to EBUTTHEAD, that should be perfectly safe for Apple.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters w...@softweyr.com
Andrew J Caines
> If it's just used for kernel errors, I was pretty happy with the
> EDONTPANIC suggestion someone made earlier. :)
In many of the more relaxed civilizations on the Outer
Eastern Rim of the Galaxy, FreeBSD has already supplanted
the great UNIX[R] as the standard repository of all knowledge
and wisdom, for though it has many omissions and contains
much that is apocryphal, or at least wildly inaccurate, it
scores over the older, more pedestrian work in two important
respects.
First, it is slightly cheaper; and secondly it has the error
EDONTPANIC inscribed in large friendly letters in its source.
[With no apology to the late great DNA, -hackers or anyone else]
-Andrew-
--
_______________________________________________________________________
| -Andrew J. Caines- Unix Systems Engineer A.J.C...@halplant.com |
| "They that can give up essential liberty to obtain a little temporary |
| safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 |
Stijn Hoop
> Jordan said...
> > If it's just used for kernel errors, I was pretty happy with the
> > EDONTPANIC suggestion someone made earlier. :)
>
> In many of the more relaxed civilizations on the Outer
> Eastern Rim of the Galaxy, FreeBSD has already supplanted
> the great UNIX[R] as the standard repository of all knowledge
> and wisdom, for though it has many omissions and contains
> much that is apocryphal, or at least wildly inaccurate, it
> scores over the older, more pedestrian work in two important
> respects.
>
> First, it is slightly cheaper; and secondly it has the error
> EDONTPANIC inscribed in large friendly letters in its source.
>
> [With no apology to the late great DNA, -hackers or anyone else]
I vote for EDONTPANIC, but only if the this text is included as a comment
directly above the definition in the header :) :) :)
--Stijn
--
"...I like logs. They give me a warm fuzzy feeling. I've been known to keep
logs for 30 months at a time (generally when I thought I was rotating them
daily, but was actually rotating them once a month)."
-- Michael Lucas, in Big Scary Daemons article 'Controlling Bandwidth'
Peter Jeremy
>> #define EDOOFUS 88 /* Programming error */
>
>#define E370HSSV 88 /* Programming error */
You might get this one past the suits if you can come up with an
appropriate acronym (one that keeps their mind off reading it
.(umop 3p!sdn
My (non-tongue-in-cheek) suggestion is EASSERT - this is an assertion
failure that you don't want to abort()/panic() on.
Peter
Wilko Bulte
> On Tue, May 13, 2003 at 07:55:14PM -0400, Michael Meltzer wrote:
> >> #define EDOOFUS 88 /* Programming error */
> >
> >#define E370HSSV 88 /* Programming error */
>
> You might get this one past the suits if you can come up with an
> appropriate acronym (one that keeps their mind off reading it
> .(umop 3p!sdn
>
> My (non-tongue-in-cheek) suggestion is EASSERT - this is an assertion
> failure that you don't want to abort()/panic() on.
#define EDONTPANIC 42 /* ... */
--
| / o / /_ _ wi...@FreeBSD.org
|/|/ / / /( (_) Bulte
John Baldwin
On 14-May-2003 Wes Peters wrote:
> On Tuesday 13 May 2003 01:57, Jordan Hubbard wrote:
>>
>> jkh@freebsd-> grep DOOFUS /usr/include/sys/errno.h
>> #define EDOOFUS 88 /* Programming error */
>
> I think your tie is knotted a bit too snugly, it's cutting off the flow
> of blood into your brain.
>
> If Apple wants to import FreeBSD code (it has been a very one-way
> street, hasn't it?)
Just a comment here. I think this last statement is bull. Apple
has made lots of bugfixes to our code available in Darwin. All it
takes is for someone to extract their lazy rear from a chair and
import those fixes. We don't import our fixes into Darwin, Darwin
developers do that. In the same way, it is rather absurd to
require Darwin developers to backport their fixes to FreeBSD. That
is the job of FreeBSD developers. As an example of how this can
work, see the recent fixes to smbfs that bp@ imported from Darwin.
--
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
David O'Brien
> _If_ there had been substantial traffic of kernel source from Apple
> to FreeBSD, I _might_ have been a lot easier to persuade, since the
> diff might one day be on my screen, trying to integrate something
> from Apple.
>
> But as it is now I am not at all interested in selling our freedom
> to have a bit of fun to Apples sensibilities when I see little or
> no tangible returns for me or the project for such concessions.
_ _ _ _ _ _
| | | | ___ __ _ _ __ | | | | | | ___ __ _ _ __ | |
| |_| | / _ \ / _` | | '__| | | | |_| | / _ \ / _` | | '__| | |
| _ | | __/ | (_| | | | |_| | _ | | __/ | (_| | | | |_|
|_| |_| \___| \__,_| |_| (_) |_| |_| \___| \__,_| |_| (_)
--
-- David (obr...@FreeBSD.org)
Roman Neuhauser
>
> On 14-May-2003 Wes Peters wrote:
> > On Tuesday 13 May 2003 01:57, Jordan Hubbard wrote:
> >>
> >> jkh@freebsd-> grep DOOFUS /usr/include/sys/errno.h
> >> #define EDOOFUS 88 /* Programming error */
> >
> > I think your tie is knotted a bit too snugly, it's cutting off the flow
> > of blood into your brain.
> >
> > If Apple wants to import FreeBSD code (it has been a very one-way
> > street, hasn't it?)
>
> Just a comment here. I think this last statement is bull. Apple
> has made lots of bugfixes to our code available in Darwin. All it
> takes is for someone to extract their lazy rear from a chair and
> import those fixes. We don't import our fixes into Darwin, Darwin
> developers do that. In the same way, it is rather absurd to
> require Darwin developers to backport their fixes to FreeBSD. That
> is the job of FreeBSD developers. As an example of how this can
> work, see the recent fixes to smbfs that bp@ imported from Darwin.
As far as I know Covalent's and IBM's developers *do* work on
mainstream Apache in they day work.
But don't read this as a support to Wes' position. I'm undecided.
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html
Jordan Hubbard
> Just a comment here. I think this last statement is bull. Apple
> has made lots of bugfixes to our code available in Darwin. All it
> takes is for someone to extract their lazy rear from a chair and
> import those fixes. We don't import our fixes into Darwin, Darwin
> developers do that. In the same way, it is rather absurd to
> require Darwin developers to backport their fixes to FreeBSD. That
> is the job of FreeBSD developers. As an example of how this can
> work, see the recent fixes to smbfs that bp@ imported from Darwin.
Thank you for saying this, and not because I don't think there isn't
more that Apple can to do communicate and work cooperatively with the
open source community - I do think so and it's one of the things I work
almost every day to improve. I thank you for saying this because what
you summarize below is a long-standing problem endemic to FreeBSD's
relationship with almost ALL other open source projects, not just
Darwin. As early as 1993, people were meeping about FreeBSD not doing
enough to track NetBSD changes or how it was gratuitously diverging
from NetBSD due to NIH syndrome. The same has subsequently been said
about FreeBSD and OpenBSD and all the security work which has gone on
in that project.
All these allegations have also been true to a large extent, and I'm
sure that "mining" all the good stuff out of OpenBSD, NetBSD and Darwin
could keep a team of 5 engineers busy for several months, probably to
the great benefit of FreeBSD. That would also represent a serious
amount of drudge work, however, and most of it drudge work of the most
onerous kind: Sifting through thousands of lines of source code just to
find the good bits and then hand-merging then carefully back and
thoroughly testing the result to make sure nothing was broken.
This is why I've been prevailing on Apple (and engineers in general) to
stop thinking of contributing to the Open Source community as "throw
lots of code over the wall and hope that it's of use to somebody" since
that's actually a very limited view of contribution and, sadly, how
most people measure it. Anyone going to
http://www.opensource.apple.com/darwinsource/10.2.5/index.html will
find, for example, tons of software freely available, anything marked
"Other" being truly easy to deal with and the APSL stuff somewhat less
so but still obtainable (and I'm working on streamlining all the
licensing issues), but guess what: It doesn't really matter all that
much anyway since very very few people even bother to look at it and
wouldn't even if the licenses said nothing more than "Free! Take me!
Take me!" Merging code is boring drudge work, particularly when you
have to merge it in "polling mode" where you're coming along after the
fact and trying to reconstruct a history of events between now and
whenever you last looked.
What's missing isn't code. What's missing, in all of these cases, is
sufficient COMMUNICATION about what's going on or where the cherries
are to be picked. If people from the NetBSD project, for example, came
by frequently with little gift-wrapped bundles of code and offers to
help anyone willing to integrate it by answering questions or working
cooperatively on any changes necessary to make it applicable to
multiple projects, we'd be talking a completely different game entirely
(not to say that this never happens, but certainly not frequently).
That would truly be collaborative development in action and, sadly,
there's generally very little of it which crosses project lines. There
are a few stalwart individuals who try to maintain a presence in
several projects simultaneously and act as message-bearers when any
technology suitable for merging goes by, but that's also not easy work
and the people in this project should go out of their way to thank
anyone for trying to do that and encourage more of it. I've also been
putting steady pressure on Apple's engineers to overcome their
traditional aversion to sticking their necks out in public (an aversion
which is sadly well-justified) and start trying to work more "shoulder
to shoulder" with engineers in the Open Source community, making the
point over and over that steady communication trumps throwing code over
the wall every single time. Progress has been slow but it's being
made, and if anyone wants to yell at Apple or any other company for not
"contributing" to the open source community, they should take a step
back and wonder if maybe they're truly yelling about the right problem.
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
Paul Turley
and fan, an interested party if you will, and so my thoughts are
disposable; my vote isn't to be counted. But here are my thoughts, for
those who care to read them.
To put this in some perspective, the various versions of Apple Pascal I ran
on my various versions of Apple ][ had a global variable which modified the
system behavior in several ways. The variable was not exactly in plain
sight, but was visible to a user who took more than a cursory glance at the
software and/or its documentation. The Boolean variable "STUPID"
--documented as STUdent Programmer ID-- was set TRUE by default, as shipped
by Apple Computer.
Apple has requested that the FreeBSD project change an identifier in the
FreeBSD source, as Apple finds the current identifier somewhat indelicate.
There seems to be some feeling that Apple has contributed little to the
FreeBSD project. So the question seems obvious: Just how much, in tangible
terms, does Apple want this changed? And what, of equivalent value to the
project, are they prepared to offer in exchange for this favor?
Be careful of the precedent you set.
--pht
Josef Grosch
> > If it's just used for kernel errors, I was pretty happy with the
> > EDONTPANIC suggestion someone made earlier. :)
>
> In many of the more relaxed civilizations on the Outer
> Eastern Rim of the Galaxy, FreeBSD has already supplanted
> the great UNIX[R] as the standard repository of all knowledge
> and wisdom, for though it has many omissions and contains
> much that is apocryphal, or at least wildly inaccurate, it
> scores over the older, more pedestrian work in two important
> respects.
>
> First, it is slightly cheaper; and secondly it has the error
> EDONTPANIC inscribed in large friendly letters in its source.
>
>
> [With no apology to the late great DNA, -hackers or anyone else]
I vote for EDONTPANIC. It has a nice inside joke feel to it.
Josef
--
Josef Grosch | Another day closer to a | FreeBSD 4.8
jgr...@MooseRiver.com | Micro$oft free world | www.bafug.org
DinDin
A. While Hubbard's shame and discomfort at broaching this subject is
endearing and appears honest, I can't help feeling this is simply a
request that should never have been made. Akin to asking your new
neighbour to drive you to the airport through rush-hour traffic: it's
only okay if there's a really good reason and there's no other way.
B. Surveying all the suggestions thus far, it now seems obvious that
EDOOFUS is by far superior to most other options. It's got just the
right touch of charming, cheerful humour to soften the necessary
criticism. The programmer unlucky enough to encounter EDOOFUS will
certainly not repeat his/her mistake again; not because they were
offended, but because they'll remember laughing about it at the time.
C. Humor and food is all we need to enjoy ourselves, and EDOOFUS has
both!
Jacob Sherman
> In a message written on Tue, May 13, 2003 at 06:51:06PM -0400, Garance A Dr
> osihn wrote:
> > EBADCOMMIT(ER) ESKIPDISASTER EAVERTWOE EAVOIDABYSS
> >
> > seem like some plausible names, given the description of the
> > history behind the name, and what error is used for. I'm sure
> > another hundred could be thought of after about 15 minutes with
> > a thesaurus.
>
> Given the history of this thread perhaps "EAPPLE" would add a nice
> bit of history. :) It would give future generations a reason to
> google for this thread.
EBADAPPLE would perhaps be more appropriate :)