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.
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?
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.
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.
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.
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.
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.