A bit over a month ago I wrote about howspam from outlook.com had started showing up with a null senderaddress (a MAIL FROM of ' <> '). It will probably not surpriseyou to hear that this spam has continued, and in fact has likelyintensified. Based on what I've seen in our logs and in a spamtrapthat I enabled in order to collect samples of this spam, a numberof spammers appear to have worked out that Microsoft will let themget away with this

In a comment on my entry on chroot() 's history ,Greg A. Woods noted that System III is the first Unix where chroot() actually prevents your process from just doing chdir("/..") toescape the new root directory. System III predates 4.x BSD, so Iwas more or less wrong in my entry on this .Only in the BSD line was 4.1c the starting point for this bit of chroot() security. System III source code is

In this entry , I covered my problemswith trying to find a good PS/2 to USB converter so that I couldkeep using my favorite keyboard and mice .Since then I have more or less come up with a solution, althoughit's not a complete one.

Based on Chris Wage 's recommendation,we got a PS/2 to USB converter that's specifically beloved by theIBM Model M fans. Specifically, the ZioTek 'PS2 Keyboard & Mouseto USB Adapter'; here is

Yesterday around 6pm, the department 'sconnection to the campus backbone had its performance basicallyfall off a cliff. Packet loss jumped and bandwidth dropped fromthat appropriate to gigabit Ethernet down to the level of a goodhome connection (it seems to have been running around 16 Mbits/secinbound, although somewhat more outbound). People started noticingthis morning, which resulted in us running around and talking tothe university's central NOC (who run the backbone and thus therouter that we connect to)

Yesterday I wrote about how CPython trusts bytecode so much thatyou can use it to read or write arbitrary memory .In comments, Ewen McNeil had a typical reaction to this:

It appears this means if you can get arbitrary Python execution (eg,unwisely trusting YAML, XML, pickle, etc...), then you can probablyget arbitrary memory read/write in the Python process, which is afairly short step away from arbitrary assembly code execution.

This is true, but it also misunderstands the security

I've written before that Python bytecode is not secure , and at the time I said:

[...] I wouldn't be surprised if hand-generating crazy instructionsequences could do things like crash CPython (in fact, I'm prettyconfidant that doing this is relatively trivial) and lead to arbitrarycode execution. [...]

It turns out that I was exactly correct here, and it's actuallybeen both found and demonstrated. Start with this tweet :

Python devs will

Canada just had a federal election, and I got asked in passing who Ivoted for. As always, I gave my standard answer for this question,namely that I don't ever talk about how I voted. This is the answerI give to everyone who asks, even my kith and kin; I'll never admitto voting for anyone, no matter what.

It doesn't matter that my likely votes are probably often easy toguess (especially for my kith and kin), and it

Suppose, not entirely hypothetically, that you want to install someadditional OmniOS systems with their kernels pinned to a specificversion, one that you know works because it's what you're alreadyrunning on your current OmniOS machine (in fact, perhaps you arehaving problems with a more recent kernel on your test machine).In order to do this, you're going to need to do three things: youneed to find out what versions of what packages to pin , then you need to actually install

Here is something that I didn't fully grasp and understand until Idid some digging in the Go compiler as part of writing a recententry :

Despite being in a package, unsafe.Pointer is really a built in typein the Go compiler, just like map , chan , string , and so on.

While there is an unsafe package and it looks somewhat superficiallylike reflect (which is a real package with real code), this isan illusion. All parts of unsafe are implemented at compile timeinside