Nitpick: the photos are labeled as "Colorized images of the surface of Venus taken by a Soviet Venera lander in 1981", but
1. those photos are from Venera 13 and 14, which were taken in color
2. the photos were taken in 1982 (though the probes launched in 1981)
and 3. those aren't the original photos, they're 'enhanced' ones that have been upscaled and extended to show more of the horizon and sky than the originals. The bottom 1/4 or so is the actual original, give or take a few details that have been changed/added in the upscale process, but the rest is artistic interpretation
The Venera panoramas are spherical projections. They can be remapped to perspective projections and overlayed (using Adobe Photoshop CS2) to produce views that give a better subjective impression of the Venusian surface
That does seem to be what the page is implying at first glance; though the images clearly show features not visible in the raw photos, so it can't be the case. I'm guessing that paragraph is actually referring to the 'overhead' image [0] next to the one in question, since it mentions how the remapped perspective makes the uniform shadows apparent.
Same with my parents! It's the only one they use. I think the simple and stable web interface goes a long way; the ChatGPT site (for example) bombards you with popups, new buttons, and opaque daily limits, while DeepSeek's is pretty consistent and straightforward.
DeepSeek also tends to follow prompts more closely IME, plus the thinking is shown, so I think it's able to register as a 'tool' more easily for the non-tech-inclined for whom that appeals.
I hadn't heard of this my entire life, but now three times in the past week I've seen it randomly pop up. Did I miss something, or is it just the frequency illusion at work?
ecode [0] is ridiculously fast -- makes Zed feel like molasses -- and quite customizable. It's still early in development and mostly just made by one guy (who is also developing the GUI framework used), so progress is slow and there are some rough edges, but it has all the important stuff and quite a few niceties too. Really cool project, reminds me of Sublime.
Semi off-topic, but does anyone know of good resources for jj that don't assume git knowledge? Steve's and others are high quality, but often things are explained in terms of git equivalents or describe workflows that I struggle to fully understand the purpose of, as someone who knows only the barest basics of git necessary to work on personal projects.
If none exist, I think there's a great opportunity there, for anyone with the knowledge and motivation to make some absolute beginner guides. Already jj is infinitely more user-friendly, and as the tool matures, it isn't far fetched to think a new generation of programmers could go straight to jj without knowing their way around git first.
> This is a tutorial for the Jujutsu version control system. It requires no previous experience with Git or any other version control system.
> At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This tutorial is my attempt to fill the void of beginner learning material for Jujutsu.
I'm not immediately aware. There's a certain amount of git-ness embedded in it with it being a DAG, having commits, and being compatible with git remotes. And, since the industry still runs on git, most people will need to learn it somewhat, anyway.
I've been using it in relatively the same way for a while now. The only meaningful changes were native support for `tug` and `absorb`, neither of which significantly changed my workflow.
eh, there have been a good amount of breaking changes. `-d`/`--destination` → `-o`/`--onto` (the former isn't yet deprecated though); deprecated `--allow-new` on push (or, forcibly making it the default for `--bookmark`); deprecated `jj bookmark track foo@bar` (and `jj bookmark track foo` having a really-weird system (I personally just call it broken, even though the behavior is intentional) of sometimes tracking the bookmark on all remotes; really I'd call jj's entire system of bookmark tracking/pulling/pushing quite incomplete outside of the trivial cases); various changed revset functions over time that break configs; and a really-annoying thing of `jj git fetch` sometimes abandoning ascendants of `@` leaving you in a confusing state (if not one with conflicts), with the solution being a future `jj git sync`.
It's certainly very usable despite all that, and the changes are simple enough to adapt to, but it's a pretty new thing.
Man, same here, those early days of Cursor were mindblowing; but since then autocomplete has stagnated, and even the new Cursor version is veering agentic like everything else.
I hope if/when diffusion models get a little more traction down the line it'll put some new life into autocomplete(-adjacent) workflows. The virtually instantaneous responses of Inception's Mercury models [0] still feel a little like magic; all it's missing is the refinement and deep editor integration of Cursor.
On the subject of diffusion models, it's a shame there aren't any significant open-weight models out there, because it seems like such a perfect fit for local use.
We didn't find evidence of life on the asteroid; rather, we found the necessary building blocks for it, which, in the right environment (e.g. earth), could become life.
If anything it slightly moves the scales toward abiogenesis, since it implies the necessary precursors to life were common in the early solar system, though it's certainly not conclusive either way.
Or the warm early universe hypothesis. In its early life, the entire universe was at a temperature that could sustain liquid water literally anywhere. The idea being, in this hypothesis, life was literally everywhere and then went dormant.
I'm building my ideal backend for small projects and hobby stuff. It's inspired by PocketBase, but built around Lua scripting instead of built-in endpoints or usage as a Go library.
Like PocketBase, it's made in Go, has an admin panel, and compiles down to one executable. Here, you write your endpoints as Lua scripts with a simple API for interfacing with requests and the built-in SQLite database. It's minimal and sticks close to being a bare wrapper around the underlying tech (HTTP, SQL, simple file routing), but comes with some niceties too, like automatic backups, a staging server, and a code editor inside the admin panel for quick changes.
It comes from wanting a server that pairs well with htmx (and the backend-first approach in general) that's comfy to use like a CMS. It's not exactly a groundbreaking project, and it still has a ways to go, but I think it's shaping up pretty nicely :)
reply