Skip to content

On the subject of Patriotism

Politics

A big deal is being made about NFL players taking a knee during the national anthem in protest of racial injustice (like the fact that a black guy is more than twice as likely to be shot by a cop than by anyone else in our society).

I think you all know where I stand on this, and I've spoken extensively about it on Twitter. What I am going to address here is the issue of patriotism - specifically the expected public displays of patriotism in our culture. Read on if you dare.

Continue reading "On the subject of Patriotism"

A developer, a sysadmin, and a DBA walk into a conference room…

Programming

…and that's not a joke, it's how your design meetings should be starting.

A few days ago on Twitter someone asked a seemingly innocent question: "I'm writing a post on the failure of Stored Procedures as a platform.  What, in your view, were the reasons they didn't work out?"

A lot of reasons were given: "They're hard to test" (They're not - your unit tests should be testing your database.),  "They're not in git" (They should be - If they arent your revision control process is fucked because your database isn't controlled), "They're fundamentally unreadable and require exponentially more tacit knowledge aka are awful for new devs to understand" (They're not "fundamentally" anything, and if they're documented well any competent developer should be able to understand them), "They encourage silos where DBAs say no." (This is a people problem: Your process doesn't facilitate understanding between your DBAs and the rest of your team).
Some folks even came up with what I would argue are good reasons, like "Badly written stored procedures don't scale well" (which is true: If your stored procedures involve lots of processing overhead the DB server becomes a processing bottleneck, which is a Bad Thing), and "It's an additional moving part in the system" (generally something to avoid, unless that moving part is the simplest solution to a problem).

I was all set to have a friendly difference of opinion on this issue until I saw this blog post, which starts out great and quickly goes off the rails into the weeds and starts eating slugs with the DevOps "we don't need no stinkin' sysadmin/DBA" children.

So now you get a rant about why you still need a Developer, a Sysadmin, and a DBA.

Continue reading "A developer, a sysadmin, and a DBA walk into a conference room…"

A new server, and a few more words about LetsEncrypt.

UNIX

Back in April some jackass promised that there would be a follow-up post about migrating bsd-box.net to use the LetsEncrypt CA.
Oh right, that was me.

As usual life interfered, but here's the followup: The bsd-box.net server has been replaced with a shiny new machine, LetsEncrypt is still my CA of choice for this system, and a bunch of other things have changed. More below the jump.

Continue reading "A new server, and a few more words about LetsEncrypt."

A few words about Lets Encrypt

UNIX

Most if not all readers of my blog are probably aware of the Lets Encrypt project, which officially exited Beta this month.  
For those of you not familiar with it, the basic premise is "It's the goddamn 21st century, and there is no reason every website shouldn't be available over HTTPS. We're giving away certificates for free, and giving you an automated tool to acquire and renew them. You have no more excuses!"

Most of you also know I was originally quite skeptical of this project: I'm not a huge fan of trusting third-party programs with my cryptography, and I like to ensure that I'm maintaining control of the impotant bits (like private keys) at all times. The final implementation however appears to be well-designed and reasonably secure, enough so that I have used it for this year's certificate renewal on bsd-box.net.
What follows is a brief description of the Lets Encrypt process on FreeBSD: Its successes, its failures, and some thiings I may be submitting patches for in the near future.

Continue reading "A few words about Lets Encrypt"

The Problem of the 9-to-5 Sysadmin

UNIX

Tom Limoncelli (yes, that Tom) recently wrote a blog post that came to my attention by way of Twitter in which he lamented his bank's scheduled downtime and the implications of routine "weekend work" in terms of an organization's respect for the time and work-life balance of its sysadmin staff.

This was posted the "Rants" section of his blog and is obvisouly ment to be taken as slightly tongue-in-cheek alongside the idea that every sysadmin in geekdom's creation would really rather be watching the Star Wars movie, but it's broadly representative of an attitude I've seen emerging more and more in our profession: That sysadmin work should be viewed as a 9-to-5 gig. I in turn ranted a little bit about that on Twitter, but I think it merits following up with a longer form discussion, so let's have a blog post before the end of the year!

Continue reading "The Problem of the 9-to-5 Sysadmin"