...is to position the computer upside-down. Condensation does not form on the hot surfaces, only the cold surfaces. If the cold surfaces cause the water to drip away, there is no way for the water to interfere. Another option is to refrigerate the entire computer (which is done by overclockers), as the coldest point will then be far away, and you've the added bonus that the air will be very dry within a short timeframe.
A third option would be to run copper from each chip surface to the refrigerator. The heat gradient will prevent any chip running hot, you only need one refrigerator, and you can handle the case of the heavy workloads shifting from one part of the system to another.
People who sell theoretical products are known as "moon rakers". Fascinating history. Sir Clive Sinclair did that and used the proceeds to build the machines he was claiming to sell. Nice business model, if you can develop the product fast enough for nobody to notice.
Oh, I agree that reality doesn't always jive with architecture, which is why we have crappy products with poor reliability and high wastage. However, the need to have what software sees be the same as what hardware sees was a problem solved many, many decades ago by having layers of abstraction. Software is totally unaware of what the hardware does, it only knows what it is presented with. If you present it with a literal view of hardware, then that is a remarkably stupid design decision, it has nothing to do with theory or with what the customer wants.
Here's how you could do it, with minimal effort. First, you want a reasonable-sized buffer. It can't really be stretchy, as it is in kernel space, but too large might cause problems as well. I'd say somewhere between 4 megabytes to 16 megabytes, depending on RAM available. Second, you want a dedicated virtual memory manager with four layers of page tables, very similar to the one used by Linux. For each page where nothing has been written, the page tables point into the flash memory. For each page where something has been changed, the page tables point into a 2K allocation in the buffer space containing the 2K from flash overwritten by whatever the user has changed. (Writing is not the same as changing. If A xor B = 0, the software should effectively ignore the write.)
Once the buffer exceeds a high water mark, the buffer is reorganized to minimize writes, then data would be bulk-written to flash, starting with the contiguous set of data that has the least probability of changing according to some standard metric. Those page table entries then get reset back to point to flash again.
Alternatively, use NUMA algorithms to handle the writing. After all, flash is effectively RAM that is a non-uniform resource in terms of access performance. NUMA already handles delayed writes, the problems of cache coherency, and even the problems of parallel access. (My initial suggested solution would not handle the case of parallel access, as would happen under PCI-E 2.x)
Alternatively, give the solid-state disk plenty of RAM, a full DMA engine and a basic CPU, then have it handle all the caching and buffering locally. Remote access would then be through RDMA channels or (again) NUMA. As far as the local system was concerned, it sees a local ramdisk that is only marginally slower than regular RAM, it would not see the flash storage at all.
All of these are possible, all of these require minimal novel coding (the code has largely already been written), and none would require the user to be aware of any changes whatsoever. The main reason "new" designs fail is that they tend to place unexpected demands on users. If the user is oblivious to the differences - except that your product seems a lot faster than anyone else's - then the user won't object to the differences that are hidden from them. (There are no compatibility problems, for example.)
The second reason new designs fail is cost. The first solution is mostly software - very little hardware is needed - and most of that software is already available under BSD or GPL licenses for nothing. The added cost, then, is going to also be practically nothing.
The second and third designs use more and more hardware to abstract out the details, which means extra costs, but they're also aimed at highly parallel environments which aren't cheap and where performance matters. Those markets just aren't going to care about the few extra dimes involved in producing high-performance solid-state disks.
Maybe, maybe not. SQLite doesn't handle parallelism well, Drizzle is supposed to. Drizzle is supposed to not remove most of these features but layer them correctly, presumably using the old Unix notion of shells-on-top-of-shells. If so, then what you will end up with will do exactly the same stuff, but by different paths through the code, such that there is a lower impact on high speed operations.
Personally, I don't know what the fuss is. Ever since MySQL started veering towards proprietary attitudes, I've been using PostgreSQL and Ingres. (Ingres is still maintained and has become fully GPL.) These databases are generally better for heavy-duty lifting, although they're obviously not designed for very fast lightweight work. I am not completely convinced you want a SQL database for the real fast work, anyway, where you are typically dealing with hashed index markers and data blobs, but are not dealing with multiple views of the same data.
Maybe, but it is insane to develop hardware to suit software. Far too many types of software will want to use the same hardware, you can't optimize for them all. It is far more logical, far more rational, to optimize the hardware for the task, and leave it to software on the device or drivers on the host machine to present a suitable view for the operating system. Any remaining problems are for the OS to take care of. If the OS doesn't, that's the OS' problem, not the hardware's.
In this case, let's take the thrashing problem. If the driver did not provide write-through, knew enough to distinguish data from indexes and had sufficient ramdisk to work with, it should be possible to eliminate writes until the last possible moment, and to maximize the number of whole-block writes. Ideally, you'd mirror the entire drive in RAM, do everything in a ramdrive, then reorganize and write only once at the very end. In practice, you won't have that much RAM, but you should have enough to absorb unnecessary or inefficient writing methods.
Algae is not innocent. Did you know that most spam is generated by algae colonies hacking into open wireless routers? Or that algae monsters invaded Las Vegas and now own all of the casinos? That President Bush is, in fact, algae?
London smogs used to burn people's lungs out. I think the average was something like fifty deaths from acid-eaten lungs for every day of pea-souper smog. The Scandanavian mountains worst affected have alkaline soils and the rivers lost much of their acidity when England stopped burning sulpher-containing coal. Fascinating coincidence. Also, the northwest of England has enormous contamination problems to this day from the Industrial Revolution. The most recent problem being metal-eating bacteria that entered the ecosystem from the smokestacks. The bacteria need far more acidic conditions than typical rainwater in which to survive, and are currently devastating the countryside. They are a major ecological hazard. (If I wanted to go all sci-fi, I'd add: "for the moment...", as the soil is ideal for them and is also moderately radioactive. Lots of juicy beta particles.)
Ok, ok, if you insist on balancing. It's actually H2NO3, 2xH2NO3 + O2 = 2xH2NO4. All that fuss over a couple of oxygen atoms.
Anyways, this is why there's a brown fog around busy roads. Car engines produce plenty of oxides of nitrogen, which incidentally is endothermic - it takes energy away from the engine to produce them. ObOffTopic: Nitrogen ionizes at a much higher energy than oxygen, so in principle you can electro-statically separate them. This would not be perfect, but the less nitrogen going to the engine, the less energy you bleed off and the less pollution you generate. This is not an efficient separation technique, however, you'd need one much more efficient to be practical. It is unlikely this would give you a net gain in usable energy, though I'd love to see the experiment done to see what happened. It should be possible to derive a superior solution, though.
CO2 will react with all sorts of things. The reaction with water produces carbonic acid. Add something alkaline and you get salt + water. Using lime water (a saturated calcium hydroxide solution) is the shortcut version (you get calcium carbonate + water). Once artificial photosynthesis is developed, you can always turn the CO2 into O2 - no shortage of sunlight.
I know people who have tens of windows and hundreds of tabs open on each. On the one hand, it's great to know someone has less of a life than me, on the other, it means browsers have to be really well-written for such people, if they are to work.
That is entirely correct. AESEC makes the claim that: "GEMSOS is the only general-purpose kernel in the world rated Class A1: Verified Protection by the National Security Agency."
The other place you want to check is the paper on security kernels. This describes how to reach A1 (CC7) without having to prove the entire OS.
JBoss is not widely used. Struts is, Hibernate mostly is... However, the underlying problem is that these are ALL middleware packages. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
This study manages to tell me one thing: This group has no idea how to perform studies. Even most FUD merchants would do a bit better job of covering the deficiencies in their methods.
Way back in the mists of time, part of my University training was on Human-Computer Interfaces and how not to design them. One of the first things we were told about was excessive alerts and excessive confirmations. It just causes the user to be desensitized to those things that are important, and they end up hitting the given key or clicking the necessary box without really reading any of the dialog presented. This actually worsens security. Especially if there's any way to silence such warnings, by disabling them for example, or having a utility that injects a confirmation into the module that handles the dialog.
I believe security can sell, but that paranoia and pestering won't. Mandatory access controls, role-based access controls and POSIX access control lists do not require pestering dialog. There are general-purpose operating systems rated A1 on the old Orange Book scale - the highest rating for host security you can get - and I doubt a single one requires massive user intervention to do anything more complex than Solitaire.
I would argue, then, that the article is wrong on Vista, that Vista is NOT the most secure offering from Microsoft because users stop trusting the security facility and are more likely to accidentally permit applications to do something stupid. You have to consider th wetware, and the wetware is very easily overloaded with trivia. Vista is only the most secure offering from Microsoft if nobody uses it.
There are generally two possible reasons - either the patent for something hasn't gone through and they're wanting to avoid too much of the wrong attention whilst still stirring up the interest of customers, OR there is a major flaw in the technology and they hope to fix it before anyone notices by hiding the details.
I have seen the latter, on two different startups I've had entanglements with. Wretched NDAs and the Old Boys Network mean you're not getting either story from me, but the fact is that dodgy use of trade secrets to hide flawed products is not unusual.
Twelve? Yeesh. FamilyTreeDNA offers 67 STRs and that's not considered to be adequate for anything more than family tree work. Hmmm. I doubt the 12 are within the 67, so for about $100 per person, they could improve the results substantially. deCODEme charts 1,000,000 SNPs per person, but their test is pricey at $1000. It would depend on how the cost of the test scales, but I imagine testing for 1,000 SNPs would again be around the $100 region. Given the trial costs per accused, and given the PR damage for every screw-up, that doesn't seem like a horrible burden. Even the $1000 test - I suspect most cop precincts spend that much on coffee and donuts in a week.
Oh god. It's a minor miracle they get so few duplicates with that method. Assuming they do, in fact, only have a few duplicates. That technique is positively stone-age and is open to all kinds of errors. That would make as much sense as the FDA using a speak-your-weight machine to measure microgram variations. (Oh god... I just thought... that would certainly explain a lot about the FDA...)
The MPs who have their own websites might be able to change their own passwords, but the Civil Service? C'mon, these are the guys that use "Yes, Prime Minister" as training material.
Slashdot Mirror
I don't know why people keep subjecting Status Quo to American culture. They're a great British rock group and should be left that way.
...is to position the computer upside-down. Condensation does not form on the hot surfaces, only the cold surfaces. If the cold surfaces cause the water to drip away, there is no way for the water to interfere. Another option is to refrigerate the entire computer (which is done by overclockers), as the coldest point will then be far away, and you've the added bonus that the air will be very dry within a short timeframe.
A third option would be to run copper from each chip surface to the refrigerator. The heat gradient will prevent any chip running hot, you only need one refrigerator, and you can handle the case of the heavy workloads shifting from one part of the system to another.
People who sell theoretical products are known as "moon rakers". Fascinating history. Sir Clive Sinclair did that and used the proceeds to build the machines he was claiming to sell. Nice business model, if you can develop the product fast enough for nobody to notice.
Oh, I agree that reality doesn't always jive with architecture, which is why we have crappy products with poor reliability and high wastage. However, the need to have what software sees be the same as what hardware sees was a problem solved many, many decades ago by having layers of abstraction. Software is totally unaware of what the hardware does, it only knows what it is presented with. If you present it with a literal view of hardware, then that is a remarkably stupid design decision, it has nothing to do with theory or with what the customer wants.
Here's how you could do it, with minimal effort. First, you want a reasonable-sized buffer. It can't really be stretchy, as it is in kernel space, but too large might cause problems as well. I'd say somewhere between 4 megabytes to 16 megabytes, depending on RAM available. Second, you want a dedicated virtual memory manager with four layers of page tables, very similar to the one used by Linux. For each page where nothing has been written, the page tables point into the flash memory. For each page where something has been changed, the page tables point into a 2K allocation in the buffer space containing the 2K from flash overwritten by whatever the user has changed. (Writing is not the same as changing. If A xor B = 0, the software should effectively ignore the write.)
Once the buffer exceeds a high water mark, the buffer is reorganized to minimize writes, then data would be bulk-written to flash, starting with the contiguous set of data that has the least probability of changing according to some standard metric. Those page table entries then get reset back to point to flash again.
Alternatively, use NUMA algorithms to handle the writing. After all, flash is effectively RAM that is a non-uniform resource in terms of access performance. NUMA already handles delayed writes, the problems of cache coherency, and even the problems of parallel access. (My initial suggested solution would not handle the case of parallel access, as would happen under PCI-E 2.x)
Alternatively, give the solid-state disk plenty of RAM, a full DMA engine and a basic CPU, then have it handle all the caching and buffering locally. Remote access would then be through RDMA channels or (again) NUMA. As far as the local system was concerned, it sees a local ramdisk that is only marginally slower than regular RAM, it would not see the flash storage at all.
All of these are possible, all of these require minimal novel coding (the code has largely already been written), and none would require the user to be aware of any changes whatsoever. The main reason "new" designs fail is that they tend to place unexpected demands on users. If the user is oblivious to the differences - except that your product seems a lot faster than anyone else's - then the user won't object to the differences that are hidden from them. (There are no compatibility problems, for example.)
The second reason new designs fail is cost. The first solution is mostly software - very little hardware is needed - and most of that software is already available under BSD or GPL licenses for nothing. The added cost, then, is going to also be practically nothing.
The second and third designs use more and more hardware to abstract out the details, which means extra costs, but they're also aimed at highly parallel environments which aren't cheap and where performance matters. Those markets just aren't going to care about the few extra dimes involved in producing high-performance solid-state disks.
Maybe, maybe not. SQLite doesn't handle parallelism well, Drizzle is supposed to. Drizzle is supposed to not remove most of these features but layer them correctly, presumably using the old Unix notion of shells-on-top-of-shells. If so, then what you will end up with will do exactly the same stuff, but by different paths through the code, such that there is a lower impact on high speed operations.
Personally, I don't know what the fuss is. Ever since MySQL started veering towards proprietary attitudes, I've been using PostgreSQL and Ingres. (Ingres is still maintained and has become fully GPL.) These databases are generally better for heavy-duty lifting, although they're obviously not designed for very fast lightweight work. I am not completely convinced you want a SQL database for the real fast work, anyway, where you are typically dealing with hashed index markers and data blobs, but are not dealing with multiple views of the same data.
Maybe, but it is insane to develop hardware to suit software. Far too many types of software will want to use the same hardware, you can't optimize for them all. It is far more logical, far more rational, to optimize the hardware for the task, and leave it to software on the device or drivers on the host machine to present a suitable view for the operating system. Any remaining problems are for the OS to take care of. If the OS doesn't, that's the OS' problem, not the hardware's.
In this case, let's take the thrashing problem. If the driver did not provide write-through, knew enough to distinguish data from indexes and had sufficient ramdisk to work with, it should be possible to eliminate writes until the last possible moment, and to maximize the number of whole-block writes. Ideally, you'd mirror the entire drive in RAM, do everything in a ramdrive, then reorganize and write only once at the very end. In practice, you won't have that much RAM, but you should have enough to absorb unnecessary or inefficient writing methods.
The Dilbert cartoon foresaw the coming of supercomputers made entirely of recycled paper!
Algae is not innocent. Did you know that most spam is generated by algae colonies hacking into open wireless routers? Or that algae monsters invaded Las Vegas and now own all of the casinos? That President Bush is, in fact, algae?
London smogs used to burn people's lungs out. I think the average was something like fifty deaths from acid-eaten lungs for every day of pea-souper smog. The Scandanavian mountains worst affected have alkaline soils and the rivers lost much of their acidity when England stopped burning sulpher-containing coal. Fascinating coincidence. Also, the northwest of England has enormous contamination problems to this day from the Industrial Revolution. The most recent problem being metal-eating bacteria that entered the ecosystem from the smokestacks. The bacteria need far more acidic conditions than typical rainwater in which to survive, and are currently devastating the countryside. They are a major ecological hazard. (If I wanted to go all sci-fi, I'd add: "for the moment...", as the soil is ideal for them and is also moderately radioactive. Lots of juicy beta particles.)
Ok, ok, if you insist on balancing. It's actually H2NO3, 2xH2NO3 + O2 = 2xH2NO4. All that fuss over a couple of oxygen atoms. Anyways, this is why there's a brown fog around busy roads. Car engines produce plenty of oxides of nitrogen, which incidentally is endothermic - it takes energy away from the engine to produce them. ObOffTopic: Nitrogen ionizes at a much higher energy than oxygen, so in principle you can electro-statically separate them. This would not be perfect, but the less nitrogen going to the engine, the less energy you bleed off and the less pollution you generate. This is not an efficient separation technique, however, you'd need one much more efficient to be practical. It is unlikely this would give you a net gain in usable energy, though I'd love to see the experiment done to see what happened. It should be possible to derive a superior solution, though.
NO2+H2O=H2NO4
CO2 will react with all sorts of things. The reaction with water produces carbonic acid. Add something alkaline and you get salt + water. Using lime water (a saturated calcium hydroxide solution) is the shortcut version (you get calcium carbonate + water). Once artificial photosynthesis is developed, you can always turn the CO2 into O2 - no shortage of sunlight.
protection from the sulfuric acid in the atmosphere
C'mon! It's no worse than the acid rain in L.A.!
A complete open-source schematic for a type 40 TARDIS* will be made available here last week.
*Blue paint sold separately.
I know people who have tens of windows and hundreds of tabs open on each. On the one hand, it's great to know someone has less of a life than me, on the other, it means browsers have to be really well-written for such people, if they are to work.
There were web users in the late 60s?
The other place you want to check is the paper on security kernels. This describes how to reach A1 (CC7) without having to prove the entire OS.
As long as it remains secret, many shops will hold off patching their DNS server, assuming the problem to have been blown out of proportion.
JBoss is not widely used. Struts is, Hibernate mostly is... However, the underlying problem is that these are ALL middleware packages. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
This study manages to tell me one thing: This group has no idea how to perform studies. Even most FUD merchants would do a bit better job of covering the deficiencies in their methods.
Way back in the mists of time, part of my University training was on Human-Computer Interfaces and how not to design them. One of the first things we were told about was excessive alerts and excessive confirmations. It just causes the user to be desensitized to those things that are important, and they end up hitting the given key or clicking the necessary box without really reading any of the dialog presented. This actually worsens security. Especially if there's any way to silence such warnings, by disabling them for example, or having a utility that injects a confirmation into the module that handles the dialog.
I believe security can sell, but that paranoia and pestering won't. Mandatory access controls, role-based access controls and POSIX access control lists do not require pestering dialog. There are general-purpose operating systems rated A1 on the old Orange Book scale - the highest rating for host security you can get - and I doubt a single one requires massive user intervention to do anything more complex than Solitaire.
I would argue, then, that the article is wrong on Vista, that Vista is NOT the most secure offering from Microsoft because users stop trusting the security facility and are more likely to accidentally permit applications to do something stupid. You have to consider th wetware, and the wetware is very easily overloaded with trivia. Vista is only the most secure offering from Microsoft if nobody uses it.
There are generally two possible reasons - either the patent for something hasn't gone through and they're wanting to avoid too much of the wrong attention whilst still stirring up the interest of customers, OR there is a major flaw in the technology and they hope to fix it before anyone notices by hiding the details.
I have seen the latter, on two different startups I've had entanglements with. Wretched NDAs and the Old Boys Network mean you're not getting either story from me, but the fact is that dodgy use of trade secrets to hide flawed products is not unusual.
Ask the lead singer of Cameo.
Shhhhh! If they realize that, they'll go and add more to the file! Someone, hide the parent post, fast!
Twelve? Yeesh. FamilyTreeDNA offers 67 STRs and that's not considered to be adequate for anything more than family tree work. Hmmm. I doubt the 12 are within the 67, so for about $100 per person, they could improve the results substantially. deCODEme charts 1,000,000 SNPs per person, but their test is pricey at $1000. It would depend on how the cost of the test scales, but I imagine testing for 1,000 SNPs would again be around the $100 region. Given the trial costs per accused, and given the PR damage for every screw-up, that doesn't seem like a horrible burden. Even the $1000 test - I suspect most cop precincts spend that much on coffee and donuts in a week.
Oh god. It's a minor miracle they get so few duplicates with that method. Assuming they do, in fact, only have a few duplicates. That technique is positively stone-age and is open to all kinds of errors. That would make as much sense as the FDA using a speak-your-weight machine to measure microgram variations. (Oh god... I just thought... that would certainly explain a lot about the FDA...)
The MPs who have their own websites might be able to change their own passwords, but the Civil Service? C'mon, these are the guys that use "Yes, Prime Minister" as training material.