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.

1. Preinstall wine

2. Enable wine as the default app to open exes,.

then, when you double click on an exe you downloaded in your file explorer, it will launch and open.

Many of the user friendly Linux distros do this.

Of course there are caveats, in that if you run an installer, it might not show up in your desktop or so on. And any programs that need admin or have heavy drm also won't run.

Im addition to that, I dislike the model of downloading exes from the internet. Here is the other comment with my thoughts: https://programming.dev/post/48941029/23338730

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.

Debian has a policy of only cherry picking security updates, or critical bugfixes, in order to ensure maximum system stability. In general, they don't do entire program updates or additional features. For the 4 year lifecycle of a Debian release, it will behave the same as it did yesterday.

As of today, current version of rsync in Debian's stable's packages is 3.4.1: https://packages.debian.org/stable/rsync (archive).

The versions with significant LLM assistance are 3.4.3 and later.

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.

Might be a bug, so we can troubleshoot to try to figure it out.

If you visit about:processes, is there any website or extension taking up a lot of system resources?

In addition to that, you can try launching firefox in safe/troubleshooting mode. 3 bars in the top right > Help > Troubleshooting mode

This restarts firefox with all addons, extensions, and themes disabled.

For further troubleshooting, also try:

Go to about:profiles, and create and launch a new one. This is a more complete reset, since it also resets all settings, about:config options, and similar.

After creating a new profile, you can play around with rebuilding your current firefox config, adding extensions and changing settings.

Certbot?

It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.

https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins

Example tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot

Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.

If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: https://docs.ansible.com/projects/ansible/latest/index.html

One thing I read about is that Ubuntu provides unattended updates, so it can automatically update packages and restart the server (that seems a bit too far ;) ). It’s probably possible on Debian but not out of the box.

Ubuntu automatically has unattended upgrades, which makes I think makes it a popular choice for VPS providers to push (beyond being popular in corporate/institutions overall), since they don't have to worry about users forgetting security updates. However, it doesn't enable automatic reboots. But, it does look like automatic restarts of services updated via unattended upgrades is done, but only as of Ubuntu 24.

Another thing to note is that Ubuntu has updates that are explicitly for security, and then everything else, including more general bugfixes and program updates with additional features. By default, unattended upgrades on Ubuntu only do security updates.

Of course, both a unattended upgrades and automatic reboots are possible on Debian (same software, Ubuntu just preconfigures it), although default configurations can vary. I wouldn't be suprised if a VPS provider was shipping a default Debian configuration that enabled automatic upgrades.

On Debian, for the most part, ALL updates are only for security issues or severe bugfixes (program crashes or the like). Debian, for the most part, doesn't do minor bugfixes at all, or do program feature updates. I prefer this model, since it's easier to manage than having separate types of package updates. It ensures absolute stability, a guarantee that the system tomorrow will behave the same as it did yesterday, while still enabling automatic security updates. This model is ideal for a server I don't want to babysit, or for your grandpa who loses his mind when the button he is supposed to click was moved one spot over.

In addition to that, I like the policy of automatic reboots. With the stable, slow moving nature of both distros, it's safe to automatically reboot to ensure that kernel vulnerabilities, or vulnerabilities in other critical systems are fixed. Automatic updates and reboots can be the difference between someone being able to escape a docker container or someone not being able to.

There is one thing to note, is that adding additional repos (or PPA's which technically you aren't supposed to work on Debian), can be dangerous, and you have to be careful: https://wiki.debian.org/DontBreakDebian/#Don.27t_make_a_FrankenDebian

The main problem is that if a third party repo and Debian provide the same package, and the system is configured to prefer the third party repo, then you can be installing a potential dependency to the rest of your system that isn't actually tested against your system, or compatible.

You have to be really careful to ensure that the programs in the repo are actually built and designed for your system, and also that the your system does not default to installing them.

Third party repos also break the guarantee of stability that automatic updates depend on. Third party repos don't have a separate security channel, so Ubuntu will probably avoid touching them, even if critical security fixes are needed. Debian will update them, but unlike Debian's packages, the overall program updates won't be guaranteed to be behave the same due to potential major/minor version changes.

For example, if you get Docker from docker's repo instead of Debian's/Ubuntu's, now your version of docker can no longer auto update and receive potential security fixes safely.

Overall, I prefer Debian but Ubuntu is fine. If I was in an environment that used Ubuntu already, I would also just use Ubuntu. If you are already using Debian, then Debian is probably preferable.

Lots of rambling in this comment. Solution below the heading.

From a security perspective of limiting privileges it doesn't quite work. If they can run apt install then they can install a malicious hand crafted package, that has an install script that runs with root privileges, or enables a systemd service or so on.

From a preventing users from doing stupid stuff, it mostly works. Of course, there are still ways it can break, like when Linus Tech Tips typed in yes, do as I say when apt had a bug and refused to continue because it suspected that something would break and then Linus did it anyways...

But it will mostly work.

I want users to be able to install apps, but only from the the gui software manager and apt install in the terminal.

Firstly, I want to mention that flatpak does not need root and can work without root. So if the goal is to have users be able to install apps from the app store, you could remove non flatpak apps from the GUI, and then they would be able freely install and remove apps from the GUI app store. They can also use the flatpak cli, but it's more difficult to use.

Secondly, I agree with the other commenter. It's probably way easier to make a backup, or use syncthing, and just give them root if that getting them apt packages the goal. If you do something like automatic btrfs snapshots (which Linux Mint has support for), it mostly gets you to the goal of "I don't want a privileged user to break their system", since it is easy to walk them through booting into an older snapshot over the phone.

If your goal is actual management of apt programs, then the specific problem you are encountering is that there are two methods of authorizing to root, and you have configured only one of them so far. There is sudo, which governs cli programs, but there is also polkit, which governs GUI programs. Polkit has a cli command that has a similar feature to sudo, pkexec, which you can use for testing configuration of polkit.

Since it looks like you got sudo working I won't waste time on that. Here is a nice intro from Red Hat:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/policykit

Hmm doesn't have what I want. (I am figuring out as I go).

Okay it looks like the GUI stuff is powered by packagekit, which is an actual daemon: https://en.wikipedia.org/wiki/PackageKit (I thought it was just a library/interface), that runs as root. You can use the pkgcli to interact with it from the command line, and it still uses polkit.

Okay here is the relevant policy file: https://github.com/PackageKit/PackageKit/blob/main/policy/org.freedesktop.packagekit.policy.in

Solution Here

Polkit rules are written in javascript, so you would want a rule that's something like:

polkit.addRule(function(action, subject) {
    if (subject.isInGroup("GROUPNAME") &&
        subject.local &&
        subject.active &&
        action.id.startsWith("org.freedesktop.packagekit.")) {
        return polkit.Result.YES;
    }
});

And put this in /etc/polkit-1/rules.d/10-enable-rootless-packagekit.rules

This does read from the local unix groups, not active directory groups, meaning you have to ensure it's present there, and also have the exact name, which is not used in the sudoers file example above.

if you run getent group, then it should be exact name of the group in that list.

What made moodle frustrating?

I have also heard the opposite take, that canvas sucks and moodle is great.

Did you use it as a student/user, or as an administrator?

There is also moodle.

Canvas and moodle are really popular in schools and universities.