svorakang

Well. I have worked quite a bit with Chinese businesses and let's just put like this: It does not matter much whatever license you think the SW or HW has. Whatever is available will be used and modified to the liking of the customer.

It is common for new employees to walk in with code bases of previous projects they have worked with and there is a great deal of administration involved in ensuring that no one else gets to work with more code than they absolutely need. Local builds and copying binary archives is common practice!

Road approval looks very differently for mass-produced vehicles. It is not an easy thing to pass.

You might have a point there, but I struggle to find any completely hackable product that is also safety-critical. Some airplane, nuclear reactor or some train, perhaps?

I'm all for open access to the code for the sake of safety. On the other hand, I'm completely against hobbyists accidently bypassing a safety mechanism.

Open access, but secure access to software download could make sense, at least for commodity parts.

When it comes to features with competitive advantage, though, I don't see that OEMs or its suppliers have anything to gain.

Neither safety now environment is something you can easily wave at like that. Also, you're completely missing security concerns and legislative.

I have worked in the automotive embedded software industry since 2009 and I have got caught in the safety track in my career. It's a strange place to be, because the basics are extremely simple, yet it takes hundreds if not thousands of man-years to get a modern vehicle reasonable safe just in terms of the electrical system (this includes the software in automotive terms). There are so many ways to make a mistake that could easily result in an accident. Even the window regulators have non-trivial implementation concerns for anti-pinch. Allowing a random hacker to override this is a terrible idea. Now imagine what kind of mess you could do with brakes and steering...

Designing a vehicle to be hackable will very likely lead to an unsafe vehicle.

I believe what I just wrote applies similarly for security too.

Furthermore releasing software for the market, extensive testing is carried out by an independent body to ensure that legislation is followed. Even conceivably simple things such as lighting or headbeam alignment is a pretty large problem domain by itself. Also, so is just the communication standards for diagnostics.

I would say that large changes would be required to transform this industry. In some, protected domains there is use of open source, such as Qt/Linux for HMI, but opening the HMI to be fully hackable is unlikely to happen. There is quite some liability to make the HMI non-distracting.

This akin to parking anxiety, where you never know how long it will take to find a parking in the city. Still, we have cars in the city.

I've had an ev for over five years now and I have so far waited on a charger once, for twenty minutes. And that was at peak hours of the spring break mountain rush (when every swede packs their cars and heads from the populated south to the mountaneous north-west).

On the other hand, I have spent accumulated hours on driving from broken charger to charger that is only for customers to one that I'm not sure if it's in operation yet.

Also hours on just installing different charging apps with the usual registration flow (email, password, verify email, register card, etc).

More chargers and standardized experience (why not just chip and pin?) would be highly appreciated.

PS1 was a low volume car, almost concept level. The UX of PS2, a large volume car, is much better and generally very well received.

I must be doing something terribly wrong. I've had my bike for 7 years now, use it every second day, in all kinds of weather, and I lube it twice a year at best. It ought to be falling apart!

What's your basis for your claim of such frequent maintenance? Also, what do you mean by a modern bike?

Automotive embedded C developer here. Most of the code in this industry is implemented in a subset of ANSI C90. The reason is not header files, libraries or linker scripts. The reason is as the grandparent post points out: compiler availability.

For rare targets, there's just no money in making a compiler work for more than this small subset of C. My favorite example is the compiler for a really strange architecture where everything is 24 bits. Char is short is long is a pointer.

Bigger controllers tend to be ARM-based, so it's getting better.

Also Tricore has a big share, but their compiler support is getting better. There was even a rust compiler being announced recently, though I doubt it's using LLVM backend, so it's likely to be behind in terms of features.

Hah, I fought a battle for months at a Nordic automotive OEM, to try to stop them from overusing "fora", to no avail. They were so convinced that it was the proper word to use, they also used it in singularis, as in "We will bring that up in another fora", often then also referring to a single meeting to be held in the next day. This is only one tale out of many on how corrupted the corporate Scandinavian English can be, and sadly, since being essentially marinated in this parlance, I can probably only detect and reflect of a fraction of the linguistical felonies committed around me, and worse: by myself.

What you're asking for is a microkernel os, or at least a generic kernel shim to interface a user space driver.

Example of microkernel: QNX.

Example of userspace driver: fuse.

I'm not familiar with the architecture of OpenBSD, does it run it's drivers in userspace?

There are jobs if you know where to look.

I regularly see ads searching for C++ developers. I'm in an automotive-heavy region in Northern Europe. C++ is widely used in HMIs, AD/ADAS, and general service development (diagnostic services, middleware). I also see the need of C++ developers in medtech and automation companies around here.

The ads request some experience, but in practice they are happy to recruit what they can find.

Some technologies change, so does C++, but not so long ago I landed a C++ gig for €80+/hr, although being more of a ANSI C90 expert, only used C++ occassionally (for test environments mostly), and being completely out of synch with the "latest" concepts of modern C++ and its tooling (as a reference, std::move was new to me; CMake was an annoying bigger sibling of Make). Customer was happy until that Chinese virus became a fad.