I wonder if things are different on the BSD side versus the Linux side. Just a guess, but Linux kernel development has always had a sort of anti-academic view, perhaps soured by the early Tanenbaum-Torvalds flamewar, whereas much of BSD was actually written by academics (the name comes from UC Berkeley, after all), and collaboration still seems reasonably common. There might be some downside to Linux being so popular, as well: it's now the default option, so people who just need something, anything to test on will pick Linux, whereas my guess is that people modifying, say, the NetBSD kernel for academic work are more interested specifically in NetBSD and contributing back to it. Solaris development also long had a close relationship with academic researchers working on Solaris, for whatever reason (probably Sun actively making efforts, including hiring academics for summer consultancies).
> Just a guess, but Linux kernel development has always had a sort of anti-academic view,
That doesn't prevent almost all realtime-related academic papers and research to be focused around linux. Simply put linux is practical. It has a large mind-share, it has a lot more drivers, and most importantly it is being very actively developed.
Sadly enough a lot of academic-only projects last on average 4 years before they die off -- that is usually the time someone takes to do their PhD.
One can also argue that realtime OS-es are largely driven by a practical need from the industry side of things rather than from an academic perspective.
> the NetBSD kernel for academic work are more interested specifically in NetBSD and contributing back to it.
That also means one would have to be a NetBSD enthusiast and also a realtime enthusiast. The intersection of those 2 sets is probably fairly small.
Excellent essay (and, I assume, talk). This jumped out at me:
So it seems that there is the reverse problem on the real world developer side: we are solving problems, comparing and contrasting approaches and implementations, but we are either too lazy or too busy to sit down and write a proper paper about it
That would be invaluable, but I understand that they don't do it for the very same reason that OS researchers don't submit patches to the LKML: it's not what they're evaluated on.
If you've ever been frustrated by the disconnect between research and industry in the area of computing, read this essay.
yup agreed, and even if developers would like to write up their findings in an academic-style paper, they aren't likely to be accepted at top-ranked conferences, since they're so selective and only publish papers that are presented and polished in a very academic way
fortunately, i think now some good conferences have more 'applied' or 'industrial experience' tracks
I think just writing them up anywhere will get at least some attention, because academics often do tend to search for "what is industry doing on this?", and they have less stringent standards for publication venues when they're looking for an industry paper versus an academic paper--- it doesn't have to be in the top conferences, since it's not a scientific result that needs to be peer reviewed so much as a documentation that industry is doing things in a certain way, and why they decided to do so.
Linux is starting to have a few self-run conferences that publish papers, like the annual GCC developers' conference, which might be good places for that sort of thing. Old-school Unix vendors traditionally had their own journals for that purpose, e.g. the DEC Technical Journal, Sun Technical Journal, and a whole host of IBM journals, all of which got cited in academia reasonably often.
The thing is, what the author describes is science. They implemented a bunch of different options, evaluated them experimentally, and came to conclusions. But, they just use their conclusions to inform how implementation should proceed, they didn't tell everyone else about their conclusions. Publishing those results would be interesting to academics.
Also industry is profit driven. It is hard for an employer to justify spending time and money to get papers published when there are bugs to be fixed and products that have to roll out.
Comparing and contrasting research results is almost impossible. Even if a lot of research happens on Linux there is no way to compare and contrast the results as researchers, most of the time, base their work on completely different base kernel versions. We talked about this last year and I have to admit that neither Peter nor myself found enough spare time to come up with an approach to create a framework on which the various research groups could base their scheduler of the day. We haven't forgotten about this, but while researchers have to write papers, we get our time occupied by other duties.
This is almost entirely the Linux kernel's fault. The development pace on the kernel is quick and very few things are guaranteed to be stable. By the time my group had worked out a patch a release block was finished. I gain almost no benefit from sending this to LKML and I hear it's never worth the flames my colleagues get when you haven't done enough "work" for them. The worst was a colleague having to defend his patch from a paper to the kernel team. Who cares? The devs can take it or leave it, we don't have time for that crap.
/Unfortunately almost none of the results ever trickled through to the kernel development community, not to mention actually working code being submitted to the Linux kernel mailing list./
Unfortunately, when an academic submits their working code to the Linux kernel mailing list, they're likely to get flamed to a crisp if they get any response at all. They learn real quick not to waste their time with that hostile crowd.
Not to mention the volume of the Linux kernel mailing list is absurd. Who has the time or inclination to keep up if it's not their main passion?
