Microsoft no longer a top Linux kernel contributor After making headlines with its unexpectedly voluminous contributions to the Linux kernel in 2012, Microsoft has all but disappeared from the Linux development scene, according the latest report from the Linux Foundation. The last edition of the Foundation's annual Linux kernel development report saw Microsoft break into the …
This post has been deleted by its author
"what about Windows 3.1 > Windows 3.11"
Windows 3.1 was actually 3.10, as you would be told by writing a program to ask it its version number. It would return 0x0A03(*), meaning 3.10.
(*) Yes, this is wanked. It is why Win95 included code to return 3.95 to programs that were marked as "built for Win 3.*". A number of "commercially important" such programs naively compared the returned version number to 0x0A03 rather than swapping the byte order and comparing to 0x030A. Win95's true version number was 4.0, 0x0004, so it lied to programs targeted for 3.* to present itself as 3.95 (0x5F03).
Well, yes and no. The kernel uses even numbers to indicate stable releases, with odd ones being more experimental. So after the 3.8 (stable)/3.9 (unstable) pair, then you can go on to the 3.10/3.11 branch.
Also, all kernel releases are defined by three numbers rather than two, eg, 3.4.1, 3.8.17, and so on. Also, to be totally pedantic, everything after a dot is treated as a regular "decimal" number when it comes to sorting (like 'sort -n').
In Perl: :
print join " < ", sort {my @A=split /\./, $a; my @B=split /\./, $b;
while (@A or @B) {
$apart = shift @A || -1; $bpart = shift @B || -1;
next unless $apart <=> $bpart; return $apart <=> $bpart;
}
return 0;
} ("3.10.1", "3.2", "3.1.2", "3.10", "2.0", "2.1.4", "3.4.1", "3.8.17");'
Which prints
2.0 < 2.1.4 < 3.1.2 < 3.2 < 3.4.1 < 3.8.17 < 3.10 < 3.10.1
(apologies for formatting, since we don't have working "pre" HTML tags)
the kernel will make whatever MVS/OS/390System Z is called this year look small. How much cruft is accumulating in there ? Time for more development of microkernel OS methinks. At least a human has a chance of keeping the possible state combinations in mind so debugging without massive tools becomes faster
Most of that code is drivers and the various architectures. If you stripped out everything but the x86-64 architecture and the drivers needed for the top 10 PC models that shipped so far this year it would be far far smaller, and show a very moderate rate of growth.
There really isn't as much worry about the possible state combinations as you seem to think since you can't run two architectures at once, so no conflict is possible there. While drivers can possibly conflict, the sheer number of drivers isn't as big of a problem as you might think because many classes of devices will never share the same running kernel. For example, you will never see an accelerometer on a Qualcomm SoC and a Fibre Channel HBA share the same kernel.
"Time for more development of microkernel OS methinks"
By all means, you can join the Minix or Hurd developing teams or, if they don't suit your aesthetics, you can start a new kernel from scratch.
By the time you support al the architectures and hardware the Linux kernel does, how big do you think will be tarball with the source?
There are a lot of good reasons for going microkernel in terms of security (even "binary blob" drivers get ring-fenced access) and in-memory footprint (only in-use drivers need be loaded).
But...usually performance hit of going in/out of ring 0 for every driver/file system action means it gets side-lined, and few have the stomach for trying to compete with Linux/Windows (even BDS) for developer attention.
I figured the whole point, if you're in a position to be hugely bothered by the kernel size, is that you can turn off a shitload of options in the kernel headers and compile your own teeny-tiny version, with support just for the hardware you're running it on?
Or just download Ubuntu or some other preconfigured distro where about everything sensible has been switched on.
Would a microkernel end up any smaller after every single driver (sorry, Service) for every possible bit of hardware out there has been included in with the distribution? Don't forget, Windows is a hybrid kernel that does a ton of stuff the microkernel way. Hardly a size 0, is it?
Today you are only likely to worry about kernel size for embedded applications, and there you probably are going to roll a customised kernel with just what you need.
As you say, Windows has a lot of micro-kernel like aspects, but still has become bloated and need rebooting for way too many patches. Most of the bloat is probably not 'kernel' in the classic sense, but it is an issue for smaller devices like phones & fondleslabs.
And it misses the point - if going microkernel you really would be doing it primarily for security and fault tolerance/recovery, so you need a _VERY_ minimal 'kernel' and everything else as user-space modules.
Oh yeah, of course! Code naturally decays over time as the bugs start to eat away at it..... That's why zx81s don't work anymore.
*sigh* All code is written on the basis of assumptions. When those assumptions are no longer valid, the code breaks.
Code that assumed it could write directly to hardware registers like it did on DOS broke when people tried it on Windows NT.
Old Linux kernel drivers that assume a function operates a particular way or a data structure is arranged a certain fashion will break when for whatever reason, that function or data structure needs to change.
Linux, for better or worse, moves a lot faster than anything Microsoft has ever put out. This is what allows it to adapt to change and be much more agile. The downside is that 6 months from now, the way of doing things back then, may mean small changes are needed to keep things working, and so it's extra maintenance overhead.
I observe Microsoft have gone to annual releases now, so this may not just be a "Linux problem".
Pretty easy to explain, Canonical works on their own crapware/spyware like Dash, plus Mir and Unity, and doesn't need to contribute to the Kernel much except to patch it to make their software work (I almost said shit, I really almost did, but we'll not let our personal feelings cloud facts). Thats all they NEED to do, so its probably all they do.
When you're busy spying on your users, attempting to make money riding on Amazon/Bezos' back, and otherwise acting like Microsoft circa 1997, you don't tend to want to contribute back any more than the minimum requirements to make Ubuntu work with the Kernel.
As much as I think the FSF and Richard M. Stallman are zealots, they got it right calling Ubuntu spyware. Debian doesn't spy on you, Fedora doesn't spy on you, Suse doesn't spy on you, hell I don't think Mint spys on you (but it is based on Ubuntu so I guess it is possible it does, but I dunno, I dont usually go near APT based distros). You can turn this behavior off, but by default Canonical is collecting and selling your data to Facebook, Twitter, Amazon and the BBC. Auntie knows what you're up to if you don't change your privacy settings. You're still not getting rid of dash unless you fork the code and strip it out yourself AFAIK.
> Canonical's considerable contributions to the Linux ecosystem have been in areas other than the kernel.
Such as?
I am an occasional contributor to the Linux ecosystem (not the kernel itself) and from what I tend to hear Canonical is not exactly popular in the community. Things might have changed in the last year or so though, which is why I would be interested to know what those contributions are.
Microsoft writing drivers for Microsoft virtual hardware doesn't really count as "kernel development" in any sense that would make them a contributor. That they were counted as a "leading contributor" only demonstrates that ranking by committed LoC is flawed.
Linux is unique among operating systems in that we have a repository of drivers maintained in lockstep with the kernel itself. While this is wonderful for maintaining driver compatibility, the downside is that it does become a bit cumbersome. I blame that twit Linus Torvalds, for refusing to maintain a stable kernel ABI.
Bottom line: Microsoft wrote Microsoft drivers. They have never been an actual kernel contributor.
Mr. Foobar, from the tone and character of your previous comment may I surmise that you are on the Forbes 400 list *and* have an Operating System named after you?
It's admiring that you even found the time to come up with a better system that counting lines of code for ranking the volume of contributions to the kernel. Perhaps you could point us to a description of your work in this area?
What the stats are for something like Windows. It would be interesting to see exactly what is going on there. How many lines of code are changed in the product? How many are left over from the MS-DOS days?
I suspect that there are some from both catagories (probably a small number). But we will never know!
I should imagine for supporting devices that didn't exist three years ago...
The built in wi-fi on this PC doesn't work OOTB on Ubuntu 10.04, but is auto detected and works fine on 12.04
Debian 7 support is there, Centos 6.3 works.
Only "problem" I have ever had was a Broadcom WI-fi in an old Dell laptop, but a quick prod with the Hardware Driver tool soon had it working.
Step-son had a few problems with an Alienware laptop with dual graphics cards, but that is now sorted.
Has the windows kernel not been updated in that time?
Microsoft is drowning in the mobile market, fighting toe to toe in cloud services, and watching their core business evaporate. Any Linux contribution at this point needs to help drive customers their way. Supporting Linux on Azure is a nice step to diversify their portfolio to reach additional customers, but developing any other Linux software may only serve to help the likes of Google's Android or Apple. They can't have that. Not now.
Notice some of the biggest contributors are hardware manufactures or those with huge hardware partners. Microsoft is still predominately a software company. When most of the open source software is being published under GPL and other copyleft licences, it doesn't bother the hardware folk because they aren't making the money back on the software. If you're a software-centric firm it can really make a huge difference.
But hasn't Microsoft done enough? Oracle buys Sun and then sues Google for using Java in Android... It's amazing Microsoft never cried foul when the mono-project (and others) cropped up to map much of their .NET technologies for the Penguins to enjoy. No lawsuits. If anything, they handed hordes of code over and made several public specifications to encourage it's development. Sure it helped them some indirectly, but would Apple have done the same? Would Google? Ahhhh... No! Think of how useful the mono-project has been to the Linux world. Microsoft not suing earns them a Penguin badge, never mind their past transgressions.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
