Good job! DLT logs are pretty standard in the infotainment industry, the format specification is openly available. I recommend you to download DLTViewer from GitHub and open the log files (if they are not encrypted). You may find good stuff there!
Author here. Yes, there is some good stuff in the logs, I found the Wi-Fi password there, that was useful. At the time I used some VSCode plugin to read the .dlt files (they are not encrypted), but later I did find that dlt-viewer on COVESA's GitHub.
You are right. Last year I've got a virus named covid (probably you have heard of it). For a few days I've lost the taste of food. I mostly stopped to eat in such days. Eating food that tasted of nothing was totally unpleasant!
This is not how odometers are scammed. The EEPROM gets rewritten to zero, then you can increment the odometer to your preferred value via OBD/UDS. Please note that you can only increment the odometer without a specialized (authenticated) diagnostic session.
FYI I do not reset odometers, I am on the other side, developing software for instrument clusters.
Deleting the DTCs is really trivial. It's just a standard UDS command. The only way to avoid this kind of scam is buying vehicles that have done the official maintenance/inspection. That will report the odometer to the car maker.
> The only way to avoid this kind of scam is buying vehicles that have done the official maintenance/inspection.
Agree, but not everyone here can afford <5 year old vehicle, so people have to do with the means they have. As soon as warranty/lease ends, people generally go with cheaper, non-manufacturer maintenance shops.
Additionally, the composition of certified products does not lead to a certified product. Even adding an enclosure around a certified board implies the recertification.
Think of the Linux kernel. That's a huge project, organized in an object oriented fashion. Is there a difference between this->method(arg) and method(this, arg)?
It'd be more like typename_method(this, arg, &err) in C because there are no namespaces or exceptions. Also you'll have to manually call destructors.
So yeah, it works fine, just more verbose cause it lacks some syntactic sugar. I prefer C for simple or high-performance programs, and I can see why people might want C++ for larger ones. Problem is some people make a mess pulling out all the stops in C++ OOP features.
> We must not use [...] Qt Creator [...] to build software using Qt LGPL-3.0 or Qt GPL. It doesn’t matter whether these tools are also available under a non-commercial Qt license.
This is the weirdest part of Qt licensing for me. An IDE is an IDE, you should not care what I develop with it. I don't even understand how is that possible, since Qt Creator is GPL3.
> I don't even understand how is that possible, since Qt Creator is GPL3.
very simply because it isn't possible and the article is just wrong. You can entirely use LGPL Qt Creator to develop proprietary apps. What you mustn't do is e.g. ship a modified version of Qt Creator as part of for instance an embedded SDK and not ship its source.
The part quoted is explicitly about the QT commercial license. Apparently, you can't use QT commercial with non-qt commercial (and Qt Studio non-commercial).
And probably this is done to be able to sell the IDEs, maybe based on n. of users, etc. Never bought Qt so I don't know how they license "users".
They obviously want you to pay for the whole development duration and for all developers; they don't want you to use the GPL/LGPL licensed stuff during development and then to buy a commercial license ony for deployment, or to buy just one commercial license and use GPL/LGPL for the other developers.
This is btw not the only trap in the license agreement; if you sign that, you are significantly less well off than if you can do everything with LGPL.
