I’d go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.

It’s a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.

The quote above covered exactly what you just said: “yet were also more likely to rate their insecure answers as secure compared to those in our control group” at work :-)

To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.

IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.

I am looking forward to follow up articles like “woodworking as a career isent right for me”, “bookkeeping as a career isent right for me” and the really enlightening “any job sucks when your boss is shit”.

The problem is that you lose out on dev attention when moving away from github.

I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).

If you want your project to be visible, it needs to be on github at this point in time:-(

The basics are all the same:. memory, cpus and caches in between ;-)

But rust does approach many things very differently from C or C++. Learning those new approaches takes time and practice.

Watch out: That mindset is what got me into Rust in the first place!

I was so fed up with everybody drowning on about Rust that I thought I need to read up on it a bit so that I can argue against the hype. I am a seasoned C++ dev after all, I use a language that I picked because it allowed for robust and fast code. What could Rust add on top of that?

Well, I have a job working almost exclusively with rust now and do not plan to ever go back.

https://docs.rs/document-features/latest/document_features/ helps to document features.

But yes, features are under-documented.

I did tick that, since I saw text boxes and went “give me everything” without reading:-)

Fixed. Thank you for pointing this out.

Slint fits the bill: We have a demo running on a line-buffer in a microcontroller with <300KiB of RAM. Framebuffers are of course supported as well, as is GPU-accelerated rendering.

What is actually meassured there? “Line goes down” is not necessary a bad thing:-)

What do you mean by “system support”? The system is mostly pushing bytes along, the programming languages/UI ovaries tend to do all the hard work. So it is usually more interesting to see what those support.