But ChatGPT doesn’t have a way of “knowing” that there is no such Flatpak - it’s unlikely that its training data includes someone explicitly saying that. But it’s fair to “assume” that a Linux file manager is available as a Flatpak.

(…), so it’s definitely making up stuff.

Yes, it’s an LLM

Honestly, this is not really technobabble. If you imagine a user with a poor grasp of namespaces following a few different poorly written guides, then this question seems plausible and makes sense.

The situation would be something like this: the user wants to look at the container’s “root” filesystem (maybe they even want to change files in the container by mounting the image and navigating there with a file manager, not realizing that this won’t work). So they follow a guide to mount a container image into the current namespace, and successfully mount the image.

For the file explorer, they use pcmanfm, and for some reason decided to install it through Flatpak - maybe they use an immutable distro (containers on Steam Deck?). They gave it full filesystem access (with user privileges, of course), because that makes sense for a file explorer. But they started it before mounting the container image, so it won’t see new mounts created after it was started.

So now they have the container image mounted, have successfully navigated to the directory into which they mounted it, and pcmanfm shows an empty folder. Add a slight confusion about the purpose of xdg-open (it does sound like something that opens files, right?), and you get the question you made up.

Virtual memory isn’t swap, it is a mechanism that allows the operating system to give processes a view of memory that is almost completely decoupled from real physical memory and other processes. For example some programs require their code and data to be placed at exact memory locations in order to work - virtual memory allows you to run as many of these programs as you wish, because one process’s address 0x1000 has nothing to do with another one’s 0x1000, unless they set it up as shared memory (but even the same chunk of shared memory might be mapped to different addresses in the processes that share it).

Swapping is a cool trick that you can do with virtual memory, though. Basically you store a piece of memory somewhere outside the physical memory, and then make the address invalid in virtual memory. When the process tries to access it, it will crash. The OS will be notified of the crash, see that it was due to the process trying to access swapped out memory, load the chunk back from disk (maybe to a different physical location), update the virtual memory to correctly point to this chunk, and restart the crashed process from the instruction that caused the crash. So from the point of view of the process, nothing went wrong at all, except that one instruction took a very long time to execute.

Also, isn’t it harmful to SSDs?

Swapping doesn’t do enough writes to matter, unless your system is running really low on RAM.

All right, I had some spare time today, so I went and installed this thing.

My setup is a bit more complex than the minimum necessary, but that’s because I’m using an already existing Postgres database instead of installing a new one on my computer. It is as follows: Postgres running on a mini PC on my local network (192.168.2.199:5432), a browser running on my main computer, and a Debian VM for DBgate with two NICs - one is the default NAT interface (I’m too lazy to configure proper bridging / routing) and the second is a virtual bridge, testbr. On testbr, the host OS is 192.168.123.1/24, and the guest is 192.168.123.2/24.

I installed DBgate on the VM using NPM - npm install -g dbgate-serve, as specified in the documentation. Then I ran it using simply dbgate-serve, then connected to it from a browser running on my host OS as http://192.168.123.2:3000/. That works fine.

Then I added my Postgres DB through the web interface (to be verbose, I entered 192.168.2.199 as the IP address), created a table and inserted some dummy data. Then I wanted to do the next step, which is to block outgoing connections to port 5432 from the VM, but I noticed something very strange, given that DBgate obviously doesn’t use the server as a backend to do the actual DB connection: this was in the server log

{"pid":7012,"caller":"databaseConnections","conid":"24d95082-ca6a-4dac-aa28-f3121bfc508d","database":"dbgate","sql":"INSERT INTO \"public\".\"dbgate_test\" (\"text\") VALUES ('haha');\nINSERT INTO \"public\".\"dbgate_test\" (\"text\") VALUES ('hehe');\n","level":30,"msg":"Processing script","time":1744395411096}

But it would be ridiculous to even suggest that the connection is relayed through the server, so it is probably some kind of telemetry. Makes sense.

Anyway, I went ahead and added the rules on the VM nft add table ip filter, nft 'add chain ip filter output { type filter hook output priority 0; tcp dport 5432 drop; }', and you wouldn’t believe what happened next… The DBgate tab can no longer load data from the database. I can reload DBgate itself without any issues, and I can connect to the database from the same computer using psql and DataGrip just fine, but for some reason it seems to be affected by the fact that its server (which is only serving the HTML/JS files and doing nothing else, as you said) cannot connect to Postgres.

Weird how that works, huh?

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

That was my deleted comment, but then I realized the article specifies they are Rome CPUs (Zen 2), while the 4000 series of EPYCs is based on Zen 4

deleted by creator

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

The thing that’s going to be locked behind the subscription is your ability to watch those files on your NAS through Plex when you’re not in the same network as the Plex server. That’s streaming.

If you only use Plex while at home, you will indeed be unaffected