dasyatidprime

The front page is giving me an inconsistent idea of whether this has somehow supplanted the other strawpoll thread, so I'll just point to my comments there (https://news.ycombinator.com/item?id=25098076) and note that the second one involves me trying to ramp into accepting little code commissions as part of trying to stabilize (nudge me at profile email if you want to, low-effort one-liners accepted).

I don't think it rules out the quitting Twitter as a factor as such? A few weeks of response lag as conditioning/expectations gradually recognize the new normal seems likely enough to me.

For basic-level exercise in the form of “walking around outside a lot”, I've been playing Happy Surveillance Pets aka Pokémon GO—as hypocritical as it sort of is with my software philosophy leanings. May not work if your version of “outside” is either too far away from civilization for the shared AR part to work or too high-risk to be going out in a lot (I live in a medium-density area of city, which seems roughly ideal).

I was able to keep up some ad-hoc home bodyweight exercises with Habitica (gamified habits) + Forest (pomodoro-ish app) earlier in the year, but that fell apart a few months later when the depression got worse, and I haven't managed to pick it up again yet.

Speaking of which:

I don't normally post things like this out of the blue, but if anyone has small software things they might be willing to commission me for within the next few-to-several months where turnaround time isn't “right now”, that could help a lot, so don't hesitate to poke me at my profile email address, low-effort one-liners accepted. (I have a partial source of work lined up for once I can focus again, but it's fraught in its own ways.)

My most native domain is oldish/systemsish/Unixish (Go, C, shell scripting, Perl…) but I can be fairly polyvalent in environments overall. Have done some previous work on things like Tor and OpenVPN. Ideal is something like “this bug/feature-request has been nagging at us and could use a fresh set of eyes”. Specific strengths historically include informal-methods precision of modeling and ability to haul The Good Stuff out of semantic mud. Specific weak areas include PHP being too psychologically taxing, Node.js likely being the same (which, ah, er, ouch given current SV culture), and flakiness from the depression itself (expected to improve with medication, but not 100% and exact curve unknown).

Posting this as a separate comment so it's easier to delete on its own if it turns out to be inappropriate. Also, to avoid surprise: I don't make my legal name too immediately visible from profiles etc. presently, but anyone who's transacting with me will get a confirmation of it privately.

Extremely. Mostly can't focus, can barely get out of bed at all some days. Some people are trying to help with various aspects of this, and they're doing some good, but they're poorly coordinated and there's secondary damage when they get things wrong.

Out of money. I was trying to get my career back into play via Triplebyte + one or two contacts around the beginning of the year; I had some minor success, but my interviews promptly got cancelled as the pandemic ramped up. And I think my Résumé of Nothing is now even more of an infinite liability than it's been in any recent years. (I took enough of a hit at the end of 2018 to pretty much lose my ability to work, after some years of on-and-off self-underemployment, and spent 2019 trying to recover; what I managed to regain has mostly been undone again in 2020.) Oh, and video calls and screen sharing (things people want a lot of nowadays) are both tricky due to secondary effects.

I finally have a source of medication that requires less effort to keep going, and that might help stabilize. Wish me luck?

… sort of. Last I checked, the Make features required by POSIX were very anemic. What winds up all over the Web in tutorials etc. is mainly GNU Make, which is extended way beyond that, including in ways which can become practical necessities pretty fast.

Which would be why my projects use the “GNUmakefile” file name explicitly, even though e.g. I tend to write to POSIX sh where I can rather than following the “bash scripting” trend. I also remember seeing a project in the wild that had a separate GNUmakefile and BSDmakefile, presumably for similar reasons.

If you use only POSIX make syntax, great for you, but there's definitely a barrier compared to what a lot of people are used to thinking of as Make nowadays.

(This is also ignoring the part where “higher probability” at a glance refers more to popularity than to standards compliance, and I don't read the parent as implying being in an environment where POSIX/SUS compliance is directly related to the set of target systems.)

I've never seen the `touch` version of that safety versus broken output files before. I've only seen the `rm` version. Is `touch` advantageous? Edit: oh, oops, I should've followed the link; the output file in the example seems to be test output which would be more distinctly useful to inspect after the fact on partial failure. That makes sense.

You probably knew this already, and there's probably better solutions if you're not in the manual sysadmin world, but after I did that on a personal machine a few decades ago (I think it was?), I got in the habit of using `--one-file-system` when doing major recursive rm operations that weren't meant to cross filesystems. Or `find -xdev … -delete` for anything more selective.

Ah, yes! I was treating those as effectively “part of” the condition mechanism for the comparative explanation, but you're right that that's misleading in CL. Thanks for the correction, or, shall I say, good catch. :-)

I can see both perspectives being possible, but I think what's under contention is less “proportion of computational literacy across the entire populace” and more something like “relative weight of control inputs to the social systems that build dominant technology coming from people who have computational literacy”. Thought experiments with much more obvious unequal channels, for instance: we wouldn't necessarily be in this situation if the major tech makers had a mysterious-wizard-enforced pact to design primarily based on the feedback of computationally literate academics; conversely, if we had a very computationally literate population, but an authoritarian government whom all the major tech makers had to answer to who wanted to keep the genie in the bottle, that could just as well be the situation in the OP. (This is not to pass judgment on other possible outcomes of those situations. I'm also using “computational literacy” here because “tech literacy” feels a bit too wide, even if “tech” has come to commonly be a metonym for “computer tech”.)

The geek/MOP/sociopath triangle wouldn't be a terrible description of the “subculture takeover” that seems to have occurred.

What phoe-krk mentions is indeed the main thing that blocks “real” integration into existing languages with exceptions: they always unwind before executing the handler. (JWZ even complained about this while writing about Java.)

To expand on their comment: if `throw` in Java or C++ is similar to `error` in CL (or `throw` in some special cases), a `catch` clause in Java or C++ is equivalent to a label, where the `try` binds a handler that exits to it immediately. There's no equivalent of putting code in the handler other than a single unwind-and-jump, and there's no equivalent of restarts.

In CL, a condition handler gets called on top of the existing stack and can inspect what's going on before choosing where to exit to. Other functions in the call stack can provide alternative exits (restarts), like “continue processing anyway” or “substitute a placeholder value”; these are dynamically named, rather than lexically bound like `catch` . So there's a lot more possible decoupling, at least in theory. The equivalent of `finally`/destructors is `unwind-protect`, which has to interoperate with the condition mechanism but doesn't deal with conditions itself.

In C++ or Java, you could implement the restarts with a (thread-local) stack of restart descriptions plus try/finally or constructor/destructor, and the same for handlers, and then do your nonlocal exits with specialized throwables. I did something similar in Lua, in fact, while trying to extend it into a fancier language. But a “normal” `throw` will bypass all of that. That's not dangerous if you do the unwind-protects properly, but none of your existing libraries will be built for it, and the results will be kind of anemic.

In the Java-style objects+throw/catch world, similar things can be achieved by toggling “what to do if X happens” state or plumbing callback pointers through the object graph beforehand, which is similar but more ad-hoc, and possibly harder to add to existing systems. That said, the CL style proper is very tied to the call stack, which can also make things tricky.

I don't know the “real” historical reason, but the deterministic UUID versions aren't really for the case where you want to obfuscate ID generation. They're more useful for shoehorning existing database-key-like information into slots where UUIDs are expected. In fact, I very recently ran into a thus-far-hypothetical situation with a set of in-memory objects identified and indexed by UUID, where “real” such objects have UUIDs that are also lookup keys for information elsewhere, and where I wanted to be able to deterministically derive a secondary, distinct “fake” object from a “real” one. My mental design sketch used SHA-1 UUIDs for this. (Sorry for handwaving over the specifics.) Though I do think the digest-based UUID versions are noncentral, especially in greenfield.

From another angle, if you look at the difference between version 1 and version 2 time+node UUIDs, they're actually quite similar except for version 2 having a UID/GID-like field replacing some of the least significant bits of the other data. So collisions between v1 and v2 would be much more possible without the version bits. And at that point there's no reason not to use similar flags to refer to other generation methods; even if in theory you could decide that they're unlikely to create collisions, that just feels like it leaves the door open for edge cases and having to remember which of those decisions were made. Why not be consistent?

From the opposite angle, in a case where you're using random UUIDs generated within a trust boundary as lookup keys, the knowledge that one of them is random doesn't tell an adversary on the outside anything useful about the others, because they're all random, so it's a few harmless “wasted” bits. Of course, since UUIDs didn't have “unguessable” as a selling point to start with, if that's something you're leaning on, then go ahead and use something else…

It's definitely not that polished, but I don't know about “extremely hacky”… how complicated are people's Emacs setups nowadays?

I installed the official Windows binaries for GNU Emacs pretty recently, copied my elisp directory over, and for the most part things worked out of the box, but with a few inconvenient exceptions: taskbar pinning didn't seem to work properly due to the awkward emacs/runemacs distinction, and some things related to directory layout and navigation were painful due to assumptions of a Unix-style home directory clashing with Windows's user-directory layout. No WSL involved.

In my case, mainly to lower the risk of supply chain attacks. Windows gaming and other such activity still includes a lot of “must run as administrator and does unclear things with this”, especially in anything with anti-cheat mechanisms as mentioned elsewhere, and there are environments (especially when dealing with mods) where you can wind up running code from dozens of randoms across the Internet in nothing approaching a meaningful sandbox. Popular messengers, video apps, etc. don't exactly seem trustworthy nowadays either.

I wouldn't want to try to directly deliver anything from such an environment that I would ask other people to run. Even my more-trusted development laptop feels scary at times, especially when I'm operating in environments where I have to do about the same thing as above with installing a dozen dependencies from who-knows-whom. I generally use separate build UIDs for some measure of separation in these cases, but we still have Linux and X being potential emmentaler attack surfaces, and I haven't yet arranged my workflow to the point that spinning up new virtual machines is trivial, especially because then you have a lot more friction with testing GUI software, sharing existing files, etc. etc.—most of the easier solutions to which seem to be very cloud-oriented and “when your Internet connection goes down, so does everything else”, which is something I insist on pushing back against in this context, including because “someone upstream did something unexpected and now everything is instantly broken in a way I have no real leverage over” is its own massive trust hazard.

My dedicated low-sensitivity machine isn't very powerful, so the cost wasn't as much of an issue as it could have been; it was a midrange laptop several years ago which I'm still using. If your workplace environment comes with its own hardware, then that's a thing too.

It would certainly be nice to have better, though, and the desire for less redundancy of costly hardware is legitimate. My desired setup from a while ago, which I never managed thus far, is to have more powerful hardware with multiple boot configurations, but not all of them persistently present like most multi-boot machines: instead, I would physically attach and detach system and user disks, assuming that firmware-level attack persistence is rare, and then rely on power-down flushing any lower-trust code before attaching a higher-trust disk. It'd be hard to ask most people to do this, though.

Interesting concept. Audio's crackly at times on my Linux Firefox. Though I keep waiting for something like this to show up that's more grounded in music theory…

Aww, I can't type outside ASCII range? Drat, I wanted to see whether different languages (even in Latin script) were distinguishable by sound this way.

Not that I endorse the “equally dangerous” comment, but if you're interested in configuration management with a language based around a powerful static type system, may I note the existence of Propellor? https://propellor.branchable.com/

… because in many cases, whoever gets there first with the wrong solution makes the social default be to continue using that, indefinitely, instead of developing something else which people will hesitate to switch to instead?

The rapidity of settlement of common knowledge in Internet time breaks a lot of the natural frictional mitigations, too.

“Oh, the path dependence is real” (said in the tone of a gaming commentator).

Pretty much yes, though I was angling toward coordination difficulties between people creating complexity which is “accidental” from the perspective of the whole system but “essential” to individual actors given their incentives and what they can rely on, either for purely social-maneuvering reasons or for other reasons as well. And more specifically, how this happens even when the accidental complexity isn't really in line with the group's values or with the values of the individual actors. The way that this grounds out in a technical sense is scenarios like the one you describe, so I think we're talking about the same broad set of phenomena.

Further, there's different levels and causes of “coordination didn't happen”, such as “we tried, but got confused and didn't have time to understand each other properly” or “actively sabotaging everyone else's ability to deal with the aggregate system so that I can get ahead”… and somewhere in there is one that stands out to me as specifically interacting with technical complexity, along the lines of “I want my piece to not have to be the one that changes and/or takes on other costs”. Which is part of the social dynamic of moving externally-essential complexity around within the aggregate system and potentially creating ripples of accidental complexity along the way.

(Whether and how this also happens when the information systems in question are human minds rather than software components might be relevant but also an exercise for the reader…)

The strategy recommended at the end with the “embrace it, give it the place it deserves” feels like the “eating your shadow” of design. It's also what I've been trying to approximate most of the time, and I appreciate the representation of it here.

I notice that there's a kind of complexity that seems to straddle the bounds, related to the way it easily turns into effort-reallocation politics. Would it be useful to consider “coordinative complexity” a separate type that's intermediary on the essential–accidental axis but also has other properties?

No. So long as you're willing to take a build-dep on that code.

Either you're expecting the code from that repository to exist somewhere in the compilation-host system already, or you are vendoring the code by copying it into your own repository and taking on any potential maintenance, unportability, any necessary configuration integration to make sure, for instance, that you're compiling for the host rather than the target in a cross-compile setup (did you make sure?)—

Either way, if you use that code as part of your build process, you are taking a build-dep on that code. The fact that its only build-dep is a C compiler may play into making this a sensible choice as compared with something that has even more transitive dependencies, but it does not make it go away.

I mean, so long as you're willing to take a build-dep on that, in that case.

Yes, so long as you're willing to take a build-dep on vim. An od+awk+sed+sh combo will get you there from a POSIX base—and you have to add some wrapper text around the output of xxd anyway…

XHTML tried to do this after the webmasters (loosely defined) had fled the barn, and then it fell out of the world and the WHATWG ate everything.

I use a Sennheiser GAME ZERO for audio calls on a regular basis, including professionally, because the sound quality is quite good for voice. (I do also use it for gaming, and for music listening.) For audio calls they're not going to see it anyway, and I don't think most of the people I talk to would care if they saw it on a video call; the design doesn't scream “business”, but the red metal tracery is the only flashy thing about it, and that's kinda subtle.

What's more of a problem I might run into soon is that my setup was already out of date for video calls; this seems increasingly like a hard expectation rather than an optional plus; and the pseudo-docking way I use my primary laptop at my desk doesn't currently allow me to orient the builtin camera so that it catches my expression at a reasonable angle while also letting me leave the monitor in front of me. Putting the laptop where my monitor currently is might be workable, but it could also get squint-inducing at that distance… I might have to play around with this.

Unsorted-array-based maps are sometimes used in the Java world, and for two or three elements will have much less overhead than hash tables. For instance, fastutil has http://fastutil.di.unimi.it/docs/it/unimi/dsi/fastutil/objec.... The map interface and encapsulation into a single “object” is the same.

It occurs to me that I don't know whether any of the major dynamic language implementations with maps/dicts/hashes as a central data structure use a similar approach for very small ones… huh.

I've just been recently learning some Rust coming from a heavy C background. The dynamic trait objects mimic what I do in C with vtable pointers and glue functions, and then sometimes I look at it over and over to make sure the casts are right and I haven't forgotten a free or anything. The borrow checker and lifetimes mimic what I do in C with pointer constness and function documentation, and then often I get very nervous and look something up again and maybe add extra intermediary comments on the data flow within a function if I'm not absolutely sure I remembered what the lifetime behavior contract was for a caller or particular callee, and of course I have to do this with all the structs too. The Drop trait mimics what I do in C with either straight-line fallthrough-chained exit labels as interior-exit goto targets or carefully included cleanups before a lesser amount of interior returns, and then I sometimes have to convert between the two for readability, and in the former case I have to carefully use a temporary variable if I also needed to return a non-constant at the end of all that. Compound-value ownership movement mimics what I do in C with either structure assignment or memcpy, and if the latter, hope that I got the pointer types and type size right because memcpy won't check, and in either case hope that I was able to prove that the original structure wasn't going to be incorrectly reused and maybe memset it to zero just in case that makes something crash rather than cause memory corruption.

I expect I'll run into more friction once I get to any point where I want to make more dynamically interlinked data structures, though that might also push my designs into directions that use fewer pointers and more indexes or other indirect references to start with (I'm not sure of that yet)—and I really like the idea that if I can pare some of it down to a working “core” data structure semantic that involves pointer juggling, I can put carefully constructed hard-packed blocks of the pointer juggling in their own unsafe zone and then not be able to accidentally break the invariants outside of that.

Which, again, is almost exactly the same thing I'd tend to do in C with inline wrapper functions and visibility stuff, and making sure I compute all the intermediary results in one phase and putting all the hard mutations in a second, unfailable (except possibly for hard crashes due to null pointers or such) phase so that if something goes wrong the data doesn't wind up crashing down to a persistent broken state from mid-flight!

Heck, I've even done the newtype pattern (single-element structs for safe reinterpretation/bounding of an underlying type) in C before!

I've described the way I write C as “as though I were hand-cranking the front end of a strict, low-level Haskell or Caml compiler in my head”. Rust is the closest I've seen thus far to moving a big chunk of that part of me into the digital part of the compiler. So I'm guessing my taste wasn't exactly uncommon.

The way I read the advisory is: (1) The most harmful vulnerability represented anywhere in this advisory is SQL injection. (2) The sync endpoint allows a full SQL injection, but the sync endpoint is normally IP-restricted and has an empty allow list in the default configuration, which can mitigate the exposure. (3) The verify endpoint does not allow a full SQL injection, but allows overly long values to be passed through to SQL.

The first paragraph in “Technical details” mixes (1) and (3) confusingly, and should have had a paragraph break before the sentence beginning “Verify” (or been rewritten).

A quick glance at the patchset suggests this is right (the verification code looks to have been made stricter in the verify endpoint, but added in the sync endpoint), but I didn't dig deeper than that.

[edited slightly for wording]

When I'm trying out a new language and writing programs in it that I'm going to invoke from the command line, one of the first things I do is put in those BSD-style extended error exit statuses. I also check along the way whether whatever option parsing library I'm using integrates at least EX_USAGE by default; the answer tends to be no, though I'm not sure how much of that is the library authors not knowing or intrinsically not considering them appropriate, and how much might be “new users will see this behavior, decide it looks complicated or bizarre, and leave”.

I conjecture specifically that presenceless messaging systems are more dangerous this way, both because of random reward and because of social risks surrounding attention allocation (engendering the default expectation of always-on). If you don't know when the other party is online, you send messages whenever, and sometimes you get rewarded with immediate feedback. Conversely, if you don't know when they're going to message you, then when they do, you might feel like responding right away is “supposed to be” no big deal for you even if it turns out to crowd out other things. IM where people are visibly only signed in when they're probably ready to chat, or telephone calls where both parties are expected to pay attention or hang up, allow conversations to have more explicit closure that releases attention for other activities.