This is seriously cool. Although the current specs are a bit funny - if you take the largest possible disc size (360 TB), then it would take a million hours to fully write it at 10 MB/s (more if the storage unit is actually TiB). That’s over a hundred years.

Also if the goal is datacenter archival, then I wonder what the plan for practical use is - many individual discs with separate write “heads” (basically a RAID 0) to bring the speed up? And then maybe the maximum size per disc is a theoretical limit for the technology once we get faster access rather than something practical they intend to build anytime soon.

Charles university uses and develops something called ReCodex, and it is available on GitHub. As a student, it was very nice to use.

https://github.com/ReCodEx/wiki/wiki

Yes, the DE-specific implementations is pointless (as far as I know, I use a WM), but the XDG implementation is actually used first, and the function returns true if any impl returns true, like xdg() || gnome() || gnome_old() || kde().

True, I must’ve read the code wrong when making the comment.

This isn’t that bad?

Yes, which is why I take issue with a PR (or rather what should have been a PR) that introduces crap code with clearly visible low effort improvements - the submitter should’ve already done that so the project doesn’t unnecessarily gain technical debt by accepting the change.

With multiple impls, you have to resolve conflicts somehow.

Yep, that’s why I think it’s important for the implementations to actually differentiate between light and fail state - that’s the smallest change and allows you to keep the whole detection logic in the individual implementations. Combine that with XDG being the default/first one and you get something reasonable (in a world where the separate implementations are necessary). You do mention this, but I feel like the whole two paragraphs are just expanding on this idea.

But it’s better to criticize the code’s actual faults (…)

I made a mistake with the order in which the implementations are called, but I consider the rest of the comment to still stand and the criticisms to be valid.

Well, the detection is broken for KDE and backwards in the XDG implementation (which is also only used as a fallback when the three DE-specific implementations fail, even though all of them actually support XDG so having separate implementations is pointless).

Also with the way it’s implemented, it will have unexpected results for users who have both KDE and Gnome installed (or at least have leftover configuration files) - if you for example used KDE in the past with a theme considered to be “dark” by this and now use Gnome and have it set to light mode, you will get dark mode GZdoom with no obvious reason why.

Oh and the XDG implementation is also very fragile and will not work on everyone’s system because it depends on a specific terminal utility being installed. The proper way would be to use a DBus library and get the settings through that.

And when somebody comes to fix it, they will have to figure out a) what’s so special about the DE-specific implementations that XDG wasn’t enough (they might just assume that XDG isn’t supported widely enough), b) learn how to detect dark theme properly on the DE they’re fixing, c) rework the code so that there is a difference between “this DE wants light mode” and “couldn’t figure out of this DE is in light or dark mode” - both of these are now represented by the “false” return value.

I don’t think a well written and functioning code made with AI assistance would get a response this strong, but the problem here is that the code is objectively bad and its (co-)author kept doubling down about something they probably barely even checked.

Don’t know about the UK, but in central Europe it’s common for houses to get three phase power that can then be used on 400V three phase circuits and gets split (ideally evenly) into 240V circuits. And the fact that the phases have effectively zero coupling means that you also need to just try the adapter to find out if it’s going to work or not unless you happen to know how exactly your house is wired up, just like with split phase power.

Apartments usually get a single phase though, but IMHO it’s also less likely that WiFi won’t be enough there, so it’s questionable if that’s even a point for powerline.

Just to be clear, the applets were stuck while the laptop was plugged in? If so, then it might just be the threshold - connected, not charging, not discharging (because the laptop is running off the AC adapter).

For example on my IdeaPad laptop, when I enable the charge limiting feature it will get “stuck” at 59 or 60% while plugged in. It doesn’t have a configurable threshold. Although your laptop might provide a more fine-grained control given that you were able to fully discharge it while plugged in.

Hey, just a tiny note: static and dynamic addresses aren’t mutually exclusive. You can let SLAAC do its thing AND also set a static address on your server. Remember, IPv6 works best when you aren’t afraid of adding more addresses.

I agree, the fact that Meta considers 13 year olds being able to have romantic chats with chatbots to be perfectly fine is disturbing and IMHO the main newsworthy thing here.

However there is no mention of “200 pages of romantic interactions with minors” in the article - that is the whole chatbot guidelines document. Still, it including such things shows how shitty Meta is as a company.

OK, so the whole LLM chatbot arranging dates with people thing is obviously problematic, but this person simply tripped and fell, and the headline vaguely implies that the chatbot is responsible for his death. That seems a bit clickbaity - if it was a real person and they were actually waiting to meet at the agreed upon address, the outcome would be the same.

Idk, it surprises me it took so long for TP-Link to get into trouble with how they tend to support every HW revision of their routers for about a year and then stop releasing any security updates for them. That’s awful for a device intended to sit at the edge of your network, possibly having a public IP address.

Like sure, you can look for any reasons you want, but not giving a fuck about security in a device that’s always connected to the internet and also routes all user traffic is bound to get companies in trouble when someone with the power to do something about it notices.

Maybe htop? It’s pretty configurable and has decent bars for various resources.

Also if your reason for choosing pure TUI is just resource usage (and not the aesthetics of it / cool feeling / whatever else), then you could maybe look into running something like Sway or Xorg+i3 - those are very lightweight, well suited for single window usage, and open up a lot of possibilities for lightweight GUI apps.

The “correct” way to handle “static” addresses with dynamic prefix is using tokenized network interfaces (which is pretty much just the lower 64 bits of the IPv6 address). That will then be used for SLAAC in addition to the randomly generated address. The support for dynamic prefixes in firewalls on Linux and Mikrotik is however still pretty dire (obviously, as it’s not an enterprise feature). No clue about BSDs/pfSense

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.

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

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