Medical hardware is already at the point where accidents can be lethal. (Can you imagine what a rogue 9.2 T MRI scanner would do? Or a berserk gamma knife?) It doesn't require absolutely defect-free software, because they balance the cost of lawsuits against the cost of development.
However, it's possible to imagine medical hardware that is sufficiently dangerous that the cost of ANY lawsuit would be prohibitive.
It is also possible to imagine, given the extreme cost of - say - a manned mission to Mars, situations where life-support or medically-related hardware must be defect-free because the cost of replacing the mission would be too great. When you've only got one shot and your only constraint is to make that shot count (no other factors matter), provably-correct software becomes the cheapest alternative.
Oh, I'll add in how to write non-trivial bug-free programs: eliminate ALL programming AND non-programming elements that cannot be proven correct in advance. The programs are just a part of a system and if the system is flawed, the program is flawed.
Occam was an attempt at just this. The processor and the programming language were developed in tandem (which meant you had a provable platform), dynamic structures were verboten, everything was strongly-typed and even the syntax for coding was tightly-defined to reduce errors introduced by sloppy coding practices.
(An unproven platform may introduce bugs into a program when the program itself is bug-free. The only way to make a truly bug-free program is for each element - the CPU, the compiler, the language, the system libraries AND the program - to all be demonstrably correct.)
It is possible to produce defect-free non-trivial software. Generally, though, it is better and more cost-effective to produce defect-tolerant software.
Defect-tolerant software is any software that probably contains bugs but where the bugs simply don't matter. It's a simple extension of the method used to produce a secure general-purpose OS - you have a security kernel that is guaranteed to be defect-free AND guarantee all arcs must go through that security kernel such that no potential vector in any other component can ever be exploited.
It's also an extension of fault-tolerant software, where no failure is ever fatal and any potential bug can be recovered from in some manner.
Once you combine these two ideas - proven kernels for specific functions, and proven recoverability in all functions outside of those kernels - you have software that has no user-visible or system-visible bugs. The bugs will always be contained and the resultant problems will always be dropped.
Frankly, forcing Microsoft to produce a bug-free OS sounds a great idea. (They'd go bankrupt trying. How much better do you want??)
As for the fraudulent concealment of bugs, I don't think it should matter who produced the software, how, or why. If the bug was fraudulently concealed, that should be what matters. This would likely impact security notices (ie: we'd get them sooner, rather than later) and that sounds a great idea to me too.
I'd consider ANY fraudulent concealment to be a problem, though, not just by developers. Thus, a bank or online store that fraudulently concealed the fact that it had a bug which exposed credit card information should likewise be a crime.
(This might result in better upgrade policies, but it would certainly result in a better-informed public. And since panicked buyers don't buy, it might also result in a better-educated public on how to understand risk. Again, something that is long-overdue and filled with potential benefit.)
I'll accept it was not conceived as a plugin system. My argument is not so much that it could be used that way, merely that it's the closest of all the existing audio systems out there to being a true plugin system. You don't have to be close to be the closest, you merely have to be closer than everyone else.
I'll also agree that the context switches make it too cost-prohibitive to scale. I didn't say so in this post, but I have mentioned it in prior posts.
Part of the problem I've discussed before is that a kernel-based solution that provides both plugins and connections to other userspace processes will have context-switch problems between userspace and kernel space, so you don't save anything by moving code into the kernel and may actually worsen the problem in some cases.
I would argue that the distinction between applications and pipes is not necessarily a useful one. A pipe is simply a null application - one where the output is an untransformed input. You could replace a wire with a resistor whose value is the same as the piece of wire it is replacing and there would be no difference. In the same way, there is no functional difference between something that pipes between applications and an application that performs a transformation. It is merely a special case.
Thus, JACK is a plugin system, but a plugin system where all plugins are null plugins. There is absolutely nothing to stop you from adding non-null plugins to the architecture - the input mechanism will be the same, the output mechanism will be the same, and since all JACK-aware applications are already essentially non-null plugins (just externally-located), there is really nothing special that would prevent you from having them internal.
Ultimately, the only way to eliminate the whole context-switch problem is to eliminate the multitude of contexts. This cannot be done on Linux as it stands, no matter how you implement the audio system. It would require a "context-free" ring which exists in ALL contexts simultaneously without prejudice or penalty, and thus be directly addressable from all applications AND from the kernel, AND contain code that could be executed by any of those contexts.
Yes, yes, this defeats all the protections designed into multi-tasking OS', which is why really high-end stuff is done on ultra-thin layers that are not true OS' at all. Bare metal will always beat a general-purpose OS for latency. The only solution to this is to have some sort of container that's very close to bare metal that the OS can interact with without treating it any differently.
Well, to an extent you do. A bad driver is much easier to upgrade/replace than bad hardware, especially if the hardware is built into the motherboard. In the case of audio (a classic Linux problem), if ALSA has a bad/missing driver you are still free to use OSS, and vice versa. If X has a bad video driver, there may be one in GGI or in the Linux framebuffer that you can use. On the other hand, if the chipset is crud, all the software options in the world won't help you.
Ok, let us examine this, using SDR and the session management and IGMP protocols as our candidate for prior art, and using the MBONE itself as the required database. How many of the claims does it meet?
1. A digital notification and response system, comprising (So far, so good, but this one was easy) a. an administrator interface for preparing and transmitting a message from an administrator to at least one user contact device; (SDR is an administrator interface and will transmit to at least one user contact device) b. a dynamic information database for storing the message, wherein the dynamic information database comprises; (yes, SDR does store the message for the session) i. user contact data comprising: (yes, SDR stores this as well) 1. user contact device information; and (It includes the IP of the person creating the session) 2. user selected priority information that indicates a contact order for the user contact device; (At the time multicast was defined, priority bits were defined for IPv4, so yes, there's priority bits. The place in the multicast backbone defines the order of reception and as tunnels are user-defined, the order of reception is also user-defined. Either way, the answer is yes.) ii. user selected grouping information comprising: (No problem with this) 1. at least one group associated with each user contact device; and (Since multicast uses groups, SDR mandates group 224.0.0.1, and all subsequent sessions will be on their own unique groups, yes.) 2. a priority order for contacting each user contact device within the group; (Answered above and shown to be yes, no matter how you understand this.) iii. response data comprising: (Well, yes, there would be.) 1. user response information that indicates individual user contact devices have received the message; and (Yes. Dead branches are pruned from the tree, so if the branch exists, the user contact device is indicating it is receiving the message. This clause does NOT require a definitive ACK as it is worded.) response information that indicates when insufficient user contact device information exists to contact the user contact devices; (Yes, the node will not be present on the tree.) wherein the administrator initiates distribution of the message using the grouping information, priority information, and the priority order, and wherein the message is transmitted through at least two industry standard gateways simultaneously, wherein the two industry standard gateways are selected from the group consisting of: a SMTP gateway a SIP, an H.323, an ISDN gateway, a PSTN gateway, a softswitch, and combinations thereof, wherein the message is received by the at least one user contact device, and the at least one user contact device transmits a response through the industry standard gateways to the dynamic information database. (Yes, you initiate the construction of a group via 224.0.0.1, the tunnels and the priority bits, SDR is industry-standard, multicast delivers to multicast gateways simultaneously by definition, SIP gateways are multicast gateways and thus at least two multicast gateways on the MBONE are probably SIP gateways, and the response is shown by the fact that the tree is maintained.)
Ok, ok, I'm still not looking for special definitions, but I have shown that a system that meets all the generally-understood definitions of the patent has certainly existed for well over a decade. As such, I am not satisfied that anything has been invented here.
I'm certain it would. Indeed, if the bomb bay were replaced with another fuel tank, you'd have an estimated range of 6,000 miles. (The external bomb racks can carry 250 lbs of bombs or 2,000 miles worth of fuel, and the internal bomb bay can carry 250 lbs of bombs and thus should be adaptable to carry the same amount of fuel again.)
I honestly haven't looked, but I seriously doubt you'll find any modern twin prop with a better range than that, and that's before you factor in what would happen if you replaced the Merlins with lighter-weight, more fuel-efficient engines.
Their easy-to-fix, easy-to-maintain design makes them essentially the VW of the skies. They were intended to be repairable in the field without specialist skills and with minimal resources. That would seem ideal for most private owners.
Because they're fast, efficient and can land on airfields too small for executive jets, they should logically be much cheaper (and much safer) to run than private jets without being significantly slower, making them a logical replacement for executive jets for businessmen in this day and age.
Because they are extremely long-range, and because one of the roles they were designed for was coastal patrol, they might make for superior rapid-response aircraft than modern spotter planes.
So all in all, I can't think of a good reason (besides the other poster's thoughts on termites, and that's a solvable problem) as to why these do not grace the skies today. There probably is a reason, but I can't imagine it's a good one.
I've not had quite that problem. Certain apps will kill audio (no idea why), which can be fixed only with a cold boot. Other times, the sound server locks up and rebooting X after kill -9ing the server will fix it.
Certain sound cards, like the Diamond I have, won't work under ALSA. Not sure if the current OSS supports it. We really need a mod for Wine that lets people run drivers within Wine in such a way that the drivers appear to be within the kernel.
Never mind a plan, some sort of agreed specification would be wonderful! (And, no, a bunch of vendors locked away with OSDL or some other tiny group isn't any way to come up with a specification.)
I'd argue that JACK is probably the most Unix-like in passing data from A to B, where all components are special-purpose. I'd also argue that it's the closest to a true audio plugin system of any system out there for Linux. Thus, any specification would logically be derived from the JACK experience.
Why only the experience? Because JACK is linear, but audio processing may want more complex flows. There's a very nice package that lets you build up a synthesizer by running leads from modules to other modules, allowing you to split and merge the signal as you like. That would obviously be superior to single pipe in, single pipe out.
Another problem is that you want audio to be hard real-time, and only the kernel is currently capable of being hard real-time. The user space can only do soft real-time. But flipping between user space and kernel space adds enormous latency for each switch-over. It wouldn't take a long pipe to kill the audio entirely.
Thus, either real-time needs to make it to user space, OR there needs to be an ambivalent layer that is neither strictly kernel nor user, where you can have hard real-time without the horrible overheads.
At this time, neither option seems likely to happen, but until it does true HQ studio audio won't be possible in Linux. It'll come damn close, but it'll never reach the point hardcore professionals would take it on.
Well, some'll do 30 mph, which is the speed limit for inner city driving in England and is ten times what you can actually drive in practice in any real city for much of the time. So, although you couldn't take it on the highways, I don't see why cars of this kind could not have a future in, say, getting to classes, visiting a library or heading down to a coffee shop.
(Ok, ok, it wouldn't be as cool-looking as a Ferrari, but I could picture there being a real market for cars that needed fuel once a year for students.)
Although the 25 watt car deserves a mention, it's not petrol/gasoline powered and therefore not what I'm talking about, which is the upper extreme of where you can take internal combustion engines.
Since the Pteradactyl can't take off under its own power (it has to leap off a cliff or build said catapult), they don't technically expend any energy to achieve altitude. All the effort is in climbing (an independent activity) or coaxing mech eng students to time travel.
Why not? Schools and Universities generally did better at the Micromouse tournament than "professional" engineers. Generally, it was the same class of people you saw winning Eggmobile contests. Boeing didn't win the X-Prize, and I don't believe it was any of the super-giant aviation companies that did the work on the two round-the-world record flights.
Hell, although big companies have contributed to Bloodhound (the 1000 MPH car being built in the UK), it is largely driven by super-genius inventors and engineers in a small team.
For that matter, look at who is doing well in Formula 1. Braun. A small bunch of enthusiasts who told Honda where their management could go. Look at who is quitting. BMW. The super-giants aren't guaranteed to walk off with the big prizes just because they're big companies. It happens, sure, but it's not in itself a recipe for success.
I was seeing sports cars advertised at 100 MPG at 100 MPH back in 1995. There were several listed in the Brands Hatch F1 program, as I recall. (Anyone who still has a copy like to verify that?)
The current record for fuel economy at regular road speeds in a car is something like 6000 MPG. The current record for fuel economy in any petrol-driven engine without assistance from alternative sources is 9998 MPG.
Aircraft have an advantage in that they have no ground friction to deal with. Also, prop planes have been developed to be efficient for decades - the DeHavilland Mosquito had a range of 4,000 miles on 500 lbs of fuel in 1941, and some of the more modern composite-fibre aircraft and modern engines have fuel efficiencies vastly superior to that.
Since I'm dangerously underweight (always have been), can't stand Cheetos and regard World of Warcraft as an inferior MUD that cannot hope to ever match the true supremacy of Live Roleplaying (Spirit of Adventure-style, or Trouble At Mill), I don't match any of your naive and rather superstitious stereotypes.
I probably walk more in an afternoon than you do in a week (I consider 21 miles to be a nice, gentle stroll), probably have more friends than you know people, and am unquestionably Aspie (diagnosed repeatedly by both neurologists and pdocs).
So who's crying? You, with your inferior 6-digit UID and stereotypical fantasies, or me?
NT version 3.5 or 4?:) I wouldn't consider it parlour tricks, and you WILL be grateful for that ability when you're in your 90s. Polyglots and "classical" thinkers (those who mix arts and science) have a much higher resistance to almost all the effects of old age and are virtually bullet-proof to things like Alzheimers.
Yes, you're right that it's polarizing, but NTs actually set out TO polarize their abilities. They just do it under the pretense that they are now "specialists" or "experts" in a field. NT is an evolutionary dead-end, and those who live in their world try hard to recreate ours in order to function.
Normal is a bell-curve in terms of frequency, but an inverse-bell in terms of functionality, producing more of a saddle-shape. The topology of this class of shapes is fascinating, but the usefulness is near-zero.
Frankly, does it matter what a large number of people do? A medical psychiatric diagnosis can only be given by a fully-qualified specialist on the disorder in the psychiatric profession and a neurological diagnosis can only be given by a neurologist.
If these professions concur that, say, Britain has an incidence rate of 1:60 people for AS disorders, of what possibly consequence is the opinion of the remaining 59 on what they have, or indeed of the 1 in that 60 as to what consequences they face?
I see you're avoiding the issue that it can be detected and diagnosed by brain scans. I don't give a damn what person X says person Y says they have, I care that MRI results establish a neurological disorder within the mirror neurons produces the symptoms established by the psychiatric profession as Asperger's Syndrome.
What you say others say is of no significance whatsoever compared to the hard evidence. Now either address it or admit you have no point.
(ObTrivia note for USians: A man claiming to be the reincarnation of King Arthur successfully lodged an appeal on the grounds he was saner than the Government.)
Kevin Mitnik spent how many years behind bars before the case even went to court? The fatalities in custody in the US is how much in excess of the norm of the rest of the Western powers?
Besides, the Supreme Court actually has no power whatsoever to actually enforce any of its decisions, which is why when it is convenient to do so, the US Government ignores it. Sanity in the US is optional, and sadly nowhere near as common as it should be.
Referring to the Prince Philip PRESTEL e-mail case, I would point out that the defense successfully argued there that there was no trespass or breaking-and-entering.
Slashdot Mirror
Medical hardware is already at the point where accidents can be lethal. (Can you imagine what a rogue 9.2 T MRI scanner would do? Or a berserk gamma knife?) It doesn't require absolutely defect-free software, because they balance the cost of lawsuits against the cost of development.
However, it's possible to imagine medical hardware that is sufficiently dangerous that the cost of ANY lawsuit would be prohibitive.
It is also possible to imagine, given the extreme cost of - say - a manned mission to Mars, situations where life-support or medically-related hardware must be defect-free because the cost of replacing the mission would be too great. When you've only got one shot and your only constraint is to make that shot count (no other factors matter), provably-correct software becomes the cheapest alternative.
Oh, I'll add in how to write non-trivial bug-free programs: eliminate ALL programming AND non-programming elements that cannot be proven correct in advance. The programs are just a part of a system and if the system is flawed, the program is flawed.
Occam was an attempt at just this. The processor and the programming language were developed in tandem (which meant you had a provable platform), dynamic structures were verboten, everything was strongly-typed and even the syntax for coding was tightly-defined to reduce errors introduced by sloppy coding practices.
(An unproven platform may introduce bugs into a program when the program itself is bug-free. The only way to make a truly bug-free program is for each element - the CPU, the compiler, the language, the system libraries AND the program - to all be demonstrably correct.)
It is possible to produce defect-free non-trivial software. Generally, though, it is better and more cost-effective to produce defect-tolerant software.
Defect-tolerant software is any software that probably contains bugs but where the bugs simply don't matter. It's a simple extension of the method used to produce a secure general-purpose OS - you have a security kernel that is guaranteed to be defect-free AND guarantee all arcs must go through that security kernel such that no potential vector in any other component can ever be exploited.
It's also an extension of fault-tolerant software, where no failure is ever fatal and any potential bug can be recovered from in some manner.
Once you combine these two ideas - proven kernels for specific functions, and proven recoverability in all functions outside of those kernels - you have software that has no user-visible or system-visible bugs. The bugs will always be contained and the resultant problems will always be dropped.
Frankly, forcing Microsoft to produce a bug-free OS sounds a great idea. (They'd go bankrupt trying. How much better do you want??)
As for the fraudulent concealment of bugs, I don't think it should matter who produced the software, how, or why. If the bug was fraudulently concealed, that should be what matters. This would likely impact security notices (ie: we'd get them sooner, rather than later) and that sounds a great idea to me too.
I'd consider ANY fraudulent concealment to be a problem, though, not just by developers. Thus, a bank or online store that fraudulently concealed the fact that it had a bug which exposed credit card information should likewise be a crime.
(This might result in better upgrade policies, but it would certainly result in a better-informed public. And since panicked buyers don't buy, it might also result in a better-educated public on how to understand risk. Again, something that is long-overdue and filled with potential benefit.)
I'll accept it was not conceived as a plugin system. My argument is not so much that it could be used that way, merely that it's the closest of all the existing audio systems out there to being a true plugin system. You don't have to be close to be the closest, you merely have to be closer than everyone else.
I'll also agree that the context switches make it too cost-prohibitive to scale. I didn't say so in this post, but I have mentioned it in prior posts.
Part of the problem I've discussed before is that a kernel-based solution that provides both plugins and connections to other userspace processes will have context-switch problems between userspace and kernel space, so you don't save anything by moving code into the kernel and may actually worsen the problem in some cases.
I would argue that the distinction between applications and pipes is not necessarily a useful one. A pipe is simply a null application - one where the output is an untransformed input. You could replace a wire with a resistor whose value is the same as the piece of wire it is replacing and there would be no difference. In the same way, there is no functional difference between something that pipes between applications and an application that performs a transformation. It is merely a special case.
Thus, JACK is a plugin system, but a plugin system where all plugins are null plugins. There is absolutely nothing to stop you from adding non-null plugins to the architecture - the input mechanism will be the same, the output mechanism will be the same, and since all JACK-aware applications are already essentially non-null plugins (just externally-located), there is really nothing special that would prevent you from having them internal.
Ultimately, the only way to eliminate the whole context-switch problem is to eliminate the multitude of contexts. This cannot be done on Linux as it stands, no matter how you implement the audio system. It would require a "context-free" ring which exists in ALL contexts simultaneously without prejudice or penalty, and thus be directly addressable from all applications AND from the kernel, AND contain code that could be executed by any of those contexts.
Yes, yes, this defeats all the protections designed into multi-tasking OS', which is why really high-end stuff is done on ultra-thin layers that are not true OS' at all. Bare metal will always beat a general-purpose OS for latency. The only solution to this is to have some sort of container that's very close to bare metal that the OS can interact with without treating it any differently.
Well, to an extent you do. A bad driver is much easier to upgrade/replace than bad hardware, especially if the hardware is built into the motherboard. In the case of audio (a classic Linux problem), if ALSA has a bad/missing driver you are still free to use OSS, and vice versa. If X has a bad video driver, there may be one in GGI or in the Linux framebuffer that you can use. On the other hand, if the chipset is crud, all the software options in the world won't help you.
Ok, let us examine this, using SDR and the session management and IGMP protocols as our candidate for prior art, and using the MBONE itself as the required database. How many of the claims does it meet?
1. A digital notification and response system, comprising (So far, so good, but this one was easy)
a. an administrator interface for preparing and transmitting a message from an administrator to at least one user contact device; (SDR is an administrator interface and will transmit to at least one user contact device)
b. a dynamic information database for storing the message, wherein the dynamic information database comprises; (yes, SDR does store the message for the session)
i. user contact data comprising: (yes, SDR stores this as well)
1. user contact device information; and (It includes the IP of the person creating the session)
2. user selected priority information that indicates a contact order for the user contact device; (At the time multicast was defined, priority bits were defined for IPv4, so yes, there's priority bits. The place in the multicast backbone defines the order of reception and as tunnels are user-defined, the order of reception is also user-defined. Either way, the answer is yes.)
ii. user selected grouping information comprising: (No problem with this)
1. at least one group associated with each user contact device; and (Since multicast uses groups, SDR mandates group 224.0.0.1, and all subsequent sessions will be on their own unique groups, yes.)
2. a priority order for contacting each user contact device within the group; (Answered above and shown to be yes, no matter how you understand this.)
iii. response data comprising: (Well, yes, there would be.)
1. user response information that indicates individual user contact devices have received the message; and (Yes. Dead branches are pruned from the tree, so if the branch exists, the user contact device is indicating it is receiving the message. This clause does NOT require a definitive ACK as it is worded.)
response information that indicates when insufficient user contact device information exists to contact the user contact devices; (Yes, the node will not be present on the tree.)
wherein the administrator initiates distribution of the message using the grouping information, priority information, and the priority order, and wherein the message is transmitted through at least two industry standard gateways simultaneously, wherein the two industry standard gateways are selected from the group consisting of: a SMTP gateway a SIP, an H.323, an ISDN gateway, a PSTN gateway, a softswitch, and combinations thereof, wherein the message is received by the at least one user contact device, and the at least one user contact device transmits a response through the industry standard gateways to the dynamic information database. (Yes, you initiate the construction of a group via 224.0.0.1, the tunnels and the priority bits, SDR is industry-standard, multicast delivers to multicast gateways simultaneously by definition, SIP gateways are multicast gateways and thus at least two multicast gateways on the MBONE are probably SIP gateways, and the response is shown by the fact that the tree is maintained.)
Ok, ok, I'm still not looking for special definitions, but I have shown that a system that meets all the generally-understood definitions of the patent has certainly existed for well over a decade. As such, I am not satisfied that anything has been invented here.
I'm certain it would. Indeed, if the bomb bay were replaced with another fuel tank, you'd have an estimated range of 6,000 miles. (The external bomb racks can carry 250 lbs of bombs or 2,000 miles worth of fuel, and the internal bomb bay can carry 250 lbs of bombs and thus should be adaptable to carry the same amount of fuel again.)
I honestly haven't looked, but I seriously doubt you'll find any modern twin prop with a better range than that, and that's before you factor in what would happen if you replaced the Merlins with lighter-weight, more fuel-efficient engines.
Their easy-to-fix, easy-to-maintain design makes them essentially the VW of the skies. They were intended to be repairable in the field without specialist skills and with minimal resources. That would seem ideal for most private owners.
Because they're fast, efficient and can land on airfields too small for executive jets, they should logically be much cheaper (and much safer) to run than private jets without being significantly slower, making them a logical replacement for executive jets for businessmen in this day and age.
Because they are extremely long-range, and because one of the roles they were designed for was coastal patrol, they might make for superior rapid-response aircraft than modern spotter planes.
So all in all, I can't think of a good reason (besides the other poster's thoughts on termites, and that's a solvable problem) as to why these do not grace the skies today. There probably is a reason, but I can't imagine it's a good one.
I've not had quite that problem. Certain apps will kill audio (no idea why), which can be fixed only with a cold boot. Other times, the sound server locks up and rebooting X after kill -9ing the server will fix it.
Certain sound cards, like the Diamond I have, won't work under ALSA. Not sure if the current OSS supports it. We really need a mod for Wine that lets people run drivers within Wine in such a way that the drivers appear to be within the kernel.
Never mind a plan, some sort of agreed specification would be wonderful! (And, no, a bunch of vendors locked away with OSDL or some other tiny group isn't any way to come up with a specification.)
I'd argue that JACK is probably the most Unix-like in passing data from A to B, where all components are special-purpose. I'd also argue that it's the closest to a true audio plugin system of any system out there for Linux. Thus, any specification would logically be derived from the JACK experience.
Why only the experience? Because JACK is linear, but audio processing may want more complex flows. There's a very nice package that lets you build up a synthesizer by running leads from modules to other modules, allowing you to split and merge the signal as you like. That would obviously be superior to single pipe in, single pipe out.
Another problem is that you want audio to be hard real-time, and only the kernel is currently capable of being hard real-time. The user space can only do soft real-time. But flipping between user space and kernel space adds enormous latency for each switch-over. It wouldn't take a long pipe to kill the audio entirely.
Thus, either real-time needs to make it to user space, OR there needs to be an ambivalent layer that is neither strictly kernel nor user, where you can have hard real-time without the horrible overheads.
At this time, neither option seems likely to happen, but until it does true HQ studio audio won't be possible in Linux. It'll come damn close, but it'll never reach the point hardcore professionals would take it on.
*collapses laughing at work*
The image! It is burned into my brain!
[Modern English Filter Disabled]
Uggg. Gnnnnorg wibble nug. Floccinoccinihilipilification.
You're right. My bad. I should write for The Grauniad.
Well, some'll do 30 mph, which is the speed limit for inner city driving in England and is ten times what you can actually drive in practice in any real city for much of the time. So, although you couldn't take it on the highways, I don't see why cars of this kind could not have a future in, say, getting to classes, visiting a library or heading down to a coffee shop.
(Ok, ok, it wouldn't be as cool-looking as a Ferrari, but I could picture there being a real market for cars that needed fuel once a year for students.)
Ok, links you shall have.
Although the 25 watt car deserves a mention, it's not petrol/gasoline powered and therefore not what I'm talking about, which is the upper extreme of where you can take internal combustion engines.
Since the Pteradactyl can't take off under its own power (it has to leap off a cliff or build said catapult), they don't technically expend any energy to achieve altitude. All the effort is in climbing (an independent activity) or coaxing mech eng students to time travel.
Why not? Schools and Universities generally did better at the Micromouse tournament than "professional" engineers. Generally, it was the same class of people you saw winning Eggmobile contests. Boeing didn't win the X-Prize, and I don't believe it was any of the super-giant aviation companies that did the work on the two round-the-world record flights.
Hell, although big companies have contributed to Bloodhound (the 1000 MPH car being built in the UK), it is largely driven by super-genius inventors and engineers in a small team.
For that matter, look at who is doing well in Formula 1. Braun. A small bunch of enthusiasts who told Honda where their management could go. Look at who is quitting. BMW. The super-giants aren't guaranteed to walk off with the big prizes just because they're big companies. It happens, sure, but it's not in itself a recipe for success.
I was seeing sports cars advertised at 100 MPG at 100 MPH back in 1995. There were several listed in the Brands Hatch F1 program, as I recall. (Anyone who still has a copy like to verify that?)
The current record for fuel economy at regular road speeds in a car is something like 6000 MPG. The current record for fuel economy in any petrol-driven engine without assistance from alternative sources is 9998 MPG.
Aircraft have an advantage in that they have no ground friction to deal with. Also, prop planes have been developed to be efficient for decades - the DeHavilland Mosquito had a range of 4,000 miles on 500 lbs of fuel in 1941, and some of the more modern composite-fibre aircraft and modern engines have fuel efficiencies vastly superior to that.
Since I'm dangerously underweight (always have been), can't stand Cheetos and regard World of Warcraft as an inferior MUD that cannot hope to ever match the true supremacy of Live Roleplaying (Spirit of Adventure-style, or Trouble At Mill), I don't match any of your naive and rather superstitious stereotypes.
I probably walk more in an afternoon than you do in a week (I consider 21 miles to be a nice, gentle stroll), probably have more friends than you know people, and am unquestionably Aspie (diagnosed repeatedly by both neurologists and pdocs).
So who's crying? You, with your inferior 6-digit UID and stereotypical fantasies, or me?
NT version 3.5 or 4? :) I wouldn't consider it parlour tricks, and you WILL be grateful for that ability when you're in your 90s. Polyglots and "classical" thinkers (those who mix arts and science) have a much higher resistance to almost all the effects of old age and are virtually bullet-proof to things like Alzheimers.
Yes, you're right that it's polarizing, but NTs actually set out TO polarize their abilities. They just do it under the pretense that they are now "specialists" or "experts" in a field. NT is an evolutionary dead-end, and those who live in their world try hard to recreate ours in order to function.
Normal is a bell-curve in terms of frequency, but an inverse-bell in terms of functionality, producing more of a saddle-shape. The topology of this class of shapes is fascinating, but the usefulness is near-zero.
Frankly, does it matter what a large number of people do? A medical psychiatric diagnosis can only be given by a fully-qualified specialist on the disorder in the psychiatric profession and a neurological diagnosis can only be given by a neurologist.
If these professions concur that, say, Britain has an incidence rate of 1:60 people for AS disorders, of what possibly consequence is the opinion of the remaining 59 on what they have, or indeed of the 1 in that 60 as to what consequences they face?
I see you're avoiding the issue that it can be detected and diagnosed by brain scans. I don't give a damn what person X says person Y says they have, I care that MRI results establish a neurological disorder within the mirror neurons produces the symptoms established by the psychiatric profession as Asperger's Syndrome.
What you say others say is of no significance whatsoever compared to the hard evidence. Now either address it or admit you have no point.
Except for King Arthur. You forgot that part.
(ObTrivia note for USians: A man claiming to be the reincarnation of King Arthur successfully lodged an appeal on the grounds he was saner than the Government.)
Kevin Mitnik spent how many years behind bars before the case even went to court? The fatalities in custody in the US is how much in excess of the norm of the rest of the Western powers?
Besides, the Supreme Court actually has no power whatsoever to actually enforce any of its decisions, which is why when it is convenient to do so, the US Government ignores it. Sanity in the US is optional, and sadly nowhere near as common as it should be.
Referring to the Prince Philip PRESTEL e-mail case, I would point out that the defense successfully argued there that there was no trespass or breaking-and-entering.