> The main thing that gives me some doubt is it seems plausible that we'll retroactively find that the deaths directly attributable to COVID-19 were somewhat overstated, in the sense that my understanding is a presumed COVID-19 diagnosis is accepted in lieu of having a positive test.
Looking at the total number of excess deaths (for all causes, ignoring if it is COVID-19 or not), I would say that it looks more likely that it is severely undercounted.
I guess you could argue that the huge increase in deaths was caused by side-effects of the lockdown, but that does not really jive with the results from countries like Denmark, which did an early and hard lockdown, and as result show almost no extra mortality.
Individuals reducing their carbon footprint by reducing consumption is all good, but it is really a drop in the bucket in the big picture. I would be worried that focusing on that could be counter-productive with a higher chance of making people either feel that they have "done their part" (if they have personally done these minor reductions) or induce general apathy over the fact that the only way forward is to reduce your quality of living while knowing that it won't make any real difference anyway.
If we really want to make a change we have to focus on big picture solutions. Instead of being against, we need to focus on what we want to move towards.
The only way to reduce our dependency on carbon fuels within a realistic timeframe is an aggressive rollout of renevable energy like wind and solar, _and_ nuclear. If we were really serious about this, we would do massive investments in nuclear, building lots of new plants and also stepping up the research in technologies like molten salt and thorium based reactors.
If we should take to the street and demonstrate, it should be _for_ actual solutions like that, rather than _against_ minor things that don't make much of a difference anyways.
Definitely! I'm not against big picture solutions -- I just don't see then need to postpone action on an individual level until a big picture solution has been put in place.
The changes we need to do will require a large cultural change in order for people to accept them. We need to accept collective AND individual responsibility for something that affects the entire biosphere. Increasing taxes on fuel won't change the way people think, any more than getting rid of plastic straws will. After all, most large changes can be summarized as a long sequence of smaller events (not sure if that last part sounds right -- English isn't my first language).
> with a few exceptions (you have PMF, second-time founder with exit under belt, obvious deep industry/technical knowledge), you have to know someone
I don't think this is true at all. Me and my co-founder had zero connections (being from Denmark, as far from the Valley as you can get), no previous startup experience, only an early pre-prototype (just barely above idea stage) of our product and obviously zero revenue (so no PMF whatsoever). I would hope that it came across that we had deep technical knowledge, but really how much can you communicate that in a 10 min interview?
We got accepted, and we were far from the only ones in our batch like that, so it is clearly possible to get into YC just on the quality of your idea and how well you can communicate it.
i don't think i'm explaining this well. I apologize for that.
i looked at your company. you and your cofounder had deep technical expertise in an area that was white-hot at the time (obviously not a perfect comp, but that was the year zynga ipo'ed on the strength of mobile gaming). so i am not surprised at all that you got into YC without any connections. im sure there are many deeply technical founders in "hot" areas such as AI, robotics, etc that are currently getting into YC without connections.
note: again, not a perfect comp, but they probably looked at you and thought that this has dropbox-like potential. also, perhaps you will disagree that the space was "white hot" based on your own personal experiences -- my rebuttal to this would be YC was probably ahead of the curve, as it usually is, as that space definitely became white hot if not around that time period, then shortly thereafter.
my point is that there are thousands of founders that apply every year to YC, who do not have PMF, prior exits, or obviously industry/technical knowledge in "hot" areas -- out of these folks, the ones that get in, i am guessing, had really good connections.
i honestly don't think i'm saying anything that outlandish. VCs don't even try to hide that you need to be connected with a "warm" intro to get their attention -- they make that publicly known. while there are always exceptions such as you and your cofounder, i don't think YC (which is for intents and purposes a VC with a better business model, a 3 month founder bootcamp, and afaict no LPs) is any different.
The author Ernest Callenbach made a very detailed proposal for just this back in the 80's, called "A Citizen Legislature": https://www.well.com/~mp/citleg.html
Sorry that this is a limitation for you. Currently event handling is only available in the commercial editions, but we do plan to gradually make more and more of this functionality available in the free developer edition as well.
Is there a way I'm missing to generate things like notifications based on changes in data with the open source edition? Or would you have to send a separate request to the server to let it know to send out the notification, something like that?
Again, I'm not trying to say that you shouldn't be able to charge for your product, but it has kept me from trying it out so far. Thanks!
Right now the only way to listen for changes on the server is through the Node.js SDK provided in the professional/enterprise editions. The open-source Node.js SDK does not support opening/writing/listening to synchronized Realms.
This is extremely helpful feedback, as we have been exploring how to expose this functionality at lower prices or in the free developer edition. One option would be to include the ability to register listeners through the dashboard similar to AWS Lambda. Would that help?
I think my ideal scenario would be to have a Java API similar to what android has, but running on the server with a sort of global view of the data. Then it could listen to whatever it wanted to and issue notifications, send emails, etc. That seems like it would be killer since it leaves all the error prone sync and data update code to realm, but still lets the server do whatever it needs to once it sees a change.
A server-side Java SDK is on our roadmap. The current version makes use of Android functionality, like the looper, so we need to transition it.
Already, the Node.js SDK has an API where you can register callbacks across Realms, giving you the global view you are talking about. You just pass it a regex pattern of the Realms you want to listen to.
This functionality lives in the shared C++ codebase so once we have Java on the server, it would also have it (we also plan to migrate our .Net SDK as well for server-side use).
(Alexander from Realm here) Yes, where this approach fits is very dependent on the use case. In our experience the key is to have a data model that is flexible enough to express many different use cases. There might be cases where updating a single field is enough, or you might need it to work as a counter, or maybe your data will be better modeled by ordered insertions into a list.
Having the flexibility to use the exact combination of data types that fits your specific requirements and allows you to express your intent in a way that makes it clear how you want the conflicts resolved is essential to make it work.
That design doc seems to mix loose ideas with the current state of the system. For instance, are strings last-write-wins currently, or do they have character-level OT? Congrats on the release - I'm a huge fan of realtime, and I'd like nothing more than to build apps that depend on such a system - but seeing documentation with those kinds of holes gives a really bad first impression.
Sorry the docs are not clear. Right now you can only apply set operations on the entire string. Internally in the database core, we support substring operations, but we haven't exposed them yet mainly because we need to add the compliment to listen for these changes. We have a working collaborative text editor demo/prototype so hope to have more to say soon!
Thanks for the link. when you mention "time" in the doc, what's the definition of "most recent" ? Do you mean, last one received by the server ? Or do you have any hint based on local state (either local time clock, or local logical clock) ?
That would make a huge difference if, let's say, i reconnect an old unsynchronized device with pending, outdated, changes.
Time means logical clock. We incorporate a number of mechanisms to track causality, such that for each changeset we know exactly which other changesets it was based on. Timestamps are only used when two changesets that are causally unrelated conflict, in which case we use the timestamp to decide on the ordering.
Timestamps are only used to merge conflicting but causally unrelated changes. In principle we could pick a random number instead of using the timestamp and we would still achieve convergence, but it just so happens that the current local time on the device is highly correlated with the user's experience of real time, so that if the user makes conflicting changes on two offline devices, those changes will still be properly ordered in the general case.
> If it were such a great idea for a country, it would have already occurred at a smaller level.
It has. The Svanholm community in Denmark (http://svanholm.dk) raised taxes to 80% for all its members, but in return you free housing, food and all other essentials. They have been doing this successfully since the 70's.
"It requires personal energy, commitment and desire for self-management in the community to become Svanholmer. Both people with work "out of town" and people who want to work at home on the estate can participate."
This doesn't sound like they just hand out money, and seems likely (I'm just guessing here), that if you don't work you may get kicked out.
