Yes, you can’t install F-Droid

TL;DR: the minimum went from 16 to 32 GB

Node.js is a web server. It doesn’t run in a browser, therefore doesn’t deal with the browser sandbox. That should answer your first dig.

For the second part, WebRTC is a standard that allows two WebRTC peers to communicate. You can’t use WebRTC to open an arbitrary TCP or UDP stream to for example a database, unless said database decides to implement a WebRTC peer support.

If you’re unfamiliar with all of this, that’s your job to get educated. This is how browser-based JS software works.

The browser version cannot connect to Postgres without a server-side part, for rather obvious reasons - you can’t just make arbitrary network connections from the browser. Electron build is of course different, as that doesn’t have to deal with the browser sandbox.

By the way, here’s a similar issue documented in Outerbase’s repo:

Outerbase Studio Desktop is a lightweight Electron wrapper for the Outerbase Studio web version. It enables support for drivers that aren’t feasible in a browser environment, such as MySQL and PostgreSQL.

Not gonna lie, telling people how they need to get educated on stuff you don’t understand ticks me off.

xfwm is XFCE’s window manager, and it’s eating almost 30% of the total system memory, so that’s the prime suspect (I’m not exactly sure how much it interacts with other apps, so it’s possible something else is forcing xfwm to use all that memory, but that is IMHO unlikely).

An ugly “fix” is to log out and log back in (yes, not much better than just rebooting), or you could try to somehow restart xfwm - running xfvm --replace in terminal might work.

Edit: there’s an issue on the Manjaro forums that might be related: https://forum.manjaro.org/t/xfwm4-memory-leak-since-4-20/173910/7

Potentially the same thing, assuming PCIe 2 x1 provides enough bandwidth.

Nobody’s saying that Google won’t give them the code, though. Nothing is moving to closed source, Google just isn’t going to be showing the current work-in-progress code for the next release to the public.

How so? I doubt many ROMs are based on code that isn’t part of an Android release. Surely GrapheneOS devs can just use the Android 16 branch once it’s released to make an Android 16 version of GrapheneOS.

Not in the CPU/modem department, that’s a first

Nah, the kernel isn’t that important for apps - you can replace the kernel and update the massive Android framework to work with the new one relatively easily (you will need some Linux compatibility for native code that does syscalls on its own, but that’s pretty much it - even WSL1 could do that).

It’s all the APIs and system apps provided by Google that have no reasonable alternative in AOSP that are the problem for compatibility. Look how incomplete projects like MicroG (an open-source implementation of Google Play Services) are, and their only goal is to provide Android compatibility for unofficial ROMs without installing the proper Google services.

Idk, seems like it’s sticking out of the back and isn’t symmetrical like the camera bar, so it might wobble or lay uneven on a table. That’s way more obnoxious to me.