iio.ie

techbunker: I wish small computer clubs existed

Mon, 06 Apr 2026 00:00:00 +0000

When I was a kid, I used to hang out at a cybercafe near my aunt's place. Places like this were later dubbed "internet cafes", but back then the internet wasn't really a thing. The machines were connected to each other and people played Quake II, Red Alert II, and typical LAN games like that. Lacking pocket money, I mostly just watched other people playing. It was quite fun. Such local play has a completely different vibe than online gaming.

Later I hung out at my high school's computer room. This was much better because I didn't need to pay to use the machines there. But the machines were older and not connected to a network. We mostly played local multiplayer games. Eventually we got more powerful, networked machines and then we could play shooters too. We had a blast!

These experiences died down during my university years even though the university had a much bigger computer lab. I don't fully remember why. We probably started having our own laptops, so we could play anywhere we wanted, and thus we didn't need the lab machines. Maybe we had rules against installing games too.

But at university I had another local activity: programming contests like ACM. Those were thrilling too: you tried hard to solve the problems and afterwards you hung around and discussed solutions. Even I could somewhat socialize there as a person who is otherwise incapable of even rudimentary social interactions.

This atmosphere is completely gone from my workplace nowadays. We can't even reinstate it. Everything has to be locked down, everything has to be secure, just because the internet has become such a crazily dangerous place.

These computer labs were like a third place for me. They are gone and I realized I quite miss them. So let me braindump what I wish existed.

## Description

I wish that bigger cities had a small, non-profit, offline computer club that anybody could join. Imagine a big room with about 12 machines mostly for playing simple video and coding games together.

I want this place to be an escape from the modern distracting world, a technology bunker. The machines are networked with each other; people can interact with each other within the room, but not with the outside internet. The room is a Faraday cage; the wifi modules on the machines are physically disabled. If people are there, I want them to be present, not chatting on their smartphones with outsiders.

The machines would be cheap Raspberry Pis with a monitor, keyboard, mouse, and two gamepads attached. They would run some niche OS like a BSD or similar, just to avoid mainstream stuff. The OS would be ephemeral so if you reboot a machine, you get back a pristine machine. Games, compilers, documentation, user data could be stored on a NAS that is also accessible by all the machines.

Ideally it would be near the city's transport hub but somewhat hard to find. I don't want to attract foot traffic; I just want it to be at an easily accessible place so I have fewer excuses not to hang out there. Knowledge about the club would spread via word of mouth or people could discover it when they searched online for old-school LAN party places or local coding competitions.

## Usecases

Old networked games like Doom, Warcraft, Red Alert would run just fine on old machines. Emulated SNES games could also be played with the two attached controllers. These games are still quite fun with the right people!

Or this would be the perfect place to host small, local programming competition parties. For example, host a weekly 45-minute programming competition with some AI generated tasks. You don't even need to have strong testcases. Just have another 20-minute section after the coding part where you can read other people's code and submit testcases to break it. I love this, and I bet you can find 12 interested people in a big city for this to be a regular weekly event.

People could hold local game jams or coding hackathons here. Educators should be able to reserve the room to teach programming basics to interested people. You don't need the internet for this either. Believe it or not, it is possible to code without internet and AI. If you didn't know something, you would need to ask ... the human mentor in the session! It's enjoyable to learn together, which is another experience that we are losing through the internet and AI.

## Rules

I want to have some strict rules to maintain the retro bunker / sanctuary vibe for the place:

Initiation: you need to register, do some short training, and accept the rules of the bunker to become a member and gain access.
Crumb-free zone: no eating / drinking in the bunker.
Player two: you can bring one visitor but you are fully responsible for the person.
WYSIWYG: no plugging in outside devices or tweaking or hacking the machines in the bunker; you have to embrace the limitations. Keep your smartphones and laptops tucked away too.
Sauron: you accept that cameras watch over you.
Airgap: let the admins know if you need a package installed, a file downloaded, or a file emailed to you from the NAS. They will fulfill the request after three days. The delay is there to reduce the dependency on online connectivity and to teach people to plan ahead.

Anyway, this is just a raw collection of ideas. The point is that this space could be a nice third place for folks with the above described niche interests. I would love to regularly attend such a place, especially for the low-tech coding jams. Plz, start such a club if you have the means for it.

published on 2026-04-06

dorms: cities should offer the shared dorm rooms experience

Mon, 02 Mar 2026 00:00:00 +0000

During my undergraduate studies I lived in a cheap, state-subsidized student dormitory about 120 km away from my home. It was Soviet-style: many small rooms, 4 people per room, bunk beds, 1 kitchen + 1 study room + 2 bathroom blocks per floor (one for each gender). The room was small, you only had a very small desk space and a small storage cabinet. It was all right because you weren't meant to live there anyway; most people went home for the weekend.

Living in a tight space with 3 other people is an interesting experience. It can be:

meh: You just work and sleep next to each other but otherwise don't interact with each other.
bad: You could have incompatible roommates. Your roommate might never clean up after themselves, be smelly, etc. Or maybe you are an early bird but your roommate is a night owl, owns a clicky keyboard, and has furious chatting sessions at midnight. Then you never sleep well, you are grumpy all the time, and you have a lot of conflicts with your roommate.
amazing: You have fully compatible roommates. Maybe you have the same work schedule and same interests. Then you can study together, have LAN parties together, etc. It's truly an amazing experience.

I think the 3rd experience is very rare. For this reason people demand more isolation, single rooms, often with private bathrooms, etc. Students aren't forced to interact with others, or to learn respect and communication with others through the daily struggle. This robs students of important life experiences and social connections needed for a healthy adult life.

Fortunately, I was lucky enough to experience all three. I wish this were more common though. So in this post I daydream about some ideas on how a good dorm experience could be more mainstream.

## Buildings

In my dream the government provides these apartments for free. The government hires the maintenance staff directly and gives them a fixed budget to operate with. Rather than seeking profit, the goal is fostering community. It's an investment in the future because a good community is likely to lead to a more prosperous future.

Ideally, there would be 3-5 such buildings in different parts of the city. They should be managed independently so that dorms can compete on the quality of life. The maintenance staff would get bonuses from the government based on resident satisfaction surveys (a monthly survey), and perhaps other stuff like maintenance velocity (repair time for showers and elevators), community engagement (inhabitant engagement rate in dorm events), eco-friendliness (how much water/energy is used). So they have an incentive to do a good job.

Living in such a room wouldn't be free for the inhabitants though. They would need to pay a small fixed monthly fee, e.g. $100 or something. This doesn't go back to the government or management, it goes to a per-dorm money pool. The inhabitants can use this pool to sponsor equipment or events that the maintenance staff otherwise wouldn't.

I'm imagining here a 10-floor building not unlike a hotel. The basement has a laundry room, a ping pong table, a small fitness corner. The ground floor has some food vending machines, large conference room / event space. The first floor has some meeting rooms of various sizes where the inhabitants can work together on stuff. The roof is parkified with outdoor gym equipment (or just solar panels if a park would be too expensive). The rest is for living. Each floor has: 1 free room that can be used as a study room, 1 kitchen, 1 bathroom for each gender, and a dozen 4-person rooms.

## Themes

If there are multiple dorms in the city, then each of them might as well come with some unique perks. Here are some ideas:

The Maker Dorm: the ground floor has a big workshop with 3D printers and other tools.
The Library Dorm: the rooms are soundproofed and library rules apply to hallways after 8 PM.
The Active Dorm: has lots of fitness rooms, and group workout events.
The Social Dorm: has large rooms, shared dinners, lots of board game nights, language clubs.

Each dorm would be resident-governed. The dorm residents could vote for their representatives who would then work with the management to ensure that the required tools get bought or events get organized. This allows the residents to practice community governance.

## Eligibility

In order to be eligible for the application, you need to:

be between 18 and 30 years old,
score some predetermined minimum on a standardized general knowledge test (not too high though; just enough to confirm that the applicants can read/write and do basic math),
have a clean criminal record for the past 2 years,
maintain an academic or some community-oriented business in the city for the duration of the stay.

The system selects from the applicant pool the residents to onboard based on a public lottery to ensure fairness. The draw is seeded by a verifiable randomness beacon (like NIST). Every applicant gets one ticket. But good academic grades, community contributions, distant home address, poor financial situation grant you extra tickets so you have a greater chance to get in. Once in, you won't be kicked out for 4 years unless you behave antisocially or are not actually living there much.

I'd limit max residency to 4 years. The purpose of these dorms is not to provide cheap, long-term living but rather give people a pure community experience without the financial stress. You cannot use your dorm as a permanent home address.

## Matching

If you don't have a room assigned or you would like to leave your current room then you can participate in a reshuffle. There would be 3 reshuffles per year (August, November, April). If you like your room and nobody is leaving, then you don't need to do anything, you can skip the next reshuffle and everything stays the same. Otherwise fill out a lifestyle compatibility profile:

chronotype: early bird ... night owl
sensory tolerance: need absolute silence ... need to hear music all the time
cleanliness: clean ... messy
social battery: room is for sleeping ... I like to chat a lot
temperature: cold ... warm
preferences: major:maths, classical-music, age>=26, ... (other arbitrary tags)
dealbreakers: smoking, snoring, loud-music, age<=23 ... (other arbitrary tags)
friends: bob, charlie, ... (the people who you would prefer to share a room with)
foes: dave, eric, ... (the people who you would prefer to not share a room with)

You also rate the previous experiences and explain why you want to move out from your current room.

The system then tries to match you with different roommates and a different room. It will try to honor the above compatibilities but otherwise it's relatively random. Random is good because it mixes people with different backgrounds together and reduces the chances for social cliques to appear.

If the new roommate is too much, the system also allows you to swap around with other people at any time. But you have to find a person to swap with manually.

Note that the frequent reshuffles are disruptive and lower the chance of deep bonds emerging with any single person. However at the same time it increases the social network and through that the chance you meet someone with whom you can establish a deep bond quickly. I think the increase of the latter is bigger than the decrease from the former so the disruptions are worth it.

## Expectation

I'd expect that after about 3 years most people would find their cool roommates and end their residency with positive memories. They would gain experience in how to live together in tight spaces with minimal conflicts. Their social network would also be greater, so if they are in trouble, they have more options now in finding support, rather than relying on the state supporting them. Overall, I think it would be a net benefit for society, and well worth the taxpayers' money indirectly.

Will there be conflict and stress when you live with 3 new, untrusted strangers every 4 months in a tight space? Yes. But keep in mind that you would be in such a place voluntarily and you can leave any time. Try to learn from the conflicts and stress and grow from it; it's the cost of not living in a bubble.

Also note that I'm not advocating that this is the only possible cheap accommodation that the government should subsidize. There's no single type of accommodation that works for everyone. All I'm saying is that this should also be an option. Society should not swing entirely into single-occupancy rooms and capsule hotels for everyone.

published on 2026-03-02

cmdmatch: match commands with simple syntax

Mon, 02 Feb 2026 00:00:00 +0000

Imagine you are implementing sudo or you have an AI worker / intern. You want to allow them to run commands on your local or production machines. For most commands you want a confirmation, justification, or your explicit approval. At the same time you want to allow running a set of safe commands without any roadblocks. How would you specify this list of safe commands?

First, what not to do: use a regex for the whole commandline. For example, suppose you want to allow listing the files in an arbitrary directory. While you might use a regex like `ls .*`, this inadvertently lets your intern also run `ls .; rm -rf /`. Similarly, you might want to allow listing logs like `cat /var/log/cups/access_log.1`. For this you might use a regex like `cat /var/log/[a-z0-9_./]*` but now your intern can also run `cat /var/log/../../root/.secretpassword`.

sudo allows globs and regexes, but the globs match whitespace of the space-concatenated invocation, so the grant "myuser ALL = /bin/cat /var/log/*" would allow running "sudo cat /var/log/secure /etc/shadow". Furthermore, the regex gets hard to maintain very quickly once you want to allow various combinations of flags.

So what would I do if I could start the universe from scratch?

# Grant syntax

Let's call the rules that allow specific invocations "grants". A single grant is a list of matchrules. A matchrule is a `[count][type][pattern]` string. The argv array is then matched greedily against the matchrules. Skip to the examples below to see it in action.

Cardinalities:

{number} means this has to match exactly the given number of times.
{min,max} means this has to match at least min and at most max times.
{min,} means this has to match at least min times.
{,max} means this has to match at most max times.
(no cardinality) means this has to match exactly once, same as {1}.
? means this has to match zero or once, same as {0,1}.
+ means this has to match at least once, same as {1,}.
* means this can match any number of times, same as {0,}.

Types:

= means the string has to match exactly.
~ means the string is an anchored regex (i.e. the regex has to match the full parameter).
: means the string is a glob. The wildcards * and ** will never match `..`.
--: this is a special marker that signifies that flags end here. It means that either a -- must follow or the next argument doesn't start with a dash.

# Grant examples

  # Match journalctl without any args.
  # = on its own without cardinality means the string has to match exactly once.
  # The list ["journalctl"] matches but ["journalctl" "journalctl"] doesn't.
  =/bin/journalctl

  # Match ls with some flags but then anything as long as it's not a flag.
  # Notice that the last part starts with the * cardinality.
  # It means there can be an arbitrary number of positional arguments.
  =/bin/ls   # argv[0] must be /bin/ls
  ?~-[lth]+  # argv[1] can optionally be a flag like -lh
  *~[^-].*   # accept non-flag-like arguments for the rest of argv

  # Allow printing the logs with globs.
  # Here the grant uses : for globs, so the user can specify only files under this directory.
  # Globs can be generally less error-prone than regexes.
  =/bin/cat
  +:/var/log/**  # ** in globs means match anything recursively (cannot go upwards via ..)

  # Allow dumping a USB disk to /tmp.
  =/bin/dd
  ?:bs=*
  :if=/dev/mmcblk*
  :of=/tmp/usbdump.*

  # Allow disk usage/free utility with some flags (https://github.com/muesli/duf).
  # ? means the flags are optional.
  # Also notice that flags are specified in a sorted order; see below why.
  =/bin/duf
  ?=-all(=(true|false))?
  ?~-output=.*
  ?~-sort=.*
  --
  *:**

# Flags

This simple matching syntax relies on a strict constraint: predictable commandline parsing. The problem is that most tools weren't designed for adversarial invocations, so it's still easy to get things wrong. In order to fully embrace the simplicity of the above syntax, you need to simplify and restrict how you invoke commands.

I recommend using this only for tools that fully embrace @/flagstyle. Here's a recap of my suggested flag syntax:

All flags must be before the positional arguments. All arguments are positional after the first positional argument even if they look like a flag. That's why -- only scans the next argument to determine whether flags are done. Refer to the command wrapping section in @/flagstyle to see why this simplifies commands.
All flags must be specified with a single - dash (though OK to allow --flag style too for compatibility).
The value for all flags must be specified via the = syntax. "-flag=value" is OK, "-flag value" is not (otherwise bool flags are too hard).
The flags configure global variables in the program, so it should be fine to reorder them.

If you accept those restrictions, then you can sort the user's flags and match them alphabetically. The duf grant in the above example relies on this. So after sorting it would accept the following invocation too:

  duf --sort=size -output=size,usage /tmp /home

Notice that --sort (with two dashes!) appears before -output. -all doesn't appear at all. You can specify multiple positional arguments thanks to the `*:**` part of the grant. This part can no longer match flags due to the -- marker. All the while the grant syntax remains a simple list of strings.

# Recommendation

I recommend writing all tools that are meant to be used in such a security context with @/flagstyle in mind. Their usage is less user-friendly, but in exchange you gain a lot of simplification in your security configuration. I wouldn't recommend using the above syntax for general-purpose commandline matching because GNU flags are too flexible. But if you are writing a small Go tool with many subcommands, then the above approach could be a simple way to specify which commands should not require extra verification.

Also in general don't trust your AI workers or interns with full, unreviewed access to production. List explicitly the common safe commands and then you will sleep better when you are on vacation. As you can see above, the syntax doesn't have to be too cumbersome.

# Notes

The sudoers glob example is from https://www.sudo.ws/posts/2022/03/sudo-1.9.10-using-regular-expressions-in-the-sudoers-file/.

published on 2026-02-02

cliusage: use the Go package doc as the usage string

Mon, 12 Jan 2026 00:00:00 +0000

Writing a nice -help message for a CLI tool is often a hassle. But in Go I found a nice technique: use the package comment (the top block) as the usage string. You can achieve this easily by embedding the source with //go:embed and parsing out the top comment block:

  // The cliusage tool demonstrates using the main package comment as the usage string.
  //
  // Usage: cliusage -input=[filename] -output=[filename]
  //
  // Some description and examples go here.
  package main

  import (
    "context"
    "flag"
    "fmt"
    "os"
    "strings"

    _ "embed"
  )

  var (
    flagInput  = flag.String("input", "", "The input file.")
    flagOutput = flag.String("output", "", "The output file.")
  )

  //go:embed cliusage.go
  var source string

  func usage(fs *flag.FlagSet) {
    for line := range strings.Lines(source) {
      if len(line) == 0 || line[0] != '/' {
        break
      }
      fmt.Fprint(fs.Output(), strings.TrimPrefix(strings.TrimPrefix(line, "//"), " "))
    }
    fmt.Fprintf(fs.Output(), "\nFlags:\n")
    fs.PrintDefaults()
  }

  func run(ctx context.Context) error {
    return nil
  }

  func main() {
    flag.Usage = func() { usage(flag.CommandLine) }
    flag.Parse()
    if err := run(context.Background()); err != nil {
      fmt.Fprintf(os.Stderr, "Error: %v\n", err)
      os.Exit(1)
    }
  }

The output looks like this:

  $ go run cliusage.go -help
  The cliusage tool demonstrates using the main package comment as the usage string.

  Usage: cliusage -input=[filename] -output=[filename]

  Some description and examples go here.

  Flags:
    -input string
          The input file.
    -output string
          The output file.

This keeps the documentation natural and readable for people reading the source directly. Note that the source doesn't have to be the package comment. It could be a section from the README or other documentation files; the concept remains the same.

One downside is that embedding the full source (not just the top comment) increases the binary size. But if you keep the actual logic in a library and treat main.go as a thin wrapper, the overhead is negligible. It's a small trade-off for documentation that rarely goes out of sync.

This practice also helps keep the usage string short. -help shouldn't be a full reference anyway. It should just describe what the tool does and contain example invocations for the common use cases. The goal is to jog the memory, not to teach. Detailed docs should live in a markdown file; -help should simply link to it rather than dumping pages of text.

Edit from 2026-04-07: In general always put the doc comment in a file named after the package or a file named doc.go. This predictable pattern makes it easy to find it when browsing the code. If you plan to embed the source just for the doc comment, then put it into doc.go. Then the overhead will be quite small.

published on 2026-01-12, last modified on 2026-04-07

huelights: I switched my lights to Philips Hue lights

Mon, 01 Dec 2025 00:00:00 +0000

this post has non-textual or interactive elements that were snipped from rss. see the full content at @/huelights.

When I was a kid in the late 2000s, we had those earlier versions of the Osram Duo Click lightbulbs. Switch once, and the lamp is at full brightness. Switch twice, and it has very low brightness, ideal when waking up in the night. I've missed that feature ever since I moved out, though I never actively looked for such a bulb.

One day a friend showed me his Philips Hue lights. I really liked that you can adjust the brightness. I realized I could recreate my old experience with it. So as an experiment I bought a few lights and a 4 button switch, this one:

[non-text content snipped]

Hue also needs a bridge but I managed to snag one from a friend who ditched the Hue ecosystem for Home Assistant. (I did look into Home Assistant too but it was just too much for me; I wanted something simple to start with.) Hue doesn't need internet or a central service either. Everything can be controlled from the local network, so that sounded good enough for me. Plus, I only want controllable lights; I'm currently not looking for any other smart home widget.

I played around with Hue and I ended up liking it. I really like that I can put switches all around the place and configure them however I want.

I understand that the lights are always on and listening for commands from the bridge. So I'm wasting some electricity even when they are off and this bothered me at first. But they don't seem to add up to a lot on my electricity bill so I decided I can sort of live with this in exchange for the convenience.

# My configuration

I configured each of the four buttons to be an independent switch for a specific room, with this scene cycling logic:

First press when the light is on: turns it completely off.
First press when the light is off: sets the light to low brightness. I use this during the night when I don't really need light but I don't want to bump into things either.
Double press: sets the light to mid brightness. This is the general setting when I need some light.
Triple press: full brightness. I use it when reading or writing.

I used the official app to configure this. However, I don't use it for controlling the lights because it takes ages to start up. For my wife I installed Hue Essentials (available in Play Store) and for myself I sideloaded https://f-droid.org/en/packages/io.github.domi04151309.home/ because that one looked even simpler.

# Configuration changes

I have not found a way to configure scene switches in apps other than in the official one. And the official app allows you to configure only the top and bottom buttons for scene cycling. The middle buttons can be configured only for dimming. I don't understand why. Maybe to sell more switches?

I started wondering how the various apps communicate and configure the system. It turns out the bridge exposes a REST API for this and that allows you to configure all buttons to scene cycle. You can go to /debug/clip.html of your bridge's https port and play with it. There's a v1 and a v2 API. I suspect the scene cycle stuff is specific to v2, and that's why most apps don't support it.

Unfortunately the API is underdocumented and the bridge only returns a generic HTTP error code without any explanation if you make a mistake. You can find a short reference of the endpoints on the Philips webpage (needs registration). But it doesn't tell you how to use it or give you usage examples. I couldn't find a good article or forum post explaining how to use it either. And I searched a lot.

Eventually I gave up and asked an AI to provide me sample code. And to my surprise it managed to come up with an almost working JSON that the bridge accepts. This really cemented my belief that AI is truly a transformative approach to how humans work with information. So I managed to get started thanks to AI.

Now I have an intent file at $HOME/.config/hue.cfg with content like below. In general the bottom three buttons of all the switches control the same main lamps in my apartment. Only the top button controls switch-specific rooms based on the switch's location. This way the buttons remain easy to remember for me. With more lamps I'd probably label the buttons on the physical switches, e.g. when I get Hue bulbs for the kitchen too.

  hueaddress https://192.168.1.ADDRESS/
  huekey     SOME_RANDOM_CHARACTERS_THE_BRIDGE_NEEDS

  KidSwitch 0 Kid
  KidSwitch 1 Office
  KidSwitch 2 TV
  KidSwitch 3 Hallway

  BedSwitch 0 Bed
  BedSwitch 1 Office
  BedSwitch 2 TV
  BedSwitch 3 Hallway

  # The switch on the bathroom entrance switches the bedroom too.
  # I don't have Hue lights in my bathroom yet.
  BathSwitch 0 Bed
  BathSwitch 1 Office
  BathSwitch 2 TV
  BathSwitch 3 Hallway

This describes my 3 switches and the 5 lamps they control. If I want to add a new switch or reorder the buttons then I just edit the file and run `huepush -apply`. The tool reads the full bridge configuration so it understands which entities the references in the config file refer to. Then it generates a new switch configuration and pushes it. Without the `-apply` flag it just prints the switches that are not matching the intent. The code is this: https://github.com/ypsu/cfg/blob/main/huepush/huepush.go. Requires no dependencies other than the Go standard library. Quite easy to use for me.

Note that I configure the actual brightness levels in the app itself. I save the desired levels as scenes named "low", "mid", or "high". The switch buttons are then mapped to cycle those scenes.

(Sidenote: when I was still experimenting with various apps, one switch got into a bad state. One button was always turning off the lights and I couldn't override that behavior with the v2 API. Maybe it was a v1 API setting. Resetting the switch via removing it from the bridge and readding it solved the issue.)

# Switching from my desktop

I also wrote myself another small tool to adjust the light levels from my desktop. I named it lll as in "Light Level Lever" just to make it easy to type with my dominant hand. If I run it without arguments, then it displays the light levels of all my lamps.

I can use it like this to switch the lamps: `lll o3t1h0`. The letters identify the light and the number sets the desired brightness. The above sets the Office light to level 3 (full brightness), the Tv light to level 1 (minimum brightness), and turns off the Hallway light (level 0).

I also configured it to control the display backlight brightness of my desktop using DDC. I wanted this because I use different monitor brightness and system theme depending on how much background light I have. Previously I did this via `ddcutil setvcp 10 $BRIGHTNESS` but thought I would simplify this for myself. So now I can use `lll d3` for full backlight or `lll d0` to set backlight level to 0% which is still a usable backlight level on my Thinkpad display. I needed AI assistance for this too because the ioctl magic was too hardcore for me to figure out. I asked AI to generate a code example to set brightness via ioctl and then I based my code on that.

I often use this tool because it's nicer than fiddling with the phone or walking to a switch to adjust the light. The code for this one is at https://github.com/ypsu/cfg/blob/main/lll/lll.go.

# Recommendation

Are you happy with your traditional lights? Then I recommend sticking with them.

But if you are looking for flexibility in brightness then I can wholeheartedly recommend the Hue ecosystem. I'd expect that other similar brands could work just as well, e.g. IKEA. I went with Hue just because it's simple to start with, it has a broad selection of lights, and has a REST API for the complex needs later on. As far as I understand, the switches and lights use standardized technology so you can put them into other systems too if you change your mind later.

Buy one such light+switch+bridge combo for experimenting and then decide. That's how I started too.

published on 2025-12-01

exercise: do the minimum effective dose of exercise every day

Mon, 03 Nov 2025 00:00:00 +0000

I want to avoid being overly unfit without spending too much time on exercise. So for the past few years I have done a small <10 minute exercise almost every day. The exact approach varied over time but now there are two types of exercises:

Hard ones where I can do only a few reps, for example pushups, pullups, curls with heavy weights. These I count manually to my desired target and do 2 sets of reps.
Easy ones that I can do for minutes, for example plank, squats, situps, curls with light weights. For these I set the phone timer for 2 minutes and do them for that long. Then I can daydream during the exercise. I quite enjoy these.

I pick 2 exercises every day and do them. It's different every day so the muscles get plenty of breaks. I won't bulk up from these but it makes me feel much better about myself. My mood is better for the day. And I no longer feel unfit or get out of breath from a bit of stair climbing.

If I feel unmotivated, sad, or otherwise constrained (for example while traveling) then I only do one set only, for example squat hold because I can do that anywhere, even in the toilet. Rule: never break the habit. No zero days. If it's the end of the day and I'm in bed, I can still do some situps. This way the habit stays in my subconscious and the momentum keeps me going. The habit gets easier over time. I don't even think about it much.

published on 2025-11-03

smartgo: I wish for a Go-like language with Rust-like pointers

Mon, 06 Oct 2025 00:00:00 +0000

I'm using Go now for over 5 years and I really like it. But the properties of Rust's model are quite seductive:

No GC, no runtime.
More optimization opportunities compared to C-like languages thanks to the lack of aliasing for anything writable.
Race-free coding by default.

I tried learning Rust a few times but I always failed to get traction in it. I like that Go's structure and idioms are simple so it doesn't require advanced IDEs to be productive with it.

For instance you cannot define new types within a type. You can have only top level types. And for functions you can only have top level functions or methods on a type. No deeply nested structures. Those always make my head hurt because they are often messily organized. In Go you have to organize on the package level. This makes documentation lookup trivial because I can just run "go doc packagename.Symbol" to look up stuff. And there are other small quality of life things with Go that make it easy to work with, e.g. I love the simplicity of the interfaces or the imports system.

My point is that my problem is not with the borrow checker or lifetime analysis but basic programming language ergonomics. I argue that some complexity in Rust is not due to its memory model and I want a language that gets rid of that part of complexity.

What I'm envisioning here is having a Go variant with the GC replaced with smart pointers inspired by Rust and everything else kept Go-like. There would be 3 pointers:

*: star represents the read-only pointers.
+: plus represents mutable pointers.
^: hat represents mutable pointers with ownership.

Here are the main rules:

You can borrow ^ or + as a * pointer to a struct or function as long as nothing else accesses a ^ or + variant of the pointer during the lifetime of that borrow.
When a ^ pointer goes out of scope, the resource behind it will be auto-released. If the pointer type has a release() function then that will be automatically called before the free.
A struct can contain any combination of ^+* pointers. But all those fields downgrade to * when accessing the struct through a read-only * pointer.

Slices contain pointers so slices would have 3 variants too. Similar for closures (^ and + represent closure, * represents a free-form function).

Oh, and while we're at it, let's make all the pointers non-nil by default. Use something like ?*ptr to express the fact that ptr can be nil too.

I'll now use code examples written in this hypothetical language to better express what I mean. I don't have a compiler so apologies for syntax and logical errors. Hopefully the gist comes across.

# Binary tree example

A binary tree looks quite complex in Rust but could be relatively simple here. I'll demo this with an integer tree because I don't want to overcomplicate this with generics for now.

  type Tree struct {
    // ?^Node means this pointer is either empty or it owns a Node pointer.
    root ?^Node
  }

  type Node struct {
    value  int

    // ?^Node means this pointer is either empty or it owns a Node pointer.
    lt, rt ?^Node
  }

  // In this implementation only the owner can add elements (mostly for demo purposes).
  // That's because the receiver is a ^ pointer.
  // If a function receives a ^ pointer then it must be returned or it will be released.
  // In this function it is returned so the node is kept alive.
  func (n ?^Node) Add(v int) ^Node {
    if n == nil {
      return &Node{value: v}
    }
    // At this point n cannot be nil so its type is the same as ^Node.
    if v <= n.value {
      // Here's an example for an explicit borrow with a tuple assignment.
      // The struct's lt field is borrowed in the tmp local variable.
      // Setting n.lt is not really needed here with a smart enough compiler with a borrow checker.
      // Such a compiler could recognize that n.lt is not used anywhere in this block,
      // and it will be overwritten eventually anyway.
      // So you could have a usable language even without a borrow checker.
      // Though I do want a borrow checker so that I can keep the code compact.
      var tmp ?^Node
      tmp, n.lt = n.lt, nil
      n.lt = t.Add(v)
    } else {
      // Here it is the same while relying on the borrow checker to prove this is fine.
      n.rt = n.rt.Add(v)
    }
    return n
  }

  func (t *Tree) Add(v int) {
    t.root = t.root.Add(v)
  }

  func main() {
    var t ^Tree = &Tree{}
    t.Add(3)
    t.Add(4)
    t.Add(5)
    // Here the whole tree gets auto-released because t goes out of scope.
  }

# Flags example

I really like Go's solution to flags. It's simple to use for simple functions too. It relies on global flags though. But that's not a problem with the right building blocks: a smart mutex type in this case.

  package sync

  // This is a standard mutex.
  // Note that Lock/Unlock modifies it yet it takes a read-only receiver.
  // Internally it is implemented via unsafe magic to bypass the language constraints.
  // But this unsafeness doesn't get exposed to the users of the mutex.
  type Mutex struct { ... }
  func (mu *Mutex) Lock() { ... }
  func (mu *Mutex) Unlock() { ... }

  // RAII type for auto-unlocking mutexes.
  type MutexLock struct { mu *Mutex }
  func (mu MutexLock) release() { mu.Unlock() }

  type Guarded[T any] struct {
    mu    Mutex
    value ^T
  }

  // Takes a read-only guard and converts it to a mutable reference.
  // Again relies on unsafe magic.
  func Lock[T any](g *Guard[T]) (+T, ^MutexLock) { ... }

Now you can write this:

  package flag
  func Int(name string, value int, usage string) *sync.Guarded[int] { ... }

  package main

  // Globals can be only read-only (*) pointers.
  // But *sync.Guarded[] happens to be that.
  var flagPort = flag.Int("port", 8080, "The server port.")

  func main() {
    flag.Parse()
    // Use RAII to get exclusive access to the flag.
    // The lock will be autoreleased when the scope ends.
    port, _ := sync.Lock(flagPort)
    http.Listen(*port)
  }

It's a bit cumbersome to access global vars through locks but should work out quite reasonably.

# Other notes

I wouldn't mind not having goroutines or coroutines either. IMO normal threads could scale well once Linux starts supporting userspace scheduling.

Also I'm not optimizing for max performance. For instance accessing a global variable would need to go through a mutex lock. But that's fine: the main optimization is that there's no runtime and that's enough for most things. More unsafe constructs can be used for parts that need to be truly performant.

There is more to all this: how to handle slices, closures, interfaces. Probably not worth going into those details given I'm not fully sure I got the pointers down to a usable state. But my main point here is that I strongly believe there's a not-yet invented language that has Go's simplicity but Rust's memory semantics. If someone manages to pull this off well, then I think they have a good chance of disrupting the programming language world yet again.

# Edit 2025-10-10: Linear types

I came across the concept of "linear types" as defined at https://borretti.me/article/introducing-austral#linear or in more detail at https://austral-lang.org/spec/spec.html. This looks like a simplified version of the Rust semantics. Borrows are explicit in this language. I haven't digested these ideas yet, just wanted to save the link here for now. My first reaction is leaning dislike because I don't like too much verbosity. But it certainly proves that borrow checking doesn't need to be expensive.

published on 2025-10-06, last modified on 2025-10-10