mboerwink

RE self dialogue: I think it is also self-reinforcing in a positive way. "I am competent and capable of this" is certainly less distracting internal dialogue than "maybe I'm not smart enough" to children. I believe most adults eventually get better at ignoring this type of thing altogether, since it isn't really useful or productive.

The comparison to pre-atomic steel is poignant. I have found myself preferring pre-AI sources in some cases even (especially?) for computer related information. It is difficult to view pre-slop info as a limited resource without implying decline until the status quo changes again.

PCI still recommends 90 day password changes. Luckily they've softened their stance to allow zero-trust to be used instead. They're not really equivalent controls, but clearly laid out as 'OR' in 8.3.9 regardless.

I think this could still be a very useful question for an interviewer. If I were hiring for a position working on a complex system, I would want to know what level of complexity a prospect was comfortable dealing with.

I worry that this change increases the attack surface of what was a very safe application for viewing untrusted files. Of course, I worried about that at the release of 'new' notepad too...

I actually recently delivered a project which uses almost this exact technique. Python lambdas that operate on SQLite files have the benefit of being much simpler and cheaper than most other scalable database solutions (like Aurora) for very light loads.

That said, accessing SQLite databases is surprisingly disk IO heavy. I haven't gone too deeply into measuring the effect, but it seems the core issue is that traditional RDBS wire protocols are better than SQLite's disk accesses wrapped over NFS (or whatever connection the lambda/EFS join is). Stuff especially starts to break down when you need any sort of concurrent access. The small overhead for locking/unlocking files can quickly become awful when multiplied by the EFS latency, so you really do need extremely fine sharding.

I personally replaced tailing logs with lnav (lnav.org, also in Debian repos). Coloration, decompression, filtering, etc. with no learning curve made it an easy transition for me after hearing about it on HN. It isn't nearly so featured as a log aggregator like splunk, but it was a total tail replacement for me.

I have always interpreted bones/ghosts as using previous runs as an additional source of level-generation data, rather than a progression mechanic. In the game, it is realistic that other adventurers would have attempted what you are attempting (and died trying). The game could fill in this assumption by randomly generating ghosts and loot, but real-world data is more interesting and nuanced. For example, one of my favorite components of the nethack bones system is seeing the cause of death of the ghosts I run into. Again, 'cause of death' could be reproduced with some random generation, but it wouldn't be as good.

Anyway, I only play nethack on public servers or using the nethack hearse tool, so I don't 'progress' by using my own bones files. Maybe if you play purely locally, you can view your own bones files as a form of progression.

I start my manual picks at 3000 to avoid conflicts with users created by people like you. (I'm not only making a joke, I really do. My siblings are people like you, too.)

Sorry if I'm missing context, but where is the write-up?