I saw these folks at AfrotechFest[1] in London last year, which one of my colleagues helped organise, talking about their entrepreneurial experience. Really great to see them getting mainstream media coverage, and I wish them all the best. The idea of getting into a van full of blades with strangers was definitely joked about on stage, and if they can salve that concern then they must be doing a good job!
The Rolls engines designed for HOTOL were meant to do the same, by a different method. They were going to use the hydrogen fuel to operate the intake heat exchangers. The engine then burnt hot hydrogen. Any excess was used as reheat injected into the exhaust.
There was a movie showing their heat exchanger test going around. It is a gas to gas (helium.) And you can pump helium at very high flow rates. Speed of sound in helium is 1000m/s after all.
I find vector clocks to introduce a lot of complexity. In our case, we just use PostgreSQL to handle ordering. When committing an event into PostgreSQL, you verify that the last committed event for your stream is still what you expect it to be (i.e. CAS), and you have strong ordering.
Vector clocks I typically want to stay away from as far as possible.
Yeah, accept those writes and favour availability. Customer was a wealth management company.
Imagine a customer has £100 in their account. System partitions. Customer withdraws £70, hitting one DC. Customer then hits the second DC, this time withdrawing £50. Each DC thinks the transaction is valid, and so serves it.
Later when the partition is restored, events are played back, and divergent history is detected via the vector clocks - the two withdrawals are not causally related. Remediative action can then be taken.
Transactions prevent bad things happening, but require CP semantics. Eventual consistency allows AP, allows bad things to happen, meaning you have to be able to detect them and clean them up later.
There’s a long history on this debate, but in practice even the GOOG and AMZN have settled on transactional CP systems for handling the important stuff like money (Spanner, Aurora). Expecting app developers to roll their own transactions and conflict resolution at the app layer proved intractable even with all their resources.
> Remediative action can then be taken
Sounds expensive and error-prone; taking a “read only” outage makes more sense in many use cases
Does using Kafka help mitigate this? Or should it be producer-driven vector clock? I imagine the latter is the event-driven equivalent of a optimistic locking.
Edit - yep, the event producer manages and increments the vector clock.
---
I've not really used Kafka, so couldn't comment on that. I did some work for a customer that involved multi-DC microservices with isolated databases (ie one DB per DC). We used event sourcing with vector clocks to do manual reconciliation of the databases including during partition. Reconciliation involved custom logic depending on the event type, so not sure how a transport mechanism like Kafka would handle that.
Edit: to add on about Kafka, it guarantees a serializable ordering on the incoming messages and is driven internally by a vector clock. This may not be suitable for applications, but the throughput is high and allows multiple subscribers to get a consistent ordering.
I've got a Model X, and the touchscreen is only dangerous when using the on-screen keyboard. If I need to type something whilst driving, I engage Autopilot. There is voice recognition for the phone connectivity and Spotify, but I rarely use it.
Turning on windscreen heater, heating, and all that stuff is pretty straightforward, the on-screen buttons are always in the same place and are next to the bezel so you can anchor your hand. Plus cabin heating can be controlled via clickwheels on the steering wheel.
I think maybe the seat heaters are a little distracting. You can only tell their state by looking at the screen, and they cycle through settings. That's something I'd like a button for, or at least to be able to control via the clickwheels.
Edit
Studied HCI and Usability Engineering at university, did my dissertation in usability of web systems, and generally share your concerns. Not aiming to dismiss them, more say that in my experience it's not as bad as one might expect.
It's no more a distraction than opening a drink, taking a swig of said drink, or having to look around to see why the kids are crying in the back of the car.
Let's not suggest that Autopilot is safe completely unsupervised, and let's also not suggest that all drivers always look at the road 100% of every drive they take. There is a realistic middle ground, and I'm very grateful to have Autopilot to be an extra set of eyes.
The big missing piece is not LIDAR, but causal reasoning. Autopilot and similar 'AI' cannot reason; it doesn't have a mental model to ponder 'what if' and can't use counter-factuals to ponder what would happen if it didn't do something. It's just glorified pattern matching currently.
Reading Judea Pearl's The Book Of Why certainly sobered my outlook on AI.
Well, that's not necessarily true... self driving in particular usually uses planning, which is basically all about 'what if'. But it's true this is relevant to AI in general.
Isn't that more of an indictment of the self-driving industry as a whole? In Tesla's case they are missing that, but they are also missing LIDAR (or some other thing to fill in that technological gap).
The Porsche Taycan already exists and goes on sale at the end of the year. It's designed around an 800 volt architecture that can make use of 350 kW chargers. Porsche is also testing 450 kW chargers for the future:
I know specs are sexy but, you're missing one important detail here. Battery Longevity.
Tesla did not initially do this because they wanted the batteries on their customer's cars to last for a long time. Now that they have the data, they bumped it to 250kW along with the on-route battery warmup.
So far, I have not heard a single detail on how the Porsche Taycan deals with making sure the battery life is being preserved. This could have financial and ecological cost if not handled properly.
The same as it's done in every EV. The individual battery cells are charged in parallel to achieve the high rate of charge and the battery pack temperature is managed to ensure optimal battery performance:
Porsche's been making a particular point of the Taycan's temperature management. The goal is to be able to drive it like a sports car without overheating it. They talk about the Taycan offering "reproducible performance".
Teslas have a history of overheating when you try to drive them like sports cars:
Not sure what you mean. The current European superchargers use a Type 2 Mennekes adapter, but the protocol is proprietary.
I gather that European Model 3s will have CCS sockets (a superset of pins of Type 2 Mennekes) so they will be able to charge at other networks' stations.
https://www.afrotechfest.co.uk/