Automotive Grade Linux Launches New Expert Group Led by Toyota | Hacker News Reader

Automotive Grade Linux Launches New Expert Group Led by Toyota

automotivelinux.org

74 pointsteleforce54 comments

Am I the only one who hears "Software Defined Vehicles" and thinks, "wow, these companies really have entirely lost touch with what everyday people need and/or want" ?

I'm half convinced the right company could make a decent hybrid small or tiny vehicle (like Fiat 500 size or Mini size at most) for under $15k given Ford apparently was or is fine making hybrid Mavericks for like $26k and only raised the price because dealers and lack of competitive forces. Though the prices of three wheelers (often more than a Maverick) suggest maybe I'm wrong.

Where's the fun in that when consumers happily pay twice as much? There's no question you can make decent cars under 10K$. There are lots of those on the market in China. Most of them are pure electric of course because they are good enough, super simple to build, and inherently cheaper to make than anything hybrid. If you are competing on price, cutting cost like that is what you do.

Fiat 500 and Mini Cooper are certainly not tiny. I mean the originals from the 70's yeah but the new ones are huge and bloated in comparison.

Anyway such tiny vehicles do exist in Europe and Asia. The Citroën Ami (the new EV one) comes to mind in Europe, where it's had some success, but is still kinda expensive for what it is.

Those cars already exist, look at all the cars produced for the Indian market.

Considering Windows and then iOS were smashing surprise success stories, vehicles defined by software probably is barking up the right tree.

The problem is whether the barking is effective.

No, people actually want feature-rich vehicles. Pretty much nobody outside of corporate actors is buying "bare" cars.

And software doesn't actually cost that much. Just look at the Chinese market.

I don't think that's necesairily true for HN people?

I regularly get mind-blown by the number of anti-features of modern cars v.s. my 32 y/o Camry.

Some that come to mind: no physical buttons, no right/possibility to repair the car yourself, can't replace the car stereo by something else, extremely slow unusable navigation systems even in 2024 models (I just use my smartphone and put it where the screen would be in a modern car), beeping when not wearing seatbelt even at 5 km/hr on a parking lot, data plans/simcards to enable car spyware, extremely expensive tires with (broken) pressure sensors in them, headlights made of plastic instead of glass that get ugly after a couple of years, use of rusting materials instead of aluminum for body, active suspension systems that are extremely expensive to service, tons of unnecessary electronics that will break as the car gets slightly older and extremely expensive to service. I could go on and on.

The first time I drove some new-ish Toyota that displayed a tap-to-dismiss advertisement for the navigation subscription every single time you started it up, I knew I would never own one of these smartphones on wheels.

> no physical buttons

New cars are reintroducing physical buttons again.

> no right/possibility to repair the car yourself

Unless you're talking about electric vehicles, this isn't true. You can buy diagnostic equipment and do the repairs yourself on most modern cars.

> can't replace the car stereo by something else

Huh?

> extremely slow unusable navigation systems even in 2024 models

That's why you don't buy a car without Apple CarPlay or Android Auto. It's especially good on newer vehicles as there are integrations with the dashboard and HUD too.

> beeping when not wearing seatbelt even at 5 km/hr on a parking lot

This is because of government regulation.

> data plans/simcards to enable car spyware

You're not obligated to buy them. I don't think their software package is good enough to warrant such a purchase, but if they would be able to bring it up to what aftermarket guys are offering it would be a great addition.

> extremely expensive tires with (broken) pressure sensors in them

Huh?

> headlights made of plastic instead of glass that get ugly after a couple of years

You can restore them fairly easily. It's funny you ignore that the same issue happened to old cars too, on top of the fact their headlights were horrible to begin with.

> use of rusting materials instead of aluminum for body

This is partly because of regulation and partly because of cost-cutting.

> active suspension systems that are extremely expensive to service

Buy an expensive high-performance vehicle and it'll be costly to service.

> tons of unnecessary electronics that will break as the car gets slightly older and extremely expensive to service

The regulatory environment has changed significantly. Without these sensors you'd have a very inefficient or very slow car. Furthermore, the vast majority of these sensors you can change yourself.

I am mostly concerned by the ongoing maintenance cost of software. Cars live 20,30 years - how to keep the software running and in good condition? Foss is no solution, especially due to regulations (totally warranted, I want your car to have working braking systems...) and that this also involves systems at the producers.

Software is only subject to entropy when you touch it. In most practical cases these days not being able to "improve" the software is a feature, not a bug.

Safety critical software is in a totally different league of development process to say, the infotainment system. The thing is we are basically at the point where infotainment systems should be on the way out - because the correct solution is basically "interface with the consumers phone".

But any vehicle with software running which controls the brakes is either correct or unsafe when it ships - but you would never need regular maintenance updates to it.

Safety Critical Components (ECM, ABS, etc) need to be certified. This is very expensive and modifications are done very infrequently. I doubt that auto-manufacturers will use Embedded Linux for them.

Yes, but what's about the components controlling speed, e.g. by detecting the speed limit from some map? Or the stuff implementing emergency calls? Also there is a plethora of features I (charging station maps) which probably need all maintenance, too.

I don't believe this at all. I followed the Maverick for a while when it came out, not for me, but interesting strategy.

The vast majority wanted the baseline, barebones. However, Ford produced the least of these, and gave people 1 year lag times.

Most people who bought higher models did so begrudgingly. Yet Ford will claim higher sales on these upper models, so obviously "what the consumer wanted."

Sure, nobody buys bare cars. But you can't buy them when nobody sells them.

Selling them through fleet programs only doesn't really count.

I recently purchased an 1981 Vanagon, and it's made me happier than any car I purchased new. It's not without a computer... it does have electronic fuel injection, but I think that's mostly a lookup table of pulse length given airflow and temperature. There's an aftermarket replacement if it goes bad (but let's hope it doesn't).

What people want is to not drive at all. People detest driving, they're just not able to see any alternative. If people really wanted feature rich vehicles then they'd relish traffic jams as they'd get to spend more time in their car. But instead it's torturous and drives people insane.

Dacias are popular where I am and they are pretty simple. Cheap, light, durable and with the main extras (AC, backup/multiple cams and Android Auto/Carplay). People want feature- rich cars in the sense that everyone would 1:1 trade their Sandero for a W223 and they probably won't watch YT videos of Sanderos much but price/performance is a large factor.

imnsho it's a shiny misnomer for software dependent vehicle. cars today need software as much as they need a drive train and wheels.

Out of context, I rembember someone creating cloud architecture (kubernetes etc) to emulate 8-bit NES/Atari, or something like that. It was really funny... Especially because CPU ticks were requests

Someone needs to make an x86 version of it and then run Kubernetes on it.

I've found it! https://blog.davetcode.co.uk/post/21st-century-emulator/

> In 1974 when the 8080 was released it achieved a staggering 2MHz. Our new modern, containerised, cloud first design doesn’t quite achieve that in it’s initial iteration. As can be seen from the screenshot above, space invaders as deployed onto an AKS cluster runs at ~1KHz which gives us ample time for debugging

I wonder how much does it cost to run a space invaders game on AWS

Soon kubernetes will be running on a Toyota Prius near you

F-16 aircraft is doing it already: https://thenewstack.io/how-the-u-s-air-force-deployed-kubern...

The moment where I had to scroll up to see if this was posted on 1st of April.

We're already doing that: https://www.redhat.com/en/blog/running-containers-cars

That's just Podman.

Honestly you might be surprised how similar to a small homelab a modern/near future day vehicle really is.

Source: currently working at VWAG.

What's a small homelab?

The start of a bigger and more expensive homelab.

Ain't it the truth

a small tcp/IP ethernet network with some microcontroller devices which are attached with a simpler serial bus like usb.

Yipp. It's obviously cool to swap out a 5GB pod to get three more vehicle signals...

Kollege, I can't agree with that. I feel you are talking about middle to far future :)

the id.X series host a number of arm based embedded Linux servers on hypervisors, from the get go (id.3)

so one of us has a temporal anomaly going on

I went through the list of open source licences in my VW ID and was pleasantly surprised that bash-completion is included. So when I gain shell in my car, I should be able to use tab completion! These lists are often quite interesting.

When does market competitors collaborating on FOSS become anti-competitive, collusion, etc.?

If Apple and Google collaborated on a FOSS smartphone OS that both used, that would seem obviously illegal. What if the collaborated on the kernel only? What about the screen UI only? In a way that seems worse, but engineering-wise it's less significant than the kernel. A security subsystem? Some drivers? Keyboards?

I'm not sure how that applies to these automakers. While none of Apple's or Google's market power, as far as I know, and while an OS is less significant to a car than it is to a smartphone, possibly, I'd be surprised if they all can ship cars with the same OS. Where and how is the line drawn?

Would it? Especially as it's FOSS - rising ship raises all tides and all that.

If it was behind closed doors, then yes.

(Usual IANAL a lawyer disclaimer, and I don't mean my comment to shoot yours down - think there is merit in further discussion here!)

> Especially as it's FOSS - rising ship raises all tides and all that.

That's anti-competitive, at least in many ways. I doubt Ford could freely give GM some highly profitable technology to help GM's profits; Ford should maximize its advantage. OTOH, there are industry standards - but those could be defined by performance or they could possibly be for (non-competitive?) aspects like safety.

It's anti-anti-competitive, they aren't only giving it to GM.

Similarly Volvo giving away seat belt designs was not anti-competitive and neither would this.

Given the results are given to all and open to changes from all - I'm not sure how this is anti-competitive?

Do you mean a scenario where-by it's tuned to run on only hardware that is controlled by the vested parties, effectively locking out other players on the hardware level, while strengthening the desirability of said hardware by leveraging a greater number of software engineers under a somewhat false premise?

Competitors collaboratively building industry standard tools in the open and sharing them freely with all marketplace participants new or existing is the opposite of anti competitive collusion where established market players collaborate to prevent new market entrants.

If it would allow other manufacturers to use the software in their own vehicles, meaning truly open source, it's the opposite of anticompetitive behavior.

I could see some of the newer, much smaller electric vehicle manufacturers taking advantage of the software.

I think both Microsoft and Redhat can contribute to Linux kernel without it becoming an issue of unfair competition.

> If Apple and Google collaborated on a FOSS smartphone OS that both used, that would seem obviously illegal.

Not sure why this would be “obviously” illegal. For example - Intel, IBM, Compaq, Microsoft and others collaborated to design the USB port standard. It’s an open standard, any of their competitors is free to use it.

Well, kinda, there are still fees for things like the right to use the various USB logos and of course to allocate a vendor ID [1] ($3,500 for two years, and $6,000 respectively).

[1]: https://www.usb.org/getting-vendor-id

the problem never is doing things together. the problem always is hampering markets, hampering others.

How do you envision to hamper third parties with FOSS?

and do you mean FOSS, as in copyleft? or OSS as in OSI compliant?

With either, how do you think you can block third parties?

> the problem never is doing things together. the problem always is hampering markets, hampering others.

As far as I know, market participants, especially large ones, must compete; they can't choose not to compete. Otherwise they hurt consumers and economic growth, and can create a barrier for new market entrants.

help me understand how technical cooperation hurts customers and economic growth, exactly? I don't see it.

to the contrary. reality (e.g. Linux, android) also indicates competition, cooperation of competitors, is helping customers and grows economy.

Translation: We have a new caste of operating system user. First there were regular users. Then there were mobile users. Now we have automobile users, which are similar to the second case, except due to driving are even more defenseless against advertisements with malware payloads, captive popup dialogs, and drop down lists you don't want that take up 30% of the display.

Is this like the Linux nvidia driver package? Totally open source, except for the interesting parts?

The AGL distribution is more like an SDK, as it's a fork of Yocto embedded Linux which focusses on building/cross-compiling to a specified target architecture and creating the firmware images.

I guess the difference of AGL is that they implemented kernel mods so that they can guarantee ASIL-A/B/C/D spec compliant behavior which was the deal breaker when vendors were considering an RT Linux kernel over e.g. QNX (which focusses heavily on ISO 26262 compliance).

I am quite familiar with yocto, I did not realize that it was the toolchain used. Thank you for the information.

I should write a blog about yocto sometime, I have many thoughts.

Reply on news.ycombinator.com