Carl Hensler <[EMAIL PROTECTED]> wrote:
> Yes, but ...
>
> Is this kind of restriction on access to code consistent with open
> source development? The Linux world copes with the fact that a lot of
> code is a work in progress. Things evolve, rapidly at first and then
> more slowly. Consumers and participants accept the fact that things change.
>
> I understand our traditional rules for Solaris, but are they appropriate
> for OpenSolaris?
This isn't really restriction on access, it's just annoying
inconvenience. In fact, I would turn your question around: Why is GLDv3
being handled *differently* from traditional rules for Solaris? There
isn't supposed to be any implication of interface commitment just from
shipping a header file. Why does someone seem to have gone out of their
way to make GLDv3 especially inaccessible, compared to other private
implementation details?
I think the GLDv3 obscurity is just stupid. It seems to indicate a
belief that Solaris is used by only two kinds of people: ISVs who depend
on stability and forward compatibility, and end-users who only use ISV
products and don't write code or look at how the system works. I'm in
neither category. I *use* the system itself. I have always preferred
Unix over closed systems because I can, if I want to, write code that
does what I need today, taking full advantage of any internal, unstable,
or ill-conceived system functionality that I can find, knowing full well
that my code will rot away (or just get rm'd) after I'm finished using
it. I've written dozens, perhaps hundreds, of useful programs that
became obsolete a few months later as soon as I upgraded to a new OS.
Looking back, I don't consider any of that effort to have been wasted.
In fact, I see it as lingering examples of why I've always chosen to use
open "hackable" systems and been very productive in doing so.
To put a practical spin on this particular issue, when I installed my
new Solaris server at home a few months ago, I downloaded an open-source
driver for my NIC. It had been written and tested on the current GLDv3.
I tried to build it but it didn't compile because, you guessed it,
sys/mac.h is not present. And I knew, more-or-less, what to do... find
a snapshot of the ON gate from the build that I'm running, pull it down,
install mac.h somewhere (/usr/include?) and perhaps repeat a few more
times depending on what else might be missing. But I didn't know if
this meant I'd have to set up and learn how to use Mercurial, and didn't
know how long this would take, so it was easier to find a GLDv2 driver,
which meant I can't use IP instances, which meant I can't decommission my
old firewall when I bring up the new machine, which means I can't really
switch over yet to the new server in the way I plan to deploy it, which
means the whole project is much lower on my priorities list now, which
means I haven't gotten around to working on it lately... so here I am
typing this email on my old Red Hat system.
mac.h being missing isn't a fundamental barrier to adoption, it's just
one additional glitch along the way, and, I think, a sign of an
unhealthy attitude by the developers.
</grumble>
Of course, like many, What I'd most prefer to see is GLDv3 completed and
made a committed interface.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
[email protected]
