nicpottier

Fun read, but man, the hubris! I play chess a fair bit and have gone through various stages of study, though admittedly never a month full time. But man, no way do I think Max could beat even an intermediate player (say 1800 ELO) 3 out of 5 games. It just isn't something you pick up in a month.

Source?

Also note that some of the first iPhones had plastic backs.

I for one miss plastic, it is a hell of a lot more durable and doesn't have any of the issues with interference. There are lots of ways of making plastic feel premium as well.

I really loved Threadless back in the day and this was an interesting read. While it did a good job of covering what changes Threadless made that ultimately changed the culture around it and led to its fall, it didn't cover the why.

Was their model no longer profitable? Were they facing outside competition (and what was that competition doing better?). Did they take money and have to grow big / fast and therefore started selling to big box stores to increase revenues?

I don't see any reason why Threadless couldn't still be a profitable business (god forbid a lifestyle business) even today if they had maintained their cachet but maybe I'm missing something.

For RDS, it is much cheaper to pay for more storage than more IOPS, at least if you are under 3k IOPS.

IE, you will save a bundle if you are currently buying 3k provisioned IOPS vs just paying for 1 TB of storage.

More here: http://blog.textit.in/why-buying-provisioned-iops-on-rds-may...

This is not an unreasonable ask though. You should certainly think twice to pigeon holing yourself with any technology that you do not have full rights to and will be lost without a specific provider.

It does make figuring out your business model more complicated, but having SOME story for what will happen if you go out of business or start being a bad actor is something you need to figure out.

It isn't impossible though, our SAAS is Open Source and we survive, though yes, some customers do choose to self host. You just end up with fewer enterprise customers and more smaller clients.

I've been going through the process of learning Spanish for the past year or two (with various levels of dedication) and I have also thought about starting yet another language learning app. I used RosettaStone and DuoLingo for a while and they both provided a lot of value, but for sure the greatest benefit came from doing 1 on 1 lessons with native speakers. Lots of progress then.

One thing I've noticed with all the language learning apps though is that they are generalized methodologies that are then applied to lots of languages. IE, duolingo in French and Spanish and German are basically the same track, just in different langauges. Same with Rosetta Stone (even more consistent there).

That seems to really be leaving a lot on the table. Every language has its quirks and most importantly every language has a few shortcuts you can learn to really give yourself a ton of utility with little work. But because the software is built to be generalized you get the lowest common denominator instead of the fastest possible path to fluency and speaking.

Not sure which approach chatterbug is taking, but at first blush and by the way they talk about it I'm guessing it is yet another generalized approach, but I suppose we'll see.

I feel the same way in that their portrait mode just doesn't look right compared to what you would get from a real shallow depth of field and a fast lens.

But I think the (depressing) truth of it is that I notice it because I've had fast lenses and spent a lot of time taking photos, so I know what natural looking bokeh looks like. And bokeh is also just an artifact of a lens and aperture combo, so who is to say that extreme blur with a sharp line as they are doing isn't just going to be the new standard?

I suspect the next generation will come to prefer this look (if it continues) and find the "natural" effect with real glass as weird.

> It won't help you with most killer avalanches such as large powder ones

This is tautological. Yes, few people survive killer avalanches, because that's what defines a killer avalanche.

Many avalanches encountered by backcountry skiers especially are not these giant killer ones, and can be survived either by skiing out of them or having the proper equipment and training. Your odds aren't great, but they aren't nothing either or people wouldn't bother carrying the gear. (beacon / shovel / probe / avy bag)

Anyways, this is sufficiently off topic, but your characterization of avalanches is movie-like-stuff. Huge avalanches happen but they aren't the typical case. Most are small / medium slides triggered by humans in the backcountry.

Avalanches act very much like liquids while they are still moving, swimming upstream is indeed the common advice and it has definitely worked. That is why one of the newest devices to survive one (if you are caught) is basically a life preserver: https://www.scott-sports.com/global/en/page/avalanche-pack

These serve the dual purpose of protecting your head and decreasing your density so you float to the top of the snow pack.

Yes, obviously there are big enough avalanches with huge slabs that will kill you in the ride, especially if you end up going through trees, but most skier involved avalanches are on more open terrain (thus why they slide) and are loose snow while moving.

Are you sure you are understanding the argument being made here?

I think the argument, which is fair, is that it is very weird that if I pay Spotify $10 a month and listen exclusively to a single artist, that artist may get a penny from me and Justin Bieber may get $3 from me, despite me never listening to a single track from him.

Nobody is arguing Spotify can take it's 20% or whatever, people are just arguing that the calculation Spotify uses to distribute the monthly royalties severely penalizes small artists. (because it looks in aggregate across all listeners instead of divvying per user)

Ya the weird case we ran into with the dict / list was when unmarshaling some JSON which had an empty list `[]` then marshaling it back to JSON you end up with `{}`. Which is pretty broken and given the prevalence of JSON as an on the wire format is seriously disappointing.

Not sure if there's an easy fix to that apart from using `null` instead of empty lists.

Would love if there was another option between those two as well. I know lots of people love Lua but I find it different enough that using it as an embedded scripting language is annoying. IE, I'm not programming in it all the time, so things like 1-indexing of arrays never becomes feels natural and I make indexing mistakes. Other differences like arrays and dictionaries being the same type cause other context switches which I dislike. (and can cause super subtle bugs in JSON marshaling and unmarshaling if you aren't careful)

I would really love a fast, lightweight stripped down "C Flavored Syntax" dynamic language to use instead of JS or Lua but I haven't found either yet.

Is it really so hard? Cost of a service like Equifax's own TrustedID or LifeLocks is over $100/year. Seems you could easily argue that you'd have to subscribe to said service for the next decade to guarantee your credit and identity aren't stolen?

(and I would think refusing to accept Equifax's "coupon" for TrustedID would be a similarly easy argument to make)

Chi gives us just enough while still adhering to all the Golang standards: https://github.com/go-chi/chi

Do augment it a bit here and there with other libraries.

Sent you a note, thanks for the reply.

Have you read the White Man's Burden? (the book) I'm not sure you are qualified to say it isn't fair to bring it up if not, as it deals exactly with this. (and yes it isn't about race, nor is the book, but about how broken the approach to aid has been in Africa in particular)

And yes, indeed, bringing small local NGOs to help one local community can be more harmful than not. Among other reasons because you are only adding to the fragmentation of health care services in a country that is desperately trying to unify them and just seeding confusion within that system.

EMR's like what it looks like Watsi is doing have been going on since before I was there in 2007 and like I said are constantly popping up because everybody is like "hey, I can build an EMR". That should be the first clue that it isn't the core problem at hand.

It feels like there aren't a lot of people in this thread that have spent any time in this space, specifically health care in East Africa or the wild wild world of NGOs / aid there.

This has the same breathless and "six weeks of hacking to save babies" feel to it that every other project starts out with. What exactly is different? There are a zillion mini-EMRs operating in East Africa, especially Uganda, what most lack is real integration and cooperation with the government to make them sustainable and scale. What is the story there for Watsi? Why will Watsi avoid the complexity of a real EMR like OpenMRS? Are you integrating with them?

There's a slide somewhere that I think UNICEF put together of all the NGO (as in non-UG-government, not just non profit) health projects active in Uganda. It is this hilarious demonstration of the crazy amounts of bootstrapped projects exactly like this and just how much they overlap.

To the founders, have you read The White Man's Burden? If not, please bump it to the top of your list.

Source: I lived in neighboring Rwanda for 5 years and work in this space, including projects in Uganda. It is a fascinating space with lots of opportunity for good, but also one that requires real introspection on why you are pursuing particular strategies and whether that is being driven by ego or truly because you think it is the best for the people. Almost always the answer is that no, a new thing isn't required, but rather you should be pitching in with someone else or building upon an imperfect system to better it, because that system is government owned and managed and thus will be sustainable and gives the country and people agency. This is why aid is hard work, because most good organizations have moved past the "hey, look what we built you stage" to instead trying to build capacity and institutionalize changes. That is so much more difficult but much better tack, though my beliefs are still more in the camp of direct cash transfers these days.

Does anybody know of a high level overview of how storage of on chain variables is dealt with in Ethereum? I have a vague high level understanding that miners are the ones running Ethereum contracts, and I'm guessing it works like Bitcoin where lots of transactions get "mined" into a block, but I don't understand how shared state works.

How are races etc, dealt with?

Why would you use this over BTC or ETH? This will run into all the same KYC laws as those just that you are locked into a single provider instead of having a marketplace of exchanges to go from fiat to a crypto.

Sure smells like an ICO scam.

As I recall this was out of CMU. I also recall that they got smoked by Stanford in the actual Darpa challenges, which was slightly surprising given their head start.

I seem to recall Stanford used a far less intimidating VW SUV instead of a giant Humvee.

I'm about 8 months in to using Go for a few largish projects and I'd say these are probably the two biggest things I still struggle a bit with. (not generics as others seem to obsess about)

On errors, I'm really of two minds. In a way, it is a lot like how Java started with checked exceptions, it forced you to deal with the error. But at some point most people decided that was annoying and switched to runtime exceptions for everything, which while requiring a lot less code, still led to errors often bubbling up all the way to the user.

I think checked is the right thing, but it does require developers to be thoughtful and not just throw errors upwards. If you accept that checked is the route you want to go, I don't find Go's use of error values worse than exceptions.

On the package management front, I think the current best practice for projects that must not break is to vendor your dependencies. Go is working towards having better tools to allow you to specify SHA's for your dependencies easily but we aren't fully there yet.

While it took a bit to wrap my head around using `govend` to vendor my dependencies, in the end it really hasn't ended up being a big pain point in practice. I also never have to worry about a dependency either disappearing or pulling a trick of shipping the same version # with different code. (or having the repo/package manager be down, which anybody who has shipped a lot of code will tell you has happened)

So yes, I agree these are both, weird, but they aren't deal breakers. For our particular application, I really love Go, more so than I have any other language in recent memory.

I checked out those blogs and none of them really go into any depth about scaling issues. Do you guys plan to share your learnings there, I for one would find that interesting.

You've said this in a few different places, do you have a source for that? You are saying you could load AOSP on an S9 regardless of what Samsung does?

If so, this is indeed huge, but I have some serious doubts about it, perhaps because I have felt so very burned by Android so many times in this respect on anything but Nexus devices.

Pretty sure they used Sharp as a partner, so it isn't like they started from scratch. That guess is based on this Sharp phone looking mighty familiar (http://www.gsmarena.com/sharp_aquos_s2_taken_apart_a_bezelle...) and Rubin having worked with Sharp extensively during the Danger days. (most of the Sidekicks were made by Sharp)

I'm kinda sort interested in this device, but honestly I'm in the sit and wait given that Sharp isn't exactly a name brand anymore.

Off topic, but man, I feel like the "Black Mirror" series is required viewing for anybody working in technology. Depressing yes, but also a good warning of what is coming.

Forks don't last more than few blocks because the miners won't get paid. But I think GP raises a fair point that if the idea here is that we are broadcasting the current chain to places that have no other connectivity, then you have to trust that broadcast. By definition you don't have access to other peers to check.

So if you imagine blockstream as an attacker, they could broadcast their version of the chain which say doesn't include payments they made on the main chain so that they could "double spend" them in places that rely solely on the satellite for truth.

Or am I missing something?

---

edit: I guess there's no way for blockstream to create blocks at the appropriate difficulty level fast enough, so it would be pretty obvious if they were trying to create their own fork. So I guess this does work..

That seems like a pretty good summary according to the understanding I have and I've been following things fairly closely.

Couple additions:

- there are a few lightning implementations already out there (see https://github.com/lightningnetwork/lnd), three I believe, and they have worked on being interoperable. Getting segwit activated was a big blocking (hah!) point towards being able to actually use those, and that happens soon so we may start seeing some more activity in that space very soon now.

- I don't think lightning necessarily means KYC, at least no more so than any other bitcoin->bitcoin transaction. It is basically all the same thing as current bitcoin transaction except things are kept off chain until someone wants to settle (or the channel approaches its timeout). This took me a long time and many videos to grok but it is pretty clever and has me excited about Bitcoin scaling to everyday use again. But ya, though the specter of regulation is always looming there isn't anything in lightning that necessarily makes that worse.

The whole big block / small block thing is absolutely nuts in the amount of trolling that takes place, so totally expect some crazy replies to this.. troll on brothers!

1) The $186M raised was a mix of Ethereum, Bitcoin and cash. We don't really know how much was of each.

2) They really don't need to sell all at once and who knows, may even have engineers willing to be paid in cryptocurrencies.

Sure, but there's a weird / interesting aspect to these ICOs here as well, in that the valuation of the coin is also what will drive adoption of the providers. Since miners will be paid in coin to validate providers and providers will also be paid in coins, then there needs to be some value associated with it.

The ICO in this case kind of bootstraps the value of the coin in a way that is needed in order to bring on miners and providers. So in a way the value being raised is a bit like capital costs that the network will "spend" to bootstrap and verify the network.

Don't get me wrong, this is a lot of money to raise, but saying this is totally nuts without taking into account that the model is very different (and interesting!) is not giving credit where its due. Will it work? Who knows and certainly most startups fail, but it isn't a foregone conclusion.

I think you are absolutely right, that there are huge problems still left to solve. But even so, then how is this different than a very large VC round that is (slightly) more open to the public? Plenty of businesses get money to build out technology with only the belief that the team raising it have what it takes to make it happen.