Slashdot Mirror

Heh, I know someone who refused to hire anyone but a white person based on similar reasoning to what you just mentioned (she was a Chinese woman). She found someone who fit her profile, and he was lazy and a lousy programmer. She immediately regretted her decision.

I've worked with great people of all races. Sometimes you get duds, sometimes you get Amit Singh. You might as well stereotype and say that American developers are over-entitled with the attention span of twitter: constantly needing entertainment like free food or nerf-gun-wars to stay on task.

Okay so malware might be more appropriate. See for example: http://www.kernelthread.com/publications/security/vunix.html though (albeit a bit old). Vulnerabilities exist in UNIX and a large set of things can be expected to be on a lot of other systems (eg. Apache, Perl, bash etc), so find an open interface to something and a corresponding vulnerability and away you go. Malware doesn't have to rely on peer to peer replication: they effect a server and the visitors "do it to themselves" afterwards.

Also: the dude that coined the term for virus did his research on UNIX so viruses are clearly possible on UNIX if rare.

Ok, yes, there's the "because I can" motivation behind things like hanoimania, and if you don't think that's awesome, I don't know what you're doing on Slashdot.

But there is a more serious reason this would be useful, either in C# or .NET: A managed memory OS would likely be more secure and more stable than one written in, say, C. They're also playing up the idea of having it be entirely verified. It's also nice in that if apps are all bytecode, it should be transparently portable across hardware.

Such a beast would likely not be a replacement for current OSes for a long time, because of performance. I'd love to be proven wrong here. Still, even if it comes at a heavy performance penalty, I know there are a lot of places I would gladly take an 80% performance hit for better security and stability, especially on today's hardware. In fact, that's a reason to run web apps. At the very least, there are small apps like the ragemaker which are useful despite whatever imperceptible performance penalty there is, but which there is no way in hell I'm going to run outside of that sort of sandbox. And, similarly, there's no way in hell I could expect its author to release a Linux/ARM version, but if it runs in the browser, it runs on whatever platform/OS I want.

Babies can learn and grow and become something more than they are.

What can this become? It's born a freak of nature, a frankenbaby, and really ought to be put out of its misery. I put it much more in the category of stuff like hanoimania than stuff like WebGL and Native Client -- the latter are kind of security and stability hazards now, need better user controls to avoid random websites burning even more battery life than Flash, and don't have any applications proving themselves, but could be really fucking cool later on, whereas hanoimania is really cool, but was never meant to be taken seriously.

So, seriously, why would you ever want this? Let's run through those again...

DOS games? I suppose it could work, but it's never going to be as efficient as a native DOSbox. But I guess that could be cool, and maybe even useful, if there's some old DOS app that you absolutely, positively cannot get running any other way.

Crypto libraries? There are tons of libraries for JavaScript, even crypto libraries. And even if this was the way to do it, surely there are better choices than x86 as an instruction set for something you know is going to be pure emulation -- and surely there are better APIs than running the entire thing in a VM.

Training? I don't really see it. I mean, yes, Try Ruby is awesome, and having something similar for Linux and the shell would be similarly awesome. But Try Ruby lasts about 15 minutes before it's really time to move on, there's nothing more you can do here, go download the actual software. Even Heroku seems to be deprecating their web-only approach in favor of downloadable commandline utils.

And that's if it was a fully-functional VM-in-a-browser, with decent enough performance, etc. Those are the best uses I can come up with for when it's no longer a baby, and it can't do any of those things right now. Again, the most useful things seem to be tech demo and benchmark, even if it could play Doom and run a LAMP server.

BTW, I have reasons to believe that in reality the parent is a paid advertisement for you-know-who.

doesn't slashdot have a quote feature? Could not find one except typing the <quote> tags. Awkward.

Not particularly. Also, there's <ecode> for sample code.

Because you call the command with an empty argument, then you call the rm. So the rm is executing in your interactive shell, not in the program you want to demonstrate to be exploitable.

In other words, I am exploiting the shell.

In other words, anywhere that has a "system"-type call, where a command can be assembled as a string (rather than an array of string arguments), is a potential avenue for abuse. What about my example implied the shell must be interactive?

You are mixing up typing in a command into an interactive shell and calling a shell with a parameter.

Again, no, this is not "typing in". Try the following in Ruby:

arg = "'; rm foo; #"
system "echo '#{arg}'"

The same in Perl:

my $arg = "'; rm foo; #";
system "echo '$arg'";

The same in Python:

arg = "'; rm foo; #"
import os
os.system("echo '"+arg+"'")

I could continue, but I doubt you'd find PHP to be any better about this, and I don't want to touch it. Point is, blame the language or the shell, but either way, executing shell commands this way is a bad idea. Executing them the right way is a hassle, unless you're already in the shell, but unless I'm missing something, implementing a web service in the shell is a hassle.

And that's before we start examining commandline programs for security.

I hope you see the difference between the interactive shell and...

The only real difference between an interactive shell and a noninteractive shell is the way the prompt is displayed. That's why shell scripts are so cool to begin with -- if you know how to type it into an interactive shell, you probably know how to make a basic script, and as your scripting abilities improve, those translate into increased proficiency with the shell.

Yes, I understand the difference between a command executed in the context of a shell and commandline arguments passed to a shell script ($1, $2, etc).

yes, he did not use CPAN but system calls to run other unix utilities. Like calling mailx to send an email (using a user supplied email address, wow!) and he took 3 weeks to get 1 day worth of work done.

Ew.

Not knowing ruby I don't know how it's calling external commands. If it's doing an equivalent of "sh -c $command" you need to sanitize arguments.

That depends. The same method can be used to do either way:

system "echo #{myvar}"
system 'echo', myvar

The first is vulnerable unless I trust myvar. The second is safe, assuming I trust ENV['PATH'], and if I don't, it accepts absolute paths as well.

Well not really a webservice, but what about a chatroom?

Either way.

By the way, I've seen games like tetris written in Bash, so I don't doubt it can be done. I just doubt it's sane -- it strikes me as similar to hanoimania.

This is the cool feature of shell, it does not in fact execute strings which look like they may break your system.

Neither does any other language I know.

As I said, it's the border between the two. I can combine strings as many ways as I like, and they won't jump out and eval themselves -- but if I 'eval' an untrusted string, I'm hosed. If I stay entirely within the shell, I can combine strings any way I like (though it seems slightly trickier), and they won't jump out and eval themselves -- but if I 'sh -c $foo', I'm hosed.

And of course, there are oth

They were on the left side in NeXTSTEP (screenshot). The reasoning, AFAIK, was that in left-to-right languages the user is focused more on the left-hand side of windows (at least those that contain text), and so that's where the scrollbar should be. To me this makes a lot of sense.

Hurray Apple catches up to OS X 10.2 circa 2002 in terms of the GPU composting graphics. Hurray!!!! Oh wait.... http://www.kernelthread.com/publications/appleoshistory/10.html http://en.wikipedia.org/wiki/Mac_OS_X_v10.2 Microsoft maintains it's consistent 8 year lag behind Apple, and no truth isn't a troll.

http://www.kernelthread.com/mac/vpc/images/win101.gif who ripoff who again?

The whole foundation of your argument is flawed. UNIX was not designed with security in mind. In a 1979 document titled "On the Security of UNIX", Dennis Ritchie said

"The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes."

http://www.kernelthread.com/publications/security/tunix.html

Certainly Unix as well as other OS software have come a long way in security and none of them is perfect, but to make such a false statement that Windows is bad because security was an afterthought while thinking that Unix is any different is just foolish. There have been massive internet worms for Unix in the past, there will be virii for their vulnerabilities in the future.

They steal everything from Apple and somehow, Apple is silent...

Why don't actually steal the genius idea of on the fly optimising from Apple that only optimises things a)actually used (by user), b)way fragmented and the system is really idle to do luxury things like that?

Check the "Built-in Measures in Mac OS X Against Fragmentation" section on http://www.kernelthread.com/mac/apme/fragmentation/

It is not needed on SSD but there is no such thing like "lets defrag cvs command which that old lady would never use" too. So Apple doesn't have that problem with SSD.

xnu is based on Mach 3 but it is not a microkernel http://www.kernelthread.com/mac/osx/arch_xnu.html

Open fimware

http://www.kernelthread.com/mac/osx/arch_boot.html

OSX uses a Mach kernel...

Mach is a microkernel, not a kernel. Classically, you had to run a OS "personality" on top of Mach to get a full set of kernel features (things like a filesystem, processes, and users are not found in Mach). Back when Mach was a hot topic in the mid 90s, there were POSIX and OS/2 personalities being developed.

OS/X's XNU kernel uses a combination of the Mach microkernel with the BSD kernel - they're co-equal, not a BSD "personality" on top of Mach.

... is not to be confused with Amit Singh, who also works at Google and has authored an excellent book on Mac OS X Mac OS X Internals.

OS X uses a subsystem just like Windows does for Unix compatability, it is the same conceptual system.

No, OS X is based on NextOS, which has a kernel based on Mach with a BSD subsystem that shares very, very little code with BSD.

You seem to think the POSIX subsystem in Windows isn't integrated into the Kernel in a similar fashion the way OS X does, but it is.

So no, I don't consider it a direct descendant and if you're going to call OS X a Unix, the same is going to apply to Windows because they're just too similar in how they implemented the features, the code sharing etc.

It is a BSD subsystem ontop of the kernel

and the majority of code related to the subsystem is, I'm told not really match much of BSD4.x

Hm, I wonder if that acronym for XNU came out after the SCO lawsuit.

To me, it just means OS X has gone down it's own unique path and does not wish to be a Unix.

You can surely question Apple's commitment to having a "real Unix," but remember that the BSD/Mach combo came from NeXT. Back in 1988, BSD Unix was undeniably a "real Unix" which they had to license, there was no free one available. Interesting that they integrated the Mach and BSD kernels only after BSD was free of AT&T code!

Interesting debate, thanks! I know it's an old one that's been beaten to death here and elsewhere, but it's rekindled my interest in the history of Unix and made me re-evaluate a lot of what I thought I knew about Mac OS X and BSD. I've already ordered a copy of Amit Singh's book, Mac OS X Internals.

- Nick

Ever since Ubuntu Edgy much of the low hanging fruit in speeding up the Ubuntu boot has already been taken. Looking at the bootcharts for my system since then shows remarkably little time when the CPU is idle once the base kernel has finished loading. This means that running anything more in parallel simply won't net me anything (in fact scheduler overhead and disk thrashing may in theory make things slower).

For example, there is an improvement in the time it takes for the clock to appear from "Ubuntu Dapper Flight 3 Default kernel" to "Ubuntu Feisty Herd 5 generic kernel". The Ubuntu folks worked hard to try an eliminate sleeps from their initscripts and when a sleep was unavoidable they would run other parts of the startup process in parallel. They also made changes to Xorg to prevent it (re)reading so much stuff on launch. There was also the introduction of the readahead script which tries to arrange for as much of the boot time reading to be done in one big chunk. Throughput is higher when the disk is only reading and can utilise it's readahead. An attempt is also made to try and request files in the order in which they are laid out on disk (to minimise disk seeks which hurt performance). In Feisty a move was made to using dash instead of bash for scripts because it was smaller and executes scripts faster.

The only things that seem to win me any gain over the default Ubuntu Feisty install are turning off initscripts for services I absolutely won't use (e.g. ipv4 autoconfig via avahi) and reducing the number of restricted binary driver modules being probed (I have long noticed that the only benefit that recompiling the kernel gives to boot speed is that you can simply leave out features not on your computer making the initial kernel startup where it probes for things you might not have (like which software RAID is faster) a shade faster). It is also worth noting that Ubuntu starts X quite early and continues loading services afterwards which means the gain from disabling one of these "after X" services (like CUPS) isn't so noticeable (but might mean your desktop actually starts responding to clicks a bit sooner).

Profiling the boot to try and improve the readahead takes a long time to run - the profile run seems to take three times as long as a regular boot. It could be argued that you will never gain back the extra time you waited on the profile run...

I suspect reducing the boot further will start to need more complicated procedures, perhaps reordering modprobe.conf and reducing the amount of needless reading of files. Eventually you end up having to do the same tricks as Windows/OSX - e.g. working out where the fastest part of the disk is and copying every file needed to boot there, bringing up the network cardafter the desktop has started, periodically defraging bits of the disk, prelinking...

I really think that explanation needs a whiteboard! Having read your post hand-in-hand with an overview of XNU I think I nearly "get it". There is still much confusion in my mind however.

My understanding is that the kernel of Darwin is a hybrid of a monolithic kernel (e.g. Linux / Windows) and a pure microkernel (e.g. NeXTstep), presumably this is a pragmatic performance tradeoff.

When you therefore state "kernel_task is the Mach task to which all kernel threads belong"., I assume you are describing just the Mach part of the kernel. In other words the section dedicated to fundemental things such as interprocess communication and virtual memory. I assume that higher level operations that make use of system calls such as network access would not be spawned by Mach, but by userland processes.

Does this imply that Mach is in a sense a process of itself? It sounds sufficiently weird and recursive to be vaguely right; this would explain why one can see the kernel itself in a list of running processes.

Perhaps part of the problem is that "the kernel" is a term that is too ambiguous in this context. It could be used to mean Mach, which is highly fundemental, or the much wider BSD system that exposes a familiar API that user processes can call.

Does my rambling make sense? I know very little CS, I'm just an ignorant physicist and still think preemptive multitasking and virtualisation is dark magic!

I'm seeing File/Edit/View in the very first version of Mac OS.

http://www.kernelthread.com/mac/oshistory/3.html

...you're on slashdot trying to make a point. I shall counter your extension with one of my own!

The offspring of a zebra and a horse is not a horse

Something derived from two other things, containing elements of both, is not merely one of those things.

I don't know why people are so vehement that the mach part of XNU doesn't count... but having just found the kernelthread article where Apple zealots flame the hell out of Amit Singh for saying Mac OSX isn't unix (horrors! the sky is falling!) I do believe I will give up now.

Never mind.

Another approach can be found on Amit Singhs site, where he has more than 100 implementations of Towers of Hanoi (in all kinds of languages etc): http://www.kernelthread.com/hanoi/

Another great one: HanoiMania. 111 solutions to the "Tower of Hanoi" recursive problem, some in very creative and bizarre environments (as outlined in the summary at the top).

Not true. As a maintainer of the lastest ftp NeXT freewares repository, I can see that NEXTSTEP (so mach kernel) ran on 68k, x86, PA-RISC, and SPARC platforms. Of course OpenStep existed not only for mach but also for Windows NT/95 (like the Yellow Box Rhapsody, with a better support of the broker system and OLE than Microsoft itself), SunOS and HP-UX.
Every genuine or complete NEXTSTEP 3 Apps were a bundle directory which contains 4 binaries for 680x0, x86, HPPA and SPARC (OPENSTEP bundles were more complex because the Resources content were splitted for OpenStep IB and Windows ones); and so, the file manager or the 'open' command launched the well-fitted binary when you "start" the bundle directory.
A piece of history here: http://www.kernelthread.com/mac/oshistory/7.html

It supports a few other file systems too. Including read-only on NTFS.

http://www.kernelthread.com/mac/osx/arch_fs.html

You are right that decrypted pages are not cached in memory. I'm don't think the issue of caching disk blocks applies, as XNU uses a unified buffer cache. So if the one encrypted page has the same size as a unencrypted page and each page can be encrypted indenpendently, the mechanism is roughtly the same as for normal code pages: the are loaded and evicted as needed, simply the load phase includes a decryption phase.

That is essentially what Apple has done.

No, it isn't. He's talking about a microkernel, like QNX or L4. Mach is also considered a microkernel, but OS X is not based on Mach; it is based on XNU, a hybrid kernel that consists of Mach bolted into the FreeBSD monolithic kernel, with I/O Kit thrown in for good measure.

You give performance arguments, but the speed of OX X does not imply that it uses a microkernel; quite the opposite, microkernels have been known to run significanly slower than monolithic ones, which is presumably why Apple went the hybrid route instead of using pure Mach. To be fair, Mach is rather outdated among microkernels, and "modern" microkernels like the aforementioned L4 have shown that the speed penalty might be as low as 5-10%, but the point still stands. Don't confuse simplicity of code with performance.

I find your excuse of legacy software annoying.

The subject line is a short summary of the solution that Microsoft should have implemented a long time ago---to implement a union of file systems so some files are drawn from a read-only file systems and others from a read-write file system.

See http://en.wikipedia.org/wiki/UnionFS.

Basically, the program folder has only read access to users, but unionfs of the program folder and a user folder in "Documents and Settings" would allow each user to modify content of that program folder independently. Users do not see each other's changes, and the main copy is left intact. You also don't need to be a privileged user to run that program.

Mac OS X also has it. See http://www.kernelthread.com/mac/osx/arch_fs.html.

I apologize in advance if Microsoft has already included that feature, but I would get even further irritated because there is absolutely no excuse now to make everyone administrators.

Here's what I know of and/or could find for the ones I didn't.

• Aaron Hillegas
• Adam & Tonya Engst
• Amit Singh
• Andrina Kelly
• Andy Ihnatko
• Ben Wilson
• Brent Simmons
• Dan Frakes
• Danny Goodman
• David Pogue
• Drunkenbatman
• John Gruber
• John Siracusa
• Jonathan "Wolf" Rentzsch
• Josh Wisenbaker
• Michael Bartosh
• Mike Breeden
• Nigel Kersten
• Ray Barber
• Ric Ford
• Rich Siegel (Bare Bones SW)
• Rob Griffiths
• Rosyna Keller
• Scott Knaster
• Wil Shipley (Delicious Monster)

Unfortunately, it seems that Slashdot has a limitation on the minimum number of characters per line. So I can't just create a nice, simple list, but instead need a significant amount of text to pad out the list, so that I can make it past the filters being used. But I'm still not there yet... sooner or later I will (20.4 is still too few). I'm probably going to have to type a whole lot of crap in here just to deal with the 25 names that are only a few characters each. (and I tried removing returns from the message, but it didn't seem to help at all)

He actually has a desire to recompile the kernel and not get ad hits as far as this article appears.

So all you xnu hackers, please stand up and be counted. As I recall, only three people even came close to understanding the kernel bug in the The Mac OS X Expert Challenge. As previously reported on slashdot, "Also looks like other than these guys, nobody got anywhere with the problem.". So much for the myth of the legions of ubergeeks working with Macs.

Even the parts of the OS that are most useful for tinkering were an afterthought for Apple.

FWIW, xnu from Darwin released before the Intel switch six months ago is still available for Infoworld blogers to recompile to their heart's content.

cheers- raga

You must have really liked Windows 1.0.

I suggested the use of an accelerometer on an Internet messageboard, when another user had asked for advice for building a high-end lightsaber toy. I directly got snotty remarks that it would be infringing on this guy's patent. He was then selling circuits with an accelerometer that were connected via radio-link to a PC that played sounds.

I then told him that I was building such a circuit myself and knew of other people who also had designed similiar circuits independently from eachother, because it was quite straightforward design if you know your way around electronics. I pointed out that I thought that such straight-forward patents were stealing from the community, especially if this was a software patent but that it wouldn't apply to me anyway because he was in the US and I was in Europe. For this I was banned from the msgboard, for "software piracy" (!) .. apparently the admins did not distinguish between different types of intellectual property, or they were friends with this guy. I don't know.

No, what you're saying is incorrect, and unfortunately, what many people seem to believe.

Apple and IBM sensors are similar.

*BOTH* are on the motherboard. Not sure where this "sensor on the hard drive" myth comes from.
*BOTH* use the same technology (they are MEMS sensors).
*BOTH* are manufactured by non-Apple/non-IBM companies.
*BOTH* are driven by software drivers (what else do you expect?).
*BOTH* have a private interface that is not available to third parties.
*BOTH* have been reverse engineered by third parties.

There's already support for using the IBM's sensor in Linux. The first reverse engineering was that of the PowerBook's sensor (the kernelthread.com link that you mentioned) -- way back in early 2004.

Most importantly, please don't say "Apple sensor has an API" etc. Apple certainly never made anything public about how to "use" the PowerBook/iBook/MacBook/MacBook Pro sensors. kernelthread first reverse engineered it, and then the whole idea became popular all over the net in no time.

And while we are at it, IBM started including such a sensor in ThinkPads a long time before Apple. Like Apple, they didn't make their "API" public either.

Is this the same motion detector that IBM's HDD labs came up with a few years ago?

Is this the same motion detector that IBM's HDD labs came up with a few years ago?

The column view (browser view) has been in NeXTSTEP since 1989. Apple acquired NeXT in the mid-90s. I do not say that Apple holds patent on it nor invented it (Xerox Smalltalk class browser?). I just want to say, that the column has been here for a while and it was somehow related to Apple too.

Moreover! Filtering data using a column view is also quite old. It has been used in data-warehousing as way of drilling-down. In the music player it is nothing more, nothing less: it is drilling-down through your song database. Just ask Bill Inmon or Ralph Kimball :-) It is the same to drill-down by region, store and date or by genre, artist and album. They are just different terms.

No, Apple partly "fixed" it by making Mac OS X' kernel run in one big address space, and "message passing" in the kernel now consists of plain function calls.

Not quite true. Apple inherited the monolithic Mach kernel from NeXT. NeXT in turn used the 2.5 version of Mach which was already monolithic (ie Mach and BSD were all munged together in the same kernel). More details on the history here.

Might want to review the following to better understand fragmentation and how HFS+ suffered and fights the issue...
HFS plus fragmentation

Also XFS doesn't use journalling, it is a transactional file system that ensures on disk structures are always consistent, no need for a journal.

I didn't say it. Wikipedia said so.

http://en.wikipedia.org/wiki/ZFS

Just for the record, here are the Mac OS X supported file systems;
http://www.kernelthread.com/mac/osx/arch_fs.html

I'm just going to wait on my ass for ZFS port on Linux... I'm waiting folks.. waiting... c'mon.. chop chop, lets get to work...

Which is true if you limit yourself to just the kernel and immediate surrounds. OS X includes a tad more code than that, however, and rather large portions of it were done from scratch.

To back up what you were saying http://www.kernelthread.com/mac/osx/history.html:

"It would be an understatement to say that OS X is derived from NEXTSTEP and OPENSTEP. In many respects, it's not just similar, it's the same. One can think of it as OpenStep 5 or 6, say. This is not a bad thing at all - rather than create an operating system from scratch, Apple tried to do the smart thing, and used what they already had to a great extent. However, the similarities should not mislead you: Mac OS X is evolved enough that what you can do with it is far above and beyond NEXTSTEP/OPENSTEP."

Just like you can think of XP being NTv5.1 (I think it is 1 or 01...)

...Amit Singh from IBM and kernelthread.com (slashdotted 16 times for excellent technical articles on various bits of internals of Apple hardware and Mac OS X) has his own legacy boot solution as well. From a rejected submission:

It appears that Amit Singh of IBM Almaden Research Center, of kernelthread.com and author of Mac OS X Internals, has devised a method to allow legacy, or BIOS-based, booting on Intel-based Macs, which they're calling "BAMBIOS". This means operating systems that currently only support legacy booting, such as many Linux distributions that don't yet support EFI, or things like Windows XP and the forthcoming Windows Vista (the 32-bit version of which will lack EFI support), will now be able to run on Intel-based Macs without modification (and completely legally). There is also another solution from "narf2006", described here and shown in this flickr set of photos. narf2006's solution is awaiting verification by Colin for the $12,000 pot. Time to get that MacBook Pro you've been waiting on for the best of both worlds, everyone...

So even if narf2006's solution isn't real, Amit's solution most certainly is, since he has a great deal of credibility. One way or another, we'll all be able to boot Windows directly on our Intel-based Macs.

This will be great news for people interested in Windows gaming on an Intel-based Mac (who really need the direct video access) and/or people who just want to do it NOW; however, a virtualization solution running under Mac OS X, such as VMware or Parallels, will be the real holy grail for most users. Most people don't want/need/care about the highest graphics and I/O performance; just the ability to run Windows side-by-side with Mac OS X at a speed that is more than usable, and to also have some capability to seamlessly share things like clipboards and files between the environments (as a nice VM environment would most certainly do). Not to mention not having to reboot.

In any case, even dual booting will be a welcome capability. It remains to be seen how convoluted the process is...

Also, I just spoke with Colin Nederkoorn (the guy running the contest) moments ago, and narf2006's solution has NOT been submitted to him yet. He said that narf2006 said he's "cleaning it up" and will be submitting it "later this week". So, no one, including Colin, has actually seen this solution working yet. Also, he apparently hasn't been in communication with Amit on the BAMBIOS solution as yet...

Wow. Are they sure they can't get DOS and OS/2 involved in that process somehow?

I'm reminded of this guy who runs several dozen operating systems on a PowerBook.

I could also swear I once saw a screenshot of someone running a DOS box inside a virtual Windows session inside a virtual Linux session on a Mac host, or some permutation thereof, but I couldn't begin to guess where to find it.

In computing, virtualization is the process of presenting a logical grouping or subset of computing resources so that they can be accessed in ways that give benefits over the original configuration. This new virtual view of the resources is not restricted by the implementation, geographic location or the physical configuration of underlying resources. Commonly virtualized resources include computing power and data storage.

A good example of virtualization is modern symmetric multiprocessing computer architectures that contain more than one CPU. Operating systems are usually configured in such a way that the multiple CPUs can be presented as a single processing unit. Thus software applications can be written for a single logical (virtual) processing unit, which is much simpler than having to work with a large number of different processor configurations.

A new trend in virtualization is the concept of a virtualization engine which gives an overall holistic view of the entire network infrastructure.

Virtualization is a broad term that refers to the abstraction of resources across many aspects of computing. Some common applications of virtualization are listed below.

A virtual machine is an environment which appears to a "guest" operating system as hardware, but is simulated in a contained software environment by the host system. The simulation must be robust enough for hardware drivers in the guest system to work. With paravirtualization, the virtual machine does not simulate hardware but instead offers a special API. Operating System-level Virtualization is virtualizing a physical server at the operating system level, enabling multiple isolated and secure virtualized servers on a single physical server. Partitioning is the splitting of a single, usually large, resource (such as disk space or network bandwidth) into a number of smaller, more easily utilized resources of the same type. This is sometimes also called "zoning," especially in storage networks. Aggregation, spanning, or concatenation all combine multiple resources into larger resources or resource pools. For example, symmetric multiprocessing combines many processors; RAID and volume managers combine many disks into one large logical disk; RAIN and network equipment uses multiple links combined to work as though they offered a single, higher-bandwidth link. At a meta-level, computer clusters do all of this.

Wikipedia article

and another great article with an introduction to Virtualization

or more precisely, 4.4BSD/Mach VM.

Plenty more info here: http://www.kernelthread.com/mac/osx/arch_xnu.html although not the definitive source, but interesting known the less.

OS X certainly "uses" a microkernel, Mach, but it's not used as a microkernel.

You can, with AMS2HID.

Reminds me on a sed script from http://www.kernelthread.com/hanoi/

(I tried to paste it, but it contained too many juck characters) http://www.kernelthread.com/hanoi/html/sed.html

Apparently it solves the towers of hanoi problem. Pretty impressesive. I have no idea how any human can keep track of all that noise.

Reminds me on a sed script from http://www.kernelthread.com/hanoi/

(I tried to paste it, but it contained too many juck characters) http://www.kernelthread.com/hanoi/html/sed.html

Apparently it solves the towers of hanoi problem. Pretty impressesive. I have no idea how any human can keep track of all that noise.

If you have any interest at all in OS X, you should check out Amit Singh's article on it at http://www.kernelthread.com/mac/osx/. It doesn't go into detail, but it drops enough names to give you a running start. Apple's "Conceptual" documentation is very good too.