He's also recently been on Empire [1], the Goalhanger podcast — and sister show to the great The Rest is History (which I hope will cover this period someday, though they tend not to go back that far in time) — in a series of episodes on the late Bronze Age collapse, which had Stephen Fry as a guest as well.
Cline does cover the evidence of destruction, which is also talked about in the other episodes. But the thing about drought is that we have written communications between different rules documenting that they were struggling with food supply.
An aside: For some reason I find Cline super annoying to listen to — his voice, drawl, and odd cadence triggers something visceral in me. But I admit he knows his stuff.
Counterpoint: All of the current Postgres codebase is already wrapped in an invisible unsafe{}.
The difference with a Rust codebase like this is that all of the unsafe code has been neatly isolated and clearly marked. The outside code is safe — at least according to the definition of what Rust considers safe, which is a high bar indeed and objectively superior to the unsafe mess that is C — and the unsafe code is naturally fenced in, which means that it can be seen by developers and tackled by incrementally.
In some cases unsafe is unavoidable, but it is possible for a human to verify that it is, in fact, acceptably safe even if inside an unsafe block.
People bring this up a lot. What I see here is that thousands of potentially (not actually, just potentially) safety risks have been neatly tagged in the code.
If you took a program written in Zig, Go, C++, or C, you would have no idea which parts of the code were potentially unsafe. In those languages, the entire program is one big unsafe{} block.
Rust isolates unsafe code. Having them explicitly tagged means they're isolated and can be eradicated over time, if need be. Though in many cases, unsafe blocks are quite safe.
For those struggling to find tech specs: Apparently [1] it has a 2MP CMOS sensor, F2.4 aperture, 24mm equivalent wide-angle lens, and shoots a resolution of 1920x1080.
My memory is fuzzy here, so I may be wrong. But I remember the generation of buggy WYSIWYG editors that preceded ProseMirror, and they were all contenteditable-based. They would typically start by attaching to a textarea, but then replace it with a div.
While these use contenteditable, it's not accurate to say they're just contenteditable plus some UI and interop.
None of these modern editors (Wordgard, ProseMirror, Lexical, Slate) use contenteditable for the document model. Rather, they have their own internal document model and use contenteditable as a kind of input layer where the editor monitors what the browser does, then translates that into actual edits.
Early editors like FCKEditor and TinyMCE were only wrappers around contenteditable. They used the DOM as the real document model, then intercepted certain keypresses and events and "fixed" the behavior when it wasn't correct (e.g. double enter inside a bullet list should switch to paragraph mode).
The result was rife with bugs and inconsistencies, and didn't allow for a proper split between the model and the view (e.g. to represent columns, video embeds, and so on).
Hello! I was definitely not looking to block all network access. I would want to maintain a whitelist of hosts and IPs. I don't know if that's possible?
Always interesting to see new HN apps, and this one seems OK.
Personally I prefer HACK [1], which is probably the most extensive HN client for iOS. The amount of options for controlling the look of the app means you can influence the reading experience quite a bit, which isn't true for this new app.
My biggest complaint with HACK is search. Instead of a real UI, it uses its own kludgy search syntax to control what to filter. For example, "foo #stories" filters stories only.
You might like HACK [1], then. It has a large set of options (maybe too many!) to change fonts, styles, colors, and spacing. It's probably the most extensive HN client for iOS.
Seconding this. I've been running Safehouse for months and love that it can wrap any process (it's just a wrapper around the native macOS sandbox API, after all). The only thing I miss is the ability to limit network access, which isn't supported by the API.
Postgres's whole origin story is basically to think outside the box and don't be constrained by existing thinking. Stonebraker thought existing databases were too limited in terms of their data types and expressiveness. He started Postgres as an evolution of Ingres (Postgres = Post Ingres) that added rich custom data types and a rewriting system based on rules.
Columnar and all the other fun stuff (JSON, GIS, inverted indexes, embedding vectors) is a natural progression of that thinking. With TimescaleDB, Hydra, Citus, pg_mooncake, etc. becoming very popular the last few years, there is a clear demand for an integrated experience.
(Stonebraker also thought one database shouldn't do everything, as described in his early 2000s "One Size Does Not Fit All" paper, and Stonebraker branched out into HStore/Vertica for columnar. In hindsight, I think that was appropriate for the time, but no longer a significant concern.)
The onus is on the DMCA processor to verify the legitimacy of the claim. I don't have a real solution, but Congress created the problem and should solve it.
There's of course a whole legal system that has been dealing with this since for ever.
If I were to implement it myself, I'd use a third party service like those that can verify passports and driver's licenses and so on.
A good start would be to require that claimants must verify their real identity. The claim in this case was made by an apparent pseudonym and their address is fictional. Both should themselves be reason to reject the claim. The fact that anyone apparently can submit claims to Google under false names seems insane to me.
I love sqlc, but I think it's more fair to say it's an SQL code generator for Postgres and Go. Everything else is much less well-supported. You can pretty much forget about trying to use it with ClickHouse or SQLite, for example.
It's also a project that seems to be suffering a bit from maintainer burnout. Important bugs aren't being fixed and contributor PRs aren't being merged. It took months to merge support for the new "\restrict" syntax introduced in Postgres 17's SQL schema dump format, for example.
You shouldn't do this, as others have said. Also, some medications must not be crushed at all.
In my experience, the best way to give cats pills is a pill pocket, e.g. from Greenies [1]. The pocket is a hollow, soft cat treat. You put the pill inside the pocket, close it, and feed it to the cat. With some larger pills, you may have to split them up (if the medication allows). Some cats don't love the flavor, but you can use a sauce packet and coat it with some sauce.
I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly.
When I say "benchmark the query engine using the foobar dataset and compare it to run 431", the agents go and run my special benchmark tool and use the different subcommands to compare results and so on.
I'm sure a new VCS would be a little less smooth sailing, but not by much.
Email: [email protected]
Github: https://github.com/atombender