I think there is a difference between “nitpicking” and “discussing” details. I personally do not see any nitpicking in OP’s comment, I rather see it as valuable and well-presented contribution to the general (wholistic) discussion.
To me, your response would have been just fine with only the last sentence.
> in general people would like their IDE to run language servers, set up build systems, and any number of other things
That I understand, I’m mainly wondering why all that would have to happen automatically by merely opening a folder.
My personal preference may differ here, but for things like running a build or starting a dev server, I usually prefer to trigger them manually, and not have them silently executed only by me browsing through the sources.
Therefore I’m trying to understand whether there are legitimate use-cases for this “auto-run on open folder” feature besides the obvious convenience aspect of saving one or two extra clicks.
Not a VSCode user, so a genuine question: what are practical use-cases in which you want VSCode to automatically execute a task only by opening a folder?
Is it only for convenience so it already `npm i` or `npm start` without you having to do anything, or are there any other legitimate purposes beyond that?
I find the “no light” bit in the subtitle confusing, as the article says he had “a torch as his only light source”. I get that a torch is not much light, but it’s still significantly different from “no light”. Or maybe they meant “no daylight”, but that seems hardly worth to mention for a cave.
This limitation comes with more interesting implications: e.g., I noticed that some bike trips are noticeably slower than average. For those I’d assume that the rider either took a detour or made a stop in between. The animation, however, makes it appear as if it was a very slow ride. Maybe worth considering to filter out all rides that are essentially walking speed or slower.
It also would be interesting to learn how many rides had been excluded altogether, just to put things into perspective.
> piracy is often the only option to ”own” any media at all.
Maybe I’m misunderstanding something here, but I find that nowadays the process of buying high-quality, DRM-free MP3 music is as simple and straightforward as it can be: you purchase the files (on Bandcamp, Amazon, Apple Music, etc.), download them legally, and then physically own them forever.
By the way, when purchasing through Bandcamp, 80+% goes to the artist (https://bandcamp.com/fair_trade_music_policy). So not only do you own the music, but you also make sure the artist is properly paid for their work.
On macOS, I find “3 finger drag” very convenient to use, and for me it works a lot better than “press and hold”. (https://support.apple.com/en-us/102341) It even allows you to briefly lift your fingers to reposition them on the trackpad without stopping the drag action.
To me, it would have been clearer to avoid the “Demo” button label altogether and be explicit about the different versions and OS targets. Also, I think the visual hierarchy of the two respective buttons is too subtle.
> I have yet to see any solid, significant evidence that passkeys are materially more secure than a random 32-character password + TOTP 2FA.
I think the main selling point of passkeys is their ability to prevent phishing.
A 32-character password + TOTP can still be entered on a phishing website, e.g. if you happen to follow a fabricated link. With passkeys, this is not possible by design.
> I find that the drag and drop experience can quickly become a nightmare, especially on mobile.
To me, drag and drop is only a nightmare on mobile. On desktop (using a mouse or trackpad), drag and drop actually works quite well.
Your design experiment reminds me of a recent talk of Scott Jenson, where he talked about how we just took over established UX patterns from desktop to mobile as is, and how that created all sorts of nuisances. (https://youtu.be/1fZTOjd_bOQ?t=1565)
If mobile drag&drop was implemented like you are suggesting from the very start, I actually might have preferred that over the situation we now ended up with.
One technical note on your implementation: on certain mobile browsers, there is a glitch where the UI can jump around as the browser dynamically slides top or bottom menu bars in and out.
> You will not think about liquid glass after a day, especially if you turn on the new options.
I wouldn’t say so. The “Increase Contrast” and “Show Borders” accessibility options make liquid glass just bearable to me, but the new UI design is still ungracefully buggy and unnecessarily hard(er) to use. (See e.g. https://www.nngroup.com/articles/liquid-glass/ for a detailed discussion.)
Sure, life goes on. However, considering the price tag of an iPhone/iPad, I understand how iOS 26 is off-putting to so many people – despite all the other new features.
It seems OP bought the gift card themselves as a means to top up their account balance (https://news.ycombinator.com/item?id=46252989). They basically used the gift card as an alternative payment option.
To me, your response would have been just fine with only the last sentence.