There is some free software called Morph X that does face morphing. It is not as advanced as Morph was, but it could do the trick. Plus, the source code is available and free, so you could tailor the application to your needs.
Openfirmware is based around an somehow similar idea: the firmware contains a Forth interpreter - a tiny virtual machine that can run programs. If I remember well, you can even write simple drivers if F-code and have them handle devices until the real OS starts.
Running something like VM-ware at this stage makes little sense. The goal of the BIOS is to serve as a bootstraping system for the actual OS. Putting the full OS would increase the cost of the BIOS system and decrease flexibility. The original Macintoshes had a large part of the OS in ROM, but this has been abandonned years ago (they use Openfirmware now).
Actually one Macintosh had a full boot disk in ROM (the Macintosh classic), you could mount this volume and boot from it. It contained a full OS including an Appleshare client so you could boot and run the computer without any disk...
This is dealing with the ROC, not the PRC. The PRC claims the ROC is a renegade province, the ROC is just sitting back with the US covering its ass waiting to be able to truly flip the PRC off.
Actually, not anymore, since the last elections, the old party line "we will take back the mainland" has been abandonned. The new plan is to become a independant country, which has angered the PRC governement a lot (even more that the invasion stance) the idea that China is not one cannot be tolerated...
If I remember well (somebody correct me), Macintosh Nubus cards had something like this. The card's ROM memory contained information about the card and then a low level driver. This meant that you could plug in a video card and it worked without having to resort a common denominator (say VGA). At that time, most PCs had trouble figuring out on what DMA the soundblaster was sitting on.
Nubus was the proprietary bus interface used by Apple in the Mac II series. It was finally abandonned when Apple adopted PCI for internal extension. This approach was very good for plug and play, but very expensive.
I think that loading drivers inside peripheral is very reasonable: first it would be expensive and second how many drivers would there be? If you build a PCI card, this would mean you would need drivers for different plateforms (xx86, PowerPC,Sparc and probably others) and different OSes. This means a lot of combinations. More reasonable ideas IMHO are:
Have busses where you can query the device for its type and id and also the assumed bus speed. And have devices tell their type. Serial ports are nightmarish in this respect. The trick to figure out the speed is a hack (this is the reason for the AT sequence, the modem could recognised the AT pattern at any rate and thus guess the rate). Also the system cannot figure out what is connected to a serial port in a reliable fashion.
Generic drivers. Many new USB components (small disks, mices, keyboards) do not need any drivers because they export a standardized interface.
Flexible drivers. This is an intersting feature of the driver system of Darwin / OS X, IO/kit. Drivers are object oriented. A PCI SCSI card drivers is basically two objects: one that inherits from a PCI class, and another that inherits from a SCSI controler class. This does not remove the need for drivers but should help make them simpler: a driver would only contain code that handles stuff that is specific to the component.
Here's where I think he's wrong. What he's describing here is how it works in Darwin (and NT) yes, but only because they moved those systems back into kernel space. But the way it works on a proper microkernel system (like the HURD) doesn't just run these things in a separate address space but at a different privilege level, so instead of crashing the kernel you simply crash a daemon and have to restart it. This does mean drawing the lines a little differently than they have, of course.
The problem, as I understood (can't remember where I read this) it is that in practice restarting the deamon that handles the swap disk is very tricky. Assume demon A is responsible for the swap infrastructure. If A crashes, the kernel has to restart it - but it has to do this without paging in or out any page (swap is not available anymore). Demon A must probably be reloaded from the file-system - but by design a micro-kernel should not know about file-systems.
I don't know if the Hurd can manage this kind of recovery. What I'm sure about is that such an recovery mechanism would be complex - and implementing it hard work.
I'm not convinced that the effort needed to enforce this kind of fault tolerance would be reasonable - on one hand you could tolerate failures of the Unix personality, on the other this would add complexity to both the kernel (to be able to restart demons/servers) and to the servers (they would need to be able to restore their state at restart) - IMHO, for a single OS machine, it sounds overkill.
One case where I think such an architecture makes a lot of sense is if you implement many virtualised OSes on one single machine. For instance you would have n logical servers that share one micro-kernel - in this case, if one of the virtual servers fails, the others are not affected.
hey both live in kernel space. So why are they using Mach? I dunno.
Software enginiering. Even if you compile everything in the same address space, it makes sense to separate functionality. This way, you keep a nice design, but do not pay the performance price for context switches. Also separated address spaces do not reduce the chances of a kernel crash. Even if the BSD layer was in its own address space, a crash would still bring down the Mach kernel, as part of the BSD layer handles disks and so swap devices.
Also Mach offers functionalities that the BSD layer does not. Some parts of Mac OS X rely directly on Mach facilities - for instance for distributed objects. Posix threads are directly mapped to Mach threads.
Mklinux is a joint project between OSF and Apple. It is an implementation of Linux on top of Mach 2.5 (Darwin is based on Mach 3). It mostly ran on early PPC machines (x100 models, the so called Nubus Powermacs) Althought MkLinux was discontinued it served as a proof of concept that you could run a microkernel architecture on a Mac. Contrary to Darwin, MkLinux has the linux layer and the Mach layer in different address spaces.
... being able to move the mouse pointer between computers (assuming these are separate computers, not just multiple monitors); I assume this indicates some sort of network-transpart clipboard (and that the user is signed onto both computers). cool, that.
Having mouse pointers that can go on other screen can be intersting, but also very confusing: there might be two mouse pointers on one screen. So you would need a way to distinguish both pointers and also an interface that can handle multiple selections, for instance this would mean two active windows (imagine the problem with focus on move). This would definitely require a serious rethinking of the way GUI work.
I mean, this is getting old. Singe OS X came out there seems to be such an article once a week someplace or another. This leads to the same discussions, and is really not constructive.
What I find more intersting is why is the slashdot crowd so obsessed with this idea? If apple did the switch to intel processors do people on slasdot really belive that:
Apple hardware would be less expensive?
OS X would run on commodity (non Apple) hardware?
If OS X would run on commodity hardware, the pricetag would not be high or the hardware support low?
I find it quite ironic that the crowd that touts open source software seems to have an ongoing dreams of running proprietary software. The funniest thing is, most elements for building an open source variant of OS X are around:
The code of darwin, the kernel, is available and compiles on IA32, albeit in a limited fashion.
The Cocoa libraries have an open source clone: Gnsustep.
Re-implementing Carbon according to the spec, which is publicly available and quite clear would clearly be less work than project WINE.
You can already do this on a G4 by using Altivec, except you can work with 128 bit chunks. In fact, if I remember well, the internal datapath of the G4 is 128 bits wide. The performance bottleneck is more in the memory bus.
I believe there are factors other than the pointer size. For instance, a 64-bit CPU should be able
to perform operations on two 32-bit values at once by simply placing operands side-by-side in
one 64-bit register...
Indeed, but using Altivec, a current G4 can already handle 4 32-bit values in one cycle (all altivec instructions work on 128 bit blocks).
Also, 64-bit registers should allow high-precision floating point operations to be handled natively,
rather than tying up multiple registers for one value.
In current PPC architectures, the FP registers are already 64 bits wide.
(although, if you want the most speed, you'll eventually need to upgrade to the 64-bit versions of your apps).
Why would code that uses 32 bit pointers be slower than code that uses 64 bit pointers? Having 64 bits pointers is needed to address more than 4 gigabytes, but why would there be a performance gain? I would think that longer pointers imply moving more data into the CPU, and therefore would consome more memory bandwidth. Am I missing something?
One format that seems to be supported by both Mac OS X and Linux is the UDF format. This format is
Standard.
Designed for large data sets (1 GB).
Designed for large file transfers.
That said, UDF is usually used in DVDs and I don't know if and how a firewire drive can be formatted in UDF, but it might be worthwhile to check it out.
I would have preferred an XML data format, but at least a text format means I can manage it using cvs (I don't want to buy a.mac account).
The text encoding also seems to be UTF-8.
Does anybody know if this format is used somewhere else or even documented?
Then again, I imagine they could do a user-friendly version:
No, not this way! did you count the screws? I told you to do it! Don't hit your fingers with the hammer! Now the cat is struck under... Why didn't you read the manual?
Some people would argue that this device exists already, it is called a girlfriend...
Is there any reason to believe that AltiVec is better than Intel's or AMD's vectorized instruction set?
The main difference between Altivec and MMX (can't say for AMD technology), is that altivec has its own registers, so that altivec instruction can run in parallel with normal instructions.
There is more info on Apple's developer site.
Well, I depends on your point of view. I already get a lot of spam on how to evade US tax laws - or how to get certains US permits, etc. Guess what, I don't live in the US. Getting messages from US politicians would certainly be spam in my book.
At least, viagra works - the same cannot be said from politicians.:-)
The core problem is always the same "it's not spam if it is sent to the right people". The problem is, spammers are not very good at selecting the right people.
If you add up all the people that cannot vote in the US, don't care, don't want to get political stuff at their work address or hate the guy anyway - it makes quite a lot of people that will get unsollicited e-mail, eg will be spammed.
Political messages can be handled in the same way that legitimate communications from organisations: by using an opt-in mechanism.
There is an intersting discussion about this in the register. To summarise, it makes little sense for Apple to design and build its own phone - a partnership with Sony and Ericson would be more reasonable. Designing and builind a portable phone is much more expensive that building a MP3 player.
All Apple wants is to integrate the phone into their digital hub.
The reason many carbon applications have trouble with non HFS file-systems is probably that they use Resource Manager functions that have been deprecated. The system emulates the resource forks, but its internal are very different.
The original point is well-taken, in that Mac users are more often than not die-hard Apple users and as such are more likely to view Apple
favorably, independent of the service they receive.
Do you have any data to back this up? A lot of people have wierd ideas on mac users. I agree that
the evangelists tend to make a lot of noise, but there are not exactly representative. Saying that mac users are die hard, unobjective zealots that suffer from cognitive dissonance sounds to me at best as a gross generalisation.
Most mac users I know are mostly people who know (or want to know) little on computers and want the system to just work. If they are not satisfied with something, they will say it. My mom's (yes she has a iMac) view will not shatter if she complains about stuff - as a matter of fact, she tends to complain a lot.
The few people I know who are strong mac fans tend also to be vocal in critizing Apple because they are fans.
As they identify more with the product, they are also more genuinely disapointed when it fails.
They have very high (unreasonable I would say) expectation on Apple products.
Apple tends to listen to some extent to those people. I never heard (might be wrong) of Dell changing a design because of popular demand.
So while I agree that Apple's target andience is different from Dell (they cater different markets), I'm far from convinced that this crowd is so easy to satisfy for tech support, as it included a large proportion of computer illiterate people and a bunch of loud mouths that complain a lot.
Slashdot Mirror
There is some free software called Morph X that does face morphing. It is not as advanced as Morph was, but it could do the trick. Plus, the source code is available and free, so you could tailor the application to your needs.
Indeed, in fact it was build based on a measure of the earth circumference from Pole to Equator (via Paris).
Running something like VM-ware at this stage makes little sense. The goal of the BIOS is to serve as a bootstraping system for the actual OS. Putting the full OS would increase the cost of the BIOS system and decrease flexibility. The original Macintoshes had a large part of the OS in ROM, but this has been abandonned years ago (they use Openfirmware now).
Actually one Macintosh had a full boot disk in ROM (the Macintosh classic), you could mount this volume and boot from it. It contained a full OS including an Appleshare client so you could boot and run the computer without any disk...
I tried it on a Powerbook 667. It works - menu navigation is kind of weird, but no fuss about regions.
Nubus was the proprietary bus interface used by Apple in the Mac II series. It was finally abandonned when Apple adopted PCI for internal extension. This approach was very good for plug and play, but very expensive.
I think that loading drivers inside peripheral is very reasonable: first it would be expensive and second how many drivers would there be? If you build a PCI card, this would mean you would need drivers for different plateforms (xx86, PowerPC ,Sparc and probably others) and different OSes. This means a lot of combinations. More reasonable ideas IMHO are:
I don't know if the Hurd can manage this kind of recovery. What I'm sure about is that such an recovery mechanism would be complex - and implementing it hard work.
I'm not convinced that the effort needed to enforce this kind of fault tolerance would be reasonable - on one hand you could tolerate failures of the Unix personality, on the other this would add complexity to both the kernel (to be able to restart demons/servers) and to the servers (they would need to be able to restore their state at restart) - IMHO, for a single OS machine, it sounds overkill.
One case where I think such an architecture makes a lot of sense is if you implement many virtualised OSes on one single machine. For instance you would have n logical servers that share one micro-kernel - in this case, if one of the virtual servers fails, the others are not affected.
Also Mach offers functionalities that the BSD layer does not. Some parts of Mac OS X rely directly on Mach facilities - for instance for distributed objects. Posix threads are directly mapped to Mach threads.
Mklinux is a joint project between OSF and Apple. It is an implementation of Linux on top of Mach 2.5 (Darwin is based on Mach 3). It mostly ran on early PPC machines (x100 models, the so called Nubus Powermacs) Althought MkLinux was discontinued it served as a proof of concept that you could run a microkernel architecture on a Mac. Contrary to Darwin, MkLinux has the linux layer and the Mach layer in different address spaces.
As for a clipboard that is shared between machines, this already exists.
I used headerdoc to document a C++ project I did on Solaris. Not very impressive, and I did not change the perl source code, but it was usefull.
What I find more intersting is why is the slashdot crowd so obsessed with this idea? If apple did the switch to intel processors do people on slasdot really belive that:
I find it quite ironic that the crowd that touts open source software seems to have an ongoing dreams of running proprietary software. The funniest thing is, most elements for building an open source variant of OS X are around:
- The code of darwin, the kernel, is available and compiles on IA32, albeit in a limited fashion.
- The Cocoa libraries have an open source clone: Gnsustep.
- Re-implementing Carbon according to the spec, which is publicly available and quite clear would clearly be less work than project WINE.
So what gives?You can already do this on a G4 by using Altivec, except you can work with 128 bit chunks. In fact, if I remember well, the internal datapath of the G4 is 128 bits wide. The performance bottleneck is more in the memory bus.
Having 64 bits pointers is needed to address more than 4 gigabytes, but why would there be a performance gain? I would think that longer pointers imply moving more data into the CPU, and therefore would consome more memory bandwidth. Am I missing something?
You are right, I misread, I mixed up UFS and UDF. Silly-me.
Typo, UDF supports 1 TB, not 1GB.
- Standard.
- Designed for large data sets (1 GB).
- Designed for large file transfers.
That said, UDF is usually used in DVDs and I don't know if and how a firewire drive can be formatted in UDF, but it might be worthwhile to check it out.Does anybody know if this format is used somewhere else or even documented?
Well, I depends on your point of view. I already get a lot of spam on how to evade US tax laws - or how to get certains US permits, etc. Guess what, I don't live in the US. Getting messages from US politicians would certainly be spam in my book.
At least, viagra works - the same cannot be said from politicians. :-)
The core problem is always the same "it's not spam if it is sent to the right people". The problem is, spammers are not very good at selecting the right people.
If you add up all the people that cannot vote in the US, don't care, don't want to get political stuff at their work address or hate the guy anyway - it makes quite a lot of people that will get unsollicited e-mail, eg will be spammed.
Political messages can be handled in the same way that legitimate communications from organisations: by using an opt-in mechanism.
There is an intersting discussion about this in the register. To summarise, it makes little sense for Apple to design and build its own phone - a partnership with Sony and Ericson would be more reasonable. Designing and builind a portable phone is much more expensive that building a MP3 player. All Apple wants is to integrate the phone into their digital hub.
The reason many carbon applications have trouble with non HFS file-systems is probably that they use Resource Manager functions that have been deprecated. The system emulates the resource forks, but its internal are very different.
Most mac users I know are mostly people who know (or want to know) little on computers and want the system to just work. If they are not satisfied with something, they will say it. My mom's (yes she has a iMac) view will not shatter if she complains about stuff - as a matter of fact, she tends to complain a lot.
The few people I know who are strong mac fans tend also to be vocal in critizing Apple because they are fans.
So while I agree that Apple's target andience is different from Dell (they cater different markets), I'm far from convinced that this crowd is so easy to satisfy for tech support, as it included a large proportion of computer illiterate people and a bunch of loud mouths that complain a lot.