I just don’t get it. Why does a game studio care about, and have better hardware attestation than most nation states?

Idk…

Maybe you can use a VPN that acts a public ipv4 address so you can get to ipv4 only stuff reliably?

or you can use one of the public free 6to4 gateways?

Could it be that rubygems does not support ipv6?

Some sites, even big sites don’t support it: https://areweipv6yet.com/

According to the above, Github doesn’t properly support it yet.

There is the excellent chess programming wiki, but unfortunately it does error 503 for me right now.

Here is the archive: https://web.archive.org/web/20250302091125/https://www.chessprogramming.org/Main_Page

Main site: https://www.chessprogramming.org/Main_Page

It has some pretty good resources to get started, and all the techniques being used.

EDIT: It’s back!!! And Lichess is doing the hosting.

If you don’t have internet, which you may need for some of the fixes mentioned here, you can try tethering, which is where you share a phone’s internet with a computer over a wired connection.

https://wiki.archlinux.org/title/Android_tethering

https://wiki.archlinux.org/title/IPhone_tethering

Although, these might depend on NetworkManager, although they might not.

Debian has old software and doesn’t support some newer hardware. Even the latest version, Trixie, is still very far behind. I realize this now.

Debian has backports, which enable you to get select versions of newer software. Relevant to your case, you can get a newer version of the kernel, drivers, and other things relevant to hardware support.

I’m sure this is completely unrelated to android’s recent decision to require all app developers to register with google, even if they aren’t distributing apps through the google play store: https://keepandroidopen.org/

Shizuku was how I was thinking of bypassing this for now, taking advantage of the local ADB connection and then using that to install apps instead of the normal package installation flow. But it looks like they want to take that away too.

Yes, Conda, not Anaconda. It uses Anaconda’s repos by default, which are bound by these terms of service: https://www.anaconda.com/legal/terms/terms-of-service , which require you to pay for commercial use if your org has more than 200 users.

Although it looks like if you only use conda-forge, or alternate repos then you should be good. It looks like miniforge, which does use the conda package manager, was made partially with the goal of avoiding these licensing issues.

https://isitreallyfoss.com/projects/conda/

The code for conda is all open source, but the default repos are provided under terms that prohibit commercial usage. Anaconda baits you into using it since it’s “free”, then sues:

https://thehftguy.com/2025/04/07/anaconda-inc-has-entered-litigation-against-non-paying-user-of-anaconda-alibaba-intel-dell-airbus/

Technically you could find alternate repos, but this is the kind of thing that should be mentioned on pages like this.

what if someone just sloppily hand-coded an insecure docker container, should you be able to kick that off too?

I can talk to them and have them fix it without them being weird about it. But if they don’t understand the poor design decisions in the first place then I have no confidence won’t be able to actually fix it, and keep it fixed in the future.

It’s fuzzy, and many generalizations are gonna be made.

Ultimately, it really comes down to human judgement and not your instance not your rules. They are hosting for free. They don’t have any obligation to host your projects. The rules and everything are nice conventions, and a good attempt at transparency, but at the end of the day, there is someone with access to the admin panel who is going to make the decisions, and you’re not really going to be able to do anything about them.

It’s the same thing with lemmy tbh, although it’s less annoying because it’s much easier to self host and migrate to Forgejo, as opposed to hosting Lemmy. That’s why I phrased it as “I would feel uncomfortable hosting this content” rather than trying to address the fuzzier arguments about the necessity of human judgement, the difficulty of detecting LLM generated code, or the possibility of incorrectness.

Ah. You’re on Void. Indeed, it does look like Void doesn’t have an implementation of systemd-tmpfiles. Here is the file from my system, it’s only creating a single symlink, which is basically the same thing you are doing:

[moonpie@nefertem home-manager]$ cat /etc/tmpfiles.d/non-nixos-gpu.conf 
L+ /run/opengl-driver - - - - /nix/store/2r6vmqh1vkivsrmr6n1vh1862i2qndqz-non-nixos-gpu

Oops, the below is for artix. I was nosy but not nosy enough and I saw a comment where you mentioning you used void after you wrote all of this. I’m gonna leave it here since it was an enjoyable rabbit hole.

I did some digging, and it looks like it is possible to use systemd-tmpfiles outside of systemd. It’s just a binary that creates files/directories/symlinks based on a format, so it’s pretty easy to extract, or reimplement entirely.

Artix has their own, an extraction from the systemd package: https://packages.artixlinux.org/packages/system/x86_64/etmpfiles/

It looks like that package is required by the base package, which is the core package set declaring the minimal dependencies needed to have a working system, so it’s highly likely you have it installed.

I think it automatically starts too, but I can’t find a hard source for this. Based on this page: https://wiki.artixlinux.org/Main/Migration#Download_the_Artix_packages it looks like etmpfiles is needed before you select/install the init system, which suggests that. This reddit post, where a user has an issue where etmpfiles isn’t installed, so their service manager complains and dies.

If you have a service named something related, like tmpfile or the like, then it does autostart.

Yeah, this makes sense. They won’t be able to kick every vibecoded project off, but it gives them a rule to point to when they do find and remove slop.

Some of the commenters on the Codeberg issue are expressing concerns about copyright status, but my main concern is security issues with these projects, which I have expressed before. Somebody vibecoded a script to sort files? I don’t really care.

Someone vibecoded a network facing application, shipping a docker container, and is trying to encourage people to deploy it? If I investigate, and see the bad security practices common to vibecoding, I wouldn’t want to be providing that for people to download. Even though I’m technically not responsible for it, it just doesn’t feel right to host something that could explode later. I would want to be able to take it down, and having a rule to point to prevents complaints when Codeberg does so.

Depending on how desperate you are, and if you are willing to delve into the dark arts, there are ways to get new KDE on stable distros. It’s probably way more effort than it’s worth, however, and I wouldn’t really recommend them to most users, due to the steep learning curve and various limitations. However, if I were to ever build a Linux distro, then I might consider them, as a way to mix and match older and newer packages.

I will also preface that KDE Plasma is one the more unreliable and prone to breakages part of my Linux system (Arch). People like to joke about krashes, but it’s kinda true. The bottom bar likes to crash sometimes, and I then I have to run systemctl --user restart plasma-plasmashell (the fact that I have that memorized scares me). KDE never really stops working overall, but various papercuts appear which I find workarounds for. Gnome is better though, and is much more reliable, IF you aren’t using extensions that aren’t officially supported, which often break on major Gnome updates. It’s probably because of that that Arch Linux sat on the Gnome update for a bit, to wait for the extensions to update and become compatible, whereas Fedora just said YOLO and pulled the trigger lmao. However, Gnome’s harder dependency on systemd might make it tough to drag a newer version onto another distro using the methods mentioned below.

The 3 ways I can think of (in order of how much I prefer them):

1. The Nix package manager can install recent packages from Nixos’s rolling release or more up to date stable distro on other distros.

Nixos is both a distro and a package manager, and their repos include things like desktop environments, that wouldn’t normally be included in solutions like brew. In fact [Hyprland’s wiki has a guide on using Nix to install Hyperland on non Nixos distros](https://wiki.hypr.land/Nix/Hyprland-on-other-distros/. This will not work for KDE however. By default, Nix packages on other distros don’t have GPU hardware acceleration, which is kinda needed for a DE. You would have to wrap these packages via Nixgl. The best way is to use home manager and use that to wrap the packages.

Wait, it looks like the docs have been updated: https://home-manager.dev/manual/unstable/usage/gpu-non-nixos.html#sec-usage-gpu-non-nixos . If you are using home manager, it looks like GPU wrapping is automatically enabled if you set targets.genericLinux.enable to true, although this requires root.

Then you would have to do some stuff to setup the login manager so that it can detect the Nix/home-manger version of KDE.

2. Bedrock Linux let’s you install multiple Linux distros at once, next to eachother, mixing and matching packages and utilities.

With bedrock, you could use a Debian base system, using the Debian bootloader, kernel, and systemd, but you could be getting your DE components from Arch. Unfortunately, it doesn’t support many things or distros (see pre installation checks), and some of the things like grub + btrfs would suck to lose.

3. Distroxbox can run an entire desktop environment from within another docker container.

The main limitations with this setup, is that you are now inside the container by default. If you execute bash, or a terminal, or whatever, it’s actually the container’s version, and not the hosts. You can configure it to automatically find and execute the host’s version of the program if it’s not found in the container. But, I would prefer just cherrypicking the DE from another distro, in order to use only that component, which is why this one is third and my least favored. But it does technically work.

Coming back to these docs a year later, it looks like something like it’s possible to enable it for everything by default by setting targets.genericLinux.enable to true. Seems the docs have been updated: https://home-manager.dev/manual/unstable/usage/gpu-non-nixos.html#sec-usage-gpu-non-nixos

Huh. The page was updated, reviewing it a year later. It does look like there is an option to automatically give GPU to all Nix/home-manager programs now. If you set targets.genericLinux.enable to true, then it should work.

Read receipts aren’t end to end encrypted.

Reactions aren’t either.

You should be able to disable it clientside.

Firstly, please don’t use Debian testing. It doesn’t receive security updates in a timely manner: https://programming.dev/post/20084040

Secondly, it looks like the versions of Nvidia drivers provided in Debian testing and Debian stable are the same:

https://packages.debian.org/trixie/nvidia-driver-full

https://packages.debian.org/forky/nvidia-driver-full

Please don’t use Debian Testing. It doesn’t receive security updates in a timely manner. I previously made a post about it:

PSA: You should know that Debian Testing does not receive security updates in a timely manner, and is not intended for production use.

Unlike Debian Unstable or Debian Stable, there is no fast track for vulnerability fixes needed into Debian testing. In my post above, I note that Debian stable and unstable received a fix for a very severe vulnerability. However, Debian testing was left to dry for almost a week, for a known critical vulnerability.

If you want more updated applications, you can use tools like flatpak, distrobox, appimage, or nix to layer newer applications onto a system of any Linux distro.

If you want newer base packages and underlying utilities, like a newer desktop environment, you can get stable distros that provide this, like Fedora, or Opensuse Leap.

Unfortunately it is still in Beta, but Opensuse Slowroll is OpenSuse’s solution, a rolling release that delays package updates to test and iron out bugs before pushing updated versions out. It’s somewhat of an in between a rolling release and a stable distro, and a very promising model.

You can also just directly use a rolling release distro. Debian Unstable isn’t as bad as it sounds. Unstable doesn’t mean unreliable or prone to breakages. Unstable just means that the bugs deal with will constantly be changing, instead of dealing with the same bugs all the time.

But please don’t use Debian Testing. It’s in the name, it’s only for testing purposes.

Firstly, did you get it working? I notice your latest commit seems to mention that you got it working

One thing I would recommend is to declare the iamb package separately in a let... in statement.

let
   iamb = (mknixpak blah blah blah)

....
....

in

 userconfig.programs.iamb = {
      enable = true;
      # By using "iamb", instead of pkgs.iamb, it means we are using the nixpak wrapped version here
      package = iamb
      settings = {
        profiles.user.user_id = "@username:instance.com";
        settings = {
          image_preview = { };
          username_display = "displayname";
          user_gutter_width = 15;
        };
      };
    };

This make it so that iamb is the nixpak wrapped version instead, in the userconfig. This would probably also make it so that you don’t need to declare it explicitly in your systemPackages.

There are probably other private parts of the crates website, like the pages for developers who are uploading crates. It makes sense to just give the same error for everything, from the same logic all in one easily auditable spot.

And of course, just because all crates on the site are public now, doesn’t preclude the possibility of private crates im the future.