TNG, by a country mile. B5 has "writer identifies too much with the main character" written all over it. It's the story of how Our Great Leader does the right thing and saves the world, over and over again.
I'm slightly taken aback by the telnetd fix: The solution to the username "-f root" being interpreted as two arguments to /usr/bin/login is to add a "sanitize" function, really? I'm not seeing the sense in that. Surely in any case where the sanitize functions changes something, the login will fail. Better to error out early than to sanitize and try to hobble along.
What I'd like to know is how the arguments get interpreted like that in the first place. If I try giving that kind of argument /usr/bin/login directly, its argument parser chides me:
$ login '-f root'
login: illegal option --
What's telnetd doing differently? Is it invoking login via a shell?
You passed '-f root' to login (a single long string). telnetd is likely passing '-f' 'root' to login (two arguments instead of one, whether this is because it creates two, or it uses the shell (which then reparses) I don't know).
But '-f' is a valid option to login (man login):
login [-p] [-h host] [-H] [-f username|username]
...
-f Used to skip a login authentication. This option is usually used by the getty(8) autologin feature.
I was reading https://www.offsec.com/blog/cve-2026-24061/, which implies that precisely that single long string passes through getenv("USER") in the attack. The mystery is how that single long string in telnetd becomes two separate arguments for login. execv or posix_spawn certainly won't do that. So either there's a version of /usr/bin/login that parses arguments in some very sus way, or there's a shell involved somehow.
This article is just about as un-AI written as anything I've ever read. The headings are clearly just the outline that he started with. An outline with a clear concept for the story that he's trying to tell.
I'm beginning to wonder how many of the "This was written by AI!" comments are AI-generated.
I struggled a bit with what to point to as signs that it's not an LLM conception. Someone else had commented on the headlines as something that was AI-like, and since I could easily imagine a writing process that would lead to headlines like that, that's what I chose. A little too confidently perhaps, sorry.
But actually, I think I shouldn't have needed to identify any signs. It's the people claiming something's the work of an LLM based on little more than gut feelings, that should be asked to provide more substance. The length of sentences? Number of bullet points? That's really thin.
I don't think people should be obligated to spend time and effort justifying their reasoning on this. Firstly it's highly asymmetrical; you can generate AI content with little effort, whereas composing a detailed analysis requires a lot more work. It's also not easily articulatable.
However there is evidence that writers who have experience using LLMs are highly accurate at detecting AI generated text.
> Our experiments show that annotators who frequently use LLMs for writing tasks excel at detecting AI-generated text, even without any specialized training or feedback. In fact, the majority vote among five such “expert” annotators misclassifies only 1 of 300 articles, significantly outperforming most commercial and open-source detectors we evaluated even in the presence of evasion tactics like paraphrasing and humanization. Qualitative analysis of the experts’ free-form explanations shows that while they rely heavily on specific lexical clues, they also pick up on more complex phenomena within the text that are challenging to assess for automatic detectors. [0]
Like the paper says, it's easy to point to specific clues in ai generated text, like the overuse of em dashes, overuse of inline lists, unusual emoji usage, tile case, frequent use of specific vocab, the rule of three, negative parallelisms, elegant variation, false ranges etc. But harder to articulate and perhaps more important to recognition is overall flow, sentence structure and length, and various stylistic choices that scream AI.
Also worth noting that the author never actually stated that they did not use generative AI for this article. Saying that their hands were on the keyboard or that they reworked sentences and got feedback from coworkers doesn't mean AI wasn't used. That they haven't straight up said "No AI was used to write this article" is another indication.
> Also worth noting that the author never actually stated that they did not use generative AI for this article.
I expect that they did in some small way, especially considering the source.
But not to an extent where it was anywhere near as relevant as the actual points being made. "Please don't complain about tangential annoyances,", the guidelines say.
I don't mind at all that it's pointed out when an article is nothing more than AI ponderings. Sure, call out AI fluff, and in particular, call out an article that might contain incorrect confabulated information. This just wasn't that.
A __del__ that does any kind of real work is asking for trouble. Use it to print a diagnostic reminding you to call .close() or .join() or use a with statement, and nothing else. For example:
def close(self):
self._closed = True
self.do_interesting_finalisation_stuff()
def __del__(self):
if not self._closed:
print("Programming error! Forgot to .close()", self)
If you do anything the slightest bit more interesting than that in your __del__, then you are likely to regret it.
Every time I've written a __del__ that did more, it has been trouble and I've ended up whittling it down to a simple diagnostic. With one notable exception: A __del__ that put a termination notification into a queue.Queue which a different thread was listening to. That one worked great: If the other thread was still alive and listening, then it would get the message. If not, then the message would just get garbage-collected with the Queue, but message would be redundant anyway, so that would be fine.
Yep, a __del__ in the redis client code caused almost random deadlocks at my job for several years. Manual intervention was required to restart stuck Celery jobs. Took me about 2-3 weeks to find the culprit (had to deploy python interpreter compiled with debug info into production, wait for deadlock to happen again, attach with gdb and find where it happens). One of the most difficult production issues I had to solve in my life (because it happened randomly and it was impossible to even remotely guess what is causing it).
> If you think you disagree with him (as I once did), please consider the possibility that you've only been exposed to an ersatz characterization of his argument.
My first exposure was a video of Searle himself explaining the Chinese room argument.
It came across as a claim that a whole can never be more than its parts. It made as much sense as claiming that a car cannot possibly drive, as it consists of parts that separately cannot drive.
I'm not that concerned with bugs in sqlite. sqlite is high quality software, and the application that uses it is a more likely source of vulnerabilities.
But I do see a problem if you really need to use a sqlite that's compiled with particular non-default options.
Say I design a file format and implement it, and my implementation uses an sqlite library that's compiled with all the right options. Then I evangelize my file format, telling everyone that it's really just an sqlite database and sooo easy to work with.
First thing that happens is that someone writes a neat little utility for working with the files, written in language X, which comes with a handy sqlite3 library. But that library is not compiled with the right options, and boom, you have a vulnerable utility.
Most of the recommended [1] setting are available on a per connection basis, through PRAGMAs, sqlite3_db_config, sqlite3_limit, etc; some are global settings, like sqlite3_hard_heap_limit64.
A binding can expose those settings. It's not a given a third party utility will use them, but they can.
Ah, I missed that 9.a-c were alternatives. And that, in the absence of custom tables or functions, they are merely defense in depth for something that is already secure, barring bugs. I withdraw my concern.
15 years ago, was intermittent fasting even a thing back then? I wonder how many of the people eating within an 8 hour window didn't do it because of a diet, but instead because of an eating disorder or some other disease.
I have an idea for a gameplay that I think I would enjoy more:
- If the first guess is within a factor of sqrt(10), then you win.
- If not, you are given two choices for the second guess: Up or down.
- Up and down are 10x higher and lower guesses (making them adjacent ranges to the first guess).
- If the second guess is wrong, you lose. No more guesses.
The point is that the second guess makes you rethink the original question once more, to figure out what it was that you missed. Which is more fun that doing bisection.
I wrote 10x and sqrt(10) to make a game literally about orders of magnitude, but you could of course you smaller numbers, like 4x and sqrt(4), to make it harder.
I greatly appreciate your suggestions, munch. I really like it, but I worry that the game loses some of its mainstream appeal through that. I don't know, I have to look into this in more detail.
However, I did find a solution to bring the focus a bit away from the binary search/bisection.
Namely, the game now shows a hint after the second incorrect guess. For example the hint "The US covers 1.87% of the Earth's surface." is displayed for the question about what percentage of the Earth's surface is land.
This of course lets you, just as you wanted, rethink the original question once more now in light of new information.
text:
I think I found a solution to bring the focus a bit away from the binary search and would greatly appreciate feedback from you.
The game now shows a hint after the second incorrect guess. For example the hint "The US covers 1.87% of the Earth's surface." is displayed for the question about what percentage of the Earth's surface is land.
How does the new information received through the hint impact your guess and assumptions?
help
Not only that, the compiler's optimizer might actually do a better job if you split up a big function. Because the smaller functions have less register pressure.
I'm not sure I agree and I think you should try some stuff out on godbolt first. The compiler can see where variables are no longer in use, whereas unless you turn on link time optimization (which is known for being messy so nobody seems to), you'll likely get a lot of unnecessary push/pop between the function calls.
reply