Hacker Newsnew | past | comments | ask | show | jobs | submit | Arch485's commentslogin

Is there any specific reason to use this over e.g. manually setting an "emotional score" for specific dialogue? Maybe I'm misunderstanding how this works, but from a game design perspective I'd be a bit worried about the model inferring the emotion incorrectly, or more generally having a lack of control over the specific values being used.

Good question! Actually, it complements manual settings. There are many use cases but for example, in some games with multiple followers. You sometimes get bugs where they fight each other randomly for some reason. With this system, you could check their emotional state toward each other before triggering combat, and if they're actually friendly, you prevent the unintended fight

Hey, Alexa?

It's crazy that a repair shop needs your passcode. I can't think of any case where it would be necessary.

I'm glad this person won the lawsuit though; getting your nudes leaked is a really shitty situation to be in. Apple needs to do a better job vetting their repair shops.


The problem is that Android doesn't offer a pre-boot UI for testing anything unless you flash TWRP (at which point the userdata will be wiped), and I'm not sure if iOS does either.

Yes, this sucks hard.


Can't you restart into recovery mode and run graphics test?

Stock recovery mode on most devices is as barebones as possible - it _might_ have an option to flash a signed image if you're lucky.

Often not even that. Samsung wants its proprietary Odin stuff to flash, Mediatek has their own toolsuite. Both need Windows to run.

Only ones actually using fully open source tools are Google's Pixel lineup.

But none, not even Pixel, allow for anything resembling actual "recovery" for common failure modes. Dead display at least for Samsung and Pixel means you have to install a new display if you want to access the data, otherwise it won't even pass the first bootloader stage, much less boot into the OS or unlock the encryption. Something gone corrupt with the OS? Same case. If you can't manage to boot at least to the Android Safe Mode, you're out of luck. And no HW self-test at all.


Recovery mode on stock Android offers nothing other than wipe userdata and partially update firmware, that's the thing.

My stock Galaxy S24 has this option. Its the most popular Android phone of that year, no?

Sounds like a new religion in the making!


To add: AFAIK most adult content websites bill under a different, innocuous name as well. You don't get a charge on your credit card from BigBussomsCom, you get a charge from SuperCard or something like that. (uh... I know because of a friend...)


Yeah. Never dealt with an adult content website, but in my admittedly limited experience adult products always come in innocent packaging and generally bill under innocuous names.


It looks to me more like bad Photoshop, not AI. Like a real photo with a bunch of elements comped in on top, like you'd see in historical edutainment content back in the 2010s or earlier.


This is something I think a lot of people miss about Rust - outside of slow compile times and personal preference, there is no reason not to choose Rust over JavaScript/TypeScript (unless of course you're working in the browser). It does everything JavaScript can do, but it does it faster and with more stability. At the end of the day, these features pay out huge dividends.

And this isn't Rust zealotry! I think this goes for any memory-safe AoT language that has a good ecosystem (e.g. Go or C#): why use JavaScript when other languages do it better?


Rust's type system gymnastics compared to most languages goes quite a bit beyond preference. I can't see the overlap at all with dynamic scripting languages, two completely different tools for completely different problems.


TS has one of the more gymnastics-heavy type systems, IMO, and I think many if not most JS shops use TS.


TS is gradual though, Rust is all or nothing.


A world of difference between the borrow checker and a garbage collector.


> there is no reason not to choose Rust

Sounds like Rust zealotry to me, followed by a mild attempt to walk it back.


> any task that has any sort of safety or security critical risks should never be left to a “magic black box”. > human input/review/verification/validation is always required.

but, are humans not also a magic black box? We don't know what's going on in other people's heads, and while you can communicate with a human and tell them to do something, they are prone to misunderstanding, not listening, or lying. (which is quite similar to how LLMs behave!)


Well if a human consistently hallucinates as much as an LLM, you definitely not want them employed and would probably recommend they go to rehab.


from my comment

> at the same time, i could totally see myself scanning through a README and going “yep, sounds like what i need” and making the same mistake (i need other people checking my work too).

yes, us humans have similar issues to the magic black box. i’m not arguing humans are perfect.

this is why we have human code review, tests, staging environments etc. in the release cycle. especially so in safety/security critical contexts. plus warnings from things like register articles/CVEs to keep track of.

like i said. don’t blindly trust the untrusted output (code) of these things — always verify it. like making sure your dependencies aren’t actually crypto miners. we should be doing that normally. but some people still seem to believe the hype about these “magic black box oracles”.

the whole “agentic”/mcp/vibe-coding pattern sounds completely fucking nightmare-ish to me as it reeks of “blindly trust everything LLM throws at you despite what we’ve learned in the last 20 years of software development”.


Sounds like we just need to treat LLMs and humans similarly: accept they are fallible, put review processes in place when it matters if they fail, increase stringency of review as stakes increase.

Vibe coding is all about deciding it doesn’t matter if the implementation is perfect. And that’s true for some things!


> Vibe coding is all about deciding it doesn’t matter if the implementation is perfect. And that’s true for some things!

i was going to say, sure yeah i’m currently building a portfolio/personal website for myself in react/ts, purely for interview showing off etc. probably a good candidate for “vibe coding”, right? here’s the problem - which is explicitly discussed in the article - vibe coding this thing can bring in a bunch of horrible dependencies that do nefarious things.

so i’d be sitting in an interview showing off a few bits and pieces and suddenly their CPU usage spikes at 100% util over all cores because my vibe-coded personal site has a crypto miner package installed and i never noticed. maybe it does some data exfiltration as well just for shits and giggles. or maybe it does <insert some really dark thing here>.

“safety and security critical” applies in way more situations than people think it does within software engineering. so many mundane/boring/vibe-it-out-the-way things we do as software engineers have implicit security considerations to bear in mind (do i install package A or package B?). which is why i find the entire concept of “vibe-coding” to be nightmarish - it treats everything as a secondary consideration to convenience and laziness, including basic and boring security practices like “don’t just randomly install shit”.


> We don't know what's going on in other people's heads

I don't know about you, but for most people theory of mind develops around age 2...


Why not use Lua for config instead of TOML? IIRC Lua was originally a data schema language, so it should be good for it.


Is there a good reason to introduce the halting problem to a package manifest?


Lua has a sandboxed runtime so couldn't you kill rogue scripts after a timeout?


Would you rather do that or use toml?


Lua was designed for configuration, so I'd rather use Lua. Plus, it makes for a more elegant, unified design. TOML, and friends, are better paired with languages that were not designed for configuration.


It seems like every new language community and generation of developers needs to re-learn a set of the same lessons (why declarative instead of imperative config is the way to go, why functional is superior to imperative, why immutable is superior to mutable, why TDD (or just unit testing) is important, why hexagonal design is the best organization of logic, why static typing is important, why Nix is the only valid global package manager, etc. etc. etc.) and I suspect it's because these problems all share the same attributes:

1) the inferior solution seems easier at first (but won't be in the long run)

2) the people blithely picking the inferior solution have not yet encountered enough of the thorny nastiness that the initially-harder option completely prevents

the end result being that all the "greybeards" have settled on the "initially harder" solutions for things because they all learned the hard way that it just causes less headaches in the long run


I know what lua was designed for and have professional experience with it. It's not that great as a config language imo, I can easily understand why a project would use something else.


With Lua, it becomes near impossible for a program like lux to edit the manifest.

For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?


Indeed. I'm glad for us to have learned Python's 20 year lesson on the dangers of an executable manifest.


The Zig language seems to have learned the lesson the other way though: https://ziglang.org/learn/build-system/


Isn't build.zig.zon the equivalent of the manifest in that case though?


Sure, but a zon file is really just an anonymous zig struct.


With the disclaimer that I know nothing about zig, I will say that Nix's flake files follow an interesting pattern where the output section is evaluated under the regular Nix interpreter and can do anything, whereas the input section is evaluated under a far stricter mini-interpreter that prohibits everything other than basic strings and attrsets (dictionaries).

A flake.nix is certainly not packaging metadata, but I do know those input section restrictions do cause occasional confusion with users who think "ah, Nix code" and only realise afterward that it's really json in Nix syntax."

All that to say, if a thing is not evaluate-able, it's probably best to represent it in a different enough form that no one could mistake it for a thing that can be evaluated.


Why not use a function to add dependencies, e.g. `add_dependency "dependency@version"` or `add_dependencies { ...table-here... }`. This is, more or less, how premake works [1]. For `lx add ...` you'd append the function call to the script.

[1] https://premake.github.io/docs/Your-First-Script


That doesn't seem very ergonomic - especially for the use cases we have in mind.


Load the table. Modify. Serialize to file.

Not too hard. Emacs does it with the .emacs file, mixing generated and manual content.


> Load the table

If it comes from an impure function, you don't know if you'll get the same result each time you evaluate it.

> Modify. Serialize to file.

And potentially lose information.


Location: Stockholm, Sweden

Remote: Yes. On-site is also OK.

Willing to relocate: Yes.

Technologies: JavaScript/TypeScript, Python, C#, C++, C, PHP, Rust, Dart/Flutter, Zig, PostgreSQL, MySQL, SQLite, Cloudflare, and more...

Résumé/CV: https://resume.kurtisknodel.com/

Email: kurtis@kurtisknodel.com

Hi, I'm Kurtis. I've been programming for ~10 years, 3 years professionally. I'm currently looking for a project that has positive real-world impact; working at a company that chugs out AI slop for the betterment of stakeholders isn't really my thing. The listed technologies are in no particular order, nor are they comprehensive. For relocation: I have Canadian and EU citizenship.

Feel free to shoot me an email with any opportunities you have, or just to connect. (I'm always down to expand my network) Have a nice day :)


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: