I think the Wikipedia is a bit short on details for Z-RAM, so I'll provide an additional link. As you can see this leads to the company behind Z-RAM, so they may look a bit too much on the possitive side. It sounds very promissing, I must say. Only for SOI though, so Intel is left out a bit here, but very interesing for IBM or AMD. I wouldn't be surprised to see eDRAM or Z-RAM in chips pretty soon, since they don't seem to require too much rework.
"Or in other words: wouldn't it be better to just run the database in RAM?"
That does not operate on a battery. If you put - as the other poster suggested - a journalled filesystem on there (e.g. ZFS) then this device would not fail even on an unexpected shutdown, and there is little or no chance that it can be corrupted by the OS or another application. Unless the OS or the application mess with the filesystem of course. It's a bit of a shame that they don't allow more than 4 GB or ECC memory or hot swap, so this device doesn't seem to go all the way either.
Currently I always run a tiny 64 MB ramdrive in Windows so that logfiles don't mess up my timing. With the current processors and RAM, the overhead is neglectible. Just an additional tip:)
Ehm, just a thought: first you put a possitive V on one side, making it go to the right (picture b). After that you put a (higher) possitive voltage to the outer tube (note that it is also connected, initially to the ground). The left simply acts as ground, not atracting the inner tube. Could this work? This would also mean that the tube would stay attracted to the right, solving the first problem you came up with.
Every kid should at least read all the stuff from Captain Copyright, so it's a bit ashamed that this site is now down. Of course, I don't mean the cartoons, I am talking about the more than terrible copyright page of the captain himself. After they have read all of that they know what is wrong with society.
"This is what makes movie DRM untenable. Since the format of the disks is publicly known (to insure that UNencrypted disks operate correctly), attackers know that they can discard solutions after decrypting very little of the ciphertext (probably just one byte)."
Bollocks. AES (used by AACS) and many other ciphers are pretty well protected against known plain text attacks. Furthermore, with common block sizes of 8 and 16 bytes it would be very hard to decrypt just a single byte.
I think the CEO of Oakley Networks has seen too many Inspector Gadget cartoons:
... or have some way of ensuring that certain types of activities indicative of somebody trying to break into the data would result in an automatic destruct.
Maybe they should order some old Dell laptops and short cirtuit the battery after too many bad logins to the hard drive encryption.
Oh, and they are considering using encryption to protect their data? Can someone please send these guys a clue-stick?
For a new C++ with multithreading language extensions (for manually coding the multithreading), good API and IDE/tool support, look no further. It's called Java and it has been around for ages. You really, really, really don't want multithreading in a non-"managed" language. You don't want to debug an application where *every* part of your application can be messed up by any thread. The advantage of Java is that the build in security meassurements.
Things you need to have support for in a language/environment: - All the usual multithreading design patterns in the API (producer/consumer, stream support, stacks etc); - Thread safe collections; - A keyword and mechanism to do locking ("synchronized" in Java, "volatile" is handy for optimizations); - Memory protection; - Multi-threading supporting debuggers (at least halt all functionality) - Very well documented API, especially if classes are thread safe and how to use them; - If anyway possible, automated code checking tools for multi-threading (won't catch every multi-threading error, but are very usefull). Furthermore it's very important to make sure you can use the API's on different platforms if you expect to port the application in the future. Also, since threading may be expensive, a lightweight version of threads may be usefull as well.
It's not just adding a language extension for threading. Support must go much further than that. Especially the API documentation is important in this respect. Unfortunately there are always parts of the API that are not really usefull for multithreading, such as the Date classes in Java (they suck in all other aspects as well, to be honest).
If you are every going to try Java, make sure to not use arrays too much. You cannot prevent write access to arrays, so any thread that has a reference to an array may change it all the time. Try and use immutable classes as much as you can (BigInteger, BigDecimal and of course Strings are all immutable), and make defensive copies when needed. In C++ any thread can mess up any data element by simply casting, something that is done *way* to much in C++ anyway. You can also use C#, but a quick google search scan shows that C# multithreading is not used as much as can, and getting support might be much more difficult. At least you can make the collections thread safe.
Java has a rather simple problem. Its API is huge. And currently this means that you need to download an entire JRE to upgrade. This is a bit much for most people. Fortunately there are plans to make use of Java components. (Web) applications would only have to download the pieces that are needed, making Java downloads much easier. If you also know that a single VM will be able to run multiple applications at once in the near future things already get better. Then there are the current speedups that have been implemented in Java 6 and 7. Also there is the pending open sourcing of Java (which makes it easier to make lean and mean Java plugings). Since Java won't go away, I would not be terrible surprised if it is able to come back even as applets and such.
Yeah, say we manage to wipe everything out and the people of the ISS return home, travel to the little island to get the seeds, just to find out that there aren't any bees left to pollenate the apple tree in their little garden of eden in the middle of a completely sterile planet.
"Actually when they've investigated, it turns almost every disgruntled shooter DID give signs beforehand. It was just that most co-workers, manager, and neighbors ignored the signs or were clueless that they were significant."
Yeah, but most importantly, they probably did not give a damn. I'm 100% sure that if you would ask these people what there biggest grunt against the company was that they felt ignored and undervalued. Of course, there will always be people that don't need things like complete ignorance to do something stupid, but I believe most times this is not the case.
This will generate some much needed criticism of Skype. It's not only that it is closed source, it's a closed protocol as well. I presume every Skype phone will have to pay nice amount of royalties.
Basically Skype is not much more than VOIP. What it has going is a lot of hype, a cool name and an efficient way of doing the networking. But even then I have always been very sceptical of Skype. Unfortunately I haven't seen this reflected in real life. People simply buy Skype phones - even ones that only know how to do Skype - without realizing they are setting up a new monopoly again.
And, as you can see, monopolies can do really bad stuff. Maybe this will turn out to be nothing spectacular, but who says that the next time this will be the case? It's not that I hold eBay in such a high esteem either (although this is mostly gut-feeling).
"I suppose these devices will not be legal for civilian use where they conflict with trash and recycling industry."
In that case they should create new laws, because it's my trash. I can do whatever I want with it, providing that it doesn't break any existing laws. What the recycling companies think about it surely is not my problem. Since this is a souped up diesel generator, I would not want in my appartment though. First of all, it would hardly fit, and second it would probably be noisy as hell. And I would probably gas myself to death first.
Now compare it with that of OpenID, if you can find it on their wiki-like site. IMHO, this is just FUD to keep wind out of the sails of the Liberty Alliance. The same stupid tactic they have performed with the open source document format. Kill it by strengthening the currently loosing spec, and both will perish.
In our democracy (well, kingdom officially, just like yours) the "first chamber" is set by old party members that have more or less retired. Sometimes someone young comes in, but most of the time they are old geysers that don't have to care too much about party lines and becoming popular. They are, just like the house of commons, a security net, that catches the most disturbing stupidities (they may accept or reject laws, but not actually propose laws). Fortunately, this group of people generally consist of rather intelligent, weathered politicians instead of a group of wig-wearing loonies (no offense meant, but that's my impression of the house of commons). They are choosen by the directly choosen representatives of the provinces of the Netherlands.
Astma is a chronic disease. One you don't die from. You are just waiting for some disease to *really* fuck up your life. And unless you die from a sudden attack, it's almost certain you will get one - maybe some others before that. We'll talk to you after you payed that off - if you ever can. So the other citizens will have to do that for you.
It's pretty easy to think that paying up insurance if nothing much is happening. When something does, I suspect you are the first person to shout that medical costs are ridiculously high. If I look at the medical costs of my parents they would cover of a small company alone (and I don't mean income, I mean all the assets). And thats assuming that you will keep making money the way you are now - check how many companies go broke and ask yourself what would happen if all these people are not insured.
"To clarify, I was a Soldier in West Germany in the early 1980's (three minutes to midnight on the Doomsday Clock); our unit was expected to survive for about three weeks in the event of a NATO / Warsaw Pact conflict (other units were as low as a few hours). Yes, I was protecting him indirectly, just as millions of Soldiers and Police protect the rest of us (myself included) every day."
First of all, "soldier" and "police" are spelled using undercase letters. So are doctor, fireman, and aid-worker - professions that I and many others hold in high esteem as well. But mostly, here's me thinking that Europe wouldn't have lasted that long. Neither would the Sovjet Union or the USA for that matter. Maybe the world.
"In the 1980's, there was no such thing as deployed pay for overseas duty, and we paid all federal and state taxes as well as Social Security. Hazardous Duty Pay today is still only about $150 a month."
I would call hazardous duty pay while stationed in West-Germany in the 1980's a bit of nonsense myself. I presume that Iraq and Afghanistan are completely different matters. The trick about the cold war was that you had very little reason to be killed, unless the conflict went warm. And in that case it would have gotten too hot for *everybody* really, really quick.
"Yes, we given "three hots and a cot", and our facilities were decent. However, when you are in the field, your living conditions can be a bit primitive, and you can be out there for quite a while. Yes, there were benefits, but the downside risks are very serious. You never forget the first time you are given mission load (the ammunition you will use) and told "this is not an exercise". Thankfully, I never faced combat, especially since a war in 1980's Europe would have gotten very ugly, very quickly."
Yeah. So primitive that whole cities in Germany face bankrupcy now that the big spending Americans have gone. And Germany can hardly be called third or second world country.
"In my original post, I just wanted to point out that we each have our cross to bear and we each chose it."
Don't get me wrong, I am rather glad that I don't live in a communist country (although I would have much preferred that over war) and I admire your sense of duty. But being stationed in West-Germany is not that big a cross.
This attack is a form of a relay attack. These kind of attacks can be really, really hard to avoid. Basically you need both sides to be authenticated and communicate in a secure fashion. Both sides also need to be secured ("tamper resistant" or, if possible "tamper proof"). And to top it off you must be sure that anything you sign is really correct, and that the human input (if any) isn't listened upon. Of course, you must use something to confirm the transaction as well.
Basically it comes down to the fact that this is almost impossible to accomplish. As shown, it's pretty easy to replace the terminal by a fake one. I can remember an attack where a complete ATM was even replaced by a fake one. It might be possible to see keypresses through emitted radio waves. There is some discussion about contactless credit cards that don't need PIN entry for small transactions; bad idea, it's possible to simply relay the signal from other terminals and have someone use many, many small transactions from someone elses card. If you cannot trust the screen, there is literally no way to see which transaction you are signing - this is for instance a problem with many banking sites, even if they do authenticate individual (agregated) transactions.
Of course there are levels of security. Chip security is better than magnetic stripe security because the contents of the chip (and especially the key) cannot be (easily) copied. You can use a secure channel - if anywhere possible with terminal authentication - to hide the PIN as well, and really sign the transaction. Also, there is no need to store the PIN or PIN hash at the bank (currently any bank-employee with access to the PIN hash database can calculate the PIN in mere nanoseconds). But, as shown, it does *not* prevent against fake terminals - there are terminals with secure memory that could do terminal authentication and are tamper proof, but these are rather expensive.
I'm sorry if this response become something of a mess. Please be so kind to blame it on the inherent difficulty of secure transactions:)
"The extra step the researchers added is that the terminal sends the card a single bit *challenge* -- a 0 or 1 -- and the card *responds* in kind. The terminal can record how much time elapsed between sending and receiving the response, which would be a few nanoseconds in a normal transaction."
A challenge response is otherwise known as a handshake. They took a small challenge because otherwise the handshake would take too much time, making the method meaningless. A few nanoseconds is a bit on the possitive side, especially since the communication time between the reader and card would take much more than that.
Furthermore, it's impossible to use a signle bit. With 3DES you have a block size of 8 bytes, with AES the block size is 16 bytes and with RSA and other asymetric ciphers you normally use padding up to the key length (128 bytes for a 1024 bit key). So it's unclear to me what is exactly meant by this solution. Probably ZD messed up here; there are few people that really understand practical cryptography.
Oh, the same thing exists for linux as well. PGP has support for smart cards, as well as GPG does. The problem is that the certificates of the other users won't be on the smart card, and that the computer you are working on needs to have hardware and middleware installed to use it. Smartcard make things more secure, but not easier to use.
Slashdot Mirror
I think the Wikipedia is a bit short on details for Z-RAM, so I'll provide an additional link. As you can see this leads to the company behind Z-RAM, so they may look a bit too much on the possitive side. It sounds very promissing, I must say. Only for SOI though, so Intel is left out a bit here, but very interesing for IBM or AMD. I wouldn't be surprised to see eDRAM or Z-RAM in chips pretty soon, since they don't seem to require too much rework.
"Or in other words: wouldn't it be better to just run the database in RAM?"
:)
That does not operate on a battery. If you put - as the other poster suggested - a journalled filesystem on there (e.g. ZFS) then this device would not fail even on an unexpected shutdown, and there is little or no chance that it can be corrupted by the OS or another application. Unless the OS or the application mess with the filesystem of course. It's a bit of a shame that they don't allow more than 4 GB or ECC memory or hot swap, so this device doesn't seem to go all the way either.
Currently I always run a tiny 64 MB ramdrive in Windows so that logfiles don't mess up my timing. With the current processors and RAM, the overhead is neglectible. Just an additional tip
Ehm, just a thought: first you put a possitive V on one side, making it go to the right (picture b). After that you put a (higher) possitive voltage to the outer tube (note that it is also connected, initially to the ground). The left simply acts as ground, not atracting the inner tube. Could this work? This would also mean that the tube would stay attracted to the right, solving the first problem you came up with.
Every kid should at least read all the stuff from Captain Copyright, so it's a bit ashamed that this site is now down. Of course, I don't mean the cartoons, I am talking about the more than terrible copyright page of the captain himself. After they have read all of that they know what is wrong with society.
"This is what makes movie DRM untenable. Since the format of the disks is publicly known (to insure that UNencrypted disks operate correctly), attackers know that they can discard solutions after decrypting very little of the ciphertext (probably just one byte)."
Bollocks. AES (used by AACS) and many other ciphers are pretty well protected against known plain text attacks. Furthermore, with common block sizes of 8 and 16 bytes it would be very hard to decrypt just a single byte.
No it wasn't.
No, more than one US of A would be too much for one single world.
Why? The grand-parent post is indeed interesting - at least for someone not already into politics - but off-topic none-the-less
Maybe they should order some old Dell laptops and short cirtuit the battery after too many bad logins to the hard drive encryption.
Oh, and they are considering using encryption to protect their data? Can someone please send these guys a clue-stick?
For a new C++ with multithreading language extensions (for manually coding the multithreading), good API and IDE/tool support, look no further. It's called Java and it has been around for ages. You really, really, really don't want multithreading in a non-"managed" language. You don't want to debug an application where *every* part of your application can be messed up by any thread. The advantage of Java is that the build in security meassurements.
Things you need to have support for in a language/environment:
- All the usual multithreading design patterns in the API (producer/consumer, stream support, stacks etc);
- Thread safe collections;
- A keyword and mechanism to do locking ("synchronized" in Java, "volatile" is handy for optimizations);
- Memory protection;
- Multi-threading supporting debuggers (at least halt all functionality)
- Very well documented API, especially if classes are thread safe and how to use them;
- If anyway possible, automated code checking tools for multi-threading (won't catch every multi-threading error, but are very usefull).
Furthermore it's very important to make sure you can use the API's on different platforms if you expect to port the application in the future. Also, since threading may be expensive, a lightweight version of threads may be usefull as well.
It's not just adding a language extension for threading. Support must go much further than that. Especially the API documentation is important in this respect. Unfortunately there are always parts of the API that are not really usefull for multithreading, such as the Date classes in Java (they suck in all other aspects as well, to be honest).
If you are every going to try Java, make sure to not use arrays too much. You cannot prevent write access to arrays, so any thread that has a reference to an array may change it all the time. Try and use immutable classes as much as you can (BigInteger, BigDecimal and of course Strings are all immutable), and make defensive copies when needed. In C++ any thread can mess up any data element by simply casting, something that is done *way* to much in C++ anyway. You can also use C#, but a quick google search scan shows that C# multithreading is not used as much as can, and getting support might be much more difficult. At least you can make the collections thread safe.
Java has a rather simple problem. Its API is huge. And currently this means that you need to download an entire JRE to upgrade. This is a bit much for most people. Fortunately there are plans to make use of Java components. (Web) applications would only have to download the pieces that are needed, making Java downloads much easier. If you also know that a single VM will be able to run multiple applications at once in the near future things already get better. Then there are the current speedups that have been implemented in Java 6 and 7. Also there is the pending open sourcing of Java (which makes it easier to make lean and mean Java plugings). Since Java won't go away, I would not be terrible surprised if it is able to come back even as applets and such.
Yeah, say we manage to wipe everything out and the people of the ISS return home, travel to the little island to get the seeds, just to find out that there aren't any bees left to pollenate the apple tree in their little garden of eden in the middle of a completely sterile planet.
I agree, please mod parent clueless.
"128kbps mp3 isn't even worth listening to, unless you're into poetry/other spoken material"
Can I have your FM receiver? Sounds like you won't be needing it anymore.
"Actually when they've investigated, it turns almost every disgruntled shooter DID give signs beforehand. It was just that most co-workers, manager, and neighbors ignored the signs or were clueless that they were significant."
Yeah, but most importantly, they probably did not give a damn. I'm 100% sure that if you would ask these people what there biggest grunt against the company was that they felt ignored and undervalued. Of course, there will always be people that don't need things like complete ignorance to do something stupid, but I believe most times this is not the case.
This will generate some much needed criticism of Skype. It's not only that it is closed source, it's a closed protocol as well. I presume every Skype phone will have to pay nice amount of royalties.
Basically Skype is not much more than VOIP. What it has going is a lot of hype, a cool name and an efficient way of doing the networking. But even then I have always been very sceptical of Skype. Unfortunately I haven't seen this reflected in real life. People simply buy Skype phones - even ones that only know how to do Skype - without realizing they are setting up a new monopoly again.
And, as you can see, monopolies can do really bad stuff. Maybe this will turn out to be nothing spectacular, but who says that the next time this will be the case? It's not that I hold eBay in such a high esteem either (although this is mostly gut-feeling).
"I suppose these devices will not be legal for civilian use where
they conflict with trash and recycling industry."
In that case they should create new laws, because it's my trash. I can do whatever I want with it, providing that it doesn't break any existing laws. What the recycling companies think about it surely is not my problem. Since this is a souped up diesel generator, I would not want in my appartment though. First of all, it would hardly fit, and second it would probably be noisy as hell. And I would probably gas myself to death first.
"I didn't RTFA to see how the generator works, but I'll bet it's something like an old steamtrain."
IMHO !RTFA ==> STFU
Of course, MS would not want to support the Sun answer to Passport: the Liberty Alliance. Check the current member list here:
n t_members
http://www.projectliberty.org/liberty/about/curre
Now compare it with that of OpenID, if you can find it on their wiki-like site. IMHO, this is just FUD to keep wind out of the sails of the Liberty Alliance. The same stupid tactic they have performed with the open source document format. Kill it by strengthening the currently loosing spec, and both will perish.
In our democracy (well, kingdom officially, just like yours) the "first chamber" is set by old party members that have more or less retired. Sometimes someone young comes in, but most of the time they are old geysers that don't have to care too much about party lines and becoming popular. They are, just like the house of commons, a security net, that catches the most disturbing stupidities (they may accept or reject laws, but not actually propose laws). Fortunately, this group of people generally consist of rather intelligent, weathered politicians instead of a group of wig-wearing loonies (no offense meant, but that's my impression of the house of commons). They are choosen by the directly choosen representatives of the provinces of the Netherlands.
Maybe something to copy?
Astma is a chronic disease. One you don't die from. You are just waiting for some disease to *really* fuck up your life. And unless you die from a sudden attack, it's almost certain you will get one - maybe some others before that. We'll talk to you after you payed that off - if you ever can. So the other citizens will have to do that for you.
It's pretty easy to think that paying up insurance if nothing much is happening. When something does, I suspect you are the first person to shout that medical costs are ridiculously high. If I look at the medical costs of my parents they would cover of a small company alone (and I don't mean income, I mean all the assets). And thats assuming that you will keep making money the way you are now - check how many companies go broke and ask yourself what would happen if all these people are not insured.
"To clarify, I was a Soldier in West Germany in the early 1980's (three minutes to midnight on the Doomsday Clock); our unit was expected to survive for about three weeks in the event of a NATO / Warsaw Pact conflict (other units were as low as a few hours). Yes, I was protecting him indirectly, just as millions of Soldiers and Police protect the rest of us (myself included) every day."
First of all, "soldier" and "police" are spelled using undercase letters. So are doctor, fireman, and aid-worker - professions that I and many others hold in high esteem as well. But mostly, here's me thinking that Europe wouldn't have lasted that long. Neither would the Sovjet Union or the USA for that matter. Maybe the world.
"In the 1980's, there was no such thing as deployed pay for overseas duty, and we paid all federal and state taxes as well as Social Security. Hazardous Duty Pay today is still only about $150 a month."
I would call hazardous duty pay while stationed in West-Germany in the 1980's a bit of nonsense myself. I presume that Iraq and Afghanistan are completely different matters. The trick about the cold war was that you had very little reason to be killed, unless the conflict went warm. And in that case it would have gotten too hot for *everybody* really, really quick.
"Yes, we given "three hots and a cot", and our facilities were decent. However, when you are in the field, your living conditions can be a bit primitive, and you can be out there for quite a while. Yes, there were benefits, but the downside risks are very serious. You never forget the first time you are given mission load (the ammunition you will use) and told "this is not an exercise". Thankfully, I never faced combat, especially since a war in 1980's Europe would have gotten very ugly, very quickly."
Yeah. So primitive that whole cities in Germany face bankrupcy now that the big spending Americans have gone. And Germany can hardly be called third or second world country.
"In my original post, I just wanted to point out that we each have our cross to bear and we each chose it."
Don't get me wrong, I am rather glad that I don't live in a communist country (although I would have much preferred that over war) and I admire your sense of duty. But being stationed in West-Germany is not that big a cross.
This attack is a form of a relay attack. These kind of attacks can be really, really hard to avoid. Basically you need both sides to be authenticated and communicate in a secure fashion. Both sides also need to be secured ("tamper resistant" or, if possible "tamper proof"). And to top it off you must be sure that anything you sign is really correct, and that the human input (if any) isn't listened upon. Of course, you must use something to confirm the transaction as well.
:)
Basically it comes down to the fact that this is almost impossible to accomplish. As shown, it's pretty easy to replace the terminal by a fake one. I can remember an attack where a complete ATM was even replaced by a fake one. It might be possible to see keypresses through emitted radio waves. There is some discussion about contactless credit cards that don't need PIN entry for small transactions; bad idea, it's possible to simply relay the signal from other terminals and have someone use many, many small transactions from someone elses card. If you cannot trust the screen, there is literally no way to see which transaction you are signing - this is for instance a problem with many banking sites, even if they do authenticate individual (agregated) transactions.
Of course there are levels of security. Chip security is better than magnetic stripe security because the contents of the chip (and especially the key) cannot be (easily) copied. You can use a secure channel - if anywhere possible with terminal authentication - to hide the PIN as well, and really sign the transaction. Also, there is no need to store the PIN or PIN hash at the bank (currently any bank-employee with access to the PIN hash database can calculate the PIN in mere nanoseconds). But, as shown, it does *not* prevent against fake terminals - there are terminals with secure memory that could do terminal authentication and are tamper proof, but these are rather expensive.
I'm sorry if this response become something of a mess. Please be so kind to blame it on the inherent difficulty of secure transactions
"The extra step the researchers added is that the terminal sends the card a single bit *challenge* -- a 0 or 1 -- and the card *responds* in kind. The terminal can record how much time elapsed between sending and receiving the response, which would be a few nanoseconds in a normal transaction."
A challenge response is otherwise known as a handshake. They took a small challenge because otherwise the handshake would take too much time, making the method meaningless. A few nanoseconds is a bit on the possitive side, especially since the communication time between the reader and card would take much more than that.
Furthermore, it's impossible to use a signle bit. With 3DES you have a block size of 8 bytes, with AES the block size is 16 bytes and with RSA and other asymetric ciphers you normally use padding up to the key length (128 bytes for a 1024 bit key). So it's unclear to me what is exactly meant by this solution. Probably ZD messed up here; there are few people that really understand practical cryptography.
Oh, the same thing exists for linux as well. PGP has support for smart cards, as well as GPG does. The problem is that the certificates of the other users won't be on the smart card, and that the computer you are working on needs to have hardware and middleware installed to use it. Smartcard make things more secure, but not easier to use.