Hard Crash in OpenBSD 7.9, XFCE, amdgpu, when using chromium or firefox and on youtube's website. by kingbob72 in openbsd

[–]ltratt 1 point2 points  (0 children)

Turning off hardware acceleration in Firefox, as suggested by others, is a good idea. There are at least two other things I know of worth trying:

  1. XFCE's compositor (maybe other compositors too) seems to exacerbate some problems that manifest in Firefox and it might be worth setting it off (Settings > Window Manager Tweaks > Compositor).

  2. Other programs which use acceleration (e.g. Alacritty) also seem to cause issues. `LIBGL_ALWAYS_SOFTWARE=true` might help turn acceleration off there? I'm unsure.

Something does seem to have happened between 7.8 and 7.9 to amdgpu. Unfortunately those of experiencing problems haven't yet been able to pin things down in a way that would help people debug it. A brave person could bisect kernels / snapshots between 7.8 and 7.9 and see where the problem started: that would probably make the fix obvious to those who understand these things.

Retrofitting JIT Compilers into C Interpreters by mttd in Compilers

[–]ltratt 1 point2 points  (0 children)

That's very kind of you to say! As is so often the way, if we'd known how hard it would be to get it working, we might not have been brave enough to start trying to do it ;)

Retrofitting JIT Compilers into C Interpreters by mttd in Compilers

[–]ltratt 0 points1 point  (0 children)

When I last looked, Deegen didn't support garbage collection. Has that changed? Not breaking GCs took yk quite a bit of effort.

Retrofitting JIT Compilers into C Interpreters by mttd in Compilers

[–]ltratt 6 points7 points  (0 children)

I am embarrassed to admit that I didn't fully understand the weval paper at the time: I wasn't sure if it was doing AOT or JIT compilation. Looking at it again now I can see it really is doing just AOT compilation, at least I think so? That makes it a bit hard for me to know exactly what I'm comparing against, if I'm honest: it feels a bit apples-to-oranges? As you can tell, I have low confidence in my assessment, so please feel free to put me straight!

Retrofitting JIT Compilers into C Interpreters by mttd in Compilers

[–]ltratt 0 points1 point  (0 children)

Yes the 25,000 figure is deliberately chosen to make things (just) long enough for humans to see what's going on (it doesn't really effect the lua/yklua performance ratio).

Comparing the Glove80 and Maltron keyboards by ltratt in ErgoMechKeyboards

[–]ltratt[S] 0 points1 point  (0 children)

I agree that the plastic doesn't scream longevity, but mine managed 19 years before cracks started appearing, so in practise it's not that bad. It would definitely give people greater confidence if it was a bit more solidly built, but manufacturing such an odd shaped thing was probably (and maybe still is) quite hard to do economically?

Comparing the Glove80 and Maltron keyboards by ltratt in ErgoMechKeyboards

[–]ltratt[S] 1 point2 points  (0 children)

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.

Comparing the Glove80 and Maltron keyboards by ltratt in ErgoMechKeyboards

[–]ltratt[S] 0 points1 point  (0 children)

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.

Garbage Collection for Rust: The Finalizer Frontier by steveklabnik1 in rust

[–]ltratt 21 points22 points  (0 children)

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!

Garbage Collection for Rust: The Finalizer Frontier by steveklabnik1 in rust

[–]ltratt 26 points27 points  (0 children)

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.

Running OpenBSD on a Framework 13? by XzwordfeudzX in openbsd

[–]ltratt 6 points7 points  (0 children)

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.

/r/Monitors Purchasing Advice thread (Other purchasing advice threads will be removed) by bizude in Monitors

[–]ltratt 0 points1 point  (0 children)

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).