sxa's Technical Musings

(Link to this article on twitter:  https://twitter.com/sxaTech/status/1628064140576059392 ) A while back I took delivery of a Mac Mini M1 system ("2020" model with 16Gb RAM running MacOS 11.6 "Big Sur" (It's now on 12.3). It came with no keyboard, mouse or screen (but I had plenty of them around, including a Unicomp Model M buckling spring keyboard with mac keycaps which I'd acquired a few months previously!) First problem was that the HDMI output didn't seem to want to talk to the 1600x1200 screen I had on my desk, so I switched it over to my 27" 1080p display ... So what's it like to use? I've used macOS systems as servers before but other than a small amount of GUI remote access I hadn't seriously used a desktop system before so I wanted to share "first timer" experience for some common use cases as a developer. Oh, and it's quick. Really quick. Whatever Apple have done in designing the M1 ("Apple Silicon") CP

This is a follow up to my GitHub primer post where I introduced how most of the git concepts. One of the things that catches a lot of people out when the first use git is the idea of rebasing. While you're working on the code base, other people can be working in their own forks, and things can get out of date and this can cause problems when you go to merge your changes back in. So how do you avoid getting into "rebase hell"? This is the stuff I wish I'd properly appreciated before I started, and includes the commands I use to get out of problems. I'm going to repeat the diagram from the previous post because I'm going to refer to some steps in it by number: I'm going to refer to the "main" branch here as it;s now the default that GitHub creates, but many repositories will still be using the old default of "master" used upstream development branch. If your project uses "master", or you're working from an alternate upstrea