This is a guest post by James Hutter, a technology librarian in New York. The post was written for the 2015 International Day Against DRM.
As Defective by Design celebrates another Day Against DRM Digital Restrictions Management, many overlook the significant impact that DRM has had on public libraries and their avid readers. Today, public libraries everywhere are directly affected by DRM, by the will of book publishers or of authors, in a variety of ways. Perhaps the most common appearance of DRM technology is its frequent integration into published e-books and downloadable audiobooks as a way to prevent them from being copied or shared. The reality is that publishers and authors’ use of DRM technology in electronic works is flawed and unethical for a number of reasons—and should be argued against by library advocates throughout the world.
Entities that have decided to force published works, such as e-books and downloadable audiobooks, to integrate DRM technology have fundamentally broken the library lending model. In the past, if a library wished to share a physical book with a reader, there was little to prevent that person from enjoying the publication. Today, for that reader to enjoy an author’s work in electronic format, there will likely be significant technical hurdles that they must overcome. They must use download services that have made agreements with book publishers. Readers must own devices that are supported by the download services (and if your device isn’t supported—you are out of luck).
We exist in a reality of tight and highly limited library budgets. Yet libraries must now be willing to pay for not only the electronic publications that will be added to their collection, but also for overall access to the download service that provides those works. This is, for all purposes, to help maintain DRM’s hold over an electronic work. For many libraries, this particular cost is extremely high—sometimes prohibitively high. For libraries that may be able to afford access to the download service, they find themselves suddenly “sticker shocked” when they see that individual e-books may cost many times the price of their physical counterparts. Library staff are then angry to learn that the e-books they’ve purchased have a shelf life of 52 weeks after which they become unusable.
It is clear that this goes beyond mere inconvenience. DRM has been utilized as a weapon by book publishers to fundamentally change the library lending model and manipulate it in such a way that they can now dictate the terms of ownership. Through DRM, publishers are now licensing creative works to libraries instead of selling ownership of them. Through the combination of licensing, DRM, and tightly controlled delivery methods, publishers now dictate that an e-book “wears out” after 26 downloads and must be re-purchased (meaning the license must be renewed).
It is worth noting that some authors have released their works DRM-free and some download services have begun sharing electronic audiobooks in non-DRM format. Those that have done so should be applauded and supported. However, there is still much more that can be done, and the fight against DRM is anything but over.
Extremely tight controls, high pricing, e-books without ownership… as I sit here, I have to wonder, was DRM put into place because publishers think the library lending model is theft and our readers are thieves? DRM gives these publishers a level of control over libraries that must be reversed and the Day Against DRM raises awareness on this critical issue.
James Hutter is an opponent of DRM, an advocate of free software and supporter of electronic privacy rights, he has a love for all things library-related. The views and opinions expressed in this piece are his own. You can follow him at @james_lead on Twitter.
I generally liked it, but almost stopped watching halfway through. This movie wasn’t original or interesting enough for me to want to see it again. Peter Parker didn’t feel like Peter Parker. While that could be okay, it felt like the character wasn’t developed as much as he needed to be. Maybe I just prefer the first Spider-Man film… but I don’t think this one deserves a 5 star review like some others have given it.
The in-progress Vagrant AWS has a lot of promise, especially for devops. The ability to test your Puppet or Chef scripts on an EC2 instance using Vagrant is very tempting. Unfortunately, it’s not yet quite stable enough to rely on, in my experience. Some errors seem to happen sporadically. Most are related to ssh, although running ssh manually works fine (either vagrant ssh or ssh user@host).
Sometimes, something as simple as mkdir fails without reason:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mkdir -p '/vagrant'
Other times, rsync completes, but then it immediately terminates the instance:
[default] Rsyncing folder: /home/ben/aws-sandbox/ => /vagrant
[default] Terminating the instance...
I’m still hopeful that it can be useful to us in the future. Like I said, there’s a lot of promise in this young project.
At any rate, we took some time to research how to get SSH agent forwarding working, which is valuable for us when remote pairing. We were getting stuck with errors like this:
It turns out that vagrant itself ignores anything but identity files, which was key to getting agent forwarding to work. This can be inspected using vagrant ssh-config
It turns out that lib/vagrant/util/ssh.rb can be modified like so:
@@ -108,7 +108,7 @@ module Vagrant
# IdentitiesOnly option. Also, we don't enable it in plain mode so
# that SSH properly searches our identities and tries to do it itself.
if !Platform.solaris? && !plain_mode
- command_options += ["-o", "IdentitiesOnly=yes"]
+ command_options += ["-o", "IdentitiesOnly=no"]
# If we're not in plain mode, attach the private key path.
There’s a related change that can be made to make vagrant ssh-config match, but it seems to be cosmetic:
@@ -6,7 +6,7 @@ Host <%= host_key %>
IdentityFile "<%= private_key_path %>"
- IdentitiesOnly yes
+ IdentitiesOnly no
<% if forward_agent -%>
That was enough to get our SSH agent forwarding to work. These changes make sense in the context of AWS, but probably not in Vagrant at large. I’m tempted to make a pull request, but the above changes are a little half baked — and vagrant-aws still needs some fine tuning before the change can really be tested.
The preferences look nice but are hard to use. I wouldn’t have found out that I had to click the “check” next to my newly-added city to get it to stick if I hadn’t read it on a blog post. That needs a fix ASAP, as I’m not the only one running into it!
However, there wasn’t a built-in way that I could find to get the next leap year. It turned out to be pretty simple, but still worth sharing.
# License: MIT
year += 1 until Date.leap?(year)
describe 'next_leap_year' do
describe 'given a leap year' do
it 'returns the same year' do
describe 'given a non-leap year' do
it 'returns the next leap year' do
I recently helped an intern at Hedgeye work through a problem with a database query. Because I’m working in a separate timezone, I ended up making suggestions through a GitHub pull request. We discussed and decided that what I wrote was self-contained enough that I should re-post so it can help others.
I’m what you might call an “Iowa City enthusiast”. As residents, we are extremely fortunate to be surrounded by an incredible number of people who work every day to make this a better place to live.
Even so, Iowa City has its blemishes. When I first relocated to study at the University of Iowa, I was taken aback by how hard it is to use a car here. Where I used to live, I was used to driving everywhere and not having to worry much about parking. Iowa City has a famously pedestrian downtown and it can sometimes be at odds with car ownership in general.
But we all have places to be, don’t we? Cars give an amazing sense of freedom and independence, but as many have found, they also can be amazingly expensive and often inconvenient.
I just moved back to Iowa City, after living in New Haven, CT because of a job at the Yale School of Medicine. While I was there, I was happy to find a great car-sharing service called Zipcar that included a Yale-subsidized membership. I even lived there for a year without owning my own car. When we decided to move back, I was happy to learn that Zipcar was coming to Iowa City soon after we arrived. If only it had been here when I was a student!
I still work for a company based out of New Haven, CT (they’ve been gracious enough to let me work remotely from Iowa), and I often travel for work and open source conferences. It’s great to know that I have a car waiting for me downtown Iowa City if I need it, in New Haven two blocks from my office, in Philadelphia and New York if I get stuck, and in many cities where I might visit. That’s not bad for a small yearly membership fee and then $8/hr. That price includes gas, maintenance, and auto insurance too.
We do still own a car, but with Zipcar and everything else Iowa City has to offer, we’ve been able to delay the purchase of another. That helps reduce traffic congestion in Iowa City, saves us money, reduces our environmental footprint, and reduces the number of car related headaches we have. To me, that’s a great example of a win-win scenario.