On i18n [was: Re: On errno]

[Poul-Henning Kamp]

In message <17CC6EDA-E2F7-4BC3-B7EB-EAAA3F80A9C1 at mac.com>, Marcel Moolenaar wri
tes:

>> We write an OS for the people who can and will use an OS written by  
>> us.
>
>Doesn't this ipso facto mean that FreeBSD is bound to be
>used by the same people who develop it?
>
>Isn't this a recipe for cliques?

And isn't that more or less the case ? :-)

It was a registration of fact, not a prescription to follow.

>> Such an influx, should it happen, would most likely be rebuffed and
>> resisted by the current developers of FreeBSD.
>
>Right. You block the thing you argue will not happen.

I don't block anything, I merely record my non-belief in the viability
of the concept, and advocate not unduly wasting our severely limited
developer time on it.

If people want to I18N the kernel, they are free to do so for all I
care, as long as the source code is still readable.

The thing I do try to block, is the "lets try to squeeze it into
15.72 bits and use the rest for flags" mentality, because it hurts
us to no end.  It is a 1970 mindset that should have no place in a
general purpose kernel running on multiple megabyte RAM machines.

I went a long way to push "state of the art" in this area with nmount
and geom, both of which abandons the "struct+#define" model for much
more flexible means.

The "struct+#define" model, stems from times where disk deviced
drivers allowed root to fondle their registers directly through
ioctls, so magic operations like disk formatting could be done from
userland without bloating the kernel.

Today we tell kernels to perform complex operations, which gives
complex diagnostics when they do not succeed, and therefore the
solution is not a 64bit errno encoded in bitfields, but a text
buffer, where a sensible diagnostic can be produced.

If you don't belive me, look in netgraph, which has a nightmare
facility for encoding stuff, pushing into the kernel, and decoding
it again.

The really funny thing here is, that if you measure the amount of
code required to fold error conditions into struct+#define packing,
and unfolding it again into text, you'll find that it bloats the
system, relative to just writing the text in the first place.

That is why I propose that programs register a buffer with the
kernel, and we stick the error right there and then.

That obviously raises the question of I18N and language in the
kernel, and my position is: as long as dmesg(8) speaks english,
the kernel speaks english.

If somebody want to come up with a credible I18N model for the
kernel, fine.

Until such time, forget I18N in this context, because there are
much bigger problems for I18N in the kernel, than this error text
buffer.

>Maybe we should ask ourselves this: if the current
>developers rebuf and resist influx, isn't it time
>for them to hand in their commit bits and find some
>other project to contribute to?

Marcel, if you have access to the core mail archives, you will find
a lot of emails from me on the subject of retirement, retirement
policies, and the lack thereof.

Over history, we have had a lot of arm-chair generals cling to their
commitbit, because in FreeBSD you don't even get a goldenish watch
when you retire: you get nothing.

Recently, a committer who have been in the project longer than me,
and carried a particular important task through a decade, retired.

I don't recall seeing as much as a "thanks for all the fish"
from core.

Personally, I hope to be able to give my reasoned advice and shrug
my shoulders when it is not followed:  I have always been a big
believer in the principle, that committed code talks loudest.

Poul-Henning

FreeBSD General (3. Armchair, under the window)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.