Actually, it would be relatively easy to implement a generic driver interface - simply move all hardware-specific drivers into hypervisor-based firmware (of course, there would have to be a mechanism for the firmware to load drivers from a disk or option ROM) that provides an abstract interface for each type of device, and only have generic drivers (for the abstract firmware interface) in operating systems. Lots of operating systems run under paravirtualization, so why not go one step further and stop running operating systems on the bare metal completely? It would certainly make things a whole lot simpler, and there would be no significant disadvantages that I can see other than having to throw out pretty much all existing operating-system-based drivers.
I don't think that is a good idea. It's not as if autism is all deficits with no beneficial traits (if it weren't for certain autistic traits, I think that we'd probably still be living in caves). I think that it would be dangerous to try to eugenically select out autistic traits like that, especially since autism is becoming less and less maladaptive due to better understanding and better technology.
I strongly believe that this is the case. It looks like autism (or at least "non-syndromal" autism) is present from brain formation, and has multiple causal factors for each individual (and each autistic probably has a somewhat different set of causal factors). Because of the lack of a single cause, and the nature of some of the neurological atypicalities involved, not to mention the fact that autism appears to affect fundamental properties of the personality such as compartmentalization and sense of self, it appears that a non-destructive "cure" for autism is basically impossible. Autistics aren't impaired typical individuals, but something else entirely. Even a prenatal test is unlikely, because there could very well be hundreds of different mutations that contribute to autism, and most of these probably also occur in non-autistics as well.
Actually, a classical definition of autism, the way Leo Kanner or Hans Asperger defined it, excludes cognitive impairment, and is a condition of developmental delay at most (however, many autistics have relatively little developmental delay), not developmental stasis. Go read Leo Kanner's papers - most of his patients who weren't sent to institutions did reasonably well, but still had some difficulties, as adults. I don't actually think that a strict classical definition of autism is the one that should be used, though - autistics can have cognitive impairment, but autism should be defined by atypical thought processes rather than cognitive impairment, and individuals with severe cognitive impairment should usually not be considered diagnosable with autism.
Most modern Unices don't need a sound server, because they have a mixer built into the sound driver. Linux is the only commonly-used Unix that still has a single-open sound driver, as far as I know.
I would be very surprised if Linux, which would be a soft realtime kernel at best, would have better latency than QNX, which is a hard realtime system specifically optimized for latency and determinism. I could see how Linux could have have better throughput, but not better latency.
I think a better idea would be to remove all awareness of hardware specifics (other than the core of the CPU instruction set) from operating systems entirely, and move it into firmware. This firmware would contain a "low-level" driver for each installed device, and would present a consistent abstract interface for each device class. Operating systems written for this firmware would have a single "high-level" driver for each device class, written for the firmware's interface, and a single firmware driver would work on all operating systems written for the firmware.
The drivers in the firmware would be relatively minimal, and would basically just "translate" between the hardware's interface and the abstract interface seen by the OS. The firmware interfaces would be low-level, and comparable in exposed functionality to hardware interfaces, although they would be designed to be easily implemented in software (in other words, something like the interfaces presented by e.g. Xen). Because devices of a particular type may vary in capabilities, there would have to be some way to specify "extensions" to the interface (kind of like OpenGL or X11), but there would be a minimum set of functionality for each device class, guaranteed to always be present.
Besides putting all compatible operating systems on an equal footing with regards to hardware support, this arrangement would have another benefit. If the firmware abstracts away certain parts of the CPU in addition to abstracting away I/O device specifics, it would make all compatible operating systems inherently paravirtualizable.
It annoys me when Linux zealots claim that an amorphous kernel is superior to a modular one. It isn't all that much harder to write binary-only drivers for Linux (just write a wrapper and only distribute source for it), and an amorphous kernel would be harder to maintain than a modular one (it is possible to rip an entire module out and replace it with a completely different implementation, as long as the replacement has the same interface).
Too many free software developers seem to think that source is a substitute for good design. It doesn't matter what the license is, be it free, proprietary, or whatever - all complex software should be modular (especially operating system cores).
(and if anyone is thinking of claiming that Linux is modular because it is possible to dynamically load kernel object files, don't bother - modularity is more about separation of components than run-time loading)
Slashdot Mirror
Actually, it would be relatively easy to implement a generic driver interface - simply move all hardware-specific drivers into hypervisor-based firmware (of course, there would have to be a mechanism for the firmware to load drivers from a disk or option ROM) that provides an abstract interface for each type of device, and only have generic drivers (for the abstract firmware interface) in operating systems. Lots of operating systems run under paravirtualization, so why not go one step further and stop running operating systems on the bare metal completely? It would certainly make things a whole lot simpler, and there would be no significant disadvantages that I can see other than having to throw out pretty much all existing operating-system-based drivers.
I don't think that is a good idea. It's not as if autism is all deficits with no beneficial traits (if it weren't for certain autistic traits, I think that we'd probably still be living in caves). I think that it would be dangerous to try to eugenically select out autistic traits like that, especially since autism is becoming less and less maladaptive due to better understanding and better technology.
I strongly believe that this is the case. It looks like autism (or at least "non-syndromal" autism) is present from brain formation, and has multiple causal factors for each individual (and each autistic probably has a somewhat different set of causal factors). Because of the lack of a single cause, and the nature of some of the neurological atypicalities involved, not to mention the fact that autism appears to affect fundamental properties of the personality such as compartmentalization and sense of self, it appears that a non-destructive "cure" for autism is basically impossible. Autistics aren't impaired typical individuals, but something else entirely. Even a prenatal test is unlikely, because there could very well be hundreds of different mutations that contribute to autism, and most of these probably also occur in non-autistics as well.
Actually, a classical definition of autism, the way Leo Kanner or Hans Asperger defined it, excludes cognitive impairment, and is a condition of developmental delay at most (however, many autistics have relatively little developmental delay), not developmental stasis. Go read Leo Kanner's papers - most of his patients who weren't sent to institutions did reasonably well, but still had some difficulties, as adults. I don't actually think that a strict classical definition of autism is the one that should be used, though - autistics can have cognitive impairment, but autism should be defined by atypical thought processes rather than cognitive impairment, and individuals with severe cognitive impairment should usually not be considered diagnosable with autism.
Most modern Unices don't need a sound server, because they have a mixer built into the sound driver. Linux is the only commonly-used Unix that still has a single-open sound driver, as far as I know.
I would be very surprised if Linux, which would be a soft realtime kernel at best, would have better latency than QNX, which is a hard realtime system specifically optimized for latency and determinism. I could see how Linux could have have better throughput, but not better latency.
I think a better idea would be to remove all awareness of hardware specifics (other than the core of the CPU instruction set) from operating systems entirely, and move it into firmware. This firmware would contain a "low-level" driver for each installed device, and would present a consistent abstract interface for each device class. Operating systems written for this firmware would have a single "high-level" driver for each device class, written for the firmware's interface, and a single firmware driver would work on all operating systems written for the firmware. The drivers in the firmware would be relatively minimal, and would basically just "translate" between the hardware's interface and the abstract interface seen by the OS. The firmware interfaces would be low-level, and comparable in exposed functionality to hardware interfaces, although they would be designed to be easily implemented in software (in other words, something like the interfaces presented by e.g. Xen). Because devices of a particular type may vary in capabilities, there would have to be some way to specify "extensions" to the interface (kind of like OpenGL or X11), but there would be a minimum set of functionality for each device class, guaranteed to always be present. Besides putting all compatible operating systems on an equal footing with regards to hardware support, this arrangement would have another benefit. If the firmware abstracts away certain parts of the CPU in addition to abstracting away I/O device specifics, it would make all compatible operating systems inherently paravirtualizable.
Exactly.
It annoys me when Linux zealots claim that an amorphous kernel is superior to a modular one. It isn't all that much harder to write binary-only drivers for Linux (just write a wrapper and only distribute source for it), and an amorphous kernel would be harder to maintain than a modular one (it is possible to rip an entire module out and replace it with a completely different implementation, as long as the replacement has the same interface).
Too many free software developers seem to think that source is a substitute for good design. It doesn't matter what the license is, be it free, proprietary, or whatever - all complex software should be modular (especially operating system cores).
(and if anyone is thinking of claiming that Linux is modular because it is possible to dynamically load kernel object files, don't bother - modularity is more about separation of components than run-time loading)