13,165 karma · joined May 28, 2013
I long to work on a team who values shipping correct code over shipping anything until they're up to their eyeballs in technical debt and can't ship.
The intermediates seem to be difficult in that the root stores don't seem to have a mechanism for it (… kinda seems like an oversight, at this 20:20 vision point?). If eight of the CA's intermediates are hosed … how many are still "good", and are they good good, or are we just fooling ourselves?
No, the price drops at the exact moment the DoJ starts looking into it.
So I wonder if we could be seeing a bit of survivorship bias.
¹though with cops you never know
The smaller one is 16 bit. The larger one is 128 bytes, or 1024 bit. The PCB is labelled in English. ;) (pause at 49s)
(There are also subtitles in English, though, yes, those could be inaccurate.)
> Wait, is each of the rings one bit?
Because it's probably an impossible to answer question hinging on each person's pet definition of "stable".
In one example of an unstable cluster, pods are "regularly" crashing — but at a really low frequency, like, each pod crashes onces every few days. They're OOM'ing — a bug in the workload, not really the cluster's fault — but the control loop pattern still ensures the failure is corrected in the sense that the pod will either be restarted or evicted and re-created.
(But yes, you absolutely want monitoring to pick up on that. In the specific example here, I'd say it's "just monitor pod failures", and then you get not only OOMs, but all the other ways a workload might crash too.)
I've actually had more problems when the control loops get stuck. (Which they can, almost always because you've asked for the impossible. But sometimes it is hard for the various pieces to say more than "no solution". Why no solution is usually a human-level deduction.)
The article's title is literally:
> What changes when your search index lives on S3?
None of this changes because your search index lives on S3; there's no property of S3 that says "this is an inherently better format for S3 than it is for disk". The format improvements are independent of the latency difference.
There's not really a difference here between S3 and your disk, aside from the literal amount of latency. Restructuring the format to require less reads to make S3 faster would proportionally benefit disk reads.
S3 is a lot easier manage, though. Storage is just then AWS's problem. (And what's a few ms of latency on the BE when pages take tens of seconds to load on the whole.)
> “parking,” which activates only front lights, at half brightness, and (for some reason) leaves the tail lights off.
I've also just double checked the manual for my car to be sure I'm not talking out of my ass here: the symbol he calls "parking" activates the tail lights. From the manual:
> “[double headlights, one left one right symbol]” position:
> Instrument panel illumination, parking lights, front side marker lights, rear side marker lights, tail lights and license plate lights are on.
(My manual does not ascribe a name to it.)
Now, I suppose this could be an unexpected thing that differs between cars, but it also shouldn't really matter that much. The intro example is in the rain; you should be using the symbol he calls "park" in the rain, you should be using the "low beams" setting, and then your tail lights are definitely on. Or … just let "Auto" handle it?
(I've always called this symbol "daytime running lights". Wikipedia says that's a different symbol (a single headlight with stippled lines emitting from it), one I've definitely never seen before & isn't in TFA; Wikipedia claims it to be the ISO symbol, however, I've found the relevant ISO standard¹, but it seems to lack the symbol Wikipedia calls "daytime running lights". The symbol I call DRL is called "position" or "side" lights, and the term DRL is not used by ISO AFAICT, despite what Wikipedia claims. What a mess.)
(from TFA:)
> Many cars have an AUTO option now, but would you trust it to choose the right thing?
… yes? Absolutely yes. The car can just do the right thing for me, without me having to remember. Sensing ambient light is not complicated.
> pull on the stalk for high beams (another mode), or rotate the stalk left or right for turn signals.
There is absolutely no way whatever car this is a photograph of is rotating the stalk for turn signals. Turn signals are pull up or down, universally.
¹ISO-2575:2021, though technically a draft since ISO standards are not open. But this symbol has been around since forever, so unless it's changed recently…
However, Doom also renders textures using an algorithm that sort of paints walls as like vertical lines of sorts. The exact algorithm it uses makes it hard to look up (to pitch), and I think impossible to roll the camera. See <https://en.wikipedia.org/wiki/Doom_engine#Rendering> — it has a good animated graphic of what happens if you do look up, and the differences between the output of Doom's software renderer's algorithm and something actually rendering 3D.
¹modern ports have ways to accomplish this, and even before there were direct ways of doing it, clever map layout and instantaneous teleporting can get pretty close.
But it means that, by definition, we are deploying a different tag to dev, staging, and prod. (Or whatever your pre-prod envs are called.) Hopefully, these all point at the same commit … hopefully¹. (Worse, some schemes out there — not the TFA's — force them to never specify the same commit(!) and we devolve to "let's pray those different commits specify the same tree.)
Just tag a version number. Use the date, if you can't think of a version number. Separately, you maintain some file containing what tag/revision you want on each of your dev/stage/prod/etc. environments. This is basically the same rough scheme as what TFA lays out … but not special. Just text files, in a repo², like everything else. You can do it in a separate repository (I'd recommend) or the same one (I wouldn't recommend, but it can work).
The exemplar question,
> When did we last deploy the www.our-app app to production?
Is just the `git log` of the file that contains the hash that that app should be deployed to.
The SRE in me notes, however, that gitops-based deployments (what all of these schemes are) represent the point in time that a deployment is requested — not when it actually rolls out. Deploys that fail or are blocked on some externality can converge much much later than the git commit instructing them to occur is minted. Also, the SRE in me wants to notes that deploys in any realistic scenario are not a point in time. (It starts when you start bringing up the first replica of your app, and it finishes when the last replica of the older deployment has spun down. Depending on how much bloat you have … it can be a good little span of time.)
(¹TFA's scheme seems to contain a textual reference to the tree sha, but is that checked?)
²If you have worked with Flux or ArgoCD, you're almost certainly doing exactly what I am describing, though those are not the only two such systems capable of it.
The Persian empire did not exist until round about 550 BCE.
Thus, the upthread statement,
> the business plan people got convicted for trying in ancient Persia, 5000 years ago.
Is somewhat nonsensical: 5000 years ago, Persia did not exist. I suppose we could be talking about whatever existed in that locale of the world around 3000 BCE. But that's what they're saying: "what do you mean, 'in ancient Persia, 5000 years ago', Persia did not exist then".
https://www.thomas-huehn.com/knuth-reward-check
src="./bug-report-knuth-2006.jpg"
https://www.thomas-huehn.com/bug-report-knuth-2006.jpg
One can infer that the post's URI is like a "directory" of the subresources for the post, including those images; the URL of
https://www.thomas-huehn.com/knuth-reward-check/
https://www.thomas-huehn.com/knuth-reward-check/bug-report-knuth-2006.jpg
If the author is here, you might consider redirecting the non-slash to the slash.
> But why will you find me there with the entry “0x$1.20”, i.e. decimal $2.88?
I know Knuth has his own notation here, (it is clearly noted at the bottom of the BOSS page) but 0x1.20 should really be decimal 1.125.
I've also never really fully understood why terminfo seems to be a singular package, and not something like man pages where, e.g., each terminal drops in their respectively entry.
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.
Obviously, wider ranges will (possibly) reject more often, but unless the range is huge, rejection should be a very cold branch.
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.
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?"
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.
Try a sweet wine, or if that's still too bitter, try a dessert wine. Wine has a huge range of sweetness.
> (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.)
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.)
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.)
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…
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.)
> 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.