chrchr

I'm not an expert, but it's frustrating to read these threads about passkeys. The common objection I see here is "But if I lose my device I'm locked out!"

A lost passkey should be treated the same as a lost password.

Sites that implement passkeys need to have an account recovery mechanism. Granted, not every site does this correctly. Don't use passkeys on sites that don't have a recovery mechanism!

Secondly, the site you're authenticating to must allow you to have multiple passkeys. You either have a cloud-synced password manager so that all of your devices get the same passkey, or you have a passkey per device that you use to access the site. Again, not every site allows multiple passkeys. Don't use passkeys on sites that don't allow you to have multiple passkeys.

For a site implements both of these properties correctly, if you lose your device, you just connect to the site with your new device, perform whatever account recovery procedure (TOTP, email verification, phone verification, ...), create a new passkey, and, ideally, disable the passkey from your lost device.

Test driven developmet practitioners in Smalltalk used to (still do?) write the test before writing the implementation, run the test, and, when the "method not implemented" error shows up in the debugger, type the implementation and continue the execution. Common Lisp can do that too.

So, in practice, it might look like you hit any kind of runtime failure, and then the LLM writes some code to fix it, and the user's request completes successfully with no errors.

This is Noctalia 5. It's a complete, standalone shell with no Quickshell dependency.

I don't think people even read the blog post, because the blog post pretty clearly explains that Laya isn't really comparable to Jev.

I vividly remember the months after AMD64 came out when tech companies were dumping their specialty RISC server hardware (mostly Sun, but some other stuff too) and replacing them with commodity AMD boxes. It was felt like a monumental shift.

Interestingly, this device uses a totally different mechanism than classic trackpoints. Where true trackpoints use a network of strain gauges on the PCB, this is a 3D hall effect sensor and a spring. A trackpoint has only an imperceptible amount of travel, and this is designed to physically move. I really wonder how it feels in practice. It might feel more like a thumb stick from a game controller than a trackpoint.

Yes, but on the other hand, there's https://www.reddit.com/r/ididnthaveeggs/, which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.

It's funny that they call it "reverse game theory", like it's a new thing, when it's actually just regular game theory.

Amazon developers use similar devboxes. I think it is mostly so that developers can use a production-like Linux environment with integrated Amazon dev tooling. You're not required to use a devbox, but it can be easier and more convenient than running stuff on your laptop.

"Everybody on earth knowing that beauty is beautiful makes ugliness."

That resonates with so much of the discussion on this site. We're all trying to make good technology that helps people! Why does it so often fall short?

But your friend is wrong. She does know at least one person who comments on online forums. I bet she knows more too.

DankLinux provides packages for the Niri scrolling Wayland compositor and related tools, targeting popular mainstream distros: Fedora, openSUSE, Debian, and Ubuntu. Niri and related tools are still too bleeding-edge to appear in Debian or Ubuntu's official repos, so if you're interested in Niri and don't want to assemble the long list of prerequisites to compile everything yourself, this is an easy way to try it out.

While it pains me as a normie Gen-Xer to recommend anything "dank", using Niri along with DankMaterialShell [1] for configuration and launching apps lets you quickly put together a reasonably complete desktop using this repo. I've been building my own Niri binaries for a few months now, and I'm very happy that I can finally retire my build environment.

[1] https://danklinux.com/docs/dankmaterialshell/installation

There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.

I played the map mode and got a map, with labels!

Anyone interested in zippers, or, more significantly for this website, how new technologies are invented, adopted, and mature, should read "Zipper: An Exploration in Novelty" by Robert D. Friedel [1]

YKK is kind of one of the heroes of the story. The zipper was pioneered by the U.S. company Talon Fastener, which was acquired and parted out in the 1970s. YKK bought the legacy machining for manufacturing zippers and went on to dominate the global market.

[1] https://www.amazon.com/Zipper-Exploration-Robert-D-Friedel/d...

I did something like this for Python [1]. The application I worked on at the time had a feature allowing users to import and export their data as a JSON document, and users often had enough data to make this cumbersome, especially with serialization and deserialization overhead. My implementation can also generate JSON documents as they stream out, from Python generators. The incremental JSON parsing was a little difficult to use, but incremental generation was an immediate win. We generated JSON documents from database results row-by-row and streamed the output to the web server, never producing the entire document in memory.

[1] https://github.com/chrchr/flojay

I had a surprising interaction with Gemini 2.5 Pro that this project reminds me of. I was asking the LLM for help using an online CAS system to solve a system of equations, and the CAS system wasn't working as I expected. After a couple back and forths with Gemini about the CAS system, Gemini just gave me the solution. I was surprised because it's the kind of thing I don't expect LLMs to be good at. It said it used Python's sympy symbolic computation package to arrive at the solution. So, yes, the marriage of fuzzy LLMs with more rigorous tools can have powerful effects.

I also switched from PaperWM to niri, and I was reluctant to do it, because I really liked not having to configure several different little apps to get a working desktop environment. GNOME comes out of the box with an app launcher, a basic configuration editor, a screen locker, widgets for controlling audio and network, etc. But ultimately, PaperWM was too quirky. For example, sometimes PaperWM and an app would disagree about what size the app's window should be, and the window would resize itself repeatedly. The vertical sizing never worked very well either.

The reason to use a factory instead of 'new' is that a factory can vary the return type, unlike a plain constructor. You need a factory when, based on the constructor parameters or the system configuration, different classes of object may be instantiated. I really have to disagree with your characterization of the GoF book. The premise is that it's a set of designs that can be applied when specific situations are encountered, though, granted, if you're reading the book before you've actually seen the situation where a particular pattern can be applied, it seems abstract. Certainly, popular conceptions of patterns taken out of context make that problem worse.

Outside of maybe NYC, taxi service in the U.S. was totally unreliable before Uber/Lyft. It's not even a matter of price. It's so much easier to get a ride now in most of the country.

I don't think AirB&B really improved hotels, but it did organize and centralize the "vacation rental" market, making it easier to, for example, rent a beach cottage for the weekend.

Part of the answer to this puzzle is that your dishwasher itself is a robot that washes dishes, and has had enormous impact on blue collar jobs since its invention and widespread deployment. There are tons of labor saving devices out there doing blue collar work that we don't think of as robots or as AI.

I added oklab to emacs's color module. I initially intended to use it to make better procedural themes, but I haven't gotten to that yet. In any case, emacs version 30 has color-oklab-to-xyz and color-xyz-to-oklab functions that work with the other functions in emacs's color module to convert to/from oklab colors.

This approach is, arguably, more readable because it relies on a simple left-to-right evaluation. Programmers don't have to recall the complex, though often familiar, rules of operator precedence.

That doesn't explain why there's a market for "Yes". For "No" to be worth 3% instead of 0%, there must be people who think "Yes" will in some way be worth 3% or more.

Right! The explanation in the article -- that "no" holders will need to sell to buy other things before the market resolves, pushing the price up -- doesn't make sense to me. Sure, maybe the price goes up shortly before the market closes, but that's a hell of a falling knife to try to catch.

Any of those "AI companion" apps can do this very well, or so I have read!

I don't know what third candidate you think could have beaten both Trump and Harris in a three way race. "Someone else" is always a popular choice until the someone else turns out to be RFK Jr. or Vivek Ramaswamy or Kanye West. And that's beside the point. Voters had a choice between Harris, who would have been a capable defender of the health research funding that the article discusses, and Trump. They chose Trump. That was a bad choice and it was clearly a bad choice at the time. If the general election is between Pinochet and Marco Rubio you can bet I'll vote for Marco Rubio.