jotaen

> I would assume, however, that they didn't "fake" it - that they instead chose a filming position and lens such that camera was obscured behind the edge of the device

I’d suspect the same. From that angle, the camera bump is on the opposite edge; when I hold my iPad Air in the same position, the camera bump is also just about hidden.

That being said, I’d also suspect that Apple chose that angle deliberately.

> Are there any limitations compared to a native app?

Probably only minor ones; three come to mind:

- The web app has to be loaded every time (~700K total right now), whereas the native app works offline. This could be mitigated with a progressive web app, though.

- Fullscreen mode is usually blocked by mobile devices for websites, so you always see e.g. the address bar. That’s just a visual thing, though.

- I’d assume that native audio APIs would allow for more control (and are likely easier to work with too).

I’m wondering whether anything could be done in terms of name/“tagline” to clarify this? (Or maybe this is just a peculiar niche?)

I’m still using [x]it! every day for tracking daily todos or various check lists (e.g. tracking payments or packing lists) – same for klog, by the way, which I use for time tracking.

I consider the [x]it! file format mostly complete, so in a way there isn’t much for me to do anymore. But I guess that’s also a good thing about such standards – that there is little to no maintenance burden compared to “actual” software.

(Links for reference: https://xit.jotaen.net and https://klog.jotaen.net)

> For the first time in a decade or so you can buy a PHYSICAL key and use it to sign into websites. I can explain this to any grandma out there.

What would you answer if grandma asked you what happens if she loses her physical key?

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.

README on Github says “pi.dev domain graciously donated by exe.dev” (though that doesn’t say anything about the original price of course).

The post says their web frontend was public.

This is the portfolio website of an event agency, not the Gmail website.

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

The submission’s map includes the affected area of the power outage, so that info is already public, isn’t it? https://openinframap.org/#12.98/52.43214/13.26948

> The area to the east of the power station

s/east/west/

(I.e., the area left of the power station.)

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.

Not sure what you are insinuating, but 30–45 minutes per month to stay on top on your finances doesn’t sound particularly crazy to me.

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

I think you should better post this separately, e.g. as “Show HN”. It’s off-topic for this thread (hence, I assume, the downvotes).

Not OP, but it looks like the wording of their downloads page (https://videohubapp.com/en/download/) is slightly confusing:

- Clicking “Demo” (for macOS) points to the 3.2.0 ARM version

- Clicking “Intel Mac” points to the 3.1.0 (!) Intel version

The Github release page appears to list all available versions: https://github.com/whyboris/Video-Hub-App/releases

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.

This looks like an interesting concept!

> 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, “imagine” would have been a more fitting term here.

(“Generate”, while correct, sounds too technical, and “confabulate” reads a bit obscure.)