It has two passwords: One password provides access to the system. The other, if used, causes the system to silently erase itself or otherwise self-destruct. In this case, the prisoner could solve two problems with the second password: He provides "the password" to the authorities, thereby keeping himself out of jail, and he has those same authorities do the dirty work of destroying the evidence.
Does there already exist an encryption system and/or filesystem does this?
With all due respect, I'd like to go on record as disagreeing with every point in your entire post. Instead of making what I think your point is, your post points out the fundamental faults associated with the path the industry has taken over the last 15-20 years.
TFA hints at this but doesn't come out and say it: the larger you scale, the more you swamp yourself with atomicity protocol overhead. If your database is geographically distributed, then you have to decide if atomicity is more important than forgoing the very large bills for the associated network usage. I suspect that this may explain a lot about why Google, Amazon, etc., went with NoSQL solutions.
Well written gcc/g++ code will compile using gcc/g++ on many, many platforms and operating systems with no changes to the source. The other compilers mentioned, besides being non-free in various ways, won't do that. For me, the portability angle is a whole lot more important than the freedom angle.
A bit off topic, but since I'm seeing posts about OpenCL and portability...
OpenCL will indeed get you portability between processors, however OpenCL does not make any guarantees about how well that portable code will run. In the end, to get optimum performance you still have to code to the particular architecture on which that your code is going to run. For example, performance on Nvidia chips is extremely sensitive to memory access patterns. You could write OpenCL code that runs very well on Nvidia chips, but runs poorly on a different architecture.
Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.
From my own experience with these kinds of systems, it's very likely that, during telemetering, the stream can become corrupted to a point where the ECC will fail. So then the question becomes, what do you do when the ECC doesn't work (making it impossible to decrypt)? Drop the frame? Retransmit? Neither of these choices are very good. The "easiest" thing to do is just send unencrypted and handle the funkified data payloads as the come in.
More importantly, these video stream are sent over comms links that have a finite bandwidth. Encryption and ECC are essentially "anti-compression" techniques that ultimately require much wider comms bandwidth for the same data payload throughput (e.g. frame rate). It's possible that a trade off was made preferring higher data throughput over a relatively narrow comms pipe -- at the expense of security of the stream.
It's a kind of Sophie's Choice tradeoff, but that's what Engineering is all about.
Unlike some other popular languages, Go includes hooks into the OS:
... the low-level, external syscall package, which provides a primitive interface to the underlying operating system's calls.
Finally, some sanity in language design. syscall will no doubt be used only occasionally, but it's there if you need it and you know what you're doing.
If you haven't read "Good Calories, Bad Calories" by Gary Taubes, you should. This book outlines how 40 years of bad science and personality cults in nutrition research has lead to a serious misunderstanding of the causes of heart disease and obesity.
At the very least you should read his eye-opening NY Times article, which pre-dated the book by a couple of years.
Nope, OS X is Darwin, and for the last ten years or so, Linux has defined the main stream of Unix. Sure, Darwin has -- through its lineage -- a better connection to the origins of Unix, but c'mon, pedigree doesn't matter if it's not relevant.
Apple has done a fine job of building a decent platform around Mach and BSD, and I like using my Mac. A lot. But I do 90% of my "real" WORK at the command line, and with its BSD-style commands, the Mac kinda sucks in this dept. If I want to get WORK DONE, then I either ssh to a Linux machine, or I install a bunch of packages from Fink on the Mac so that I can have "normal", Linux-style commands at my disposal.
BSD commands are just strange. In the words of that immortal Unix guru Willie Nelson: That shit ain't right.
You can read all about the work leading up to this device, why it works, amazing stories of recovery from brain injury, and other cool stuff in a book called The Brain That Changes Itself.
If you simply dislike spinach, you don't have a disease. If your dislike of spinach, however, makes you start a massive campaign calling spinach evil and saying nobody should eat it, then yes, you have a disease.
Preview is pretty great for viewing PDFs, but I just spent a frustrating two hours trying to get a PDF document to print correctly from Preview. The bottom of the document was getting chopped off. I tried scaling down the document, but Preview prints bottom-justified -- so the bottom of the document was still cut off no matter how much I scaled it down. I tried all kinds of tricks, but I couldn't make it work.
So, I finally gave up and installed Adobe Reader, and it printed the document correctly the first time out.
The moral of my story: Preview for viewing, Adobe for printing.
Slashdot Mirror
It has two passwords: One password provides access to the system. The other, if used, causes the system to silently erase itself or otherwise self-destruct. In this case, the prisoner could solve two problems with the second password: He provides "the password" to the authorities, thereby keeping himself out of jail, and he has those same authorities do the dirty work of destroying the evidence.
Does there already exist an encryption system and/or filesystem does this?
With all due respect, I'd like to go on record as disagreeing with every point in your entire post. Instead of making what I think your point is, your post points out the fundamental faults associated with the path the industry has taken over the last 15-20 years.
TFA hints at this but doesn't come out and say it: the larger you scale, the more you swamp yourself with atomicity protocol overhead. If your database is geographically distributed, then you have to decide if atomicity is more important than forgoing the very large bills for the associated network usage. I suspect that this may explain a lot about why Google, Amazon, etc., went with NoSQL solutions.
For those of you wondering WTF this is all about, Wikipedia has a good write-up on leap seconds: http://en.wikipedia.org/wiki/Leap_second
Are you trying to tell us that you don't know the difference between an operating system and a web server software package? [*]
[*] Apache also runs on on Windows
Without a healthy competition, there is no pressure to lower prices.
Healthy competition? What healthy competition? It certainly won't be in the form of Micro-Soft's rush-job tablets.
Why is anyone still using GCC then?
In a nutshell, portability.
Well written gcc/g++ code will compile using gcc/g++ on many, many platforms and operating systems with no changes to the source. The other compilers mentioned, besides being non-free in various ways, won't do that. For me, the portability angle is a whole lot more important than the freedom angle.
that video ... what?
... this is very old news.
Apple is lock-in. Adobe is lock-in. You have a choice of how you'll be locked in. What's the point of developing software?
Me: UGPSJ0722-05.
UGPSJ0722-05: We meet again.
Me: It's been a long time.
The age-old Rules of Optimization:
1. Don't.
2. (For experts only) Don't yet.
A bit off topic, but since I'm seeing posts about OpenCL and portability...
OpenCL will indeed get you portability between processors, however OpenCL does not make any guarantees about how well that portable code will run. In the end, to get optimum performance you still have to code to the particular architecture on which that your code is going to run. For example, performance on Nvidia chips is extremely sensitive to memory access patterns. You could write OpenCL code that runs very well on Nvidia chips, but runs poorly on a different architecture.
Not saying that portability isn't a good thing, but a lot of people seem to be thinking that OpenCL will solve all your portability problems. It won't. It only will let code run on multiple architectures. You'll still have to more or less hand optimize to the architecture.
From my own experience with these kinds of systems, it's very likely that, during telemetering, the stream can become corrupted to a point where the ECC will fail. So then the question becomes, what do you do when the ECC doesn't work (making it impossible to decrypt)? Drop the frame? Retransmit? Neither of these choices are very good. The "easiest" thing to do is just send unencrypted and handle the funkified data payloads as the come in.
More importantly, these video stream are sent over comms links that have a finite bandwidth. Encryption and ECC are essentially "anti-compression" techniques that ultimately require much wider comms bandwidth for the same data payload throughput (e.g. frame rate). It's possible that a trade off was made preferring higher data throughput over a relatively narrow comms pipe -- at the expense of security of the stream.
It's a kind of Sophie's Choice tradeoff, but that's what Engineering is all about.
http://bishophill.squarespace.com/blog/2009/11/20/climate-cuttings-33.html Nice summarized digest of the CRU et.al emails. Doesn't look good for the Hockey Team. Not good at all.
Here's the particular one you're after: http://www.eastangliaemails.com/emails.php?eid=490&filename=1107454306.txt
... And, can we PLEASE have a thread-safe STL? Please, please, please?
... the low-level, external syscall package, which provides a primitive interface to the underlying operating system's calls.
Finally, some sanity in language design. syscall will no doubt be used only occasionally, but it's there if you need it and you know what you're doing.
Thing is, though: They're right.
If you haven't read "Good Calories, Bad Calories" by Gary Taubes, you should. This book outlines how 40 years of bad science and personality cults in nutrition research has lead to a serious misunderstanding of the causes of heart disease and obesity.
At the very least you should read his eye-opening NY Times article, which pre-dated the book by a couple of years.
Keeping in mind that all back-lit displays suck, can we please have a reader that doesn't suck?
I mean other than the Kindle.
I think I'd rather hammer #10 nails into my skull than do another VxWorks project.
The fun stuff (Java, .NET, Web) ...
If by "fun", you mean "hammering #10 nails into my eyeballs", then I agree.
OS X *IS* Unix
Nope, OS X is Darwin, and for the last ten years or so, Linux has defined the main stream of Unix. Sure, Darwin has -- through its lineage -- a better connection to the origins of Unix, but c'mon, pedigree doesn't matter if it's not relevant.
Apple has done a fine job of building a decent platform around Mach and BSD, and I like using my Mac. A lot. But I do 90% of my "real" WORK at the command line, and with its BSD-style commands, the Mac kinda sucks in this dept. If I want to get WORK DONE, then I either ssh to a Linux machine, or I install a bunch of packages from Fink on the Mac so that I can have "normal", Linux-style commands at my disposal.
BSD commands are just strange. In the words of that immortal Unix guru Willie Nelson: That shit ain't right.
You can read all about the work leading up to this device, why it works, amazing stories of recovery from brain injury, and other cool stuff in a book called The Brain That Changes Itself.
This is one of the best books I've ever read.
If you simply dislike spinach, you don't have a disease. If your dislike of spinach, however, makes you start a massive campaign calling spinach evil and saying nobody should eat it, then yes, you have a disease.
Oh, sorta like these wingnuts?
Preview is pretty great for viewing PDFs, but I just spent a frustrating two hours trying to get a PDF document to print correctly from Preview. The bottom of the document was getting chopped off. I tried scaling down the document, but Preview prints bottom-justified -- so the bottom of the document was still cut off no matter how much I scaled it down. I tried all kinds of tricks, but I couldn't make it work.
So, I finally gave up and installed Adobe Reader, and it printed the document correctly the first time out.
The moral of my story: Preview for viewing, Adobe for printing.