I’m collecting baseball cards again.
I collected for most of my youth, but as adulthood set in, other priorities took over. It happens a lot. But now my kids are getting old enough to take an interest in such things, and if my son is buying baseball cards, I might as well buy a card or two myself, right?
On Christmas Eve, I decided to take on a challenge: The 1935 Goudey set. Goudey was the biggest name of the 1930s, but at 36 cards, the 1935 set is small enough that a mere mortal like me can stand a chance of accumulating one example of each, and do so in a reasonable period of time. Most of the player drawings in the 1935 set are reused from the 1933 and/or 1934 sets, so it looks and feels like a classic Goudey set.
It’s not going to be a particularly cheap endeavor, but with one exception, it’s possible to get a low-grade example of each card in the set for $10-$15. A complete set in low grade is likely to cost less than $1,000. And while $1,000 is a lot of money, that’s approximately $20 a week. Most of us spend $20 a week on things that aren’t particularly good for us. Spend two years doing it and it drops to $10 a week.
A really bad remote code execution bug surfaced yesterday, in Bash–the GNU replacement for the Unix shell. If you have a webserver running, or possibly just SSH, it can be used to execute arbitrary code. It affects anything Unixy–Linux, BSD, Mac OS X, and likely many proprietary Unix flavors, since many of them have adopted the GNU toolchain.
This could be really bad. Some people are calling it potentially worse than Heartbleed. Maybe. I’m thinking it’s more along the lines of MS08-067. But there’s an important lesson we must learn from this. Read more
Dan Bowman kindly pointed out to me that former Commodore engineer Bil Herd wrapped up his discussion of the ill-fated Commodore TED machines on Hackaday this week. Here in the States, few remember the TED specifically, but some people may remember that oddball Commodore Plus/4 that closeout companies sold for $79 in 1985 and 1986. The Plus/4 was one of those TED machines. So was the Commodore 16.
What went wrong with those machines? Commodore miscalculated what the market was doing. The TED was a solution to too many problems, and ended up not solving any of them all that well. Read more
My 9-5 gig revolves primarily around Tibco LogLogic (I’ll write it as Log Logic going forward, as I write in English, not C++), which is a centralized logging product. The appliances collect logs from a variety of dissimilar systems and present you with a unified, web-based interface to search them. When something goes wrong, having all of the logs in one place is invaluable for figuring it out.
That value comes at a price. I don’t know exactly what these appliances cost, but generally speaking, $100,000 is a good starting point for an estimate. So what if I told you that you could store 45% more data on these expensive appliances, and increase their performance very modestly (2-5 percent) in the process? Read on.
Some revolutionary advice surfaced this past week–stop patching everything. And while I understand the argument that people need to stop letting the difficulty of patching everything paralyze them and cause them to do nothing–as I’ve seen some organizations do–and I agree that some patches are more critical than others, as someone who once had to prioritize patches, I can assure you that prioritizing the patches was more work than deploying them and recovering from the fallout was. We eventually found it was much less work just to install all the missing patches every month.
And guess what? Nothing bad happened from doing that.
I saw this phrase in a job description last week: Troubleshooting at all layers of the OSI model. That sounds a bit intimidating, right?
Maybe at first. But let’s not overcomplicate it. Once you get past the terminology, it’s a logical way to locate and fix problems. Chances are you already do most of this whether you realize it or not. I was already troubleshooting at at least four of the seven layers when I was working as a part-time desktop support technician in college in 1995.
Thanks to Tony’s Kansas City for the link this morning. Tony noted that “Security dude reminds us that Google Fiber could kill the software industry.”
That’s an interesting spin. I do think it will affect the software industry–but so long as Kansas City stays at the forefront and the rest of the country is content with being a technological backwater, the effect will be minimal. But “kill” is an awfully strong word, even if every major city in the country were to get affordable Gigabit Internet in the very near future.
I say that because of what I saw in college. Read more
Yesterday an interesting question popped up on Slashdot, asking for an alternative to a computer science degree for an aspiring web developer. He complained that what he’s learning in class doesn’t relate to what he wants to do in the field.