I don't mean this as a knock on you, but your comment is a bit funny to me because it has very little to do with "modern" databases.
What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.)
Don't get me wrong, Postgres has gotten a lot better since 2006. But most of the improvements have been in terms of more advanced query functionality, or optimizations for those advanced queries, or administration/operational features (e.g. replication, backups, security).
The article actually points out a number of things only added after 2006, such as full-text search, JSONB, etc. Twenty years ago your full-text search option is just LIKE '%keyword%'. And it would be both slower than less effective than real full-text search. It clearly wasn’t “sub-100ms queries for virtually anything you want” like GP said.
And 20 years ago people were making the exact same kinds of comments and everyone had the same reaction: yeah, MySQL has been putting numbers up like that for a decade.
If you read the discussion, they weren't kept because of their encyclopedic value, or because they were "widespread". I'm not sure why the parent commenter said that.
They were kept to preserve a record of their having been uploaded, and to not create a legal risk for third parties who might be relying on the Commons page as their way to provide attribution.
The original proposal was to keep the image pages with the metadata, but delete the image files. That turned out to have some technical hurdles, so instead the images were overwritten with versions containing big ugly attribution messages, to discourage their use.
I'd guess that everybody involved (including the coroner's office) tacitly understands that even if the baby was deliberately or negligently killed, there's very little chance after 20 years of finding evidence of who did it, in order to demonstrate guilt beyond a reasonable doubt. And if there's no chance of a conviction, there's no benefit to anybody from reopening the investigation.
The scientific case about infant opioid poisoning in general is a separate issue, of course. But assigning blame in this particular case doesn't have any bearing on that.
> And if there's no chance of a conviction, there's no benefit to anybody from reopening the investigation.
It's probably true that without a chance of conviction, standard protocol dictates that public resources should not be expended on reopening the investigation. But I was also heavily distracted while reading the article, scanning optimistically for the happy (under the circumstances) ending where justice is served. I certainly don't think there is "no benefit to anybody".
The "happy ending" where one of the parents and their three other kids find out that the other parent likely killed the older brother they never met? That doesn't sound very happy to me, but maybe we have different definitions of happy?
When I tried reading into the causes of so-called SIDS it seemed like at least some of the cases were a catch-all diagnosis that included cases where parents inadvertently killed their infants (eg co-sleeping and rolling onto them). Fundamentally I think there often isn't much upside to fully fleshing out the truth of cases where parents have already paid the heaviest price.
Man, SIDS. It's specifically non-specific, but the worry it causes is quite specific.
My daughter, as a baby, always managed to find a way to sleep on her stomach. Wouldn't sleep on her back, but almost magically by comparison would fall asleep lying on her stomach (face to one side or the other, not straight down, obviously - I hope). We tried various combinations of devices, arrangements of pillows and cushions, tight wraps, to keep her lying on her back, but babies are remarkably, if involuntarily, wilful (or she was, anyway, and remains to this day).
I worry about very few things, but for the first few nights we'd regularly get up to check on her, and literally be holding our breath waiting for her to expel hers.
Out of necessity the every-parents-SIDS-fear, from allowing the baby to sleep on their stomach, had to be removed from our psyche so that we could continue to function day-to-day.
Said baby is now, thankfully, a semi-healthily functional teenager. As functional as teenagers get anyway :)
I swear, all the shit they push at new parents. You can see the point to much of it, and it's obviously going to be a very stressful time regardless. But there's the same inescapable bureaucratic dynamic where once something becomes legible, the system pathologically emphasizes those few bits over and over and over, to the detriment of balanced judgement - both your own and most healthcare providers if you try to get some nuance out of them.
It's understandable that they're trying to help the people who might not be the most competent at following the guidelines, because there is still harm reduction to be had there. But it pushes the instruction-followers into the territory of "well, this probably doesn't apply to us because XXX", which is an epistemologically terrible place to be.
We're still joking about how much they repeated the advice to keep the belly button dry, when it was relevant for like maybe two whole weeks.
during covid they actually laid hospital patients face down (suspended i think?) to help with breathing when a ventilator wasnt available. this behaviour reminds me of that, perhaps your baby was doing this to help with breathing? i dont know...
> The "happy ending" where one of the parents and their three other kids find out that the other parent likely killed the older brother they never met? That doesn't sound very happy to me, but maybe we have different definitions of happy?
While "happy" isn't the word I'd use, that seems better than knowing that this could happen to any baby at any time and nothing would be done.
I mean, if it was the case that one parent killed the child (Which, to be clear, we don't know. It could have been anybody who had access to the child at the time), then I'd think the best outcome is them getting convicted of it. I don't know why so many people treat homicide as "not a big deal" when it comes to babies.
Consider an unrelated hypothetical scenario, a family father accidentally hits and kills somebody with his car. He flees from the scene and is not discovered for 20 years. Would you then not attempt to prosecute him because it would be sad for his family to know? And now consider the case if it was his own child that died.
It's not that it's "not a big deal", rather the problem is you're up against the limits of details fading to time, negligence, etc. The best case here you're probably looking at each parent blaming the other parent for either doing it or at least letting it happen.
But really my main issue was with characterizing such a thing as a "happy ending". While it's generally good for justice to be served, we should still be wary of people who are a bit too gleeful about punishment.
> However, since immunizations are given to about 90 percent of children less than 1 year of age, and about 1,600 cases of SIDS occur every year, it would be expected, statistically, that every year about 50 cases of SIDS will occur within 24 hours of receipt of a vaccine. However, because the incidence of SIDS is the same in children who do or do not receive vaccines, we know that SIDS is not caused by vaccines.
Serious question: if the chance of evidence leading to a convistion is very very small, what would be the benefit of opening an investigation? Just to go through the motions on principle? And what would they even investigate?
It's a cost-benefit analysis like many other things. There are limited resources, they should be spent on investigating cases that have a chance of getting closed.
Cold cases might get reopened because of advances in technology or other changes over time.
There is no potential "principal" here that is distinguishable from posturing and dick swinging.
Unless you find some unforeseeable smoking gun any conviction will necessarily be questionable at best. That doesn't really serve much of a purpose beyond saying "we're the prosecutor's office, look how bad ass we are, look how we somehow manage to convict someone decades later, fear us". Never mind the fact that dredging this stuff up is not likely to be good for the family and that odds are all of these deaths are purely accidental/negligent so it's not like you're going after a "real criminal".
Investigating a murder is posturing? I really don't understand the "bad ass, fear us" language. Do you consider all criminal investigations to be as frivolous?
> odds are all of these deaths are purely accidental/negligent
How can you say that given that the article presents evidence that
> "... someone gave this baby crushed Tylenol-3,” likely mixed in breast milk or formula
Is that an accident according to you, or do you have any evidence that the article is wrong about that conclusion?
>Investigating a murder is posturing? I really don't understand the "bad ass, fear us" language. Do you consider all criminal investigations to be as frivolous?
>How can you say that given that the article presents evidence that
Take a freakin step back and look at the big picture. Someone lost their kid, their first kid FFS. Even if a crime was technically committed along the way call it time served.
On a technical level, this is almost certainly not chargeable as a murder. Evidince of intent is lacking and almost certainly does not exist. The best you might be able to do is some negligent wrongful death manslaughter type thing, exact details depending on how such things are defined in the jurisdiction. Just based on plausibility these cases are almost certainly accidents. Very few mothers or the people around them murder newborns in the jurisdictions we're talking about. So if you did find intent, like a text exchange or something, the best you're likely to do is prove intent in the exact opposite direction and that no harm was meant. So then you have to prove negligence or something, which is also likely to be uphill. And this all assumes you can pin it on one person.
No good purpose is served by this. You're not getting some hardened criminal off the streets or putting someone in jail for an act committed with a bad frame of mind. Best case you wind up punishing someone using some negligince wrongful death type statues that's written based on the assumption that the person who caused the death DGAF about the deceased. Even if you pull that off this person is probably the mother or father or a grandparent who already lost their kid or grandkid for it so there's a real tinge of double jeopardy to the whole thing. This serves no purpose other than a show of force by the prosecuting office. The "real" crime committed here is not accidentally giving one's infant the wrong pills (someone gave a kid Tylenol, it's not like it was Xanax or booze to shut them up or some other thing everyone knows you don't do), the facts are likely to stack up in a way that make that act a non-criminal accident. So what you're doing in practice is screwing up one or more people's lives, to much fanfare, because they failed to tell the whole truth to the state a decade or more ago. Now, I get that that might sound like a good thing to some people, but those people are bad people and their ideas are bad ideas.
>Is that an accident according to you, or do you have any evidence that the article is wrong about that conclusion?
Stop trying to re-frame my assertion as an issue with the article rather than a critique of the proposed action (prosecuting someone). I know you'd rather discuss that, because that's much more defensible than a hypothetical decision to prosecute, and I do not accept your slight of hand.
Calm down. I'm not trying to re-frame anything, perhaps I misunderstood you because your reasons for not prosecuting are incomprehensible to me. Do I understand correctly that you think a murder (or involuntary manslaughter etc) is not "as bad" because the perpetrator was close to the victim?
> this person is probably the mother or father or a grandparent who already lost their kid or grandkid
Would you say the same about a man who (perhaps accidentally) killed his wife 20 years ago and covered it up? "He's already lost his wife, time served, no reason to investigate."
Speaking as a parent, giving a 12 days old infant Tylenol is clearly absurd and just as unreasonable as giving them booze.
>Would you say the same about a man who (perhaps accidentally) killed his wife 20 years ago and covered it up? "He's already lost his wife, time served, no reason to investigate."
There is a massive gulf of intent there and I think it speaks volumes that you cannot (or worse, decline to) identify it.
>Speaking as a parent,
And also speaking as a person who's been espousing the opinions you've been espousing thus far, that's more than just "parent"
>giving a 12 days old infant Tylenol is clearly absurd and just as unreasonable as giving them booze.
People are stupid. Shit happens. I know it seems wild now and everyone turns into a screeching moron about it now but the "suck on a finger dipped in booze" thing was not abnormal (note for said screeching morons: I did not say "considered tasteful") for decades. Doesn't surprise me that someone would give an infant a fraction of a pill of Tylenol as a sleep aid not knowing they have the opioid type and that the fraction they chose is enough to kill the kid one shot.
> Doesn't surprise me that someone would give an infant a fraction of a pill of Tylenol as a sleep aid not knowing they have the opioid type and that the fraction they chose is enough to kill the kid one shot
Note that this is just a story you made up, we really don't know what happened. You're also leaving out that if somebody did this by accident, they also chose to keep quiet about it for 20 years. Doesn't that speak about "intent"?
Also, giving a 12 days old baby a "normal" Tylenol, say one with 500 mg acetaminophen, is a very bad idea. The normal dose for a 3 month old is 60 mg (for fever, not as a "sleep aid"). Doses above 200 mg/kg can cause acute toxicity, so for a slightly small baby of 2500 g, you're there already. Perhaps thinking that there's a "safe" type of Tylenol to give a baby as a "sleep aid" (what??) is a good example of "People are stupid".
With my example with the wife, I'm simply trying to establish why you seem to consider children (or rather babies) to be not worthy of the same justice as adults. How about an adult who accidentally kills their elderly parent, would you consider that worth investigating, or should it also not be investigated on the principle of "they lost their parent"? Or further, at what age do you no longer consider it morally justifiable to accidentally (or otherwise) kill one's child and cover it up? 5 years old, 10, 18?
To me, being stupid does not mean you're allowed to give your elderly father 10 Tylenols as a "sleep aid" and claim "shit happens" if he dies. I might want to call a person of that viewpoint a "bad person with bad ideas" or a "screeching moron", but I'd like to stay above such childish namecalling.
I believe the point is that it's much easier to create a plausible justification than an accurate justification. So simply requiring that the system produce some kind of explanation doesn't help, unless there are rigorous controls to make sure it's accurate.
> You can easily scale different parts of your application independently.
Just to add that I think some people assume this is something they need, even when there's no basis for it.
Do you actually need 1 instance that handles Foo-type requests, and 99 instances that handle Bar-type requests, or would you be fine with 100 instances that are capable of handling either Foo or Bar as necessary?
The distinction only really matters if there is some significant fixed overhead associated with being available to serve Foo requests, such that running an extra 99 of those processes has a cost, regardless of how much traffic they serve. For instance, if every Foo server needs GBs of static data to be held in RAM, or needs to be part of a Paxos group, or something like that.
But if your services are stateless, then you probably don't benefit at all from scaling them independently.
> But if your services are stateless, then you probably don't benefit at all from scaling them independently.
Quite easy to run into hardware, OS or especially language runtime (looking at you Ruby, Python) limitations when pushing even moderately high traffic even for totally stateless applications
I don't really understand what you mean by this or how it relates to what I said.
I certainly wasn't suggesting that you can vertically scale a service to handle unlimited traffic on a single instance.
The point is that if you have stateless services, where the resources being consumed per request are mainly CPU and network bandwidth, then "scaling independently" is not a useful thing to do. You can just scale everything instead of artificially restricting which instances can handle which kinds of requests.
This is obviously incorrect conclusion because scaling stateful services is considerably harder than stateless and typical design involves heavy caching (which technically is state just not durable state)
Of course there are plenty of situations where you don't need this and probably a lot of people optimize for "being able to scale independently" without understanding when they would even need that/why those two services don't even make sense to scale independently.
If your services are stateful/are being treated as persistent, IMO even more commonly than your example, you really want to make sure they're only bundled together if they directly interact at the application layer. Disk is unlike ram/cpu in that it generally increases montonically in the absence of explicit handling of its size, so if applications share disks unnecessarily you've basically made it so that each fails due to lack of disk space when any other applciation on the same disk fail, and any cleanup/management of eg pruning old data or wiping out logs or cleaning up some extra noisy/disruptive disk operation now has to be coordinate with each other application sharing those disks. Terrible situation to be in.
For stateless services the big reason you might want separable scaling is for cost-controls and operations. The problem is not necessarily that two stateless services are bundled, it's that giving permission for stateless service VeryImportantFoo to scale up aggressively also requires granting UnimportantBundledBar and all the other bundled services that same permission for aggressive scaling. If these APIs are exposed to the internet in anyway, (or if their usage patterns and availability requirements are completely different, eg one is some webhook plugin or old marketing demo and the other is your PayMeTonsOfMoney api) that's a really bad idea, because you've basically made it possible for someone to send a bunch of api requests and waste a lot of your money, or lowered your availability/scaling of your important stuff to prevent that.
Also, scaling applications independently is roughly synonymous with releasing them independently (eg keeping one truly constant and un-modified rather than rebuilding it and releasing it in the same push) which is again important if you have varying availability/reliability requirements (releasing the slack bot should not require rebuilding the main backend and pushing it again).
Let me be clear though, even though most developers think about microservices in terms of engineering considerations, these are ultimately all business requirements. If you don't need cost controls or to care about availability, or aren't worried that "kyle tried to push the slackbot and now prod is down" will happen, don't think you need to do all this stuff anyway because "it's what you should do". I'm mostly writing this because I think developers who are inexperienced or haven't used microservices before tend to not realize there are almost always business and coordination and operations problems being solved when companies (who know what they're doing) invest significant time and resources into microservices.
Come on, even if that's true, it's obviously a very different situation.
For one thing, the grocery store is deciding what produce to stock and what suppliers to get it from. They can choose suppliers that have at least a minimum standard of quality. They don't just let anyone on the world slap a barcode on anything at all, claim it's a grapefruit, and put it into their stores.
For another, a large fraction of produce (though not all) is bought in person, and customers can see if it's obviously bad quality before buying it, unlike Amazon where all you have to go by is the product listing for the SKU.
But the per-request cost is not the only one. You're also paying $0.02 per million CPU-microseconds. If you do the math, that's easily double or triple the equivalent hourly charge for VM instances from the various major cloud providers.
For now, you're benefiting from the zero idle charges and Cloudflare's generous free allowance, because you're at a small scale. As you get bigger, the effect of those factors -- as a fraction of your total spending -- will decrease by a lot, and you'll still be paying the inflated unit costs.
Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.
Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.
I wonder if due to C slowly fading away things like syscall
ABI, kernel numbers, etc, will start getting more stable, not just on Windows but on macOS too
There still needs to be a cause for working directly with the kernel interface instead of going via the userland interfaces (libc on Linux, kernel32/user32 on Windows, macOS frameworks) to justify the required effort, and the use cases are basically only DRM, malware, malware detectors and anti-cheat.
What you're describing would probably have been equally possible with Postgres from 20 years ago, running on an average desktop PC from 20 years ago. (Or maybe even with SQLite from 20 years ago, for that matter.)
Don't get me wrong, Postgres has gotten a lot better since 2006. But most of the improvements have been in terms of more advanced query functionality, or optimizations for those advanced queries, or administration/operational features (e.g. replication, backups, security).
reply