heads

What I realized after 25 years is that configuration comes in three parts:

1/ the defaults, either built in or read from /etc;

2/ my defaults, included in each file (or with ssh, at the bottom) with that particular config’s native version of #include; and

3/ local specifics that are rarely if ever used anywhere else, or trivially short as to be copy-paste-able.

Almost everything I want to customize goes into (2) so I wrote a single Python function that manages a block at the top (or with ssh, at the bottom) of each config file:

  # BEGIN my foo stuff
  include = /my/repo/foo/config
  # END my foo stuff

That way foo starts out with (1) the system defaults; then adds (2) my personal foo defaults as defined in a working copy at /my/repo; (3) anything else I insert in the file after that which isn’t centrally managed and that’s ok.

I haven’t ever needed anything more complicated. I do not have any work specific configs that I need to gate. I no longer have to manage different configs based on whether I am using Debian, Debian (old), Debian (very old), SunOS (very very old), or AIX (very very very old) because those days are behind me.

If you do still need to manage slightly different but ethereally different configs on different hosts then I’m sorry to hear that. Rationalising my computing life so that I use the latest version of some Linux distribution everywhere has been very helpful!

North America has lots of land and oil. Timber (Canada), plastics, and corn fertilised by nitrates that were made using fossil fuel energy. Corn probably doesn’t ship in containers but corn-fed beef and poultry do?

In the sense that violence is coercion they have a lot of purely electronic means of persuasion:

  update account
  set balance = 0
  where user = ‘steve1977’;

We used to have an ecosystem like this. In our case it reflected an entrenched set of divisions between warring teams. In some ways it may have then enhanced those positions and we still bear a few of the scars today.

A lot of the old guard have left the company though and our main product moved from four repos to just one. The threat from the legal team to have enforced OWNERS files — essentially replicating the divisive politics of the old repos but in the monorepo — thankfully withered on the vine. We still audit what goes into each release but it’s no longer part of any active permissions thing. We trust our developers but verify, for legal reasons, that nothing went wrong.

You either want one engineering team to act in unison behind your company’s mission, or you want to live a divisive narrative that you are actually multiple teams “working” together with none of the advantages of living under one roof and all the disadvantages of hard repository boundaries crisscrossing your intellectual property.

So many factors threaten to curdle your team dynamic: multiple offices, multiple floors, work from home hermits, bad management, etc. It’s simply org entropy and it takes much effort to keep the weeds out of the garden. Multiple repositories is one less bullet you can keep out of your feet while fighting all the other battles that threaten to turn your team from 1990s Sun Microsystems into 2010 Sun Microsystems.

Put wings on it and go up sideways. It solves the thrust/weight issue the same way a hill climber does: instead of going directly up they zig zag.

You need the lateral velocity anyway, for orbit.

And at the command line: headers to stderr, body to stdout.

Without it you get this behavior:

  > heights | sort -k2 -nr
  George  186
  Wally   173
  NAME    HEIGHT

But if the headers bypass stdout then you get this instead:

  > heights | sort -k2 -nr
  NAME    HEIGHT
  George  186
  Wally   173

I’m sure this is real but just for fun I’m entertaining the idea that someone is trolling — either with a fun dialog title or the app name.

I worked at a company in the late 2000s that moved to an office with automatic urinals. These were fairly novel at the time and had a matte black plastic unit with a flush handle that also had a shiny window made of dark, IR transparent plastic. It was clearly some kind of proximity sensor for the autoflush but some joker made an official “do not touch the cameras” sign that wound a few people up.

Parliament is all the players from all 12 teams including all those on the bench who never even played.

Government is the members of the winning team who were on the field when the whistle blew. They get to lift the trophy.

In real competitions the subs get to lift the trophy too so maybe a better analogy is that the UK Parliament is 12 teams, all their subs, the coaching staff, club management, and the people who run the official fan club. A subset of these from the winning club get to lift the “I am the government now” trophy but not all of them do.

Oh, and of course while the Commons are playing [association] football, the Lords are playing charity match celebrity cricket, and yet some of them (e.g David Lord Cameron) get their hands on the FA Cup too.

In the US, by contrast, it’s more like the guy who owns the team is the one who lifts the trophy. They do so by winning a “whose team do you like the most?” competition, all while a separate match with actual players is going on, none of whom will win the executive trophy.

There are also only two official USA Sports League teams but they split into cliques that play together behind the scenes. Kind of like the midfield caucus doing a deal with the forward caucus to give them the ball in exchange for extra oranges at half time.

What a fun read! Your “how to get shot in the airport” caption nearly made me spit out my coffee.

I feel like there are metric lurking in here somewhere. Something to do with the following concepts:

(1) the number of documented atomic changes to the codebase, be these merges or pull-requests or changesets or patches — the thing with a title and description that was code reviewed;

(2) the number of tasks in your task management system that might be bugs or feature requests — these are large and must be implemented in pieces, with testing and reviewing of assumptions along the way; and

(3) the time period on which you are required to be held accountable for actually finishing stuff.

I do maybe 30 commits for a big task and will spend six weeks on it. There might be small bugs along the way that get closed out with a 1:1 mapping between task and commit. The majority of the work is a giant slowly but surely moving set of iterations towards a top level goal. The cadence is to review on a quarterly basis.

Not so in the past though. I’ve had to do one commit per task. Multiple tasks in a big bushy tree of verbiage that overlaps too much with the actual commits (the meaningful bits!) and all done on two week cycles. It felt exhausting and piecemeal, as if software engineers were a fungible resource there to further marketing goals instead of innovate the next big things. Nowadays I demand to work for a true technology company, not a marketing company that sells tech.

So negative! Where I work this tool is called “new-hires”. It uses a restricted read-only API key to our third-party people tool. It was given to me by our People Director. Sometimes there are lines beginning with - but the tool is named for the lines beginning with +.

new-hires is built on top of the “people” python module / cli in our monorepo. That tool is so much more useful than just a way of diffing the org chart. Who is in what team, where are they, are they working today, is it time to celebrate their anniversary, etc. It also follows what I coin the “ZFS litmus test” for good CLI tools by providing -pH for parseable, headerless output.

Treasure such places indeed.