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.
the physical display output is claimed by something else totally separate.
Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It’s possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being “headless”, and not shown.
I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I’m running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.
Do you actually need the headless backend? Or do you need a background session that doesn’t interfere with the main session?
Second comment:
https://docs.lizardbyte.dev/projects/sunshine/v0.21.0/about/guides/linux/headless_ssh.html
There is also this guide, but it is specific for Xorg and Nvidia gpus. But I suspect that if you replace the startx here with startplasma-wayland or dbus-run-session startplasma-wayland, then it will work. It would still be nvidia gpu specific though.
If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run dbus-run-session startplasma-wayland, does that work?
Sometimes just startplasma-wayland works, which used to work for me but didn’t work for me this time.
Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.
Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.
EDIT: I only am somewhat confident that this setup will work, I haven’t tested it personally.
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.
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
https://libregamewiki.org/Roguelike_games
There are more games on there, but I have been meaning to try the roguelike stuff out.
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.
Built-in live preview for HTML
Only in electron based editors AFAIK. It requires an integrated browser engine, and electron already is an integrated browser engine so that makes it easy.
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.
One potential workaround is probably to use a download manager, that supports more advanced and nuanced control over how the files are downloaded.
Here is what I have used in the past:
https://github.com/subhra74/xdm
https://addons.mozilla.org/en-US/firefox/addon/xdm-browser-monitor/
The browser extension hijacks firefox’s download function, so that when you download a file, it instead connects to XDM, and offers to download that there.
It also offers save and resume functionality, so if it dies in the middle you can resume.
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:
Technically you could find alternate repos, but this is the kind of thing that should be mentioned on pages like this.
It looks like KDE and linux mint have the ability to auto unlock and mount drives, according to this bug:
https://bugs.kde.org/show_bug.cgi?id=466731
Probably a feature of the desktop environment.
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.
That’s a lot of stuff. Are you sure you can learn it all at once?
Anyway, I would highly recommend finding local software meetups to attend. You can sites like meetup.com, or luma or eventbrite to find them. You can also try to hunt down websites made by other people that might document it.
You can also try these, although they are focused more on cybersecurity:
https://wiki.hackerspaces.org/List_of_Hacker_Spaces
But definitely try to engage with the community near you. It will help you stay motivated, and you’ll learn a lot.
Yes, although there have been a few CVE’s related to escalating privileges or breaking out of the sandbox. You’re going to want to keep those updating and keep on top of those.
There is one concern, in that the nix store (
/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.
My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day’s. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.
Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.
And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn’t have enough value (assuming of course, your research isn’t too valuable and worth targeting), and you mostly don’t have to worry about it.
Sure, people will root it. But then they’ll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.
However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux’s user based isolation.
The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.
In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host’s performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU’s usually support it though.