dkoston

To solve problems effectively, you shouldn't try and preconceive the solution. If you really want to solve the problem, you'll need to immerse yourself in the problem and field and figure out what are some causes of the problem that you can affect.

You've distilled the problem down to "money laundering, tax avoidance, and governmental complacency" but do other issues like zoning, foreign investment, lack of suitable space, etc contribute?

While it's possible to solve problems in fields that you don't work in, it's less common. If you want to affect real-estate prices on the West coast of Canada, you should dive into the real estate industry and most likely some obvious inefficiencies will pop out that can be solved.

To follow on to eric's comment, there are two major aspects of the law:

- what is written as law

- how courts rule

The most important aspect is "how courts rule". This is because law is open to interpretation by those ruling on it.

The main upside of using judges instead of juries is that precedent is real. In a jury trial, you are relying on a random group of people to choose the outcome. In a trial ruled by a judge, you can reasonably expect that judge to rule in a similar fashion as they have on similar cases or based on precedent of previous cases.

Having a more predictable outcome that eliminates the "wild card" aspect of juries allows your representation to give you better legal advice as they can study how the courts have ruled in the past and give advice that will likely put you on the correct side of the law.

Early hires are incredibly important as losing someone early derails progress. Think long and hard about who you want to partner with.

Any person you bring on board should vest over time so that if you’re wrong, it doesn’t cripple your cap table.

Thanks for the added clarity. Being able to charge from below 50% without damaging cycle life is huge. Would be great to see some cycle life charts showing GBatteries vs traditional chargers.

One of the other challenges you may face is the lack of consumer knowledge about how charging affects cycle life. Since consumers tend to charge batteries in ways that dramatically reduce cycles, this is potentially huge.

Figuring out how to create demand from consumers will be very important as OEMs don’t really have any motivation here. Cycle life isn’t published nor really considered by consumers when they buy devices with rechargeable batteries.

476mi/h of charging isn’t gorundbreaking. Aston Martin, Tesla and Porsche already charge at those speeds or faster.

https://www.greencarreports.com/news/1118575_gm-working-on-u...

I believe their “secret sauce” is allowing existing packs which charge slower to get “up to speed”. If so, that’s a pretty limited market as it’s likely that within a few years, all EVs sold will charge faster than the listed speeds. They’ll likely have a maximum tota addressable market of a few hundred thousand cars with only a few thousand real consumers. Most people buying electric cars with slower chargers are doing so because those vehicles fit their lifestyle and wouldn’t have a massive incentive to buy a new charger.

True. "Doctors with Borders" would not be as helpful for sure

It amazes me that funds hold long positions in a market without safeguards and regulations and that really has yet to formalize. I'm bullish on digital currencies but there's going to be a ton of turmoil while the world figures out how to deal with this new asset class and major shake ups as regulations start to formalize or continue to formalize in some cases.

Long plays in this market are massively risky bets. They seem completely unnecessary as well. With the volatility that exists and the decent level of volume, there's tons of easy money to be made.

- Doctors with Borders (https://www.charitynavigator.org/index.cfm?bay=search.summar...)

- Wikimedia Foundation (https://www.charitynavigator.org/index.cfm?bay=search.summar...)

- Houston Food Bank (https://www.charitynavigator.org/index.cfm?bay=search.summar...)

- American Civil Liberties Union Foundation (https://www.charitynavigator.org/index.cfm?bay=search.summar...)

- Ovarian Cancer Research Fund Alliance (https://www.charitynavigator.org/index.cfm?bay=search.summar...)

- A small dog rescue in Houston

- A small charity for women who are victims of sex trafficking in Austin

I also supported a number of projects (like Homebrew) via Patreon and Humble Bundle though those were not charitable contributions.

It really depends on your use case but one of the main "pros" of etcd is the narrow latency band when writing.

This article is likely biased to the good parts of etcd as it's written by coreOS but you can see how the latency of writes in etcd is very consistent compared to the wide range of latencies experienced writing to ZooKeeper or Consul:

https://coreos.com/blog/performance-of-etcd.html

There are other "pros" related to the fact that it's been designed for "cloud native" architectures like kubernetes. For example, FoundationDB can perform on average at sub-milisecond latency for writes (https://apple.github.io/foundationdb/benchmarking.html) versus 1.6ms on etcd however configuring FoudationDB to run programmatically is challenging as it was designed in an environment where ops people rack physical servers.

All key/value stores have good points and bad points but that's in relation to your use case. If write or read throughput isn't the most important, say it's consistency or availability, you may make a different choice about what are "pros" and what are "cons".

Another "pro" or "con" may be the language its written in or how it runs or deploys. If you run a Java shop and have tons of experience writing and deploying Java code, it may be in your best interest to be able to have more control by using a project written in Java. conversely, if you have all go engineers, you may want a project written in go. If you only have junior engineers, you may want whatever is easiest to operate and deploy.

Check out https://github.com/grpc/grpc-web

protocol docs here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md...

Thanks for putting this together, it's great to have something that covers backups and restore and operation all in one package.

I'd recommend updating the name to be more descriptive. Anything xDB sounds like it in itself is a database. That's what I was expecting. KubeDBOperator or similar would let us know: it's related to K8s, it has to do with databases, it likely manages deployments with HA/failover/backups.

As other commenters noted as well, you have to click at least 3 times before you understand what the software does based on the above link. Linking to the home page rather than the welcome would be a better choice for those not currently familiar with your project.

Either way, appreciate all the work that went into this project!

Thanks. I may be an outlier but I won’t download the trial until I know the cost. Appreciate you taking the feedback.

This mentions try for free many times but doesn’t mention pricing anywhere. Why don’t you have clear pricing information on the site that’s easily accessible?

Yup, Audi offers similar driver assists with lane changes(https://www.audi-mediacenter.com/en/technology-lexicon-7180/...), Land Rover has lane keeping (https://www.landrover.com/ownership/incontrol/driver-assista...), so do Honda/Acura (https://www.acura.com/rlx/modals/lane-keeping-assist-system-...) and many more.

I agree that Tesla overhypes their system the most and that contributes to consumer confusion. They use the classic Silicon Valley tactic of making their features which are comparable to competitors seem light years ahead through marketing. On one hand, it sucks for consumers, on the other hand, this type of advertising is rampant and they are playing the game.

Tesla’s over promising does erode trust. There’s only so many times you can promise stuff that’s obviously overhyped or years out (FSD) before consumers will stop believing the hype.

What’s interesting about Tesla is that almost all of their controversy is self inflicted by Elon’s comments.

What’s not clear to me is if this is intentional as he wants to stay in the news cycle or if it’s driven by his ego.

Would love to see that kind of consumer protection across the board. Almost every US ad looks like this these days:

100% effective, works wonders, fully natural!

(These statements haven’t been validated by any organization; our product may not be effective at all. Natural has no legal meaning but it seems good for you! Actually, our product is a placebo but thanks for throwing away your money!)

Yea, it is frustrating that these driver assistance technologies aren’t self driving. It’s also frustrating that they are over hyped.

At the moment, they are really good in certain situations (stop and go traffic, highways that are maintained properly and designed really well, roads without a lot of high speed curves, etc)

They won’t add value to many commutes but they add tremendous value to others.

Like all products, they are definitely not one size fits all

I totally agree that the marketing hype is ramped to the maximum. This is a result of the abysmal lack of consumer protection in US advertising laws. A large portion of advertising in the states is making overblown promises and unfortunately that is the standard. Tesla is not an outlier when it comes to over hyping their products.

Unfortunately so. I really wish advertisers were held to higher standards

I don’t understand what you disagree with. I’m not arguing for or against driverless cars.

I’m saying that our basis right now is whether or not driver assistance systems are making driving safer or less safe.

Driverless cars are currently only used in specific areas under tight regulation. They are not generally available and this article is about Teslas which are not self-driving, they have driver assistance features.

The original commenter above was making a remark about how the driver assistance features in a Tesla are “unsafe” due to a highway barrier accident.

I was making the counter argument that the driver was acting in an unsafe fashion by using driver assistance features as “self-driving”

I agree that if driver assistance features with a human driving are safer than driverless cars, driverless cars are not ready.

The point I was trying to make is that rather than talking about a single traffic accident, we have to look at the data. This is a law or large numbers thing, not penny press headlines.

I don’t think this a choice between driverless cars or not. We should be looking for the solutions which reduce traffic fatalities and injuries and also those which reduce the amount of hours wasted in traffic. Driver assistance features or self driving is only one angle for that. Improving road design patterns, building roads that actually follow the principles of psychology and fluid dynamics related to driving, properly maintaining roads, and other non technology related solutions are also potential factors for improvement.

This is definitely a major challenge for driver assistance features. Poorly maintained roads are less of a burden to humans who can more easily account for flaws in road design or maintenance.

What is also a major issue is lack of design patterns on roads. Rather than using a standard set of merging lanes, circles, right and left turn lanes, etc, there are hundreds of variations across municipalities. What makes it worse is that even the patterns in a single municipality aren’t often followed. We notice this when driving on 290 from Austin to Houston where the turn lanes are sometimes marked with a white line on the left and other times marked with a yellow line.

It’s going to take a concerted effort by legislature to help driver assistance and self driving cars by adjusting roads to make them safer rather than the free-for-all we have now.

You’re going to be disappointed for quite some time then. Most of the improvements to autopilot in the near future will be refinement of the cars reactions to sensor data and not new public facing features. They are closing in on the line where regulation does not allow for further “self driving” festures. Having the car change lanes itself is “self driving” and that’s why the driver must initiate the lane change. The same argument can be made about stopping at stop signs and red lights which is the next killer iteration of driver assist. Hopefully there will be enough data collected and good decisions made to allow for iterative improvements to driver assist features which would improve overall traffic safety.

That actually is a part of v9 autopilot but Tesla is never going to put that in writing.

The fixing of bugs like this without admission of guilt isn’t unique to Tesla. Apple, Google, Samsung, and many others do the same.

The reason they haven’t been buried in a lawsuit is because these are driver assistance features, not self driving features. It’s the responsibility of the driver to keep control of their car at all times.

Arguing that “people think they can drive with their hands off the wheel” isn’t a real legal argument. This is why Tesla warns drivers in documentation that they need to keep control of the car at all times.

This is the same legal argument that has caused warnings in microwave manuals about not putting animals inside them to dry them out. Just because someone misinterprets the capabilities of technology they purchase doesn’t mean the technology isn’t doing what it’s designed to do.

All self driving cars and driver assistance tools will be imperfect. The question is whether or not they are statistically safer than the average human. If you are an above average driver (by your record, not your impression of yourself), these tools may be unnecessary or may actually be worse for you. It’s the average and below average people that they do wonders for.

Please stop using one or two data points to form an opinion about something that has millions and millions of data points.

The main point that people are missing is that experienced engineers don’t want to work with people who think like the author of this article.

Protocol Buffers are not wrong, they simply have constraints, advantages, and disadvantages.

No language, binary format, text format, etc is free from advantages and disadvantages. All of them have different use cases.

If you are building a system where your data can be described by protobufs, it may be a good choice. If your data structures don’t mash up well and you have to manipulate them heavily, protobufs may be a bad choice.

Instead of pointing out use cases where a different serialization format may be better than protobufs and use cases where protobufs are better, and why, the author is spouting dogma about how protobufs are bad for every use case.

Be wary of working with developers who prefer to argue about why they hate certain technologies instead of providing useful data and ways to solve problems. You don’t always have to solve a problem just because you are aware of it but don’t go shouting from the rooftops that a technology sucks for every use case under the planet when that’s obviously not the case. The author’s opinion is more of: I don’t like protobufs. Not: protobufs are wrong

Thanks for the thoughtful reply. I think this is a good start and the question still remains as to how usable it will be.

We’ve seen this issue on mobile where users give access to certain capabilities on their phone and then are surprised at how apps use them (camera, mic, location, etc).

The challenge is how to describe these things in the way that the average user can understand and trust.

ACLs, capabilities, etc are generally easy for developers to consume but much harder for the average person to understand.

My main thought is that there will need to be some standardization of data and how it is consumed for this to take off. If a consumer is providing access to their location data in 15 different ways for 15 different apps, how are they even suppposed to keep track and understand that?

Standardization of ACLs/access has become standard on mobile and the permissions are very coarse so they aren’t overwhelming but it often leads to unwanted results. I’ve yet to see someone implement ACLs in a way that is easily consumable by the average user.

As noted, I’d love to see that happen. It’s a tough problem to solve but one that would benefit all users.

What’s not clear to me is how this will work from a data storage and access standpoint.

In order to have a permissions system, you have to have permissions. For example: read:photos, write:photos, read:running_data, etc

In order to do that, there are a few hurdles:

  - You have to define ACLs for every type of data stored in everyone’s POD. 
  - More complex is to define what parts of what data certain ACLs give access to. For example: I may want to provide heart rate data from my runs, workouts, and temperature data but not GPS. That’s getting very granular 
  - Since every app will have different or possibly new types of data, having a central standard for data types and ACLs will be tough. 
  - You’ll also need a mapping mechanism for where the data is stored and how it’s named and the formats that are being used. Even within a single app, you can denotmalize data and store it in multiple places for different purposes.

I like the principle of this but it seems very challenging to adopt. I look forward to seeing someone solve the above challenges.

What would be even easier to search is to use things that aren’t common words like:

Azure Cloud SQL R364T11

That’s hard to remember but likely narrows the search content drastically

I have no problem finding documentation for google cloud which has a similar naming scheme.

I don’t use a search engine though because they have made a good documentation site.

Adding a small identifier (as I suggested, even though jokingly) solves your problem as it’s easy to index:

Azure Cloud SQL Photon

That’s easy to understand it’s a Database and easy to search

Truth!

Names and Icons on AWS were made by people who don’t realize who helpful names and icons can be.

If it’s a database, use the cylinder icon that everyone knows is a database and then add some identifier to show which database it is.

If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.

If you want something that the marketing folks can feel proud about wasting time on, add the silly name to the descriptive name: Amazon DNS Potato

Wonder how pricing compares with http://www.jouleboxpower.com/. The batteries seem to be the large cost in these energy storage solutions. Removing them and using hydrogen in propane tanks may reduce costs significantly.

Exactly. Not having proper tooling meant they didn’t know what to do. When your check engine light comes on, you don’t replace every system in your car, you get out a scanner and check the code.

Google cloud has trace built in which could have shown them execution times and is dead simple to drop into most frameworks.

The real story here is that hey didn’t have engineering leadership on the team who knew how to properly diagnose issues, put tooling in place before launch, and understand how their system is architected.

Kudos to the engineers for solving this issue under pressure.

Good to know.

Agree that if there was a body with representation from all major engines, this could be good.

I personally don’t want my content to be served in such a way that requires me to use a specific analytics product though. Would be ok with it if log access was part of the standard.