Cranky about OS X

So I needed a laptop for work, and, perhaps against my better judgment, I decided to go with a Macbook Pro. I’ve had mixed experiences with PC laptops, where I think build quality varies wildly and it’s hard to consistently get a good piece of hardware (though I am somewhat curious about the Dell XPS ultrabook line, though unenthusiastic about its weak keyboard).

Along with this is that I’ve always liked the fact that OS X is built on top of Unix; not a variety of Unix I know well, to be frank, but still. What do a few cosmetic changes matter compared to a shared POSIX heritage?

Welp. I am now regretting my decision, and to a not inconsiderable degree. Where to begin? The lack of a decent package manager? The fact that in El Capitan Apple has made the Disk Utility completely worthless for partitioning? The fact that it’s impossible to write an .iso to a flash drive without mucking around with the dd command?

My naive belief was that OS X is an operating system that hides some of the complexity of its internals from the end user, but that makes up for that with a polished user experience; my hope was that, beneath the hood, OS X still had a lot of good functional tools for the power user. I’m finding myself somewhat disappointed in the first respect, and deeply frustrated in the latter. The iOS-ification of OS X is much, much worse than I thought, and has really made me miss a lot of the functionality of Linux. Hell, I’d settle, in some respects, for the advances that Windows has made in 7 and 10.


DuBois, MySQL Cookbook, 3rd ed. (O’Reilly, 2014)

MySQL (and SQL more generally) is a funny beast; or maybe it’s more like a familiar (but still odd) country. You can get around on the subway and get your bearings on the street, but you go to the post office or try to do something at the bank and realize that you’re still not thoroughly acclimated to the country. I’ve felt that way about MySQL from time to time– I have a sense of how to write basic queries, but there are parts of MySQL I don’t visit because I don’t have any idea they’re there; and there are things about MySQL that still seem a bit odd. The new, third edition of DuBois’s MySQL Cookbook is a rich handbook for MySQL, a Baedeker for those occasions when you need to venture out into the MySQL countryside.

There are many, many helpful recipes in this book, to the extent that picking particular ones out for praise becomes difficult. The discussion of working with strings and character set collations is quite nice, and shows how to do a fair amount within MySQL; Chapter 9 (on stored routines and triggers) is great; and the discussion of joins in Chapter 14 was one of the best I’ve read. I’ve felt at times that my ability to work with MySQL has been hampered by an imperfect sense of its possibilities; and browsing the Cookbook demystifies and demonstrates how to do useful things in MySQL.

However, one weakness of the book is that it tells you how to do lots of things in MySQL (and often covers the range of ways to do things in MySQL) without giving a sense of whether it makes sense to do it in MySQL at all as opposed to a proper programming language. For example, the book discusses regular expressions within SQL, but leaves for the end the important point that SQL regular expressions do not work with multibyte character sets (UTF-8, most crucially).  Similarly, some of the non-MySQL code in the book seems old-fashioned; chapters 18-21 include some Ruby and Python code, but lean very heavily on Perl. To return to the travel metaphor, it’s like a travel guide that is very solid on its main subject, but much less reliable about the towns across the border. On the other hand, though, the book is quite good at telling you what is MySQL-dependent, and what is portable across SQL and database implementations. As this qualification suggests, this caveat only reduces the usefulness of the book slightly, though; as a guide to using MySQL, the book is both thorough and impressive.

Fluent Conference 2013: JavaScript & Beyond Complete Video Compilation (O’Reilly)

I want to begin this review by emphasizing that I am not primarily a Javascript person, though it’s hard to do web stuff and not need to do Javascript now and again. I also want to point out that, as other reviewers have noted as well, I have not had time to watch all of these videos, and further exploration will likely uncover more useful material from this conference.

That said, I found the videos from this conference only somewhat useful for viewers, like me, who only work with Javascript in passing. Some of the topics– such as the extended tutorial on AngularJS– will probably seldom be of use to the casual JS user (though I thought this presentation was very well done). Other topics were more immediately relevant– such as Manor’s presentation on improving your jQuery, but Manor’s occasionally nervous manner distracted from the content of his presentation to some extent. Not all of the presenters of this conference were equally confident as public speakers; this might not be a problem in the moment, but might make the collection somewhat less useful as a point of reference.

I wonder, too, whether the value of such a video collection is diminished by the passing of time. Brendan Eich has given a more recent talk on the state of Javascript in the interim, and it’s unclear whether Content Security Policy, the subject of Ben Vinegar’s talk and a method of preventing XSS by restricting the domain of origin of a script, is still a live subject in 2014– much of the activity on the subject seems to have petered out in 2013, after a lot of activity in 2011 and 2012.

The advantage of such a conference (and such a video collection) is that it can give you insight into the way things work in the wild, in production environments, and in the leading companies in the world– insight into the way that leading figures in the field are currently thinking about a subject. This thinking can take a while to be codified in books and other instructional materials. As a casual JS user, I hesitate to say that I found the snapshot of the Javascript world from this 2013 conference to be essential viewing, but other viewers may get more from it.

Then again, one of the perks of attending a conference– and even watching the videos online– is serendipity: as an afterthought you attend a talk that turns out to be quite useful. I found many of the non-JS talks to be rather good. McKesson and and Wilson’s brief talk on “responsive publishing” and the O’Reilly Atlas project– the interface of books, ebooks, and web publishing– was actually really fascinating; Kalin’s talk on licensing was too brief, but interesting and informative; and Verou’s discussion of web standards was illuminating.  Similarly, Bootstrap isn’t something that’s been on my radar, but I was glad to have an extended introduction in Jen Kramer’s tutorial.

Learning PHP, MySQL, JavaScript, CSS, & HTML5, by Robin Nixon (3rd ed., O’Reilly, 2014)

If you work around your house or mess with electronics, you come to have a sentimental attachment to your toolbox (or at least I do). You and your toolbox have seen a lot together. More than this, there’s a practicality to your toolbox: in a small space, you have a lot of what you need to handle a variety of situations. Robin Nixon’s Learning PHP, MySQL, JavaScript, CSS, & HTML5 is the web programming equivalent of a well-stocked toolbox. It’s not going to have what you need for all possible situations as a web programmer, but it packs a lot of utility into a compact space.

The core of the book is Nixon’s concise coverage of the basics of PHP, MySQL, and JavaScript. The book then delves into each of these topics in a further chapter or two– giving some further ways to use PHP, or tips on working with MySQL databases. Along the way, Nixon covers many of the most common ways readers are likely to want to use these tools: working with forms, cookies, sessions, and authentication, for example. For such a comprehensive book, it does an admirable job of thoroughly explaining topics (such as AJAX) that other books often skim over with a few code snippets. The coverage of topics as substantial as these in a single book enforces brevity, and might suggest that topics get less coverage than they merit. It is to Nixon’s great credit, I think, that there are far fewer gaps than one might expect. The only really egregious one, to my mind, is that jQuery only merits a brief mention (on p. 420).

The second major part of the book moves from the web programming side of things to consider CSS and HTML5. Aspiring web designers should be aware that– despite the book’s occasional claims to be for those who want to learn how to “style and lay out” web pages (p. xxii)– this is not the book from which to learn the nuances of web design with CSS and HTML5. The book does not cover the new semantic elements in HTML5 (though an explanation for this is given on p. 601), nor does it cover all of web design’s intricacies (divs, spans, floats). The book’s chapters on CSS could serve as a helpful primer or refresher for the web programmer who needs to do some light web design work, though. The coverage of CSS3 and HTML5 is good; Nixon discusses many of the ways that HTML5 and CSS3 are changing (and often simplifying) the way to do things on the web, from streamlining layout and display to displaying audio and video, while still explaining how to support older browsers.

This may not be the final word on web programming– given how much things are in transition at the moment, it is hard to know how any single book could be– but as an introduction and a practical set of tools, this book is nevertheless recommended.

Scientific-Atlanta Explorer 8300

I was interested in fucking around with/voiding the warranty on my new Scientific-Atlanta Explorer 8300– I’d be most interested in figuring out a way to mod the UI, which is pretty profoundly shitty. I checked out the stuff Scientific-Atlanta has on its website, but that was rather unhelpful (it’s mainly about deployment and distribution).

what we have dreamed of, sleeping and waking

“For too long typographic style and its accompanying attention to detail have been overlooked by website designers, particularly in body copy. In years gone by this could have been put down to the technology, but now the web has caught up.”

Finally someone is working on adapting Bringhurst to the web. It’s just getting started, but it looks like it’s for real. Check it out here (

the h-word

I just got back from Notacon in Cleveland this weekend, and it has me thinking about the word ‘hacker’ quite a bit. (I’d like to claim the title for myself, but I don’t really think that I have the technical acumen– though I try)

I’ve been reading the third edition of O’Reilly’s ‘Practical Unix & Internet Security’, and I was pissed off by how glibly they dismiss the term hacker. Their gloss: “Today the confusion over the term hacker has largely been resolved. While some computer professionals continue to call themselves hackers, most don’t. In the mind of the public, the word hacker has been firmly defined as a person exceptionally talented with computers who often misuses that skill. Use of the term by members of the news media, law enforcement, and the entertainment industry has only served to reinforce this definition.” (Introduction to Chapter 1)

This is far too glib, and far too dismissive, I think. Despite the common, non-technical use of the word, hacker is a useful term, and meaningfully describes a set of people (especially the group of people who describe themselves as hackers).

On the other hand, the definition in the Jargon File and elsewhere (within the culture) is overly rosy. (At some level, I think the definition in the Jargon File is more prescriptive than descriptive– it doesn’t accurately capture the grammar of the word. This may be intentional, or it may just be that the sense of the word has evolved). This definition is just too general, as well.

Coming up with an accurate definition of the h-word isn’t easy. But I think you can describe what makes the hacker community different, and special.

Hacker culture is, above all, inclusive, bounded by angsty high school kids on one side, and white hat infosec professionals on the other. As a very general characterization, I think most hackers tend to be libertarian idealists (if that isn’t redundant) or anarchists in their twenties or thirties.

I think it’s fair to say that hackers define themselves to some extent by contrast with the great mass of IT professionals. One type of IT professionals is money-minded, bordering on venal, and I think it’s fair to say that most of these people work for big business maintaining SQL Server or some other shitty software. (I suspect that much of the anti-hacker antipathy comes from this quarter) Furthermore, there are many principled coders working in industry; here we run up against the distinction between open source people and hackers.

Most venal IT people do it because they figured out that they can make money doing it; hackers and open source people do it out of love. I think the difference between the open source segment and hackers is one of priorities: open source people worked on projects on their own time in college, but many of their projects languish once they hit the world of work. Open source people are at pains (and good enough) to cherry pick work that they approve of at a moral level. Hackers, by contrast, work to pay the bills while they work on their own projects.

These distinctions also have ramifications for OS choice. Hackers are (almost exclusively) Linux people, as are many open source folk. Venal IT people are frequently dismissive of Linux (fuckers), though this may change with IBM and big business’ embrace of Linux. My impression is that open source people respect OS X and use it, whereas hackers are less inclined to use it. This may also be a function of money.

Hackers are frequently interested in (or at least conversant in) security, and problems of security have important ramifications for the hacker ethos. Hackers run up against many of the problems encountered by scrupulous serious-minded people in other technical fields, but security has ethical ramifications that hackers, by and large, choose to ignore.

A contrast is furnished by Eric Meyer’s talk at Notacon. The proper implementation of CSS and responsible security implementation have run up against institutional and commercial barriers. Meyer talked about how impartial public shaming proved to be a fairly effective way of getting companies to do a better job of implementing CSS. At some level, this is what 2600 and others attempt to do, but they ignore the ethical problems of such an approach.

Hackers have a unique problem. It seems irresponsible not to tell companies about their security holes, but direct reporting of problems is seldom practicable. Nobody wants to hear that the security set-up they rolled (or worse, paid for) is complete bullshit, for one, and implementation runs up against problems of organizational hierarchy, even if the tech people would like to fix their problems.

On the other hand, it seems irresponsible for 2600 to swing wide the door to security exploits by publishing sensitive information. Such public shaming could provide the impetus for a company to set its house in order, but implementation takes time and energy. The 2600/hacker way of doing things is either irresponsible or naive.

At the same time, though, industry has been seriously derelict in selling companies snake oil ’security solutions’, and not educating the public more about security.

The problem is made even more vexing by the success of the internet, I think. It was different when the internet was a glorified research experiment, and not a driving force of commerce. Exposing flaws in an academic setting is completely different than threatening someone’s livelihood.

It would be different if enforcement and legislation were able to keep pace with technical innovation, or be somewhat more forward-thinking. (This might improve if less energy was expended on RIAA/MPAA bullshit) As it is now, the laws that get made are really shitty (anyone remember the DMCA?) and the people who get busted are either immature or undeserving of prosecution. Maybe this will change in the future, but it will be a long time coming. This all leaves hackers in something of a quandary.

Whatever the solution, acting naive isn’t helping anything. Hopefully the culture will evolve and become less simplistic as people in the culture get older– hopefully without losing the inclusiveness towards angsty high school kids.