dezgeg

Maybe this is doable with scoped API keys instead of SSH keys?

I've understood that in more recent models you need to run extra compute to get a human-readable version of the thinking tokens, so it does impact latency. Though probably the more important motive is you can squeeze in more concurrent users by skipping this.

IIRC the initial value for the jiffies time counter in Linux kernel is initialized at boot time to something like five minutes before the wraparound point, precisely to catch this kind of issues.

For HN comments, the LLMs seem to really like 2 or 3 paragraphs long responses. It's pretty obvious when you click a profile's comments and see every comment being that exact same structure.

I believe the same author has made a ninja successor (n2) that uses hashes instead. Haven't tried personally but hopefully get around to try that in the near future

Roulette to find all those vibe coded apps with zero users, sounds great!

Bye bye getting automatic upgrades to that package.

The best thing about monorepos is nothing ever gets versioned and packaged.

That means, a subcomponent can just make a needed change in the supercomponent as well, and test and the ship the subcomponent without excess ceremonies and releases.

_FORTIFY_SOURCE is way smaller in scope (as in, closes less vulnerabilities) than -fbounds-safety.

Yeah Gemini seems to be good at giving silly answers for silly questions. E.g. if you ask for "patch notes for Chess" Gemini gives a full on meme answer and the others give something dry like "Chess is a traditional board game that has had stable rules for centuries".

In that situation one of the switches should short the mains voltage and blow the fuse when the door is opened.

No, the VFAT driver doesn't do anything even slightly resembling that.

In general "what DOS did" doesn't cut for a modern system with page and dentry caches and multiple tasks accessing the filesystem without completely horrible performance. I would be really surprised if Windows handled all those cases right with disk caching enabled.

While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.

No. There are proprietary implementations which can, though not in 100% of the cases.

Better hope you didn't have a rename in progress with the old name removed without the new name in place. Or a directory entry written pointing to a FAT chain not yet committed to the FAT.

Yes, soft updates style write ordering can help with some of the issues, but the Linux driver doesn't do that. And some of the issues are essentially unavoidable, requiring a a full fsck on each unclean shutdown.

Are you also adding the proper prompt cache control attributes? I think Anthropic API still doesn't do it automatically

I've also tried Gemini 3 for Clues by Sam and it can do really well, have not seen it make a single mistake even for Hard and Tricky ones. Haven't run it on too many puzzles though.

It has taken a turn back in the last couple of years, now in Finland even university students go to sauna in swimsuits.

USB HID actually works pretty much how you describe, for instance a Physical Descriptor can contain metadata about which body part a button/control is supposed to be used with.

It's extremely complicated however (like many things USB), which is probably why everything just emulates an XBox 360 controller like you said.

It'd be interesting to see a setup where a Linux-capable SoC would run the Arduino application on a isolated CPU core with no interrupts handled, so you'd still have real-time guarantee for the Arduino app

For handhelds the temperature of the device's case is one factor as well when deciding the thermal limits (so you don't burn the user's hands) - less of a problem on laptops.

It's possible that it's just operating the lights and turntable without actually cooking - if you search HN you find that failure mode.

When the next gen chip comes out you can usually reuse large amount of stuff.

Is that really rust-specific? I would be really surprised if any other languages do fsync() in their destructor either

Do you have this publicly available? Sounds useful!

Cool, it's something I've been trying also. Here are my attempts: https://www.youtube.com/watch?v=JZ4-YUuCVNo&list=PL8C_UWcLmv...

The Jeju Air crash from late 2024 (still under investigation) also had birds go in both engines.

I wish checksumming filesystems had some interface to expose the internal checksums. Maybe it wouldn't be useful for rsync though as filesystems should have the freedom to pick the best algorithm (so filesystem checksum of a file on different machines would be allowed to differ e.g. if filesystem block size was different). But so that e.g. git and build systems could use it to tell 'these 2 files under a same directory tree are definitely identical'.

Do you have any concrete evidence of the type of power supply being the culprit?

My personal feeling is the write patterns of Linux distros and filesystems are way more punishing to the card when compared to write patterns done other use cases. For example most writes done by digital cameras are fairly big and sequential, and done on FAT/exFAT where there is no journalling.

However, it seems that extra SIBs aren't necessarily broadcast but may be available on demand... and it wasn't clear to me whether making a on-demand SIB request can be done without SIM card.

Yecchh, 5000+ lines! USB-PD is truly cursed...