No, because the 2nd drive provides redundancy - if drive 1 fails then you restore from drive 2. There's a slight possibility that both drives fail at the same time but that's a very remote chance.
I think we are describing the same thing. Facebook convinced a couple manufacturers to pre-install that overlay in shipped units, and those probably did not sell great. But the overlay can still be manually installed from Google Play store, as far as I know, as is still in active development. I don't know how many downloads have been made to date.
I think it's mostly because I just don't like dealing with people. I'm not anti-social enough to refuse the exchange of pleasantries when I have to deal with someone, but I am anti-social enough that I really don't want to be bothered. Since I go through self-checkout 95% of the time (sometimes even waiting for a self-checkout lane when there's a staffed lane open), I also now find it vaguely creepy to have someone pawing through my stuff. I know that in either case the computers are tallying it all and my purchase history is being datamined, but I don't care about that. People looking through my stuff bothers me.
Not marketing, except from the perspective of engineers to whom any portion of the business processes not related to technology gets called "marketing". IBM did all of the marketing relevant to the success of MS-DOS. Microsoft's coup was in brokering a deal with IBM and being smart enough to make it a per-copy licensing deal rather than selling the software outright.
The minimum transaction fee changed from 0.0005 BTC to 0.0001 BTC during the runup to $1100
Which is exactly the problem they are referring to. The fee dropped to the point of being not worth it.
Yes, but their conclusion is wrong in two ways, because the two parameters (fee and cost) are both variables.
The fee is actually a market-driven value, essentially a distributed real-time auction. Those who perform transactions bid for the services of the miners who generate the blocks to record the transactions. You're free to place any bid you want, but if there are higher bids available the miners will take those instead, so your transaction could fail to ever complete.
The cost, in computation, is a variable that is centrally controlled. In the past it has only been ratcheted gradually upwards to counter Moore's Law and the shift from general-purpose CPU to purpose-built ASIC mining. However, the increases can be halted, which will result in a gradual decline in monetary cost per block. Or it could even be decreased, to further lower the cost. However, it is important to keep the cost high enough that blocks can't be trivially generated, which in turn will keep the fees up.
If someone makes me angry I "Ok Google Now" then roar into my phone and politely add "John Cramer". Then Google Now auto spams him with pre-generated hate spam.
Why do you want to hatespam John whenever someone pisses you off? Poor guy. I feel for him on the days your morning commute is bad.
You forgot my favorite feature: It looks at appointments on my calendar and, as long as they have an entry in the location field which can be unambiguously parsed by Google Maps, prompts me when I need to leave to get there on time. 10-15 minutes before I need to leave, based on current traffic conditions, my phone chimes and tells me "You need to leave by...".
You should RTFA. The records are digitized already. A big part of what the "hole" does is turn them all into paper, then process them, then re-enter them in the computer.
Thus a lot of the records having to deal with these employees are on paper, because that was what was in use when they were hired.
So there are two options - spend a ton of money all at once and digitize everything, or simply process the old paper records only as needed when those long-term employees retire.
Because there are no personnel-related actions between hiring and retirement which could benefit from automation?
And, in any case, the fundamental assumption behind your argument -- that records were all paper-based 30 years ago -- is simply false. I know from personal experience that one significant federal employer, the Department of Defense, managed all personnel records electronically 30 years ago. And, in general the notion of any large organization not having digitized such record-keeping in 1984 stretches credulity. Even in 1954 automation wasn't rare in large organizations, though it was of the punched card variety (and the punched card processing was often mechanical, not electronic). In 1964 it would still have been unsurprising to find a large organization that did everything on paper. In 1974 it would have been surprising and a bit backward, but not shocking. In 1984? No.
In fact, the article even quotes a man who oversaw the system in the early 80s and upon discovering the fact -- in 1981 -- he was shocked and dismayed, and concerned that being near such backwardness would destroy his reputation. 30 years ago was well past the point when everything of the sort was all electronic.
I'd think he should design an entirely new tool that does the same job but better... taking into account the limitations and advantages of the medium he's working in.
That would require understanding the limitations and advantages of the medium he's working in -- and no one yet fully understands them. That is the point of exercises like this. He didn't print a tape measure because he needed a tape measure (duh), he printed one because he's exploring the limitations and advantages of his 3D printer.
Doing that while simultaneously devising some entirely new sort of object would be a truly impressive feat indeed. I presume it's the sort of thing you do routinely, though. Got links? I'd love to see genius of higher order than represented by this tape measure at work.
As long as the research is valid and the conclusions correctly presented (which, in this case, they do not seem to have been), I don't care for the motive.
No argument. The research seems decent and worthwhile. The tone of the press release is what's eye-rollingly ridiculous. This is a minor security UI deficiency, but they're selling it as a "privilege escalation", which is normally understood to mean the ability to break out of the sandbox at least, and usually implies root access.
If you don't have the source, you just need to bring the original binaries along with all of the original libraries. The kernel API calls haven't changed (though there are new ones). Getting the link path configured correctly for the old code will be a PITA, but it can be done.
Take it up with the guy who claimed "you only need a recompile".
I'm taking it up with the guy who claimed that recompiling might not be possible, and therefore implied that you might be screwed because you can't recompile.
So your point is that Linux advocates can't be believed. Thanks for making that thing certain. Case closed.
Ah, I see. You're an ass. Sorry, I hadn't understood that, else I'd never have responded.
If you don't have the source, you just need to bring the original binaries along with all of the original libraries. The kernel API calls haven't changed (though there are new ones). Getting the link path configured correctly for the old code will be a PITA, but it can be done.
Take it up with the guy who claimed "you only need a recompile".
I'm taking it up with the guy who claimed that recompiling might not be possible, and therefore implied that you might be screwed because you can't recompile.
But sure, if your (in this case) ATM user interface is has hard-linked libraries (including the GUI manager), all should be fine. Apart from your fucking ATM interface.
Hard-linked libraries don't matter. You can do the same with shared libs... in fact I was assuming shared libs, which is why I mentioned the link path (LD_LIBRARY_PATH et al). And you can even use the old libs for the GUI -- The X API is also very stable. Depending on what the old program uses, the transitive dependencies could theoretically drag the entire userspace library collection along with it, but that's unlikely.
Of course, something in that userspace may be buggy, so upgrading to a newer kernel may not solve your problem -- and apparently there is a problem, or else why are you bothering to upgrade? Software doesn't wear out, after all. So if fixing your problem requires fixing stuff in those userland libs, you're in for more work, but still not screwed... because all of that stuff is open source.
If the problem is in the closed source stuff and Billy Bob's won't support it, then you're screwed.
But with respect to the OS and userland... open OSes like Linux give you a wealth of options that closed source OSes do not. It's still possible to end up in a situation where it's cheaper to buy a whole new system, but if you want to you can use the source to fix anything that needs fixing, and the only limits are the boundaries of the closed bits of the solution.
If you don't have the source, you just need to bring the original binaries along with all of the original libraries. The kernel API calls haven't changed (though there are new ones). Getting the link path configured correctly for the old code will be a PITA, but it can be done.
There are innumerable 2.4 applications which will flat out not run on a 2.6 system.
Bullshit.
There are many applications which won't run with the libraries installed on a typical 2.6 system, but if you go get all of the supporting libraries for that 2.4 application and install them, it'll work. The syscall interface is extremely stable, and I don't know of anything that has been removed or had its semantics significantly changed since pre-2.0.
As long as you give them everything they ask for, AND they believe you have done so. Then they can't ask for the keys.
No. There hasn't been a single example, AFAIK, of a company complying with a court order then not being believed.
That's a loophole big enough to drive a truck through.
It's not a "loophole" because (a) that's not what happened and (b) even if it had happened it would have been a case of one unreasonable judge, not a systemic issue. That's what appeals are for, etc.
You really need to read the whole Lavabit story. Basically, the government was able to convince the court that the combination of Lavabit's security architecture and the company's early stonewalling demonstrated that the only way to be sure they got all of the data the court had ordered Lavabit to hand over was to require the keys. Had Lavabit complied initially and just handed over the requested data the question of keys would never have come up.
That may seem like a subtle distinction, but it's not. The court never said that the government has a general right to demand keys, it just said that in that particular case there were factors which meant that merely asking for the data was not going to work, and that, therefore, the government could demand the key.
In Google's case, if the government asks -- through correct legal channels and with an appropriately-specific request -- for your e-mail, Google can and will simply comply with the request, which means that the government has no need to get keys. The only reason the government would ask for keys is in order to obtain the ability to do mass surveillance which cannot be justified Constitutionally -- and Google has the legal and technical resources to make that argument and to appeal it to the highest level.
Unless google invented practical homomorphic algorithms, It's still decrypted somewhere. Just a different post it note.
Obviously it's decrypted, but only inside data centers... and maybe only inside servers. In either case it's still ultimately accessible, but we're talking about different classes of spying problems: tapping a fiber running hundreds of miles across open country vs tapping a switched network inside an access-controlled building vs extracting data from a running machine.
Granted that it wouldn't be too hard for an organization like the NSA to obtain surrepititious access to a Google data center, but the logistical scale of the problem multiplies enormously when you have to somehow tap every one of hundreds of switches or tens of thousands of machines. And the odds of getting noticed increases non-linearly with scale.
Google can encrypt the data all they want, right down to encrypting it when it arrives, and leaving it encrypted for its lifetime on their servers, but the NSA can just say "gimme the data AND the keys to unlock it". The keys are just data, and obviously Google has access to them, therefore so does the NSA.
More precisely, the NSA would just say "gimme the decrypted data". But it's simply wrong to say that's not an important difference.
If the NSA can snoop all connections they can scoop up terabytes of data and figure out later what's interesting and no one is the wiser. If they have to ask Google, they have to make the request specific and they have to provide justification that will satisfy some set of legally-defined standards -- and Google will then add the request to the published transparency statistics so legislators and voters can see how much is being done and decide if it's excessive.
There's a huge difference there.
Oh, and I can't think of any case in which the government could legally demand the keys.
Google was only furious because the NSA was accessing the data without paying.
Google doesn't sell user data to anyone. What makes you think they'd be happy to give it to the NSA if they were paid? If Google were interested in exchanging user data for money (and if it didn't contradict Google's privacy policy), they could sell lots of it.
It's not a matter of forcing. I can use whatever I like. But I'm stepping into an entirely new space and being able to ask questions of my colleagues and get quick and accurate answers is really, really valuable.
Slashdot Mirror
If you have another location. Personally, all of my important data is in my house, unless I upload it to some offsite backup.
No, because the 2nd drive provides redundancy - if drive 1 fails then you restore from drive 2. There's a slight possibility that both drives fail at the same time but that's a very remote chance.
House fire.
I think we are describing the same thing. Facebook convinced a couple manufacturers to pre-install that overlay in shipped units, and those probably did not sell great. But the overlay can still be manually installed from Google Play store, as far as I know, as is still in active development. I don't know how many downloads have been made to date.
Looks like a tad over 33,000.
Heh. I greatly prefer self-checkout.
I think it's mostly because I just don't like dealing with people. I'm not anti-social enough to refuse the exchange of pleasantries when I have to deal with someone, but I am anti-social enough that I really don't want to be bothered. Since I go through self-checkout 95% of the time (sometimes even waiting for a self-checkout lane when there's a staffed lane open), I also now find it vaguely creepy to have someone pawing through my stuff. I know that in either case the computers are tallying it all and my purchase history is being datamined, but I don't care about that. People looking through my stuff bothers me.
Not marketing, except from the perspective of engineers to whom any portion of the business processes not related to technology gets called "marketing". IBM did all of the marketing relevant to the success of MS-DOS. Microsoft's coup was in brokering a deal with IBM and being smart enough to make it a per-copy licensing deal rather than selling the software outright.
The minimum transaction fee changed from 0.0005 BTC to 0.0001 BTC during the runup to $1100
Which is exactly the problem they are referring to. The fee dropped to the point of being not worth it.
Yes, but their conclusion is wrong in two ways, because the two parameters (fee and cost) are both variables.
The fee is actually a market-driven value, essentially a distributed real-time auction. Those who perform transactions bid for the services of the miners who generate the blocks to record the transactions. You're free to place any bid you want, but if there are higher bids available the miners will take those instead, so your transaction could fail to ever complete.
The cost, in computation, is a variable that is centrally controlled. In the past it has only been ratcheted gradually upwards to counter Moore's Law and the shift from general-purpose CPU to purpose-built ASIC mining. However, the increases can be halted, which will result in a gradual decline in monetary cost per block. Or it could even be decreased, to further lower the cost. However, it is important to keep the cost high enough that blocks can't be trivially generated, which in turn will keep the fees up.
If someone makes me angry I "Ok Google Now" then roar into my phone and politely add "John Cramer". Then Google Now auto spams him with pre-generated hate spam.
Why do you want to hatespam John whenever someone pisses you off? Poor guy. I feel for him on the days your morning commute is bad.
You forgot my favorite feature: It looks at appointments on my calendar and, as long as they have an entry in the location field which can be unambiguously parsed by Google Maps, prompts me when I need to leave to get there on time. 10-15 minutes before I need to leave, based on current traffic conditions, my phone chimes and tells me "You need to leave by...".
You should RTFA. The records are digitized already. A big part of what the "hole" does is turn them all into paper, then process them, then re-enter them in the computer.
Thus a lot of the records having to deal with these employees are on paper, because that was what was in use when they were hired.
So there are two options - spend a ton of money all at once and digitize everything, or simply process the old paper records only as needed when those long-term employees retire.
Because there are no personnel-related actions between hiring and retirement which could benefit from automation?
And, in any case, the fundamental assumption behind your argument -- that records were all paper-based 30 years ago -- is simply false. I know from personal experience that one significant federal employer, the Department of Defense, managed all personnel records electronically 30 years ago. And, in general the notion of any large organization not having digitized such record-keeping in 1984 stretches credulity. Even in 1954 automation wasn't rare in large organizations, though it was of the punched card variety (and the punched card processing was often mechanical, not electronic). In 1964 it would still have been unsurprising to find a large organization that did everything on paper. In 1974 it would have been surprising and a bit backward, but not shocking. In 1984? No.
In fact, the article even quotes a man who oversaw the system in the early 80s and upon discovering the fact -- in 1981 -- he was shocked and dismayed, and concerned that being near such backwardness would destroy his reputation. 30 years ago was well past the point when everything of the sort was all electronic.
Feel free to e-mail the links to me, then.
I'd think he should design an entirely new tool that does the same job but better... taking into account the limitations and advantages of the medium he's working in.
That would require understanding the limitations and advantages of the medium he's working in -- and no one yet fully understands them. That is the point of exercises like this. He didn't print a tape measure because he needed a tape measure (duh), he printed one because he's exploring the limitations and advantages of his 3D printer.
Doing that while simultaneously devising some entirely new sort of object would be a truly impressive feat indeed. I presume it's the sort of thing you do routinely, though. Got links? I'd love to see genius of higher order than represented by this tape measure at work.
As long as the research is valid and the conclusions correctly presented (which, in this case, they do not seem to have been), I don't care for the motive.
No argument. The research seems decent and worthwhile. The tone of the press release is what's eye-rollingly ridiculous. This is a minor security UI deficiency, but they're selling it as a "privilege escalation", which is normally understood to mean the ability to break out of the sandbox at least, and usually implies root access.
Privilege escalation? That phrase, I don't think it means what you think it means.
If you don't have the source, you just need to bring the original binaries along with all of the original libraries. The kernel API calls haven't changed (though there are new ones). Getting the link path configured correctly for the old code will be a PITA, but it can be done.
Take it up with the guy who claimed "you only need a recompile".
I'm taking it up with the guy who claimed that recompiling might not be possible, and therefore implied that you might be screwed because you can't recompile.
So your point is that Linux advocates can't be believed. Thanks for making that thing certain. Case closed.
Ah, I see. You're an ass. Sorry, I hadn't understood that, else I'd never have responded.
If you don't have the source, you just need to bring the original binaries along with all of the original libraries. The kernel API calls haven't changed (though there are new ones). Getting the link path configured correctly for the old code will be a PITA, but it can be done.
Take it up with the guy who claimed "you only need a recompile".
I'm taking it up with the guy who claimed that recompiling might not be possible, and therefore implied that you might be screwed because you can't recompile.
But sure, if your (in this case) ATM user interface is has hard-linked libraries (including the GUI manager), all should be fine. Apart from your fucking ATM interface.
Hard-linked libraries don't matter. You can do the same with shared libs... in fact I was assuming shared libs, which is why I mentioned the link path (LD_LIBRARY_PATH et al). And you can even use the old libs for the GUI -- The X API is also very stable. Depending on what the old program uses, the transitive dependencies could theoretically drag the entire userspace library collection along with it, but that's unlikely.
Of course, something in that userspace may be buggy, so upgrading to a newer kernel may not solve your problem -- and apparently there is a problem, or else why are you bothering to upgrade? Software doesn't wear out, after all. So if fixing your problem requires fixing stuff in those userland libs, you're in for more work, but still not screwed... because all of that stuff is open source.
If the problem is in the closed source stuff and Billy Bob's won't support it, then you're screwed.
But with respect to the OS and userland... open OSes like Linux give you a wealth of options that closed source OSes do not. It's still possible to end up in a situation where it's cheaper to buy a whole new system, but if you want to you can use the source to fix anything that needs fixing, and the only limits are the boundaries of the closed bits of the solution.
If you don't have the source, you just need to bring the original binaries along with all of the original libraries. The kernel API calls haven't changed (though there are new ones). Getting the link path configured correctly for the old code will be a PITA, but it can be done.
There are innumerable 2.4 applications which will flat out not run on a 2.6 system.
Bullshit.
There are many applications which won't run with the libraries installed on a typical 2.6 system, but if you go get all of the supporting libraries for that 2.4 application and install them, it'll work. The syscall interface is extremely stable, and I don't know of anything that has been removed or had its semantics significantly changed since pre-2.0.
As long as you give them everything they ask for, AND they believe you have done so. Then they can't ask for the keys.
No. There hasn't been a single example, AFAIK, of a company complying with a court order then not being believed.
That's a loophole big enough to drive a truck through.
It's not a "loophole" because (a) that's not what happened and (b) even if it had happened it would have been a case of one unreasonable judge, not a systemic issue. That's what appeals are for, etc.
You really need to read the whole Lavabit story. Basically, the government was able to convince the court that the combination of Lavabit's security architecture and the company's early stonewalling demonstrated that the only way to be sure they got all of the data the court had ordered Lavabit to hand over was to require the keys. Had Lavabit complied initially and just handed over the requested data the question of keys would never have come up.
That may seem like a subtle distinction, but it's not. The court never said that the government has a general right to demand keys, it just said that in that particular case there were factors which meant that merely asking for the data was not going to work, and that, therefore, the government could demand the key.
In Google's case, if the government asks -- through correct legal channels and with an appropriately-specific request -- for your e-mail, Google can and will simply comply with the request, which means that the government has no need to get keys. The only reason the government would ask for keys is in order to obtain the ability to do mass surveillance which cannot be justified Constitutionally -- and Google has the legal and technical resources to make that argument and to appeal it to the highest level.
Unless google invented practical homomorphic algorithms, It's still decrypted somewhere. Just a different post it note.
Obviously it's decrypted, but only inside data centers... and maybe only inside servers. In either case it's still ultimately accessible, but we're talking about different classes of spying problems: tapping a fiber running hundreds of miles across open country vs tapping a switched network inside an access-controlled building vs extracting data from a running machine.
Granted that it wouldn't be too hard for an organization like the NSA to obtain surrepititious access to a Google data center, but the logistical scale of the problem multiplies enormously when you have to somehow tap every one of hundreds of switches or tens of thousands of machines. And the odds of getting noticed increases non-linearly with scale.
Somebody mod this up. This is dead right.
Google can encrypt the data all they want, right down to encrypting it when it arrives, and leaving it encrypted for its lifetime on their servers, but the NSA can just say "gimme the data AND the keys to unlock it". The keys are just data, and obviously Google has access to them, therefore so does the NSA.
More precisely, the NSA would just say "gimme the decrypted data". But it's simply wrong to say that's not an important difference.
If the NSA can snoop all connections they can scoop up terabytes of data and figure out later what's interesting and no one is the wiser. If they have to ask Google, they have to make the request specific and they have to provide justification that will satisfy some set of legally-defined standards -- and Google will then add the request to the published transparency statistics so legislators and voters can see how much is being done and decide if it's excessive.
There's a huge difference there.
Oh, and I can't think of any case in which the government could legally demand the keys.
Google was only furious because the NSA was accessing the data without paying.
Google doesn't sell user data to anyone. What makes you think they'd be happy to give it to the NSA if they were paid? If Google were interested in exchanging user data for money (and if it didn't contradict Google's privacy policy), they could sell lots of it.
Here's a link:
http://www.gizmodo.com.au/2013...
That document is what motivated Google to encrypt all links between data centers, specifically to stop that.
It's not a matter of forcing. I can use whatever I like. But I'm stepping into an entirely new space and being able to ask questions of my colleagues and get quick and accurate answers is really, really valuable.