kristoffer

I have three children aged 15-17. My youngest one has shown an interest in becoming an electrician, and I encourage that as I think it is pretty AI safe and in high demand.

My two older and more theoretically oriented children I am not sure what to recommend so I let them find something they are interested in mostly on their own.

Well, the backend is native at least.

Yes, certainly. I will add that very soon.

It is also possible to download and try yourself without paying (there is a free trial period).

I have been building an agentic code IDE (like everybody else :)).

https://syntverk.com

Native cross platform app coded in rust + tauri.

I prefer using it to the other agentic code apps I have used. It has multi tab worktree isolated agents, sandboxed tools, git integration, built in code editor (with inline generation), searchable document support (i.e. upload your docs, datasheet and you or the agent can use them) and even built in local image generation (using stable diffusion and flux schnell) and asset handling for game developers. Oh it also has a remote feature so you can share the gui or deploy it on a server and access it on the go.

Working on adding text to 3d also.

It is a hobby project that has grown quite large. Feel free to try it out.

No. Poverty has significantly declined during the 20th century ..

"Torvalds wrote the original code for printk, a debugging tool that can pinpoint exact moments where a process crashes"

A debugging tool? I do like printk debugging but I am not sure about that description :-)

It is not related to OpenSparc. LEON is a SPARCv8 developed initially by ESA and later by swedish company Gaisler Research.

Automotive Grade Linux is pretty much a Linux distribution for infotainment units. It's not about running Linux on ECUs.

Well the creator of Snabb lives in Sweden.

I have read this post many times and just want to say that I really like it :-). Sounds like great fun.

Unfortunately not a citizen though!

You can only address one row/column at a time in a normal DDR memory. Start by reading this if you want to learn more: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

In the end memory design is limited by the laws of physics.

Well, on e.g. x86 you have "rep stos" instruction which pretty much amounts to memset in HW.

The operation needs to be blocking otherwise you could of course do it without CPU at all (DMA). But you still have to go through the memory controller and actually write each word of memory.

I am yet to see a embedded system using Qt that is not upgradeable.

And lots of embedded systems are sold to consumers.

In what way was I "completely wrong"? It seems to me you were the one who was wrong and now are grasping at straws...

I think I'm clearly stating my assumptions. GPL3 and LGPL3 requires you to enable the user to replace the GPL/LGPL3 code on your device with the users own version of said code. It does not matter if you link statically.

Now, it would be possible let the user do this and not let it be a problem for your product (in terms of security, reverse engineering, ip theft, etc) but it is more and harder work.

I have used both older version of Qt (LGPL2) without licensing and newer (LGPL3) with licensing in commercial products. The former was not a problem. But using LGPL3 Qt without licensing in a commercial embedded product is a headache (if you are concerned about the problems it might bring), according to me.

Hence, I wish Flutter all the best.

You don't agree that you need to provide a way for your customers to replace the Qt libraries? (because that is a fact of LGPL3, read the anti tivoization clause).

Do you see any possible security problems with the above?

Because in reality it means that you give your customers the possibility to run their own code on your hardware. That is a problem for many companies and products.

No need for the tone.

That is really easy as you say. What you seem to have overlooked are the implications of doing this. You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications.

So ... no thanks!

I do contract work for a company licensing Qt5. I'm hoping for Flutter or something else to kill Qt in the long run.

Your last sentence is a bit hard to comprehend but not paying for Qt and shipping a commercial embedded product is pretty difficult due to the anti-tivoization clauses of GPL3.

I agree with parent poster that flutter is very interesting for Embedded GUI development.

Ok I'll admit I'm not familiar with medical certification. I know that the so called Qt Safe Renderer for ISO26262 compliance is a bit of a joke at least.

I have seen two very big Qt projects being cancelled due to Android. Not the Android Auto app but native Android for IVI.

I don't see any indication of your vision for shareware. The trend is towards more and more software being licensed under licenses such as MIT.

Most embedded tooling is free nowadays. Free software has eaten the world and will continue to do so.

I will use a free UI toolkit when I can. Qt will kill itself with their current pricing model.

Automotive is moving towards Android. Qt is not good for medical either because it is not really certifiable.

Reasonable? It's about $500 / month / developer with additional royalties if you are shipping devices with Qt firmware. Sure I think Qt/QML is the best UI toolkit available but this crazy pricing is driving me towards any possible alternative. So I'm really hoping Flutter will take off (for desktop/embedded as well, not only mobile).

Note that Qt is GPL3 nowadays so you can't really ship embedded devices with Qt without paying.

I don't know why they disabled ASLR, but safety critical systems (and functional safety people) tend avoid randomization...

If cell providers advertises their services as "Always 100 Mbps guaranteed" that would be a problem, but do they really?

Because that is not how wireless communication works. E.g. in LTE the user is scheduled both in frequency and time. The operator has a certain frequency spectrum that gives a certain maximum transmission rate (one user getting all frequencies and time).

The scheduling happens based on (amongst other things) signal to noise ratio and priority of each user and their traffic types (voice, data, etc). The goal of the operator is to maximize the overall capacity of the network. This is beneficial for the user as well.

I think the problem in the US is the lack of competition. Not net neutrality issues. In places where this works well you just change operator if you are not happy with your current one. This way the provider is free to experiment with how to run their network and everyone benefits.

Sure, I agree that you should limit ASIL certified software as much as possible. Nothing running on Linux will be certified ever.

That also limits the benefits of Qt Safe Renderer. I think it is mostly a marketing thing within the automotive sector. The competitors there (Disti, Kanzi, etc) have their "solutions" for safety critical and say Qt can't handle it. So Qt needs to check the box of "safety critical" to fend for themselves.

Tell tales can quite simply be implemented by hand coding. But there is OpenGL SC which possibly could support more fancy and certified graphics. It could be nice if Qt/QtCreator/Qt3dStudio supported that in some manner. Having a layer that is safety critical and separated out to it's own OpenGL SC code. The usual argument for this kind of stuff is that nice graphical ADAS features (think advances HUDs) will need this (although I think it is still reasonable to hand code it in OpenGL SC).

This does not really mean Qt (and/or QML) is certified. It means there is support in QtCreator for exporting certain graphics (tell tales) so that they can be rendered by Qt Safe Renderer and if that happens on a certified RTOS the system could be certified.

So the Qt libraries or QML renderer are still not certifiable.

You’re confusing film and video.

Anyway (D)SLR use phase detect autofocus in which you don’t have to figure out much at all.

Mirrorless is another thing.

Note: Silicon validation engineer.

They probably use Linux as extra validation for their chips.

The author writes a long text about how this is "not as easy for an autonomous system to solve" just to make the obvious point at the end of the article.

It should be obvious to anyone that you need to compose systems of different criticality to build a safe autonomous vehicle.

Of course the "AI" system needs to be complemented with a safety critical auto brake and other fail safes.

Getting down to around 6 MB on modern ARM kernel + minimal userspace is doable at least.

What are the views on ISO 26262 functional safety compliance in the US self driving companies? This report is very light on details and only mentions ISO 26262 in the passing.

Here in Europe it seems to me that functional safety is high on the self driving agenda ... (maybe too high?)