Thanks, I'll certainly be running that now!

The N9 is a wonderful phone, can certainly be scripted (I ssh into mine all the time to do things), but lacks a physical keyboard. The onscreen one is great, but because it takes half the screen it makes the shell-window smaller. (really, you might want an N950, but those "don't exist" and getting one is difficult, plus the antenna issues make it less useful as a real phone).

The N900, now hard to locate, has a great screen, a great keyboard and is the predecessor to the N9. But they have a known issue with the USB port breaking over time, so if you do actually succeed in finding one to buy don't expect it to last forever and ever. But this is 2000+ where things aren't expected to last longer than a few years.

sigh

the sky is still blue.

Just like the windows screen-of-death soon to be seen on your "substandard phone".

The QML language is amazingly simple to learn and contains javascript snippets to drive the complex stuff. It has much better concepts of variable bindings than HTML/Javascript alone and is significantly faster (and runs on pretty much everything).

I recently taught a child QML and had her create a Mahjong game for her mother in a couple of weeks. I did some of the harder javascript logic, but she did most of the entire game from scratch. Oh, and she learned git in the process and the concept of simultanious development during the portions I was working on the javascript to create the game board structure (she had to tell me the algorithm though).

side note: she would have done the harder code too, but we were short on time for the present to get delivered

The worst change is that in order to have a secure browser you have to be using the current version of Chrome.

You seem to think they think this is a bad thing...

yes, you should because you're still modifying the data (it's just the DNSSEC data that's getting modified in this case, even if your normal "usage" data isn't).

True, though it's not a transcript: it's a very different set of text. I don't think transcripts are useful because they're designed around a video. The web page, on the other hand, is a tutorial that is independent of the video.

Side note: the video describes other tools as well, not just zonesigner. The web page only has zonesigner on it (though you could go find the similar pages for donuts, lsdnssec, etc, that the video shows)

No, I agree with you. But it is the new trend because some people definitely prefer to see it over time rather than over a page. Color me confused as well.

But we have a text version as well, so never fear: https://www.dnssec-tools.org/wiki/index.php/Sign_Your_Zone

Signing you own zone is trivial and you don't need to pay anyone. I even created a simple, short video on the subject using the DNSSEC-Tools components: http://www.youtube.com/watch?v=7ksgTFxAg6U

Though I'm associated with the above project, I actually don't care what tool set you use: just sign your zone!

I've only played 1st (long ago) and 4th (much more recently and not nearly as long). IMHO, the 4th battles don't seem longer than I remember the 1st battles being: they're all long. But not unreasonably long. Good players stream line it, bad ones need to be walked through each step. The important thing is to have everyone write down (ahead of time) all their likely bonuses, etc, per power they're likely to use and then the addition is easy and doesn't take time. There's even a spot for it on the character sheet (though the spot isn't big enough).

We've had very few vulnerabilities in general, but it is not our responsibility to fix vendor's products. We announce a fix, be it generic bug or security related, and off it goes. When your code is distributed very and very wide, it's a challenging task no matter what the license is. In fact, the last critical flaw that was found a few years ago had a CERT disclosure that was leaked far in advance of the CERT defined time-line. When you notify half the world through CERT, there isn't a huge amount of chance of keeping things quiet (and if we ever have another issue, I'm no longer sure CERT is the right process to take it through).

It is not necessarily easier to ensure every linux distributor has a devoted package manager that will notice the change either. Simply put, it doesn't matter who needs to know about an issue: there are far far too many to manually track (CERT proved this last time). If downstreams can't subscribe to a low volume -announce list and push out fixes rapidly, then that branch of the world is in a serious bit of hurt.

As the maintainer of Net-SNMP I've received a huge number of patches that would never have been given to us if Net-SNMP used a GPL license (though in this case, the code predates the GPL). Companies that have worked on the Net-SNMP code and have given back to it do so because they want to use their cool new feature they've developed for the code base in their proprietary software or hardware. IE, the Net-SNMP libraries and applications are the base upon which they build. It's important to them to contribute their patches to the base back to the core Net-SNMP repository so they can be assured future patches will not conflict with their feature (ie, because a patch isn't accepted that breaks the existing code base). Plus it gets their name in lights (ie, the COPYING file. Not many lumens, but still "lights").

I've been told many times that if Net-SNMP was GPLed code it would never be used. But since it's not, it's used in pretty much distributed by nearly ever OS vendor except Microsoft, and is used on a ton of embedded hardware. This would not have happened if it was a GPLed code base.

(ok, Microsoft still wouldn't be distributing it and linux* still would be; but all bets on Apple, Sun, etc, would be off)

By double-clicking on your pinky, silly.

Nah. Think "flip books".