It's about time that they're ready for production.

I'm not sure what you mean. Could you please explain again?

If this is the case, which I won't concede, exactly how many of the Microsoft tablets are sitting in a warehouse somewhere, only "sold" in order to make the numbers look good?

Actually, I've sort of been waiting for an @aol.com e-mail address to become retro/cool again. Like seeing the hipsters all wanting @aol.com addresses to show their hipster status. Apparently I'll need to keep waiting.

Seems like you're making an assumption that AES itself hasn't been backdoored and that the implementation of the same is also correct, neither of which I would assume. Steve

It's a few days early for the April Fools edition of Slashdot. I'm sure the MIT researchers in question think they really have something here but it would be nice if they would've looked around before beginning their research. It seems as though this system connects to a server which then sends back encrypted data. That data is then decrypted at the local client. And they made a browser plugin for it. How is this fundamentally different than public key encryption?

The performance is horrible. From the Mylar web site, "a 17% throughput loss and a 50 msec latency increase for sending a message in a chat application." A 17% throughput loss and 50ms latency is *huge* for something as trivial as a chat application. Imagine what happens when real data is being crunched.

There are still enough attack vectors that make this a non-starter. First off, the encryption itself is still brute-forceable by a determined attacker with enough resources. Second, it assumes a secure client environment. Finally, it assumes that your adversary plays by the rules and won't inject malicious code or backdoors into the software or encryption, with or without a complicit service provider. The client code can check authenticity? Cute, but only works if your adversary doesn't "require" that the service provider comply with a secret order to say that the code is authentic, even when backdoored.

Steve

I'm doing exactly this. I have a Pi firewall running with three total ethernet ports (the third is a wifi DMZ). I got another Pi and it's running asterisk for the house with a POTS connection via an Obi110. However, based on the load and RAM usage I could be using a single Pi for both. Speed tests show that the Pi performs the same as the full scale computer that it replaced. Check my blog for more details on the firewall rig. I haven't blogged about the asterisk setup yet. Steve

My first question is: Why? Why, if they're both hateful and fearful of change, would they need to change? Why not a newer version of Windows or a Mac?

Users aren't oriented towards their OS, they're oriented towards their tasks. Their typical question will begin with "How do I..." and then continue into "but then how do I...". So your first issue is to determine what they use and how they use it and then find out the best way to solve each of those individual use cases or problems. For example, "How do I manage my finances, I currently use Quicken?" or "How do I upload pictures from my camera?". You need to solve each of those use cases in a sane manner that's easy to use and just as good or better than what they have. Typical users, especially the ones you describe, don't want to spend any more time with their computer than they need to.

Don't underestimate a user's ability to forget things that they do on their computer. Again, they're task-oriented and so they won't necessarily remember that they need a certain program to update some infrequently used spreadsheet twice a year.

Only if you can help them complete their tasks should you switch; you shouldn't switch them to Linux because you perceive it as better; it might not be better for them and then they'll have a tainted view of Linux when in fact the problem was that they couldn't use their silly banner-creation software from 1999 on it.

Hi,

Well, you're going to need a presentation layer, which may or may not be obvious to you but HTML5 and JavaScript. You'll want to learn JavaScript but shortcut the process with jQuery and jQuery UI. And of course CSS3. So now you've got a pretty frontend, look and feel, behaviors, etc.

For the backend why not stick with Java? You know it already. If you're thinking PHP then that's fine too but stay away from the frameworks and shortcuts for PHP because they always end up becoming a burden down the road for upgrades, ongoing maintenance, and expansion.

I've had great luck with LAMP stack and with today's cloud bits and strong hosting providers, getting the infrastructure is easier than ever.

And if you're looking for books, try my JavaScript Step by Step book for JavaScript related (it includes jQuery too). O'Reilly has some good HTML5 material too.

Steve

Ugh. Seeing a sentence like this "...architect a machine only you could have dreamt of" makes me think that they may want to consider allowing just *one* non-developer... someone who can write.

Steve

Earlier in my career when I had to do level 1 tech support I might have liked opportunity to cut holes in skulls to make sure people heard what was being said. However, *hearing* what's being said and actually processing that into meaningful and actionable instructions are two different things.

The latest ECMAScript standard includes the 'use strict' pragma, which is one step towards what you're looking for.

Also, I was playing with Visual Studio 11 Express preview and it includes some decent code completion for JavaScript, which maybe fulfills some of your IDE stuff; though admittedly I haven't put it through its paces to see how well it does JavaScript code completion. Eclipse for JavaScript developers might do the same, I honestly haven't used it in a while for JavaScript writing. (I still prefer Vi for coding, versus an IDE, fyi).

Use the tools in Chrome or Firebug for Firefox to help with debugging.

You won't find the same advantages of compile-time error checking that you currently have but it also forces you to become more disciplined about thinking through your code and test cases when writing JavaScript. Obviously, the tradeoff is that if you don't test for it you won't find the error until someone finds it in the live environment.

Others have pointed out jQuery and I'll echo that. However, if you're like me you'll want to learn some of the underlying bits or the "why" something works and then augmenting with jQuery and other libraries. You'll want jQuery for most of the frontend work that you do.

And finally, I can't talk JavaScript without shamelessly plugging my book, JavaScript Step by Step.

Steve

Since I seem to be the last person on earth without a Facebook account, I think I'll sign up for this and start sending invites to all of those people on Facebook who keep spamming me to join.

Anyone have any invites to spare?

Steve

As someone who has written several books (ok, shameless self-promoting link to the latest one) I might suggest that you raise the price. Sound counterintuitive? People may be looking at your book and the price point of $0.99 and thinking "this might be a scam or reprint of some material already on the web." By raising the price to say $9.99 or $14.99 you're still below the traditionally published books but also give the appearance of extra value; the consumer is getting something valuable.

I know nothing of the self-publishing world, though I have considered it at various times. But if I was going to be publishing something for Kindle I'd likely be setting it at a higher price point to give my book separation from the spam.

Oh, typically royalties are in the 8% to 15% range for tech books, depending on the publisher and the deal being offered. The royalties are sometimes higher on the eBook versions. However, realize that the royalties are off of the wholesale price not the list or sale price. So if retail on JavaScript Step by Step is $39.99, Amazon has it for $25, but the publisher sold it to them for $20, I get a percentage of the $20 not of the $39.99.

YMMV.

Steve

But it's simply not realistic for the software to change significantly in 6 weeks. Web standards don't change that much in 6 weeks to warrant this much changing in the browser. Therefore, they're supporting largely the same codebase for months and months, same as before. At some point they add major new features and these are the ones that should get the new major version number.

Simply incrementing the major version every 6 weeks will hurt Mozilla and Firefox.