Linked by Thom Holwerda on Mon 17th Sep 2012 16:56 UTC, submitted by Andy McLaughlin
Permalink for comment 535799
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2007-03-26
I see what you're saying. I guess even if there wasn't a technical limitation, there might still be a political one as to have a universal driver format, you'd have to have a universal binary format. You raised a good point about how windows uses DLLs and Linux uses ko's. So on one OS, PE's are the preferred binary format and on the other -Linux- ELFs are.

I'm fairly certain I read somewhere that the Linux kernel is written in such a way that it can have support for other binary blobs (in fact a.out is still natively support), but the question is, would Linus, Redmond nor any of the other kernel devs want a "foreign" (for want a better term) executable format to be supported in kernel space? Maybe I'm just being naive or overly critical, but I couldn't see that happening.
You did also raise the point about compatible source code, but Linux has a hard enough time getting source code for things like 3D graphic acceleration and Wireless chipsets, so I couldn't see any universal model working unless it supported closed binary blobs.
I don't mean to be pessimistic as I think your idea is a great one. I'm just trying to understand the logistics of it all