I've done some experimenting with running a local model with ollama and claude code connecting to it and having both in a firejail: https://firejail.wordpress.com/
What they get access to is very limited, and mostly whitelisted.
There is already much snake oil sales and marketing going on, it's already enabled by arguments that are not based on bodily autonomy, which suggests that a move towards more respect to bodily autonomy will not noticeably increase such snake oil. The resistance to homeopathy has not gone well. I actually believe the resistance is actively harmed by making legit chemicals harder to get instead of easier. When people can easily get the good stuff that works there's not much of a market for the easy to get snake oil that doesn't.
You can pirate a copy of the DSM-V and see the diagnostic criteria for yourself. It's particularly interesting to me (as I believe the field has "crystalized" more than it has right to) that two people can be diagnosed with "ADHD" but share few overlapping symptoms. Separately, fMRI evidence is still not solid on its own, it has to be paired with stronger science to be at all useful, but even so studies based on it tend to suffer from numerous problems. The most infamous case being a "study" that found brain activity using fMRI of a dead fish. That was in 2009. In 2020, Botvinik-Nezer et al. published a paper about 70 different research teams analyzing the same fMRI dataset and producing wildly different results. It's a blunt instrument but people are deceived into thinking it's really solid; it's not.
What a strange post... The linked sl4 source (http://sl4.org/crocker.html) is short enough it could have been quoted in full. It's Yudkowsky's version, I think this is the first I'm hearing via jandrog's comment that it's not exactly faithful to the original (which I presume originated on an extropian mailing list). On the SL4 mailing list, people would sometimes join and note that they operated under the rules. Stuart Armstrong had an aside to such a declaration once:
"I'm not convinced that Crocker's rules are particularly useful
(rephrasing the same idea to make it more polite doesn't lose
anything, can be more convincing to the target, and will often
generate more insights in yourself than a curt dismissal), but it's up
to everyone to choose their approach."
I think that aside is part of the same strangeness and confusion as this post. Operating under the rules is something you do for yourself -- the "begging" that you're doing to other people is asking them to communicate to you in a manner that is optimized for information, not for being nice. The problem isn't necessarily that people dance around the issues (though that can and often is a problem), the problem is that they simply won't communicate the issues or other information in the first place, and so leave such out, especially if they can't figure out a nice way to say it. Also, if you are writing for someone who is operating under the rules, for you to respect their wishes that doesn't mean you have to be rude or omit politeness or be blunt, it just means you should include all the information you want to say, and not worry about it not being phrased nicely, though of course you can phrase things how you please.
To beg others to follow Crocker's rules is basically saying "I am tired of having to use delicate language and sometimes having to avoid talking about things for you, can't you just grow up and let me be lazy and direct and sometimes rude as I tell you everything I have to say?" There are more sensitive ways to make such requests (and ruder ones too), it's probably better to use such methods if you want people to adopt your preferences in receiving information. It's also important to ask if people want certain information in the first place -- I asked a departing intern once (who sadly ended up not being very strong, at least compared to most interns our team had) if they would like some more candid feedback from me before they left, and they declined. That's fine. I think it's usually better to lead by example and just ask people to be direct if you notice them communicating to you in overly sensitive ways and perhaps leaving important things out, and link them to Crocker's rules if you want. Often the rules aren't needed and you can just create a direct and information-rich culture to begin with, or in specific circumstances (e.g. code reviews) use short hand symbols like "Nit: " or "Blocker: " that compress all the niceties you'd otherwise be encouraged to say. When someone new joins, they can read the room, but pay attention if some people express things like "I wish people were nicer here". Maybe they're a snowflake who needs to grow up, or maybe your environment is just toxic and so unpleasant and full of assholes that it gets in the way of productive work. Again, Crocker's rules is about receiving information independent of nice/rude presentation, it doesn't require rudeness or even directness or bluntness since none of those are automatically implied by efficient communication. (Efficient communication optimized for information is not just a character count.)
A personal example from 12 years ago: after I was rejected after an onsite job interview, with such rejections notoriously (and for sound legal reasons) omitting many details about the precise whys for the rejection, I invoked Crocker's rules in my request for further feedback and actually received some more useful information than the initial rejection. "The particular role ... required more experience ... There was also the sense that the manner in which you had answered questions came off a bit rough around the edges ... We tend to look for engineers who are very curious, passionate, and large drive/motivation to learn more - it seemed we didn't get those senses from you." The last bit especially was kind of an oof, but it was certainly useful feedback that going forward I, believing myself to actually be curious and wanting to learn more (passion has always been a problem though), would need to make more efforts to show those traits.
In general, no, but sometimes, yes, or at least linked from the commit the same way user stories/issues are. Admittedly the 'sometimes' from my perspective is mostly when there's a need to educate fellow humans about what's possible or about good prompt techniques and workarounds for the AI being dumb. It can also reveal more of x% by AI, y% by human by for example diffing the outputs from the session against the final commits.
Looks like a sibling comment mentioned the proper documentation home. And OMFG cliki is still down... 17 days ago it was "being worked on, being brought onto new infrastructure". It will be back eventually... But a lot of Lisp people aren't really web dev people, for better and worse. (Having any significant downtime for such a service is nuts to me.)
You might be right about typically needing deep implementation support but that hasn't really stopped people from trying to do all sorts of concurrency approaches with Common Lisp including async ones. Ones of note are listed here: https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil... Usually they are still built on the native threads, though, but cl-coroutine is built on cl-cont (continuation passing style) which has also served as a foundation for building green threads with e.g. https://codeberg.org/thezerobit/green-threads cl-async is also odd as being built on libuv, and similarly there's libev bindings with https://github.com/fukamachi/lev that power the webserver woo: https://github.com/fukamachi/woo (Which as of 10 years ago, had comparable performance with Go in reqs/s.) (That timing makes me want to add that personally, after trying things and experiencing the hype of the 2010s, at the end of the day I think async-driven code is harder to understand than thread-driven code with some concurrent data structures, blocking queues, and the occasional promise/future. The need for more lightweight non-kernel threads is pretty context dependent.)
So what did you do? Clearly you didn't die. Did you just have no insurance for the week before the new job started, or what?
This also happened to you while you were working and slightly between jobs. So it's not really a FIRE concern if the concern is the US messing up the health care system even more in that it would effect everyone whether working or not. Generally speaking, an answer to mitigating a lot of types of risk with a FIRE model is: you just go back to work for a while. This is easier the younger you are.
Edit: Also I thought COBRA would have been a more recent thing but it was Regan era. So did you not have employer-sponsored coverage with the startup?
No, my then fiance/now wife and I canceled our wedding we had planned, and went to the courthouse and got married six months earlier so I could get on her insurance.
Also, just so happen I did end up in the hospital three weeks later because something happened that affected my breathing for an entire year.
And how do you “go back to work” if the entire reason you need to go back to work is that you have a health condition?
If you haven’t checked, jobs aren’t that easy to come by quickly in 2026 in tech like they use to be. Sure I could find someone to give me a contract if not hire me full time - but we are still back to not having insurance .
The US messing up insurance on the open market is the concern and it being back like it was pre ACA. That only affects the unemployed under 65.
As far as being between jobs - usually you can get COBRA for a limited amount of time - not an option for FIRE.
Oh yeah, that brings up another point, I did pay for COBRA for two months back then. The contract I had paid more than enough to afford it. Then the acquiring company shut down their insurance plan and COBRA wasn’t even an option
Nope, it's just mindful capital allocation. There are plenty of ways to spend money wisely on a wedding. It's just a big party, and maybe a traditional ceremony. It's whatever you want it to be.
I haven't kept up with the Claude plays stuff, did it ever actually beat the game? I was under the impression that the harness was artificially hampering it considering how comparatively more easily various versions of ChatGPT and Gemini had beat the game and even moved on to beating Pokemon Crystal.
The Claude Plays Pokemon stream with a minimal harness is a far more significant test of model intelligence compared to the Gemini Plays Pokemon stream (which automatically maintains a map of everything that has been seen on the current map) and the GPT Plays Pokemon stream (which does that AND has an extremely detailed prompt which more or less railroads the AI into not making this mistakes it wants to make). The latter two harnesses have become too easy for the latest generations of model, enough so that they're not really testing anything anymore.
Claude Plays Pokemon is currently stuck in Victory Road, doing the Sokoban puzzles which are both the last puzzles in the game and by far the most difficult for AIs to do. Opus 4.5 made it there but was completely hopeless, 4.6 made it there and is is showing some signs of maaaaaybe being eventually bruteforce through the puzzles, but personally I think it will get stuck or undo its progress, and that Claude 4.7 or 5 will be the one to actually beat the game.
This is a nice and unexpected release, thanks for writing it. Getting a RPG endorsement is great. I just finished reading his foreword and skimming the table of contents and bibliography from the preview. I'd have liked to see a sample of a middle chapter to really see how technical and deep it gets (e.g. Land of Lisp gives its chapter 8 as a sample which I think is very representative for that book). But I plan to get this book regardless -- just not right now.
The back blurb hints that expert systems might be mentioned, but how much? No one ever seems to go much into their implementation or usage.[0] It also mentions writing some JS, which I guess is part of chapter 5, I wonder if that was a publisher request. (My favorite take on that subject in recent years is https://github.com/jart/sectorlisp)
Would it be fair to say this is mainly a history told through the lens of AI and PL research?
Amusingly I think part of me is already setting myself up for some disappointment -- it seems too short with too few references! But it's good to have a Lisp history book like this looks to be and I'm sure I'll learn things from it, and the promise of more RPG writings inside is enticing. Besides, any complete telling would take multiple books. (There's so much of historical interest locked up in proprietary applications and companies with their own histories, and so many papers published, there's also so much that can be dug through in the standardization mailing list (and other lists, like emacs) archives[1], the SAIL archives[2], the Xerox PARC archives[3], the CMU archives[4], and the many undigitized things sitting in boxes at the computer history museum...[5])
[5] Even in the earliest Lisp reports like https://www.researchgate.net/publication/42766480_Artificial... there are interesting things mentioned like a two-move checkmate program or "Other projects on which work continues include the Advice Taker, visual pattern recognition, and an artificial hand." Multiple times I've tried to track down those sorts of things mentioned in really old papers only to hit dead-ends on so many of them. Sometimes things were embellished, or were abandoned, or were just lost to time, and sometimes there's an undigitized box at the museum that might contain printouts etc. (There might be MYCIN source code, even.)
Yes, the book doesn't do Lisp justice, it is too short. But at the current volume, I had something at least passing muster; I'm toying with extending it but that depends on feedback/success/etc. There are a lot of Lisp implementations I haven't mentioned (or dealt with in the depth they deserve), there is a lot more to say about the sort of AI work that was (and, I think, is) done with Lisp, etc. And I have written it with a "general techie" audience in mind more than "I'm already a hardcore Lisper", I will probably disappoint the latter group with a lack of depth. I haven't aspired to LOL or PAIP or similar great works.
It's a history through a lens, but if there is one I'd say "MIT/Stanford" as a central axis rather than a field of reesarch.
And Javascript? My own choice. The amount of "language" I needed was very small and I actually like the very minimalistic (lisp-y?) sort of Javascript you can write these days if you just ignore most of its history. It's accessible, that was more important to me than anything else - one of the few concessions where I wanted to make things digestible to as wide an audience as possible in a language that was good for the problem at hand. Strangely enough, it worked very well (I think).
I heard your (and others') request for a better sample chapter than the intro that Amazon shows, I'll put it on the site as soon as possible.
That choice absolutely makes sense, once you recall that Brendan Eich was initially hired to write a Scheme! Business and Netscape being what they are, it ended up with Javascript, but there are some lispy roots.
I went for the somewhat humbler reasons of "I can assume that my reader will know it at least a bit" and "simple to obtain" - a bunch of the examples will run in the browser :-)
But yes, JS' dynamic/LISP-y roots did make my examples simple to implement and thus simple to follow. No trickery was needed, it was all pretty straightforward.
(JS is a much maligned language and for very good reasons, it had a shaky past and still is too full of warts that should be excised at some point. But modern JS with the help of modern IDEs isn't actually _that_ terrible and traits like it being prototype-based make some otherwise complicated things easy)
reply