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

Pay 100 Gold or 15 Gems to generate this feature

You joke but as a parent, I’m so sick of the gem packs, etc. they try to push on the kids to obfuscate your actual spend on games in real world money.

And now it feels like the are gamifying the compute we use for work for all the same reasons.


I hate that pattern so much. It’s also not just to obfuscate the spending - it’s also to ensure you already have some amount left over in your account, so that it feels like you’re not spending as much to just “top up” and afford that one thing you want this time.

If you have some left over that you can’t spend, it feels like you’ve “wasted” them.


Please read the link you're citing

> The court held that the Copyright Act requires all eligible works to be authored by a human being. Since Dr. Thaler listed the Creativity Machine, a non-human entity, as the sole author, the application was correctly denied. The court did not address the argument that the Constitution requires human authorship, nor did it consider Dr. Thaler’s claim that he is the author by virtue of creating and using the Creativity Machine, as this argument was waived before the agency.

Or in other words: They ruled you can't register copyright with an AI listed as the author on the application. They made no comment on whether a human can be listed as the author if an AI did the work.


An earlier attempt at registering AI creations without AI attribution was rejected by the Copyright Office[1], saying that person in particular needed to make an AI attribution, which they were originally not doing.

In this case, the court is saying AI attribution is not okay, either. There is no way to register copyrights for AI creations.

It's consistent with the Copyright Office's interpretation of copyright law where it holds that it only applies to human creations and doesn't apply to non-human creations, which is what they say AI creations fall under:

> The Copyright Office affirms that existing principles of copyright law are flexible enough to apply to this new technology, as they have applied to technological innovations in the past. It concludes that the outputs of generative AI can be protected by copyright only where a human author has determined sufficient expressive elements. This can include situations where a human-authored work is perceptible in an AI output, or a human makes creative arrangements or modifications of the output, but not the mere provision of prompts.

[1] https://www.copyright.gov/rulings-filings/review-board/docs/...

[2] https://newsroom.loc.gov/news/copyright-office-releases-part...


The most controversial part is that they wrote a TUI in ReactJS, but they don't try to keep that part secret, they brag about it. :^)

Yeah as much as I avoid OpenAI for [reasons], the Rust TUI was really the move. Claude Code is a mess.

Some are stuck in 2010s, where people thought that JS was turning into a lingua franca. As usual, such delusions are costing us some pretty heavy price. People seem to now accept crappy, laggy UIs "because it makes business sense", completely ignoring that their business _is_ providing a seamless experience. ugh sorry, </rantmode>

I think the reason behind using React and JavaScript is simpler - these tools are heavily vibecoded, and React/JavaScript is what was most present in the training data and as such is what the models excels the most at generating.

The crappy laggy UIs have the same root cause - heavy use of vibecoding with lackluster quality processes


vibe coding is barely a year old, this trend is older

> RISC-V is little

These days it's bi, actually :) Although I don't see any CPU designer actually implementing that feature, except maybe MIPS (who have stopped working on their own ISA, and now want all their locked-in customers to switch to RISC-V without worrying about endianness bugs)


Well, sort of. Instruction fetch is always little-endian but data load/store can be flipped into big. But IIRC the standard profiles specify little, so it's pretty much always going to be little. But yea, technically speaking data load/store could be big. Maybe that's important for some embedded environments.

> Well, sort of. Instruction fetch is always little-endian but data load/store can be flipped into big

ARM works the same way. And SPARC is the opposite, instructions are always big-endian, but data can be switched to little-endian.


The endianness of file formats and handwriting is irrelevant when it comes to deciding whether your code should support running on big-endian CPUs.

The only question that matters: Do your customers / users want to run it on big-endian hardware? And for 99% of programmers, the answer is no, because their customers have never knowingly been in the same room as a big-endian CPU.


Saying that (hand)writing is irrelevant is a bit of a strawman implying I said writing hexadecimal numbers big-endian on paper matters for coding.

The second sentence, weather your customers know if they have been in the same room with a big-endian system (CPU alone doesn't matter) is irrelevant when the point is to write correct code. Many of then aren't interested in this or other details and that is ok as they are not responsible for the implementation.

Changing the endianness either direction did have show bugs to me several times, that could be fixed, and it was worth it for that alone.


AFAIK they recapture most, but recapturing all simply isn't possible / financially feasible. And they use a lot of helium, so even if they capture most of it, the losses are still higher than the currently available supply.

> we are unfortunately not able to guarantee bootloader unlocking, as it is not feasible for us to search through thousands of devices in order to find one that is

Ohhhh, is that how it works? Maybe I should try that next time. Instead of selling broken hardware as "NOT TESTED, AS IS, PARTS MACHINE" I should sell them as "100% working!" and when someone asks, I'll tell them "sorry, it's not feasible to search through all devices and find the working ones"


Imagine a supermarket telling you "sorry, it's not feasible to check the expiration dates on all of our products".

I think where the analogy falls apart isn't whether or not there may be expired products on the shelves, it's whether or not the store will make a reasonable effort to make it right and either refund your money or replace the product with one that's known to be good. Most will.

Source: I ditched the techpocalypse at the end of 2024 and now happily work at a grocery store.


That essentially is the case. Grocery stores make a best effort to remove expired foods but you can often find expired food on the shelf in the US.

Go make a stink about it at the customer service desk and they will probably say exactly that.


They… will not say that, because they get a large fine if you report them. Every store I've been too has been deeply apologetic when this has happened (a small handful of times in my entire life).

In a lot of the US it is entirely legal to sell expired food. Near me there are grocery stores that specialize in “close to expiration” food, for a discount.

Rewe in germany also has some things discounted when close to expiration as well, but it has a fat red/white label on it indicating it (usually meat products)

Outside of a few states and a few product types (baby formula), they won't be fined. But yes, customer service usually swaps it out.

I feel like supermarkets more or less do tell you this--I get expired crap all the time if I don't check myself.

Of course, you can do your own due diligence at the supermarket before you part with the cash.

Where are you located, generally?

New England

> Isn't it the case that coherence is what makes Rust’s dependency graph sound? So, why would I want to give up that?

Read the article that comment is on, it's all about why one would want that.


I have read it. I see only theoretical reasons not really practical ones. Maybe I do not use Rust enough to run into issues with coherent Rust.

> Even clay would not be enough to hold this asteroid together, so it’s probably one big rock or even solid metal.

Neat! I think most people would expect most asteroids to be single big rocks, so finding out they're apparently rare compared to "rubble held together by gravity" asteroids is interesting. The linked article about landslides on rubble asteroids was also cool.


The demo video (https://x.com/NVIDIAGeForce/status/2033617732147810782) is even less appealing than the screenshot. The old woman at 00:20 especially looks awful!

This has all the worst aspects of AI-generated faces. Unfitting high contrast lighting that doesn't match the environment, shiny plastic-looking skin, and only barely resembling the original likeness. It's like an Instagram yassification beauty filter.

I'll be honest, I don't know enough to judge whether it's impressive that they can generate these kinds of faces (that were state-of-the-art two years ago?) in real time now, on an $8000 dual-GPU prosumer desktop. But artistically, it serves less as an ad and more as a warning to stay away from this tech. I'm surprised someone thought this was a good showcase.


The uncanny valley remains undefeated.


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

Search: