Linux Unified Kernel

I'm looking forward to when this gets to beta status:

http://en.wikipedia.org/wiki/Linux_Unified_Kernel

This is practical, pragmatic kernel development. Linus was recently quoted putting down Ndiswrapper, well I'm glad that these LUK developers are embracing Ndiswrapper as part of the kernel. The potential is enormous, and I have always been unhappy that Linux is controlled by open source GPL fanatics who have deliberately kept Linux incompatible with closed-source drivers. Ndiswrapper is not just for wireless but could conceivably extend to supporting other Windows device drivers -- very easily support modem drivers -- which would be wonderful (and almost too late, as the world moves on from dial-up).


Posted on 27 May 2009, 15:12


Comments:

Posted on 27 May 2009, 21:30 by linuxcbon
gpl
linus is right rejecting closed source stuff.
I am not happy puppy relies on those.


Posted on 27 May 2009, 21:51 by Dougal
LUK, GPL, OSI and FSF
Hmm.

The "GPL fanatics", as you call them, are in fact the "Free Software" people -- quite the opposite of the "Open Source" people. The OSI/BSD camp actually criticize the FSF/GPL people for their "fanaticism", claiming their hardline approach hinders development. To find how much sense that makes, I'd recommend you try basing Woof on Debian/kFreeBSD and see how well it is in terms of HW support... (I'm sure Rarsa can provide more input on matters of the GPL.)

As a matter of fact, Linus does _not_ like the FSF approach (see also his fight with Tridge from five years ago -- Samba _are_ Free Software people), having as his only goal technical advancement. Thus he favors the GPL for it's demand for reciprocity.

The reason for a lack of stable kernel driver ABI has long been stated as not wanting to limit the technical development of Linux just for te sake of those companies who don't want to play along (and actually break the law in doing so). (you will also note that the Linux people are willing to sign NDAs with companies, in order to write GPL drivers, while the BSD people won't... hmm)

As for Ndiswrapper, people who actually bother trying to fix bugs (ahem), don't really want to have to try and figure out what screwy things some Windows driver might be doing (the kernel has enough ugly workarounds to deal with crap HW, they don't really need to add more crap just to handle foreign drivers).




Posted on 27 May 2009, 22:58 by linuxcbon
gpl and bsd
Bsd or Minix reject the gpl, for money and they want to please companies.
Thats why I will never like them !
And I reject companies like Apple who use open source to have free manpower.
Call me dangerous communist extremist but its Gpl or nothing.


Posted on 28 May 2009, 8:19 by BarryK
Re: free software
Yes, my use of the words "open source" in regard to fanatics was not precise.

My post was a bit "devil's advocate", stirring things up.

The Chinese apparently have a long-term strategy, which also includes their mips-based Loongson CPU and Lemote laptop.



Posted on 2 Jun 2009, 12:54 by Raffy
Free-dom not libre
Oh, how do we call the "firmware" that Puppy actually uses - aren't these closed-source (binaries)? The Classmate PC does well with RT73 firmware, for example.

Linus chose GPL for its reciprocity (free to modify then share code), and I guess you did, too.

GPL allows people to earn from free software, such as via customization for users. And user-specific code can be kept proprietary.

"Open source" has been used loosely, and GPL advocates are quick to avoid it. For example, a smarty often says that "open source software is not secure 'coz it's open" (sic sic sic). :D


Posted on 2 Jun 2009, 13:08 by Raffy
x86 platform by DMP
As to alternative processors and chips, DMP is forging ahead with its x86 architecture:
http://www.dmp.com.tw/

Perhaps it will be easy for you to evaluate their new PMX-1000 line.

Note that DMP is the partner of Norhtec's Michael Barnes. You have a post about their gecko laptop:
http://puppylinux.com/blog/?viewDetailed=00771


Posted on 13 Jul 2009, 9:30 by wrygeek
A better idea...perhaps
Hmm...so what happens if one of those sturdy, reliable MS device drivers everyone loves, just happens to fall over because of, say, "lunar disturbances"? Will a hard reset be required?

From what I've read previously, Torvalds is against having fixed API's in Linux (the kernel) to retain flexibility as it evolves. The LUX project would, at first appearance, go against this philosophy, as it seeks to implement the various MS API's for drivers and applications in the kernel itself.

I've had this idea for some time now, having "bumped" my skull into a few HW devices over the years whose makers have been tight-fisted
with their specifications, and seeing the ways a
determined few have made up for that absence.

I have not mentioned it before now because if implemented, HW makers would have no incentive
to provide specifications for their products so
that Linux drivers can be written. Now that this
would happen anyway if the LUK was taken up...

The idea is this - All closed-source drivers would instead be run outside the kernel in a daemon, say
"closed" (or "tainted" ;-), which keeps the complexity of supporting API's for other OS's out
of Linux.

In this way, faulty drivers would typically crash the daemon - the offenders could then be removed and the daemon restarted, instead of restarting the entire OS.

And yes, this idea could be extended to foreign applications as well ("wined", "dosemud", etc.)

If nothing else, keeping potentially-rotten eggs away from Tux's nest would help to direct "user's comments" to the appropriate parties ;-)

Just my $0.02 worth...


Posted on 13 Jul 2009, 9:48 by BarryK
ndiswrapper
wrygeek,
I don't really know anything about how ndiswrapper works, but isn't this what it already does in Linux? A layer to isolate a Windows driver.

But, it has only been developed for wireless drivers. I know though that it could be extended to cover other Windows drivers such as modems -- the ndiswrapper developers themselves have said so.

But the major players in Linux development do not want to embrace the closed source proprietary Windows drivers.

As you say, if it could be done such that the evolving Linux is not held back, that would be very interesting...