Shameless plug: Some of my hobby projects written in C (e.g. https://github.com/pts/bakefat) can be built reproducibly for Linux >=1.0 (1994), FreeBSD (same ELF executable program file as for Linux) and Win32 working on all versions of Windows (Windows NT 3.1 (1993)--Windows 11). The C compiler (running on Linux i386 and amd64 host) used for the release build is self-contained and included in the project, along with the libc.

Doing such backward compatibility is definitiely possible for command-line tools. Once set up, it's automatic, and it needs extra testing after major changes.

If a text-mode process monitor is larger than about 200 KiB, then it sounds bloated to me. If it's loaded with tons of features, then my upper limit is 1 MiB.

This video doesn't explain what the project does and how it does it. Also it's deliberately misleading the viewer, for example it purposefully incorrectly states that C++ is an interpreted language.

Also the music is way is too loud and sudden.

The video is a compliment to the Github repository, the presenter even shows code and brings up the repo in the video. I guess you didn't watch that part and unfortunately you didn't get the joke either.

Well the video is almost entirely a joke and almost every sentence in it is ironically false; that's the point.

This should have been solved in the last 30 years on Linux console, X terminal emulators and through SSH.

It's more of a "just in case" thing for the most part... the actual risk of an escape as part of a sequence showing up over TCP without the rest for over a fraction of a second today is highly unlikely. That said, so many systems seem to add a delay well over half a second like we're using dialup.

I'd probably tune the delay to 100-200ms if I ever really felt it and have the option to change it.

The kitty key protocol solves this, but your app and terminal need to support it. Many do.

The correct spelling is in lowercase: shared_ptr<T> . The title of the article is correct, the title of the HN post is incorrect.

In hindsight this convention seems weird to me by the way. I didn't question it for the decades I was paid money to write C, but after adopting Rust it jumped out more that it's weird how monocase the C and C++ standard libraries are.

Maybe there's a reason I'd never run into, but this seems like a missed opportunity. Even if I have no idea what Goose is, I can see it's a type, that seems like a win.

Yeah I don't know why so many C programmers ended up on a convention where case is entirely unused. I wonder if it's some ancient compatability thing that they have just been keeping self-consistent with forever. To me not using case is like designing a road map in black-and-white just because you didn't have any ideas for what colors should represent.

I believe HN does that automatically.

How is Areal different from Arial? Neither the article nor https://are.al.are.na/ seem to be informative and focused on this.

https://are.al.are.na/ does include some information on what they changed after tracing the original.

Might as well just quote the one single sentence that gives any specific details:

> Stem thicknesses were streamlined, more characters added, a monospace version drawn, dark mode functionality optimized.

I find this style overy verbose, disrepectful, offensive and dumb. (See example dialogue in the screenshot on the project page.) Fortunately, it's possible to change the prompt above.

I find it hilarious and it made my day.

Half of the source code is colored very-light-on-white, which is impossible to read. I'm using Chrome on Android.

Interesting, and thanks; that's not how it's supposed to look for sure. I'll ask someone to look at the whole mobile experience, definitely not my area.

Supporting arbitrary image formats and compression methods in the browser is easy: just ship the decoder as a WebAssembly function.

(This is not any better solution than GIF or aPNG though for the problem in the article.)

Where are the benchmarks comparing hyperpb to other proto parsers?