That's why I love Linux... [LWN.net]

That's why I love Linux...

Posted Dec 15, 2005 10:35 UTC (Thu) by Duncan (guest, #6647)
In reply to: That's why I love Linux... by sbishop
Parent article: SMP alternatives

I'm certainly no MSWormOS fan, and I like your point, but in actuality,
from what I've read, MS is one of the better proprietaryware venders in
regard to multicore, at least. While the likes of Oracle continue to bill
per core, MS has been looking pretty flexible by comparison, saying it
will continue to license per CPU, even as the number of cores per CPU
begins to climb.

As to the USB driver, if it's useful for you, unless you are developing it
for as yet unreleased hardware, it's almost certainly going to be useful
to others as well. The GPL doesn't require publishing code for internal
work, but consider the benefits of either /not/ having to do that internal
maintenance, as it's done for you by the kernel crew, or submitting it for
kernel inclusion and becoming the maintainer yourself, thus gaining
visibility and favorable press throughout the Linux world, /plus/ having a
bit of the work still done for you, when someone changes out kernel code
you depend on from under you.

Of course, you likely have your reasons for not doing so, but come on, you
gotta admit such a posting to LWN is just /begging/ someone to ask why you
haven't yet made source available! <g>

Duncan

(Log in to post comments)

That's why I love Linux...

Posted Dec 15, 2005 16:18 UTC (Thu) by sbishop (guest, #33061) [Link]

Yea, I suppose that I should have seen that coming. :)

I work for a manufacturing company. The hardware is a tester that only we'd be interested in. And the driver really isn't far distanced from usb-skeleton.c, so it very interesting either.

That's why I love Linux...

Posted Jun 1, 2006 16:41 UTC (Thu) by cventers (guest, #31465) [Link]

Is it a tester that no one else on Earth owns? :)

I read that GregKH re-emphasized at the recent FreedomHEC that the kernel
has drivers with only a handful of users. Perhaps mainline inclusion
isn't an impossible thing after all.

Internal-use kernel code

Posted Dec 16, 2005 16:51 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

You silently merge the idea of making source code available and of getting it in the kernel.org tree. You also seem to merge, as many people do, the idea of submitting code for inclusion and of that code being included.

There's a significant cost to getting code into kernel.org. I myself write lots of kernel code, and while the world is welcome to all of it and much of it is published, I have never attempted to get any of it into kernel.org.

First, I'd have to translate it to a coding style I don't like and package it according to some pretty specific rules. Then I'd have to run the gauntlet of some mailing list, probably having to rework the code a few times. Some of that rework would be stuff I don't agree with. Some would be stuff I have no use for. At no point would I have any guarantee my work would result in any code going in.

So I suffer the costs of being out of tree (mainly, I can't use the most current kernel.org code), but it beats the cost of getting in tree.

Internal-use kernel code

Posted Dec 16, 2005 19:42 UTC (Fri) by Duncan (guest, #6647) [Link]

Well, I'm aware of the difference, but didn't go to my usual lengths to
specify it. How come other folks can take shortcuts, but every time I
abridge a detail, I get called on it? <g> I suppose it's likely because
folks are used to me being so detailed, tho some might be just
coincidence.

Anyway, yeah, thanks for making the code available, even if it's not
targeted at the kernel tree ATM. That's an important right of Free
source, too, being able to NOT have to go for merge, if desired, tho
because it's Free source, others can take it and go for that merge if they
want to, again, another important right.

Thanks also for filling in those details. It's quite possible the
additional information will be of use to future readers, and I /did/ fail
to mention it, so it's good someone came along to fill the gap. =8^)

Duncan