codingkoi

> the Wayland server

This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.

Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).

That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.

There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.

I accidentally did that with the original Team Fortress on Quake, and the Mechwarrior 2: Mercenaries CD. I always felt like the track from that CD that went with the `rock` map was a good match, but I couldn't really say why.

I haven't thought about that in years.

I haven’t used it recently but I believe it sets a header on the request when it comes from HTMX so you can change whether you send the whole page or just the fragment back.

You can also just send the whole page and use other features to select just the part that you want to update (obviously that has a cost of sending the whole page though).

My siblings and I would tape a monopoly board to the TV to split it vertically and then play team games to get around “screen cheating”. I think it had the best of both worlds. We were still in the same room but we could ambush and sneak up on each other. Definitely less expensive than this solution.

Goldeneye 64 was the best bang for our buck of any game we ever bought. We did the same thing with Perfect Dark.

Once I discovered `lib.fakeSha256`, I just put that in the derivation, try to build it and then use the error message to find the correct hash to put into it. Probably not the fastest way to do it, but it's easier for me to remember.

I’m not sure I follow your analogy. I think the dynamism of a list is separate from the type system. I can say I have a list of integers but that doesn’t limit its size.

I can think of instances where that might be useful and I think there’s even work being done in that direction in things like Idris that I really know very little about.

There are trade offs in everything. I’m definitely a fan of dynamic type systems especially things like Lisp and Smalltalk where I can interact with the running system as I go, and not having to specify types up front helps with that. Type inference will get you close to that in a more static system, but it can only do so much.

The value I see in static type systems comes from being able to rely on the tooling to help me reason about what I’m trying to build, especially as it gets larger. I think of this as being something like what Doug Englebert was pointing at when he talked about augmented intelligence.

I use Python at work and while there are tools that can do some pretty decent static analysis of it, I find myself longing for something like Rust more and more.

Another example I would point to beyond the blog post I previously mentioned is Rust’s serde library. It totally allows you to round trip data while only specifiying the parts you care about. I don’t think static type systems are as static as most like to think. It’s more about knowns and unknowns and being explicit about them.

Your third point about having to encode everything isn’t quite true. Your example is just brittle in that it doesn’t allow additional values to show up causing it to break when they do. That’s not a feature of static type systems but how you wrote the code.

This blog post[1] has a good explanation about it, if you can forgive the occasional snarkyness that the author employs.

In a dynamic system you’re still encoding the type of the data, just less explicitly than you would in a static system and without all the aid the compiler would give you to make sure you do it right.

[1]: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

I’ve used Input Sans[1] with Python in the past and it works pretty well except if you use white space for formatting or ascii art as opposed to just indenting.

It works because the spaces are nice and wide unlike in a typical proportional font.

I don’t use it anymore mostly because I wanted something with a little more character but it’s worth a try.

[1]: https://djr.com/input/

Does anyone know the US case law on the 1st amendment being applied to corporate actors?

I see the argument often that things like this are a free speech violation but the 1st amendment says “Congress shall pass no law...”. It doesn’t apply to actors other than the state.

I’m not defending Google’s actions here but I also don’t think it’s technically a free speech violation at least as the amendment is written, so I’m wondering if there are any cases addressing this sort of censorship w.r.t. the 1sr amendment.

I came to it from the perspective of wanting a digital notebook that I could also load PDFs on and write margin notes in. I used to keep handwritten notes in notebooks, mostly bullet journal style, and I've completely converted over to using the reMarkable for that.

For that purpose, it is excellent. The software has a few bugs that I've bumped into from time to time, but nothing show stopping. The feel of the stylus on the screen is much closer to pen and paper than anything else I've tried.

It's running Linux and you can shell into it when it's connected to a computer via USB (it appears as a network device on the host), so even if the company collapses, it's very hackable as evidenced by the library I mentioned above.

That said, the price point is a bit high for what it does, and the first thing I always get asked about it is whether it converts my writing to text, which it doesn't.

My wife is in grad school and used to print out papers she needed to read for class so she could write margin notes, and now she just loads the PDFs on her reMarkable and keeps notes there.

The EPUB support was dodgy last time I tried it. The one book I loaded on it would only show one line per page until I adjusted the font size. I generally prefer PDF format anyway, since it's usually laid out better and I'm usually reading technical books on it anyway.

All that said, I highly recommend it, if it's something you think you'd find useful, and aren't put off by the price tag.

The tools exist with which to do it. People have reverse-engineered the reMarkable enough to start creating Rust libraries to support the hardware[1].

I've been thinking of experimenting with building a Sketchpad-like system on it. With Rust, you have access to LLVM fairly easily, so you could probably do something with JIT compiling code (maybe a Smalltalk dialect) to give whatever you build a programmable interface.

Why Smalltalk? It's simple syntax would be easier to deal with on the reMarkable, and you might be able to look at doing handwriting recognition to let you write the code with the stylus. Could also go with a Lisp, for similar reasons.

All of this is just speculation because I haven't started it for lack of time, but I'm really interested in exploring what's possible in that space. The system specs will probably be constraining (I haven't looked at them recently) but I'm sure they're far far more than what Sketchpad had.

[1]: https://github.com/canselcik/libremarkable

That's alluded to by the synopsis on the back of the book. I don't think I'd consider it a spoiler.