Linked by Thom Holwerda on Mon 17th Sep 2012 16:56 UTC, submitted by Andy McLaughlin
OSNews, Generic OSes "Visopsys (VISual OPerating SYStem) is an alternative operating system for PC-compatible computers, developed almost exclusively by one person, Andy McLaughlin, since its inception in 1997. Andy is a 30-something programmer from Canada, who, via Boston and San Jose ended up in London, UK, where he spends much of his spare time developing Visopsys. We had the great fortune to catch up with Andy via email and ask him questions about Visopsys, why he started the project in the first place, and where is it going in the future."
Thread beginning with comment 535498
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: The hardest part
by zima on Mon 17th Sep 2012 19:35 UTC in reply to "RE[2]: The hardest part"
Member since:

Well then that's what the UEFI does now. Or at least was supposed to, I think - didn't really work out (NVM forcing all OS into the same idiosyncrasies; IIRC it follows some of WinNT, so MS even kinda participates...)

Reply Parent Score: 2

RE[4]: The hardest part
by Alfman on Mon 17th Sep 2012 20:27 in reply to "RE[3]: The hardest part"
Alfman Member since:

Well, maybe, but I only posted that in response to the BIOS comment. I don't consider UEFI firmware a great substitute for a software driver standard. I don't have practical experience with UEFI, but I see some possible negative implications:

1. The hardware firmware can't be managed as easily/safely as software drivers can be. Can I update firmware drivers for one device independently from the rest or is this a monolith firmware?

2. For UEFI services to work, my devices will have to be supported through my mainboard. If the device uses a newer standard, and my os supports the newer standard, is it possible that my mainboard can never the less prevent me from using it because it lacks firmware updates?

3. I don't think UEFI can contain drivers to support all external peripherals - like webcams, cameras, scanners, various adapters, voip devices, etc. It seems like a bad idea to try and cram all the drivers for these in the motherboard's UEFI services.

To be honest, I'd rather have a standard that is capable of scaling to all sorts of devices and not one that depends on my motherboard's firmware implementation. So I think a software solution would be better....however I'd like to hear other ideas.

Reply Parent Score: 2

RE[5]: The hardest part
by ssokolow on Mon 17th Sep 2012 20:34 in reply to "RE[4]: The hardest part"
ssokolow Member since:

To be honest, I find UEFI ominous because, apparently, most motherboard manufacturers start with Intel's reference implementation and end up with something as big and complex as an OS kernel.

It's bad enough that the motherboard's firmware now contains enough of a network stack to spy on you and phone home if subverted. Does it really also need to be so big that it's statistically guaranteed to have exploits?

(When this BIOS-based motherboard breaks, I'm either going to buy a replacement from the crop of pre-Win8 mobos or I'm going to start my shopping at the CoreBoot compatibility list.)

Reply Parent Score: 2

RE[5]: The hardest part
by zima on Tue 18th Sep 2012 18:07 in reply to "RE[4]: The hardest part"
zima Member since:

I only posted that in response to the BIOS comment. I don't consider UEFI firmware a great substitute for a software driver standard

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.

Reply Parent Score: 2