rallison

> Decay seems to be very slow even in the jurisdictions with the strictest controls. (I do think the hardest hit jurisdictions may show something close to symmetry).

Agreed. Watching the graphs for Italy made this exceptionally clear. It's been a month since their peak in new infections, and they're just now hitting the 50% of peak level for new infections. And that's with a very strong stay-at-home order.

> IMHE has entered the re-opening fray, and is setting target dates based on when they think we'll be down to fewer than 1 infection per million. It seems that it's driving public policy, and it's kinda ridiculous.

Re IMHE, hopefully policymakers will listen to IHME themselves:

> We strongly believe decision-makers should draw on a variety of #COVID19 models.

https://twitter.com/IHME_UW/status/1255294109503406080

> Granted, there's the IMHE model, which somehow fantastically thinks the virus will mostly be gone in Santa Clara County in mid-May, but it's shown very little agreement with the actual data and is nearly as bad as saying the Easter Bunny will take the virus away.

Yeah, that IHME model.. It's unfortunate that it's become the model most people have become acquainted with. It has its uses, but the down-slope has previously generated critiques.

Good Carl Bergstrom thread: https://twitter.com/CT_Bergstrom/status/1250304069119275009

A few select quotes from that thread:

> 6. But this is a mix of two different processes, an acceleration phase prior to control, and a deceleration phase once controls are in place. Given that, why does the model predict symmetric death curves?

> 7. The answer is that this is a modeling assumption that the research team has made. They have chosen to fit a particular sigmoidal curve called the Gaussian Error Function (erf function, for short) to the data representing the cumulative number of deaths that have occurred.

> 13. The actual trajectory tracks the forecast pretty closely, but then starts to turn around. Once that happens, the back side of the curve is constrained to mirror the front side; the epidemic is predicted to wane quickly. By May 17, the uncertainty range collapses to 0 deaths.

> 14. This strikes me as unrealistic. Even ignoring the real-world coupling between states (this is not included in the model), I am not persuaded that the epidemic will necessarily be entirely finished in just over a month.

And a very important point he brings up:

> 16. In defense of the model, every model is a tool with a purpose. The primary purpose of their model is to predict peak health care need, not the endpoint of the outbreak. That said, people need to be aware of a model's purpose and be cautious when using it for anything else.

In other words, it's actually a pretty bad model* for predicting the down-slope. I fully expect that we'll hit 100k deaths for this first wave.

*unless the US were to have done a Wuhan-style lockdown.

Sure!

Andrew Gelman (Stats at Columbia) had a commonly shared piece: https://statmodeling.stat.columbia.edu/2020/04/19/fatal-flaw...

Also a good dive into the issues: https://medium.com/@balajis/peer-review-of-covid-19-antibody...

Mercury News also had a good article covering a lot of this: https://www.mercurynews.com/2020/04/20/feud-over-stanford-co...

And yes, lots of twitter discussions from folks in the field, e.g. Natalie Dean of University of Florida https://twitter.com/nataliexdean/status/1251309217215942656 and Trevor Bedford (Fred Hutchinson) https://twitter.com/trvrb/status/1251332447691628545 and others.

> All three indicate a significantly lower IFR than previously expected.

The NY study, if it holds up, suggests an IFR in the 0.8-1.0% range for NYC (depending on whether or not you include the additional excess deaths), which is in the range most experts have been assuming (0.5%-1.0% has been a common range that's been tossed around). For example, the Imperial College model used 0.9% IFR as an input. Additionally, a 10x confirmed cases to actual cases ratio is in the range most experts were assuming.

The two CA studies were outliers (and, had significant and substantive critiques), and suggested an IFR as much as 10x lower than the NY study suggests. I wouldn't call those two studies as aligning with the NY study.

> which means hospitalisation is at 0.83% and CFR is 0.016% (1% dead or in hospital).

0.16%, not 0.016%.

If the results from this NY study hold, the numbers are basically exactly in line with the Imperial College study. That study assumed an IFR of 0.9%, and the NY results imply an IFR right around that.

> We are now up to 13 with 7 more on critical condition.

Minor note, but it appears we are up to 14 now - https://en.wikipedia.org/wiki/2020_coronavirus_pandemic_on_D...

> Another Japanese man in his 70s died on 14 April, making him the fourteenth fatality.

An IFR of 0.6%, with 2/3 of the US infected (about what you'd need for herd immunity at an R0 of 3), means ~1.3 million deaths. That's well in line with the models. The distinction between CFR and IFR was not news to the experts.

For those considering Comodo, I'd ask that you reconsider.

They tried to trademark LetsEncrypt:

https://news.ycombinator.com/item?id=11964583

https://news.ycombinator.com/item?id=11973232

Bad OCR led to certificates being issued to the wrong people:

https://news.ycombinator.com/item?id=12761248

They created their own Superfish-like adware:

https://news.ycombinator.com/item?id=9091917

This actually is a thing - some people really wanted metal credit cards before they started becoming slightly more common:

https://metal-creditcard.com/

That said, the addition of chips to US credit cards has made that more difficult.

This was actually one of the reasons I ended up getting the Reserve card - it includes primary car rental insurance for no extra fee.

Not quite the same situation, but in my travels abroad, I've encountered a pretty significant number of places that require a key to leave the room/apartment/house. Lose that key, and you are effectively locked inside. I think it is mainly done to prevent break-ins (e.g. you can't just break the window next to it and reach in to unlock the door), but it's always concerned me from a fire safety standpoint.

Anyway, at least in some countries, this is pretty common. Not that's it good. But, common? Yes.

Good call. I just set up monthly contributions and would urge others to as well.

Chaco is definitely on the remote side. I think you are right about the reasons for it being not as popular.

I'll also throw out that Chaco can be incredibly gorgeous right after a snowfall. I was lucky enough to see it right after a few inches fell: https://roundme.com/tour/23482/view/57102/

While I can't stand passwords sent as part of a welcome email, this does not actually mean that they store the passwords in plaintext. Often, companies will send the username and password as part of a welcome email upon the user registering (and the above screenshots look exactly like that). This does not preclude the company from then hashing the password and storing it hashed.

That said, it still is a terrible practice, as any records of that email on the origin server or servers in between will thus contain the plaintext password.

3,000 gallons per cylinder * 6 cylinders * $4 per gallon = $72,000

5,000 gallons per cylinder * 6 cylinders * $4 per gallon = $120,000

I like this. I'd love to see more ventures in this direction.

Ever since trying out Google's photo sphere feature (yes, they weren't the first ones in the space - Microsoft and others actually beat them to market), I've been quite interested in the concept of 360° by 180° ways to explore places.

I've used the feature to document, especially, my hikes, and a trip to Peru (https://www.google.com/maps/views/profile/111004183840840391...). I've experimented with using my DSLR to do the same (https://www.google.com/maps/views/view/111004183840840391992... and https://www.google.com/maps/views/view/111004183840840391992...).

And, after all that, what would I love to be able to do? Take a video with a setup that is something like in the link and be able to put together a 360° by 180° video that would allow a viewer to follow along with me skiing down a slope in the not so snowy mountains of southern California, or enjoying a zip line through a cloud forest in Costa Rica, or descending on bike down a mountain road. Imagine being able to view such a video but being able to pan side to side, up and down, looking forward or backward - basically, allowing the viewer to pan to any angle at any point in time in the video.

I have to imagine this is not a novel idea, but I can't say I've seen any demos of such an experience. I'd love to see some if they exist.

Anyway, just some thoughts I had while enjoying the video in the link.

Based on what I've read, it is meant to be a memory-hard coin, so I would assume GPU (and, if like previous coins, an AMD-based card), or possibly CPU to start. That said, I've not yet read enough, so take the above with a grain of salt.

The short answer is yes. The longer answer is that you also need virality. There are multiple coins released every day [1]. Most of these coins go nowhere.

Why are so many coins released? Quite simply, most coins are forks of Bitcoin/Litecoin/etc with minor tweaks. Occasionally, you get a truly new coin based on something new, but most simply tweak the coins per block, the difficulty re-targeting rate, the starting difficulty, the block time, etc. Coingen.io exemplifies how simple this is. Of course, there are exceptions, such as the upcoming Etherium [2], the first Turing complete cryptocurrency (as far as I know, at least).

Despite that, most coins basically fail. Sure, they receive hashing power, and some even get onto exchanges. Most of them, however, don't really go anywhere.

So, yes, it is relatively easy to create and launch a coin. It is a bit harder to launch a coin that makes it to an exchange. It is harder still to make one that also sticks around and stays in the public consciousness (such as dogecoin).

Finally, let's say you have a great idea for a new coin. The way some people previously got rich by creating a new coin was to premine the coin. Basically, one would mine the first x number of blocks, before releasing it. This still happens, but is now much more often frowned upon. So, to get rich off of creating a coin, you basically would need to premine a coin, and convince others that you had a good reason to premine it [3]. This absolutely still happens, but is becoming tougher to pull off.

So yes, you could create aarondfcoin. Yes, you could probably release it and get hashing power thrown at it. But, would you make money doing so? Well, that requires a bit more effort. Keep in mind that there are hundreds of attempted alt currencies for every dogecoin success.

That said, yes, there is still room for success here, but it usually requires more than just creating aarondfcoin. The virality aspect is the more important aspect, at the moment.

[1] See the bitcointalk announcement forum https://bitcointalk.org/index.php?board=159.0

[2] http://ethereum.org/ and the whitepaper: http://ethereum.org/ethereum.html

[3] Yes, there are a still a number of ways to make money off of releasing a coin that doesn't involve premining (or appears not to involve premining), but that is a topic worthy of its own thread.

A quite enjoyable and interesting piece by TAL. One aspect that I found interesting is that Manny, the guy inspired by Sun Tzu and without much inherent interest in the cars themselves, actually fared poorly in sales [1].

This sort of salesman is exactly the sort of person I always want to avoid when I am looking at purchasing something, so I am glad to see his techniques were not all that effective.

Overall, the piece doesn't paint the dealership model in a very positive light. While it makes one sympathetic to some of the individual salesmen (at least, to some extent), it also largely reinforces many peoples' assumptions that, mostly, they are prey when they arrive at a dealership, unless they know what they are doing (or, if they happen to arrive at the end of the month during a poor sales month and happen to be slightly stubborn).

A related note: I'd love to see more car sales go the way of Tesla and Saturn [2] (yes, Saturn), where pricing is much more transparent/fixed. Basically, I find the current dealership model's incentives to be largely mismatched to the actual needs of consumers.

[1] (~10 cars per month) http://www.thisamericanlife.org/at-the-car-lot/

[2] http://knowledge.wharton.upenn.edu/article/saturn-a-wealth-o...

Indeed. The non-scrub option simply should not exist. Are there use cases for non-scrub? Yes. Are the risks worth it? No, at least in my opinion.

Forget to check that box? Oh well, better hope the next droplet doesn't go and read your data.

Moderately competent developer doesn't realize the implications of not checking that box? Oh well, better hope that developer didn't have too much sensitive data on the droplet.

Etc etc. Security is the big area where the default should be to err on the side of caution - often removing choices that are simply too dangerous (when, for example, the tradeoff is a tiny amount of performance gain).

I say this all as someone who likes and is a customer of DO. I am disappointed.

I use Keepass for this. The android port (https://play.google.com/store/apps/details?id=com.android.ke...) works perfectly fine for me, and it looks like there are a few ports for iOS as well. Keepass itself has, of course, long established itself as a solid password manager. And the cost is $0.

While the article has some good points, I also have a number of issues with it.

- Don't worry about proper password storage until you are at 4-10 employees and have a prototype out the door? No, proper password storage is one of those things you deal with at the very beginning.

- Not worrying about a password safe until 11-30 employees? Using something like keepass, lastpass, etc, is trivial and should be started from day one as well. Your developers should already be in the habit of using one anyway.

- There should be decent password-locking screensavers on all computers. That way a smash-and-grab computer theft only amounts to a $1,500 asset loss, no critical data loss. There is nothing here about hard drive encryption, so a password locking screensaver is going to do nothing to prevent loss of sensitive data in a smash and grab.

I also dislike this attitude, mentioned in the 1-3 employees stage:

And from a security standpoint, you shouldn’t be doing very much.

In our industry, we keep on complaining about horribly poor security practices all over the internet. Attitudes like that just persist the poor state of affairs.

1. This is something that has come up in discussion a fair amount, as the blockchain is already GBs in size and takes a fair amount of time to even sync with peers to download it all. There are a number of proposals for "thin" clients that will hopefully address this:

https://en.bitcoin.it/wiki/Thin_Client_Security

2. I'm not sure what you are asking here. Transactions are almost always fractional as is - you can send as little as 0.00000001BTC at a time. I think I am missing what you are asking.

Great article. There is a lot in the bitcoin protocol that is possible that the vast majority of people have never heard of, some of which this article touches on.

For an idea of some of what could be done, see the Contracts section on the bitcoin wiki:

https://en.bitcoin.it/wiki/Contracts

In the near future, we may start to see things like multi signature transactions* and the like. In theory, it could open up some very interesting options.

*Technically, I believe there exist a few of these transactions already on the blockchain.

And therein lies the the big difference. I can opt out of Google's tracking in a number of ways. Secret tracking from the NSA? I will likely not even know it is happening, and if I do, opting out is likely to be slightly more difficult. This, of course, does not even touch upon what that tracking data may then be used for.

Considering that this is made my Troy Hunt, I would trust it. He has built up enough reputation in my mind.

To a certain degree, I do agree. If websmart can't do this right, I imagine there are many other security vulnerabilities plaguing client sites. I will say that, as a client, I would want to know this.

It seems to be a combination of both a lack of knowledge with respect to security and often a lack of respect. With many smaller companies, it is often ignorance. With many others, it is still too often the case that security concerns end up getting thrown in the "yeah, we should fix that eventually" pile of bugs.

Another issue is that security issues are often not visible to normal users. In the websmart example, a normal user looking for development services would have no idea that websmart has absolutely no clue how to do security. So, websmart gets the business, while the client gets a ticking time bomb, without even knowing it.

That, and most developers don't have any formal training in security concerns. I know I didn't when I first started - I had to pick it up as I went. It does not surprise me that these sorts of things keep coming up. Unless something changes - e.g. the majority of computer science degree programs include a course or two on security, I don't expect things to get drastically better.

That said, things like bug bounty programs help raise the visibility. And, at least many of the large tech companies do now respect security. We've at least improved in some ways as an industry.

I do actually somewhat agree here. If one doesn't know what they are doing, it is very easy to do regular expressions incorrectly.

That said, regex is sometimes necessary, so it is important for developers to be competent in this realm. In my opinion, ideally, junior developers would start with using them in non-production environments to become familiar, then go from there. It is also important to be able to distinguish which problems should be solved by regular expressions, and which shouldn't. A good mentor here can be great.