Uberphallus

I actually had 3 of these with PII 300MHz @ 450MHz running OpenMOSIX. Good times.

Exactly. Here we crunch loads of data, and by a lot, I mean our production databases run on a three digit cluster of four digit terabytes of data. Good luck having that scale in preproduction environments.

We have loads of redundancy, and dedicated "test in production" machines/datacenters to test actual production loads in actual production-scale sets machines.

Now, tests in production usually involves a pair of hands and 2 other people looking behind (dev + ops + dba), and requires a well defined rollback procedure and post-mortem. We still have absurdly high SLA (99.999%).

It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0].

Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.

[0]https://news.ycombinator.com/item?id=29128107

Yeah, but this scale of documentation production is unprecedented.

A lot of cash was dumped into fast and extensive R&D, trials and production scaling because of the urgency of the situation, and along comes an insane documentation backlog.

To put in perspective, the original HPV vaccine R&D and trial spanned over 7 years with 25,000 patients (of which only 20,000 women), and assuming the documentation was provided to the FDA as it was produced, it could be FOIA'd relatively quickly.

Pfizer/BioNTech did the same, with almost double the patients, in just over 6 months.

Ironically, if the FDA could deliver those documents "in time" it would be a sign of a pretty limited trial, and people would be complaining about that instead.

Damned if you do, damned if you don't.

Critical mass. FB groups are a dumpster fire for topic discussions, but the fact that they're just there means loads of communities end up there anyway.

Reviewing/analysing data and filtering it are dramatically different tasks. With raw data, most of the heavy lifting is done by your data analysis stack, you don't crunch numbers yourself. Complying with FOIA requests though, is largely manual work.

The FDA has 14,000 employees; its FOIA office has 10, and they go at roughly 80,000 pages per month, meaning each employee does 8,000 pages per month, or roughly 400 per working day per employee, less than a minute per page. That to my non expert opinion sounds pretty fast.

That speed has been appropriate until now that the plaintiffs want 4 months' worth of FDA FOIA work for yesterday.

I agree that there should be a solution for these cases, but it's this particular FOIA request that's the anomaly, not the FDA way of work.

Spain is a funny one.

The Community of Madrid is the succession tax haven of the country, so loads of people go live there their last years so their families aren't taxed on the inherited wealth.

Combine with the regional government short of condemning to death the elderly in nursing homes by refusing to hospitalize them[0], but I guess it's fine since they forgave themselves [1].

Add to the mix that the healthcare access hasn't kept up to handle what Madrid brought to itself, and then you obtain these numbers [2].

TL;DR: during the first wave, while most regions had peak excess deaths of 10-50%, Madrid had 200%, at the same time as being one of the most populous. In the rest of the periods, Madrid has been usually at the lead as well.

With Madrid removed the numbers are in line with Germany and Sweden.

[0] https://elpais.com/espana/madrid/2020-06-08/la-comunidad-de-...

[1] https://www.lahoradigital.com/noticia/32918/madrid/la-invest...

[2] https://www.isciii.es/QueHacemos/Servicios/VigilanciaSaludPu...

The only justified situation I can find is when you are working on two (or more) independent components at the same time.

My pain point in particular with PYTHONPATH (or playing with sys.path) is that people tend to use it with the only purpose of making import lines shorter, which brings naming collisions of all sorts when you aren't creative enough.

Not parent, but aside from the novelty factor:

For small scale energy production small VAWTs [0] are relatively cheap, they offer more W/m2, and they are much more easily serviceable and installable.

For large scale production it's orders of magnitude less efficient, plus having multiple kites on the same plane brings in the wake effect [1] in full force. That's why regular turbines are generally laid in lines rather than wide surfaces, or with significant separation between them.

[0] https://en.wikipedia.org/wiki/Vertical-axis_wind_turbine

[1] https://www.wind-energy-the-facts.org/wake-effect.html

I hate Gitter with a passion. It's indexed, but it's chat after all, meaning it's painful to read as there are multiple conversations going on, and whatever you're looking for needs to be extracted from below the noise floor.

It always keeps coming up in my search results but it's absolutely never been useful to me.

The article links to literature about it being a nocebo effect. Do you have literature pointing in another direction?

Asus Zenbooks have always been solid on Linux for me, using them since they came out. Typing this on a UM425.

> It was slower with the fewer threads, and giving it more threads made it even slower. Celebrating this as awesome efficiency is..."interesting".

With 1 to 4 process increase in 4 cores there's basically no granularity, at 3 there's not enough concurrency, and at 4 there's too much, choking the PostgreSQL process.

Whereas 1 to 16 blocking process increase allow for more granularity ramp up and leave the (almost) exact room for the PSQL process to do its thing before performance degrades.

That would be solved having the DB on a separate host to isolate this effect, and what happens in literally any non-dev environment.

And that's leaving asid the fact that 16 processes use roughly 4 times as much memory as 4, meaning async is cheaper to scale horizontally overall.

> Benchmark

> Uses a VPS

Not saying the results are wrong (though for client side code my experience is very different), but that's not really a good start.

Personally we don't use it in my org, and the mix of on-prem Kubernetes and GKE is just a shitshow.

I recently started learning Nomad, and Nomad (+ Terraform for cloud) is the only thing that makes sense (for our use cases). That said, I think higher management is too highly invested in K8s and they won't backtrack on this.

Since when are graphics cards registered?

Not a design/advertising guy, but often times I think it's to be able to display an ad at the bottom without the user to fully read the article, and without putting it ahead of the article (which is ugly IMO).

Here though I don't think it's the case.

Without giving much detail, where I work many accounts from different businesses aren't linked... in customer facing systems. But internally everything is linked, and well linked (for good reasons). FB will profile you even more even though you can use a different email.

You joke but that's literally what I expect.

That sounds like you live in a relatively large suburban house instead of an apartment in an urban area :)

I know, I'm doing it wrong, but my position wasn't remote before the start of the pandemic.

> we need to feel certainty that we will not be distracted.

This, so, much. Working from home with a young kid around, it always feels like something's gonna fall, the cat is gonna fight back, mom is gonna get mad at him for some reason, or simply he needs me to go play with him. I never know if I have 5 minutes or 3 hours.

Nowadays I tend to not work so much during the day as I don't have the means to focus, then work into the night.

It's certainly not like you understand epidemiological dynamics, that's for sure.

Yeah, war is terrible but it ain't contagious.

Where's the DNA altering drug? Sounds cool.

Yeah, if half-smart, certificates should expire relatively frequently to contain damage in such a scenario.

Obviously it's super easy compared with the restrictions before.

Pre-green pass I basically carried a thick folder as I crossed multiple countries, each with different restrictions and translation requirements.

Not dating since a few years, but living near a tech hub, the 20-30 year old population was 1.4:1 men to women. You could imagine it was tough, but most single men in that age bracket were stereotypical socially unaware software engineers. Just don't talk anything nerdy and you're golden.

"I can't believe you work at BigTech!"

I don't think that's changed. +30yo is a different subject, though, most stereotypes are ironed out by then.

Not sure it's any open (Kobo devices usually are hackable), but Kobo Elipsa[0] is feature par with Remarkable 2.

[0] https://us.kobobooks.com/products/kobo-elipsa

That article is exactly from when the merge was happening, and one of the reasons to onboard Aaron was to help with web.py. I don't see anything surprising from changing their->we, when he edited it to address the new state of art in Python web frameworks.