For 1) it's the first time I hear it from a technical point of view - Tesla's dashcam records continuously for the last 10m, and should save the data on the internal computer in case of a crash and send it back to Tesla if feasible AFAIR (I'm an owner). IIRC it's not the first case though where Tesla claimed the data wasn't available or corrupted, and then it was actually recovered some time later after pressure from authorities. So I think technically the data is there, but also believe Tesla is behaving unethically and dishonestly to cover up or delay retrieval.

2) I often hear it as FUD, as in: AP/FSD was off, the user just did it by accident, wasn't accustomed to it, or just didn't know how it worked. AFAIR most of the accidents had the data released and showed some of the following: user touched steering wheel and disengaged autosteer/FSD (whether knowingly or by accident), user was pressing accelerator pedal by accident, user was pressing accelerator instead of brake, etc etc

AEB should still be working to pump the breaks AFAIK, but auto-steer and cruise control will be disabled while the computer and electronics are still perfectly operational to make the car more secure for the passengers and first responders after the event.

EDIT: IIRC the threshold for disengagement is 1s.

The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.

IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.

I normally run applications maximized on my 28" 4k, unless I need input from 2 applications at the same time, then I tile them.

Working from my work-issued 16" Macbook Pro or any other of my laptops is a pain because of the limited estate - it's hard to see patterns at a glance or get the whole context when I can only see 30 lines of text that is truncated at <=80 columns. Plus, the fact that the keyboard isn't detachable from the screen forces bad habits on the posture.

Unfortunately that is not the experience for the average driver of a PHEV. Most people buy by brand, not by specs, so the average result is what you see in the links of EVClinic - 80`000km cars with fried batteries that cost more to replace than the resale value of the car itself (and again, as also noted by EVClinic IIRC, BYD is better than average in regard to repairs and parts cost).

Starlink already accounts for these (e.g. https://www.theregister.com/2025/11/18/starlinks_method_of_d... ), and in any case they are put in orbit so that they eventually fall back to earth in case control is lost.

The problem is that even one satellite could start the Kessler syndrome due to how many are currently in orbit, and the numbers are expected to keep increasing rapidly - everyone wants their "sovereign" Starlink now that it has been shown to be feasible and performant.

> I also believe that most pure BEV drivers would charge their cars daily to mitigate the risk of range anxiety.

(not parent poster) I got the perspective from people that wanted to help other people, but stopped repairing PHEVs:

- https://evclinic.eu/2025/09/27/if-you-drive-a-hybrid-may-god...

- https://evclinic.eu/2025/01/19/ultimate-ev-ice-and-hybrid-co...

- https://evclinic.eu/2025/12/04/2021-phev-bmw-ibmucp-21f37e-p...

The difference with BEV charging is that the battery is much bigger and it's a core component (it's properly serviceable), so I can charge it at 60%, keep degradation at bare minimum, and still have 270km of range. With a PHEV you'll need to always charge it 100% to fully use that EV range, so the battery will degrade way faster due to way more cycling.

- the button is integrated in the A/C dashboard? Everything needs to be replaced. Part cost: 250-600€ depending on car model and brand

- some dashboards can be stupid annoying to disassemble (Claude mentions VW, BMW, ...), 2-3h work at the dealer: 240-540€

- diagnostic fee they'll charge before they touch anything: 80-150€

Total cost: 550-1300€

"...With a premium German brand and a complex dash, breaking €1,000 for what is functionally a single button is entirely realistic..."

Yes, you can save money if you go used/aftermarket and DIY, but the same applies to Tesla.

Tesla:

- 1300€ touchscreen (e.g. for my old M3 2019): https://epc.tesla.com/it-IT/catalogs/34f82bd6-90fb-417c-8a06...

- probably 45m tops disassembly and reassembly: https://service.tesla.com/docs/ModelY/ServiceManual/en-us/GU...

Lots of used parts available, since they have the same parts for 10+y now.

Why? I do that. I give it broad permissions but I also give it very specific instructions, especially when it's about deleting resources. I work in small chunks and review before committing, and I push before starting another iteration (so that if something goes wrong, I have a good state I can easily restore).

I'm the one with the brain. The LLM can regurgitate a ton of plumbing and save days of sifting through libraries, but it'll still get something wrong because at the core it's still a probabilistic output generator. No matter how good it becomes, it still cannot judge whether it's doing something a human will immediately spot as "stupid".

Interacting with and fixing API calls automatically is something that normally works for me, but allowing the agent to run a terraform destroy is something I'd have never let it execute, I'd have been very specific about that.

Quality looked amazing, but the pre-installed phone camera gets close enough and it's instant.

At the moment, there isn't another project (that I know of) like PostmarketOS filling the same niche. If a new project were to appear, and were using LLMs, it'd likely progress faster.

Regardless, I've had success with LLMs and while I understand the maintainers' concern, if used properly they're a powerful tool to quickly iterate on huge amounts of information. They could be used to automate reviews of the spam of low-quality PRs, for instance (if they were to materialize).

But having read their policy page, their stance is more on ethical grounds, not moral: https://docs.postmarketos.org/policies-and-processes/develop... . So while I still stand by my argument in the general case, here it's not applicable, and while I see their ethical concerns, one project boycotting a tool doesn't really fix the systemic issues they mention.

There's no moral necessity, but if you want to survive as a project moving forward, you'll have less and less velocity compared to projects using LLMs, so you'll eventually shrink and die as a project, because less people will contribute to a project that gets less features and bug fixes.

I don't understand why these projects have such a strong "moral" stance of "no AI ever", and instead they don't deploy LLMs to automatically review PRs based on their own guidelines, so that if the contribution is valuable, it gets through no matter if it was written by an LLM or not.

A lot of my developer colleagues don't know how git works, so they have no idea that "I merged the PR" != "I deleted the feature branch". I once had to cleanup a couple repositories that had hundreds of branches spanning back 5+ years.

Nowadays I enforce it as the default project setting.

I understand it has become a standard but it's not a particularly good one, and adding it "just because it's a standard" would detract from the car experience in my opinion. It's a separate device, with a separate OS, kernel, apps etc where you can install almost anything, that's supposed to take over a piece of equipment that belongs with the car and controls all its functions. I'd really rather not have that.

If the infotainment is the basic "show 2D maps and a couple settings", then Android Auto/CarPlay can serve as a viable replacement for low-end cars. But when the car costs >30k and the screen is also the central command console, no thanks. I'd rather have proper OTA updates, give feedback, and see it evolve over time for the better.

We're running a self-hosted GitLab -> hosted GitHub migration at my company (which to me feels a downgrade), and without LLMs I would have spent weeks just researching syntax for how to implement the requirements I had.

I asked Claude to simply "translate these GL templates to GH actions, I want 1 flow for this, 1 flow for that, etc" and it mostly worked. Then in the repos I link the template and ask Claude to write the workflow that uses the template with the correct inputs. I think I saved maybe 3 months worth of coding and debugging workflows. Besides maybe picking slightly outdated actions (e.g. action@v4 instead of action@v6), 95% of the work was ok, and I had to tweak a couple things afterwards.

China supplied the batteries, sure.

But there's definitely a pre-Tesla and post-Tesla world regarding the vehicles themselves. Tesla changed the image of EVs available to the general public by making performant and low maintenance vehicles that looked futuristic and were capable of things basically only supercars could, for a fraction of the price. And they built the DC charging infrastructure all over the world to support long-range trips, which was non-existent before Tesla. EVs before Teslas were basically niche experiments.

As an example, after a refreshing 8h night's sleep, you put yourself at the wheel and you know you need to drive for 8h. After 2h, you'll feel the need to stretch your legs, have a bite, go to the toilet.

But if you have something like Tesla's AP, you'll still be alert and awake. Otherwise - at least for me, but I bet for many people - the constant nagging of micro-correcting the wheel, keeping the distance to the car in front, keeping the right speed, takes a huge toll on your mental resources, so much that it puts you to sleep whether you want it or not, and many people will try and push through that regardless.

You're saying that cruise and lane assist are dangerous because they're used to do bad things.

I'm saying they're very liberating from the busywork that is driving, and even people that use them as an excuse to stay on their phones are better off for it, because something more alert and precise is driving for them and as a consequence, less harm can derive from their stupidity.

I'm not saying that people that do stupid things should not be punished, and I'm quite happy that Tesla had to implement better driver monitoring. I know how things work and that I always need to monitor the system, but many people assume it's a magic button and disconnect their brain.