Markaos @ Markaos @discuss.tchncs.de

Posts

0

Comments

53

Joined

8 mo. ago

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

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

I don't think overheating would cause random corruptions (it should throttle down when overheating, and then shut down if the temperature gets too high even when throttled, but there should never be an incorrect result of any computation), and surely the RAM will run at the standard 2133 speed on default settings - OP says they reset the BIOS settings to default between CPU swaps.

A simple rm -rf says hello

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.

Google Maps is US-based whether you use it in the US or anywhere else

Sure, but I don't see how any of that disproves the current "M$ supremacy" for "normies" - the fact is that people who couldn't care less about how their computers work will have a much easier time using Windows (and probably macOS) than any Linux distro. You don't have to worry that some software won't be available to you because of your choice of the OS, and if you ever have a problem it's easy to find help.

I haven't used Windows in a decade on my personal computers, but as long as these two things hold true, it will always be my recommended OS for people who simply don't care - I'm not going to spend my time doing free IT support for everyone I know and then get blamed everytime something doesn't work.

Annoying warning keeps showing up at boot -> bring the PC to the nearest computer-literate person, and they'll fix it. Good luck doing the same if you use Linux.

Obviously you need some redundancy in case the script gets corrupted. 5000 repetitions seems reasonable for such a high quality work

Only true if you don't know what you're doing. The only reason any network is safe at all is NAT and Firewalls that come with it.

I don't have to worry about devices on a local network in as far as firewalls go, I can expose anything I want, in fact I delete iptables at first sight on any new distro install or VM, so long as none of it is port forwarded and everything is behind NAT it's all okay. My network is my castle. Thanks technology! Thanks smart people for figuring this out!

NAT is not a security mechanism. If you set up a NAT with an otherwise permissive firewall, your router will happily forward any incoming packets destined for RFC 1918 addresses inside, no questions asked. I use this for a "lab" network that I sometimes want accessible from the bigger LAN - the lab router doesn't have any rules for dropping incoming packets (only blocks some outgoing traffic), and all I have to do on the main router to get this working is to set a static route to the internal lab network through the lab router's "external" IP.

And yes, practically it's a security nightmare to have any IP of any computer accessible from the internet. If you go around configuring firewalls forever you might get it right but oh boy one mistake and you're done for. Instead, consider NAT, the solution to all problems. I'm writing this behind quadruple NAT rn and it's honestly fairly easy to manage, I've been too lazy to change it, not that I'd advise anything more than 1 necessarily.

accept established, related; drop incoming. That's all you need to get the same security as a NAT with a proper firewall. Outgoing connections will get marked and have return traffic allowed, everything incoming without related outgoing traffic gets dropped. Want to "port forward"? Add a rule that allows incoming traffic to a specific IP/port/protocol triplet. Done. Don't know how to make sure a client stays reachable on a specific address? Give it that specific IP address in addition to the one it autogenerates. This was always possible with IPv4, too, it's just that the tiny address space made it impractical to use.

How do you get the equivalent of NAT punchthrough (which is unreliable with many NAT implementations) when you want to do a VoIP call without having to bounce all the data through a central server? Simple, you can just tell both clients the other one's IP and port, have them spam each other for a tiny while with messages and eventually a message gets through both firewalls. It is very similar to NAT punchthrough, except you don't have to guess how the NATs work and it'll reliably connect.

Yikes! That's a lot to type to hammer in a nail that sticks out (Android). Thanks but no thanks. I'll find some way to cripple mDNS on the non-compliant device instead.

Not sure why you'd regularly need to type out the whole thing. Also not sure why you picked .local when .lan is also incorrectly used for this purpose and is shorter (and isn't yet assigned to any conflicting technology)

So are you saying you run some sort of mDNS server(not sure what the word would be there)/provider? Why? How?

The point of mDNS is that devices auto discover each other on a network without a central authority. The word multicast in multicast DNS is the key. And the reason I use it is because... it just works. There's no need to configure it, it works like this by default on pretty much every OS. Set the hostname and you're done, .local now works. You can even bridge it across networks with a mDNS repeater available on many routers.

Given the ambiguity of certificates everywhere, malicious devices on the local network posing as a different server are not an issue (and it's not like they couldn't hijack the IP address in any flat network anyway).

Well don't build your network around unassigned TLDs.

Also NAT does literally nothing other than being a massive PITA, so... yeah, I don't think there's much I can agree with in your rant.

Like, oh no, fully functional point to point connectivity across the internet, how terrible

Edit: .home.arpa is actually designated as local TLD, and is what I use for a crappy old tablet that doesn't support mDNS

As far as I know, bootloader locks are done by the manufaturer not by the provider.

Verizon requires the phones they sell to NOT have the ability to unlock the bootloader. That's why there are separate factory images for Verizon Pixels.

What do you mean "now"? Google Photos has had a photo editing feature for a very long time now