The Irish NCT results for 2024 show high failure rates for Teslas in:
- Vehicle safety and Equipment
- Steering and Suspension
- Side Slip
- Wheels and Tires
and to a lesser extent
- Lights
- Lighting and Electrical
The (Tesla) overall failure rate is over 50% (697/1301), which is above the (population) overall failure rates of just under 50%.
Note that the oldest Tesla is 2015, and most are 2020+ which is significantly newer than a good chunk of the cars on the road here.
Also note that in my personal experience of ~10 NCTs, I've had 3 nominal failures which were stupid trivial things that aren't actually maintenance issues. (1, extra seat not in car. 2, tent peg fell in and folding seat didn't lock in place. 3, folding seat wasn't up when tested, as well as at least one where my mechanic swears that they screwed it up (steering rack boot not attached))
Suspension and steering is probably loose bushings. Side Slip is alignment/tracking. Wheels and tires is almost always worn tires, especially passenger side front due to roundabouts.
I'm not sure what the vehicle safety and equipment failures would be, nor the distinction between lights and lighting and electrical. The fact that it's a noticable failure point is a little surprising to me because all the lights should be LED and pretty solid.
(Though, I'll say, even though we have mandatory inspections, 5-10% of cars in my area are driving with at least one light that's out.)
That is probably because the ID4s had pre-inspection before their yearly technical inspection. That is what they do in The Netherlands, probably also other countries. That makes their cars stand out in these reports.
Don't all cars in the Netherlands have at least a small checkup before inspection?
I once had a Fiat Panda from 1984, 20 years old by then. It had a small checkup and maintenance, then went for the inspection. It passed, but was highlighted for inspection from the controlling organizing. The mechanic, owner of the shop, started getting really nervous about losing his license, asking, is the car allright, is it really allright? And it passed inspection again.
They had an overall failure rate of 20% so I don't think that's the case.
Anecdotally most people I know here don't bother with preinspection. It's usually cheaper even if it fails the first time. Although looking at the data most people driving EVs could probably save time/money by investing in a tire thread guage!
Also to add, the Irish system is totally different to a lot of Europe. The owner always brings the car for inspection, it's never part of an annual maintenance package.
There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.
There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2].
So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration.
When I've run into this is with data migrations, or if you're adding/assigining permissions to groups.
Did you mean migration signals (pre_migrate and post_migrate)? They are only meant to run before and after the whole migration operation, regardless of how many steps are executed. They don't trigger for each individual migration operation.
The only catch is they will run multiple times, once for each app, but that can also be prevented by passing a sender (e.g. `pre_migrate.connect(pre_migrate_signal_handler, sender=self)` if you are registering them in your AppConfig.ready method).
Does that affect the autogenerated migrations at all? Teh only time I ran into that issue as if I generated a table, created a data migration and then it failed because the table was created same transaction. Never had a problem with autogenerated migrations.
Whether they are allowed or not, probably depends on the place.
In Germany, at Frankfurt, I had to dump in a garbage bin a smaller Swiss army knife, to be allowed to pass.
I had it because my high-speed train of Deutsche Bahn had arrived more than one hour late, so there was no time to check in my luggage.
After losing the knife, I ran through the airport towards my gate, but I arrived there a few seconds after the gate was closed. Thus I had to spend the night at a hotel and fly next day, despite losing my knife in the failed attempt to catch the plane. Thanks Deutsche Bahn !
>Whether they are allowed or not, probably depends on the place.
It's a EU thing, even though the Swiss are outside... and I was sure it was a directive until:
The recommendation allows for light knives and scissors with blades up to 6 cm (2.4 in) but some countries do not accept these either (e.g. nail care items)[citation needed]
I thought it was universal mostly since I had no issues at the airports.
Prior to the 6 cm rule, once I had to run to a post office at the airport and mail a parcel to myself with the pocket knife (which is also a memento)
I don't recall it in Frankfurt last summer, but it was definitely going earlier this month. Though, they've got a weird security setup for some of the gates, so I'm sure it varied from gate to gate. Dublin and Edinburgh have had it for a while too, Dublin since last summer. Really speeds up security.
Yeah, even small airports like Belfast City have had it for the past couple of years. Other London area airports (Luton, City, and Gatwick - not sure about Stansted) have had it for about as long, too.
Heathrow's definitely a straggler - I'm assuming it was a more difficult project for them due to their sheer size.
It's a specific liquid scanner that's done on bottles that have been pulled aside for extra scanning (at least, that's what Frankfurt was doing a couple weeks ago)
As far as I know, it's not. You're now specifically told to not take liquid out of your luggage.
At least that was the situation when I flew out of London Gatwick last time - they had people going up and down before the scanners admonishing people to leave everything in their bags to avoid delay.
We had 4 bags go through, 3 had liquids (2 water bottles and one Barenfang) in them. All three were pulled for secondary screening, at which point they put the specific liquid bottles in a secondary scanner and cleared them.
So, yes, they stay in the bag, but then they're pulled out and scanned separately, at least in Frankfurt.
I've noticed every airport is different, and major airports are usually more likely to have the big fancy looking scanners that help keep the crowd moving along, without taking everything out. Smaller airports seem to have less of that tech and are thus often more of a hassle.
And yet somehow, airport security staff frequently get impatient when people in line ask whether to remove their shoes, laptop, etc. As if the travelers are stupid for asking.
This is a fairly new change - the new scanners are being rolled out "everywhere", but not everyone has them again, and there were some snafu's last summer that caused them all to be decertified within the EU, and at least for a while only scanners from one company had been recertified.
It'll probably be chaos for the next couple of years while this sorts itself out.
1) It's not. Maplibre is a JS library for displaying map data. OpenStreetMap is a collection of map data that is published in various formats. Different levels of the stack.
2) It's an optimization/advancement. There are some pain points in the older version that 10 years of experience can fix in a newer format.
3) Attention, funding. Technically, they're at the leading edge of open source.
Additionally to point 2, the older format was created by a company (Mapbox) that used to be open source-friendly but has recently made a larger pushback against open source and open standards, changing the licenses of much of their formerly open source work. (The Maplibre JS library itself is a fork of that company's previous open source work from its last open source drop to keep the work open source.)
Lack of tessellation was a big one. In many cases you'd rather have the polygons pre-tessellated in the file format. Now you can. Or you can avoid doing that and save the bytes.
The format is also designed to slide onto the GPU more easily. If you're writing a vector map from scratch, I say just do MLT.
There was never any support for more complex geometry. Now someone could add curves.
Attributes had to be fairly simple. Now you could conceivably do hierarchical attributes.
The requirements for navigation data tiles get specific and weird (from a visual perspective). Now it can be added without breaking existing data.
Me too. Mini has gone from main dev machine, to backup, to kids, and now to Lightroom. It wasn't a slouch BITD, 6 core and 32G ram. It's a bit slow now, but not that bad even on the 4k screen. But it's the best thing I have that runs 32 bit MacOs.
Interesting that citibike publishes trip level data. The bike share schemes in Dublin only publish station counts or free bike locations. So you can see the overall pattern of bike motion, but there’s no way to see how many north side trips go to the docks vs Heuston station vs the city center.
Greylistibg is very effective in my experience, but there are definitely some confirm your email loops that won’t work without whitelisting. It’s a combination of multiple ip addresses and retry times greater than the life of the code.
Note that the oldest Tesla is 2015, and most are 2020+ which is significantly newer than a good chunk of the cars on the road here.
Also note that in my personal experience of ~10 NCTs, I've had 3 nominal failures which were stupid trivial things that aren't actually maintenance issues. (1, extra seat not in car. 2, tent peg fell in and folding seat didn't lock in place. 3, folding seat wasn't up when tested, as well as at least one where my mechanic swears that they screwed it up (steering rack boot not attached))
https://www.rsa.ie/road-safety/statistics/nct-statistics-and...
reply