> Plutarch tells us in Lysander 17 that, in early times, nails (ὀβελοί (obeloí)) were used as money, six of which made a handful (δραχμή (drakhmḗ)), and that the name was changed to ὀβολός (obolós).
In the (legendary) Spartan version of this, though, the currency was more cumbersome and deliberately less practically useful. You don't want people coveting money for its intrinsic utility — it's bad enough they'll covet it for its trade value! So the Spartan iron money was (allegedly) quenched in vinegar to ruin its intrinsic value.
"Two weeks of warranty" jumped out at me. That's like "you have two weeks to find the thing we broke, or else we aren't responsible for it." In my experience, a good bug can hide for months more than two weeks! My codebases are definitely not in the target demographic for this service, though, and maybe if I were in the target group (bunch of LLM slop, trying to dig out of the hole, presumably no shipping product or existing userbase yet) the proposition would appeal to me.
> In every system of morality which I have hitherto met with [...] the author proceeds for some time in the ordinary way of reasoning [...] when of a sudden I am surprised to find that instead of the usual copulations of propositions is and is not I meet with no proposition that is not connected with an ought or an ought not.
Or ask the agent to visit a web page, or load an image, whose URL involved the secret? Or ask it to install a new .authorized_keys and then go get the contents of the machine themselves? From the post it sounds like a lot of people were just trying to get the LLM to write them a reply email — which it had been told not to do.
I see there's a "log" at
https://hackmyclaw.com/log
but (maybe because I'm on mobile?) I can't actually click through to view any of the table entries.
+1. It felt very mechanical running through "bard, card, hard, lard, nard, pard, sard, ward, ware, care, dare, fare, hare, mare, nare, pare, tare, bare, bark, dark, hark, lark, mark, nark, park, sark,..." Definitely feels like something a computer could do better than a human. (And the leaderboard confirms it.)
But switching the traversal order to "bard, bare, care, card, hard, hare, dare, dark, hark, hart, cart,..." doesn't seem to make it any more fun.
My suggestion would be to add an "enemy AI" following its own trajectory toward you; your job then is not just to walk around as long as possible, but to stay at least one step ahead of the enemy for a long as possible.
The enemy might not move just one step per turn; it might do something like "stand still for 3 turns, then change 2 letters in a single turn."
Showing the enemy's words to the player would also increase the "discoverability" of paths in the game. The player could say "Oh, apparently NARD is a valid word! I'll remember that for next time."
The other day I learned that the command line interface (or whatever) to Antigravity goes by the abbreviated name "agy", which is awfully close to "agi" as in "artificial general intelligence." I strongly suspect they did that on purpose.
From my read of the article, this isn't a problem "in DNS." OP runs an uptime monitoring service that purports to check whether DNS can resolve your domain — but today OP learned that because he's hitting his ISP's recursive resolver, he doesn't notice downtime until the TTL of the previous response expires.
Solution (which everyone else does, and OP has now implemented): don't use your ISP's recursive resolver! Run your own instance of bind9 or whatever, with the cache disabled. Or it seems like `dig +trace` would probably work, too.
"Cached resources remain visible for their whole TTL, even if the original becomes unreachable or changes" seems like one of the very first principles someone should learn when deciding to go into business selling an uptime monitoring service.
It's not a "ghost domain," it's a Time-To-Live field!
As a banner or something, maybe. But I'd much rather see a broken-looking site on mobile than see nothing at all on mobile.
In the same category: websites that display nothing but a splash screen "This site requires Internet Explorer X" or whatever. Don't nanny me, just feed my browser the HTML! Whether my browser can render it properly is my problem, not yours.
In the middle of this too-long-and-rambling piece, there's a sketch of an interesting sequence: look for the text "universal winner." Let a(n) be the size of the smallest "coin-matching player" DFA that eventually matches the output of its n-state opponent no matter the identity of that opponent. a(1) is obviously 2 (right?); Wolfram indicates a(2) <= 10; what is a(3)?
This is different from the problem of identifying the opponent, which obviously requires at least as many states as there are opponents.
The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.
But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.
FWIW, I believe that's not a mistake, just a consistent use of (novel?) jargon. From context I infer that the paragraph is distinguishing between the _hard requirements_ of the traits (quote: "the language contract says they cannot become unsafe") and the behavior human programmers would naturally _expect_ of the traits ("the social contract").
And yes, looking at https://docs.rs/misfortunate/latest/misfortunate/index.html and Ctrl+F'ing for "social contract," I see that usage very consistently. The entire point of Misfortunate is that its types correctly implement the language contract, while violating the "social contract" in various surprising ways. For example, causing a hash collision on every operation is a perfectly cromulent implementation of Hash, but violates the "social contract" of Hash. For another example, look at LoadLetter — throwing an error on every operation is a valid implementation of Read, but still violates the "social contract" of what a human programmer would naturally expect from something readable.
...Ah, `heap_sort` is used only for trivially copyable types. So my complaint about not distinguishing copy from move is essentially unimportant (matters only in pathological cases that we shouldn't worry about).
But it's perfectly possible for a type to be "trivially copyable" without being "default-constructible." An example of such a type from the STL: `std::reference_wrapper<int>`.
Anyway, looks like a quick fix for this would be to just extend the list of traits on which blqsort is gated (currently `is_trivially_copyable` and `sizeof(T) <= 16`) by adding `is_trivially_default_constructible<T>::value` also.
> Plutarch tells us in Lysander 17 that, in early times, nails (ὀβελοί (obeloí)) were used as money, six of which made a handful (δραχμή (drakhmḗ)), and that the name was changed to ὀβολός (obolós).
In the (legendary) Spartan version of this, though, the currency was more cumbersome and deliberately less practically useful. You don't want people coveting money for its intrinsic utility — it's bad enough they'll covet it for its trade value! So the Spartan iron money was (allegedly) quenched in vinegar to ruin its intrinsic value.
https://en.wikipedia.org/wiki/Pelanor
It's unlikely that the legend corresponds to any ancient reality, though.