• 0 Posts
  • 11 Comments
Joined 3 months ago
cake
Cake day: June 30th, 2025

help-circle
  • I fully flipped over every device in my house off windows about a week or two ago, and so far so good!

    I’ve been daily driving linux on my personal laptop since 2009 (16 years now!?) for school / work / personal work-esque stuff, and my work laptop is now OSX. A few weeks ago I flipped my gaming machine from windows to popOS and been quite pleasantly surprised at how well gaming on Linux is these days. So much so, I convinced my wife to let me flip her gaming machine to Linux as well.

    The only hiccup I’ve recently had was having to deal with windows-only, non-steam software. Ie. insta360. Luckily, there are compatibility layers / emulators I can use to be able to run it. It’s slow, but good enough.

    At this point, there’s no good reason for me to go back to Windows or anything Microsoft. It’s even become a red flag when I hear a business is using Microsoft’s products. I want to hope Microsoft gets a wake up call at some point soon and turns the ship around, but I think they’ve got too many big-company deals to have to worry about their consumer products being shite.




  • I was thinking OP could give everyone their own VM to use as a workstation so they could access the files on the server easily, and/or run programs based on their work. When their coworkers leave, OP can easily destroy the VM and the resources would be automatically reallocated (depending on the servers configuration). With a physical device, the storage on that device is only allocated to that device and can’t be shared when it’s not in use

    Me, personally? I have multiple VMs for different contexts: my teaching job (super clean, video sharing tools, presentation tools), gaming, media server (has scripts to download stuff off of YouTube), server management (just a regular Debian install), and a fuck around box (I just use it to try new OSs like Fedora, or try breaking OSs like deleting the system32 folder on windows)






  • I haven’t gone through your specific case, but generally what I do when doing a major update with potentially breaking changes:

    • Read the upgrade guides, if they have them. Some devs will put them out if they know their users will encounter issues when upgrading. If they don’t have an upgrade guide, there might be some in the change logs. Going from 1.17.1 to (assuming) 2.x.y, check the change logs at 2.0.0.
    • Backup everything. I’d recommend doing this on a regular basis anyway.
    • (If you’re running it in a docker container) Setup a second instance, restore the backup, then run the upgrade. You’ll be able to check to see if it breaks at all. If it works, you can just destroy the old one and use the new one
    • (if you’re not running it in a container) with the backup, try upgrading. If it breaks, you should be able to uninstall & reinstall the old version, then restore the backup

  • I haven’t gone through your specific case, but generally what I do when doing a major update with potentially breaking changes:

    • Read the upgrade guides, if they have them. Some devs will put them out if they know their users will encounter issues when upgrading. If they don’t have an upgrade guide, there might be some in the change logs. Going from 1.17.1 to (assuming) 2.x.y, check the change logs at 2.0.0.
    • Backup everything. I’d recommend doing this on a regular basis anyway.
    • (If you’re running it in a docker container) Setup a second instance, restore the backup, then run the upgrade. You’ll be able to check to see if it breaks at all. If it works, you can just destroy the old one and use the new one
    • (if you’re not running it in a container) with the backup, try upgrading. If it breaks, you should be able to uninstall & reinstall the old version, then restore the backup

  • I usually only keep documents and media. Programs can be redownloaded and reinstalled (and it might be better to reinstall them in case you move to a new OS anyway to ensure compatibility).

    For docker specifically, only keep stuff that’s specific for your instance; which you normally setup as an external volume anyway. Docker is designed such that you should be able to nuke the container, and all persistent data is restored via an external volume on the host. If you’re not doing that, you should immediately go and set that up now (to get the data out safely, setup a volume connection such that the container path is new - that way you don’t accidentally destroy what’s there, copy the stuff you need out, then readjust the path so it’s correct)