Awesome, thanks. My searches must have missed these, as I was focusing on UV radiation rather than outdoor activity. It looks like there's still a ways to go to understanding the causes of myopia.
770 karma · joined September 11, 2017
From what I can tell, the sunseekers claim is based on a study[1] where people were surveyed about their sun exposure, and then mortality was examined years later. The most likely causes identified for the longer lives of those with more sun exposure was vitamin D preventing heart disease. I feel like there's more to the story, since vitamin D is also available in other forms that don't involve UV exposure.
[1] https://bottomlineinc.com/health/longevity/more-sun-longer-l...
In general, cell quality voice should be similar to that of a POTS line. Better codecs can provide higher quality for VoIP, even on small bandwidth, but with "real" phones you are going to get the lowest common denominator.
It's an interesting way to think about priorities, but I think the missing step is to then go and make the lists again. My first cut of the lists included lots of individual skills that I wanted to build, and ignoring some felt wrong. I realized that I actually do have a high priority goal of building a broad set of skills, and that I care more about that then mastering any one of my top 5.
A lot of the advice in the article is aimed at folks trying to focus on one skill or habit. You can identify as the kind of person who masters chess, for example, practicing every day. It's equally valid to identify as somebody who has a passing interest in many games and prioritize accordingly.
Building the lists didn't make me focus on the top 5 items, but it did help me better express what I care about.
Another reason could be that it is easier to obtain emotional distance on a decision when you're not personally involved. Believing that something is best as an abstract policy doesn't always make it easy to believe it is best for you.
A third possibility is that he does believe that the market should decide, but that he also believes in taking full advantage of the system as it exists today.
1. Generate a long random password.
2. Use that password once, but don't make any effort to store or remember it.
3. When you need access to the service, use the Forgot Password flow. Return to Step 1.
This is admittedly inconvenient, especially on mobile, and it won't work well if you routinely use devices that cannot access your email. But...it is an alternative approach that removes the need for a password manager.
In my personal experience, this approach has worked well for services I use rarely, especially those with good Forgot Password flows or long remember-me session times.
See also: Passwordless[0] is a Node library that discusses a similar approach to authentication from the service's perspective.
This has actually happened in the past. When massive amounts of Ethereum were stolen from the DAO, the community got together and decided that those coins did not belong to the hacker. With >50% of the network, they forked the coin and created a refund contract where people could retrieve their stolen coins.[1] The dissenters remained to form what is now Ethereum Classic.
So, what prevents this from happening in a malicious way? The first hurdle is building that consensus. Many people involved in cryptocurrencies today believe that the future value is much higher than today's value. Paying them off would not be easy, especially considering that cashing out a large sum would crash the price of the coins, and thus the profits from your maneuver.
That being said, a core assumption of cryptocurrencies is that 50%+ of the network is not malicious. Another way of looking at this is that whoever controls greater than 50% of the network cannot be considered malicious from the network's perspective. They are they consensus.
The last point I'll make is speculative. If you created (or took over) a cryptocurrency and built consensus out of malicious actors, what value do you think the outside world would place on that coin? You would win lots of coins, but would anybody pay you dollars for them?
[1] https://www.cryptocompare.com/coins/guides/the-dao-the-hack-...
I, too, found that annoying.
On a tangential note, this behavior reminds me of Benford's law, which is probably based on other statistical reasoning.
That being said, I do think the ability to create small communities and organize that way could just be considered a different way of modeling connections. Rather than peer-to-peer links, you have topic groups as the primary structure.
There's definitely a spectrum, though, and I would be willing to accept it if somebody made the argument that Reddit wasn't a social network.
> The other reason not to trade bitcoin is that, as far as I can tell, the fate of any bitcoin exchange/wallet/bank/custodian is to be hacked. That is just how bitcoin works: You buy bitcoins on an exchange, and you store them at the exchange because it's a pain to keep your private key yourself, and then the exchange gets hacked and your bitcoins get stolen. ("There have been at least three dozen heists of cryptocurrency exchanges since 2011," Reuters noted[2] last week.)
In general, his Money Stuff commentary tends to have a sort of sarcastic reductionist vibe to it. Whether the ignorance is true or feigned for effect really depends on the reader's perspective, I guess.
[1] https://www.bloomberg.com/view/articles/2017-10-03/bitcoin-t...
[2] https://www.reuters.com/investigates/special-report/bitcoin-...
What I hope is also apparent is that thank you notes will not be enough on their own to fix the unfortunate trend of entitlement, underfunding, and burnout that is attacking open source maintainers. Any step is progress, though, so long as we don't fool ourselves into thinking it's literally all we need to do.
On the other hand, Bitcoin was also priced under $200 just over a year earlier, in November 2013. In December 2013 it spiked over $1000 before crashing. The $200 in January 2015 is where it eventually stabilized.
This doesn't invalidate your comment, by any means, but it does illustrate that such a collapse is not out of the realm of possibility.
(All prices sourced from https://www.coindesk.com/price/)
Also, that does still sound like it could be an epiphany for some. It's not immediately obvious to apply game strategies to real world scenarios. I would consider that type of analogous thinking to be one of the hallmarks of cleverness.
This wiki article describes an atomic swap process.
I believe the largest issue with that process is that it takes multiple steps. Those steps can be reversed if the process is halted (and are therefore atomic). However, needing to transmit to the network multiple times and wait before continuing makes it a hassle to carry out manually. That leads to either wallets or trusted third parties completing the transaction for you so you don't have to sit and wait.
> (Today, we’re excited to share some big news for developers around the world wide web: )We’re committing our resources towards making MDN Web Docs the best place to go for web API reference.
[1] https://arstechnica.com/information-technology/2014/01/malwa...
Most of these points, I think, generalize to all code review workflows. Some teams, though, put a high priority on individual ownership and accountability, which creates a few interesting dynamics. First, code reviews were mostly treated as nonblocking. With high trust, we assumed that most code was good by default. From that perspective, it was also discouraged to drop everything to do a code review. You were better off focusing on being productive until you found a natural breaking point. Because the code was often already shipping when it got reviewed, small style changes were typically moot and the focus was higher level.
There's definitely a trade-off with that approach in terms of catching bugs early, and it does depend on a high level of trust in developers. But I didn't feel like the posts assumptions quite covered that.
Getting caught up in cognitive biases is itself an example of a problem that interferes with our productivity. It doesn't strike me as a useful view of the big picture, other than the realization that perhaps software engineering is all about balancing these sorts of conflicting factors. E.g., know when to experiment, quick and dirty, and now when to go deep in refactoring.
That being said, the primary concern so far seems to be the CPU melting effect of the mining. (I don't want to use my battery, CPU, etc to make you money without you asking me.) Rather than blacklisting certain domains or requests to crypto-mining services, I'd like to see something that protects against intensive scripts in general.
Here's how I could see it working:
* Services like Coinerra want to do intensive work without blocking site responsiveness, so they should use something like Web Workers.
* Browsers should provide user controls to throttle the execution of Web Workers. This will protect their resources from most intensive scripts.
* Intensive execution on the main thread already has (inelegant) protections (no responsiveness, script timeout warnings). Maybe these will need to be improved as more sites request intense, continuous computations on behalf of clients.
Unfortunately, crypto miners themselves will have little incentive to add the controls on their end, because it is best for their customers if the hashes are computed at the maximum rate. (Well, they will have a little incentive, because throttling may allow them to fly under the radar, providing smaller revenue without being blocked entirely.)