Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)O
Posts
5
Comments
777
Joined
3 yr. ago

  • That was Microsoft's goal with Windows Phone and Windows 8, it just never took off

    Ubuntu also tried (not sure if MS or Canonical was first)

  • I'm not as concerned about whether the packagers can be trusted - I also trust the packagers in sid, and like the fasttrack keyring is in Debian's main repo

    What I'm worried about is that it seems like these bypass the testing repo, and build directly from sid (and sometimes experimental)

    Generally, that has been discouraged, as the package version can get ahead of testing, and make a "frankendebian" where it isn't safe to upgrade from e.g. Debian 12 -> Debian 13, as your Debian 12 packages are newer than the Debian 13 packages

    Is there something with the package versions that keeps this "safe," or will there be fasttrack packages for Debian 14 prepared prior to Debian 14, such that you can upgrade between major versions without conflicting packages (take for example fast track's Kernel and Mesa being ahead of Testing)

    Edit: for another example, are these more like backports-sloppy with all the warnings about upgrading after using the repo?

  • Do these repositories follow similar rules to backports such that you have a guarantee you can safely upgrade to the next release with them installed?

  • They'll get loaded, even without root

  • At least with the vendors I'm referring to (2/3 that make all Android phones), they just took the open source code, hacked it up as quickly as possible to get some basic drivers working, and moved on.

    There wasn't any "special sauce" in the source, they just didn't want to spend the effort to upstream it

    Edit: Just because you said "hardware open source" I wasn't advocating for open hardware, just for hardware vendors to, ya know, support the hardware

  • Linux phones try to build from upstream Linux, and the major phone SoC vendors HATE upstreaming their code.

    They believe every character in their source code is absolutely top secret.

    A middle ground I wish was considered more is taking Google's kernel and the vendors DLKM partition/DTB/DTBO for hardware support, and putting a GNU userspace on top.

    This has had problems in the past, because vendors would modify syscall tables such that they don't match userspace anymore, but with GKI, I think we're closer to that being a possibility

  • Just gotta go back to tri-channel

  • The corporate images for our company come with Firefox ESR, and you can file an automated request for Chrome if you want it added 🤷‍♂️

  • TL;DR, it looks like a faster PWM, closer to an LCD monitor's PWM speed (fingers crossed without affecting color accuracy)

    No changes to potential burn-in

    Edit: I'm curious if this change affects the power savings of OLED over other panels?

  • GitHub manages not one, but TWO nines of availability.

    Sometimes both nines are even in the front!

  • We got one for my sister in law, and she likes it for college.

    She wanted to just use an iPad, but she had to have macOS for the proprietary test tool spyware. It runs on the neo

  • Edit: to be clear, this advice is specific to Ubuntu. If you come across this and need advice for a different distro, message me or reply to this

    Yes.

    Ubuntu doesn't follow upstream kernels, so they will have to make a custom backport for 6.17 to fix the kernel

    It's very unlikely you need the module that has the bug, so the mitigation should work for you

    Just double check lsmod | grep aead

    As long as that module is not loaded, and you have the kmod update that adds /etc/modprobe.d/disable-algif.conf you're protected

  • The kmod change makes it so the affected module cannot be loaded, it was their initial workaround

  • The ones I was watching look like there's an update as of an hour ago, but there wasn't at the time of the post

    Need to check Raspbian still, being on self hosting

  • They aren't available on all releases - the people that found the issue didn't really follow responsible disclosure, so distros didn't have time to fix it

    They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out

  • Giving a better solution is certainly useful.

    I'd used initcall_debug before, but not initcall_blacklist

  • I'm working off the knowledge that OP is using a rolling release, so is likely fixed by that for them. (Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I'd expect Bazzite to have it too. If they're using Debian Sid/Testing, it's both fixed and a module)

    If you're using something else, this eBPF filter is probably your best bet https://github.com/Dabbleam/CVE-2026-31431-mitigation

  • Yeah... It seems like they only reached out to the kernel, and not to any distros...

    They also disclosed after 37 days rather than the more standard 90 days for everyone to patch

  • KDE @lemmy.kde.social

    Plasma Vault Experiences

  • No Stupid Questions @lemmy.world

    How can sales tax brackets affect purchasing behavior when prices are pre-tax?

  • Games @lemmy.world

    Halo on the Gameboy Color

    sofaswordsman.itch.io /halo-combat-devolved
  • Linux @lemmy.ml

    Silverblue vs uBlue

  • wefwef @lemmy.world

    Keyboard missing in text entries