The battery tray indicators I've tried on Linux so far only seem to take the instantaneous power consumption into account. Is there one that estimates remaining battery life based on power draw over a longer time window and integrates easily with my desktop environment's tray?

Even if I have the full address of a destination, trying to search for it in CoMaps easily takes more than 30 seconds before I can select it and have it shown on the map. Sometimes if I have a general idea of where it is, I can find it faster than search. Is this normal? Are there settings I'm overlooking that could speed it up?

When I first looked up psyllium husk powder as a fiber supplement, people were complaining that it made the water thick and gross. That enticed me to buy it. And when the packaging said to drink immediately after mixing lest it thicken, I instead let it sit for a good 15 minutes until my glass of water had a smoothie-like consistency. Makes me love drinking water again and also sad that I can't have it with every glass of water or else I get stopped up.

When the privacy laws in the US are so weak, it seems like maintaining the effect of data removal requires paying for the data removal service indefinitely. Is it worth it regardless? Are there any cases and criteria where one should pay for data removal, more so than the average person? Interested to hear if anyone here has seen noticeable benefits, beyond the mere fact that their PII have been scrubbed from data brokers and search sites.

Middle click failure plagues nearly every mouse I've owned, OEM, Logitech, wired, or wireless. I take full advantage of the middle click shortcuts like opening links in new tabs, but I don't think I'm putting it through undue stress either. As far as I can tell, I'm clicking it with the same force as I would the other mouse buttons and much less frequently than the left click.

Failure usually starts with occasional missed middle clicks, which after some point, rapidly progresses until it's failing to register more often than not. At that point, everything else will still work perfectly. No improvement even if I take it apart to clean out what little dirt had accumulated.

One of my mice has managed to avoid this fate far longer than the others but I've just recently stopped using it due to the rubberized exterior turning all gooey and sticky. The only middle mouse buttons that seem immune to all of this are the ones on ThinkPads. Anyone else notice this or could recommend a good mouse that can stand up to a bit of middle-clicking?

A while ago, I set up unattended-upgrades on my Debian 13 machines. Running sudo apt updatedoesn't cross my mind now that I assume unattended-upgrades takes care of that for me, but every once in a while, I'll try installing something and get the "Unable to locate package" errors associated with outdated repositories. After being made aware of having outdated repositories and packages, I'll go and run sudo apt update && sudo apt upgrade on my other machines, only to be told that all packages are up to date and unattended-upgrades did do its job there. I don't keep a record of this happening, but I also don't recall there being any pattern to which of my machines are affected and which aren't at any given time.

Where could I start hunting down the cause of this inconsistent behavior? I did double-check that I enabled it via sudo dpkg-reconfigure unattended-upgrades

I could in theory upgrade the power supply to go beyond the 150W target, but then I'd also need a better chassis because it is already quite warm with my current 130W card.

Hoping to stick with AMD, but if my wishes to play around with local LLMs and image upscaling makes Nvidia a more practical choice, I can live with that compromise.

Working with a budget of 200 US, I'm fine going with a used GPU.

Friends and I are considering some travelling around the world, including perhaps a trip to China. There is much negative press on the state of digital privacy in China, but what exactly should I pay attention to if I do visit? If I am your typical privacy enthusiast with a GrapheneOS phone and Linux laptop, how might I prepare for the trip privacy-wise? I'd also love to hear any firsthand experience as to which concerns are myths and which ones are real.

Got my hands on a Dell Latitude ON module. Turns out it's nothing more than a 2 GB flash module that fits in a mPCIe slot and is wired to the USB lanes. Shows up as /dev/sdb.

I do have a couple of old laptops that don't have a secondary SATA drive slot, but do have open mPCIe slots with USB lanes (no mSATA lanes). The Latitude ON module would allow for a dual drive system, albeit a rather crappy one. What would you put on a secondary internal drive if it were limited to 2 GB and USB protocol?

For several years, I've entertained the idea of creating an online portfolio, but it's remained only an idea since I am not sure what I should put on it. What's a good way to decide what goes on the personally-identifiable portfolio and what should remain under pseudonyms?

In the interest of maximizing battery life, I've set up suspend-then-hibernate on my laptop. Using a discrete window manager, so I have a systemd unit that locks the screen when I close the lid. After an hour, it automatically goes into hibernation.

All is well, until I have to boot up from hibernation. I'm prompted to unlock LUKS, then I'm hit with a redundant lock screen once resumed. I've tried setting up systemd units referencing suspend-then-hibernate.target and hibernate.target, but I can't get it to kill the screen locker when resuming from hibernation only, so I don't have to type in my password twice. Is there any way to have systemd discriminate between the suspend and hibernate parts of suspend-then-hibernate?

Earlier post for context: https://lemmy.ml/post/35496495

TL;DR: Don't buy Huawei or Honor phones if you need bootloader unlocking capabilities. Even on units without a carrier lock. I couldn't unlock my Honor 90 Lite.

While the following comes from my experience attempting to unlock the bootloader on an Honor 90 Lite, it likely also applies to recent Huawei smartphones. Honor shares a great deal of its codebase with Huawei as it was a subsidiary spun off several years ago.

Unfortunately, a visible OEM unlocking toggle under the developer options does not guarantee bootloader unlocking in practice. It is up to the bootloader itself to accept unlocking commands, which manufacturers can patch out or severely restrict.

Prior to 2020, users could fill in a form on the Huawei/Honor website that provided the 16-character code required to unlock the bootloader. Instead of

fastboot flashing unlock

Huawei/Honor bootloaders require

fastboot oem unlock [16-CHAR CODE]

However, the form has since been discontinued, leaving us with

• Exploits for certain models with Kirin and Qualcomm SOCs
• Various paid and proprietary unlocking services
• Brute-force tools for models without known exploits

Since my phone does not have a known exploit and I don't feel like handing over my money to unlocking services with characteristically shady-looking websites, I am left with the latter option.

Brute-force with Luhn algorithm

For some time, the unlock codes were 16-digit numerical strings which were related to the IMEI and satisfied the Luhn algorithm (the same algorithm used as a rudimentary checksum for credit card numbers). This greatly narrows down the number of codes to be tried, such that I exhausted the entire space of 16-digit codes satisfying the Luhn algorithm in 45 minutes using the following Python scripts.

https://github.com/vcka/huawei-honor-unlock-bootloader

The better-known of the two Python scripts, this works mostly as intended, but does not stop once the space of 16-digit codes are exhausted, instead continuing up into 17-digit codes and beyond. However, an unlock code longer than 16 digits has never been attested.

https://github.com/borisgrigorov/bootloader-brute-force

This script did not appear in my initial search and didn't work out of the box on account of expecting a specific error message and stopping execution otherwise. However, it proved a friendlier script than the former with a quick patch and stopped once all 16-digit codes valid under the Luhn algorithm were exhausted.

Huawei/Honor are also known to require 16-digit alphanumeric codes, paritcularly on later models. Adding just the uppercase alphabet would make for a 16-character base-36 code, effectively conveying the information in a 25-digit base-10 code. Searching through this space would take about 800 million times longer. By the time this finishes, I can only hope that humanity has moved on past locked bootloaders. So I ditched any effort of extending the scripts to include alphabetic characters.

Trying both scripts with both IMEIs yielded no working unlock codes, so onto our next options.

Brute-force without Luhn algorithm

But what if it's still a 16-digit code, but it just doesn't add up according to the Luhn algorithm? How much longer would that take? The following C programs claim to be the fastest brute-force unlockers, neither of which use the Luhn algorithm.

https://github.com/Martazza/Huawei-Bootloader-Unlocker

The simpler and more well-known of the two, this simply increments up from 1000000000000000, testing each code along the way. At a rate of 200 guesses per second, my computer and phone would have burned through a good chunk of the world's remaining coal reserves by the time this finishes, even without accounting for alphabetical characters. So this is a no-go.

https://github.com/B83C/huawei_bootloader_unlocker

This optimizes upon the code of the former, incorporating portions of the fastboot source code to suppress unnecessary output. However, it appears to get stuck after guessing only 8 codes. I'll guess why in a bit.

Previously reported successes and time required to unlock

There are reports of the scripts utilizing the Luhn algorithm working on Huawei and Honor devices from around 2018 and 2019. Those attempts required continuous brute-forcing anywhere from several hours to several days. So why was my computer, featuring an i7-9700 also from 2019, able to iterate through all codes accoring to the Luhn algorithm in only 45 minutes? I am not certain, but my theory is that my phone had been silently discarding attempted codes without ever taking the time to evaluate them. The program from B83C is the only one to check the USB connection status and 8 attempts may have been the cutoff for my phone. I didn't bother with further testing. And unless someone manages to guess several million codes per second, at which point USB I/O would become a bottleneck, Martazza's code is of little practical use.

If it had taken longer to search through possible codes, my phone would have died during the process as it did not take in enough charge to sustain itself in fastboot. Fortunately, fastboot is kind enough to wait until the phone is ready again after disconnecting, charging, and reconnecting.

Other things that didn't work

• fastboot reboot fastboot: bootloader seems to double as fastboot for Huawei/Honor devices. fastboot with a white background and plain orange text doesn't seem to take any commands.
• Recovery menu accessed by holding volume up during boot: OTG upgrade does not allow choosing a file. USB upgrade allows the phone to show up under adb devices, but there is no dialog to grant permission.
• mtkclient: tried every button combination I could think of during power-up, but could not enter BROM mode
• Honor Suite: Just a dumbed-down syncing tool that requires admin privileges on Windows, no option anywhere related to bootloader unlocking. Worse yet, it doesn't even detect the phone in fastboot mode, even though the phone suggests opening Honor Suite when in fastboot.

Addendum: for thoroughness, shorting the internal test point to ground and plugging in USB brings the phone into "META MODE", after which the screen stays black. The phone is unresponsive to all commands I could think of and requires a power cycle, after which the RTC resets to the default date and time.

• and adb reboot edl and similar commands: simply does a normal reboot. fastboot edl seems to exist, but is prohibited from running.

Just to be clear: I could not unlock the bootloader of my Honor 90 Lite (CRT-NX1). Gotta love how we have to worry about things like Cellebrite cracking our precious data in a matter of hours while concerted efforts have done little against the accursed little bootloader.