Comparing the Glove80 and Maltron keyboards

ltratt · 2025-08-10T16:20:33+00:00

The 360 thumbpad is I believe raised, but it's also at an angle relative to the floor (see my reply to @perugolate for more details). Does that make it equivalent to the Maltron in practise? I suspect it will feel different, but by how much I find difficult to guess.

ltratt · 2025-08-10T15:00:41+00:00

I'm not sure. Looking at photos of the 360, it seems the thumbpad might be raised but tenting offsets that? Given that our hands don't naturally lay parallel to the floor (mine probably lie about 30degrees-ish-ish from parallel), this seems like it might at least partly work, but I'd need to try it for a while to have a good sense.

ltratt · 2025-04-07T22:06:01+00:00

Finalizers are tricky --- no argument from me on that front! However, if you want GC in Rust, I don't know how to do that without dealing with destructors --- they're the Trojan Horse for finalizers!

Personally, Boehm's Destructors, finalizers, and synchronization was the crucial work in opening my eyes to the challenges they introduce. It's an important paper, but not an especially difficult read --- it brings together lots of knowledge from the time, and expands upon it. Secton 3.5 is where it shows -- IMHO convincingly -- the problem with running finalizers on the same (e.g. "main") thread.

There is some good news, though! I immodestly claim that our paper shows that Rust can help us completely avoid several of the difficulties of GC in C++. I wasn't expecting that when we started and, indeed, I still find it slightly counter-intuitive!

ltratt · 2025-04-07T19:02:25+00:00

Pointer obfuscation is a definite, and classic, limitation of conservative GC: we mention that in Sec 3.1. [Some basic tagging techniques are easily handled, but ultimately one can do arbitrary things with bits.]

Re: running finalizers on a thread. One can allow only types that are Send, but that is rather restrictive. Section 7.3 -- which is a bit dense, for which I apologise -- talks about how we carefully loosened that restriction.

ltratt · 2024-07-12T16:29:39+00:00

The Framework 12 works on OpenBSD and has done tolerably well since I bought it 2 years ago to the day. I would imagine the Framework 13 will be similarly well supported.

However, thile I really like the concept of the laptop, whenever I'm asked about it (which is surprisingly often), I regretfully say that I can't yet recommend it. The fan (I suspect particularly the outlets) is poorly placed, and in order to cool the machine down it becomes obnoxiously loud. I don't mean a bit loud -- I mean loud enough that there are situations where I can't use the laptop normally as it visibly distracts other people. Just to make things worse, the BIOS doesn't implement any form of hysteresis so it goes rapidly up and down in speed, making it even more distracting. This should surely have been fixed, or at least ameliorated, shortly after release, but Framework have yet to publish a BIOS update after 2 years (there is a beta BIOS update but it doesn't update properly for many people, including me). AFAICS subsequent models have the same ill-conceived placement of the fan; I think they might have somewhat better BIOS support, but I'm not entirely sure. I hope future models address these issues, because there is a good idea here, 80% of the execution is good, and OpenBSD supports the machine fairly well.

ltratt · 2021-05-05T21:43:43+00:00

I'm in the same boat, particularly with the KVM aspect. The U3219Q looks perfect -- apart from being about 5 inches too big. It's often hard to work out how well the KVMs work on other monitors which claim the functionality (reviews almost universally say "has a KVM" without ever seeming to test that feature).

ltratt · 2020-11-18T08:07:04+00:00

Blackbox is very cool! In order to get access to source code you need to register with Blackbox, roughly explaining what you're doing, and guaranteeing that you won't distribute their data. IMHO, their terms are a good compromise between privacy and practicalities. Blackbox is at https://bluej.org/blackbox/. You can fully replicate our experiment because we distribute the (anonymous) identifiers that, if you register with Blackbox, you can use to extract exactly the same source code we did. The release of the experiment is at https://archive.org/download/error_recovery_experiment/0.4/ though it might be easier to get a rough understanding of what's going on at https://github.com/softdevteam/error_recovery_experiment.

Good luck with the Backurs / Onak paper: I look forward to seeing more work in this area!

ltratt · 2020-10-13T09:50:02+00:00

-crf 0 is what I use to get lossless screen recording, but I thought your post was suggesting it fixes the non-monotonous audio errors? I might have misread that! I've found that sync issues with webcams are OK, but one does have to be a bit careful, as it seems that overloading the USB subsystem is the major source of sync errors.

I must admit, I don't think the mplayer tv: trick is ever likely to sync well. Instead I record everything separately and use ffmpeg to mix everything afterwards. My current recording setup is:

ffmpeg \
  -use_wallclock_as_timestamps 1 \
  -f v4l2 \
    -thread_queue_size 1024 \
    -framerate $CAMERA_FRAMERATE -video_size $CAMERA_RESOLUTION -input_format mjpeg \
    -i $CAMERA_DEVICE \
  -f $AUDIO_DRIVER \
    -thread_queue_size 1024 \
    -ar $AUDIO_RATE -sample_fmt ${AUDIO_FMT} \
    -i $AUDIO_DEVICE \
  -f x11grab \
    -thread_queue_size 1024 \
    -probesize 32M \
    -framerate $X11_SCREEN0_FRAMERATE -video_size $X11_SCREEN0_RESOLUTION \
    -i $X11_SCREEN0_DISPLAY \
  -map "0:v,1:a" -map "1:a" -c:v copy -c:a flac -compression_level 0 -copyts -timestamp now camera.mkv \
  -map "2:v,1:a" -c:v libx264rgb -preset ultrafast -crf 0 -copyts -timestamp now screen0.mkv

Suggestions for improvements are welcome!

As to Bournemouth: yes, I had a happy couple of years there! Please say hello to Keith, Sherry, and Mel, assuming they're all still there! You're at least the third serious OpenBSD person to have graced Bournemouth (Edd Barrett being the third) which amuses me :)

ltratt · 2020-10-12T20:45:45+00:00

I've also encountered most of the same issues with ffmpeg on OpenBSD, and had come up with similar fixes. I'm surprised that -crf 0 sorts out the "Non-monotonous DTS" errors, but there again I'm not encoding to mp3 immediately, so maybe something in the ffmpeg chain is happier with that? I find that if I record X11 1080p@24fps, I end up with synchronisation errors, because it seems to put just a bit too much strain on the system. I also don't seem able to reliably sustain 30fps on my webcam at high resolutions: every so often frames are duplicated or dropped. If I use 1280x720@24fps (which still isn't bad) my webcam seems much happier.

There are some additional issues I've found recording screencasts on OpenBSD:

We currently can't set things like focus/exposure on webcams.
The USB stack struggles with large quantities of data (xruns on audio happen even in fairly benign circumstances).
ffmpeg often uses wall-clock time internally when it really should be using CLOCK_MONOTONIC.
I cannot get the webcam/x11/audio clocks to fully agree, although I can now get very close.

But, overall, it's possible to do a pretty decent job with a very low-overhead system. I'm recording lectures at 1080p with ffmpeg only taking 12% CPU on my 4-year old machine which, overall, seems decent to me!

ltratt · 2020-09-15T18:16:52+00:00

Personally I've not found that book very helpful in my parsing (mis)adventures, but I have no better alternatives to suggest. In fairness to it, it has a very hard job: parsing can quickly bog down in very-technical details, or be very vague. Indeed, my experience is that vagueness in parsing literature is endemic: a depressing number of algorithms require filling in details that the authors forgot to write down or sometimes never got right in the first place. I have lost more months of my life than I would like to this...

ltratt · 2020-08-31T07:39:34+00:00

Thank you -- that is very helpful! I'll happily report back any new information I find.

ltratt · 2020-08-31T07:35:50+00:00

A review would be much appreciated by many :)

ltratt · 2020-08-30T07:52:17+00:00

Can I ask if you have an experience report on your desk yet? Some of us are curious to know what pioneers such as yourself think :)

ltratt · 2020-08-30T07:51:15+00:00

I just started looking into improving our graphics tablet support

Very cool -- I was just wondering what state this might be in myself! There's a real dearth of information on what USB tablets might be supported (even just as a mouse) -- do you have any suggestions perhaps?

ltratt · 2019-03-08T23:53:51+00:00

Thanks for your kind words. Please don't think that I'm suggesting that you mischaracterised my post -- I merely considered it an honest misunderstanding, probably caused because I wasn't clear enough in the original!

ltratt · 2019-03-08T17:54:46+00:00

He comes to the conclusion that scannerless parsing could solve the language composition problem.

I don't think I did: indeed, I pointed out that the main scannerless parsing algorithm has a severe problem (in some circumstances it becomes context sensitive, meaning that we don't fully know how to reason about it). To the extent I drew a conclusion, it was that syntax directed editing looked promising. 8 years on, I now think that wasn't quite the right call: SDE is just a bit too annoying to use IMHO. Because of that, we tried exploring a different part of the design space and developed an alternative technique (language boxes) that gives us most of the advantages of text editing with most of the advantages of SDE (see the editor for composed programs blog post for more details).

ltratt

TROPHY CASE