You can argue about whether the Erlang runtime constitutes an OS of sorts
AFAICS there's no argument at all. It is an OS; not a particularly good one, but one that provides scheduling, interprocess communication (albeit for what we'd traditionally consider to be threads rather than processes, but due to Erlang's memory/threading model there's actually no real distinction), memory management, and abstraction of IO (albeit somewhat simplified from the approach taken by a typical modern OS).
I think you'll find usage 1 is both a lot more common than usage 2, and almost certainly what was intended here.
There are lots of words that have two meanings, and it would be somewhat restrictive to say that everyone should avoid using them in case somebody interprets them the wrong way and potentially gets offended.
I don't see the point to encrypt the system partition because there is no private data on it. I just encrypt my home partition.
On Windows it is actually incredibly difficult to set up system and home to be on separate partitions. It can be done, but it means either using a hacked installer to make changes to the registry before users are created or messing around with symlinks after the users are created - plus i've heard reports of common software misbehaving after it has been done. It is therefore highly unlikely that this is a realistic option for OP.
+1 to this. I have a setup similar to the OP's (albeit with different software) and it has no impact at all on my backups, which I take in exactly the same way as I would were the system not encrypted, i.e. they access the files using the ordinary file system API and copy them to a different location (where they are, of course, reencrypted). I suppose the decrypt-compress-reencrypt cycle involved here is a little inefficient, but it doesn't seem to be a huge issue in reality.
As for increased number of write cycles, it's all down to the software you use. If the driver will emulate an SSD and pass through the 'trim' commands, you won't see any problems. At least some OTFE packages can do this. Truecrypts docs suggest that at least some configurations will work, although it does warn that using it means attackers will be able to potentially identify empty sectors. This means its use is incompatible with hidden volumes, but nothing in OP's description suggests he was using them.
That's a slightly different case, in that Sklyarov had been directly involved in performing the activities that were believed to be illegal, i.e. he wrote the code that broke PDF encryption thus prompting Adobe's original complaint. He wasn't just a random employee of ElcomSoft, but the employee of ElcomSoft who was essentially responsible for the company's actions. Now, as it turned out, the court ruled that the actions weren't illegal, but that's largely irrelevant to the argument at hand.
Simply because the corporation itself cannot be arrested. It may be easier for the CEO to be identified with the company than a low-level IT guy but I don't feel it's that black and white.
Yes it is. At least in common law countries anyway -- in those, directors, other officially nominated corporate officers (e,g, chairman, company secretary, etc) and (in rare cases) shareholders can be held liable for the company's actions and debts, but not ordinary employees.
But does that control your dvd player and stereo too?
Generally speaking, I'm using the media player built in to my TV for all my media-playing requirements these days, so while the answer is technically no, it does everything I need.
Can you turn off that annoying TV in the pub?
Generally speaking, I just tend to find a better pub. Works out best in the long term...
The problem is that they just end up listening to the pressure groups, who are basically an unelected elite selected for their capability to make every minor problem seem like a moral crisis that spells impending doom for civilization as we know it. I don't know the general fix for that, but politicians with at least a little knowledge of the areas they are legislating in seem to be better able to resist them.
IR port? It would be nice if I could get an app for my phone that controls my TV.
My samsung TV has a network-based protocol for that, no IR necessary. Or fiddly pointing of the device at the screen; I can just use it without picking it up from the arm of my chair.
At 441ppi, you should be able to resolve individual pixels at a distance of about 20cm. For the retina display the distance is about 27cm. For me, the natural distance I hold my phone from my eyes is about 40cm, so I doubt this will make much difference at all.
It's called versioning the protocol and having compatibility lists. When two clients connect, they exchange version numbers and if one is too old then the newer one performs additional checks to verify compatibility. If the issue is reconcilable then it aborts the connection with an error. Or programatically enforce that the older version is discontinued and that anyone who is using it can no longer participate in the chain.
How do you securely arrange such a system in a distributed network with no central authority? I contend that it is impossible, although perhaps somebody smarter than me could propose a workable scheme...
Which key-value store would you recommend using instead?
Depends on the type of keys and values, but if the keys are short and the values are typically larger than a few KB I've discovered that my operating system comes with this wonderful thing called a filesystem that seems to do the job quite nicely.
"A few hours" outage fails the most basic test of a currency - ability to spend it. For a few hours, no merchant could accept bitcoins as payment.
That is simply not true. Merchants could, and quite happily were, accepting bitcoin payments throughout the period of the failure.
"Incompatible fork[s]" causes bitcoin to fail yet another basic test of currency. The population should never be able to fork their currency into "new dollars", "old dollars" and "something which is most likely, in almost all cases, a mixture of both".
You misunderstand the basic concept of a fork in this situation. The currency was not forked -- the chain of signatures on the distributed transaction list used to validate ownership of the coins was. As the transaction lists should be basically the same between the two variants (and a manual effort can be made to ensure they are, which I presume somebody is now doing, and manual corrections inserted into the accepted fork if any transactions were omitted from it) there should be zero consequence of this for end users. The only issue is for those who signed the blocks in the rejected chain, who would have received a reward for doing so had it not been rejected.
A technical error should not introduce "little opportunity" for malfeasance. When my bank has a glitch, the cash in my wallet does not turn worthless for "a few hours".
Nobody's wallet turned worthless. The only potential opportunity for malfeasance works like this: if I owned BTC and attempted to make two transactions using the same coins simultaneously, there would have been a small but non-zero chance of both being accepted during the fork. One of the recipients, if they had dispatched goods immediately rather than waiting for a few hours, would have ended up out of pocket. On the other hand, those vendors are using a currency transfer system that has no per-transaction fee, and have likely saved more by not paying credit card handling charges over the years than they lost during the incident. And it's actually very unlikely that something like this would happen, anyway.
If I have already completed a transaction, with cash in hand, that transaction must not be "most likely" legitimate. It must be legitimate from the very moment that I verify the currency that I received as legitimate. It must not pass verification, then "most likely" have to pass verification again.
This is the only statement you make that's legitimate, although I would argue that it is no worse than current systems. As a vendor, I do not have access to any system other than physical cash that does not have this property -- money paid to me by credit card can be taken away if the bank is later convinced the transaction was fraudulent, for example. In most respects, bitcoin is an improvement over existing online payment systems.
You misunderstand the parent post. There was no outage -- transactions were processed as normal during the event. Only miners (i.e. people running the network for the random chance of being rewarded as recipient of newly created coins) may have lost out due to the error. Events like this were anticipated in the design, and the system has an automatic method of resolving it, which unfortunately leaves some miners out of pocket, but has no effect on general users.
No. The only problems concern miners, not currency use. Transfers, and transfer validation will all work as designed throughout, only those attempting to mine blocks using the newer version have any need to worry. The system was designed to account for the possibility of a chain fork, and to automatically reject one version once consensus is reached on which is "best", and the only reason any action is needed is to avoid miners being dissapointed by minimising the length of the fork (as anyone who mined a block in the rejected fork will not get a reward for it).
Imagine your employer operated on a scheme were instead of paying all of their employees every month they randomly picked an employee and gave them the entire month's pool every time. Now imagine the result of that random selection was ambiguous due to, say, nobody having noticed that two people had picked the same lottery numbers. They then decide arbitrarily in favour of one employee over the other. Does it sound as much like they've lost now?
Also: miners should be well aware that they aren't guaranteed to receive the bitcoins even if they do successfully produce a signed block. The system is designed to cope with the fact that such chain forks may occur and to resolve them automatically by checking which chain is longest. It's part of the protocol that they signed up for from the very beginning, so it's hard to argue they were in some way cheated.
So if I want to buy a chewing gum with BC, every BC user would neet to create a record of that transaction?
No, every user who wants to be able to check that transactions are valid needs to create a record of it. In the event of the network becoming too large, scaling would likely happen by service providers offering to validate transactions on behalf of customers for a small fee, thus relieving customers of the need to keep a copy of the transaction list. Anyone who wants to set up such a service provider could do so with relative ease.
If this becomes too hard to manage, a further simplification can be made: it would be entirely possible to use a system that summarises the block history list, so that you only have to hold (e.g.) the last few months worth of transactions. Of course, you'd have to trust your source of summaries, but at the moment we have to trust our banks and the credit card processing companies, so we're used to trusting people like this.
What makes bitcoin not scalable on the level of a real currency is the fact that the system is designed so that there can never be more than 21 million of them. OK, they can be subdivided, but even assuming you subdivide them to their technical limit, if the amount of money represented by BTC ever reaches the scale of the amount of USD that was in circulation as of 2008, that would be equivalent to the smallest possible unit of exchange being around 30c. Over time, this figure would increase. And as bitcoin can be lost (e.g. by data loss without backup, owners dying without a record of their passphrases, or simply by people forgetting they own them) and once lost can never be recovered (except by very expensive cryptographic key cracking exercises), the number in circulation is doomed to drop over time. This will merely exacerbate the problem.
Yes, that sounds sensible. Or perhaps a little simpler is this scheme: miners will probably end up skipping 0.8 and going directly to 0.9, which should artificially limit the size of blocks it signs while accepting larger blocks from other sources. Then, a later version will start producing the larger blocks once the developers are happy that all miners are using code that is compatible with the 0.9 standard.
This likely will not happen quickly: a lot of miners use custom hardware processors whose support software will need to be updated, and that software is not likely to be the mainline bitcoin client but a reimplementation of the protocol from scratch. The hardware designers will need to update their software, which might take a while to organise, if it is even possible (some hardware may have been designed with a 512KB buffer for the block to sign... I'm not sure of the precise details of how these chips work, but that seems a plausible scenario).
Now can you explain why exactly is the preferred solution to revert to the old, flawed, code rather than updating everything to the newer code that can properly handle the larger transactions?
Because updating everything is likely to be impossible. The system relies on a distributed network of data processors that perform very large numbers of difficult cryptographic operations in the hope of randomly hitting the right answer for a cash reward (this is what is referred to as 'mining' in the summary). Because of the high rewards offered, a lot of people have invested large amounts of money into these operations, with many of the larger players using hardware built around custom ICs (if you do google searches for 'bitcoin' and then 'asic' you'll start seeing adverts for them, even if you leave it months between the two searches...). These likely cannot be upgraded to the new version trivially, as it would rely on the developers of the chips providing updates to their support software -- that is, if it is even possible at all (they may have hard-coded that 512KB block size limit directly into their design).
Just ask yourself what Ayn Rand would do in the same situation.
Die in penniless poverty while dependent on the state to provide basic income and medical facilities that are necessary to maintain her life, all while maintaining that such a system is inherently evil? It's what I like to think of Ayn Rand doing in *any* situation.
Ok, this is going to burn karma like crazy... but an article about a guy named Dave Winer who is complaining? Seriously?
Oddly enough, he never seems to do anything else these days. The last time he was mentioned here, he was complaining that CS courses don't teach the kids about historic software (like the word processor he wrote back in the early 80s, which is clearly the best thing since sliced bread and should be a core component of every curriculum).
On a separate note: Did I miss something? They are talking about coding this up in databases, yet the code they give is in Java. It would be nice to see code in both Java and SQL
Their database is a NoSQL database that uses queries implemented as Java objects; it doesn't have a query language other than those objects.
Slashdot Mirror
You can argue about whether the Erlang runtime constitutes an OS of sorts
AFAICS there's no argument at all. It is an OS; not a particularly good one, but one that provides scheduling, interprocess communication (albeit for what we'd traditionally consider to be threads rather than processes, but due to Erlang's memory/threading model there's actually no real distinction), memory management, and abstraction of IO (albeit somewhat simplified from the approach taken by a typical modern OS).
I think you'll find usage 1 is both a lot more common than usage 2, and almost certainly what was intended here.
There are lots of words that have two meanings, and it would be somewhat restrictive to say that everyone should avoid using them in case somebody interprets them the wrong way and potentially gets offended.
On linux I would at least make sure that /tmp and swap are zeroed on shutdown/reboot.
Zeroing is over the top -- encrypt them with a key that is generated randomly at each boot.
I don't see the point to encrypt the system partition because there is no private data on it. I just encrypt my home partition.
On Windows it is actually incredibly difficult to set up system and home to be on separate partitions. It can be done, but it means either using a hacked installer to make changes to the registry before users are created or messing around with symlinks after the users are created - plus i've heard reports of common software misbehaving after it has been done. It is therefore highly unlikely that this is a realistic option for OP.
+1 to this. I have a setup similar to the OP's (albeit with different software) and it has no impact at all on my backups, which I take in exactly the same way as I would were the system not encrypted, i.e. they access the files using the ordinary file system API and copy them to a different location (where they are, of course, reencrypted). I suppose the decrypt-compress-reencrypt cycle involved here is a little inefficient, but it doesn't seem to be a huge issue in reality.
As for increased number of write cycles, it's all down to the software you use. If the driver will emulate an SSD and pass through the 'trim' commands, you won't see any problems. At least some OTFE packages can do this. Truecrypts docs suggest that at least some configurations will work, although it does warn that using it means attackers will be able to potentially identify empty sectors. This means its use is incompatible with hidden volumes, but nothing in OP's description suggests he was using them.
That's a slightly different case, in that Sklyarov had been directly involved in performing the activities that were believed to be illegal, i.e. he wrote the code that broke PDF encryption thus prompting Adobe's original complaint. He wasn't just a random employee of ElcomSoft, but the employee of ElcomSoft who was essentially responsible for the company's actions. Now, as it turned out, the court ruled that the actions weren't illegal, but that's largely irrelevant to the argument at hand.
Simply because the corporation itself cannot be arrested. It may be easier for the CEO to be identified with the company than a low-level IT guy but I don't feel it's that black and white.
Yes it is. At least in common law countries anyway -- in those, directors, other officially nominated corporate officers (e,g, chairman, company secretary, etc) and (in rare cases) shareholders can be held liable for the company's actions and debts, but not ordinary employees.
But does that control your dvd player and stereo too?
Generally speaking, I'm using the media player built in to my TV for all my media-playing requirements these days, so while the answer is technically no, it does everything I need.
Can you turn off that annoying TV in the pub?
Generally speaking, I just tend to find a better pub. Works out best in the long term...
The problem is that they just end up listening to the pressure groups, who are basically an unelected elite selected for their capability to make every minor problem seem like a moral crisis that spells impending doom for civilization as we know it. I don't know the general fix for that, but politicians with at least a little knowledge of the areas they are legislating in seem to be better able to resist them.
IR port? It would be nice if I could get an app for my phone that controls my TV.
My samsung TV has a network-based protocol for that, no IR necessary. Or fiddly pointing of the device at the screen; I can just use it without picking it up from the arm of my chair.
At 441ppi, you should be able to resolve individual pixels at a distance of about 20cm. For the retina display the distance is about 27cm. For me, the natural distance I hold my phone from my eyes is about 40cm, so I doubt this will make much difference at all.
I'm thinking this film is the one we're currently in.
It's called versioning the protocol and having compatibility lists. When two clients connect, they exchange version numbers and if one is too old then the newer one performs additional checks to verify compatibility. If the issue is reconcilable then it aborts the connection with an error. Or programatically enforce that the older version is discontinued and that anyone who is using it can no longer participate in the chain.
How do you securely arrange such a system in a distributed network with no central authority? I contend that it is impossible, although perhaps somebody smarter than me could propose a workable scheme...
Which key-value store would you recommend using instead?
Depends on the type of keys and values, but if the keys are short and the values are typically larger than a few KB I've discovered that my operating system comes with this wonderful thing called a filesystem that seems to do the job quite nicely.
"A few hours" outage fails the most basic test of a currency - ability to spend it. For a few hours, no merchant could accept bitcoins as payment.
That is simply not true. Merchants could, and quite happily were, accepting bitcoin payments throughout the period of the failure.
"Incompatible fork[s]" causes bitcoin to fail yet another basic test of currency. The population should never be able to fork their currency into "new dollars", "old dollars" and "something which is most likely, in almost all cases, a mixture of both".
You misunderstand the basic concept of a fork in this situation. The currency was not forked -- the chain of signatures on the distributed transaction list used to validate ownership of the coins was. As the transaction lists should be basically the same between the two variants (and a manual effort can be made to ensure they are, which I presume somebody is now doing, and manual corrections inserted into the accepted fork if any transactions were omitted from it) there should be zero consequence of this for end users. The only issue is for those who signed the blocks in the rejected chain, who would have received a reward for doing so had it not been rejected.
A technical error should not introduce "little opportunity" for malfeasance. When my bank has a glitch, the cash in my wallet does not turn worthless for "a few hours".
Nobody's wallet turned worthless. The only potential opportunity for malfeasance works like this: if I owned BTC and attempted to make two transactions using the same coins simultaneously, there would have been a small but non-zero chance of both being accepted during the fork. One of the recipients, if they had dispatched goods immediately rather than waiting for a few hours, would have ended up out of pocket. On the other hand, those vendors are using a currency transfer system that has no per-transaction fee, and have likely saved more by not paying credit card handling charges over the years than they lost during the incident. And it's actually very unlikely that something like this would happen, anyway.
If I have already completed a transaction, with cash in hand, that transaction must not be "most likely" legitimate. It must be legitimate from the very moment that I verify the currency that I received as legitimate. It must not pass verification, then "most likely" have to pass verification again.
This is the only statement you make that's legitimate, although I would argue that it is no worse than current systems. As a vendor, I do not have access to any system other than physical cash that does not have this property -- money paid to me by credit card can be taken away if the bank is later convinced the transaction was fraudulent, for example. In most respects, bitcoin is an improvement over existing online payment systems.
You misunderstand the parent post. There was no outage -- transactions were processed as normal during the event. Only miners (i.e. people running the network for the random chance of being rewarded as recipient of newly created coins) may have lost out due to the error. Events like this were anticipated in the design, and the system has an automatic method of resolving it, which unfortunately leaves some miners out of pocket, but has no effect on general users.
No. The only problems concern miners, not currency use. Transfers, and transfer validation will all work as designed throughout, only those attempting to mine blocks using the newer version have any need to worry. The system was designed to account for the possibility of a chain fork, and to automatically reject one version once consensus is reached on which is "best", and the only reason any action is needed is to avoid miners being dissapointed by minimising the length of the fork (as anyone who mined a block in the rejected fork will not get a reward for it).
Imagine your employer operated on a scheme were instead of paying all of their employees every month they randomly picked an employee and gave them the entire month's pool every time. Now imagine the result of that random selection was ambiguous due to, say, nobody having noticed that two people had picked the same lottery numbers. They then decide arbitrarily in favour of one employee over the other. Does it sound as much like they've lost now?
Also: miners should be well aware that they aren't guaranteed to receive the bitcoins even if they do successfully produce a signed block. The system is designed to cope with the fact that such chain forks may occur and to resolve them automatically by checking which chain is longest. It's part of the protocol that they signed up for from the very beginning, so it's hard to argue they were in some way cheated.
So if I want to buy a chewing gum with BC, every BC user would neet to create a record of that transaction?
No, every user who wants to be able to check that transactions are valid needs to create a record of it. In the event of the network becoming too large, scaling would likely happen by service providers offering to validate transactions on behalf of customers for a small fee, thus relieving customers of the need to keep a copy of the transaction list. Anyone who wants to set up such a service provider could do so with relative ease.
If this becomes too hard to manage, a further simplification can be made: it would be entirely possible to use a system that summarises the block history list, so that you only have to hold (e.g.) the last few months worth of transactions. Of course, you'd have to trust your source of summaries, but at the moment we have to trust our banks and the credit card processing companies, so we're used to trusting people like this.
What makes bitcoin not scalable on the level of a real currency is the fact that the system is designed so that there can never be more than 21 million of them. OK, they can be subdivided, but even assuming you subdivide them to their technical limit, if the amount of money represented by BTC ever reaches the scale of the amount of USD that was in circulation as of 2008, that would be equivalent to the smallest possible unit of exchange being around 30c. Over time, this figure would increase. And as bitcoin can be lost (e.g. by data loss without backup, owners dying without a record of their passphrases, or simply by people forgetting they own them) and once lost can never be recovered (except by very expensive cryptographic key cracking exercises), the number in circulation is doomed to drop over time. This will merely exacerbate the problem.
Yes, that sounds sensible. Or perhaps a little simpler is this scheme: miners will probably end up skipping 0.8 and going directly to 0.9, which should artificially limit the size of blocks it signs while accepting larger blocks from other sources. Then, a later version will start producing the larger blocks once the developers are happy that all miners are using code that is compatible with the 0.9 standard.
This likely will not happen quickly: a lot of miners use custom hardware processors whose support software will need to be updated, and that software is not likely to be the mainline bitcoin client but a reimplementation of the protocol from scratch. The hardware designers will need to update their software, which might take a while to organise, if it is even possible (some hardware may have been designed with a 512KB buffer for the block to sign... I'm not sure of the precise details of how these chips work, but that seems a plausible scenario).
Now can you explain why exactly is the preferred solution to revert to the old, flawed, code rather than updating everything to the newer code that can properly handle the larger transactions?
Because updating everything is likely to be impossible. The system relies on a distributed network of data processors that perform very large numbers of difficult cryptographic operations in the hope of randomly hitting the right answer for a cash reward (this is what is referred to as 'mining' in the summary). Because of the high rewards offered, a lot of people have invested large amounts of money into these operations, with many of the larger players using hardware built around custom ICs (if you do google searches for 'bitcoin' and then 'asic' you'll start seeing adverts for them, even if you leave it months between the two searches...). These likely cannot be upgraded to the new version trivially, as it would rely on the developers of the chips providing updates to their support software -- that is, if it is even possible at all (they may have hard-coded that 512KB block size limit directly into their design).
Just ask yourself what Ayn Rand would do in the same situation.
Die in penniless poverty while dependent on the state to provide basic income and medical facilities that are necessary to maintain her life, all while maintaining that such a system is inherently evil? It's what I like to think of Ayn Rand doing in *any* situation.
That link didn't go where I was expecting it to go.
Ok, this is going to burn karma like crazy... but an article about a guy named Dave Winer who is complaining? Seriously?
Oddly enough, he never seems to do anything else these days. The last time he was mentioned here, he was complaining that CS courses don't teach the kids about historic software (like the word processor he wrote back in the early 80s, which is clearly the best thing since sliced bread and should be a core component of every curriculum).
On a separate note: Did I miss something? They are talking about coding this up in databases, yet the code they give is in Java. It would be nice to see code in both Java and SQL
Their database is a NoSQL database that uses queries implemented as Java objects; it doesn't have a query language other than those objects.