There's a good reason why people don't write about VM systems often; the combination of writing skill and the ability to understand modern VM is extremely rare.
Take most, if not all, of what the article discusses with a large grain of salt. Everything, from his history (did Microsoft invent demand paging? Hardly) to his terminology is flawed.
Just reading the first 40 comments or so here reveals that VM remains one of those "black magic" areas, where reason is overcome by superstition and people will assert the most ridiculous, irrational and unsupportable things. Regrettably, the contents of this article do nothing to improve the situation.
Just to echo what others have said; find somewhere that's not "home", but with network connectivity. For that matter, find several and cycle through them.
For example, when I was working for a small startup in Atlanta, I was living in Berkeley, CA. I'd pack my laptop and a book, and hike up the hill to Wall Berlin (RIP). Free wireless, interesting people and scenery, cheap food; all good. On better days, I'd take my Ricochet (RIP) out into a park and work under the trees.
Obviously being in a university town helps a lot, but with the push to get wireless into more cafes it shouldn't be too hard to find somewhere that's not-home and not-office that will let you work.
OKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:
-On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up.... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.
-Hopefully with a simple recompile on NetBSD i386/etc. So for companies that have the sense to open-source their drivers, this is a shortcut to using them on NetBSD without rewriting the code itself for a new API.
No. This post, and the work it references, suggest nothing of the kind.
The work to date presents interfaces to userspace that look vaguely like the MacOS framebuffer and HID system. There is no kernel infrastructure that resembles IOKit, and no practical way that you could implement it without pulling in the existing IOKit code more or less wholesale.
Just for starters, IOKit is built heavily on C++ class inheritance, and runtime use of IOKit depends on the MacOS X kernel linker and the XML parser in the KEXT tools. None of this is implemented.
For similar reasons, a "simple recompile" isn't going to cut it.
Yep. As others have pointed out, it's also a shortcut to letting the Quartz server binaries from OS X run on NetBSD/PPC (just like X11 needs to be built to talk to the hardware through standard UNIX APIs or direct rendering modules, Quartz needs to be able to talk to the hardware through IOKit), but Apple's EULA probably bars that, so I don't see that as bragging rights. Drivers are third-party code, so they're not governed by Apple's licensing.:)
Running the Window Server isn't very useful by itself. You're going to get un-accelerated video at best (since you can't load the chipset-specific (NDRV) drivers), and you're missing ATSServer (font server), PBS (pasteboard server), LoginWindow, coreservicesd, lookupd, SecurityServer, SystemUIServer, &c.
MacOS X is a very highly integrated system; there are a lot of pieces that all need to be running and talking together for a useful application to do real work. By the time you have all this in place, you've basically replicated MacOS X, and you could just have walked out and bought it, then gotten on with some useful work instead.
This means that there are a couple of crufty stubs that look like the framebuffer and HID drivers.
Replicating the entire IOKit infrastructure would require, well, the entire IOKit infrastructure. Which could be done, since it's all open-sourced, but would be a lot of work.
If you "dumbed" this down to "plain old english", it would be just too painfully obvious that it's crap. In being so maddeningly opaque, the paper tries to avoid that, I would allege.
If his math is anything like his grammar, you can basically write it off straight away. And if it's not, it's still impossible to work out what he's really trying to say since he's not communicating with any sort of precision.
Whilst optimised for use with CVS repositories, you might want to consider CVSup.
ftp.cdrom.com never ran Linux
on
Slashdot Tweaks
·
· Score: 1
It was briefly (many years ago) a Sparcstation 1, but it's been a FreeBSD box for years. The machine itself is never "slow"; it saturates its 100Mbps link on a 24x7 basis.
This is, of course, why Microsoft use Apache on an open-source operating system ( FreeBSD) on their massive Hotmail cluster. You can verify that here. Nobody, and I mean nobody, is pushing these servers to their limits in a production environment. When it comes down to it, the key issues are flexibility and reliability, and there you'll find that Apache is the market leader for a very good reason.
FreeBSD is too big, and it changes too fast for a single "changelog" file to really cover it all. If the summary of changes in the release notes isn't detailed enough for you, the next stop is the CVS commit logs. Everything is there, albeit not necessarily in a format that's the easiest to recover.
If Linux(x86) binaries can run native on Linux(x86) and, by using Ixrun library interpretation, run natively on FreeBSD,
FreeBSD does not use the (inferior) system call emulation technique that lxrun uses, rather it supports alternate ABI models based on the individual binary's original platform. This basically translates to as-fast-as-native (or faster, in some cases) performance. In contrast, lxrun depends on signal delivery to notify the wrapper of an attempted system call. This technique is elegant and portable, but imposes a severe performance penalty. It also makes emulating many system functions difficult if there is not a direct native ABI equivalent.
Don't confuse the FreeBSD (and NetBSD/OpenBSD) ABI emulation with the very much inferior lxrun; the two are quite different animals.
Just "for reference", FreeBSD currently supports gigabit adapters based on the Tigon chipset (eg. those from 3Com, Alteon, etc.). Initial benchmarks show a useable TCP bandwidth over 500Mbps and UDP bandwidth over 800Mbps. For a server feeding a gigabit-capable switch, this is a useful improvement over 100Mbps ethernet.
Given that current pricing on fibre-based cards is well under $500, expect to be seeing Gb ethernet making a real play very soon.
Slashdot Mirror
See http://niap.nist.gov/cc-scheme/st/ST_VID4012.html
There's a good reason why people don't write about VM systems often; the combination of writing skill and the ability to understand modern VM is extremely rare.
Take most, if not all, of what the article discusses with a large grain of salt. Everything, from his history (did Microsoft invent demand paging? Hardly) to his terminology is flawed.
Just reading the first 40 comments or so here reveals that VM remains one of those "black magic" areas, where reason is overcome by superstition and people will assert the most ridiculous, irrational and unsupportable things. Regrettably, the contents of this article do nothing to improve the situation.
= Mike
"Scott's driver" is actually my driver, albeit with considerable input from Scott after I moved on.
http://people.freebsd.org/~msmith/RAID#adaptec
Likewise, the OpenBSD aac(4) driver is based on the FreeBSD aac(4) driver (check the copyrights if you care).
= Mike
Be at:
http://developer.apple.com/wwdc/descriptions/in
Just to echo what others have said; find somewhere that's not "home", but with network connectivity. For that matter, find several and cycle through them.
For example, when I was working for a small startup in Atlanta, I was living in Berkeley, CA. I'd pack my laptop and a book, and hike up the hill to Wall Berlin (RIP). Free wireless, interesting people and scenery, cheap food; all good. On better days, I'd take my Ricochet (RIP) out into a park and work under the trees.
Obviously being in a university town helps a lot, but with the push to get wireless into more cafes it shouldn't be too hard to find somewhere that's not-home and not-office that will let you work.
No. This post, and the work it references, suggest nothing of the kind.
The work to date presents interfaces to userspace that look vaguely like the MacOS framebuffer and HID system. There is no kernel infrastructure that resembles IOKit, and no practical way that you could implement it without pulling in the existing IOKit code more or less wholesale.
Just for starters, IOKit is built heavily on C++ class inheritance, and runtime use of IOKit depends on the MacOS X kernel linker and the XML parser in the KEXT tools. None of this is implemented.
For similar reasons, a "simple recompile" isn't going to cut it.
Running the Window Server isn't very useful by itself. You're going to get un-accelerated video at best (since you can't load the chipset-specific (NDRV) drivers), and you're missing ATSServer (font server), PBS (pasteboard server), LoginWindow, coreservicesd, lookupd, SecurityServer, SystemUIServer, &c.
MacOS X is a very highly integrated system; there are a lot of pieces that all need to be running and talking together for a useful application to do real work. By the time you have all this in place, you've basically replicated MacOS X, and you could just have walked out and bought it, then gotten on with some useful work instead.
This means that there are a couple of crufty stubs that look like the framebuffer and HID drivers.
Replicating the entire IOKit infrastructure would require, well, the entire IOKit infrastructure. Which could be done, since it's all open-sourced, but would be a lot of work.
If you have a Macintosh involved, you don't even need the crossover. The interfaces autodetect and cross over for you.
.local.
Of course, with MacOS and Rendezvous, you don't need to run any "network wizard" either. You plug the machines in. They're "just there" as
The Nexus BBS developed by the South Australian Department of Education featured a multiuser chatroom that did this back in the mid-late 1980s.
Nice to see MIcrosoft continue to "innovate".
I've been a regular user of the Lamy Safari since my highschool days. You can get them (and ink for Lamy pens) from Swisher Pens.
If you "dumbed" this down to "plain old english", it would be just too painfully obvious that it's crap. In being so maddeningly opaque, the paper tries to avoid that, I would allege.
If his math is anything like his grammar, you can basically write it off straight away. And if it's not, it's still impossible to work out what he's really trying to say since he's not communicating with any sort of precision.
Whilst optimised for use with CVS repositories, you might want to consider CVSup.
It was briefly (many years ago) a Sparcstation 1, but it's been a FreeBSD box for years. The machine itself is never "slow"; it saturates its 100Mbps link on a 24x7 basis.
This is, of course, why Microsoft use Apache on an open-source operating system ( FreeBSD) on their massive Hotmail cluster. You can verify that here. Nobody, and I mean nobody, is pushing these servers to their limits in a production environment. When it comes down to it, the key issues are flexibility and reliability, and there you'll find that Apache is the market leader for a very good reason.
If Hotmail couldn't do it with Microsoft's backing, I can't imagine it being worthwhile here without it.
FreeBSD is too big, and it changes too fast for a single "changelog" file to really cover it all. If the summary of changes in the release notes isn't detailed enough for you, the next stop is the CVS commit logs. Everything is there, albeit not necessarily in a format that's the easiest to recover.
FreeBSD does not use the (inferior) system call emulation technique that lxrun uses, rather it supports alternate ABI models based on the individual binary's original platform. This basically translates to as-fast-as-native (or faster, in some cases) performance. In contrast, lxrun depends on signal delivery to notify the wrapper of an attempted system call. This technique is elegant and portable, but imposes a severe performance penalty. It also makes emulating many system functions difficult if there is not a direct native ABI equivalent.
Don't confuse the FreeBSD (and NetBSD/OpenBSD) ABI emulation with the very much inferior lxrun; the two are quite different animals.
Just "for reference", FreeBSD currently supports gigabit adapters based on the Tigon chipset (eg. those from 3Com, Alteon, etc.). Initial benchmarks show a useable TCP bandwidth over 500Mbps and UDP bandwidth over 800Mbps. For a server feeding a gigabit-capable switch, this is a useful improvement over 100Mbps ethernet.
Given that current pricing on fibre-based cards is well under $500, expect to be seeing Gb ethernet making a real play very soon.
Nice of him to forget the 500+ FreeBSD systems at Hotmail.
... as you've handily demonstrated.
Linux is a desktop operating system; ask Linus, or any of your other advocates. What you need is a server operating system.
Like this.
Funny, I wonder what this 4-way Xeon box behind me is running then....
"Anything goes"? Linux is controlled by *one*person*.
Faugh.