Minority Opinions

Not everyone can be mainstream, after all.

Archive for February 2013

Gunning for Safety

leave a comment »

A few of my co-workers have been mildly obsessed with recent gun control bills. One of them, noticing my lack of participation, asked whether I pay attention to the news.
“No,” I replied.
I was then asked, “Do you care?”
My response: “No. Bicycle safety makes a much bigger difference in my life.”
“Gun control can make a difference to your life.”
“It might sometime maybe make a difference. Cars kill more people than guns do.”

Read the rest of this entry »

Written by eswald

26 Feb 2013 at 9:20 pm

Posted in Lifestyle, Politics

Vague Python Ideas

leave a comment »

I recently spent some time perusing the python-ideas mailing list, particularly around the development of tulip, and a few ideas struck my fancy.

def __main__():

I’ve mentioned before that the standard scriptish prefix bugs me, but more recently I’ve noticed myself moving all logic out of an if __name__ == "__main__" block into a separate function.  Why not make that official?  The transition could be handled in a few steps:

  1. After loading the __main__ module, check to see whether it has a callable __main__ attribute.  If so, and if it hasn’t yet been called, call it.
  2. Give modules their real __name__ where appropriate.
  3. Remove the “hasn’t yet been called” hack.

I’m fine with parts of this process taking until Python 4, though I wouldn’t be surprised if the multiprocessing developers pushed it forward.

name := expression

A second assignment operator would be useful for while and elif conditions, but it was the discussion of a __bind__ operation that made it seem useful in its own right.  Basically, the statement above would translate into (expression).__bind__("name", locals()), where object.__bind__(self, name, namespace) would be implemented as namespace[name] = self.  (The translation doesn’t really have to call locals() to get the namespace, though.)

In general, it’s just a more expensive assignment statement.  The real power comes in letting an object know its canonical name.  The canonical examples here are namedtuple and ORM fields, which are usually passed the same names as they collect on assignment.

The object of the expression also discovers when it’s bound, and to what, either or both of which might be useful.  Something might want to raise an exception if it’s bound into an incompatible environment, for example, but considering that removing the colon bypasses that restriction, it might not be worth the code.

Finally, it can bind a new object in its place; in an example from the thread, NumPy array manipulation could use that signal to evaluate a chain of lazy operations.  Even more odd would be using it to unroll looped test cases, but it’s not likely to work well for functions.

Whether that power is worth the implementation cost, I’ll leave up to others.  In particular, I could be persuaded to implement it myself, but not on my own dime.  It may also have to fight against Greg’s secret plan.

Invisible async operations

The tulip discussion originally interested me as a potential way to move forward with a hobby project I’ve been neglecting.  At first, I had my own event loop, with support for calling tasks on network availability, at scheduled times, or in separate threads.  Eventually, I replaced it with Twisted, mostly to make it easier to support multiple protocols on the same port.  Since then, I’ve debated switching to something more like co-routines.  That such an event loop might become standard makes me happy.

The tulip project itself, though, highlights a design decision that might become a sticking point: yield from gets proliferated every time something could block.  Worse, some of the functions designed for iteration look just like functions you might call directly.  That makes me think that perhaps gevent has the right idea with its monkey patching:  Calls to certain socket interfaces are invisibly replaced with something that uses a magically created event loop under the hood.

Seriously, when would a coroutine yield control?  Mostly on network I/O, sometimes when sleeping either for a given duration or until a given time, occasionally on other blocking system calls, rarely while waiting for another thread to give it a result, and seldom explicitly just to be nice during a long calculation.  All of that blocking could be handled at a low level, by packing up the current frame as a closure and continuing it later.  Does it need to know that it’s going to be suspended?

Perhaps I’ve just been contaminated by having learned a bit of the Go language, but it would be nice to have it in the language I already know and love.

Written by eswald

19 Feb 2013 at 7:19 pm

Posted in Python, Technology

Musing on Relationships

leave a comment »

A local radio station has been playing Madness lately, and it started to make me think.  I’ve had a relationship like that; it lasted off and on for two years, and wasn’t truly over for a year and a half after that.  It was fun, but wasn’t what we truly needed.

My relationship with my spouse is entirely different.  At its core, we trust each other.  We talk to each other, and our expectations have been made clear.  Much of what we actually do is boring, but that works for us.  We prefer stability over drama.  Our parents have provided enough drama for one lifetime.

Read the rest of this entry »

Written by eswald

12 Feb 2013 at 7:37 pm

Posted in Lifestyle

DNS Service Discovery

leave a comment »

Recently, I’ve been annoyed by trying to jam too many websites into a single IP address.  An obscure detail of Apache configuration caused half an hour of downtime for one of our sites, and is threatening to cause more.  Somewhere in the middle, I remembered something about DNSCurve, a project to encrypt and authenticate all traffic on the internet, starting at the DNS level.

Basically, DNSCurve is starting with the premise that public keys can be published via the DNS protocol itself.  In fact, if the nameserver’s public key has been published, then those keys can be used to encrypt and authenticate the DNS traffic itself.  For other services, the server can decrypt traffic using the corresponding private key either as part of the service’s protocol, or as part of the network stack itself.  For extra protection, a symmetric key can be negotiated as part of setting up a streaming transport.  The keys don’t even have to be signed by a trusted authority, as long as you can trust your DNS cache and each of the servers it contacts.  (If you don’t, then you have bigger problems anyway.)

The weakest link in the chain is adoption.  DNS-based attacks haven’t yet been severe enough for everyone to be clamoring for encrypted traffic, nor has it been entirely clear that this is the best solution.  Worse, name servers are largely run by registry companies, and name caches are largely run by internet service providers, neither of whom are the ones truly affected by an attack.  They need some pressure to switch, either from the (uninformed and unorganized) consumer base, or from (inertial and slightly less uninformed) companies.  To provide that pressure, the companies need to know that they’re going to get something out of it.

As long as we’re meddling with DNS, it might be nice to get rid of the idea of well-known ports, and throw load-balancing in for free.  It turns out that this isn’t a new idea, either; in fact, it’s the sole purpose of the SRV record type.  A few major protocols and plenty of minor ones seem to be using it, but not the most important ones.  Am I missing something important?  If I were to publish _https._tcp.example.com records, would anything use it?  In particular, would getaddrinfo() look for it?

If that’s the case, then a little DNS trickery is all we would really need to make Apache serve the right SSL certificate for each domain name, without having to put the port number into every URL.  (Yes, I know that modern browsers and SSL implementations allow for server name indications, but we’re forced to deal with IE 7.  And still get complaints from IE 6 users.)  Sadly, there might still be some firewall issues to work around; some of our clients might be restricted to ports 80 and 443.  Then again, certain firewalls are already configured with our domain names, so maybe the firewall could dynamically open the right ports if it knew that it would need to.

For an ideal connection, the two ideas could be combined.  Take a hostname and service, and open an encrypted connection to any of several load-balanced servers listening on arbitrary ports.  It would still take quite a bit to overcome the inertia of well-known port numbers, but even that can be promoted in the name of security.  I’m already dealing with SSH servers with goofy port numbers, for example; the default ones were collecting too much brute-force traffic, even with passwords completely disabled.

I imagine we’d get some pushback from certificate authorities, though.  How much of their business model is based on making people pay for a bit of assurance against man-in-the-middle attacks?  There might also be complaints from people worried about every last bit of performance, particularly in embedded systems, and from Iran, where all encrypted connections are blocked in the name of national security.

It’s also possible that IPv6 has some of this baked in.  One of these days, I may get around to trying it out.

Written by eswald

5 Feb 2013 at 6:53 pm

Posted in Linux, Technology