altarius

How do we know these are perfectly functioning devices? The average person wouldn't read studies and documentation or ascertain the quality - I barely can and check HN comments for many medical studies :) FDA approval is a very strong signal at least.

I'd rather avoid the supplements situation where manufacturers can essentially claim almost anything and most of the population isn't aware that it's a free-for-all. Manufacturers can still claim some function but at least there's currently a disclaimer that makes average people question some claims.

I don't really love the mix of deregulation and healthcare (even adjecent, see supplements).

I'm sure they have smart people, but they're not that exceptional imo. Otherwise mid-way through they'd have surely realized the impossibility of the situation, notified the city that the original objectives are unattainable and all presentations, documentation and suggestions clearly stated that their new goal is not to "stem jail violence" but lessen the "contrapositive" (out-of-control violence). I bet none of that happened, not because McK doesn't have smart people, but because they're often not really trying to "solve problems".

Often, I don't think you hire McKinsey to solve your problems - you hire them when your problems are already out of control and you need to deflect the blame. They give it their best shot, if they turn it around then they're heroes, if not, you can blame them and they still get paid.

Carbon fiber frames are now quite common in mountain biking and road biking, many enthusiasts (just quite average riders) buy them.

I think this bike for wealthy commuters and city dwellers, could replace public transit or Uber rides. People seem to have taken up cycling in cities due to the risk of riding on public transit. And as someone else said, taking a 50+lbs (25kg) e-bike inside or even upstairs is a pain.

But I think most of all, this is sort of a "halo" product - the best bike they could build, probably very expensive, but "sexy" and definitely news-worthy - as this HN submission has shown. And in the future they can launch cheaper alu-framed versions of this bike when this bike has established LeMond's e-bike reputation.

I am pretty sure that Adobe products make heavy use SIMD/SSE/AVX extensions to speed up any image processing that is not offloaded to the GPU - I wonder how well Rosetta 2 translates the vectorized instructions. If not well, then the M1 is really in for a treat.

That said, it doesn't seem hard to do and I wouldn't be surprised if most instructions have near 1:1 equivalents. The only question is if Rosetta 2 authors got around to translating those.

Bad as in "unrealistic", i.e. lacking details and textures? Probably because they're researchers not 3D game designers. My guess is that it is just showing a standardized raytracing scene from a public research dataset used to compare raytracers.

The scene is demonstrating their "lightpath vectorization". If the claims work out, the real gains are the better use of the full hardware capabilities by vectorizing multiple rays without GPU/SIMD branch divergence - the divergence happens happens when different rays intersect different objects and dramatically slow down parallel work. That should really speed up rendering so allow more rays and create less noise, more detail.

> They are stuck evolving a 30 year-old architecture.

ARM is older than you may think :) AFAIR the ARM instruction set was developed just a couple years after the Intel 8086, 1983 vs 1978. They're both nearing 40 years, but not that modern x86-64 or ARM64 are the same as those old ISAs.

This article explains how to measure and correct mirrorless camera and lens bayonet mount tilt for very demanding landscape and astro photography.

Another interesting article where the author documents how to measure and adjust for camera lens-mount tilt on mirrorless cameras with a rotating lens adapter.

https://cacaoeditions.com/your-cameras-and-lenses-are-crooke...

Lenses themselves often also have tilt from 50-200 microns, which you can also measure and shim.

That's an interesting idea. I just looked at the top 25 analysts, 23/25 are specialized in the tech sector - maybe something of a "rising tide lifts all boats" effect there at the top.

No, not as far as I can tell.

If I read this paper right, viruses on surfaces/aerosols decay exponentially (so no specific "life-time") and they determined the half-lives here. Start with more particles and you reach the detection threshold later.

To figure out when all viral particles are inactive you'd have to know how many particles you'd typically start with. I doubt that the amount of particles they spread on the surfaces is typical of what an infected person would spread.

I just want to stress this again!

I see so many people claiming that you need to quarantine your packages for X days to be safe - this does not seem to be what the study says!

That doesn't seem to be true unless the number of particles they spread on the surfaces is representative of someone handling a package with contaminated hands.

Viral particles seem to decay exponentially with a specific half-life (the environment just seems to break them down/inactivate and it's essentially a random process). So if you start with many more viral particles than this study, then more infectious viral particles will be on the surface after a set amount of time. Viruses do not seem to be like cells with a specific "life-time".

This study essentially shows that this virus behaves a lot like SARS-CoV-1 but spreads more aggressively - it must be something other than longer viability on surfaces/aerosols.

The only generally applicable information form the paper is the viral half-life in aerosols/on surfaces and comparing it to SARS-COV1.

This won't help in determining how long to quarantine packages unless someone finds out what the typical viral transfer is e.g. when sneezing or when handling a package with contaminated hands - and how many/few viral particles "ingested" may cause an infection.

I don't think one can simply conclude at all that "viruses will survive X days on cardboard/steel/plastic" because viral particles go through an exponential decay in the environment -- so more particles == more time to inactivate all the viruses, and the reverse.

As far as I understand it, there's no predetermined "viable lifetime" (a sort of biologic clock and death) of a virus, the environment will just eventually destroy it and that point seems essentially random for an individual viral particle with different probability distributions on different surfaces.

So if you start with a viral load that is higher, you will be able to detect viable viruses longer.

So these numbers, e.g. detectable for 3 hours in aerosol don't mean anything unless the average human sneeze excretes as many viral particles as a "3-jet Collison nebulizer". If we excrete more than more viral particles remain viable longer and the detection threshold is reached later. If less, than those 3 hours don't apply.

Linked lists aren't fast in general but there are workloads on which they outperform vectors -- which is why it is important to understand the advantages and disadvantages of each data structure.

Most lower-level memory allocators e.g. tend to use linked-lists afaik because you end up removing and inserting slabs a lot, the Linux kernel also makes wide use of linked lists as well. If there were substantial performance gains to be made without other large tradeoffs it would have been done.

EDIT: Some additional info: http://www.jikos.cz/jikos/Kmalloc_Internals.html

Even whole program analyzing compilers can't necessarily outperform a well-tuned regular compiler, see e.g. MLTon vs OCaml in this (micro-) benchmark. The OCaml compiler is just well-written and well-tuned and performs surprisingly well.

http://www.ffconsultancy.com/languages/ray_tracer/performanc...

But then as always, this benchmark may just test an implementation detail (afair OCaml is unboxing floats or float arrays (?) or maybe some of the MLTon standard lib is really slow). I seem to remember other benchmarks mirroring these results though.

I'm not a ruby guy but the implementation is quite interesting.

The syntax looks very readable compared to other library-level implementations. There seems to have been some abuse of the "::" constant access operator and a lot of meta-magic + eval but the results are pretty nice.

I find the type-mapping in the Constructor class pretty interesting as well.

... and maybe San Francisco.