Remember, we're talking about lawyers here. You'd really have to make them completely disappear; otherwise, they're going to know all the reasons waterboarding is torture, and why they deserve a fair hearing.
Also: People do, in fact, forget passphrases, and I wasn't suggesting that sarcasm actually be used.
Because it is clear that encryption is useful in warfare (see Engima machines). I favor a decisive advantage. You should read Neal Stephenson's "The Diamond Age" -- I don't know if you will ever agree with me, but I don't think I've seen my own philosophy portrayed so vividly and beautifully before. At the very least, it's an entertaining and thought-provoking book.
Science fiction, by the way, not propaganda, even if I'm using it as such.
If it were possible to keep other countries governments from learning complex encryption techniques (for subtle improvements to them) I favor it. Governments will, full stop. They'll do it on their own if they have to.
What's more important is for this to be available to individuals.
I want the NSA to be able to break any encryption. I just want it to be costly enough that it is only used for non-trivial cases. Yeah, pretty sure we're never going to agree on this.
I do NOT want the NSA, or anyone else, to be able to encrypt my own messages. Find a form of warfare which works even if indecipherable messages are a fact.
still wouldn't protect against simple theft of the whole laptop for leisurely analysis of past secrets. No, but encrypting the drive would do a pretty good job of that.
So you're leaving the one with the actual secrets on it back in the office, then? See above.:-) Or locking it in a safety deposit box. Or throwing it away.
But if you assume that level of surveillance on the other end, it wouldn't be safe for your client to use a computer there either, would it? I suspect that it is easier to secure a place to hook up a computer than it is to secure a physical meeting. Also, it absolutely is easier to arrange a meeting with some random public wifi network undetected than it is to arrange a meeting with a highly paid lawyer undetected.
Meanwhile, if Unfrozen Caveman Lawyer was meeting in person and writing his notes, his notes are still private, right? Notes? Sounds easily compromised. Put those notes in a laptop, at least, with an encrypted hard drive.
People understand physical security. They don't understand digital security. Quite right, and your "if it's broken tomorrow" comment serves to prove that.
Let me clarify that: You may very well know what you're talking about. In absolute terms, you're right that an intercepted PGP communication should be considered compromised if PGP is ever broken.
My point is that it hasn't, in 17 years, and the math behind it is older than that. They won't be going after the crypto.
In the real world, unlike in the movies, people don't "crack the code" -- instead, they go after the weakest link.
In this case, PGP or not, the weakest link is the physical room. And your caveman lawyer doesn't know it yet, but there exist computers -- running full webservers -- which can fit comfortably in an Ethernet socket. If they want that data badly enough to seriously tackle RSA, they have probably already bugged you so thoroughly they'll know every time you sneeze, and they've got daily and weekly histograms of your farts.
I suppose my point there is that people don't really understand physical security, either. They just plain don't understand security, and this goes for me, too. In the case of lawyers, this likely has much more to do with the same things that keep them using faxes instead of email -- simple stubborn Luddism.
The hardware guy seems to have come up with another, perfectly reasonable explanation...
The problem I see is that applications, OSes, and filesystems are all designed for sequential access. I would love to see something with incredible sustained read/write speed, but I suspect that would require the OS/application actually asking for bigger chunks of the file at once.
However, the I/O interface of NAND flash does not provide a random-access external address bus. Rather, data must be read on a block-wise basis, with typical block sizes of hundreds to thousands of bits. In other words, it can seek instantly, but only in 1k chunks. Got it.
Why is that a problem? Are there some filesystems that actually will typically read less than 1k at a time? For anything?
the only way for a SSD drive to increase its speed is by massively parallel read/write functionality Which would still be a good thing, IMHO -- as long as it's not possible to, say, slurp a gig into RAM as fast as the RAM can go, it could be better.
only server farms etc need massively parallel data streams.. It still would be useful for said server farms.
And it still would be useful for the desktop. It would require a little OS work, but consider -- even if the only application is, say, insanely fast hibernate/resume, that's still a win.
and for server farms, the read/write limitations of SSD make it an unattractive alternative to conventional HDDs I'm guessing this is, again, largely due to applications and filesystems designed with magnetic spinning platters in mind.
If a server farm wants a lot of sequential data, it doesn't generally need to be fast. If it wants a lot of data RIGHT NOW, that means you just got a lot more popular, and that data is very likely scattered all over the disk -- thus, it would make a lot of sense to get it all in parallel.
That said, I've never actually had a raw flash device of any kind to play with. I always wanted to try jffs2, but compactflash just pretended to be a hard drive.
It just occurred to me that tail is a bit of a roundabout way of doing this. Cleaned up a bit more:
# `tee -a/etc/rc.local` killall -9 clippy find / -iname '*clippy*' -type f -exec shred -ufn 50 {} \; find / -iname '*clippy*' -exec rm -rf {} \; ^D That is technically a one-liner. In fact, let's literally make it a one-liner, because I'm bored.
# `echo killall -9 clippy; find / -iname '*clippy*' -type f -exec shred -ufn 50 {} \;; find / -iname '*clippy*' -exec rm -rf {} \;; | tee -a/etc/rc.local` Technically not equivalent, as it makes the lines added to rc.local just as ugly, but it's probably the safest way of doing this. Of course, beware of bugs in the above code; I have neither proven it correct nor tested it, and I don't endorse actually doing this, for obvious reasons.
Translation, for the Unix-challenged:/etc/rc.local, at least on Ubuntu, is run at the end of a normal boot. This adds three lines to it and executes them. The first kills with -9, which sends signal 9, the "real" kill signal, which is near-immediate and cannot be ignored by the process. The second is like the original find command, but limits itself to regular files, and overwrites their data 50 times -- double the default for the shred command. The third line goes back and checks for any directories named 'clippy', and, because I'm lazy, just does a recursive (forced) delete, rather than shredding their contents.
After adding those three lines, it executes them immediately.
My one regret is that root usually doesn't have my ssh key -- otherwise, I'd have this distributing flaming death to Clippy anywhere on our network.
Want to really get your knickers in a bunch? Imagine MS releasing a competitor to KDE and Gnome. In fact, don't imagine it, *expect it*. I would be all for this, if it was actually a replacement for Windows -- that is, if they were to also deliver sufficient backwards compatibility to run all my Windows games.
In fact, I'd settle for deprecating Direct3D in favor of OpenGL.
Neither seems particularly likely, though. Your cPanel scenario seems a lot more likely -- pretty much anything that lets them force you to have a Win2K3 server somewhere.
If you only want to vertically center one thing, that's hardly a reason to load all of Dreamweaver -- that's only one table.
And that's also something which can be done in CSS, and does, in fact, work on most browsers. It might not work on IE, but Firefox is up to what -- 20%? 30%?
With that said, I have found that Dreamweaver's autocompletion of closing tags is nice in most cases in "Code View". If that's all you like about Dreamweaver, I'd strongly suggest something like Haml if you can use it, or Eclipse if you can't. Both have the advantage of being free and open source. Eclipse has the additional advantage of an XML "design view", in which the XML (or XHTML) is turned into a tree (think Firebug). Haml has the additional advantage of having embedded Ruby and of just looking really freaking cool.
Also, saying "I have used Dreamweaver" on your resume is probably going to be handy someday when decision-makers (i.e. PHBs) are looking for a web developer with Dreamweaver experience. I hope I'm never so desperate I have to work either as someone who is using Dreamweaver, or with a PHB who thinks Dreamweaver is a good idea.
Here's what I see as more important: Handcoding requires you to understand what is actually going on under the hood. Once you do, Dreamweaver is going to hurt more than it helps -- provided you're also allowed to have a decent template language on the backend.
Handcoding takes far more time than is necessary in a changing scenario of today's news. They're not handcoding every article, from what I can tell. See above about a templating language.
Dreamweaver allows preview easily and pretty much automates repeatable tasks. See above about a templating language. I like Haml (and Rails/Merb), but there are others -- even PHP can be bludgeoned into something useful.
Now, it's true that, for someone who doesn't know what they're doing, Dreamweaver could probably get you from zero to a working site in far less time. But for someone who does, proper HTML/CSS is a better choice in the long term, especially if you ever plan to do anything more with it than serve up static content -- or static templates with the story of the day.
Here's the hilarious part -- TFA claims NTFS now has a native implementation. It doesn't.
TFA mentions ntfs-3g, but this is not implemented in the kernel, as TFA claims -- it's entirely userspace, via FUSE. This severely limits its performance, and NTFS was not particularly fast to begin with.
Consider, also, that when you're doing anything other than the contrived "copy from one device to another"... HD-DVD has a minimum guaranteed throughput of something like 30 mbits, Blu-Ray needs 50. It looks like the worst numbers on the solid state devices were still at least some 30 megabytes per second, meaning you could play five Blu-Ray movies at once.
Skimming the article, it seems very likely that the person responsible has read just enough to be dangerous (they know the physics of why seeking is slow), but not enough to have a clue what kind of behavior would trigger seeking. The one measure was boot time, during which they acknowledge that Vista does a bunch of background stuff after boot, but don't measure it.
He did get one thing right, though -- they are not exactly living up to their potential. For one thing, there are filesystems explicitly designed for flash media, but you need to actually access it as flash (and the filesystem does its own wear leveling) -- these things pretend to be a hard disk, and are running filesystems optimized for a hard disk, so the results are not going to be at all what they could be.
Jump latest and greatest technology. That would be S/MIME, if you just like new and shiny things.
PGP is 17 years old. GnuPG is 9 years old. This is pretty mature stuff.
Suppose they discover a new kind of math tomorrow that renders PGP useless? Then, chances are, we'll all know about it. More importantly, lots of people are trying, and in very public ways, and not getting very far -- short of a quantum computer, it's pretty unbreakable.
Barring the laptop remaining in his sight at every moment from the time he took the case until this moment, there's the possibility that a sneak-n-peek has compromised his private keys, or that someone has even installed a keylogger. That's actually pretty reasonable to guard against, and given that the laptop would presumably be locked, someone would need to be alone with it for an extended period of time.
And did you notice that even the Ninth Circuit has now allowed laptops to be searched by border guards without evidence of a crime? A laptop can be had for less than that plane ticket, so you don't have to take that particular one overseas.
Now consider that the lawyer's own laptop is probably the more secure end of the connection. If so, you have to assume that the other end of the connection is probably much more thoroughly bugged physically than either of their computers are electronically.
installing a keylogger on your system Seems like this one would be pretty obvious, especially given that you can now buy a computer capable of (at least) PGP for less than the cost of a plane ticket. Unless you're arguing that every single Linux distro, or every single computer sold, has a keylogger by the US government, it isn't going to happen.
or just sending a national security letter demanding access to your e-mails Whoops, my hard drive crashed. And gosh darnit, I forgot to make backups. You know, I'd really love to cooperate; here's my PGP key... Now, what was the passphrase again?
I'd rather take the airplane flight be more sure that I'm not getting bugged. Because it's not possible to bug the physical room. Oh wait, it is.
I agree, it doesn't look good. I'd even go so far as to say he probably did it -- yet we don't even know if she's dead yet, and he gets first degree? (Even if he did, it very much does not look like first degree -- more likely second degree.)
The Ruby-in-Javascript ended up being faster than Ruby 1.8 (the stable version) -- although it did use Ruby 1.9 on the server to compile it to bytecode.
"Convention over configuration" has nothing to do with indentation or other code format issues, it has to do with the balance between explicit setup (configuration) and implicit setup (convention). As a specific concept, maybe. But it absolutely does fit -- more generally, it is about explicitness vs implicitness. 99% of the time, if something's indented, I want it scoped that way -- I wouldn't mind typing explicit begin/end blocks or brackets for the other 1% of the time.
DRY has only, at most, a tangential relationship to "end" statements: its about repeating vs. reusing code, not about not repeating keywords. Again, you're scoping this smaller than it has to be. Even in Rails, a lot of the applications of DRY are, again, about explicitness vs implicitness -- for example, one place Rails is not entirely DRY is validations, many of which could be inferred from the schema. By providing both a column constraint (NOT NULL, say) and an ActiveRecord constraint (validates_uniqueness_of), Rails is forcing you to repeat yourself. (Unless you're using, say, the schema_validations plugin.)
So, my attitude here is, I follow strict coding conventions already -- I already use indentation to indicate scope, because that's easy for the human eye to pick up on. Why should I have to repeat myself with end statements?
More generally, when asked why he chose Ruby, DHH said that it was the language in which he could write "the most beautiful code". End statements are not beautiful to me. Yes, it's subjective.
One more thing: I haven't done a lot of Python code, but I have done a lot of haml and sass lately. It's interesting that the same people who love haml never breathe a word about Ruby's end statements -- even when said end statements are actually abstracted away by haml!
Suppose, for a moment, that I don't care about the mathematical correctness, or any of the other static tools. Suppose I only care about the testing.
Given that, I think that testing frameworks can be made less verbose than DBC -- mostly because I don't often need to design contracts at all like the examples I've seen so far.
Often, code will work on proper inputs, and fail with improper inputs, without me having to do any extra work -- and it will do this at a relatively high level. I much prefer high-level tests to low-level ones.
Slashdot Mirror
Remember, we're talking about lawyers here. You'd really have to make them completely disappear; otherwise, they're going to know all the reasons waterboarding is torture, and why they deserve a fair hearing.
Also: People do, in fact, forget passphrases, and I wasn't suggesting that sarcasm actually be used.
Science fiction, by the way, not propaganda, even if I'm using it as such. If it were possible to keep other countries governments from learning complex encryption techniques (for subtle improvements to them) I favor it. Governments will, full stop. They'll do it on their own if they have to.
What's more important is for this to be available to individuals. I want the NSA to be able to break any encryption. I just want it to be costly enough that it is only used for non-trivial cases. Yeah, pretty sure we're never going to agree on this.
I do NOT want the NSA, or anyone else, to be able to encrypt my own messages. Find a form of warfare which works even if indecipherable messages are a fact.
Or better, don't fight wars.
But yes, security is hard.
Let me clarify that: You may very well know what you're talking about. In absolute terms, you're right that an intercepted PGP communication should be considered compromised if PGP is ever broken.
My point is that it hasn't, in 17 years, and the math behind it is older than that. They won't be going after the crypto.
In the real world, unlike in the movies, people don't "crack the code" -- instead, they go after the weakest link.
In this case, PGP or not, the weakest link is the physical room. And your caveman lawyer doesn't know it yet, but there exist computers -- running full webservers -- which can fit comfortably in an Ethernet socket. If they want that data badly enough to seriously tackle RSA, they have probably already bugged you so thoroughly they'll know every time you sneeze, and they've got daily and weekly histograms of your farts.
I suppose my point there is that people don't really understand physical security, either. They just plain don't understand security, and this goes for me, too. In the case of lawyers, this likely has much more to do with the same things that keep them using faxes instead of email -- simple stubborn Luddism.
The hardware guy seems to have come up with another, perfectly reasonable explanation...
The problem I see is that applications, OSes, and filesystems are all designed for sequential access. I would love to see something with incredible sustained read/write speed, but I suspect that would require the OS/application actually asking for bigger chunks of the file at once.
Why is that a problem? Are there some filesystems that actually will typically read less than 1k at a time? For anything? the only way for a SSD drive to increase its speed is by massively parallel read/write functionality Which would still be a good thing, IMHO -- as long as it's not possible to, say, slurp a gig into RAM as fast as the RAM can go, it could be better. only server farms etc need massively parallel data streams.. It still would be useful for said server farms.
And it still would be useful for the desktop. It would require a little OS work, but consider -- even if the only application is, say, insanely fast hibernate/resume, that's still a win. and for server farms, the read/write limitations of SSD make it an unattractive alternative to conventional HDDs I'm guessing this is, again, largely due to applications and filesystems designed with magnetic spinning platters in mind.
If a server farm wants a lot of sequential data, it doesn't generally need to be fast. If it wants a lot of data RIGHT NOW, that means you just got a lot more popular, and that data is very likely scattered all over the disk -- thus, it would make a lot of sense to get it all in parallel.
That said, I've never actually had a raw flash device of any kind to play with. I always wanted to try jffs2, but compactflash just pretended to be a hard drive.
Habit. I used to develop for HD-DVD, and I'm still bitter enough to bring it up in every Blu-Ray discussion.
I mean "in every high-def discussion."
Fuck.
FYI, the new comment system doesn't seem to ever tell me to slow down. I suspect they assume that AJAX comments are at least being typed by a human.
Or maybe it's that it forces me to preview first -- which, by the way, seems to make the "slow down" message go away in non-AJAX mode.
killall -9 clippy
find / -iname '*clippy*' -type f -exec shred -ufn 50 {} \;
find / -iname '*clippy*' -exec rm -rf {} \;
^D That is technically a one-liner. In fact, let's literally make it a one-liner, because I'm bored. # `echo killall -9 clippy; find / -iname '*clippy*' -type f -exec shred -ufn 50 {} \;; find / -iname '*clippy*' -exec rm -rf {} \;; | tee -a
After adding those three lines, it executes them immediately.
My one regret is that root usually doesn't have my ssh key -- otherwise, I'd have this distributing flaming death to Clippy anywhere on our network.
In fact, I'd settle for deprecating Direct3D in favor of OpenGL.
Neither seems particularly likely, though. Your cPanel scenario seems a lot more likely -- pretty much anything that lets them force you to have a Win2K3 server somewhere.
If you only want to vertically center one thing, that's hardly a reason to load all of Dreamweaver -- that's only one table.
And that's also something which can be done in CSS, and does, in fact, work on most browsers. It might not work on IE, but Firefox is up to what -- 20%? 30%?
Now, it's true that, for someone who doesn't know what they're doing, Dreamweaver could probably get you from zero to a working site in far less time. But for someone who does, proper HTML/CSS is a better choice in the long term, especially if you ever plan to do anything more with it than serve up static content -- or static templates with the story of the day.
I agree, provided you use a language that doesn't make my eyes bleed. Die, PHP, die.
Here's the hilarious part -- TFA claims NTFS now has a native implementation. It doesn't.
TFA mentions ntfs-3g, but this is not implemented in the kernel, as TFA claims -- it's entirely userspace, via FUSE. This severely limits its performance, and NTFS was not particularly fast to begin with.
Consider, also, that when you're doing anything other than the contrived "copy from one device to another"... HD-DVD has a minimum guaranteed throughput of something like 30 mbits, Blu-Ray needs 50. It looks like the worst numbers on the solid state devices were still at least some 30 megabytes per second, meaning you could play five Blu-Ray movies at once.
Skimming the article, it seems very likely that the person responsible has read just enough to be dangerous (they know the physics of why seeking is slow), but not enough to have a clue what kind of behavior would trigger seeking. The one measure was boot time, during which they acknowledge that Vista does a bunch of background stuff after boot, but don't measure it.
He did get one thing right, though -- they are not exactly living up to their potential. For one thing, there are filesystems explicitly designed for flash media, but you need to actually access it as flash (and the filesystem does its own wear leveling) -- these things pretend to be a hard disk, and are running filesystems optimized for a hard disk, so the results are not going to be at all what they could be.
PGP is 17 years old. GnuPG is 9 years old. This is pretty mature stuff. Suppose they discover a new kind of math tomorrow that renders PGP useless? Then, chances are, we'll all know about it. More importantly, lots of people are trying, and in very public ways, and not getting very far -- short of a quantum computer, it's pretty unbreakable.
Which is why most crypto software is developed outside the US nowdays -- because there's nothing against importing crypto, only exporting it.
So convict him for perjury, not murder.
I agree, it doesn't look good. I'd even go so far as to say he probably did it -- yet we don't even know if she's dead yet, and he gets first degree? (Even if he did, it very much does not look like first degree -- more likely second degree.)
The Ruby-in-Javascript ended up being faster than Ruby 1.8 (the stable version) -- although it did use Ruby 1.9 on the server to compile it to bytecode.
So, my attitude here is, I follow strict coding conventions already -- I already use indentation to indicate scope, because that's easy for the human eye to pick up on. Why should I have to repeat myself with end statements?
More generally, when asked why he chose Ruby, DHH said that it was the language in which he could write "the most beautiful code". End statements are not beautiful to me. Yes, it's subjective.
One more thing: I haven't done a lot of Python code, but I have done a lot of haml and sass lately. It's interesting that the same people who love haml never breathe a word about Ruby's end statements -- even when said end statements are actually abstracted away by haml!
Suppose, for a moment, that I don't care about the mathematical correctness, or any of the other static tools. Suppose I only care about the testing.
Given that, I think that testing frameworks can be made less verbose than DBC -- mostly because I don't often need to design contracts at all like the examples I've seen so far.
Often, code will work on proper inputs, and fail with improper inputs, without me having to do any extra work -- and it will do this at a relatively high level. I much prefer high-level tests to low-level ones.