Markaos

You can now turn on the “autoscrolling” feature of the Libinput driver, which lets you scroll on any scrollable view by holding down the middle button of your mouse and moving the whole mouse

Am I crazy, or did this used to be a feature? And not just in Firefox

It's a Windows feature that never really made it to Linux. I used to miss it but honestly, middle click paste feels way more useful to me now

Maybe Redis/Redict? The development on that seems pretty dead.

There are cameras and physical buttons that you might want to use on the phone, and the fold might make it nicer to hold in one orientation. Also, the limitation exists because splitting the apps across the shorter side can make very awkward layouts, at least on small phone screens - no such problem with a square. I see no reason not to have the option of both layouts no matter its physical orientation.

I've never used a foldable though, so take my opinion with a grain of salt.

Yes, that's exactly the problem - there's nothing wrong with the encryption used, but it's IMHO incorrect to call it time-based when it's "work-based" and it just so happens that the specific computer doing the encryption works at a given speed.

I don't call my laptop's FDE time-based encryption just because I picked an encryption that takes it 10 seconds to decrypt the key.

def generate_proof_of_work_key(initial_key, time_seconds):
    proof_key = initial_key
    end_time = time.time() + time_seconds
    iterations = 0
    while time.time() < end_time:
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
        iterations += 1
    print(f"Proof-of-work iterations (save this): {iterations}")
    return proof_key


def generate_proof_of_work_key_decrypt(initial_key, iterations):
    proof_key = initial_key
    for _ in range(iterations):
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
    return proof_key

The first function is used during the encryption process, and the while loop clearly runs until the specified time duration has elapsed. So encryption would take 5 days no matter how fast your computer is, and to decrypt it, you'd have to do the same number of iterations your computer managed to do in that time. So if you do the decryption on the same computer, you should get a similar time, but if you use a different computer that is faster at doing these operations, it will decrypt it faster.

It's a very short Python script and I'm confident I get the general idea - there's absolutely nothing related to current time in the decryption process. What they refer to as a "time lock" is just encrypting the key in a loop (so the encrypted key from one loop becomes the plain text for the next one) for the specified duration and then telling you how many iterations were done. That number then becomes a second part of the password - to decrypt, you simply provide the password and the number of iterations, nothing else matters.

Yeah, even the TLDR makes it sound more like Qualcomm is yielding to the pressure from OEMs who want to be able to offer longer updates

Oh, I tried it now and it really works. I still have mixed feelings about it, but that's definitely an improvement over how it worked at release.

Apparently it's an EU thing due to the recent DMA changes

https://www.androidpolice.com/google-pixel-launcher-change-default-search-engine/

If Microsoft got busted for giving Internet Explorer special APIs not available to other programs (which made it the best browser on Windows because of its tight integration that could not be replicated by the competition), then what business does Google have doing pretty much the same thing here?

It doesn't appear like there's any way for other search providers to hijack your nav pill and randomly pop up their own UI when you hold it, so why should Google?

You can make it use a different search engine, but that's about it. Oh, and the update that made it possible also brought a google-only circle to search gesture to older Pixels - ~~if you switch search provider, that gesture won't be available~~. Edit: it worked like that on release, but apparently has been fixed since. Now circle to search works (using Google) no matter what search provider you use for the search bar.

xrandr is Xorg only, it doesn't work with Wayland. You should be able to make SDDM use your Plasma display configuration - https://wiki.archlinux.org/title/SDDM#Match_Plasma_display_configuration

No clue if that's going to fix your issues, but at least it's supposed to work with Wayland.