Yes, you can't install F-Droid
Markaos
TL;DR: the minimum went from 16 to 32 GB
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.
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.
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
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.
Because, at least to some people, open source is more about user freedom (to modify the software and share the modifications with anyone they wish) and less about collaboration.
For example every time I publish some simple utility that I wrote for myself and decided could be useful for other people, I release it under a reasonable open source license and pretty much forget about it - I'm not going to be accepting merge requests, I don't have time to maintain random tiny projects. If I ever need to use the utility for something it doesn't quite do, I'll check if any of the forks seem to have implemented it. If not, I'll just implement it in my repo.
The reason I'm publishing the code is because I know how much it sucks when you find some proprietary freeware utility that almost does what you need, but you can't fix it for your usecase on account of it being proprietary for no reason (well, author's choice is the reason, and I respect it, but it's still annoying)