Last month, TreeHugger ran an article asking if Netflix streaming is greener than DVD-by-mail. The conclusion that the author presented is that DVD-by-mail is the greener option. I don’t necessarily disagree with the conclusion, but I have serious issues with the path to get there. Perhaps I’m judging it too harshly — it is, after all, a web article, not a scientific paper. It may be too much to ask for rigor in entertainment (Randall Munroe would agree, and I’m certainly guilty of hand-waving at times), but if we’re going to pretend to answer the question definitively, let’s put some effort into it.
The most obvious problem with the article is that “greener” is never defined. The author focuses on CO2 emissions, so I guess that’s the measure being used. While CO2 is valid, it’s hardly the only consideration in determining the environmental impact of Netflix. The DVDs must be manufactured and the shipping envelopes don’t get reused. For streaming, the hardware needs to be manufactured. These all require resources, both renewable and non-renewable. Even the CO2 emissions aren’t created equal if one considers the cost of extracting the oil needed to power the vehicles and the coal used to power the datacenters.
In “calculating” the CO2 output of streaming a Netflix movie, the author uses an entirely different kind of service and says that Netflix must generate more CO2 than that. That’s quite possible, but where’s the proof? In fact, a previous post by the same author says “[a]n even more efficient option is on-demand movies on cable, or movie downloading.” I’m now confused. Is streaming more efficient or is it a greater contributor to anthropogenic CO2 production?
It’s interesting and thought-provoking to ask if Netflix (or other similar services) is less-impactful in streaming or physical form. The article did a great service asking the question, but an incredible disservice in answering it. The answer is more complicated than a few quick calculations. It may prove that DVD-by-mail really is the “greener” option. I don’t know, but neither does Pablo Paster.
Despite our best efforts, machines sometimes get compromised. The culprit isn’t always (or even usually) a highly publicized group in it for the laughter. It could be a curious student, or an overzealous admin, or the Russians. Whoever is behind it, when it happens, it sucks. Especially if sensitive data is involved. So I really feel bad for my colleagues in the Math department at Purdue, who had to deal with this recently. According to the University News Service, over 7000 former students have been notified that an attacker potentially accessed their Social Security Number.
I know only as much about this as has been publicized, so I can’t speak to any specifics. What I can say is that stuff like this kept me up at night in my previous job. For years, SSNs were used to “anonymously” distribute grades to students. They’re nice because they’re a unique identifier and nearly everyone has one. Unfortunately, they’re also kind of important elsewhere and protected by state and federal laws. The upshot is that many faculty had files containing SSNs on their desktop or on removable media or on a file server.
In 2006, if memory serves, we were tasked with scanning every machine owned by the department for SSNs. This involved adapting some existing tools (which were basically just really fancy regular expressions to grep for), doing a room-by-room inventory, and then asking users to scan their machines and sift through the output. After the machine owners ran their own scans and cleaned up offending files, we did it again, this time forcing the scans and having the IT staff look for offensive files. It was a many-month project that was not by any means pleasant.
From the article, it sounds like it was similarly awful after this breach. You can’t assume that a SSN will be formatted 000-00-0000, so you have to look for 9-digit strings, which occur with alarming frequency. In this case, it appears that no one’s number was actually divulged, which simultaneously lends relief and futility to the exercise.
A while back, I needed to install Google Earth on my 64-bit Fedora 15 machine. Being a smart guy, I grabbed the 64-bit RPM and installed it. When I launched it, it failed because it needed a library provided by the redhat-lsb package. After installing redhat-lsb, I expected Google Earth to work. But instead, I was greeted with the same error. That’s when I began to realize that it was looking for /lib/ld-lsb.so.3 not /lib64/ld-lsb.so.3. So I checked the binary. It’s 32-bit.
To me, this seems like the exact wrong way to package this. The best way would be to build a 64-bit version and package that for 64-bit machines. The acceptable way would be to say “sorry, we only offer 32-bit builds of Google Earth”. The bad way is to pretend the 32-bit package is really 64-bit. This does not make installation more convenient, as Google says, it makes it less convenience because it breaks dependency solving. yum dutifully installs the 64-bit redhat-lsb because that’s what the package says it needs. It’s only after the binary is in place that it becomes evident that the 32-bit redhat-lsb package is needed.
If this bothers you, too, I’ve left feedback for Google. Feel free to pile on.