> I think it's time we start talking about putting limits on how much compute AI companies can purchase or own, relative to the rest of the world. It's not fair that they can use trillions of dollars of investor billionaires money to consume all of the resources that everybody needs.
Right now, the RAM market is effectively cornered. Anti-trust enforcement is what I'd look to, but the GOP do not believe in ensuring competitive markets / enforcement. (The current admin is pretty clearly 110% pro corporation.) Vote in November, but in all likelihood, there won't be government intervention earlier than 2028, and even that is optimistic. One hopes the AI bubble pops, but I think this market can remain irrational for far longer than I can keep old hardware alive.
I'd wager that most people just don't get that the second "arg" (composed of multiple args) to find is an expression. Expressions are, somewhat unfortunately, code, so there's essentially a mini DSL there.
find -name '*.md' -and -not -type d
Of course, then it becomes more obvious why there are parens, why those parens must be escaped for the shell, etc. E.g.,
I think once someone groks the nature of the expression args, then find becomes easier to start working with.
The most messed up part in my mind though is that while most things in find are clearly helping the expression towards its goal of "true" or "false" on whether to include the file or not in the results, some, like -prune or -exec do so but with side-effects. And since they're usually invoked primarily for their side-effect, it isn't immediately obvious that they even return a value, or are participating in the expression itself. (-prune is true, and -exec depends.) And this is where it becomes important that `find`'s -and & -or are short-circuiting, too. (In a purely logical expression, it wouldn't really matter except as an optimization.)
People also sometimes omit -and, which I'm not a huge fan of the legibility of. (But using -and makes it not POSIX; you can do -a but ew. which brings me to the last bit…)
macOS: the find there requires the starting-point arg; so my examples above, on macOS, would all need to be,
find . [expression args...]
… which is lame. Brew install GNU find and be done with that.
While I agree with globbing (or fd) for interactive use, I think for scripting I'd still say "you might want find"; there are limits to arg list lengths (see xargs) that (esp. recursive) globs can exceed; unless you know you'll never glob the world, find might be appropriate. Also:
echo *nope*
Globs will betray you on the zero-match case. (`man bash` & cf. `nullglob`.)
> EBS data data (sic) is unrecoverable, and that's what's reported.
I don't see where this is reported? TFA does not mention EBS. In fact, TFA seems to be nigh content-free, beyond "AWS (allegedly, and is uncited) says they cannot restore some data."
> The article does not tell us what products were impacted.
… right … which conflicts with EBS being what's reported …
(I would agree with your point that if EBS, or some AZ-level data was lost, then, yeah, that's the contract.)
> Everybody hates ads, but no-one is willing to pay a penny for a service they use daily.
My gas pump has ads, despite me paying for the gas. My airplane has ads, despite me paying for the ticket. My phone has ads, despite me paying for the service. My doctor's office has ads, despite me paying for healthcare. My car has ads, despite me paying for the car.
I can pay for a service to watch sports, and I get ads during the event, ads painted on the field, ads superimposed on the field, normal ads embedded in the commentary, obtuse ads shoved into things like "and he's the Lite Beer Co.® Player of Match", ads in the name of the building, ads in the name of the match itself, ads on the player's jerseys. Frankly at this point I wouldn't be surprised if attending the game required receiving a free tattoo of a sponsor's logo.
Corporations have decided "why make ${service_cost}, when we could make ${service_cost} + ${ad_revenue}?"
The entire second on chess engines is, from the view of the entire thesis of TFA, is incoherent. Let's assume, for sake of argument, that I agree with the section: that an idealized chess move predictor isn't a predictor — which is not a thing that exists, as the space of chess is enormous, but let's pretend! — that's not what LLMs are? Even if we just restrict ourselves to the space of written English prose, the space is quite literally infinite. So, hopefully obviously, no LLM is comparable to an idealized chess engine. Similarly, incoherently, we wave away the "make_more_likely", when, at least to me, the entire meat of that argument would be in the reward function, and we just gloss over that entirely.
(I would also agree with the parent commenter on that the writing smells like an LLM.)
The reward function seems indeed to be the protagonist there, still it stays in the shadows. One can only imagine that it is some kind of evaluator that scores the sequence based on grammar correctness, semantic consistency, etc.? To use the proposed chess analogy, maybe it could be a Stockfish engine that evaluates the submitted position that results from the move submitted by the LLM?
Yes, but also no. If I prompt a graphics artist, "draw me a picture, any style, of a calendar with this day circled in red", you do not have to tell them what a calendar looks like, what the days of the week are, or how many there are, or that days in a month increment sequentially.
Also, you probably don't need to tell an artist "don't violate other people's copyrights" while you're at it, though that's perhaps somewhat more debatable than "does the artist know that the day after Thursday is Friday".
This applies equally to all disciplines: AI generated code regularly contains wtfisms that a human would not need to be guided from, or at the very least (more similar to the copyright problems) that experience and knowledge would drive them away from — and permit me to entrust, particularly more experienced — humans with a vague outline of the idea, and trust that the details will get filled in sensibly. "Filling in details sensibly" is where AI hallucinates the hardest.
Some of us have been here longer than AI. "To be intellectually stimulated" would be the why, which there used to be more of prior to the frontpage becoming riddled with AI slop. "HN is for conversation between humans" as the guidelines say, and though the guidelines imply that's towards comments, I'd prefer it to be towards submissions too, for the same reasons it was added for comments.
I'm already at the point of "the reward/effort of HN is getting pretty low", but the question is, where to leave for?
> SHOULD — This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
You'll also need RFC 6919[1] for "OUGHT TO":
> The phrase "OUGHT TO" conveys an optimistic assertion of an implementation behavior that is clearly morally right, and thus does not require substantiation.
And the up-threads gut feel that "ought to" is slightly stronger comes across there, I think: ought to conveys that moral stance, where as "should" is more "there's a decision here, possibly".
[1]: https://www.rfc-editor.org/rfc/rfc6919.html; n.b., this is an April 1st RFC. I like it, though, and it isn't uncommon to see a stray "ought to" lacking a citation in a non-April-1st RFC.
My understanding is that they’re generally treated as homonyms in most cases but some philosophers like to use OUGHT in a moral sense and SHOULD as practical advice to achieve an OUGHT.
Hence OUGHT leads to SHOULD and the latter is meaningless without the former.
E.g.: You OUGHT to secure systems that handle sensitive customer data, so you SHOULD regularly patch your software.
Just telling someone they should do something without an initial moral motivation to do the “right thing” can fall on deaf ears.
I’ve seen an official patch management strategy in a government organisation that was simply: “Don’t”.
Their moral argument was that they OUGHT to save taxpayer money and so they SHOULD save time, money, and effort by not applying updates (which they felt weren’t necessary for security).
In other words: OUGHTs are like axioms that you can choose, and then the SHOULDs derive from them automatically.
my point is that as programmers we have to take into account that the average human today has a computer that likely struggles to open Win11 notepad. I don't buy random laptops from amazon, but an astonishingly high amount of people do and we have to work with that
> The article posits that they may just have centralized monitoring, not control.
… the article does posit this … nonsensically. TFA also establishes that "RMCS" stands for "Remote monitoring and control system". I would think the "and control" portion of the acronym would indicate that it is centralized monitoring … and control.
https://en.wikipedia.org/wiki/Cornering_the_market
Right now, the RAM market is effectively cornered. Anti-trust enforcement is what I'd look to, but the GOP do not believe in ensuring competitive markets / enforcement. (The current admin is pretty clearly 110% pro corporation.) Vote in November, but in all likelihood, there won't be government intervention earlier than 2028, and even that is optimistic. One hopes the AI bubble pops, but I think this market can remain irrational for far longer than I can keep old hardware alive.
reply