• 0 Posts
  • 38 Comments
Joined 3 years ago
cake
Cake day: June 23rd, 2023

help-circle









  • It still doesn’t matter.

    • They can coopt all the open source licenses they want, the development work doesn’t need them.
    • They’re not capturing all commits going forward in time, they’ll have to redo it every time they need an updated library.
    • Any legal work done later that legitimizes this relicensing will open the door for the public, open source world, and more importantly, other relicensing companies to do it to them.

    I believe the end game of legitimizing open source relicensing theft is accidentally abolishing software copyright altogether.

    https://nedroidcomics.tumblr.com/image/41879001445






  • tl;dr:

    If you think something is blocking DNS traffic, you could try configuring DNS-over-HTTPs or DNS- over- TLS and picking a reputable upstream. This should obfuscate the traffic somewhat and get past common DNS interference issues and tactics.


    So building on what yourself and everyone else has said, it does seem to be a DNS issue.

    I found that at select times my local ISP was up to shenanigans with DNS.

    I live in a very small country and work in IT. The NOC for all three ISPs and I have met. It would surprise me if they were competent enough to do this intentionally for malicious purposes.

    If you can get access out to the internet via ping, see if you can do other things - get on a VPS and test with tcpdump at both ends. There’s a few free ones or trials great for disposable purposes like this. Set it up in advance…

    You won’t know what it is til you troubleshoot.

    I’ve had huawei firewalls reaching some simultaneous connection limit and fail, reversing their ruleset - blocking everything except ICMP, tr069 and ssh (concerning) outbound…

    I’ve had problems with specific DNS servers, through the ISP’s network.

    I’ve seen regular BGP changes causing outages all over the place (the ISPs locally don’t peer with each other…)

    Post your findings, would love to help/hear!


  • I love my steamdeck oled.

    I use it primarily for upscaled emulation using retrodeck, (it runs PS2 upscaled to 4k, with all the beautification hacks switched on no problem) and in-home streaming which it excels at because of specialized hardware - sub 15ms 2k frame decode time over wifi (indistinguishable from being in front of your PC).

    It can run large amounts of the steam catalogue, but very modern games that are quite demanding are going to struggle a lot, even at the native 800p. I prefer to stream them from my PC which it does very well.

    Definitely get the oled model. Still might be the best screen I own. No ghosting and very good visual clarity. It’s still 800p though. I got the 512GB model and upgraded the SSD to 2TB myself. It was a little bit delicate, but nothing really major.

    Worth noting that despite hating games running less than 60Hz, and preferring 120+, the performance target of the switch is actually 45Hz. With the 90hz display, locking the fps in for vsync at 45hz is actually perfectly acceptable for most games. Not allowing screen tearing is enabled by default for everything, and the frame limiter is available for changing/switching in game via a quick menu.

    That said, if I wanted it as my sole gaming device, I would get something else.

    I keep a USB-C dock behind my tv and when the tv is mine for an hour, I plug it in and grab my controller, and I’m in my game in less than 30s. If the tv is not mine for an hour, I can still get a bit of game time in handheld on the sofa.

    Currently replaying unfinished games from my childhood - or ones I wanted but never got to play.

    Battery life is highly variable. For emulation, you’ll get ages - 6+ hours. Same for much older steam titles. I played half life for 7 hours during a hurricane power outage once. Elden ring gets maybe 1hr20m.

    I did get a Killswitch kit from dbrand, and would recommend that. It makes slinging it in a bag much easier and friendlier size wise compared to any case you can buy. It’s the best. The stand is surprisingly useful too. Fair warning, the deck is heavy enough without this extra mass, it’s not easy on the elbows for extended play on your back in bed e.g.

    The killer features are:

    • the overall simplicity
    • steam in-home streaming hardware performance (outperforms theoretically much beefier hardware in all scenarios)
    • screen

    Bummers are:

    • lackluster performance in modern titles.

    Note: I am holding out hope for the recent Wine 11 ntsync patches being ported to proton - steams version of the windows compatiblity layer. With the recent fps improvement numbers, I’m hoping this will have a big impact.

    The reason being, on the deck, the performance being poor isn’t all across the board, just for lots of newer titles. The Halo Master Chief collection will run at 120Hz at 1080p no problem.





  • med@sh.itjust.workstoSelfhosted@lemmy.worldHoliday Upgrade Disasters
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    7 months ago

    I was trying to finalize a backup device to gift to my dad over Christmas. We’re planning to use each other for offsite backup, and save on the cloud costs, while providing a bridge to each other’s networks to get access to services we don’t want to advertise publicly.

    It is a Beelink ME Mini running arch, btrfs on luks for the os on the emmc storage and the fTPM handling the decryption automatically.

    I have built a few similar boxes since and migrated the build over to ansible, but this one was the proving ground and template for them. It was missing some of the other improvements I had built in to the deployed boxes, notably:

    • zfs on luks on the NVMe drives
    • the linux-lts kernel (zfs compatibility)
    • UKI for the secureboot setup

    I don’t know what possessed me, but I decided that the question marks and tasks I had in my original build documentation should be investigated as I did it up, I was hoping to export some more specific configuration to ansible to the other boxes once done. I was going to migrate manually to learn some lessons.

    I wasn’t sure about bothering with UKI. I wanted zfs running, and that meant moving to the linux-lts kernel package for arch.

    Given systemd-boot’s superior (at current time) support for owner keys, boot time unlocking and direct efi boot, I’ve been using that. However, it works differently if you use plain kernels, compared to if you use UKI. Plain kernels use a loader file to point to the correct locations for the initramfs and the kernel, which existed on this box.

    I installed the linux-lts package, all good. I removed the linux kernel package, and something in the pacman hooks failed. The autosigning process for the secure-boot setup couldn’t find the old kernel files when it regenerated my initramfs, but happily signed the new lts ones. Cool, I thought, I’ll remove the old ones from the database, and re-enroll my os drive with systemd-cryotenroll after booting on the new kernel (the PCRs I’m using would be different on a new kernel, so auto-decrypt wouldn’t work anyway.)

    So, just to be sure, I regenerated my initram and kernel with mkinitcpio -p linux-lts, everything worked fine, and rebooted. I was greeted with:

    Reboot to firmware settings
    

    as my only boot option. Sigh.

    Still, I was determined to learn something from this. After a good long while of reading the arch wiki and mucking about with bootctl (PITA in a live CD booted system) I thought about checking my other machines. I was hoping to find a bootctl loader entry that matched the lts kernel I had on other machines, and copy it to this machine to at least prove to myself that I had sussed the problem.

    After checking, I realised no other newer machine had a loader configuration actually specifying where the kernel and initram were. I was so lost. How the fuck is any of this working?

    Well, it turns out, if you have UKI set up, as described, it bundles all the major bits together like the kernel, microcode, initram and boot config options in to one direct efi-bootable file. Which is automatically detected by bootctl when installed correctly. All my other machines had UKI set up and I’d forgotten. That was how it was working. Unfortunately, I had used archinstall for setting up UKI, and I had no idea how it was doing it. There was a line in my docs literally telling me to go check this out before it bit me in the ass…

    • [x] figure out what makes uki from archinstall work ✅ 2025-09-19
    • It was systemd-ukify

    So, after that sidetrack, I did actually prove that the kernel could be described in that bootctl loader entry, then I was able to figure out how I’d done the UKI piece in the other machines, and applied it to this one, so it matched and updated my docs…

    • IT WASN’T ukify

    UKI configuration is in mkinitcpio default configs, but needs changing to make it work.

    vim /etc/mkinitcpio.d/linux-lts.preset 
    

    Turns out my Christmas wish came true, I learned I need to keep better notes.