Mat Hill

← to home

I personally enjoy discovering new things by hearing how people work.
However, it's important to remember that practices are always changing. The personal route to a particular choice is often the more important part!
Nothing here is final, and I am always curious to hear about things I'm missing :)

# Can you help me with x?

Hopefully! Email me: mat(at)mat-hill(dot)xyz

# How can I learn x too?

I find it best to read documentation and seek out good textbooks. This can be tiring, but the trick is to put zero pressure on remembering or understanding anything - there's no exam!
Lazily scanning through every function in a library / scale in a musical style / brush type in an art catalogue etc. will go a looong way! You will be amazed at how much you recall when you get stuck.

For coders, I recommend learning some C (don't worry, it's small!) and doing an embedded software project (I highly recommend the Raspberry Pi Pico!). Much of modern programming practice is arguably a reaction to the decades spent doing similar tasks with low level languages and low-power hardware. Experiencing this really helps to contextualise things. I guarantee you won't look at your laptop / phone / washing machine the same way again :)

Some of my favourite and most rewarding tool choices have been in direct defiance of my prejudices. In fact, nowadays I actively recommend trying something utterly bizarre (like vim) on the off chance you fall in love (like I did, with vim).
Enjoying a tool is important. If you find that you do, use that energy to learn it inside-out!

Honestly, thinking about recommendations with hindsight is tricky. Much of what I have learned was motivated by aspirations that have long since changed.
If I met my past self... I doubt I could convince them to relax, ignore what's trendy, and do more aimless studying!

TL;DR: just focus on changing your perspective, you will gain confidence over time :)

For specific more suggestions, check out my links & books page.

I also have a fine art learning adventures page.

# What hardware do you use?

My main machine is a Framework laptop. I love it.
I used to buy relatively cheap gaming laptops, but I often found myself disabling the discrete GPUs to prevent excess heat and power consumption.
I hope to keep my Framework for as long as possible, perhaps upgrading to a RISC-V CPU years from now.

I have a Pinebook Pro. It's really nice to use. If I only did systems programming, I would probably make this my main laptop.

I use an ErgoDox EZ for typing. I like the keyboards on my laptops, but the EZ helps with my RSI. It also encouraged me to improve my touch-typing, and use a more code-friendly symbol layout. I bought the blank key caps and labelled them with marker pens.

I have a small Wacom Intuos tablet, which I use for digital modelling / painting. Blender is really powerful with a 3-button mouse, and my stylus has two thumb buttons which are great for RMB / MMB mapping.

My phone is a Fairphone 3 running iodéOS. I mainly use it for instant messaging, 2FA, or listening to music. I love what Fairphone are doing, but I hope to ditch Android someday for a more flexible mobile OS. The Pinephone Pro looks promising.

I love using Raspberry Pis for things. I have a Pi 3+ with a DAC board running Pianoteq. It can turn any midi keyboard into a great sounding piano!

For photos, I either use my phone, or an Olympus OM-10 35mm film camera.

For videos, I use an old Canon EOS M with a cheap CCTV camera lens, running Magic Lantern. I used to use a 550D (Rebel T2i in the US), but the EOS M offers similar quality and is much smaller and cheaper.

Oscilloscopes are wonderful. I primarily use one for making audio electronics, which has relatively low frequency requirements. Two channels is nice, but not required.
Make sure you understand how to not blow up your scope!

Most analogue audio projects require bipolar ±12v power! It's safest to set this up so that 0v is tied to earth ground, but this requires a dual output supply which can handle negative voltage. Moritz Klein has a tutorial on creating a simple synth power supply. This is great for powering finished projects, but a proper lab bench power supply provides desirable prototyping features, such as short-circuit protection.

I use the Hakko FX-888D soldering station. Soldering is deceptively difficult, especially without enough heat.

# What software do you use?

I have to use all sorts of applications & operating systems for my work... I like learning new things, but I rarely enjoy them beyond that!

Blender, Krita, Firefox, and KiCAD are generally the only GUI apps I keep installed. I love Houdini too though.

My personal laptop runs Ubuntu, as it stays out of my way more than Windows / macOS. I like to treat devices as being separate from my tasks & data, so anything with sensible defaults is great. I use the fish shell for this reason to.

Most of my personal stuff is done via command line interfaces, simple shell scripts, PGP encryption, and tabulated plain-text files. My growing collection of DIY tools has yet to fail me... although there were some nasty data losses while I was learning - backup your backups!

I use RSS feeds to keep up to date with blogs, youtube, tweets etc.

# How can i pay you?

If you are looking to pay me for client work but have lost my invoice, or would like to reimburse me for something, please email me.

If you want to support what I do, thanks :) I don't accept donations, but I would love it if you donated to Abortion Rights UK, Mermaids UK, or Gendered Intelligence.

# Aren't RSS feeds outdated?

Consider how much of our interaction with the web takes the form of a subscription.
Social media updates, email newsletters, podcasts, video releases - all commonly mediated through two-way connections: to receive, you provide an email address, username, etc.

The business reasons for this are obvious, but many users seem unaware that there are no technological reasons. Those of us with concerns around privacy, email spam, phishing attacks etc. would be better served by a one-way model, where subscriptions are anonymous.

...just like an RSS feed :)

# How do you digitally sign stuff?

If you are security-inclined, you may want to cryptographically verify that what you have received is what I intended to send.
I provide PGP signatures alongside any emails or software downloads, signed with my personal private key.

Of course, you have to trust that I myself am not making, signing, and sending you malware... (I won't I promise <3)

In reality, no security system is perfect. If my private key somehow got stolen, none of this would work.
This sounds scary, but it is probably the most secure option. Having a user account on a third-party service that supports encryption works the same way - they just look after your private key for you.
I have to put some extra effort into keeping my stuff and backed up and encrypted, but I'm a less valuable target than a major service provider with millions of users.

Apple have strict requirements for software sent between computers. Every aspect must be cryptographically 'codesigned', and the entire .dmg archive 'notarized'. I begrudgingly comply, but a frustrating consequence is that every macOS build I want to send to another person takes anywhere between under a minute to a few hours.

I do not put the same amount of effort into securing my Apple accounts and devices as I do my PGP key. Do not consider Apple's mechanisms an indication that my software is secure - please use the provided PGP signatures if you are concerned.

Education, openness, and good UX are better security solutions than mysterious black boxes that display cute icons of padlocks or ticks :)

# How do you handle pre-multiplied alpha, sRGB, etc?

There is a lot of confusion around these concepts, and many major software packages still handle them poorly.
That said, there are some great articles out there, which have helped me nail down a consistent process (see: mat-hill.xyz/links/#computing).

I do all colour processing in linearised-sRGB[0]. This requires converting any sRGB 8-bit data (hex colours, image files etc.) into linearised-sRGB 32-bit float values before processing.
For textures, I will do this as late as possible (i.e. in the shader that draws them), to take advantage of the relative size compression of 8-bit sRGB data.
After all processing I convert back to sRGB for display / export.

I treat all alpha as associated[1]. This requires that any un-associated[2] images have their colour channels multiplied, in linearised-sRGB, by the their alpha channel.
As many image formats assume alpha is un-associated, I have to divide[3] the colour channels by their alpha, in linearised-sRGB, before encoding

Although these requirements add complexity, they have solved many problems for me, with reasonable memory / processing trade-offs :)

[0] a.k.a. linear or un-gamma'd.
[1] a.k.a., pre-multiplied.
[2] a.k.a., straight or un-matted.
[3] a.k.a., un-multing, which confused me for years - it's just division!
# What are your thoughts on safe / secure code?

# What are your thoughts on safe / secure code?

Does my code correctly implement a correct system? A correct system, like a correct implementation, handles all possible edge cases via a predictable strategy[0].

In Puffins, any assumptions about the state of the system are expressed as assertions. Assertions crash upon failure, reporting the condition that failed, along with the their location in the source files.

Crashing may seem like something to avoid[1]. The reality is: if an assertion fails, the implementation and / or system is incorrect. Continuing would allow the system to explore un-predicted, potentially dangerous states. Even for my work in interactive installations, I prefer aggressive testing to catch and fix crashes. The alternative, despite my best efforts to write correct code, is clients reporting that things are behaving 'oddly', and little else to debug with.

For safety-critical software, NASA JPL, CERT C, and MISRA do not allow crashing assertions. Instead, they argue that such an error should be acknowledged and handled by the system, even when essentially fatal.
Puffins is not designed for such applications, so I avoid enforcing the complexity of having to check for errors after every function. Error checking semantics exist, but are reserved for the handling of un-trusted user input. Puffins assertions are for catching my mistakes, not the user's!

But none of the above strategies can guarantee predictable execution. Fundamentally, electrical circuits are always vulnerable to 'soft errors' such as bit flips. We must not assume that a computer system, even when implemented correctly, is 100% reliable. Safety-critical systems have learned this the hard way, and various methods have been devised to drive down the probability of failure[2].

The cultures that design systems, the implementations in code, the hardware that executes them - none are totally reliable! Engineering is always a compromise. Unfortunately, the sudden growth in leverage handed to software developers across the millennium, has largely stretched beyond our common sense, maturity, and technical competence. Check out some of the security entries on my links page if you would like to see what has informed my views.

[0] e.g: What does the system do when a cable tears, or if the user drags the application's window onto a different monitor? What does the implementation do when an integer overflows, or a pointer accesses a memory location that is no longer in meaningful use?
[1] I think this confusion arises because most modern devs work primarily on websites. The browser wants to prevent downloaded content from crashing it, no matter how ill-formed. An entire website's system and implementation is considered un-trusted input.
[2] All are fascinating: duplication of physical computers which compare results at critical steps, radiation shielding, error correction codes, to name a few...
↑ to top
← to home