gnubison

Are you sure? My impression from e.g. https://stackoverflow.com/questions/13210239/can-a-c-compile... is that it’s alright to cast between a pointer to a struct and a pointer to its first member.

Searching google for "toki pona dictionary online", in an incognito tab, brings up three dictionaries. One of them (the one on zrajm.github.io) is identical to the one in the book. You can also find a copy in the Toki Pona discord server. I have prepared a PDF version (1 page double-sided, a4 paper) which can be found here: http://0x0.st/ofqt.pdf from this groff input file: http://0x0.st/ofqv.roff (also by me).

Or something like

    printf '%s\n' '/pam_smartcard\.so/a' 'auth sufficient pam_tid.so' . wq | sudo ex -s /etc/pam.d/sudo

The dictionary is released into the public domain :)

I agree with the core idea of this, but have you personally watched 3B1B? It feels to me like a largely isolated case, and I hope “remote learning” does not become the norm, but … it is really amazing.

> The VI keyboard shortcuts only make logical sense on a specific Tektronix 4014 terminal that was popular at the time: 46 years ago.

vi is more than hjkl, and those four non-mnemonic keybindings make up for it by being extremely easy to press for QWERTY users. The vast majority of other commands are perfectly “reasonable” (easy to memorize and not dependent on any antiquated hardware) — append, backward word, change, delete, end of word, find letter, go to (OK, this one is just an arbitrary prefix), and so forth.

Not sure how my comment is “exactly backwards” — it’s logically consistent with your (new) comment. My point was that, relative to you, ye makes a case distinction (nominative), and that relative to you, thou makes a number distinction (glossing over formal/informal).

We deprecated ye and thou, but it’s the latter that “requires” y’all, because only thou (relative to us still having you) distinguishes the number of people.

Edit: put another way, “thou/thee is the one with number” meant that reintroducing them would create a number distinction.

“Ye” is just the nominative case (like “I” vs. “me” being accusative), it has nothing to do with number. Thou/thee is the one with number.

It’s nice if you would prefer to use a custom allocator, or put small buffers on the stack. But yeah, it is more annoying to use.

They’re in wikitext, which looks to be considerably less semantic than the crawled data. I’m not sure that’s the reason, but it could be a reason.

> P.S. Now that I think of it, ssh implementations have to "sync" local and remote tty parameters or at least make it look sane for the user

Hadn’t thought about this before, but I think only window size needs to be synced (maybe baud rate and parity? I really have no idea how those would work)

> if you resize your local xterm, arguably the remote e.g. vi should get notified, but what if it's the remote process that changes the terminal dimensions, should your local xterm get resized as a result?

Huh, TIL processes other than the pty master (the terminal emulator usually) can change window size. Glad I checked my sources before writing off a comment …

Note that, although bash handles this case, the terminal never interprets ^C or backspace or ^U or anything like that. That’s all in the tty driver — see OpenBSD’s termios(4) for information on how to configure it.

In general, “smart” programs like bash or vi or fzf or readline configure the termios state so that the tty driver doesn’t handle any keys. This gives them more control. When they exit, they restore the termios to the original state, so that you can still backspace in dumb programs like cat and grep.

So you might have a dance like this when you run vi:

- bash restores its saved termios, so that whatever program it’s running starts with a blank slate

- vi saves the original termios

- vi switches the termios into “raw mode” (simplification)

- you edit text …

- vi switches back to the state it saved

- vi exits

- bash saves the termios state

- bash switches to raw mode

My guess: The ssh client on your local end receives a 0x03 byte directly from the terminal, because it has disabled ICANON and ISIG and whatnot, and forwards it to the remote connection. The remote sshd then feeds the 0x03 byte to the pseudoterminal it has setup, and then the (remote) kernel may or may not interpret that as SIGINT. For example, ISIG could be disabled (“stty -isig”) or it might be a different key (e.g. “stty intr '^X'”, as mentioned elsewhere in this thread).

Your setup fails to distinguish keyboard interrupts (intended for the remote machine) and real SIGINTs generated by kill(1). It also uses the local termios(4) settings instead of the remote ones.

And, more importantly, for programs like vi and Emacs that want to handle rendering themselves.

Closer to toggling in the case of ^?.

More importantly, how do you know whether the keystrokes should be displayed at all? For example, take vi. When it starts up, it sets cc.c_lflag &= ~ECHO (basically like “stty -echo”) so that normal mode commands aren’t printed onscreen. The kernel knows whether ECHO is set, which is why it handles echoing.

Perhaps those movies are next :) … and it seems to me you could make this argument about any positive action, if you wanted.

I think fish is the outlier here, not the norm. It’s specified in POSIX and most non-POSIX shells like zsh and rc support it.

From another perspective it’s more regular that position doesn’t matter. (This behavior works in all POSIX shells, zsh, rc, etc. But not fish :p)

‘<file.txt blah’ works just fine.

Or <file cmd, to preserve the order.

OpenBSD pledges aren’t normally used for child processes, they’re more for “okay this program has super well-defined needs, let’s make sure (in its own source code) that it won’t be able to do anything else”. So a wrapper program wouldn’t really be normal usage.

> YouTube videos that now always start with a ~5 seconds extract which spoils the entire video

I vastly prefer this to the kind of “informational” video that’s designed to keep you watching a 10 minute video for the 10 second answer

I’d say it’s a kind of idiomatic phrase (?) — “great reads” where a “read” is a “thing to read” (like one could use “read” in “comfort read”). In other words:

language

GP isn’t arguing for “we should behave like animals”, they are just using it to show inconsistencies in GGP’s argument.

In what way? Ed is interactive so you’d be able to act out your script line by line and check for mistakes, which seems easier to me. If you’re cognizant about the differences between ed and ex, you could even debug with vi.

Except for when it breaks on FreeBSD or macOS. The most portable utility nowadays for desktop systems is ex, actually (because some Linux distros don’t include ed).

… but it doesn’t matter if the client is compromised, because all it would hurt is the user, right? If the client was compromised, it could just not send anything to your servers, or ignore the results, or …

> the only downside to the tildeverse is if you're not woke they kick you out.

Heh?

> That is all I’m hearing As alien as it might be to you to not use Rust or Go or Python, people really do write C because they like it — and they are aware of “system instability” usually :) This argument just makes its users seem worse off for projecting their righteousness onto other peoples’ personal choices.