Absolutely agree with the fact that mAh should never have been used as a measurement of battery capacity, but increasing the voltage (while keeping the same actual capacity in Wh) makes the mAh rating lower, not higher.
1 Wh 1 V battery can provide 1 A (1000 mA) for an hour (1 V * 1 A = 1 W, 1 Wh / 1 W = 1 h) - that would be 1000 mAh.
1 Wh 2 V battery can only provide 1 A for half an hour (2 V * 1 A = 2 W, 1 Wh / 2 W = 0.5 h), and that gives you only 500 mA.
The headline is misleading if you are familiar with bloom filters.
TL;DR: the interesting thing here isn’t decreased false positive rate (multibit bloom filters are common), but the idea to put the relevant bits together. Basically you use a hash to pick a chunk of bits (32 bits in this case), then use more hashes to pick the bits within this chunk.
It is a tradeoff between accuracy (completely independent hashes would be less likely to have collisions leading to false positives) and performance (all relevant bits for the object you’re looking up will be together and the lookup will trigger at most one cache miss / memory access).
Maybe if ReactOS on RISCV becomes a reality
Do you mean RedoxOS by chance? AFAIK ReactOS is a clean room implementation of Windows/NT
For context, AirDrop is a proprietary communication between Apple devices, but the EU forced them to open it up and adopt an open protocol called WiFi Aware.
EU forced Apple to adopt WiFi Aware, but not to switch AirDrop to use it - the intended effect is that WiFi Aware is available to developers who can then create their own alternatives to AirDrop that are not locked to one OS.
Also Pixel 10 series can currently share even to iPhones that never got the new iOS with WiFi Aware support, so claiming this is thanks to EU is absolute BS (although often repeated, for some weird reason). This is just AWDL (which was reverse engineered long ago btw, and there has even been an experimental implementation on Linux for years) + some reverse engineering of the actual AirDrop protocol implemented on top of it.
Funny thing is that the same issue was resolved for me by switching the other way around - from HDMI to DisplayPort. So there’s something weirder going on than a bug in DP implementation
Drawing over the PDF is not a digital signature. I haven’t seen a browser that can sign a PDF.
People might also assume that the quote in the post is from the article, and not just your rant
The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs?
Wayland requires apps to be able to draw CSDs, so that’s just a broken app. SSDs are optional extension. So the app should either use X11 (and rely on Xwayland to provide the decorations), or implement Wayland properly.
Charles university uses and develops something called ReCodex, and it is available on GitHub. As a student, it was very nice to use.
In fact, I think you’d be better off writing a deep dive into what/how environment variables work at build time, and also invoking commands on the CLI.
But LD_PRELOAD doesn’t really have much to do with build time behavior (unless you’re talking about replacing parts of the compiler) - it allows you to force a shared library to be loaded with higher priority than anything else, so it overrides symbols from other libraries.
It is recognized and used by Linux’s dynamic linker, which is run-time, not build-time.
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.
Aren’t most newer games just using in-engine cutscenes nowadays?
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.
You don’t need any swap space for suspend to work
It is, but it still works
The download will simply fail if the version pacman wants to download isn’t available on the mirror. The version is part of the download URL.
OK, what exactly does an average person need a computer for that cannot be adequately done on a phone? Because I do have a few relatives with computers that just gather dust permanently returned off, and they don’t seem to mind.
“Oh, you didn’t spend at least a few hundred dollars on a device that you aren’t going to use for anything except flashing a custom ROM once? What a moron!”
The usual virtualized devices like network cards (that are already supported by Linux distributions like Debian) work by the hypervisor intercepting memory access to certain memory regions. Perhaps it’s not viable to support these with the secure approach where the VM is protected from Android.