Markaos @ Markaos @lemmy.one

Posts

6

Comments

217

Joined

2 yr. ago

Zig didn't come to my mind when I was writing my comment and I agree that it's probably a decent option (the only issue I can think of is its somewhat small community, but that's not a technical issue with the language).

My argument against Go and Java is garbage collection - even if Java's infamous GC pause can apparently be worked around with a specialized JVM, I'm pretty sure it still comes at the cost of higher memory usage and wasted CPU cycles compared to some kind of reference counting or Rust's ownership mechanism (not sure about the proper term for that). And higher memory usage is definitely not something I want to see in my browser, they're hungry enough as is.

Why not just say Rust? There isn't really anything else that would provide good enough performance for a browser engine with modern heavy webpages while also fixing some major pain point of C/C++

What's Steve?

The Quick Share option missing is weird - Nearby Share/Quick Share is supposed to be available on every Android 6 or newer device since roughly 2020. And it's supposed to be able to automatically figure out a reasonable way to connect the devices (LAN if they are in the same network, Bluetooth or WiFi Direct otherwise).

They're not doing a recall, but that doesn't mean they won't somehow compensate big OEMs for their warranty issues.

Probably a bit of a TL:DR of the other answer, but the short answer is: the execute bit has a different meaning for directories - it allows you to keep going down the filesystem tree (open a file or another directory in the directory). The read bit only allows you to see the names of the files in the directory (and maybe some other metadata), but you cannot open them without x bit.

Fun fact, it makes sense to have a directory with --x or -wx permissions - you can access the files inside if you already know their names.

Edit: not a short answer, apparently

It's not about Lens, they just used it as the preview image for some reason. The built-in QR scanner should be accessible through quick settings tiles (you might have to edit your quick tiles and add it), and when I launch it and go to the recent apps screen, it doesn't have any app icon, so it is at least somewhat special and not just a regular part of some other app.

Maybe try looking up those links on Wayback Machine? I don't think they use Cloudflare

I get that, but my understanding was that you want to be able to see the map after the trip, not necessarily during it. Which is pretty much what I do with OpenTracks - record my trips and then import them to NextCloud where I can see a big map of all of them combined or look at some specific ones. And there's plenty of Android apps that can import GPX to do the same.

But if MapMyDrive works well for you, then it's a moot point - enjoy what works.

How nice does the user experience have to be? OpenTracks is a decent app for recording GPX tracks (if some map application supports importing tracks from outside the app, it will definitely support GPX), but that's the only thing it does - you don't even get a map in the app.

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.

 python3

    
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

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.

Right, now get a borderline computer-illiterate person to connect to your network, ensure their firewall isn't misconfigured to block all incoming traffic (with TeamViewer, this configuration would still work because the device just connects to the TV server) and open and set up a completely separate screen sharing program.

I know none of these steps are difficult if you have any idea what you're doing, but I've met plenty of people who would most likely need assistance going through the motions. Funnily enough, the best way to do it remotely would probably be to get them to install TeamViewer to then set this up for them remotely.

By the way, as far as networking goes, Tailscale does the same thing TeamViewer does, just for a VPN instead of a screen sharing application - it will try to do all the NAT punchthrough techniques and IPv6 connection and fall back on tunneling through relay servers if all else fails. It's not any more of a direct connection than TV.

So I did look more into it, and apparently the open firmware is technically compatible with PCIe cards using this chip, but doesn't provide any advantages over just wiping the firmware and letting the chip default to its built-in fallback firmware, and so the maintainer doesn't see any value in explicitly supporting it.

Now the question is whether you consider the proprietary fallback firmware to be acceptable to run - this might sound weird, but for example FSF has explicitly made exceptions for devices with built-in firmware to be able to qualify for the Respects Your Freedom certification, so if your view aligns with theirs, you might consider this to be completely OK. If not, the free firmware appears to have a similar feature set, you'll just have to jump through more hoops.

Also do note that both the fallback firmware and the free firmware are missing many features of the proprietary firmware, so make sure to check it's not missing anything you need (wake on LAN, Jumbo frames and PXE boot seem like the most notable missing features to me).

More info on support for various PCIe cards