I’ve got a bit of a problem in that I spend most of my career working in engineering space, but most of my thought capital is spent on larger problems of organizational design, technical strategy, laying down foundations today for problems we’re going to need to solve in a year or more. This frustrates my bosses to no end, who just want me to build a server or swap a bad hard drive out or any other of a number of mundane day to day sysadmin tasks. I’m left without much of an outlet for this stuff besides meetup groups and, when I find the time, blogging. Thanks for humoring me.
One of my frequent frustrations is we tend to carry too much legacy around in how we work, in how we organize. We do things all wrong because, well, that’s how we’ve always done it. But I’m thinking farther out, and I see many operations teams on a collision course with the hard limits of the human brain. To wit: the hierarchical limitations of Dunbar’s number and the human neocortex.
I’m a big fan of the Tor Project. It’s really encouraging to see more people using it, and more people setting up bridges, relays, and exit nodes.
What I’d like to see more of is publicly available networks that transparently redirect clients’ Internet connectivity through Tor. My first step here is going to be aimed more at someone with the means by which to set up many wireless access points on a campus, like perhaps an office building or a University. In these environments, it is typical for wireless networks to be created on different VLANs, with multiple SSID’s advertised, and each SSID being linked to a different VLAN. Often you might have a staff SSID and a guest SSID.
But because the host is concerned about bad behavior or misuse of the guest network coming back to haunt them, access is extremely locked down. Perhaps they only allow simple web browsing and nothing more. And access is not granted without knowing a guest network password, or having to go through a captive portal.
Up until a couple of years ago, I was becoming increasingly active in the illumos community. I’d given a talk on the subject at Triangle DevOps, and indeed my most popular entries on this blog tend to be the ones relating to SmartOS. But something happend in my professional career, a conflict of interests, that compelled me to pull back from that community for awhile. The conflict is now gone, and hot on the heels of illumos Day 2014, my interest is re-invigorated. (more…)
The other day, I posted some thoughts capturing a conversation that happened in the illumos community over the weekend. If you missed it, head over first to The illumos Number That Bothers Me.
The conversation can’t die there. We’ve got to take pro-active steps to better understand how we got into this gender monoculture in the first place, and be catalysts to the change we wish to see in our community. I’ve been looking around a bit since then and found a few resources that should hopefully help to get the ball rolling. (more…)
I just got back late last night from Surge 2014 and illumos Day, which immediately followed Surge the next day. There were some great talks going on, which I’m sure I’ll also be writing about. But the first speaker in particular dropped something on me that’s bothering me, and it should bother pretty much anyone that hears it.
Garrett D’Amore, founder of the illumos project, crawled through all of the commits and made a really interesting discovery. This is a four year old project, and remains relatively obscure (though some very visible things have come out of it, like zfs). In those four years, about 150 unique contributors have committed code into illumos-gate, the shared core of the illumos ecosystem that distributions are built on. Now on the surface, this number sounds pretty wicked cool. illumos is a fairly unknown project, sadly, so to score commits from 150 engineers sounds like a really good thing. Or is it?
Of those 150 unique commiters, 0 of them were women.
I had the pleasure of addressing the Triangle DevOps meetup group on the subject of DevOps: Year One. The target audience was anyone who has bought into the idea of DevOps transformation for their business, but wanted practical advice for how to get started.
With only an hour to speak, and so many great questions to answer, we barely got to scratch the surface. But we did get to talk about some specific practices that have helped the Systems Engineering team at Bronto to work much more effectively.
I admit, I cringe when people say things like this. It normally says to me “I haven’t put much thought into my process or my workflow, but we’ve got a board with some columns on it and the work goes there.”
In its simplest form, a Kanban gives you tools for two things:
visualizing your workflow
setting limits on each step (column limits) to maximize the completed units of work vs. the appearance of being busy