

Realtime Linux: academia v. reality - corbet
http://lwn.net/SubscriberLink/397422/27eef125e03b8a2d/

======
_delirium
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).

~~~
rdtsc
> 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.

------
scott_s
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.

~~~
pgbovine
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

~~~
_delirium
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.

~~~
scott_s
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.

------
Locke1689
From the other side:

 _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.

------
dadkins
/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?

