deathanatos

I'm coming predominately from other languages, so it took me a hot minute to figure out what the various bug were.

• channels are by default "unbuffered", in that a send needs a waiting recv to actually do the send, and blocks until such. The addition of the buffer prevents the block & permits the goroutine to progress (and eventually exit, and thus, not leak) … so long as the buffer is sufficiently large enough.

• channels do not, AFAICT, realize when the receiver is gone, and will block indefinitely even when there is no receiver. (It is the same "chan" object, I think, in both sender/receiver / there is no distinction. So, the single object is never GC'd.)

• goroutines are not GC'd. (& the code doesn't/can't hold like, a reference or a handle to a goroutine / there is no "join" primitive.)

> 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.

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.

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.,

  find '(' -name '*.md' -and -not -type d ')' -or '(' [...] ')'

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.)

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.

Yet if you prompt an AI: https://share.gemini.google/TyUxSnrKmq9h

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.

(And just to head off, "it's a one-off mistake!" Another example: https://share.gemini.google/yE6axJvBDKYE ; another example: https://share.gemini.google/WG6TEBjlyro7 (though admittedly, the calendar is pretty good here, I think "humans have 2 arms" is well within the point I'm making of "stuff I don't need to prompt human artists with") ; and another example: https://share.gemini.google/CIH4QM2teQKf ; and another example: https://share.gemini.google/n76c9eJq1dGe)

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.

> 【Processor】AMD Processor

> 【Graphics】 Intel Graphics

And this is why you don't buy laptops from Amazon. At best, the seller has no idea what they're doing, at worst, this is fraud.

> 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.

> I noticed this when a mozilla dev said I must use systemd+pulseaudio

I am 99% sure Firefox will run just fine without systemd, or OpenRC half of Gentoo would be with pitchforks and torches.

It isn't correct, either, that it requires PulseAudio; I'm running FF with PipeWire, for example. But perhaps let's steelman that to "does not work with ALSA". I'm not sure what the objection to PA would be. It appears you can run FF under an adapter that will backport FF's PA output to ALSA — so it is possible to do —, I'm just not fathoming what the objection to Pulse is. (Or for that matter, its successor, PipeWire.)

Well, so there's two other problems with system (and popen):

1. IME security teams want to run dumb linters over the code that look for such things. While uses such as the ones you describe are secure, the linter might be blunter than that. I'm not sure that's necessarily a bad thing: "this use of system(3) is secure" has a cognitive tax at review time, and as the code changes; often, I prefer the stance of "don't make me think" with regards to security: i.e., do the simple, trivially secure thing, not the complex, secure under the just-right conditions thing. Then we don't have to persuade (potentially non-technical) security teams, non-technical auditors, linters, etc. that are going over the code with blunt instruments.

2. (And much more minor) the entire execution of sh is often just wasted performance that an exec(2) removes.

(& yes, you are also right that even an exec(2), mishandled, can have its problems in some circumstances. But typically when the pattern is system("<shell that just runs what we'd exec(2)>"), then whatever those problems are, system(3) is going to share them.)

> well-designed to be secure

While I suppose this doesn't say the design isn't secure, system() is one of those calls that has no place in modern code. It is insecure by its design.

> Any user input that is employed as part of `command` should be carefully sanitized, to ensure that unexpected shell commands or command options are not executed. Such risks are especially grave when using system() from a privileged program.

(—man 3 system)

> One has to wonder whether all Trump voters wanted this. I don't think so.

They voted for it. The GOP quite clearly spelled out the authoritarian desire well before the election.

> My viewpoint is that we should eventually have AI be assisting in determining if a search is reasonable in the moment.

That is truly bananas. Whose AI? Trained on what data? We've had numerous studies show how AIs can be biased, and a police dept. is going to choose whatever AI "works best for them" — i.e., keeps most out of their way.

You can see Flock for examples here: despite requiring justification for searches, cops are entering things like "hehehe"[1]; the AI would similarly be given bad or falsified inputs.

> If there is an actual constitutional violation that that happens it can be resolved after the fact.

The entire point of the Constitution is to prevent exactly that. There is no resolution for violating someone's rights; you cannot merely go back in time and unviolate them. The point is to be free from unreasonable searches & seizures.

Your comments read like police have no ability to search without a warrant, which isn't true. If circumstances warrant it, a warrant from a judge is not required, and I'm sure a good number of people would argue that that's already true more often than it ought to be.

Part of the point of having a separate branch of government involved, too, is to prevent the first branch from just deciding "why, of course I'm right. What else would I be?", and to evaluate the facts separately (which the police cannot by definition do).

> I believe every part of the law enforcement and legal system needs to be systematically reevaluated finding ways to increase efficiency.

I'm all for increased efficiency, but AI is not that. "Slop, faster" is not the same "the correct action, while respecting the rights of the citizens, faster".

[1]: https://www.aclu.org/news/privacy-technology/tracking-alpr-c...

Word choice matters. Defaults matter. People will go "well it says durable right here" and while arguably, yes, they should RTFM, it would still be great if tool-builders did not set the shotgun's default state to State::AT_FOOT. It would be nice if every paragraph of technical writing that I have to do need not be burdened by a thousand asterisks of "durable in this context means something other than durable".

Since it clearly intends to satisfy the async use case, I wish you'd've phrased this as "over aiohttp".

DHCP works over IPv6, but there's also a corresponding RA option, too, if your v6-only network doesn't use DHCP.

https://www.rfc-editor.org/info/rfc8910/ is, I think, the latest version of the standard.

Tool-tips, having an accelerator next to the item in the menu/context menu, accelerator underlines, god forbid documentation … UIs have long had ways of having a simple way and hinting at, documenting, or showing to the user how to accelerate if you want to get quicker.

Or even the original premise of agile, which was to iterate on it. But "iterate" these days means "onwards to the next feature that we'll only drive to MVP", not, "polish & fix bugs" or … do things like enhanced UI for power users.

Dumb captive portals, which do still exist in some places, usually do MitM attacks on the connection, so you need some http(no-s) site that you can abuse as "yeah, this can get attacked by the WiFi" to then answer the portal.

The right way is that there's DHCP option for the network to signal "I have a captive portal", that's been standardized for over a decade.

… or … IDK … just stop shoving ads down people's throats just because they want WiFi.

And never mind should someone want to edit¹ the image that comes off the camera. Now it cannot remain cryptographically verified, which means it's now in the pool of "dunno" images, where AI fakes can thrive alongside it.

¹in a non-AI, traditional way, that doesn't mislead the viewer and this entire footnote should reveal how subjective and intractable this problem is

Well, that sounds hallucinogenic; v6 & TLS should basically not interact. But like, what error does curl give?

I'm sort of wondering if it's more cert store weirdness. Curl & Firefox, I think, will use different stores. I think FF uses Mozilla's cert store, always, whereas curl will default to the local machine's store. The site is also using the LE YE1 cert — i.e., it's using an EdDSA cert, which is a bit unusual. It's also serving the root cert itself, which it shouldn't do, but also shouldn't be fatal. (But that also results in a whopping 4 certs sent by the server, which is also quite unusually high, but again, shouldn't be fatal.) But EdDSA is also odd enough I could see it fouling something up, and TLS libraries and path building is source of so many bugs.

I'm curious, but how/what is the actual problem there? I can connect over IPv6 just fine, and IPv6 shouldn't make a difference to TLS¹?

(¹in this case)

> Sean Goedecke wrote a post arguing that you should never be angry at work — a post with which I strongly agree. Anger can be a useful signal, but being angry at work rarely improves the situation. More often, it makes life worse for the people around you, many of whom have no more power over the source of your anger than you do. I did learn that lesson, but it did not come naturally. One thing in particular that I learned is that in a company there is a shared vision, and if you don’t agree with it and are not in a position to change it, you should not start a mutiny, not even a small-scale one. Nothing good comes from that.

Say your company is acquired. The acquiring company promises how much better the world will be, how many resources they'll give you, etc. etc. Your companies get merged, hiring is basically all but shut off, management never lets another product release occur, and the entire acquisition is strangled until the day that the employees — but of course not the management responsible for this — is laid off.

I'm supposed to not be angry, while my co-worker sits there sobbing because her entire life is now in turmoil?

I sort of want to agree, in that, yes, it is generally fruitless to argue with corporations. In the above case, I'm laid off, no amount of screaming or tears is going to change it. But seeing people get away with such levels of incompetence — if not anger, what emotion should I be feeling? There's certainly some anxiety, but that's separate: I'm anxious about my coming lack of income, and needing to find new employ, sure, but that's what I feel towards my own impending future. But towards the management? I certainly don't feel agency: absolutely nothing I could have said or done would have changed things. The anger stems from the injustice of having to suffer the consequences for someone else's mistakes.

It's a borderline "how's the boot taste" attitude, in that we should never be angry, and just accept whatever bilge comes down from on high.

With regards to the AI stuff, we're watching the world (rightly) revolt against being told that glorified RNGs should dictate the outcomes of their lives in various imperceptible ways. And that leaves me feeling that, it wouldn't matter if we were building a "traditional", small-scale datacenter — the AI enthusiasts are going to so poison the well that we can forget about building anything ever anywhere ever again. All the while, the product being hawked is simply a garbage out generator, and I think the layperson gets that.

I play a number of commercial games on Linux. The best behaved ones are the native ones (Factorio, Stardew, Celeste), though the Proton/Wine-based ones (Noita, Enter the Gungeon) usually do alright as well.

Netflix's problem is Netflix's problem. There is no technical reason why 1080p (and probably 4k) can't work on Linux, today. That's just plain ole head-up-DRM-ass, and Linux can't fix stupid.

Not really, in any company I've ever worked.

The answer is "accepted", in the sense that it won't get you fired. But the meeting plows on, and decisions are made in absence of the answer to the question! — and never revisited once the answer is known.

And like 90% of the time it comes up, it's because the data contradicts the decision.

This isn't going to get solved at the consumer level. Yes, one perhaps can & should attempt to vote w/ one's wallet, but the real fix is anti-trust law enforcement. TFA knows this,

> Every pattern above can be explained without conspiracy.

(… and in a section titled "Ongoing collusion", too!) but conspiracy also explains some of it: the egg price increases were industry collusion[1]; Americans lost something like $3B to $6B in egg prices due to it. The DOJ permitted them to settle for what effectively amounts to "don't do that again".

Did I try avoiding eggs while they were $6/dz? Absolutely, but meanwhile Tyson ate one of our local meat suppliers, and those prices immediately went up 50%.

[1]: https://en.wikipedia.org/wiki/Egg_Clearinghouse#Price_fixing

Sure, I'm using "deleted" here to mean a third state more unvisible than "yanked"; I'm not trying to specify exact semantics about said third state, simply that it (a.) isn't yanked, and (b.) yanked's semantics are probably undesirable here and a third state has merit.

Yes, I agree with you that analysis is good.