blevinstein
Joined 14 years ago
Joined 14 years ago
Sounds like a lot compared to annual income, but that's trivial if you're trying to retire and live off these assets until you die. Especially since public support, pensions, etc have been eviscerated.
Assuming you can get income of 5%/year from your assets (obviously depends on interest rates, investment mix, etc), 50 percent of people would need to survive on 20k/year or less to retire.
That's not being wealthy. That's choosing between abject piece, and working until you die. Dystopian.
It's not pretty, but it works, and it has become my standard practice, so that I get consistent behavior between claude cursor codex etc.
Also, SpaceX only sold a tiny portion, and Elon is only a trillionaire based on unrealized value of unsold stock. If it crashes before he sells any, he might go back to being a "normal" centi-billionaire.
(The other common cry is "child sex abuse" but for obvious reasons this administration is less interested in talking about that particular topic.)
I want to code from my mobile device when my laptop is off or unavailable, pushing PRs directly to GitHub. Codex mobile only works with a desktop machine, at which point, I'll just use that machine, what's the point.
Google has dozens of properties and it is easy to generate an email from one of them that seems to confirm the attacker's identity. Never trust any of these to identify a legitimate representative.
The best solution to hallucination and inaccuracy is to give the LLM mechanisms for looking up the information it lacks. Tools, MCP, RAG, etc are crucial for use cases where you are looking for factual responses.
https://www.reddit.com/r/googleworkspace/s/NtJpputXtg
There was something in Google workspace that allowed the scanners to have an email sent to them, AND an additional and of their choice. But when I asked about calling them back, I was told that wasn't possible, which made me suspicious.
There definitely is a technical debt bankruptcy option.
You can stop using a particular piece of code or technology, e.g. by replacing it (with new code, or a third-party/vendor solution), or re-architecting a system or business process so that the code's function is no longer needed.
This is exactly what the technical debt metaphor means. Short-lived systems can accumulate a lot of technical debt without as much concern, because you're planning to declare bankruptcy (deprecate and decommission) the code soon anyways; long-lived systems must plan to pay off their technical debt on the usual installment plan.