dasyatidprime

The results don't exactly match your description, but a cloud-run self in which multiple plans are available and in which the implications of copyright enforcement and advertising-supported options figure prominently was depicted in the short video “Welcome to Life: the singularity, ruined by lawyers” on Tom Scott's channel. https://www.youtube.com/watch?v=IFe9wiDfb0E

“overlooks” doesn't seem right to me. He states within the first few paragraphs:

> It's obviously true that the returns for performance are superlinear in business. Some think this is a flaw of capitalism, and that if we changed the rules it would stop being true. But superlinear returns for performance are a feature of the world, not an artifact of rules we've invented.

You say “conventions” rather than “capitalism” here, but without more details it seems like you're targeting substantially the same distinction re social determination. So it sounds more like you disagree with him about that statement than that he just didn't take it into account.

The latter and definitely not the former, in my case. As far as I can tell from internal experience, my automatic procedural memory of where to reach for a character, function, or string transforms along with the layout I currently have it “configured” to use, in a rough mirror of how scancode↔keysym mapping can vary on the OS side. I have used a non-QWERTY layout full time for about 18 months now after being in mostly-QWERTY before, so my QWERTY memory has decayed somewhat, but I have past experience switching back and forth at a time scale of hours. If I want the eyedropper tool in GIMP, I reach for the O, and there isn't a separate conscious step of “okay, so that's O, right?”, it's just a single compound action. If it has to be the O in some other layout than the one I'm using, then I have to stop myself and consciously try to remember where it would be. The tools that I don't use as much I do also have to stop and remember, but that's very distinct in feel.

I wonder sometimes whether it's relevant that I'm a heavy Emacs user, in which short command gestures often include non-modified keys and are conceptually close to the physically more text-based M-x invocations. Maybe that type of experience (or what other types? Maybe CLI?) creates a different mental map of the distinction or lack thereof between text entry and shortcut keymaps. Emacs on Windows is especially awkward for me as a result of the QWERTY-on-Control behavior, because e.g. C-x C-t and C-x t now involve different positions for the T. Or maybe people who start out on non-QWERTY layouts on Windows specifically are pushed to remember shortcuts by their location early because the keysyms are illogical, and then they continue doing that, but people who stay on QWERTY all the time could go either way?

As others have mentioned, this also doesn't happen as much in gaming, where commands are often bound positionally, with WASD motion (GAST motion in my layout…) as a central example. There's still some expected-keysym mnemonic influence in which of multiple candidate keys to bind to a function as one moves away from the central motion cluster. The vi keys mentioned elsewhere are also very positional in nature, but I rarely use vi bindings, and when I do, the nav-cluster keys are usually an accepted alternative…

Gosh. With how much has wound up in this thread, I kind of wonder whether there's more serious ergonomics research on this difference in mental modeling now.

That's the same thing I was getting at, yes. When I said “KEY_Q in the header file”, I was referring to the #define that attaches it to a number (edit to clarify: in linux/input-event-codes.h, specifically, which seems most likely to be the source of calling these KEY_* in the context of a Wayland compositor) and pointing out how it doesn't actually map to the conceptual Q, and that's why I mentioned scancodes specifically. Keysyms are indeed a separate layer, and I agree that users expecting to be able to configure on keysyms and being given the QWERTY-derived scancode mapping instead is confusing.

This is contrary to my understanding of mainstream keyboard technology. Scancodes, like what you're looking at with Linux input, mainly refer to physical positions relative to a “standard” keyboard, and the labels in the header file for the alphabetic section are based on assuming the keyboard is QWERTY. A keyboard that comes from the manufacturer with different-layout keycaps on it will still output physical-position-based scancodes, and KEY_Q in the header file is not normally generated by the key that the manufacturer shipped a cap labeled Q on; it's the key in the position that would output Q if it were a QWERTY keyboard. (Though there's a few edge cases around e.g. ANSI vs ISO layout.)

This idea is corroborated if you look in the USB HID Usage Tables that the Linux input event codes are based on. From https://usb.org/document-library/hid-usage-tables-14:

> Note: A general note on Usages and languages: Due to the variation of keyboards from language to language, it is not feasible to specify exact key mappings for every language. Where this list is not specific for a key function in a language, the closest equivalent key position should be used, so that a keyboard may be modified for a different language by simply printing different keycaps. One example is the Y key on a North American keyboard. In Germany this is typically Z. Rather than changing the keyboard firmware to put the Z Usage into that place in the descriptor list, the vendor should use the Y Usage on both the North American and German keyboards. This continues to be the existing practice in the industry, in order to minimize the number of changes to the electronics to accommodate other languages.

This can get somewhat more complicated when you get into keyboards with custom remapping firmware where they do actually shift the scancodes around, but that creates other potential issues, and users who are doing that basically just have to deal with their own integration tradeoffs. Similar considerations apply to keyboards with non-mainstream physical layouts.

As another non-QWERTY user, I usually want desktop keybindings (excluding games) to follow layout changes, because I'm remembering the function by the mnemonic. Most applications have this behavior on my existing FDO/Linux system. On the Windows machine I use sometimes, by contrast, it seems like holding Control effectively forces QWERTY, which has been an unending source of little pains. If I didn't already have the QWERTY keymap memorized and I had to figure out which keys were “actually” which to configure things, it would be a lot harder.

But then, I'm an X user still; I'd like to dip into Wayland, but a combination of fragmentation of protocols and the seeming relative “hardness” of the stack in terms of customizability have caused me to hesitate thus far. And maybe that Windows behavior also means that's what you want to mimic for a lot of other people?

I broadly agree with the lots-of-pitfalls nature, but regarding the enum case specifically, which version of C++ are you talking about, and in what syntactic context? The later-introduced “enum class” makes things somewhat tighter than C-style enums.

You want https://github.com/zevv/bucklespring then.

Lagniappe: “To temporarily silence bucklespring, for example to enter secrets, press ScrollLock twice”

And if the senders are mostly within the US military and are thus resolving that domain through their infrastructure, changing the outgoing domain resolution configuration for the mail servers may be able to help with this.

There's a third vertex to the triangle here: C++ and Rust allow both at the same time by dropping separate compilation. More thoroughly so in Rust than in C++, but header-focused libraries move C++ further toward whole-program compilation compared to C (maybe you could call it “large-overlapping-chunks-of-program compilation”).

Yes, but it doesn't support HTTPS (properly).

It's possible to use a type parameter in a throws clause in Java, last I checked (as I also mentioned in more detail above). But it doesn't seem to be common practice, so interop is still a disaster.

> How are you going to write generic functions that take functions as arguments and re-throw the errors thrown by these functions, if you use checked exceptions?

I've actually done this with an interface type parameter used in a throws clause in Java before, but I'm not sure how it interacts with module boundaries, it's kind of verbose, and it certainly didn't seem to be common practice. But it did work: the HOF-ish method that took a parameterized ThingFrobber<E> and used it to frob things unchecked would compile only if it also threw E, and the method passing the HOF a ThingFrobber (I think via lambda syntax) could catch the associated concrete checked exception type to sink it. IIRC I was using it to allow a checked early exit from a complex iteration, and it even propagated a slightly complex bound with multiple checked exception types more smoothly than I'd expected it to.

Do you currently pay for much or any of the libre software you use? Of course many published libre software packages have no workable monetization scheme attached, but many of them have a facility for donations, and then there are major foundations and aggregators (of which I regrettably do not have a good list compiled at the moment).

So what would be different between those and forked processes?

Do they still have the “in case of problems, you might be asked to supply a local postal address for communication” sort of thing that got introduced a bit over a decade ago? (I forget the details and am not in a position to recheck right now.)

That can decay to ~zero from a career-agency standpoint though if it's not the limiting reagent for professional access to the next level—that is, if the assignments you can get next all include the same thing at the same speed regardless of whether you also learn it independently or not.

I believe you mean “hash functions are not injective”.

Incidentally, this is nearly identical on top to the pattern Erlang uses for the same reason, where most processes couple a long-lived “behavior” with a callback module with a particular structure and a pure-data state value threaded through everything. When the module is replaced, the new functions are picked up automatically, and there's also a callback for adjusting the state information on code changes if need be.

The underlying “system message requesting your process to ensure it picks up the code reload” part is quite different, though!

The domain seems to have been picked up as a false positive for spam/malware in places. They were blocked by Quad9 too due to one of their underlying data sources (I forget which), but they were unblocked after I submitted a false positive report.

For anyone who doesn't want to follow the link, the practical gist in that case is indeed that LuaJIT wins and they don't care about later Luas. (Edited somewhat for wording post facto.)

Side question for all of you who are saying “the Lua language is very stable”: do you mean you're staying on Lua 5.1/5.2? If so, is this driven by LuaJIT essentially freezing everything in place by grabbing so many users and libraries off the PUC-Rio implementation? If not, what counts as stable to you? Lua 5.3 and 5.4 both have dialect incompatibilities with prior versions.

See also both Windows 3.1 and the “DOS extenders” used to build applications that were launched from DOS but ran in protected mode with additional facilities.

The non-response to SIGINT makes it a more serious impediment if you get it wrong in a tight situation, though. It's not like a short joke message or something. (Yes, I know you can SIGQUIT instead.)

I can't speak in detail to whether it'd work or be a good idea, but there has been an attempt to design a fraud-resistant carbon capture coin. https://www.gwern.net/CO2-Coin

A scenario much like what you describe has sometimes been discussed by someone who did wind up moving their writing efforts to Substack later on:

> HL Mencken once said that “the trouble with fighting for human freedom is that one spends most of one’s time defending scoundrels. For it is against scoundrels that oppressive laws are first aimed, and oppression must be stopped at the beginning if it is to be stopped at all.”

> There’s an unfortunate corollary to this, which is that if you try to create a libertarian paradise, you will attract three deeply virtuous people with a strong committment to the principle of universal freedom, plus millions of scoundrels. Declare that you’re going to stop holding witch hunts, and your coalition is certain to include more than its share of witches.

> So while some small percent of Reddit’s average users moved over, a very large percent of its witches did. Sometimes the witchcraft was nothing worse than questioning Reddit’s political consensus. Other times, it was harassment, hate groups, and creepy porn.

https://slatestarcodex.com/2015/07/22/freedom-on-the-central...

And anyone without one is then nobody.

For the boolean case, yes.

But note also that an Emacs instance can open frames on multiple displays. This is not necessarily that hard to get if, for instance, you start with some X frames and then invoke emacsclient in a terminal in a way that causes it to open a character-cell frame there. window-system is documented as a terminal-local variable for this reason, and similarly the display-foo-p functions take an optional selector argument.

Which means that if you care about that, querying any of those once from your init file will not necessarily do what you want, and you should consider attaching to something like after-make-frame-functions. The global menu-bar-mode explicitly states that it applies to all current and future frames, too; toggle-menu-bar-mode-from-frame seems to be the per-frame version.

But if it's just cosmetic and you don't care about some variance in that case, then whatever. :-)

I'm not seeing from the error message how that qualifies as a glibc symbol compat issue as such. On the face of it, it looks like the application is vendoring its own libm rather than using the system glibc's libm, and then it tries to load other system libraries which expect to load the newer system libm and instead find an older one.

If my interpretation is correct, then if it's going to load system libraries, those may require system glibc, and if it's going to use system glibc, it should use all system glibc rather than trying to mix and match.

Thus ‘GAFAM’, though I've more commonly seen that one in the francophone world.