xelxebar

This label is such a blatant Americanism. AFAICT it simply communicates a social threat for violating implicit cultural norms, shutting down communication, and carries virtually no useful content beyond that.

Communication takes two. If we want peers to take responsibility for their words and actions, then shouldn't we also take responsibility for our role in interpreting and reacting the same?

Some of the best work environments I've been part of allowed space for people to accept the fact that we're all human with human emotions. If someone blows up, maybe they're overstressed or maybe they're yelling at a kid about to get run over by a car.

I really wish academia consistently provided as much security as industry. Would have loved to continue this line of research.

https://git.9front.org/plan9front/plan9front/427e868e2be75f2...

Jj is arguably also in this vein, albeit much more heavyweight.

By virtue of almost universal adoption, git as an on-disk and interchange format give us an opportunity to treat is simply as an API and experiment with new UX on top. Would love to see more of this kind of thing.

What hardware do hobby archivists usually work with?

If you configure your YAML loader to run arbitrary, input-controlled deserialization code, then of course you're opening a can of worms. Just, uh, don't do that for untrusted input maybe?

Is $programming_language terrible because some people run user input through eval?

The latest YAML (1.2 currently) gives you the option of doing all that stuff if you want. It's a bad implementation that decides to run random code by default, or heaven forbid, bakes such behavior in.

Granted, Python and other popular languages are also on an ancient YAML version for some inexplicable reason...

I've been slowly reading Agner Fog's resources. The microarchitecture manual is incredible, and pertinently, the section on branch prediction algorithms I find fascinating:

https://web.archive.org/web/20250611003116/https://www.agner...

Bigfoot is what you see in this photo here [0]. A useful phenomenological description doesn't presume and use the thing it attempts to describe.

A good definition would look like the Mirror Self-Recognition Test (MSRT), or even simple verbal affirmations of personal consciousness, or some MRI features, etc. But these all have glaring limitations.

MRST is unusable with blind patients, it only tests a specific kind of awareness, and it turns out that toddlers fail the test.

Verbal affirmations limit coverage to socially functional, speaking humans, so severe autistics fail, and duct tape over the mouth (or aphasia etc.) presumably impairs consciousness as well.

MRI brain features seem to always disappoint with obvious flaws like above or have some crazy exceptions of some living, healthy patients who are missing parts of their brain.

Until we can talk about consciousness without saying "consciousness" or referring to it indirectly, then we're just hallucinating IMHO.

[0]:https://en.m.wikipedia.org/wiki/Bigfoot#/media/File%3APatter...

If we're going to agree on anything, I just wish consciousness discussions could agree on some phenomenological referent(s) for the term "consciousness". The word is used in a way that is little more than a sed-replace for elan vital, regaling all discourse to little more than a volley of solipsistic value proclamations IMHO.

It's a pretty neat system; runs Doom, so we know it's production ready; and the source is meticulously organized.

The docs try to be overly general, IMHO, clouding the core ideas. If you're interested, I recommend just spinning up a VM and mucking about, along with the user guide.

[0]:https://genode.org/download/sculpt

There's an entire thread on the evolution of stapler design, elaborations on the invention of perforations, and abundant self-reflection. It's almost like a hybrid of Leonard Read's "I, Pencil" and Hegel.

There's something magical about paying close attention to the mundane, IMHO.

Praise dullness!

[0]:https://en.m.wikipedia.org/wiki/The_Mezzanine

That said, the automatic variables ($target, $stem, etc.) are more descriptive than those of make ($@, $*, etc) since the former are just normal shell variables passed in at rule runtime I think.

Blah blah, jargon. Mostly thinking out loud here.

Basically, you're making the astute observation that the majority of configurations fill all wealth brackets... I think? The maxentropy distribution involves maximizing over products of combinations, and I'm just gut feeling at the moment.

How does this jibe with the supposedly empirical observation that wealth tends to follow a Pareto distribution?

Very cool. Thanks for kicking off the this conceptual avalanche!

This window manager implemented in Prolog popped up here recently. It's really cool!

I jumped to it as a new daily driver in the hope that I'd learn some Prolog, and it's been quite the success, actually. The developer is really nice, and he's generously helped me with some basic questions and small PRs.

Definitely recommended. I have a Guix package for it if anyone's interested.

Any reading recommendations for high quality logic programming codebases?

I'm really trying to play as fairly as possible, though. The original suggests that ascention and azimuthal data might need to be treated separately. We really don't know, though.

The basic call graph shape of `(a-b)⌈x-y` also directly mirrors that of timeToMove, so I think I'm taking as few liberties as possible while also showing what APL design patterns can get us.

> You do need to also implement the other lines in the function.

What lines, though?

All we have in the original are three opaque functions composed in a Dovekie pattern, i.e. (f (g x) (h y)). Everything else—besides the discussed overcomplications—is just suggestive naming.

I actually agree with you! The demonstrated code is trivial, and I believe you're right to complain. It's just that APL makes the triviality painfully obvious.

> If the sample code were simply subtraction then OP would've written subtraction

The reason is that functional design patterns are very different from APL design patterns.

In functional programming we manage complexity by hiding it behind carefully-designed functions and their compositional structure. APL manages the same by normalizing data and operating over homogeneous collections. These lead to very different looking code, even without the symbols.

So, where Haskell hides a bunch of calculation behind timeToRotate and timeToAscend, with APL we usually choose to pre-process the data instead. This means that where Haskell needs timeToRotate etc. APL can just use really simple primitive.

While we're granting the author that these opaque functions are correctly implemented, I think it's fair to grant that the APL correctly normalizes it's data. The unshown work is going to be about the same, either way.

Don't you think it's intriguing if we end up with less work and clearly trivial code?

    (destEl-sourceEl)⌈destAz-sourceAz

Here's my take on performScan, too:

    Log⍪←onSourceTime+slewTime

> Hui can list the entire interpreter in the appendix because it’s just that single page, 122 lines of incredibly cryptic C, which you can view here:

I count 41 lines, but more interestingly and by pure luck, I just happened to make a post about this less than an hour ago:

https://blog.wilsonb.com/posts/2025-06-06-readable-code-is-u...

In the off chance you've not see this: https://aplwiki.com/wiki/Chat_rooms_and_forums

For non-event driven systems, the short story is to organize application state as a global database of inverted tables and progressively normalize them such that short APL expressions carry the domain semantics you want.

For event driven systems, we have token enumeration over state machines, which can be expressed as literal Branches to state blocks.

Granted, the above likely doesn't communicate well unless you're already primed with all the necessary ideas. If you're interested, I'm willing to chat. Email is in my profile description.

source: Current day-to-day is greenfield APL dev.

APL isn't really one of these exhibitions of computational simplicity in the way of the languages you mention. It's inventor, Kenneth Iverson, was more focused on the human side of thinking in and using the language.

Forth, Lisp, et al are quite easy to implement, but they require considerable library layers on top to make them useful for expressing application-level logic, even if we just focus on the pure functions. APL, on the other hand, has a larger core set of primitives, but you're then immediately able to concisely express high-level application logic.

Are you looking for a kind of reference implementation for learning purposes? If so, I'd say the best route is just go with the docs. Arguably the Co-dfns compiler is a precise spec, but it's notably alien to non-practitioners.

This AoC solution is, indeed, quite the functionista! Better yet, it leans heavily into point-free expressions. The style is pretty popular amongst APL language enthusiasts and puzzlers.

That said, you actually see quite different APL styles in the wild:

- Pointed declarative style, also a popular with functional programmers (e.g. anything like this[0] from the dfns workspace)

- Imperative, structured programming, very common in legacy production systems (e.g. this[1] OpenAI API interface)

- Object-oriented, also common in somewhat newer production environments (e.g. the HTTP interface[2])

- Data-parallel style (e.g. Co-dfns[3])

Heck, APL even has lexical and dynamic scope coexisting together. IMHO, it's truly underrated as a language innovator.

[0]:https://dfns.dyalog.com/c_match.htm

[1]:https://github.com/Dyalog/OpenAI/blob/main/source/OpenAI.apl...

[2]:https://github.com/Dyalog/HttpCommand/blob/master/source/Htt...

[3]:https://github.com/Co-dfns/Co-dfns/blob/master/cmp/PS.apl

http://ref.x86asm.net/

    sudo fail2ban-client status | sed -n '/Jail list:/{s/^.*://; s/,//g; p}' | xargs -n1 sudo fail2ban-client status | awk '/jail:/{i=$5}; /Total failed:/{jail[i]=$5}; END{for(i in jail) printf("%s: %s\n", i, jail[i])}' | column -t
    sshd-ddos:        0
    postfix:          583
    dovecot:          9690
    postfix-sasl:     4227
    nginx-botsearch:  1421
    nginx-http-auth:  0
    postfix-botnet:   5425
    sshd:             202157

But, indeed, depth vectors are nice and compact. I find them harder to work with most of the time, though, especially since insertions and deletions become O(n), compared to parent vector O(1).

That said, I do often normalize my parent vectors into dfpo order at API boundaries, since a well-defined order makes certain operations, like finding leaf siblings, much nicer.