I hope editorial departments everywhere are taking careful notes on the ars technica fiasco. Agree there's room for some kind of quick "verified human" checkmark. It would at least give readers the ability to quickly filter, and eliminate all the spurious "this sounds like vibeslop" accusations.
until then, there's a simple rule which works well: never talk to a cop. Or at least say the minimum number of words possible, give them nothing to use against you. Present ID if they ask for it, but never admit anything. If they persist, "lawyer". That has worked for me.
That's super cool, I'm currently struggling with scan tools for a 1999 Mercedes E300 Turbodiesel. I had one that worked OK for about a decade (Autel something or other) with a 38pin connector, but it recently bricked itself with a message like "connect via USB to Updata" which I assume means its firmware somehow erased itself. Cannot figure out how to "updata" it, doesn't seem to connect via USB, the Autel software runs under Wine but doesn't appear to recognize the device... gave up and bought an iCarsoft device which sorta kinda works. It can talk to every module except for the ECU (Bosch MSA 25.1 I believe?) however if I tell the device that my car is a different model (1995-1997 naturally aspirated) I can blindly clear ECU DTCs, which is good enough because this thing is barely more complicated than a toaster. All that is to say, this space is ripe for some open hardware/software love.
Not sure about your specific car, but a lot of the “consumer friendly” options like OBDeleven, Carly, etc are fantastic. You often have to pay, but a lot of work goes into them and they often just work.
Interesting...1999 is probably a bit early for that Bosch to be running one of the usual ECU update protocols like UDS. It sounds like it's in the bootloader and looking for a valid executable. So the FW updater is likely in the bootloader.
If you can open it up and find the JTAG pads, it should be simple-ish to use a JTAG reader to dump the image and then you can figure out the update protocol from that. It's unlikely to be complicated.
I just remembered one interesting thing that may help you if you make progress. The computer can only send a couple data items at and keep the engine running. So be careful how much/fast you ask.
> All that is to say, this space is ripe for some open hardware/software love.
There's just so many computers and what-not in modern cars that this is a very tall ask. You'd need a project on-par with HomeAssistant to get anywhere.
Yeah, it seems like more modern technology has settled on standard protocols (maybe a naive impression--someone will shout at me if that's the case) but there's probably a very long tail of bizarre false starts if you want full coverage of models back to the early 90s when computers became more commonplace.
After 2006/2007 nearly everyone did CAN. I think that is even mandatory in the US, though I have no clue how to look that up (I assume there are details and exceptions) However before then everyone did their own thing. Often with custom chips that haven't been made since 2004 (or even 1999): good luck finding one that works if it breaks. CAN is cheap and allows a lot of power while hiding most of the protocol complexity. The things before that were often not as powerful as CAN, while being in practice a lot more complex because the complexity wasn't hidden.
I remember getting that era working. I concluded Mercedes was trying to be clever in making a protocol so complex nobody else could understand it (thus ensuring you had to use a dealer) - and then discovered they couldn't debug it.
each body model (nothing to do with year or style) was different so clearing dtc but nothing else is not a surprise.
i did get that working, but I last touched it in 2007 so I don't remember enough details to be helpful. good luck.
> I concluded Mercedes was trying to be clever in making a protocol so complex nobody else could understand it (thus ensuring you had to use a dealer) - and then discovered they couldn't debug it.
It's mostly around engineering whether you have enough downtime to "move" your "driven" hours into.
For long-haul it's probably a bit different, but other routes have a lot of annoying delays.
E.g. waiting at a port, waiting for a trailer replacement, waiting for receiving, etc.
Afaik, these are all classified as driving hours for logbook purposes.
It creates a situation where you legally have to park a truck on the side of the road when you hit your cap, even though 1/2 of your day might have been waiting around for something.
Imho, that's a bit ridiculous, and I'm sympathetic to shadow logbooks there.
For the 16 hours straight cross-country pounders, less-so. But long-haul is what autonomous trucking will likely eat first.
The toll it takes on your sleep schedule is also brutal, because the rule is 10hr on / 8hr off. If those 8 "off" hours happen to coincide with sleeping hours you might get some rest but that won't be frequent, or enough. It would be better, smarter, and safer to just drive 16hr and then sleep for 8hr. But the rules are the rules, they don't have to make sense.
If you actually use two 120V circuits that way and one breaker flips the other half will send 120V through the load back into the other circuit. So while that circuit's breaker is flipped it is still live. Very bad. Much better to use a 240V breaker that picks up two rails in the panel.
i am guessing, without any proof, that, when one breaker fails the server lose it all, or loose two GPUs, depending on whether one connected to the cpu side failed.
GPUs aren't electrically isolated from the motherboard though. An entire computer is a single unified power domain.
The only place where there's isolation is stuff like USB ports to avoid dangerous ground loop currents.
That said I believe the PSU itself provides full isolation and won't backfeed so using two on separate circuits should (maybe?) be safe. Although if one circuit tripped the other PSU would immediately be way over capacity. Hopefully that doesn't cause an extended brownout before the second one disables itself.
IME one thing that makes this choice a very difficult one is oncall responsibilities. The thing that incentivizes code owners to keep their house in order is that their oncall experience will be a lot better. And you're the only one who is incentivized to think this way. Management certainly doesn't care. So by delegating the choice to management you're signing up for a whole bunch of extra work in the form of sleepless oncall shifts.
If someone is making the kind of mistakes that cause oncall issues to increase, put that person on call. It doesn't matter if they can't do anything, call them every time they cause someone else to be paged.
IME too many don't care about on call unless they are personally affected.
> If someone is making the kind of mistakes that cause oncall issues to increase
the problem is that identifying the root cause can take a lot of time, and often the "mistakes" aren't clearly sourced down to an individual.
So someone oncall just takes the hit (ala, waking up at 3am and having to do work). That someone may or may not be the original progenitor of said mistake(s).
Framed less blamefully, that's basically the central thesis of "devops". That is the notion that owning your code in production is a good idea because then you're directly incentivized to make it good. It shouldn't be a punishment, just standard practice that if you write code you're responsible for it in production.
Optimal in what sense? In the java shops I've worked at it's usually viewed as a pretty optimal situation to have everything in one language. This makes code reuse, packaging, deployment, etc much simpler.
In terms of speed, memory usage, runtime characteristics... sure there are better options. But if java is good enough, or can be made good enough by writing the code correctly, why add another toolchain?
> But if java is good enough, or can be made good enough by writing the code correctly,
"writing code correctly" here means stripping 95% of lang capabilities, and writing in some other language which looks like C without structs (because they will be heap allocated with cross thread synchronization and GC overhead) and standard lib.
Its good enough for some tiny algo, but not good enough for anything serious.
It's good enough for the folks who choose to do it that way. Many of them do things that are quite "serious"... Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java. It's not low effort, you have to be careful, get intimate with the garbage collector, and spend a lot of time profiling. It's a totally reasonable choice to make if your team has that expertise, you're already a java shop, etc. I no longer make the choice to use java for new code. I prefer rust. But neither choice is correct or incorrect.
> Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java.
those have low bar of performance, also they mostly became popular because of investments from Java hype, and rust didn't exist or had weak ecosystem at that time.
> you would know it should not be mixed like in a dj set, and you would not optimize your dj algorithm for it.
Yet the computer program happily tried to do it anyway. It would be much better to fail with a clear error message than to try to proceed and emit garbage.
I hope editorial departments everywhere are taking careful notes on the ars technica fiasco. Agree there's room for some kind of quick "verified human" checkmark. It would at least give readers the ability to quickly filter, and eliminate all the spurious "this sounds like vibeslop" accusations.
reply