placeholder for https://plus.google.com/115609618223925128756/posts/PDPdXTxAvZk

I posted my comments on veracity there because a lot *more* of my gitolite/git contacts are there.


meta comment on blogs and g+: at some point we'll have to choose one; we can't update both.  I'd love to move to G+ for my blogging also, but it doesn't have a search box anywhere that I can see.  I depend on that a lot to find stuff I wrote about long ago, and without that I can't really make it the main outlet for my random typing!


Dijkstra endorses perl (well, I'm stretching it a wee bit... ;-)

Dijkstra quote: If we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent".


debugging "clever" code

""Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

— Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.

This came up in a comment about an LWN article on how subtle and tricky some of [the Linux kernel] core code has become.  Some of the more interesting quotes from that article and its links:

(in the original email from Hugh Dickins):
That -ENOENT in walk_component: isn't it assuming we found a negative dentry, before reaching the read_seqcount_retry which complete_walk (or nameidata_drop_rcu_last before 3.0) would use to confirm a successful lookup?  And can't memory pressure prune a dentry, coming to dentry_kill which __d_drops to unhash before dentry_iput resets d_inode to NULL, but the dentry_rcuwalk_barrier between those is ineffective if the other end ignores the seqcount?
Let's call this "establishing the baseline" -- anyone who did not understand at least 75% of this will be lost as far as the real problem is concerned.  But what about the people who *did* understand it (or at least, had the best chance to):
There is a sobering conclusion to be drawn from this episode, though. The behavior of the dentry cache is, at this point, so subtle that even the combined brainpower of developers like Linus, Al, and Hugh has a hard time figuring out what is going on. These same developers are visibly nervous about making changes in that part of the kernel. Our once approachable and hackable kernel has, over time, become more complex and difficult to understand. Much of that is unavoidable; the environment the kernel runs in has, itself, become much more complex over the last 20 years. But if we reach a point where almost nobody can understand, review, or fix some of our core code, we may be headed for long-term trouble.
uh oh...!


Forbes columnist on "Microsoft's Android Shakedown"


Nice quote: "Getting software patents takes a lot of work, but it's not primarily engineering effort. The complexity of software and low standards for patent eligibility mean that software engineers produce potentially patentable ideas all the time. But most engineers don't think of these relatively trivial ideas as 'inventions' worthy of a patent. What's needed to get tens of thousands of patents is a re-education campaign to train engineers to write down every trivial idea that pops into their heads, and a large and disciplined legal bureaucracy to turn all those ideas into patent applications."

But I think there's one more point to be made here.

The decades-old Sun/IBM incident, narrated as the intro to that article, doesn't describe what would happen today. The alternative the "blue suit" suggested was one where IBM would actually spend the time to find *real* infringements, if Sun refused to buckle.

That was the 80s. Today, if HTC resisted, MS would proceed directly to litigation even if they knew the specific claims being made were without merit.

In other words, while Sun capitulated due to the fear of real infringement being found, I believe today's defendants pay up due to fear of the litigation itself!

Big difference!


Jon's impressions of Chromium


I guess I'll stick to Firefox -- NoScript is kind of a necessity right now :-)

It might not be bad as a second browser though, although one has to watch out for the Chromium/Chrome distinction!

[And by the way, I never understood Google's need to call a browser by the internal name for the UI component of a competing browser!]