

Just because they don’t know what it is doens’t mean your school doesn’t have it. My school is similar. They get VDI by partnering with an external organization.


Just because they don’t know what it is doens’t mean your school doesn’t have it. My school is similar. They get VDI by partnering with an external organization.


First thing you should check is if the school offers VDI - Virtual Desktop Infrastructure.
My college has VDI, where you can access a GPU accelerated Windows machine from your browser, preinstalled with tools like Autocad, Photoshop, and other stuff.
If your school doesn’t, then you should look at options like VM’s. The problem, however, is that CAD and a lot of other software is GPU intensive, and simply using it in a VM might be too slow for practical usage.


Okay, I hath returned.
So I used to play a game called krunker.io. It was browser game, but I would use a native, electron based client. I spent a lot of time tinkering to figure out what options would maximize performance, and because I had a laptop with an Nvidia gpu, a few special flags were needed. Here was the full command that I would run to run the client:
gamemoderun prime-run ./crankshaft-portable-linux-x86_64.AppImage -no-sandbox --ignore-gpu-blocklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy --disable-gpu-vsync --disable-frame-rate-limit --ozone-platform-hint=wayland > /dev/null 2>&1
You probably don’t want gamemoderun. But you can play with the rest of the flags there. I don’t remember what was needed and what was there for performance. I’m pretty sure that the first two arguments there were needed though.


I don’t think anubis can proxy webdav. So that breaks.
Instead of putting anubus at 443, put it at the port 80 block. Or at the 5555 block.
What you probably need to do is make it so that webdav traffic isn’t proxied through anubis.


I know this issue, I had a similer issue trying to get the client for krunker.io working with my nvidia gpu. I might have the solution saved somewhere, this comment is so I can remind myself to check.


Yes, but there is something important to remember.
By default, most Linux installs put there kernels in /boot, which is not on the btrfs partition. This is not an issue on distros that keep multiple kernel versions, but it can cause issues on distros that only provide one kernel version (Arch and Arch based distros).
Because the kernels are not stored on the btrfs partition, they are not restored by btrfs snapshots. And if the rest of the system, including kernel modules, are a mismatched version due to restoration, then it means your system is unbootable.
A simpler fix is to install ArchLinux’s linux-tls package, which is the stable version of Linux that doesn’t update constantly.
But what I do to get around this, I put /boot on the btrfs partition, and /boot/efi is the seperate efi partition where grub is installed. Then, kernels are restored when I restore a snapshot.


https://training.play-with-docker.com/
This is an interactive, guided docker course in your browser.
Of course, docker is easy to install and use on a Linux system.
Okay, I hath returned. Here is what I am doing with FLuxCD and it’s method of installing helm charts:
Okay, I’m cheating. :/ . I’m using Flux’s method where you can have a secret that has values, and then I’m just including those.
But yeah, using an ENV var that pulls from a secret is probably better.


I would say the big thing that might give you trouble is not the init system, but NetworkManager. NetworkManager is the… network management software (wow who woulda guessed?) used on desktop linux distros.
People have many criticisms of it, that are similar to criticisms applied to systemd (it’s also Red Hat software), so I see my friends switching to iwd, wpa_supplicant, or other alternatives when trying something other than systemd as well.
It gives them a lot of pain. None of the other alternatives are as reliable as NetworkManager when it comes to connecting to Wifi. Switching away from Systemd shouldn’t be too hard, but NetworkManager is much tougher to give up. Thankfully, you can run NetworkManager on non-systemd setups.
This is a message to remind myself to share my config later.
I will state that I a, using cloudnativepg for postgres.


The way forgejo actions works, is that it is not a universal thing for every repo. Each repo, can have it’s own forgejo actions instance connected to it, running stuff.
The big benefit of that, is that you can make users bring their own actions servers, and not bother to deploy your own.




Void auth, or kanidm look like easier alternatives.


Debian repos are basically guaranteed safe: https://programming.dev/comment/22863237
Flathub is much, much safer than say, the google play store, but it ultimately does follow a model of app developers submitting packages which get reviewed and approved. In theory, someone could sneak malware past that, although there haven’t been any incidents (perhaps flathub’s review is very effective?). But the snap store, which follows a similar model has had malware. But canonical hasn’t been the best steward of that one.
In addition to this, not all stuff on flathub is open source, which is definitely concerning.
Thankfully, flatpak has a built in sandboxing system, which lets you limit what the appps have access to. KDE has a UI for it, and there is also the GUI app flatseal.


malicious code does occasionally sneak into Debian distributed apps
Do you have an example of this? The xz utils backdoor did not make it into debian stable, only unstable.
Debian stable essentially forks every package, maintaining a custom codebase. They then cherry pick security updates only (ignoring feature updates or minor bugfixes), and applying those. This makes it extraordinarily resilient to any form of supply chain attack.


Flatpak’s show up in discover, and aren’t by the distro. Usually it’s flathub.


Journalists communicating with sources in censored regions
Whistleblowers sharing information securely
You and your peer agree on an encryption key (any string).
This is unacceptably unsecure for the usecases you mention. There is a reason why the most secure messaging apps don’t use symetric encryption, don’t use passphrases, and they also possess forward secrecy.
It’s pointless to push this as a censhorship circumvention method when many other methods exist that already do so 10x better, in a secure way, over decentralized, hidden and unblockable infrastructure. (Tor’s meek-azure bridges use microsoft’s infrastructure, which nobody is able to block because everybody depends on it, even China).
I appreciate the project, and I am always happy to see people learning, progressing, and publishing their results, but you need to be honest about the weaknesses of your software compared to established solutions. It’s not impossible for you to one day produce a secure messaging app, but today is not the day. Right now, using this is just a fast way to get killed.


somewhat relevant: https://en.wikipedia.org/wiki/Shadow_IT
I think they have a lemmy account as I first saw them here, although I don’t think OP is the site author.
Their javascript “game in less than X lines” stuff is pretty interesting and entertaining but their blogposts are mostly LLM slop. Of course, due to the fact that this article is just basic info, it’s not that bad and is pretty accurate. But their more advanced blogposts begin to fall apart and have the LLM hallucinations, outdated info, and inaccuracies.
This video: https://www.youtube.com/watch?v=40SnEd1RWUU has similar information (though a bit less and doesn’t cover some things), but presented in the style of a comedy skit type thing.