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.

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

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

Unfortunately not a citizen though!

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.

In fact all ones is not hard either, there were some experiments to give RAM ability to perform simple page-level computations with promising results.

I also wonder, for typical workloads, what percent of CPU time is spent zeroing pages.

The amount of time wasted zeroing out memory pages in a typical OS is quite significant, also take into account that such an operation will trash perfectly good cache space for no good reason.

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

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

It's really easy to ship commercial Qt app with LGPL3 (except few modules that are GPL3) You just provide sources or linkable object files.

Qt intentionally avoids explaining how to do this because they are selling commercial licenses. If you are in software business and can't figure this out, maybe you should consult someone.

(disclosure: I own commercial Qt license and stock in the company)

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.

I think I'm allowed for the tone when you respond with the following:

>You are forced to help customers replace the Qt libraries in your product. That has quite large security/warranty implications.

The above is completely wrong.

You develop and distribute your closed source software and link it with QT libraries like you would do normally. Nothing is needed from the customers. Your closed source software can be statically linked to LGPL binaries (to fix another common misconception).

What is needed from you is a way for the customers to get things separately. It can be written offer, link to files in the website (used to be directory in DVD). You can be almost 100% certain that your customers will never use or notice this option. It's just there to comply with the license.

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.

Depends on what you mean by 'help'. You are forced to give the opportunity for them to do the work if they need it. If you have statically linked files, it can't be done by accident.

> Do you see any possible security problems with the above?

No I don't. When I provide completely closed binaries for my customers, they can hack with the binaries and create security problems if they want to.

Software security is not improved by obfuscation. If you don't want your customers create security problems, you don't allow them to modify the software in your hardware.

Btw. I'm confused by your wording. I'm suspecting that you have some underlying assumptions you are not stating. Are you thinking that LGPL forces you to allow customers to modify the software in the hardware they are buying?

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.

> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

- If you ship embedded product where the code is not supposed to be easily upgraded, you don't have to provide means to do that. Anti-Tivoization applies to cases like TiVo where they added DRM to prevent users from upgrading but allowing you to upgrade.

- Also, anti-Tivziation clauses don't apply software distributed to business. Medical devices or safety critical software etc. Any devices sold to business.

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...

How do you do that, while said software depends on LGPL3 licensed Qt?

> But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

Also, anti-tivoizaton clauses does not apply to devices sold to business.

From what I see, only a tiny part of the potential market for embedded Qt and things like that can get away with "no updates possible", but still, applies for some.

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

They are pretty cheap considering the typical prices on their target markets, embedded tooling, medical devices, enterprise solutions.

Naturally they decided to pivot to those markets, as Trolltech has hardly seen any significant monetary profit from FOSS.

So it is only fair that those that don't want to pay, also ship code free to the others.

Then Nokia bought it and made it LGPL because they were planning on using it as the foundation for (some of) their mobile phones. Unfortunately, they couldn't decide which phones and went on a downwards slide.

Then Microsoft bought most of Nokia, and Qt got spun off into an enterprise thingy that takes their sales tactics from Oracle. Yes, I know the LGPL allows me to link dynamically for free, no, I don't trust Digia not to sue me for that.

Their pricing is also out of reach of anyone who's not in an industry that charges an arm and a leg due to regulation or niche.

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.

The trend is already visible with SaaS, Cloud, IoT,...

Qt is certainly certified for medical use, https://www.qt.io/qt-in-medical/.

I have hardly seen any big Android Auto adoption.

The biggest foe of Qt in Automotive is Web stack.

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.

Which is exactly my point.

Give the tip of the iceberg for free, charge for everything else and give as little back to upstream, if anything.