| News | Features | Interviews |
| Blog | Contact | Editorials |
| Visopsys: one man's vision to build an operating system |
| By Thom Holwerda, submitted by Andy McLaughlin on 2012-09-17 16:56:46 |
| "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." |
|
| RE[4]: The hardest part |
| By Alfman on 2012-09-17 20:31:41 |
|
zima, I've purchased a few webcams, one this year. I have yet to own a webcam where windows drivers weren't necessary...but then it's a noname brand. If what you are saying is true and they are becoming standardised, that's a very welcome change! |
 - Score: 2 |
| Comment by benb320 |
| By benb320 on 2012-09-17 20:33:03 |
| What part of Canada is he from? |
| - Score: 1 |
| RE[5]: The hardest part |
| By ssokolow on 2012-09-17 20:34:08 |
|
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.) |
| - Score: 2 |
| RE[5]: The hardest part |
| By ssokolow on 2012-09-17 20:41:01 |
|
Did they say "USB Video Class", "UVC", or something along the lines of "Designed for Windows Vista/7"? If not, they may be older designs. If so, then your problem is Windows's approach to drivers. There are some devices where they will work with one of the drivers Windows has built-in, but because of the metadata their USB microcontrollers report, you need to craft your own INF file to make Windows aware of that. |
| - Score: 2 |
| RE[6]: The hardest part |
| By ssokolow on 2012-09-17 21:59:46 |
|
Update: Here's are a couple of things on the pros and cons of UEFI and how they relate to Linux: https://www.youtube.com/watch?v=V... http://mjg59.dreamwidth.org/1123... |
| - Score: 2 |
| Pretty interesting. |
| By UltraZelda64 on 2012-09-18 00:02:15 |
|
I've played around with Visopsys a few times before, and I figured... why not give it another try, see if there's been a new release since I last tried it. There has been. Problem is, every single time I attempt to run it in VirtualBox the entire (host) machine crashes. First time, the screen just locked up. Then, two or three times after, the whole system crashed and rebooted. I found that this problem still occurs even with the older release (0.69), which I have successfully run before (though I'm not sure if it was in VirtualBox or even in a virtual machine at all). OS? openSUSE 12.2 with VirtualBox 4.1.18_OSE, so pretty damn recent. I wish there was a better virtualization program for Linux... VirtualBox seems too damn buggy and causes nothing but problems. Over the years, it still is a pain in the ass. Update: Damn. I burned both versions of Visopsys to a CD-RW, and neither one would boot on my hardware. Error initializing. But at least it ended more gracefully than VirtualBox, giving me the option to press a key to reboot the system. Edited 2012-09-18 00:15 UTC |
| - Score: 2 |
| RE[7]: The hardest part |
| By Alfman on 2012-09-18 01:04:27 |
|
ssokolow, Yea I know mjg59 isn't a big fan of UEFI, although I've only heard his take as it related to secure boot. I'll have to wait till I have more time to really follow your links. (very good find though, thanks for linking them!) Regarding webcam compatibility, I haven't a clue what the box said, only that win7 was supported, which was good enough for me (user reviews revealed linux compatibility too). I don't mind that I needed a driver - the main point is that one is available. To me, the benefit of standard drivers would mean that manufacturer drivers could be loaded in independent operating systems even if manufacturers don't specifically cater to them. It would give a new breath of opportunity to homebrew OS developers. Edited 2012-09-18 01:08 UTC |
| - Score: 2 |
| RE: Pretty interesting. |
| By Alfman on 2012-09-18 01:28:51 |
|
UltraZelda64, This is my experience: apt-get install kvm Download the cdrom image on this page: http://visopsys.org/download/ind... # I can get the cdrom to run without the installer # run (as normal user) kvm -cdrom visopsys-0.71.iso This allows you to go in and play around with some of the built in software. Does this work for you? For me installation fails... # This creates a 1GB hard drive image (optional) kvm-img create -f qcow2 viso.hd 1G # Run the installation cdrom kvm -hda viso.hd -cdrom visopsys-0.71.iso -boot d # visop wouldn't allow me to partition and install on the same boot, but after creating a partition I was able to restart kvm and run the installer "successfully" (at least it said so). # After install, run the virtual machine without the cdrom kvm -hda viso.hd For me, it just hangs there. Given that you've tested it on bare metal too, I suspect it's likely an issue with the OS itself. Edited 2012-09-18 01:33 UTC |
| - Score: 2 |
| RE[2]: Pretty interesting. |
| By UltraZelda64 on 2012-09-18 02:28:58 |
| I don't know; like I said, I did run the older version on an older Gateway machine from around 2001 (P4 1.7GHz, 256MB RAM, ATAPI). The problem machine I am trying to run it on is a Dell from around 2006 with an AMD Athlon 64 X2 Dual Core 3800+, a gig of memory and a SATA connection to all drives. If I had to guess, I bet the problem lies in the SATA interface or the BIOS, but really I have no clue. I can't remember exactly what the error was when running it directly on the system, but I think it did mention something about the drives. Still, the OS initially loaded from the CD fine, so I don't know. Anyone else able to get this OS running on a SATA-based system? |
| - Score: 2 |
| RE: The hardest part |
| By Brendan on 2012-09-18 04:12:28 |
|
> What we need is some kind of universal driver standard that can be shared across all operating systems. Ideally this would be in source form and the layer could be optimised away by the compiler. This way a driver wouldn't be written for "Windows X" but instead for the "2012 PC driver standard". The OS would implement the standard and immediately support numerous compatible hardware devices. It's a pipe dream though. For it's part, MS would never participate, and their cooperation would be pretty much mandatory. This has been attempted several times before. The most popular attempt was UDI (Uniform Driver Interface), which failed despite being backed by several large companies (including Sun/Solaris). Some OSs (e.g. Linux) had religious objections ("OMG what if we wrote drivers and Microsoft could use them!"), some OSs had security problems ("OMG binary blobs created by unknown third-party developers running at the highest privilege level because our kernel is monolithic!"), and some OSs had technical reasons for not using it (e.g. very different driver interfaces, capabilities and feature sets). The end result was that very few people wrote drivers for it because most OSs didn't support it (and then OSs that didn't have religious, security or technical reasons for avoiding it didn't bother supporting it anyway because there weren't many drivers). The ancient BIOS services are not acceptable because they're single-tasking synchronous interfaces (e.g. your OS freezes while the firmware waits until a DMA transfer completes). For exactly the same reason, UEFI is not an acceptable answer either. For a decent OS, you want to be able to be transferring data to/from disk while transferring data to/from network while transferring data to/from sound card while transferring data to/from USB; where the CPUs are all still free to do unrelated/useful work (and aren't stuck in a "while(waiting) {}" loop). - Brendan |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |