Spring is here, and I'm enjoying it. Generally I'm a stereotypical pasty computer nerd, but after an especially frustrating semester at school (frustrating... not hard, frustrating), I actually voluntarily did some garden work today, a first I think. Wierd!
The sun is bright, the birds are chirping, and if anything, I think these silly emails have added a measure of levity to my day. Meanwhile, I'm posting this from my porch via a long ethernet cable (ahh! wireless!) and getting ready to grill dinner. Carpe the spring diems!
(Update: This was yesterday's post, but it didn't go. Let's see if it does now... OK. Hmmm. One of the Tools I installed seems to have done something. This is why I don't like to install them willy-nilly...)
I wanted to comment on this, since I feel I'm in an unusually good position to understand it.
First, the claims are quite real, and quite attainable. This setup really can ensure that nobody can eavesdrop on your conversation without your knowlege, at least in the middle of transmission. Of course, as soon as you detect anyone eavesdropping, you stop transmitting, leaving the interceptor with only a few bytes (ideally) of data. Combined with conventional encryption, that data is virtually worthless.
There are some theoretical attacks that may enable somebody to intercept and fake some percentage of the photons en route; but the problem is, if the interceptor can't fake 100% of the photons (or some obscenely large percentage), the reciever and sender can compensate with their protocol and still detect the interception with extremely high probability, extremely quickly. It is exceedingly unlikely that it is even possible to forge 100% of the photons correctly; it may even be provable that this is the case.
Upshot: This isn't rocket cars and jet packs; it's quite feasible. (And IMHO the most significant thing we'll see from "quantum computing".)
Of course, you still must worry about the integrity of the endpoints, and all of the relays, but again, since this will inevitably be layered on top of conventional private-key encryption, this is no worse then things already are today.
The upshot is that this is a nice step forward, essentially eliminating entirely one form of attack. Of course, there are still others; corrupt a relay station and steal a key via some other means, and you can still intercept messages, but for some situations (like, say, the military), it's quite feasible to secure the devices and stop worrying about the lines being tapped.
Will consumers see this? That remains to be seen. I don't see why the equipment itself should be that expensive, but it may be difficult to use, as it must be line-of-sight, or go through a series of relays. We'll have to see how it plays out.
As the recent run of posts on my weblog might lead you to believe, I've had a little more time lately then the last couple of weeks. The downside of working with a partner on a project is that you feel morally obligated to give it 110% for his sake, even if you're inclined to just do enough to get by. . . or even if you've made it to 100% already and you want to stop for a bit. But it went well, and I think we gave the best presentation of the class. (It is surprisingly difficult to give a 30-minute presentation. Nearly everybody tried to give a 60-minute presentation, and lopped the last half off. I think we were the only group to finish in 29 minutes, only chopping off a couple of slides I put in as sacrificial cows in case I had underestimated the time.)
I'm not quite done, but I'm getting there. It's all over by Thursday, which is my last final this semester.
This brings me to the summer. Last summer, I worked for the University and took a class. This semester, the guy responsible for assigning those positions sent out an email about a month ago, which I immediately replied to (as in, about 10 minutes after he sent it). However, just last week, after I finally emailed him back and asked him what was up, did he say there isn't a position available for the summer. Oops. I had thought there would be. I had at least expected that after he knew there wouldn't be a position, he'd email me (and the others) telling us that...
(Another administrative snafu: I was never told this year when I can sign up for classes for next year. Normally, you get a letter and an email telling you the date. There is no other way to find this information out. By the time I figured that out, all the classes were full.)
So, I am now faced with an empty summer. What's worse, since I can't take a class, which I had planned on, that pushes my graduation date back by another full semester, and forces me to take classes I do not want to take if I want to graduate that soon. This disgusts me. After 20 years in school, I'm ready to be done with it. (What with all the administrative stuff crapping out, it's like the University feels the same way, on some unconcious level.)
So, I am now hunting for a job. If I can find something to tide me over the summer, I may do that and re-enroll in school next year. However, I'm really looking for a real job, with the intent of taking at least a year off of school. (I still want to finish my grad degree; half of a degree is too much to just abandon. But the fact is, I've taken most of the classes I want to take.) I'd really like something in the MidWest, which is a tall, order, I know. I may even pick something up locally. If you've got any leads, here's my resume, and my email is email@example.com.
I've worked in a "real job" before; I much prefer it to school.
I don't know how it's going to go, I don't know what's going to happen. In fact, this is as much uncertainty as I've ever faced in my life. But I'll get through somehow.
Paul Snively replies to yesterday's exploratory post regarding RPC vs. REST. I'd say I feel confident that the issues are explored.
I'd say the best thing REST advocates can do is make the tools as simple to use as the approx. 100 implementations of XML-RPC and SOAP. The URI part of the argument, with the corresponding issues, does make sense, and all things considered, I would side with the REST side of issue.
Paul: 'I feel the need to put a verbal stake in the ground and say that choosing RPC over REST is choosing worse over better, and that such decisions will not be revisited, so be very careful about the areas that are hardest to predict, such as scalability, cachability, and the like, before making large deployments based on an RPC architecture.'
But I don't feel it so strongly that I'm going to stop using RPC (which I know Paul is not asking for); it's here and a lot better then nothing. Give me the tools and a choice, though, and I would probably go REST preferentially. URIs have a lot of advantages to them, as Paul enumerates.
|<- Future Posts||Past Posts ->|