deathanatos

By that definition, all formats are lossy, because any preprocessing could be lossy, and the word loses all meaning … which is why we don't use that definition.

There are zero specifics to the complaint here. This could be as simple as "you violated the clearly posted rules of the specific community". Add to that what, at least externally (if not also actually) appears to be ban evasion, and there are plausible other reasons why what happened might have happened.

And then there's stuff like,

> I was also advised to sign up through the mobile app, as that would make my account seem more trustworthy.

… which is just utterly off the mark.

If your RNG outputs a u64 (a getrandom() call can do this, or even a simple RNG like xoshiro), a random int in TFA's range of [0, 10) has a very small (6 in 2⁶⁴ chance, or 3.2e-17%, might as well be 0) chance of needing to redraw.

Obviously, wider ranges will (possibly) reject more often, but unless the range is huge, rejection should be a very cold branch.

> If it is a blanket leaf blower ban, that is indeed asinine.

Uh … okay, it isn't immediately obvious to me why that would be. My landlords insist on (literally) weekly leaf blowing, regardless of season, and so every Thursday the air outside the apartment is quite literally unbreathable, as it is slaked with dust and exhaust, and literally unbreathable inside if I were to open a window (i.e., living here, I have to remember to always close the windows prior to Thursday). Not to mention the sound.

Banning the gas ones fixes a portion of the problem, I suppose.

I don't think I'd care as much if the cadence was something reasonable, like monthly. One bad apple spoils the bunch.

> And then you can run off 50, 100, 250 copies of that ballot and stuff the ballot box.

At least at my polling place (but I'd really hope this is universal), the machine (the ballot box, effectively) is in the middle of the room, and closely watched. You would not be permitted to stuff more than one ballot into it. (Not to mention this would be voter fraud.)

> Easy to do if the voter and the poll worker are in cahoots.

Again poll watchers are the answer.

> The simpler the machine, the better.

The simplicity of the machine does nothing for this attack? In fact a wooden box is perhaps most vulnerable. But, again, this is completely mitigated by poll watchers. (Not to mention such an attack would likely be mitigated by other voters simply going "yo, what are you doing?"…)

> Would be caught on a recount... probably.

… aside from perhaps a discrepancy between the count of voters who voted on the roll, and the number of ballots in the box (on the initial count), a recount isn't really catching this.

I suppose if I wanted to mitigate this, you could put a signed "This is the ballot for the 2026 election" (+nonce, so that if someone duplicates it, we can pick out the duplicates/replays) on the ballot paper, and attempt to control physical distribution of actual ballots. But now we need to generate a nonce, and we're right back to "I'm sure an LCG is sufficient, right?"

> Alternatively, just use plain paper ballots.

Eh … I can't tell from the article entirely, but the picture of the machine looks very familiar (and the one in the paper even moreso), and if it is the same machine as what my precinct uses, they are paper ballots. (My state is highlighted in the paper as having been vulnerable, too.) See figure 6a in the paper, which is a good view of the paper ballot.

If I've the right machine, these are just paper ballots, marked with pen. The machine is just an automated vote-counter that can read the ink off the paper. I've always assumed these provide a rough, quick tally that can give information in elections that aren't close, while the real human tally follows up with the official count in due time. (I do not really see how an anonymized per-ballot record really proves election integrity, per TFA. Seems like the data could be faked, though it not matching the official count would also be suspect, too. … there is no substitute for poll watching?)

This (assigning a hardly-random number) is essentially tagging the ballot with a sequence number when you drop it in the box — an utterly unnecessary step.

(If your point is that the machine could simply be ditched for a locked wooden box … yes, quite possibly so.)

> Either upgrade your pseudo-RNG

It seems grossly negligent that a voting machine is using a non-CSPRNG.

> Dominion has not shared any details about the new PRNG.

I think that site is missing parent's satellite … a big miss, you might say.

> it tastes bitter and not enjoyable

Try a sweet wine, or if that's still too bitter, try a dessert wine. Wine has a huge range of sweetness.

Is that not parsed as,

> (public profile), [private] page likes, [possibly private] birthday and [possibly private] current city

?

(I've put in my best understanding of the other elements. AIUI, you can make the latter two public, but if I recall the scandal, that wasn't what occurred.)

Just to add to this, not only does the federal government have, for example, SSNs, but, e.g., in my state, supplying a SSN (which then gets verified with the federal government by the state government) is one of the ways in which you can prove citizenship for the purposes of registering to vote.

There's also birth certificates, which are state-based databases, AFAIK, so there is that route too, and that process is more along the lines of how we're a federation.

(& for voter registration, probably the most common method, at least IME, is to bootstrap that from your state license/ID; since those are generally REAL IDs now, most individuals would provide birth cert and SSN, since that is the most broadly fulfillable requirement of REAL ID.)

> and resists all capability to prove it

No, studies have been done, and routinely show that non-citizen voting in election accounts for a pittance of the vote (e.g., "A study of 2016 data by Brennan Center for Justice from 42 jurisdictions found an estimated 30 incidents of suspected noncitizen voting out of 23.5 million votes cast (or .0001% of votes)"); historical data of prosecution of non-citizen voters agrees with the studies, similarly showing it to be non-issue.

There is evidence, the "one party" routinely presents it. This isn't some "both sides" issue.

> the other party […thinks] the solutions to proving legal voter status would be difficult for their citizen voters to accomplish

Yes, because they would. The GOP's proposed "SAVE Act", which was pushed directly by Trump, for example, would have (effectively) required most citizens to present passports as proof of citizenship. (And further, to obtain a passport, since most Americans do not have one.) (Among other problems with the bill.)

(And just to note, since there is some non-US in the thread: you have to be a citizen to register to vote, and — though this is handled on a state by state basis, but I do not think any state deviates here — you must prove that already at registration. The ongoing debate above simply makes that harder to do.)

Customers who are "only" willing to pay $130 for a shirt should get ads, it's fine, because if they didn't want ads, they should pay up for that shirt, to the tune of $500¹?

Do you understand how incredibly privileged you have to be to afford a $500 shirt? (Most people would say that about the $130 shirt!) Then that principle, applied across my entire set of life expenses, just to get a company to not take advantage of me?

¹… and that's tossing the $3,000 shirt on that page, too…

> there are countries where words mean something

You're using engineer in a highly context specific way; yes, in some contexts, engineering is a licensed field, but the general meaning of the word is:

> Engineering is the practice of systematically applying natural science and mathematics to design and improve systems, devices, or processes that solve problems under constraints.

Which is a word-for-word description of the sort of work (…some…) software engineers do.

(Perhaps less and less "systematically applying science" these days with the slop fest out there … but the field should be doing engineering.)

It's slop

> But kqueue goes further. It’s not just about file descriptors.

> This inversion changes the cost model entirely. Idle connections are cheap. Active connections drive work. Scale becomes feasible.

> epoll and kqueue didn’t just improve performance—they changed how systems are designed.

> epoll and kqueue are not just APIs. They are acknowledgments

(And that's if you give it cookies. If you don't give the site cookies, it just crashes outright; the content is there, but then some JS wipes it just to tell you "Oh no—this page croaked.")

…and a fair bit of the content is just flagrantly incorrect, but that's par for LLMs. The two biggest things that are just glaringly wrong is that kqueue is a more general interface; most of the alleged "counter-examples" that supposedly make kqueue more general are well-supported¹ by epoll(2).

The article also claims that epoll "won", or something, but never mentions the competing IOCP model, which has seen renewed interest, especially on Linux, in the form of io_uring in recent years. IOCP is pretty fundamentally different, but it has some advantages to (less copying comparing to readiness polling) but some disadvantages (In a naïve implementation, each pending read is holding a buffer, and that can mean a lot of memory use; io_uring has answers to this, but that adds complexity. There's also complexity regarding ownership and cancellation; there are good write-ups about AsyncDrop from the Rust community, but the problem is more general than Rust.)

¹with file I/O being the notable exception. The problem is tractable, in userspace. And … honest nothing stops a readiness model, or even epoll, from working with disk I/O, just, AFAIK, Linux doesn't wanna.

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