LLM scrapers are taking down FOSS projects' infrastructure, and it's getting worse.

[SOLVED] - I learned that this is a sure way to break your Debian, and no matter how you go about it, you'd wish you either waited or used a different distro altogether for this purpose. In my case, I got Nobara 41 working, which already has the latest mesa. Trying to install the latest from Debian unstable almost got me pretty turned around, and I'm glad I switched course when I did.

Original post: Apologies for my fairly low-level question. I spent all day yesterday spinning my wheels on this.

(I do fine using Debian Linux as my daily driver, but I'm not ashamed to admit that this (and things in this area) are beyond my experience. I've never compiled anything from source. I used to be a wiz with DOS 6.22 and Windows through 7, but my brain just stopped learning these things properly some time in the past.)

My distro (MXLinux 23.x) just announced they're almost ready to include Mesa 24.2.8. I purchased an AMD RX 9070, and all my Linux games (HGL or Steam) are angry that Vulkan can't recognize a valid GPU.

I see that Mesa 25.0.2 should work, but I don't know how to either build & install from source or add a repo for that particular package only.

I see that Arch users can easily use the Mesa-git or others, but not my Debian 12.

I installed Nobara to a spare drive as a stopgap, but on that install, FH5 refuses to prompt for account sign in there no matter which Proton I use.

Edit: I'm using the AHS version which includes the liquorix 6.13.7-2 kernel, and none of the repos (testing, back ports) show a higher version of Mesa.

EDIT2:

System:
  Kernel: 6.13.7-2-liquorix-amd64 [6.13-5~mx23ahs] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: audit=0
    intel_pstate=disable amd_pstate=disable BOOT_IMAGE=/vmlinuz-6.13.7-2-liquorix-amd64
    root=UUID=<filter> ro quiet amdgpu.ppfeaturemask=0xffffffff init=/lib/systemd/systemd
  Desktop: Xfce v: 4.20.0 tk: Gtk v: 3.24.38 info: xfce4-panel wm: xfwm v: 4.20.0 vt: 7
    dm: LightDM v: 1.32.0 Distro: MX-23.5_ahs_x64 Libretto May 19  2024 base: Debian GNU/Linux 12
    (bookworm)
Machine:
  Type: Desktop Mobo: ASRock model: B650E Taichi serial: <superuser required> UEFI: American
    Megatrends LLC. v: 3.20 date: 02/21/2025
CPU:
  Info: model: AMD Ryzen 5 9600X bits: 64 type: MT MCP arch: N/A level: v4 note: check
    family: 0x1A (26) model-id: 0x44 (68) stepping: 0 microcode: 0xB404023
  Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache: L1: 480 KiB
    desc: d-6x48 KiB; i-6x32 KiB L2: 6 MiB desc: 6x1024 KiB L3: 32 MiB desc: 1x32 MiB
  Speed (MHz): avg: 3175 high: 5437 min/max: 3000/3900 boost: enabled scaling:
    driver: acpi-cpufreq governor: ondemand cores: 1: 2900 2: 2972 3: 2959 4: 3018 5: 5437 6: 2819
    7: 3000 8: 3000 9: 3000 10: 3000 11: 3000 12: 3000 bogomips: 93602
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Enhanced / Automatic IBRS; IBPB: conditional; STIBP: always-on;
    RSB filling; PBRSB-eIBRS: Not affected; BHI: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD vendor: Gigabyte driver: amdgpu v: kernel pcie: gen: 5 speed: 32 GT/s lanes: 16
    ports: active: DP-1 empty: DP-2, HDMI-A-1, HDMI-A-2, Writeback-1 bus-ID: 03:00.0
    chip-ID: 1002:7550 class-ID: 0300
  Device-2: AMD vendor: ASRock driver: amdgpu v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    ports: active: none empty: DP-3, DP-4, DP-5, HDMI-A-3, Writeback-2 bus-ID: 4f:00.0
    chip-ID: 1002:13c0 class-ID: 0300 temp: 42.0 C
  Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.20.0 driver: X: loaded: amdgpu
    dri: swrast gpu: amdgpu display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 509x286mm (20.04x11.26") s-diag: 584mm (22.99")
  Monitor-1: DP-1 mapped: DisplayPort-0 model: Acer XF250Q serial: <filter> built: 2018
    res: 1920x1080 dpi: 90 gamma: 1.2 size: 544x303mm (21.42x11.93") diag: 623mm (24.5") ratio: 16:9
    modes: max: 1920x1080 min: 720x400
  API: OpenGL v: 4.5 Mesa 24.2.8-1mx23ahs renderer: llvmpipe (LLVM 15.0.6 256 bits)
    direct-render: Yes

The Linux Ship of Theseus

Crossposted from: https://lemmy.ml/post/27387345

1. pick any distro and install it.
2. Then, without installing another distro over the top of it, slowly convert it into another distro by replacing package managers, installed packages, and configurations.

• System must be usable and fully native to the new distro (all old packages replaced with new ones).
• No flatpaks, avoid snaps where physically possible, native packages only.

Difficulties:

• Easy: pick two similar distros, such as Ubuntu and Debian or Manjaro and Arch and go from the base to the derivative.
• Medium: Same as easy but go from the derivative to the base.
• Hard: Pick two disparate distros like Debian and Artix and go from one to the other.
• Nightmare: Make a self-compiled distro your target.

Clarifications

• chroot, dd, debootstrap, and partition editors that allow you to install the new system in an empty container or blanket-overwrite the old system go against the spirit of this challenge.
• These are very useful and valid tools under a normal context and I strongly recommend learning them.
• You can use them if you prefer, but The ship of Theseus was replaced one board at a time. We are trying to avoid dropping a new ship in the harbor and tugging the old one out.
• It may however be a good idea to use them to test out the target system in a safe environment as you perform the migration back in the real root, so you have a reference to go by.

Edit: rootless in this context means the remote windows appear like local windows; not in a big "desktop" window. It's nothing to do with the root account. Sorry, I didn't come up with that confusing term. If anyone can think of a better term let's use that!

This should be a simple task. I ssh to a remote server. I run a GUI command. It appears on my screen (and isn't laggy as hell).

Yet I've never found a solution that really works well in Linux. Here are some that I've tried over the years:

• Remote X: this is just unusably slow, except maybe over a local network.
• VNC: almost as slow as remote X and not rootless.
• NX: IIRC this did perform well but I remember it being a pain to set up and it's proprietary.
• Waypipe: I haven't actually tried this but based on the description it has the right UX. Unfortunately it only works with Wayland native apps and I'm not sure about the performance. Since it's just forwarding Wayland messages, similar to X forwarding, and not e.g. using a video codec I assume it will have similar performance issues (though maybe not as bad?).

I recently discovered wprs which sounds interesting but I haven't tried it.

Does anyone know if there is a good solution to this decades-old apparently unsolved problem?

I literally just want to ssh <server> xeyes and have xeyes (or whatever) appear on my screen, rootless, without lag, without complicated setup. Is that too much to ask?

For personal reasons, I no longer feel safe working on Linux GPU drivers or the Linux graphics ecosystem. I've paused work on Apple GPU drivers indefinitely.

I can't share any more information at this time, so please don't ask for more details. Thank you.

If you think you know what happened or the context, you probably don't. Please don't make assumptions. Thank you.

I'm safe physically, but I'll be taking some time off in general to focus on my health.

Well that's sudden.

3 years ago I needed a new computer and decided on an 16 inch M1 Macbook Pro, but did lots of overthinking about if I wanted to stick to it. I tried Asahi Linux didn't have any reasons at the time to use linux over macOS (but there was always the chance I might later), the build quality is 2nd to none, none of my Windows laptops lasted more than a few years.

3 years later, I've really been itching to switch to Linux. Two of several reasons: because its DEs are more customizable, it has better documented accessibility APIs if you want to make keyboard navigation software. I reinstalled Asahi Linux and really tried to make it my daily driver, but the lacks of apps would require me to dual boot: Photoshop and Roblox.

I researching again for computers closest to Macbook Pros but none of them come close to its build quality. I think it would be best for me to make my own desktop PC for linux. I don't think I'd fare well with another windows laptop brand.