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

The first patient might not actually have had rabies.


I don't think there's much doubt on that actually, the diagnostic was confirmed by CDC analysis and antibodies were found.


Not sure about the Recife protocol, but it's pretty much accepted now that the Milwaukee protocol doesn't work[1][2] - the initial case may have been some other encephalitis mimicking rabies.

[1] https://journals.lww.com/pidj/fulltext/2015/06000/the__milwa...

[2] https://www.cambridge.org/core/journals/canadian-journal-of-...


Back when I was a paramedic, I HAD a rabies patient that survived using the Milwaukee protocol.

It doesn't work very well... but it does seem like it occasionally works.


That's amazing.


How did you get that “the initial case may have been some other encephalitis mimicking rabies.” from the decond paper paper?

AFAICT The paper questions the hypothesis that the 2 additional survivors had rabies, but not the first patient.


Your second link is an error 404, page not found.



How did you get that “the initial case may have been some other encephalitis mimicking rabies.” from that paper?

AFAICT The paper questions the hypothesis that the 2 additional survivors had rabies, but not the first patient.


You may want to reply to drunkendog so they see your question.


Oh I didn't pay attention that you weren't the original poster of that link, thanks for pointing that out!


I believe the secure email issue linked is exploitable by any MailChannels customer, not just Cloudflare Workers.


All Workers API calls to MailChannels must send email from a domain that has a Domain Lockdown record authorizing the Worker by its CF-Worker header. Docs are here: https://support.mailchannels.com/hc/en-us/articles/456589835...

Since you cannot forge the CF-Worker header in API requests (this header is added by Cloudflare's back end), it is not possible to send email for any domain that hasn't been locked down to your specific Worker.


Replacing 4 line solutions with extensive libraries is what caused left-pad.


I understand where you're coming from here, but the whole point of this article is at the 4-line solution is wrong (and the author specifically mentioned that every other answer on the stack overflow post was wrong in the same way as well). "Seemingly-simple problem where every naïve solution contains a subtle bug" is exactly the right use case for a well-designed library method.


> “It’s wrong”

But in a completely benign way. I question why a few edge cases of writing 1000kb instead of 1Mb—so not even a misrepresentation—would ever be worth the code bloat. This is about making stuff slightly more convenient to read.


I agree with you— that was a lot of drumming for what turned out to be kind of a nothingburger as far as the "bug".

At the same time, putting this kind of thing in a library (or even a language's stdlib) is worthwhile for exactly this kind of reason— it allows devs to confidently reach for code that other smart people have really agonized over and which definitely covers the corner cases, similar to other common utilities such as sort methods.


One example: I display available memory in my status bar, which expects strings to be a constant width. If it displayed 1000kb, it would cause alignment issues and annoy the heck out of me


Yeah, copying an incorrect answer from SO thousands of times is much better!

(The subject at hand isn't whether libraries are good or not, it's whether copying something off the internet is. In the post, it turns out it isn't. If it was a library, the author could have fixed and updated the library, and the issue would be fixed for everyone that uses it. left-pad isn't an issue with libraries per se, it's an issue with library management)


No. left-pad was placing a 4-line solution in a library. prettysize is well deserving of library status.


What caused left-pad is the the ability to delete published code


You should see the implementation of `std::midpoint`[1].

Accounting for correctness even in edge-cases is what large libraries do better than throwaway bits of code.

[1]: https://github.com/microsoft/STL/blob/6735beb0c2260e325c3a4c...


> Hey guys - creator here. Have hit the Github rate limit and currently not working! Am trying to fix! Thanks for all the support!

> Update: just shipped a fix for the rate limits - you will need to signup for an account and put your own personal access token in.


Fork of neko; differences can be seen here: https://github.com/m1k1o/neko/compare/master...wanjohiryan:q...

Commit messages seem like a bit of a mess at first glance, but otherwise seems like a really cool project!


I'm hoping the changes will improve latency. I really liked neko, and wanted to use it for hosting watching parties with friends. For testing, I ran neko on a beefy EC2 instance to totally eliminate the chance that my CPU was making it run slowly, but it was still unacceptably laggy for streaming videos.


> Do you have any information about the environment in which a card was used?

That would be even more true for cards owned by non-miners; most miners will operate at a large enough scale to use some best practices, which definitely isn't true about most people who buy GPUs for personal use.


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

Search: