Linked by Thom Holwerda on Mon 17th Sep 2012 16:56 UTC, submitted by Andy McLaughlin
Permalink for comment 535589
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 06/13/13 14:35 UTC
Linked by Thom Holwerda on 06/11/13 17:07 UTC
Linked by Thom Holwerda on 06/10/13 23:13 UTC
Linked by Thom Holwerda on 06/08/13 14:57 UTC
Linked by Thom Holwerda on 06/07/13 11:40 UTC
Linked by Thom Holwerda on 06/04/13 12:45 UTC
Linked by nfeske on 05/31/13 10:12 UTC
Linked by Thom Holwerda on 05/29/13 16:59 UTC
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
More Features »
Sponsored Links



Member since:
2005-07-06
It was mostly just half-joking continuation of "That's what the BIOS does. Welcome to 16-bit mode" post just above ...though UEFI did have also that goal in mind, IIRC. And which, as I said, didn't really work out - and you pointed out some possible issues with the UEFI approach.
Problem is, perhaps that's one of the very few ways of achieving such total plug'n'play? The others would be a) drawing on the work of existing standard bodies (but I have some doubts if Haiku, Syllable or Visopsys support, say, even USB video class) b) drawing on the work done for the big boys (what NDISwrapper does, and ReactOS has a goal of using all standard Windows drivers IIRC; I believe there's also notable BSDs <-> Linux cross-pollination, extending also to Haiku and such).
Either way, it would force more idiosyncrasies of dominant OS onto independent ones - would that be good?
Cameras are also covered BTW, VoIP devices largely fall under some device class for external USB soundcards, and there was also some standard for scanners IIRC.