Since I’m in Boston, we have a lot of snow to deal with this winter. The other day I was clearing snow off my roof with a roof rake, and after about an hour for some reason it started pulling to the left when I pulled straight down. I started to compensate by pulling the roof rake more to the right to compensate, but that didn’t really help much. After finally getting frustrated enough to pull the roof rake down and look at it, I saw that one of the support brackets was no longer screwed to the rake, so the blade was unsupported on that side. That’s why the rake was pulling to the left. Had I looked at the rake as soon as I noticed the problem, I would have saved a lot of frustration, and possible permanent damage to the roof rake. I fee we do the same thing with our software tools a lot.
Very often I’ve seen software where the usual reaction to compilation warnings is to tell the compiler to ignore them. There are times when this is appropriate. My favorite example of this is with Java Generics, where it’s very hard to get around some of the warnings for things that you and I know are perfectly safe. Most of the time, though, compiler warnings are indicating a moderate to serious problem, or at least an area where the program might not be doing what you think it is. Eliminating those warnings is an excellent collaborative activity, because we all have experience with different software issues.
So the next time you feel tempted to “ignore the Check Engine” light, spend some time finding out if there’s a more elegant solution than putting tape over it.
Today’s lesson for hardware people, software people, architects, and mad scientists is brought to you by Ray Bradbury in the form of a short story called There Will Come Soft Rains. I recommend you follow this link and read a copy of the story, as it’s only a few pages long, and well done (but I already said it was Ray Bradbury, didn’t I?). The story, written in 1950, takes place in 2026 in a very modern, fully automated house, with all sorts of computers keeping its occupants fed, cleaned, entertained, and on schedule for work, school, and play.
Only there are no more occupants. Because there was a nuclear war, and they’re all ashes. The house (the last house standing), in it’s quite-less-than-infinite wisdom, has not caught on to this. So it prepares eggs and pancakes for breakfast, and provides entertainment in the nursery, and defends itself from the few birds and animals that may approach it, and fleets of mechanical robots diligently clean up any dirt that gets in the house and dispose of the uneaten food. In short, this system has insufficient connection to the world it interfaces with, and too few checks on expected responses, to know that something is horribly wrong.
According to this article (and others), Python creator and BDFL (“Benevolent Dictator For Life”) Guido van Rossum froze the Python language’s syntax and grammar in their current form for the the next few releases, and possibly longer. The reasons are good ones; To let developers catch up to the latest release, to let the rich array of third-party tools stabilize, and to improve the quality of the existing libraries.
I think it’s a bold move, but the right move. There are a lot of “hot” languages that are very popular right now, and Google just complicated the mix more with Go, a type-safe language bred for terseness. Just like with Linux distributions, some people look for the New Hotness and some people look for stability. Python, while very rich and powerful, is being rebalanced in this regard to ensure it stays reliable, predictable, and usable by the masses. Maybe this step was possible because the language is essentially the brainchild of one BDFL instead of a committee, like Java. Java remains my primary development language at this point, and it has definitely improved over the last few releases, but there are inconsistencies leaking into it. They can’t even keep to a consistent release numbering scheme (you think they would have learned that lesson from their OS).
I hope the Python community achieves these goals they’ve set for themselves and makes Python even better.
This is not a new issue, but I just found out about it from this article on TechRepublic.com (yes, their URL is technrepublic.com.com). They state that Firewire (IEEE 1394), unlike USB, was designed more as an external system bus connection, not just for external storage. That allows Firewire devices to sneak in under the covers and do pretty much whatever they want, waving the “I’m with the band!” badge at any secuirty, including logging into the system.
Since this is part of the design of Firewire, it’s not a bug that can be fixed. You cannot protect against security breach by firewire device and still adhere to the standard. This isn’t to say it’s time to weld a metal plate over your laptop’s Firewire port and a tin foil hat on your head, because this isn’t something that you hear about happening in the wild, even though there’s a program out there to do it.
I’m Assistant Director of the Boston Linux and UNIX group. A few times a year, we have an event at MIT where people come down with their computer and we help them install Linux, or just answer their questions. The event is free (though we do ask for a donation, since we’re not-for-profit), and we’re there all day.
Date and Time: Saturday, May 30, 2009 from 9:00 am to 5:00 pm
Location: MIT Building E51, Room 061
Summary: A periodic get-together where volunteers from our group help people with Linux installation and other hands-on issues.We invite you to become a member of the Boston area Linux community and offer our assistance in getting Linux installed on your computer.
We hold our InstallFests several times each year; we meet on a weekend at a location where people can bring in their computers and we can help them install Linux or other Unix variants. It’s also a great way to get together and share our collective experience with each other in a hands-on learning environment, in the grand tradition of the UNIX community.
For more information, check out the page on the BLU website.