Nice! It describes, among others, Sid Sackson's "Lines of Action" (LoA) from bis inspiring book "A Gamut of Games" which describes a large number of games which can be played with just paper and pencil or a checkerboard.
I always liked these kinds of games, easily self constructible, easy to carry and fun to play.
> My hypothesis is people will get burned out on this unguided learning via LLMs [...]
I'm less optimistic. Already 20+ years ago many people complained if you pointed them to books which answered their questions in depth. The standard reply was "just tell me how to solve this particular problem" instead.
That's generally not very clever, as it will impose an unneeded burden on a receiving server which actually has temporary resource problems, and it will collide with greylisting, for example.
RFC 5321 states in section "4.5.4.1. Sending Strategy" that the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
MUST is a requirement. You left out the "however" part:
In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.
There's absolutely nothing wrong with a fine tuned backoff. I am not saying the specific backoff discussed by GP is best, merely that 30 minutes is absolutely not a requirement, and in fact, discussed in tandem with the fact that "more sophisticated strategies" are actually beneficial.
The RFC does not agree with you. Partially quoted as you have, does not help.
> the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days
RFCs have very little to do anymore with the realities of email delivery. And advocating for password reset emails to only be retried after 30 minutes (all while the user is manically mashing the 'resend link' button) and/or to be kept around for 5 days (while the link contained therein expires after an hour) doesn't either.
I'll second Max Richter's Sleep. Timeline by Edith Progue might interest you too. The later is my favorite xcalm down" CD even before Max Richter's, when I'm too restless to sleep.
And maybe Glitch (music) might be of interest as a starting point, especially the "Clicks & Cuts Series" which gave me a lot of pointers to interesting niche artists.
> Are we just shittier engineers, is it more complex [...]
Both IMO: first, anybody could buy a computer during the last three decades, dabble in programming without learning basic concepts of software construction and/or user-interface design and get a job.
And copying bad libraries was (and is) easy. I still get angry when software tells me "this isn't a valid phone number" when I cut/copy/paste a number with a blank or a hyphen between digits. Or worse, libraries which expect the local part of an email address to only consist of alphanumeric characters and maybe a hyphen.
Second, writing software definitely is more complex than building physical objects. Because there are "no laws" of physics which limit what can be done. In the sense that physics tell you that you need to follow certain rules to get a stable building or a bridge capable of withstanding rain, wind, etc.
Absolutely. As an Electrical Engineer turned software guy, Ohm's/Kirchhoff's laws remain as valid and significant as when I was taught them 35 years ago. For software however, growth of hardware architectures/constraints made it possible to add much more functionality. My first UNIX experience was on PDP-11/44, where every process (and kernel) had access to an impressive maximum of 128K of RAM (if you figured out the flag to split address and data segments). This meant everything was simple and easy to follow: the UNIX permission model (user/group/other+suid/sgid) fit it well. ACLs/capabilities etc were reserved for VMS/Multics, with manuals spanning shelves.
Given hardware available to an average modern Linux box, it is hardly surprising that these bells and whistles were added - someone will find them useful in some scenarios and additional resource is negligible. It does however make understanding the whole beast much, much harder...
Hmm, so what about these modern high density hard drives which store track parameters for their servos in on-board flash (aka OptiNAND)? Do we get "spinning rust" which might loose the information where exactly it stored the data?
I think you're talking about two different things; "adaptives" are usually stored in EEPROM or the MCU's NOR flash, which is basically better-than-SLC levels of reliability, especially as they're written once and treated as ROM after that.
Yes, but only after viewing, of else I'd pay for "editorial" or AI generated slop which would be generated like link farms pointing to Amazon etc.
And that's the chicken-and-egg problem ...
In theory that could be resolved by registering for free at reputable sites and then paying per view with micropayments. Or by a scheme where one would register and only pay when I actually did read stuff, not with the currently en-vogue monthly fee for each and every site.
Sand is the world's second most used natural resource and sand usable for concrete gets even illegally removed all over the world nowadays.
So to continue your analogy, I made my part of the beach accessible for visitors to enjoy, but certain people think they can carry it away for their own purpose ...
If you control your own Apache server and just want to shortcut to "go away" instead of feeding scrapers, the RewriteEngine is your friend, for example:
RewriteEngine On
# Block requests that reference .php anywhere (path, query, or encoded)
RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
RewriteCond %{QUERY_STRING} \.php [NC,OR]
RewriteCond %{THE_REQUEST} \.php [NC]
RewriteRule .* - [F,L]
Notes: there's no PHP on my servers, so if someone asks for it, they are one of the "bad boys" IMHO. Your mileage may differ.
Live example: https://FreeSolitaire.win/wp-login.php (NB: /wp-login.php is WordPress login URL, and it’s commonly blindly requested by bots searching for weak WordPress installs.)
nginx also has "return 444", a special code that makes it drop the connection altogether. This is quite useful if you don't even want to waste any bandwidth serving an error page. You have an image on your error page, which some crappy bots will download over and over again.
> You have an image on your error page, which some crappy bots will download over and over again.
Most bots won’t download subresources (almost none of them do, actually). The HTML page itself is lean (475 bytes); the image is an Easter egg for humans ;-) Moreover, I use a caching CDN (Cloudflare).
I always liked these kinds of games, easily self constructible, easy to carry and fun to play.
https://en.wikipedia.org/wiki/A_Gamut_of_Games
And I always bewildered when I see some of these games built in plastic instead, like e.g.
https://en.wikipedia.org/wiki/Battleship_%28game%29 https://en.wikipedia.org/wiki/Dots_and_boxes
reply