Hacker Newsnew | past | comments | ask | show | jobs | submit | paul_milovanov's commentslogin

Vinay Prasad, the new FDA chief medical and scientific director, is an extremely sensible guy and a co-author of a great 2013 book on evidence-based medicine targeting the lay audience (Ending Medical Reversal)

Here's an EconTalk podcast with the other co-author, Adam Cifu, talking about the book. https://www.econtalk.org/adam-cifu-on-ending-medical-reversa...

The NYT article presents his COVID vaccine policy changes as yet more crazy MAGA shit, whereas in fact he holds nuanced views, based on up-to-date review of available evidence. He has published in NEJM and elsewhere on the topic:

https://www.nejm.org/doi/full/10.1056/NEJMsb2506929

A short take on the above from Adam Cifu, whom I respect greatly: https://www.sensible-med.com/p/prasad-makary-and-an-evidence...

With all of that, I suspect that the rumours of FDA's death are greatly exaggerated.


Huh? That NEJM bit is crazy MAGA shit. It admits that if you're in a high risk group you should get it, but then turns around and says that because it hasn't been proven in every sub-group it shouldn't be done for the rest of the population. That makes no sense, it's just p-hacking in reverse.

And it completely ignores the long covid elephant.


Wind/solar don't produce baseload power absent storage. If you can't scale storage proportionately to wind/solar, you can't compare w/s to nuclear because baseload and non-baseload supply are not mutually substitutable.


I was speed-watching a couple of videos on YouTube about this fifteen minutes ago. Search for "The Limiting Factor".

Battery capacity will be a minor constraint, but only minor, as there are constraints in the PV and wind turbine supply chains as well.

Those constraints are primarily NIMBY, the consenting processes for mines, refineries, and assembly factories in the case of PV and batteries, and for deployment in the case of wind.

NIMBY applies ten-fold to nuclear.


Part of the way this problem is solved is addressed by the article:

- overbuild renewables

- connect grids together

If regional grids are connected together, then excess capacity in one region can be used by another. You don’t have to store your own electricity for later if you your neighbour can sell you their excess.


Except we need to use electricity for heating and the availability of solar inversely correlates with demand for heating and wind isn’t really able to make up for it. Because the effect is seasonal neighboring regions can’t really help each other. So yew either need to build an incredible amount of transport capacity over a really long distance or come up with some kind of storage solution. Doing both on scale is unimaginably expensive. Yes, nuclear power isn’t able to adjust as quickly as renewables or coal/gas, but if required it can add reduce about 10 percentage points per minute. This isn’t done because of the economics. Fixed costs are much higher.


Solar energy is not zero in the winter months, it’s just reduced. Whether solar remains viable in the winter months is an economic question regarding the final price after overbuilding.

Wind being unable to work in to winter is an assertion that will need some backing up.

Unimaginably expensive is not accurate description. A) hydro is an already existing solution that can work as storage. B) HVDC lines are unimaginably expensive compared to what? Nuclear, while dependable is not exactly cheap either.


There is actually an inverse correlation between summer and winter in the northern and southern hemispheres. I wonder what the engineering issues with that scale of power transmission are, and if they're any worse than the political issues.


Well! That's an honest-to-God discount then!

$1.00 + 30% = 1.00 + 0.30 = $1.30

then

$1.30 - 30% = 1.30 - 0.13*3 = $0.91

PROFIT!


Sunshine is free, but materials, labour, manufacturing, manufacturing and end-of-life waste, land and opportunity cost of building solar/wind energy installations are all not free.


looks like they're just multiplying two 100x100 matrices, once? (maybe I'm reading it wrong?) in Julia, runtime would be dominated by compilation + startup time.

A fair comparison with C++ would be to at least include the compilation/linking time into the time reported.

Ditto for Java or any JVM language (you'd have JVM startup cost but that doesn't count the compilation time for bytecode).

Generally, for stuff (scientific computing benchmarks) like this you want to run a lot of computation precisely to avoid stuff like this (i.e you want to fairly allow the cost of compilation & startup amortize)


this is great, except apparently there's no support for containers? is that on the roadmap?

thanks!


Not externally (in the same way that vast.ai does it), but you could always boot the instance -> ssh in -> manually run nvidia-docker.

Added to feature requests!


thanks!


Well, that's the point. 2020 is not 1990-2000. Time to IPO has increased dramatically.


Laden or unladen?


Well, sheeeet.

(might want to rethink naming)


It's definitely crossed my mind (and others as well). But as long as it conveys the idea, I'm fine with it :)


Bazel is buggy?! Bazel is not a clone, it's the refactoring of the internal build system, basically. I am 99% certain that Blaze currently has Bazel at the core.

And it's pretty damn robust.


Bazel is definitely buggy. One of the silliest ones is this one (and as far as this one goes, I do not understand how this issue exists when Blaze has been used in Google for such a long itme): https://github.com/bazelbuild/bazel/issues/9419

One of the more fundamental bugs is this one: https://github.com/bazelbuild/bazel/issues/4558

I've even had to clean --expunge and clear my disk cache to fix some build errors before. Bazel paints a rosy picture of the world, but the real world is messy, and Bazel builds aren't as reproducible as it makes you want to think. (Which BTW is one thing that's had me asking so many questions about Nix.) At least the fact that it does not track changes outside the workspace means you can update your system compilers (or Python, or whatever) and end up with build outputs that will not be reproduced from scratch.

It takes a lot of time to track the issues down, so I don't necessarily know what goes wrong every time; these are just two issues I remember off the top of my head. But if you haven't run into bugs with Bazel then you haven't used it seriously enough.

And then there's the Python support which is even more half-baked right now. Their own comments readily mention that the Python support is not idiomatic. (Not just in terms of syntax, but some of it goes against Bazel's underlying design.)

Of course I say this with the full realization that "fixing" these things can be a huge undertaking (up to and including hooking the compiler programs manually), but that doesn't mean they're not bugs.


As far as bazel bugs, it's safe to say that if you stick to the ways that Google uses blaze, then you are unlikely to run into bugs. E.g. Google doesn't run blaze on windows or use system toolchains, so it makes some sense that those are where the issues are. Unfortunately, Google also uses their own rules, so the rule quality for open source rules varies somewhat since they haven't all been battle tested in the same way. blaze and the Google codebase have also co-evolved for like 15 years to work nicely together, whereas anything adopting bazel today might be an awkward 3rd wheel for a while.

Disclosure: Ex-Googler


Yeah, I've figured as much in hindsight. It'd have been nice if they were more forthcoming about this than leaving it as a surprise for everyone to figure out (including, now, for the parent to whom I replied).


For a long time, Python3 support was advertised and there were lots of Python3 flags, but it was patently broken and there were many tickets that acknowledged as much. Allegedly that has changed now, but my experience was so bad I ran from it.


It's probably better than when you used it now, but it might depend on what you're trying to do (e.g. Cython has more room for improvement).


It's worth noting that the bugs aren't evenly distributed across language plugins. Bazel might be solid if you're writing Java or something.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: