use Perl;

Still my favorite PHP bug story: http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html Though this one isn't far off: https://bugs.php.net/bug.php?id=18556.

And I've responded elsewhere at http://use.perl.org/comments.pl?sid=44429&threshold=0&comments… For those who don't want to follow the link the short version is that I am unconvinced and still think the claim is false advertising.

mjd also wrote on this: "There must be a specification," a couple of people said. "Just write the tests to check the requirements in the specification." There was an amazing disconnect here between what I was asking and what they were answering. http://use.perl.org/comments.pl?sid=42511&cid=67765 I think TDD is a great idea - if "you know what you are doing". It solidifies your interfaces. Which is great, provided you won't want to change your interfaces. It's the dogmatism of TDD that scares me. When "heresy" is applied to a methodology, it makes me think that a theory of reality has been favoured over reality. But hey, maybe that leaves the field clear for the reality-seekers.

Are you suggesting that the Perl community didn't follow the strategy of a) making this mistake over and over for a decade b) finally realizing, in the course of some blog posts or their equivalent, that they needed a library to fix it? c) making that library? Because here's what appears to be the Perl equivalent of this Ruby blog post, from 2005: http://use.perl.org/comments.pl?cid=45240&sid=29890 This post is promoting the Proc::UID library, which was apparently only a year old at the time and was not quite finished. The release on CPAN was marked "for testing and review purposes only. Please do not use in production code." http://search.cpan.org/~pjf/Proc-UID-0.04/UID.pm The newer Privileges::Drop library, which you link to, dates back only to 2007. Perl is more mature than Ruby. But perhaps only a few years more mature.

http://www.perlmonks.org http://use.perl.org

Sixel support is slowly making its way out in some terminals --- xterm has support, but it's not compiled in by default, at least not in the version of Debian I've got here. (I've never seen any terminals with Regis support.) It'd be really nice if it would show up soon; there's a number of cool things I want to do with it. However, xterms have supported TEK 4010 graphics support for years. It works really well --- unfortunately the TEK 4010 was a vector storage scope device, with no video framebuffer; it literally drew lines on a phosphor screen using an electron gun, and so cannot draw in black. It's surprisingly limiting. http://use.perl.org/use.perl.org/_scrottie/journal/39195.html

I don't care how "successful" Netflix becomes: I will not do business with spammers, and if you do business with Netflix, you are supporting a company that engages in spam. References: https://groups.google.com/forum/#!topic/news.admin.net-abuse.email/o2I… http://use.perl.org/use.perl.org/_jdavidb/journal/18650.html http://web.archive.org/web/20050215120033/http://manatee.mojam.com/~sk… (And yes, I have personally received spam E-mails advertising Netflix.)

This original announcement, which said "18 to 24 months, with a prerelease targeted for [July 2001]"? http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/19/161217

Worse, it is not even a certain check against integer overflow. A particularly large expression could have overflowed substantially enough that it becomes positive again! This, in fact, was the source of a vulnerability in PHP [1]. (The way they 'resolved' it, uh, isn't much better.) There is almost never a magic bullet for integer overflow. Programming secure systems requires thought. [1] http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html

Hmmm, that looks oddly familiar: http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html

Here's a gem from an attempt to fix an integer overflow vulnerability in the PHP compiler: if (size > INT_MAX) return NULL; http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html

My personal all time mysql fave - values that are both null and not-null http://use.perl.org/use.perl.org/_Adrian/journal/32627.html

I don't understand how the contrast -- using category theory to derive notions of computation and something attempting to patch up Perl's object system -- relates to the rest of the essay. I don't mean to be coy, but what's the point? Is it that business skills are important, too, and that universities (and their CS departments in particular) are underserving the computing industry? That's what one of the comments (http://use.perl.org/comments.pl?sid=42485&cid=67709) seems to indicate. The American education system needs some work, but I think it's a mistake to see a university education as vocational training: the "fields" in a university don't correspond to "fields" in the world. It's a coincidence that computer science roughly corresponds to a field in high demand these days.

A little brother using Chrome regularly won't know about keyloggers, how to write a clever bookmarklet, or even be allowed to be around when his big sister is typing in her password. But there's a good chance he does know about clicking that little icon, choosing "settings", and seeing all of his big sister's passwords when she's out on a date and forgot to lock her computer. Locks on your front door knob are not there to keep out burglars. They're there to prevent opportunistic crime: someone who tries that doorknob out of curiosity and discovers a home full of stuff and no one around. There's a large middle ground between good guys, bad guys, and those who might, just might, be tempted to be bad when they find that suitcase full of money. That's what Google is missing here. And in a condescending response[1], someone who is allegedly the Google head of Chrome security called the original author a "novice", claimed Google has "quite a bit of data" to back up their case (without describing the data, its source, or how it was evaluated), and suggested that a master password would make security worse by providing a false sense of security. First, I would suggest that if Google really does have the data mentioned in the claim, release it. Second, a master password isn't going to make the computer safer from a determined black hat because physical access to the machine means game over, but THE MASTER PASSWORD IS NOT ABOUT PROTECTION FROM BLACK HATS. When the colleague who…