indirection is great! one of the best things you can do to look smart is recommend pulling out some shared code and make both sides point at that, this is how i pass job interviews and contribute to meetings i haven’t been paying attention to.

it makes the code more complex, but for a good reason.

if you have a program b that consumes data from program a, that is simple:

(data in -> program a -> data out) -> (data in -> program b -> data out

that is great. but later, you learn there is going to be a new program c that consumes data from program a. it might be a swell idea to pull out code that is used in both places into a sharedlib, once you notice they are always changing together.

now you have something more complex! data goes into program a, program a maybe talks to sharedlib before sending it on to program b and program c who both talk to sharedlib. indirection! it takes a little longer to track down where data is being transformed, but you get a benefit in that you can make a change to sharedlib and it will be picked up by the programs without having to make a change to all three.

the idea is to make code that changes together live together.

similarly if you have a bunch of code in repo a and a bunch of code in repo b that requires a PR in both places any time there is a change then it might be good idea to pull code from repo a and repo b into repo shared too. code that changes together, lives together. if you find over time that it’s requiring a change to repo a and repo b and repo shared any time you make a change, then maybe you’ll want to put all of those in one repo.

however: don’t pull things out into shared libraries simply because you believe they may one day be used by other things, wait until you actually need them, wait until you can see it will reduce churn or duplication to separate it. never introduce indirection simply because you believe it may one day reduce duplication. DO REPEAT YOURSELF, until you can see the patterns. do not introduce configuration, shared code, environment variables, overloaded functions, dynamic dispatch, delegation, …, until you can see that it will make the codebase better.

do not use any indirection at all until it is needed. constantly watch your repos, if there are a lot of examples of two (or more) repos requiring synchronized PRs then either make it one repo or pull the shared concept into a new package that both of the others depend on.

looking at the code for my old lisp implementation of chicken egg hole, vs the 32blit-sdk c++ version. the lisp version is so much nicer. maybe i can make them more similar by using structs and functions instead of classes in the c++ version.

#computer

did that thing today where i blow away my whole linux partition and start again

it’s some kind of extreme sport; recreational crisis zone

i tried qubesos, it was unusable on my laptop. now i’ve installed manjaro. manjaro is remarkably good. btrfs, encrypted boot. it was almost effortless to get to a system that would normally take me an hour or two on vanilla arch.

i’d like some vanilla ice cream, but they would saw my feet off.

 

 

imagine you have a raspberry pi running arch linux arm, and you want to use the python library RPi.GPIO.

that requires a /dev/gpiomem device, which is a hacky /dev/mem derivative that allows you to access the gpio pins without being root. which is important if you want to also be able to access a normal user’s dbus session, or anything else where you’d like to not be root while running the python.

arch linux arm uses raspberrypi’s kernel fork, but doesn’t set up the gpiomem device the way it’s needed for RPi.GPIO to work.

Add a gpio user

as root, create a gpio user

groupadd gpio
usermod -aG gpio alarm # alarm is the name of the default archlinuxarm user

setup udev

Make a file called /etc/udev/rules.d/pins.rules and put this in it:

SUBSYSTEM=="bcm2835-gpiomem", KERNEL=="gpiomem", GROUP="gpio", MODE="0660"
SUBSYSTEM=="gpio", KERNEL=="gpiochip*", ACTION=="add", PROGRAM="/bin/sh -c 'chown root:gpio /sys/class/gpio/export /sys/class/gpio/unexport ; chmod 220 /sys/class/gpio/export /sys/class/gpio/unexport'"
SUBSYSTEM=="gpio", KERNEL=="gpio*", ACTION=="add", PROGRAM="/bin/sh -c 'chown root:gpio /sys%p/active_low /sys%p/direction /sys%p/edge /sys%p/value ; chmod 660 /sys%p/active_low /sys%p/direction /sys%p/edge /sys%p/value'"

you may also wish to append this line, if you’re going to need spi access too:

SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"

reboot

reboot, run the python, no root,