gue5t

At first, I was annoyed by having to read AT&T syntax. Then I was disoriented by realizing the next snippet was in AT&T syntax without the '%' sigil for registers. But the technique is cool.

It's a MediaTek SoC, so the Linux experience will be Bad to say the least. This thing will be running the oldest kernel possible with all kind of nasty vendor hacks.

The Gruen transfer seems to make use of confusion or disorientation upon entering a new physical space. On the other hand, the phenomena described here with data search implementations (e.g. a feed) intentionally returning things that were not asked for does not rely on user confusion. The user already made a perfectly legible request by performing the query (e.g. opening the feed). Ignoring or misconstruing this request is gaslighting. The site tries to pretend that the user asked for something different than they actually did and to sneak this subterfuge past them. It's rampantly unethical. The purported justification I've heard is that fuzzy search can find results in cases when exact matching does not, but taking the control of fuzzy vs. strict search out of the user's hands is unethical because it is motivated by the opportunity to introduce mistakes and pervert intention.

Sites like Etsy implement this dark pattern in ways intentionally intended to make CSS-based blocking of injected sponsored products difficult to block. The arms race between user agents and corporate manipulation continues, and corporate web designers will use every tool available to subject users nonconsensually to their preferred experience. This is why I consider it a net loss for users to add functionality to the "web platform". The corporation is your enemy and they're well-funded.

I concur. I looked pretty hard into adapting Serf as part of a custom service mesh and it had some bonkers designs such as a big "everything" interface used just to break a cyclic module dependency (perhaps between the CLI and the library? I don't recall exactly), as well as lots of stuff that only made sense if you wanted "something to run Consul on top of" rather than a carefully-designed tool of its own with limited but cohesive scope. It seemed like a lot of brittle "just-so" code, which to some extent is probably due to how Go discourages abstraction, but really rubbed me the wrong way.

This is one of the ways you can tell if an INTERCAL implementation is worth its salt.

These types don't seem to escape the scope of what can be described with algebraic types, but the relationships between them seem like you're looking for a notion of type-level functions: subset ≡ X => 2^X, partial ≡ A×B => (A+1)×partial(B)

One interesting perspective is to view the sequence of lists -> trees -> DAGs -> general graphs as a loosening of restrictions:

- list nodes may have one child

- tree nodes may have multiple

- DAG nodes may have multiple parents though restricted by topological ordering

- graph nodes may have multiple parents from anywhere in the collection

Lists and trees can be fully captured by sum and product types, but extending this representation style to DAGs and graphs doesn't work--you either get inefficiency (for DAGs) and then infinite regress (for cyclic graphs) attempting to continue the "syntactic" style of representation, or you need to adopt an "indirect" representation based on identifiers or indices or hash consing.

My experience attempting to contribute to Manjaro (fixes to packages including some without with which packages simply hung when being built interactively, as they depended on stdin being EOF as it is in their CI environment) was met with not just a cold shoulder but active offense and hostility. They don't accept pull requests (in fact, their gitlab configuration doesn't even let one fork), nor is there a mailing list for patches. There simply is no contribution workflow, and this isn't even clearly documented (it's fine to be a "cathedral", but you should be up-front about it).

You're right... what an annoying namespace collision. On the other hand, stylizing software as Initial Caps is much more acceptable than stylizing non-software acronyms that way, so it would still be less misleading to change the capitalization.