Skip Navigation

Help me choose linux's best option for public school lab (distro, desktop, etc.)

I apologize if my english isn't perfect in how you would say it daily, but I hope it'll help with Linux popularity and as a reference for future days.

For this post specifically I want opinions regarding what would be best for school lab of tech vocational high school (for both computer networking and software engineering).

  1. Package update frequency:
  • A. Years per update (Debian, OpenSuse Leap)
  • B. Every 6 month (Ubuntu/Fedora)
  • C. Rolling Release (Debian Sid or Arch but update whenever (every week/month/semester/year))
  1. Desktop environment:
  • A. Gnome
  • B. KDE Plasma
  • C. Cinnamon
  • D. Lightweight DE (XFCE, LXQT, etc.)
  • E. Other DE (Mate, Budgie, etc.)
  • F. Stacking Window Manager (Fluxbox, IceWM, Openbox, etc)
  • G. TIling or Dynamic WM
  1. Community or Company Distro?
  • A. Community Distro
  • B. Company Distro
  1. Display server protocol:
  • A. Xorg
  • B. Wayland
  1. File System:
  • A. EXT4
  • B. BTRFS
  • C. Other
  1. Immutable?
  • A. Not Immutable
  • B. Immutable
  1. Functionality
  • A. General Purpose (Debian, Arch, OpenSuse)
  • B. Specific Purpose (Debian Edu, Parrot Linux, AV linux, etc.)

Let me know your opinion, perhaps I missed some critical question or maybe some question above isn't that important to consider.

41

You're viewing part of a thread.

Show Context
41 comments
  • No idea where you get the idea from that it has to be proven and that it's somewhat unreliable and in beta. I get the impression you talk about something different

    • You don't put untested software in prod. You just don't. It might be fine on your machine but don't put on systems for others

      • Fedora Silverblue was released alongside Fedora 30, which was 5 years ago; it is not "untested", in fact it is quite extensively tested by its userbase. It also is not in beta as you claimed previously, its release with Fedora 30 was its full release, after the betas with Fedora 29. Atomic desktops have been around for longer than that, however. They are far more tested and reliable than you seem to be giving them credit for. In fact, they are far more stable and far more resilient because you can simply roll back changes when you boot. A few previous versions of the entire operating system are available to boot from in GRUB, and it's as simple as booting into a previous version if a new one has issues. It's actually the perfect use case for a school computer lab, because each install is perfectly consistent, can be managed and fixed easily if anything were to break (if that were the case then the OS would have broken in non-atomic versions anyway), and nothing the user does will affect the base image of the system. The base image doesn't change unless it is updated. You can overlay things overtop of the base filesystem, but the base filesystem stays the same, so those overlays can be easily reverted.

        • Fedora Silverblue was released alongside Fedora 30, which was 5 years ago; it is not “untested”, in fact it is quite extensively tested by its userbase.

          Your comment comes right after Fedora Atomic desktops and a few others were hit by a critical bug, where testing appeared to be missing : https://mastodon.social/@deflockcom/112247891318456315

        • Ansible can do all of that and its been tested for 20 years. Maybe I'm just reading into your comment but it sounds like you are getting upset.

          Traditional desktops are much simpler to manage and have more documentation. It would be really cool if immutable desktops became more mainstream but for now they are only a glimpse into what could be. Even uBlue says its in beta.

          • I'd like to clarify that I didn't intend to portray any anger in my comment, I'm sorry if it came across that way. Text is notoriously difficult to convey emotion and intention through without purposefully writing to convey it.

            With that said, I am a bit confused. I was not aware that Ansible had the ability to seamlessly roll back updates like an immutable distro, this could certainly influence my opinion. I don't have any personal experience with Ansible myself, so I suppose I'd have to take your word for it since a quick search online didn't provide any results. That would be very useful, indeed.

            As I have little experience with large scale deployment, I am unfamiliar with management software that could assist in managing large groups of computers. Would it be possible to use Ansible or some other sort of large scale management software in conjunction with an immutable distro? It seems like the management aspect of Ansible is quite useful and shouldn't be distro-dependent, so I'm unsure why it would be limited to mutable distros. I feel like that could perhaps get the best of both worlds, as it would allow for consistent deployment of atomic distros that have the ability to be automatically rolled back in the event of a bad update, even if they were to be otherwise rendered unbootable (since one of the selling points of immutable distros is that it's as simple as an arrow key down and an enter key press while booting to roll back to a bootable OS). Update rollbacks are also as simple as a single command with atomic distros. You don't have to find a backup to restore from, as the base image is basically organized with version control software (think Git or Subversion, where each update is like a commit/pull request). You can roll back any changes individually or as a group (you can roll back to the exact image you were at during the last successful boot, for instance).

            Immutable distros also have plenty of potential for globally shared applications through simple package overlays. The documentation on installing packages through rpm-ostree is fairly competent last I checked, and would be what you're looking for with globally installed apps like LibreOffice or Firefox. It just uses the normal Fedora repos for those packages. The actual install commands aren't different from any other package manager, at least in the sense that all package managers have slightly different syntax, but they have a similar base structure of being able to install/remove/update packages. The backend is unique, yes, but the presentation to the end user isn't far off from any other package manager. Of course, that comes with the caveat that you have to reboot after installing something through rpm-ostree, because the base image cannot be edited while booted in normal operation. User-specific apps can naturally be Flatpaks, as you wouldn't want users installing system packages anyway (if you even allowed installation permission, that is).

            You're certainly correct that traditional desktops have more documentation, and I suppose that since it is a change to the norm, it may be more work for someone experienced with mutable distros to learn how to manage immutable distros. I don't feel as if that is an issue OP is currently considering, though. They don't seem to have a whole lot of experience with large scale management of Linux desktops, anyway. Either option could present issues if mismanaged, but if all you need to do to fix something is to roll back a change you made, I feel like that makes immutable distros a little easier to fix (at least when the issue is caused by the user/admin).

            Also, I am unsure where uBlue claims to be in beta. I checked their site, and I didn't see anything about their products being solely beta packages. Yes, there are beta packages available (for instance, for Fedora 40 which is still in Beta as it hasn't released yet), but that can be said for practically any software. You can install nightly/beta builds for most packages if you so desire. If there's somewhere on the uBlue website that confirms your point, please feel free to provide it. I don't know a whole lot about uBlue, so I would genuinely be interested in knowing. I just know they're based off the Fedora Atomic desktops with some extra configuration thrown in, and the information readily available on their website.

            If you really wanted consistency with ease of deployment, NixOS is also an option. It just takes time to learn how to use its configs, and I believe the wiki is currently down pending a redesign (or so I heard from another post).

            I suppose I should clarify that I used Fedora Silverblue for about a year as a test drive, and when I got a new computer I installed basic Fedora Workstation back on it. Immutable distros are particularly difficult for me to use because I do a lot of low level changes that would require a lot of complicated overlays, but I'm not the average user. I'll give Fedora Atomic KDE a shot when Fedora 40 releases, but I've always imagined that the ideal scenario for atomic distros is in applications prone to breakage (like school labs where students might mess around doing something that causes issues accidentally), and situations where you want to have large scale management of computers and ensure they all behave exactly the same (though I suppose that's the draw of Ansible as well). Atomic distros' main selling point is fixing breakage and remaining stable and reliable (with failsafes you can fall back on when necessary).

            I suppose I don't have the experience to really conclude whether or not the benefits outweigh any potential costs, though. I am mostly unaware of how large scale management software works, so maybe there would be a lot of disadvantages I don't immediately see, or perhaps the advantages themselves aren't as great as they seem in my head. I chimed in because I felt like the Fedora Atomic distros were being misrepresented. For instance, they aren't in beta, and while they lack the testing of something like Debian, as the community grows, so does the testing userbase. I think that they are an interesting option with distinct benefits, but that of course doesn't mean that they are the best option.

            • Immutable distros aren't bad and can be a good thing. I just think it will take time before they are able to be troubleshooted by someone who may not be all that familiar with Linux.

              Maybe I'm just hesitant to use something I don't understand. As far as updates go theoretically you shouldn't need to roll back if your testing is good enough. Reliability is why you use something stable and review each update before deploying. There needs to be a testing and validation pipeline for each update. Then again, that is not really possible for a one man team. In that case I would recommend setting up a generic image that spins up and creates a new machine id and keys before getting taken over by Ansible automation.

              This is the kind of stuff that is used to admin thousands of VMs. Maybe it is simpler to use immutable distros but I haven't heard much from people who use them.

              Overall I think I'll give them a shot in a VM. As for the user asking for help I'll just let them decide what's best for there needs.

              If you have more than a handful of VMs Ansible is the answer

41 comments