If whoever wrote this wants to add an authentic (and somewhat period correct) terminal front-end, I wrote a VT420 hardware emulator that works in the browser and we can wire them together!

https://mmastrac.github.io/blaze/

(the API is undocumented but stupidly simple: an async js_read() function and a sync js_write() function)

You'll want VT-52 for this era.

More like the VT-05. The VT-52 came a few years later. But yeah, the VT-420 is way later.

Fun fact: The VT-52 didn't have a loudspeaker for the bell sound. Instead, it had a electromechanical relay which was set up to self-oscillate.

"Typing a character produced a noise by activating a relay. The relay was also used as a buzzer to sound the bell character, producing a sound that "has been compared to the sound of a '52 Chevy stripping its gears."

YouTube has the sound: https://www.youtube.com/watch?v=bAafRXddfxc

Thanks, I remember it being much louder when I used it in the 80's. Made me jump out of the chair the first time I heard it.

I wrote a VT52 hardware simulation: https://github.com/larsbrinkhoff/terminal-simulator

I used Miri for some key deno libraries and spent a fair bit of time cleaning up the violations. Many of them were real unsoundness bugs due to reference aliasing.

Unsafe code absolutely needs Miri if the code paths are testable. If not all code is Miri-compatible, it's worth restructuring it so you can Miri test as much as possible.

Note that Miri, Valgrid and the LLVM sanitizers all compliment each other and it's really worth adding all of them to a project if you can.

I did a huge chunk of work to split deno_core from deno a few years back and TBH I don't blame you from moving to raw rusty_v8. There was a _lot_ of legacy code in deno_core that was challenging to remove because touching a lot of the code would break random downstream tests in deno constantly.

Thanks for that work! deno_core is a beautiful piece of work and is still an option for OpenWorkers: https://github.com/openworkers/openworkers-runtime-deno

  We maintained it until we introduced bindings — at that point, we wanted more fine-grained control over the runtime internals, so we moved to raw rusty_v8 to iterate faster. We'll probably circle back and add the missing pieces to the deno runtime at some point.

Officially? You can't get a license.

Unofficially? https://github.com/kholia/OSX-KVM

I've been trying to do something similar to set up Windows VMs with developer tools. This would be awesome if there was a way to inject a `ps1` script where we could go through the awkwardness of installing choco and various dev tools.

For anyone interested, the magic incantation in the autoattend.xml is:

    <settings pass="specialize">
    <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
        <RunSynchronous>
        <RunSynchronousCommand wcm:action="add">
            <Order>1</Order>
            <Path>cmd /c powershell.exe -ExecutionPolicy Bypass -File A:\scripts\setup-dev.ps1 &gt; \\.\COM1</Path>
            <Description>Run dev setup script</Description>
        </RunSynchronousCommand>
        </RunSynchronous>
    </component>
    </settings>

Redirecting to COM1 is a fun hack I discovered that allows you to remotely monitor these from build scripts.

Even better would be figuring out how to slipstream the choco packages into the ISO - it's not super reliable to install these packages in my recent experience.

https://boxstarter.org has been working on this for a long time and might have some useful ideas.

I wrote https://github.com/mmastrac/clitest because I needed a more complex testing harness for CLI tests that does something similar. It's not exactly the same, but it's definitely in the same universe.

One-file-per testcase like `tc` does works, but it tends to fall apart a bit at large scale in my experience.

I was not a fan when I first saw it but I'm becoming desperate to have it the more Rust I write.

Why new syntax? We could have:

   let &p = &x.field;

Or

   let &mut p = &mut x.field;

I use it daily on mobile and desktop and... this never happens (maybe once a year at most?)? The only thing that breaks pages is the adblocker and things work again when refreshing.

No adblocker on Firefox Focus.

"Why" is redundant. If the article is stating premise "X" and it's on the front page (assuming it's not newsworthy enough that "X" is novel and worth discussion), it's obviously going to explain "Why X" and "X" is sufficient.

Is that actually the rationale, or are you guessing? It seems weak, if true, since:

- An article reporting X does not or can not necessarily always explain why X.

- Removing "Why" can (and does) destroy some titles, and submitters aren't always going to notice it was changed under their nose and fix it before submitting (or they will consciously trust the bad change, if they are not themselves an experienced reader of the language).

- Removing "why" doesn't seem to have any impact aside from saving a tiny bit of space and a tiny bit of annoyance for the small subset of people who are opinionated writers and dislike seeing the "why" trope in the cases when it is truly unnecessary.

It's not like we're talking about the "You won't believe why..." trope. Then I could understand.

it's the norm that article talks about why and how.

- If article "I have to give Fortnite my passport to use Bluesky" does not explain why and how then it's a bad article not worth sharing on HN anyway

- "Why", "how" is clickbait. It's the "You won't believe how" intensificator but for thinking geeks. The real topic is always what happens after. unless it's an actual question quoted in title, in that 1% of cases it can be edited in.

But why does HN feel it's necessary to editorialize titles like that? My browsing experience isn't any better because HN decided to strip out the "why", and I've seen multiple situations in the past where the auto editing of titles here actually resulted in a title that made zero sense.

Lots of posts on HN state the fact "X" is happening and are searching for help to find the reason or just conveying a story. "Why" in the title tells people the author knows the reason and is going to explain it in the post.

"Why" only adds clarity. What is the advantage of removing it?

"Why" and "how" is clickbait hooks. The point is always what is after

People on HN hold very odd opinions near and dear to their hearts. Minor variances in a article title being one of them.

They internalize title heuristics because of who they perceive is the author of the heuristics.

I honestly have no idea what you're trying to say. HN users mimic other HN posters they find credible?

"You can tell the kind of person by how they write"

You can tell the kind of person by what they write.