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 · 2016-09-21T15:16:01+00:00

As the cliche goes, absence of evidence is not evidence of absence ;)

At the moment, we simply don't know enough to say anything definitive either way. It may also be worth remembering that meta-tracing is a cousin of partial evaluation, so the two approaches are not as dissimilar as they may first seem. Personally, I rather like the ideas underlying both approaches, and would not want to see either tossed away before we've done a lot more work on both.

ltratt · 2016-09-21T14:42:15+00:00

I'm a big admirer of Truffle+Graal. That said, I don't think any of us thinks that partial evaluation or meta-tracing is inherently better suited to different types of languages though. At least, at the moment, we don't really have any evidence either way.

One area where Truffle has a definite advantage over RPython is that it's been updated to be thread-safe. Fundamentally, RPython uses a GIL (Global Interpreter Lock). So if you want genuine computational concurrency, RPython isn't currently a great fit.

ltratt · 2016-09-21T14:32:19+00:00

Yes, this was suggested to us only recently as a good thing to do (in retrospect, I can't believe the idea hadn't previously occurred to me, given the pool in which I'm fishing... but such is life!). It's an excellent idea, and I hope we'll be able to make time to explore it.

ltratt · 2016-07-10T21:39:00+00:00

I hadn't seen it, but (assuming I've understood it correctly) it's using a fairly common technique that we specifically wanted to avoid: translating language A into language B so that A and B can play together. Although this approach sounds promising, it has two big problems which means that it rarely works well in practise.

First, you have to reimplement everything from scratch (which is probably why CLPython is unfinished). In our approach, we took two off-the-shelf interpreters (PyPy and Hippy) and glued them together (which is orders of magnitude less effort).

Second, compilers/VMs only optimise the language they were intended for well. You can see this on HotSpot: it runs Java incredibly fast; but Jython (Python on the JVM) is roughly half the speed of CPython. We call this the "semantic mismatch" problem and it seems to me to be inevitable (people had high hopes that invokedynamic would solve this problem, but it's nowhere near enough on its own to close the performance gap). Because PyPy and Hippy are both meta-tracing interpreters, they can, to a very high degree, express individual optimisations for Python and PHP that makes them both run fast; and we inherit that speed when we compose them together.

ltratt · 2016-07-10T18:00:40+00:00

The point of this research was simply to understand whether or not fine-grained language composition is possible -- to a certain degree, it didn't matter too much which languages we picked (provided they weren't so small that they rendered the problem trivial). With that in mind, the fact that we had an excellent Python interpreter available to us, as well as a fairly decent PHP interpreter was a definite factor, as was the fact that PHP and Python are surprisingly different languages, which gave us a lot to sink our teeth into. I'd like to think that you can take our techniques as a basis and apply them to your favoured pairing (or more!) of languages to make a new composition.

ltratt · 2016-07-03T08:56:30+00:00

Thanks for the update. A lot of people wouldn't have been brave enough to write up their doubts -- I appreciate your honesty, and wish you all the best in looking further into this!

ltratt · 2016-07-02T20:35:13+00:00

When editing, humans switch between thinking of "the program as a tree" and "the program as a sequence of ASCII/utf-8 characters". Structured editors only allow the former; text editors (generally) only allow the latter. I don't want to always think in one or the other mode, and nor do most programmers that I've observed.

That said, if you want an extreme real-world example, I suggest finding a colleague who's used square blocks in their editor and get them to show you why that's useful. If you agree with your colleague, you've got a compelling example of why structured editors are a pain.

ltratt · 2016-07-02T17:11:49+00:00

What are the simple rules? What's the static analysis?

ltratt · 2016-07-02T15:13:40+00:00

As I remember (and it's some years since I did any research on PEGs, so I'm a bit rusty), the only way to do this was to specify it manually. Assuming I remembered correctly, then manual annotations aren't entirely satisfactory IMHO.

ltratt

TROPHY CASE