At my company, we have not seen any performance benefits from LTO on a GCC cross-compiled Qt application.

GCC version: 11.3 target: Cortex-A9 Qt version: 5.15

I think we tested single core and quad core, also possibly a newer GCC version, but I'm not sure. Just wanted to add my two cents.

I would expect a little benefit from devirt (but maybe in-TU optimizations are getting that already?), but if a program is pessimized enough, LTO's improvements won't be measurable.

And programs full of pointer-chasing are quite pessimized; highly-OO code is a common example, which includes almost all GUIs, even in C++.

Do you link against a version of the Qt library that provides IR objects?

In any case even with whole program optimization, O would expect that effectively devirtualizing an heavily object oriented application to be very hard.

it's right there in the first section:

   highlighting notable advancements in ARM-based Systems-on-Chip (SoCs) and their increasing competitiveness against traditional x86 platforms.

Not discussing x86 doesn't highlight their competitiveness. It might be a useful article for some, but for most of us the N100 is a better option overall for everything we might look at a SoC for. YMMV of course, I haven't seen a N100 SoC (I've also never looked), but complete N100 systems that are ready to work are similar prices to an ARM SoC after you buy the non-optional extras like case, disk, and power supply.

It also misses the other end - many things people think of SoC for could be done with a ESP32 or other micro controller for less cost, and this might be a better option.

I'm not completely faulting them, you have to set limits someplace. However the limits they have make this summary less useful for most people who will read it.

Recently there was an exhibition of tree root illustrations by Jitka Klimesova in Prague. I think there's potential for more art emerging from science.

My takeaway from the article is that Itanium could have been the equivalent of Apple's switch to M1 if Intel doubled down instead of panicking.

Yocto doesn't run GUI applications, it's a framework to make your own distro. The fact that many users are too lazy to create a user to run their application as, speaks of the embedded space in general rather than Yocto in particular.

> I'd suggest just looking at another distribution

You won't find one. With many vendors, it's the only option.

This topic is beaten to death in Philosophy of Software Design - I really, really do recommend it.

> This map describes kernel security hardening. It doesn't cover cutting attack surface.

For those wondering why SECCOMP is ommited.

The age of last commit on trunk is a useless metric in isolation. The fact that it is the most prominent number on the front page of a repository is a shame.

A metric I think is useful is responsiveness to issues. If there haven't been any recent commits and if I open the issue tracker and the maintainer hasn't even acknowledged issues that have been opened in the last 6 months, then I assume the project is no longer maintained.

I would love to see a metric of the number (or proportion) of issues closed even though users are trying to get assistance. No idea how to make that machine-calculable though.

Even better, a metric for refused PRs (maybe including PR size somehow), tracking where users cared enough to try to contribute and the owner just refused to accept the changes. Easily gamed though.

Sounds like CTU FEE in Prague. I learned a bunch about registers, branch prediction and cache, but most of the assembly went out of my head once the class was over.

Agreed. That being said, the CVSS calculator is useful for reminding you of factors that you may not have included in your analysis.