QT is a cross platform UI development framework, its goal is to look native to the platform it operates on. This video by a linux maintainer from 2014 explains its benefits over GTK, its a fun video and I don't think the issues have really changed.

Most GTK advocates will argue QT is developed by Trolltech and isn't GPL licensed so could go closed source! This argument seems to ignore open source projects use the Open Source releases of QT and if Trolltech did close source then the last open source would be maintained (much like GTK).

Personally I would avoid Flutter on the grounds its a Google owned library and Google have the attention span of a toddler.

Not helping that assessment is Google let go of the Fuschia team (which Flutter was being developed for) and seems to have let go a lot of Flutter developers.

Personally I hate web frontends as local applications. They integrate poorly on the desktop and often the JS engine has weird memory leaks

I know a couple game devs and absolutely blasted them for that take.

We have had quite a few indy devs make the point that the "Linux" bugs are generally cross platform issues and Linux users are more likely to raise a bug report and tend to raise more useful bug reports.

Which means avoiding Linux due to higher bug reports is just hiding from technical debt.

SpaceX are on track to launch 130 times this year. The industry competitors launch 6-12 times per year.

I suspect the higher incident rate is related, since you will need to manufacture, roll out, etc.. much more often.

The article also talks about most the incidents being in booster recovery. Only 2 Space competitors do that,

Blue Origins sub orbital booster always returned to launch site and at best managed monthly launch. This rocket hasn't launched in more than a year.

Rocket Lab perform ocean recovery but only launched 11 times last year and only recovered the booster twice.

So its hard to really compare

Debian would be a Volvo Estate, its the boring practical family choice, the owner is soneone boring like an architect or a financial advisor.

Arch is a Vauxhall Nova, second hand battered owned almost exclusively by teenage lads who spend a lot of time/money modifying it (e.g. lowering so it can't go over speed bumps, adding a massive exhaust to sound good but destroys engine power).

Fedora is something slightly larger/more expensive like a Ford Focus/VW Golf/Vauxhall Astra owned by slightly older lads. The owners spend their time adding lighting kits and the largest sound systems money can buy.

Slackware is clearly a Subaru Impreza, at one point the best World Rally Car but hasn't been a contender for a while. Almost all are owned by rally fans who spend fantastic amounts of time tinkering with the car to get set it up an ultimate rally car. None of the owners race cars.

OpenSuse is a Nissan Cube, its insanely practical. It should be the modern boring family choice, but it manages to ve too quirky for your architect while not practical enough for van drivers.

I don't know the other distros well enough.

I run Debian btw

Every programming languages has communities built around them.

Its becoming clear Rust solves a lot of C/C++ type problems and the embedded communities are definitely shifting over.

Apache is the primary community for Java, a quick look at their project list shows it's entirely web servers, data engineering and clustered projects for distributed computing.

Personally if you asked me to solve this problem I would use Spring Boot with various Spring libraries for talking to the caddy, user control, etc... Looking at the project, its exactly what they have done

I believe this post would be better if it was rewritten in Rust it would allow more efficent. memory usage compared to; the dynamically typed English language which doesn't have the borrower checker. while allows you to detect when resources are no longer used unlike English's poorly performing 'grammar checking' tools

But seriously there has to be content to engage with and people who respond to the content. I've noticed this community has someone posting really high quality updates but the community appears to be that person.

Posting blogs, or asking questions, etc.. would be a good way to engage.

MBin is a fork by a group who tried to push into KBin but couldn't. There seems to be at least 4 active committers and stuff gets merged.

You will see a number of the KBin instances moved over https://fedidb.org/software/mbin

The developer behind KBin seems to have issues delegating/accepting contributors.

If you look at the pull requests, most have been unreviewed for months and he tends to regularly push his branches once complete and just merge them in.

That behaviour drove the MBin fork, where 4-5 people were really keen to contribute but were frustrated.

To some extent that would be ok, its his project and if he doesn't want to encourage contributions that is his decision but...

KBin.social has gotten to the size where it really should have multiple admins (or a paid full time person). Which it doesn't have.

The developer has also told us he has gone through a divorce, moved into his own place, gotten a full time job and now had surgery.

Thats a lot for any normal person and he is going through that while trying to wear 2 hats (dev & ops) each of which would consume most of your free time.

Personally I moved to kbin.run which is run by one of the MBin devs

It does but for the 90's/00's a computer typically meant Windows.

The ops staff would all be 'Microsoft Certified Engineers', the project managers had heard of Microsoft FuD about open source and every graduate would have been taught programming via Visual Studio.

Then you have regulatory hurdles, for example in 2010 I was working on an 'embedded' platform on a first generation Intel Atom platform. Due to power constraints I suggested we use Linux. It worked brilliantly.

Government regulations required anti virus from an approved list and an OS that had been accredited by a specific body.

The only accredited OS's were Windows and the approved Anti Viruses only supported Windows. Which is how I got to spend 3 months learning how to cut XP embedded down to nothing.

Technical Leads are not rational beings and lots of software is developed from an emotional stand point.

Engineering is trade offs, every technical decision you make has a pro/con.

What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best meets it.

What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.

Currently the obvious tell is if they pitch Rust. I am not saying Rust is bad, but you'll notice they will extoll the memory safety or performance and forget about the actual requirements of the project.

Wine attempts to translate Windows calls into Linux, its developed by Codeweavers whose focus is/was application compatibility.

Valve took Wine and modify it to best support games, the result is called Proton. For example:

Someone built a library to convert DirectX 9-11 calls and turn them into Vulkan ones, it was written in C++ and is called DxVK.

Wine has strict rules on only C code and their directx library handles odd behaviour from old CAD applications.

Valve doesn't care about that, they care that the Wine DirectX library is slow and buggy and DxVK isn't. So they pull out Wines and use DxVK.

There are lots of smaller changes, these are 'Proton Fixes', sometimes Proton Fixes are passed on to Wine. Sometimes they can't but discussion happens and a Wine fix is developed.

Most of the updates are about long term support the performance gains are a side product.

This driver was one of the earliest open source drivers developed by AMD. The point of the driver is to convert OpenGL (instructions games give to draw 3D shapes) into the low level commands a graphics card uses.

A library (TMSC I think) was written to do this, however they found OpenGL commands often relied on the results of others and converting back to OpenGL was really CPU expensive.

So someone invented NIR, its an intermediate layer. You convert all OpenGL commands to NIR and it uses way less CPU to convert from NIR to GPU commands and back.

People in their spare time have been updating the old AMD drivers so they use the same libraries, interfaces, etc.. as the modern AMD drivers.

This update removes the last of the TMSC? usage so now the driver uses only NIR.

From a dev perspective everything now works the same way (less effort) from a user perspective those old cards get the performance bump NIR brought.