pleroma.debian.social

pleroma.debian.social

Jonathan Dowland | @jmtd@pleroma.debian.social

Principal Software Engineer on #OpenJDK #IBM. #Debian developer. PhD in Computing Science. Amateur historian (Computing Science and H/W, esp. Commodore Amiga). Guerilla archivist.

I’ve been deploying some old tech recently (smokeping, crm114, spamassassin!) and I’m wondering if they’re still the right tools for those jobs or if I’m relying on very out of date expertise

I found some late 90s mail yesterday, including stuff from a close friend of mine who since died of suicide. Ended up being pretty down about it

I just found the email where Telewest announced “Blueyonder”. Also a usenet message between me and the guy who went on to make garry’s mod (talking about Mandrake Linux 7)

@purpleidea what provoked my question was actually email but I use the year scheme for most files as well

@highvoltage I think I’m honoured to have this described as a “Jonathany question” :)

@purpleidea something spanning >1 year is a problem yes. Also non-calendar years (UK tax years, or academic). There’s definitely no bulletproof approach. But one thing I like about starting with calendar year folders is, for most stuff, it’s clear, and also caps off growth

Does anyone subdivide files etc by decade? I usually use by-year, but the lists are getting long. Something like

```
├── 199
│ ├── 1998
│ └── 1999
└── 200
├── 2001
├── 2002
└── 2003


```

I missed the rsyslog ai drama

I love how vibecoded commits are called vommits. It's so perfect.

New blog post: More lava lamps
https://jmtd.net/log/lavalamps/more/
I bought some new bottles for my lava lamp, so I write about the colour combinations I have chosen. With pictures.

@brunogirin yes. When I hit this I took it for granted that accepting file descriptors actually made sense for someone, then it was pointed out to me, the file descriptor is not a path. Why did they even add this? I wondered if it was inherited Legacy, but they explicitly added this in 3.3.

@fred perhaps there is hope: for those of us inclined and sufficiently skilled, there remains a need for taking a machete to processes, and understanding how to do things simply. We’ll be drowning in work!

what I hadn't realised was, things will get worse, not better: I'm now seeing systems that are complex beyond human reasoning, because humans *aren't reasoning about them*. >1kloc bash scripts embedded within >2kloc YAML files, that are not independently developed or tested, stuff like that

One consequence I thought would follow from vibecoding was, systems are not going to get simpler: when two bureaucratic processes interact, and those processes are aided by automation, there's less incentive to cut through the bureaucracy and simplify the underlying processes

The stupidest thing was discovering that `os.path.exists` can accept integers, and treats them as file descriptors, meaning `os.path.exists(0)` is true, and anything that coerces to 0 is also true for example the Boolean value false

Yesterday was quite unusual for me, I spent a whole day on one thing, writing python. It was also mostly quite pleasant.

I’ve reached half a day fighting $REDACTED_INTERNAL_CICD and can stomach no more. On to something else

@cstross @Gnuxie someone tell redhat (or IBM) that hah

ER has appeared on Netflix. Very happy

Huh, replicateM (where "M" once meant "Monad") now operates on Applicative. I can see how that happened, the API is being preserved (it's still in Control.Monad). I guess it's like map and fmap not being the same. #haskell

»