dasyatidprime

GitHub disallows multiple free accounts in the TOS, meaning identity separation seemingly implies a continuous subscription cost forever. I'm not aware of any high-profile enforcement, but it's there.

Not to detract from the whole point as far as Star Trek showing its social-commentary age, but AFAIK “Code of Honor” specifically was very much an early outlier in TNG history, including starting with a director who didn't direct any other Star Trek episodes.

“manual”, “manuscript”, and “manufacture” use a different root, from Latin “manus” ~ “hand”. Handbook, handwriting, and handmade, more or less, though of course the modern compounds have somewhat different meanings from those.

STUN is not a relay, but TURN is, and STUN/TURN is a common combo for when STUN doesn't manage to holepunch reliably, falling back to the relay when the direct connection fails.

What's also true, and what I think the GP was trying to get at, is that STUN requires an external coordination server. UPnP (I think—I am far less familiar with it) does not, because in UPnP you're negotiating the holepunching with the local router directly, whereas STUN is sort of using a loophole.

That rather depends on your usage pattern, I expect. Twitter has similar inconsistent reports, and I can confirm personally that I was suddenly asked for one as soon as I tried to post anything; I believe I also had something like that happen with Discord, but I don't remember as clearly.

Not that it's necessarily malicious in intent—requiring “extra verification” only on suspected misuse isn't entirely unreasonable, and that's awfully hard to distinguish from things like targeted privacy attacks—but it would be nice to establish this sort of thing as common knowledge, especially since I imagine the chaff of “huh? no they don't” is only to their benefit.

A bit of short fiction (not mine) from 2007, on recreating experiences for those who are stuck at home: https://everything2.com/title/We+control+the+algorithms+for+....

Your comment chain has taken a bit of a strange turn, but a suitable SELinux policy would work for that, which would be straightforward… ish.

Alternatively, if you're only concerned about other privileged ports, with a systemd socket unit, you could have systemd do the binding and pass your unprivileged process the socket, so that your process no longer needs the privileged-bind capability at any time; that'd probably be the easiest way if you're willing to modify the application code a bit. If you don't like systemd, you could have another helper program do it.

Or you could put your process in its own network namespace which has a filtered bridging or routing configuration between it and whichever namespace has the ‘real’ connectivity, which is complex and awkward but allows your process to ‘think’ it has full access, which might help if the code would otherwise balk.

Or you could use various other userspace sandboxing frameworks that let you install a BPF syscall filter, which I like a lot in theory but don't currently have personal experience with.

> Reading chat logs is probably like attempting to read the transcript of your family holiday dinner. It would be nonsense. You’d have no sense of time, no sense of delay, no sense of conversational flurry, etc.

This reminds me of a private virtual event I put on a few years ago which was done entirely over real-time text. There were a few people who wanted to be there, but wound up having a time conflict, so I set up to make a recording of the event—including timestamps, and providing a way to play it back correctly timed (optionally modulated by a speed control). It seemed to get a good reception.

As far as auto-learning to counter such things, https://linuxsecurity.com/features/features/introducing-crow... did show up recently: an attempt at a crowd-data-enhanced next-gen-fail2ban-alike. (Not an endorsement, never tried it.)

I don't think it uses any of the techniques currently considered central to machine learning, but if it works well / catches on to start with then it could be a good place to see how useful those would be.

I assume you mean 6% and 14% to sum to the human consumption 20%, in the second paragraph?

Note that (a usual) Forth (here I'm centering on ANS Forth) uses early binding for most code, rather than late binding as you sound like you're talking about. The dictionary is indeed available at runtime, but runtime includes compile-time!—which is how a lot of the metaprogramming works, by interleaving the two with no strict phase separation. So it's while you're defining a word that calls other words that the other words are looked up, and not while you're executing it. This has some convenient implications for redefinitions:

    : foo ( something ) ;
    : bar 2dup foo 1+ * ; \ or whatever
    \ ... in something loaded later on ...
    : foo ( other thing entirely ) ;
    : xyzzy foo bar ; \ calls later foo, then earlier bar which calls earlier foo

… which means it's harder to run into problems with stepping on “internal” symbols even if you're using short names in the “same” dictionary. “Purely” interpreted Forth does happen at the top level, in which lookups happen just before execution, but the part of it that isn't being used for compilation tends to be small fragments to kick off execution or to enter commands interactively. (In colorForth, phase distinctions are made by color instead, but I believe it also does early-bound compilation.)

In (a usual) Lisp (here I'm centering on Common Lisp and Scheme), function and variable lookups default to late binding, but based on symbol objects rather than strings. The symbols themselves contain pointers to function objects and/or variable contents, so there's a level of indirection, but it's not a hash table lookup every time. (Indeed in CL you can have “uninterned” symbols which usually have a name but can't be looked up by that name.) Again the mapping from strings, that is, packages in CL, obarrays in Emacs Lisp, etc. generally remains available at runtime, so you can do (find-symbol "FOO"), but when processing definitions, the lookup from string to symbol happens at read time. Then in CL there's some restrictions on redefinitions (http://www.lispworks.com/documentation/HyperSpec/Body/03_bbc...) that make it easier for compilers to do more localized early binding even between top-level definitions.

Traditional BASICs I vaguely recall being closer to “fully” interpreted than this, but I haven't studied those enough to say—and I wouldn't expect that to apply to later BASIC revivals after a certain point.

An interesting other example would be Lua, which uses late binding semantics for global and method lookups, and then (here I'm thinking of the mainline PUC implementation) makes them faster by interning all strings at the C level, in a way which isn't exposed to the Lua level. When all strings with the same contents have the same pointer, string equality is very cheap, which makes table lookups over the string objects cheap. But lexical locals are compiled into index lookups, which are even cheaper, and it's often considered good practice to write internal file-level definitions as locals, import external module tables as locals, etc. so in practice once again some of the late binding disappears along the way.

There've been a few times I've used checked exceptions very locally in Java where I did use a type parameter successfully for this—though it's not really threaded through the type signatures in the standard libraries, so interop can be a problem. Almost like what you wrote, of course more verbosely, something like:

    interface SomeProcessor<E> {
        void process(Thing thing) throws E;
    }

    <E> void processThingsSomehow(
        SomeProcessor<E> processor,
        Container<Thing> things,
        Parameter how) throws E {
        // ... {
            processor.process(extractedThing);
        // } ...
    }

and then later:

    void processOrFail(Thing thing)
        throws SomeCheckedException {
        // ...
    }

    void processOurThings() {
        try {
            someObject.processThingsSomehow(
                this::processOrFail,
                getThings(), HOW);
        } catch (SomeCheckedException e) {
            // ...
        }
    }

and it definitely worked the way I expected—if the correct exceptions weren't caught in processOurThings, it wouldn't compile, and processThingsSomehow did not have to catch them. It even worked in at least some cases with multiple throws on the concrete SomeProcessor, though I think the different exceptions involved had an upper type bound within the package; I don't know how well that's handled in the general case.

I'm usually in favor of conciseness for one or two type parameters (much less so for any more than that), but if you do go full-words, “Value” is not much more descriptive than “T”, like writing “argument” instead of “x” for not much benefit. “Element” would be more descriptive of the role of the type parameter relative to the List type.

I dunno, “it doesn't have to be that way” is very contextual. I think the peak group coherence and idea integration available in physical proximity is probably considerably above the peak available with current-day telecommunications (and current-day social/psychological technologies/practices surrounding it). But of course most groups won't be able to reach either peak, and the peaks for particular individuals or groups may be reversed from that, or there may be other factors that reverse them. (For instance, being able to more legibly put effort into communication practices with the excuse of “we need to relearn to work together because remote”, even if doing the same thing while in proximity would have had even better effects—and not necessarily because of external pressure, since the same emotive mechanic can operate within the group.)

Note that the optional version of this works fine, but the more sites hide a requirement this way, the more users are justified in assuming that anything they do on a new site may shove random things in their way and get fatigued on doing so entirely except in places they already know. Save the trust environment!

And sometimes you were one all along, and you didn't know, and they also didn't know enough to recognize the warning signs until they'd already gotten entangled with you. Now you're about to gradually lose everyone as they realize how much of a drain you're being and quietly shut you out.

Which connects up, in the sense that you stereotypically care less in a way that you consciously notice because you gradually internalize the culture strongly enough for it to just feel like “the way things are”, and then in old age you impute upon yourself (and/or society imputes upon you) a position of sufficient immunity that you can keep saying “the kids are wrong” even as they're about to displace you.

It's worth remembering that a large amount of the reason that's impractical is because society shifts to expect the new thing. In turn, part of the reason society gets to expect the new thing much more instantly nowadays is because past new things started including “always the newest by default”, so it became an active choice to want to keep anything around or not instantly change your behavior to match. I'm not sure how much of this is ‘actual’ values versus power conflicts versus broken equilibria though I know at least one influence was the rolling infosecpocalypse.

There's a post elsewhere on “The Amish, and Strategic Norms around Technology” which has some not-bad short description of ways this isn't universal, and potential for application to current-day (potentially America-centric, etc.) society, without going into too much depth: https://www.lesswrong.com/posts/36Dhz325MZNq3Cs6B/the-amish-...

The last part is sort of true, but there's a lot of ways for changing expectations to sneak in. The software often isn't designed for it, so it's hard to model what actions you can take and what you can't before “oops, please connect to the Internet to continue”. And once you've done that a single time, all your previous guarantees are instantly invalidated, because there's going to be a dozen unskippable updates and stuff happening in the background and so on and so on—or you can try to handle that by doing something even more awkward like moving the data off, then factory reset, then updates, then disconnect, then move the data back and hope for the best…

That said, this is something I did with a cheap laptop for a while—installed a basic Linux and Emacs and used it as a mostly-isolated Emacsing machine; I believe I never hooked it up to the network again, though I did sketch out some provisions for manually physically disconnecting sensitive filesystems in case I needed to do that very occasionally (while being aware that sufficiently clever malware could still work around this). But then the logic board malfunctioned much sooner than I'd expected, and I haven't been in a position to get another since.

And 100% air-gapping is not always desirable. Many 1990s-and-before machines that had networking capabilities were still the epitome of “local first” by comparison to the “deployment is primarily done through progressive Web apps” world of 2021. So you could have a few channels by which to talk to the outside world, but without the outside world getting its hooks deep inside you in the process: the television without the telescreen. (Security issues aside, of course—though some of that is mitigable with restrictive proxying, simpler protocols, etc. depending on how retro and how networked you are trying for.)

Me, but I'm not sure I count because it's more of a theoretical interest than a practical one at present.

Past me, however, did things like write an OTP generator for TI-83+ partly on the grounds that it was a non-networked device and simple enough to leave less in the way of interesting ways for malware to hide.

Something I've been trying to polish which seems worth saying in this context: Physical property is like control over address space. Copyright is like control over strings. Patents are like control over algorithms. But fixed-endpoint SaaSS… is like control over types.

A per-post bearer token either input or generated at post time is a pretty straightforward way of doing this. The former would be similar to a temporary password; imageboard-style tripcodes use a similar mechanism for a different purpose (having awkward-to-forge “same author” marks in otherwise-unauthenticated posts by showing a hash of the display name + tripcode).

Not round-tripping prefixes breaks other things, and this is around where I start more thoroughly agreeing that XML namespaces tried to do too much at once: mainly, there are XML-based definitions, I think including XPath and XSLT's use of it (or old XSLT's use of what might not have been XPath yet?), that use the ambient namespace prefix set as context for interpreting attribute values that contain XML names. If you might ever interchange some prefixes, you might even get similar “looks valid but means the wrong thing” problems.

And if you try to combine namespaces with DTDs (which is just an explosive mix to start with, and I think is just recommended to never do) you get other problems, because you're no longer allowed to add arbitrary namespace declarations in the middle, so anything that round-trips prefixes but might ever add redundant declarations of them won't reliably produce something that DTD-validates, and if you're transforming into a DTD from something that might have used other namespaces, you have to make sure to remove all the extra declarations, and…

Note that most of this is still “well-defined”, it's just awkwardly hairy. This is not to be taken as an excuse to implement the standard badly or incorrectly if you're going to handle it at all.

To add to this with some (potentially out-of-date!) personal experience: sometime around 2008, now somewhere in my dusty directories, I started implementing my own Ruby XML DOM-like library (based on the Parsifal XML lexer in C) mainly to handle this properly, because the most “normal” REXML did something really horrible in its API for namespaced attributes that made them almost unusable by clients of the library. (I forget why I couldn't use the Ruby bindings to libxml2 at the time; I think maybe they didn't support several things I wanted to do, and I couldn't add them without patching and vendoring libxml2, and that would be its own disaster because of shared libraries, etc.) Specifically, attribute accesses didn't always work consistently with namespaces, the callers had to handle prefix management themselves in places, and looping over the attributes of an element required you to handle both “single” attributes and sub-collections of namespaced attributes if there were any qualified and unqualified attributes with the same short name, because the second was what the outer collection was indexed by…

(I originally wrote this comment with a more fully worked-out example, but after viewing it in context I realized it was way too long to be an only-partly-on-topic comment on this thread, so I'll probably move it to a post elsewhere and submit it later.)

In other words, the minds of a large number of human specifiers and implementors have their own roundtrip corruption flaws where when you pass the XML namespaces specification through them, you get something out that's incoherent and doesn't interoperate properly, creating representation mismatch problems down the line back in the digital world.

Those who make the world smaller by drawing it toward them (and especially who profit from it) wind up at the epicenter of the resultant territory war.

Second additional thought: if you need strong unguessability, you could probably tack it onto that scheme by adding a second column that isn't indexed, but only used as a bearer-token-like add-on to the ID. So the index lookup only happens on the (unscrambled) first part, but the access is aborted if the second part doesn't match.

You don't store the scrambled key, you store the sequential-looking key and expose the scrambled key externally. That avoids things like easy key-sequence probing/inference from the outside, but means you don't take the hit of an index with random-looking keys.

I've done something similar for weakly-secured spendable tokens in the past, packing some orderly lookup state into 64 bits and then exposing the Speck64/32. That application was actually backed by an object-array sort of storage with numeric indices, so I stored something like object ID, timestamp, and sequence number, and then looked up the right property on the object at validation time. (If I needed strongly-in-the-crypto-sense unguessable IDs for security, I wouldn't do this without doing more research/analysis, since a database-wide key feels like it could be a weak point; compare how peppering is used for password storage in conjunction with salting but not as a replacement. Someone else probably already knows that answer.)

(Edit to add cross-reference: ah, looks like tmpyt in another comment claims that YouTube used to do this but then switched away because of the “knowing the small key lets you enumerate everything” loophole.)

I haven't looked at QEMU's TCG much, but I doubt it would be a good choice for bytecode formats even if you could bash it into doing something useful as part of a backend. I'd expect it to be optimized for hardware-CPU-alike machine instructions, whereas BEAM is Bogdan's Erlang Abstract Machine. See https://blog.erlang.org/a-brief-BEAM-primer/ which points to https://github.com/erlang/otp/blob/master/lib/compiler/src/g.... If you look into how some of those are implemented, just as one example, the integer arithmetic operations handle automatic promotion to bignums—not something you'd find on a conventional CPU, but not uncommon in HLL bytecode. So you'd still have most of the implementation to do—and if you punt and hardwire all of those to runtime library calls, you're almost back in threaded-code land anyway; you really want to take specialization opportunities etc. into account…

I also don't know of any other HLL JITs that use TCG, which seems like weak evidence that it wouldn't be a win.

QEMU in fact does dynamic translation, which is more like how JIT works in bytecode languages; this is why it's much faster than some earlier machine emulator software. (I think e.g. Bochs didn't have dynamic translation back when QEMU was coming into play, but the Web suggests that there's at least discussion around that feature so maybe that's not true anymore.)

The BEAM is currently a bytecode interpreter. The article describes it as using threaded code, which if you look at the C source is true in a sense on platforms where the C compiler provides the GNU-style extension of being able to take the address of labels for dynamic `goto` (https://stenmans.org/happi_blog/?p=194 agrees with my skim of `beam_emu.c`)—though if that's the only use as it seems, I might find that an edge case of the term, since I associate “threaded code” with the style used in Forth where “user-level” subroutines can be pointed to directly. If computed `goto` isn't available, then it uses a conventional switch/case loop, repeatedly dispatching the result of fetching the next bytecode instruction pointer value.