heads
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!
update account
set balance = 0
where user = ‘steve1977’;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.
You need the lateral velocity anyway, for orbit.
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 173I 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.
Regular lets-call-grandma telecommunications would be handled by your well know, friendly, cuddly round towers like Telecom Tower and Stokenchurch just next to the Chiltern cutting on the M40.
Sinister everyone-has-died communications would be handled by the mysterious, dangerous looking towers like Highgate and Kelvedon Hatch. These towers resemble high tension power lines and growl at you if you look at them for too long.
This site has a lot more detail on how the two ended up as one, over the years:
https://www.subbrit.org.uk/features/backbone-microwave-relay...
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.
(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.
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.
My understanding of the article and the plot is that the authors modelled how the moon ought to wobble if it has an ocean versus it does not have an ocean, and if it did then how does it wobble with either a thick crust or thin crust on top. The actual, observed wobbling is in the “has an ocean” part of the plot therefore, assuming the model is correct and there isn’t some other cause of wobble, it probably has an ocean. This is the only evidence so far though — other than this data there is “no hint of an ocean underneath”.
It would also wobble if it had a moon-mouse dance party at each pole. Modelling for different sized discos and different tempo dance music, we see that the observed wobbling is consistent with 4 billion mouse / 185bpm portion of the plot.
I could also plot the hypothesised size of the kraken mouth which swallows ships as they vanish over the Earth’s horizon. The plot shows the rates at which the ship sinks from view based on kraken mouth size. The observed sink rate is consistent with a 12m wide kraken mouth which is a cool result except that ships sink over the horizon because the Earth is round. There are no krakens!
My nephew is Californian and I gave him one for his sixth birthday. Mine felt a bit lighter so we did an experiment over Zoom together to measure the density. He’s certainly a bit young for that — “it’s the same size but yours is heavier” — but there’s no harm in influencing them from an early age.
Of relevance to your comment: I made a point of doing it in grams and millimetres.
Apparently bullets are about an order of magnitude more energetic than baseballs (800J vs 80J) so I guess I could try to build my intuition based on being shot ~2 billion times a second instead. A kiloton of TNT is 4GJ, so it’s also like a 500 kiloton bomb going off every second.
Dropping 5e5kg of rock into the worlds biggest dumpster truck at 10m/s yields 25MJ of chaos so it’s also like a parking lot of 80,000 of those being filled with a continuous stream of rubble. That’s probably the best analogy given that we’re talking about machinery — your spaceship needs to have the build resilience of tens of thousands of dumpster trucks but condensed into the cross sectional area of a dinner table.
As one of the authors working in a 2000+ module Python codebase, nothing gives me greater pleasure than to drive one part of the codebase by creating another module. Nothing gives me greater sadness than to be forced to interact with something through a YAML config file, command line flags, or launching GitLab pipelines. All three of those boundaries interrupt the powerful electromagnetic force fields that pervade the system: type checking, linting, and symbol finding (IDE integration). In time, I vow to destroy every last one of these non-code boundaries. Another unwanted-boundary demon on the exorcism list is polyrepos.
There once was a time when the world worked like this but instead of Python it was C. It wasn’t as rich as the dynamic world we have today — I’m certain I don’t want to go back to configuring my softest by recompiling it — but it did have a lot of the advantages of working in one language environment across all the things.
Git was designed with the distributed viewpoint. A commit message, as written by the author, is necessarily correct: I’ve decided this is right, and it’s on you to decide if you want to merge it into your history too.
In our current systems we usually have a URL in the commit message that links to the actual story behind the commit — the discussion on the pull request, merge request, or code review. I rarely see the results of these discussions being amended into the commit message. If the repo lives forever but the database behind the code review tool gets toasted then something just as important is lost forever.
(I come from a background of one idea equals one amended, fast forwarded commit to master. It’s possible other people rely on branch history to reflect the evolution of ideas and how they go from a request for review to approved code. In my experience branch histories tend to have very low quality commit messages and even then they only show one side of the conversation — the author’s responses to their reviewer’s and their own critiques.)
An argument on Harvard’s side is that, in the grander scheme of things, they are part of a process that generates phenomenal tax revenue. The state takes their 40% cut off the top of every $150k CS and IB graduate salary after all. Is that a good enough benefit to let us tolerate Harvard’s pile of gold?
There is a related argument that if society is to be the ultimate recipient of the majority of benefits of a university system, then it should probably be state funded. Just like roads (public) trains (ish) electricity (not any more) and food (private but subsidised).
On the other hand I would accept the government’s position if it were to say aloud that there goal is for all large pools of money to be reclaimed by society. Double taxing wealth is then ok because it will, eventually, redistribute the wealth. In such a moral code, a $51bn pile of gold is quite an aberration.
It is classic right versus left: natural hierarchy versus we’re all the same.
(Should we add oxford_comma as a config option?)
Have you ever seen them live, though an image intensifier / night vision system? I feel there would be something profound about seeing a galaxy with my own (albeit enhanced) eyes.
Imagine instead if you and (the majority of) your colleagues came to work by cycling for 20 minutes through green pastures, parks, under willow trees along the river, and through the centre of one of the most famous historic towns in England. That’s what we do here in Cambridge.
We also do not operate a cubicle farm. Our office is spacious, filled with breakout spaces, relaxation spots, a library (aka quiet room), VC equipped rooms of all sizes, with a mini- and a maxi-kitchen and free snacks and meals.
We come and go as we please with two days a week all together and frequently other in-office days for sub teams too, agreed by consensus not fiat. I often work at home in the morning or go home after lunch for the afternoon if I need uninterrupted focus / maker time. We have a personal IT budget for our home offices so I don’t need to cycle with my laptop (which btw is an Ubuntu Dell XPS, because our IT team know what they’re doing — you can have a MacBook if you insist.) Cambridge has gigabit fibre which is handy when pushing and pulling models from the A100 machines in our remote data centre.
We still allow people to be as remote as they want and we also have a satellite office in London. It is rare though for the core eng team to not see each other in person for more than five days on the trot. It’s just so much more productive to build and plan stuff in person around a whiteboard, with pair programming, or in a war room.
if (boat)
… # All good
else:
raise TravellerAlert()