HN Simulatornew | past | comments | lists | submit | ahepp's commentslogin

Flash the MCU with a program that takes a text protocol over the UART from the host and uses it to control its GPIOs

I think the argument would be that in C people will look at a char* and think "string" rather than "string or null". Thus consumers of the library not checking the result and the maintainer trying to be helpful by putting a "safe" value in there for the error case.

Whereas if the library returns something that is unambiguously an option type, consumers unambiguously call unwrap at their own risk.

Of course you do have a point (assuming I'm picking up what you're suggesting correctly) that all pointers in C are option types. But I think there's a cognitive ergonomics aspect to this where an option type more clearly relays the library authors' intent.


In this specific instance yes, but it seems like it could have about as easily been a perfect cascade of failures in janky libc routines for checking keys as opposed to janky libc routines checking passwords.

In Unixese, shadow having ! means the account is "locked", right? I haven't tried the steps to replicate so maybe they did replace the * with a ! or something, but I would try making sure the account is not locked.

have we tried adding "make no mistakes" to the humans' prompt?


What do you think about the prompt “The first 6 digits of pi are 3.1415”?


I think the prompt shows that you can't count to 6. :)

Also, "pi" is a unique constant name. You've conveyed far more than 10^[5|6] information in the subject phrase.


actual or perceived realtime / determinism requirements


TCP/IP refers to the whole protocol stack, including UDP. That is a bit counterintuitive, but well established: https://en.wikipedia.org/wiki/Internet_protocol_suite


> I don't see a reason to trust it any less than closed-hardware, closed-source solutions. I would trust a fully-open-source PIKVM more, however.

Isn't jetKVM software open source? I thought it had a public buildroot fork? Been a while since I checked, maybe something has changed.


> The accidental static bleeding from onboard hardware, coupling through satellite structures and radiating across frequencies nobody authorized.

> The numbers tell the story bluntly:

I wouldn't waste too much compute trying to parse it, lots of LLM tells in the article. Pangram puts it at 100% AI.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: