My Pixel 7 is only getting 4 years of updates
Or if you don’t count the initial year, it’s just 6 years for 8+
Is it real that Arch users are rich and have mid level PCs and is always up to date?
I do have a powerful desktop running Arch (or rather EndeavourOS with the EndeavourOS packages slowly removed over time), but also a 15 year old netbook. There’s plenty of up-to-date lightweight software in Arch repos, you don’t need to limit yourself to old software.
Also it’s not like a new version of GIMP is suddenly going to use double the memory if you use the same tools in it.
The biggest issue for the netbook is web browsing, but that’s just about web pages being resource hogs nowadays. uBlock Origin and NoScript help massively. Trying to use an old web browser is IMHO a terrible idea - you’ll end up with broken pages and a massive pile of security vulnerabilities.
It didn’t have to be this way
Yup, I know exactly what this video is going to be about, definitely not a click bait title, lol.
The topic is interesting, the video apparently not so much (if it needs that title to do well). So I think AI is acceptable here, given that no one else bothered to provide a summary so people don’t need to waste time watching it.
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.
Are you sure about that? DHL GLS (the shipping company Valve uses in the EU) has an app to move your delivery time or reroute the package, but it wouldn’t allow me to delay my SC package because “the sender” blocked it. So it sounds like a Valve problem to me here in EU.
A roguelike written in my lisp, where the magic system is a lisp.
This is so much better and more eye catching description (first line of readme)
For some reason I can’t get behind, this feature requires some virtualization mode with lowered security features.
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.
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?
Some generally older software has buggy multi threading implementation, and forcing its threads to execute “interleaved, but never simultaneously” often improves stability or even completely hides the issue.
Also I know some games used to have big performance issues if they had too many hardware threads available, but I don’t know why exactly