Two years back the S-bahn ticket machines at the aiport only supported chip+pin, not contactless. Had to open my banking app to figure out my pin code, as I wanted to use my corporate Amex
It's very confusing with a new Zigbee standard when I thought it was being replaced with Thread
And from the same organization that co-designed and promotes Matter.
Personally, I'm very happy that Zigbee continues to be developed. I am not very enthusiastic about everything being IP addressable (even if it is just ULA) and the convoluted Thread flow where a bunch of border routers require you to initiate the pairing with a phone over BLE to hand it over to the router. I have an Eve Energy Thread + Matter plug and it requires many takes to pair it correctly. Most Zigbee devices are just a matter of permitting join on your coordinator and holding/pressing the pairing button on the device.
I wish that Apple and Google would just add a Zigbee coordinator (or just leave home automation to others) and put some effort into supporting a wide variety of devices rather than trying to disrupt a perfectly working standard. They often cannot even bother implementing the latest Matter spec timely.
As someone who's run (and continues to run) both ZWave and Zigbee networks for over 10 years I find the direction of Zigbee rather frustrating. They used to be the antithesis of Zwave with it's frustrating "licensing" and now seems to be as though they're towing that line. Most likely because they got in bed with Google, Apple and the garbage that is Matter.
It didn't solve any of the issues it proclaimed to. And, if you look across open platforms (e.g. HomeAssistant) it has, comparatively, low uptake on available integrations because Matter is a vehicle for proclaimed interop by walled garden experts (e.g. Apple, Google, etc).
I've got several Matter smart plugs and a couple Matter smart bulbs.
They all were quick and easy to set up with their first Matter controller (an RPi4 running Home Assistant or an iPad with Apple Home), and quick and easy to add to whichever controller I didn't use as the first controller.
They all worked then without requiring me to get their manufacturer's proprietary app or make an account or anything like that.
Some needed a firmware update to support Matter 1.3, and so I had to use the manufacturer's app for that. Some also have proprietary functions and options (for example one of bulbs supports some kind of presence detection if you have at least two of those bulbs in the same room) so I might get the manufacturers app if I decide I want to use those functions.
Adding them to the manufacturer's app does not interfere with their use as Matter devices so if I do decide I want to use some of the proprietary stuff it doesn't break things.
1) If you have to use a manufacturers app for updates that's already falling into my point. 2) There are plenty of threads out there discussing manufacturers that leverage Matter but they force their own controller to be able to be used. A lot of these are together at builders as another revenue stream for them.
Finally... This [0] does a better job of explaining the issues with Matter. But, Matter is ultimately a joke. It was promoted as a standard by vendors nobody should trust for interoperability at this point.
How would you approach migrating a ~5 TB OLTP database that fundamentally constain analytical time series data? I’d think e.g., Apache Iceberg could be a better data store, and make writing much easier (almost just dump a parquet in there)
That 5 TB of data will probably be 3-400 GB in Parquet. Try and denormalise the data into a few datasets or just one dataset if you can.
DuckDB querying the data should be able to return results in milliseconds if the smaller columns are being used a better if the row-group stats can be used to answer queries.
You can host those Parquet files on a local disk or S3. A local disk might be cheaper if this is exposed to the outside world as well as giving you a price ceiling on hosting.
If you have a Parquet file with billions of records and row-groups measuring into the thousands then hosting on something like Cloudflare where there is a per-request charge could get a bit expensive if this is a popular dataset. At a minimum, DuckDB will look at the stats for each row-group for any column involved with a query. It might be cheaper just to pay for 400 GB of storage with your hosting provider.
Toyota's solid-state EV battery promises are almost as bad as Elon's full self driving timeline
Only exception is that they give themselves a bit more lead time "early 2020's" in 2017. Probably because they have an interest to delay competitors EV sales, while Elon is pumping FSD sales
Will be interesting to see which technology comes to market first
Have you ever in your life met, or even heard of, a single person who said "I'm not buying an EV because I read a PR piece that Toyota is doing R&D on some weird cutting edge tech thing" ?
The Californian government was a big booster of hydrogen at one point. Toyota might have reaped the rewards if California had built that infrastructure out (and, to be honest, if Tesla had failed early on).
Their hydrogen fuel cell technology is very good for what is. It’s just not something many people need.
i think they are making a point about Tesla's FSD specifically and not about autonomous vehicles.
We have been trying to automate trucks for one or two decades but I'm not exactly willing to bet on it getting beyond the testing phase in a specific calendar year.
At some point, either Toyota will have delivered or not.
Whereas Tesla have been saying FSD is amazing and breakthrough technology for years now and yet and, as a novelty, it is, kind of. Still needs human intervention. And I wouldn't trust my family with it at all. ymmv
So, we're back at the heart of the basic criticism it's had for years. They've been selling this dud for years, and it's still not feature ready.
I agree it's a bad choice of name, though I think the controversy is somewhat overstated.
In Tesla's view, "full" is an antonym to "limited", where Autopilot designed to work on a limited class of roads. In this way, "full" was intended to describe the system's intended ability to perform the full task of piloting a vehicle, not that the system has achieved some unspoken threshold of engineering perfection. In its current state, FSD can perform complete drives without intervention almost every time. (Yes, "almost" is doing a lot of heavy lifting. But the same is true of some human drivers who hold driver licenses.)
And to be fair, it's important to disambiguate technical and regulatory achievements. It is "supervised" because "unsupervised" would necessarily mean Tesla's software is the legally licensed driver of someone else's privately owned vehicle, which is a situation regulators are nowhere near contemplating. And it would require a vastly different insurance product to what is currently sold by insurers.
That's a lot of words to say that Tesla's self driving software is not ready yet and is undeserving of the name "full self driving".
Externalising the blame to regulators is pretty embarrassing, because regulations are flexible with respect to how well self driving cars work.
Why would Tesla be scared of having liability for a self driving car that drives better than humans? Shifting the liability to the driver who is merely sitting in the car and only exists for regulatory reasons and never controls the car is illogical in the case of the car never getting into an accident or violating traffic rules.
Additionally, it is still illogical even in the case of an accident as the driver did nothing to bring about the accident or traffic rule violation. Their existence as a backup can only prevent such things from occurring.
Assuming adversity from the driver is just one more reason to take control away from humans. E.g. the driver disengaged the self driving features to produce an accident on purpose as liability was shifted to Tesla.
Supervision appears to be extremely suboptimal for Tesla with no conceivable upside if we trust your word that regulations are holding them back from full self driving without the supervision disclaimer.
If anything, they have an incentive for locking out drivers from driving their cars manually. You should be paying for manual control instead of paying for full self driving.
> In this way, "full" was intended to describe the system's intended ability to perform the full task of piloting a vehicle, not that the system has achieved some unspoken threshold of engineering perfection.
No. Tesla simply lied. Tesla very specifically claimed it would outperform human drivers.
In 2016 Tesla claimed every Tesla car being produced had "the hardware needed for full self-driving capability at a safety level substantially greater than that of a human driver":
I don't think it's proven that Tesla knowingly lied as opposed to catastrophically misjudged the level of processing power required in 2017. But you'll get no argument from me that it's a distinction without a difference, for customers stuck with older iterations of FSD hardware.
A little bit of charity should be given to common turns of phrase, as opposed to being uncharitably pedantic. "A human" can also drive a stunt car on a movie set, or drive a fuel tanker around London city streets, or an F1 car around a race circuit at high speed.
Based on videos I've seen, FSD is absolutely fine with unpaved roads. My guess is it would fare as well as your average foreign tourist when placed in Delhi or Nairobi. But we can only guess.
As for driving on "lightly flooded" roads, this is an extremely foolhardy thing to do, especially in a normal passenger car, and if FSD refused to drive in that circumstance it would not be a mark against its abilities. Arguably a mark in its favour. Moving water can be orders of magnitude more dangerous than it appears. Even shallow standing water can conceal debris which could insta-destroy a tyre, or your suspension, or your coolant loop, or your fuel tank.
Mailing lists are horrible for people new to a list, as you have no history to search in your inbox and the UI to browse the archives are beyond atrocious.
People that have been on the list for decades tend to forget this, and wonder why it dies down
Usually an email archive of the list is available for download, which you can incorporate into your local archive. In case none is available, what I have sometimes done is to ask a resident member (privately) if they can send me their archive.
Wait, what? I regularly use marc-info (for OpenBSD) and emacs-devel, and it’s quite easy to find information. And you can always get the mbox and use something like mairix if you want local tools.
I've used Claude Code in the past month to do development on CoMaps [1] using the 20 USD/month plan.
I've been able to do things that I would not have the competence for otherwise, as I do not have a formal software engineering background and my main expertise is writing python data processing scripts.
E.g., yesterday I fixed a bug [2] by having Claude compare the CarPlay and iOS search implementations. It did at first suggest another code change than the one that fixed it, but that felt just like a normal part of debugging (you may need to try different things)
Most of my contributions [3] have been enabled by Claude, and it's also been critical to identify where the code for certain things are located - it's a very powerful search in the code base
And it is just amazing if you need to write a simple python script to do something, e.g., in [4]
Now this would obviously not be possible if everyone used AI tools and no one knew the existing code base, so the future for real engineers and architects is bright!
reply