Boof

  • 2 Posts
  • 66 Comments
Joined 1 year ago
cake
Cake day: June 16th, 2023

help-circle







  • dog@suppo.fiOPtoLinux@lemmy.mlLooking to migrate
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Could you elaborate a bit?

    Isn’t Proxmox etc. “Gpu less”, as they only use tty instead of anything like a WM or DE?

    I’d prefer a “master” / hypervisor running a bunch of VM’s for different purposes.

    Whether they be for gaming, pirating, development, pen testing, home automation, porn, or anything else really.

    'Course I’d only be running gpu passthrough into a single VM at a time, can’t split a single GPU into 50 passthroughs yet.


  • dog@suppo.fiOPtoLinux@lemmy.mlLooking to migrate
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    iGPU shares one monitor with the dGPU, but on different protocol, which from what I read online is supported.

    It only really needs output when I flick it open.

    So maybe it needs a KVM switch instead of trusting the monitors splits.





  • dog@suppo.fiOPtoLinux@lemmy.mlLooking to migrate
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    Scenario 1. X11 “works”, wayland doesn’t. Trying to update NVIDIA drivers leads to boot failure.

    Scenario 2. Wayland works. Only on igpu. Only via HDMI. Only on one monitor.

    Scenario 3. Wayland works on Displayport. Doesn’t even recognize second monitor.

    Scenario 4. Everything seems to work. Trying to do GPU passthrough fails.

    Scenario 5. IGPU is hogging displayport, despite being connected via HDMI, thus preventing the DGPU passthrough on either HDMI or DP.





  • Hashing on client side is both more private, and secure. All the user ever submits is a combined hash (auth/pubkey) of their username + password.

    If the server has that hash? Check the DB if it requires 2FA, and if the user sent a challenge response. If not, fail the login.

    Registering is pretty much the same. User submits hash, server checks DB against it, fail if exists.

    Edit: If data is also encrypted properly in the DB, it doesn’t even matter if the entire DB is completely public, leaked, or secured on their own servers.



  • Your password could also just be a long, unique sentence, without any excessive special characters. Maybe even a poem.

    Like "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum eu leo eu nibh efficitur viverra. Integer lacinia tortor est, quis aliquet tortor varius sed. Sed dapibus vel turpis at suscipit. Nulla consequat orci in nibh dapibus sodales. Phasellus at arcu ac dolor suscipit pretium. Curabitur sit amet justo sit amet ipsum scelerisque accumsan ac ac nulla. Nullam accumsan lorem sagittis iaculis varius. Nullam convallis nisi ante, id congue diam tincidunt vel. Aliquam sed iaculis mauris. Nam leo nisi, consequat sed sodales non, tempor vel ante. Nunc eleifend vulputate turpis bibendum bibendum. Morbi nec massa in mi sagittis lacinia id ut metus. Maecenas gravida mi vitae lorem laoreet sagittis. "

    That’s alot of common characters and words; yet, it’ll take centuries to crack.


  • That’s a misunderstanding of DDoS. 0 byte packets are actually worse than large packets.

    Which is why most DDoS (at least was) is extremely slow 0 byte requests until the server throttles/crashes under the number of requests.

    E: Consider this. Are you more likely to throttle a bandwidth of terabytes/petabytes with couple million 1gb requests; or break it entirely by sending >4294967295 0 byte requests that effectively never stop being requested from the server?