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

Not "hidden", but probably more like "no one bothered to look".

declares a 1024-byte owner ID, which is an unusually long but legal value for the owner ID.

When I'm designing protocols or writing code with variable-length elements, "what is the valid range of lengths?" is always at the front of my mind.

it uses a memory buffer that’s only 112 bytes. The denial message includes the owner ID, which can be up to 1024 bytes, bringing the total size of the message to 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer

This is something a lot of static analysers can easily find. Of course asking an LLM to "inspect all fixed-size buffers" may give you a bunch of hallucinations too, but could be a good starting point for further inspection.


> This is something a lot of static analysers can easily find.

And yet they didn't (either noone ran them, or they didn't find it, or they did find it but it was buried in hundreds of false positives) for 20+ years...

I find it funny that every time someone does something cool with LLMs, there's a bunch of takes like this: it was trivial, it's just not important, my dad could have done that in his sleep.


It's much, much, easier to run an LLM than to use a static or dynamic analyzer correctly. At the very least, the UI has improved massively with "AI".

Remember Heartbleed in OpenSSL? That long predated LLMs, but same story: some bozo forgot how long something should/could be, and no one else bothered to check either.

Hey we are the bozos

Lets all get together and self-reflect on the bozos way.

Most likely no-one runned them, given the developer culture.

Little endian: byte N has value 256^N, bit n has value 2^n.

Big endian: byte N has value 256^(L-N), bit n has value 2^n or 2^(l-n) depending on the architecture (some effectively have little bit-endian but big byte-endian) and where L and l are the byte and bit size of the whole integer respectively.

Design hardware or even write arbitrary precision routines, and you'll quickly realise that "big endian is backwards, little endian is logical".


and they’ve made it clear that building products around claude -p is disallowed

Imagine not being able to connect services together or compose building-blocks to do what you want. This is absolute insanity that runs counter to decades of computing progress and interoperability (including Unix philosophy); and I'm saying this as someone who doesn't even care for using AI.


But you can still integrate this (claude -p) into your local workflows when you basically want to pipe pipe stuff to Claude for inference

Except it's not counter to history for SaaS services. Many will ban unauthentic usage from non-human clients. Getting banned from a SaaS service for boting is nothing new

it's trivial to use tmux. But it does feels like openclaw is used (and increasingly developed) by people who never heard of it.

openclaw even ships with a built in tmux skill

They aren’t stopping anyone from using claude -p, they are just charging for that usage.

You absolutely can, just pay for their API usage. The subscriptions are deeply discounted if you use your full quota compared to the API.

It is confusing for a company to sell you the subscription service, say "Claude Code is covered", ship Claude Code with `claude -p`, and then say "oh right, actually, not _all of Claude Code_, don't try and use it as a executable ... sorry, right, the subscription only works as long as you're looking at that juicy little Claude Code logo in the TUI"

The disrespect Anthropic has for their user base is constant and palpable.


You could think about it this way:

All AI prices will rise soon - probably shortly after the IPOs. The new prices will be eyewatering compared with today’s. This bulling change is lengthening the time until Anthropic have to raise the subscription prices, so those of us who’re not doing 24hr claw stuff can continue to use the tools the way we’ve gotten used to.


Subscriptions are going to leave you open to changes in the subscription terms at any time. This is especially true of AYCE subscriptions for something with a substantial marginal cost of additional usage.

If you want unrestricted and unlimited usage, it's available through the API. Complaining about the subscription like this is basically saying, I want what you're offering, but I demand it for cheaper than what you charge for it. That doesn't make any more sense here than it does at the grocery store.


This strikes me the same way the people in college who would print 497 empty pages at the end of the semester for the quota "they'd paid for" or that one guy who made lemonade at restaurants with the free lemon wedges and sugar packets. "Contempt for users" is silly. Adjusting terms to handle users who use things as not intended isn't contempt.

Contempt for users is not silly when the CEO of said company has repeatedly claimed they will replace SWEs "end-to-end" by next year.

I'm not sure what to say. You're either listening to the actions of these companies, or you're not in a place where you feel the need to be concerned be their actions.

I'm in a place where I'm concerned by their actions, and the impact that their claims and behavior have on the working environment around me.


Did he say they will replace SWEs, or maybe something more nuanced, that code will be written by AI tools?

Honest question from my end, I try to not read every AI related news that keeps telling me “it’s over, good luck feeding your family in 9-12 months”.


At no point in the last 10,000 years of human civilization has there not been a developing technology that threatened to forever reshape and displace a class of labor.

Or are you also upset about the modern plight of the telephone operator, farrier, or coal miner?


I see -- and AI is just like all technologies that came before it ...

It is not a class of labor ... it is all digital labor. Do you or do you not understand this?

It is digital knowledge itself, and then all communication labor, and then all physical labor with robotics.

Is this clear to you?


Are SWE's the only digital labor job?

And? Hyperbolic fear of change always exists and there's always been more work.

Marx' whole idea of Communism was predicted on the fact that he assumed industrialization would lead to a post-scarcity society requiring virtually no work and a overhaul of how everything was owned and produced. Boy was he wrong.


Oh nooo, labor might be automated and we might see advancement that makes the Industrial Revolution look small! Oh, the humanity! Please someone, stop progressing humanity, I need to cling to my sticks!


There is a comment by sophisticles that fundamentally misunderstands the cost of an endian swap.

It costs nothing other than having separate instructions for the different endian types.

The reason for this is that on the transistor level it takes exactly zero transistors to implement a byte swap since all you are changing is in which order the wires are connected.

Forcing software to deal with the pain of big endian support in exchange for saving a nonexistent cost in hardware is such a bad trade that it's on the same level of stupidity as not applying a clear coat on a car and then seeing them rust and expecting the owner of the car to thoroughly wax the car frequently to prevent the inevitable formation of rust.


Trying to milk the last drop before the patents expire? H.264 patents have already expired in most of the world and the remaining ones, which might not even be necessary for the vast majority of H.264 use, are also approaching expiry very soon:

https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...


Milk the last drop, or raise the prices so high that people transition to a more reasonably priced option with a patent that isn’t expiring soon?

Seems unlikely, migrating away from an entrenched codec like H264 isn't like a routine software update. It has widespread hardware support, and there's an enormous body of H264 video out there.

As fhn points out, there are now truly open video codecs available (open specification, royalty free, unencumbered by patent terms) that are able to compete with the patent-encumbered ones on technical merit. Seems curious that the patent-holders would want to hike prices in this way and validate the motivation behind the truly open codecs.

Also, the article mentions the licensing fees for H265 were also increased recently. It doesn't seem to give a figure, a quick web search turns up 25% [0] or perhaps 20% [1]. Perhaps I'm missing something obvious but I'm not clear on how the change in price relates to the patent dispute between Nokia and certain laptop manufacturers.

(It seems the H264 fee increase affects streaming providers only, whereas the H265 fee increase did not, as it affected laptop manufacturers.)

[0] https://news.ycombinator.com/item?id=46004129

[1] https://news.ycombinator.com/item?id=46003285


you mean AV1?

It's interesting because this isn't that exactly the same thing Fraunhofer did with the MP3 patent?

Richard Stallman's "Right to Read" is worth reading again, because it portrays a very similar scenario.

More like turn them both into a liquid.

Nah, the solids would crash out to the bottom of the tube.

Likewise, I read it as "Fake Rescue Packet"

It would be far more interesting to look at what this was "compiled" from; it looks like the output of a state-machine generator.

The source for BNF generator is here:

https://gist.github.com/alganet/4dfd501a3377a60f7825901114d6...

Roughly 70% of c89cc was generated from it (parser, emitter).

It can generate parsers for C, ES6 and XML for example (subsets but not missing a lot).

It's still a mess though and I have lots of work to do to a proper release.


In the same vein as adblocking, the fundamental question here is, does a service have the right to control how you DON'T use their service? Are you legally obligated to be mentally influenced by adverts and cannot close your eyes or look away?

I'd love to see the EFF or similar take on Big (Ad)tech and settle this in court.

They've gone after youtube-dl and lost, Invidious is still there, etc.

A somewhat related legal case from long ago: https://en.wikipedia.org/wiki/Hush-A-Phone_v._United_States


It might not be illegal (criminal) to use a tool like Dull or an ad-blocker, but it is almost certainly a violation of the platform tos. This means the platform (Instagram/YouTube) can legally ban your account or block your IP address for using such tools, even if they can't successfully sue the tool's creator in court.

Given how broad the CFAA is, Instagram/YouTube could just try framing it as accessing their systems without proper permission, as the ToS disallow such usage.

In my vast personal experience, https://www.law.cornell.edu/uscode/text/18/1030 is the most absurdly vague law in existence.

This is disinformation. IG/Youtube will not even consider doing that.

The wording is telling:

> Instagram/YouTube could just try …

Yes, of course they can try anything. That statement is pretty much always going to be true regardless of what you replace the … with.


How can you be sure that they “will not even consider” doing that? (That’s a disinformation from your side!)

If this app were to gain traction and start to be seen as a real problem by IG/YT, they would have all legal grounds to act. They can totally sue the app creator and they would very likely win the case under the CFAA.

How exactly is this disinformation?

It is speculative, but calling it disinformation is dishonest, especially since you then presented your completely unargumented claim that they somehow won’t even consider it. It is totally in the realm of possibilities and hence IMO something to keep in mind when considering selling this sort of app/service.


It’s something the US Supreme Court has explicitly rejected.

The problem (or not depending on POV) is that TOS are subject to legal constraints. As the dominant platform YT in a critical service area needs to maneuver carefully.

I would much prefer that over them trying to dictate what I can or can't do on my own PC.

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

Search: