This is great, Locomotion was a good game in its own right. Hopefully this will be an opportunity to change and fix the game a little going forward - its a game that never quite reached its full potential although already a good game.

Thanks for sharing! I’m going to download it and try it with my gog version. Its 80% off now on fog now BTW.

Unless you’re specifically wanting to play with a different OS then Debian again. Makes much more sense to be using the same version of Linux and all the software ypu use rather than potentially different versions.

Also it will be simpler to maintain as everything is the same.

If you do want to play / test another distro then Mint has a low learning curve. FreeBSD is more different but you could easily try it and switch to something else if you don’t like it. Its different but not so much that linux users would feel totally lost.

Probably the most confusing thing for linux user trying FreeBSD is that Bash is not installed, and BSD uses sh instead by default. Bash can be easily installed and set as the default shell which will give a lot more familiarity. But otherwise it’ll feel like a familiar modern complete system, and you can use the same desktop environments you’re familiar with already in linux.

EDIT: You did say “backup” in your title. If that’s the main use case then definitely Debian again. If your laptop breaks or is stolen it makes sense to have a familiar system to pick up. Also important to sync and backup your data so it can be picked up on the other laptop. If backup machine is your focus then I’d say same OS and look more into data retention and retrieval between the two laptops, and ensure your important data is continuously backed up.

It kind of makes sense except the vast majority of software in all distros is not being packaged by the developers, its being packaged by volunteers in the relevant project. Most software is being used on trust that it is built off the original code and not interfered with.

Its very difficult for any distros to actually audit all the code of the software they are distributing. I imagine most time is spent making sure the packages work and don’t conflict with each other.

The verified tick is good in flatpaks but the “hide anything not verified” seems a little over the top to me. A warning is good but most software is used under trust in Linux - if you’re not building it yourself you don’t know you’re getting unadulterated software. And does this apply to all the shared libraries on flathub? Will thebwarn you if your software is using shared libraries that ate not verified?

And while Flatpak is a potential vector to a lot of machines if abused, it is also a sandboxed environment unlike the vast majority of software that comes from distros own repos.

Also given the nature of Flatpaks, any distros could host its own flatpaks but everyone seems to use flathub. If they’re not going to take on the responsibility of maintaining flathub and its software then their probably needs to be some way of “verifying” packages not coming directly from the developers. Otherwise users may lose put on the benefits of a shared distros agnostic library of software.

I get why mint are doing this but i think its a bit of a false reassurance. Although from mints point of view they would be able to take direct responsibility for the software they distribute in their own repos (as much as you can in a warrentyless “use as your own risk” system)

You can keep windows and install Linux next to it.

The best way would be to add a new ssd or m.2 card to your pc and install Linux on that. Make that the main boot device and Linux normally will detect Windows and give you a boot menu where you can chose between Linux and Windows each time you boot.

Alternatively you can resize the windows partition and install Linux onto free space on your main drive. This is more fiddly and things can go wrong with this if you don’t know what you’re doing.

You can also boot Linux on an external USB drive but this will be slower and may guge you a false impression of Linux. You can also try Linux in a virtual machine like Virtualbox but again this will be slower and will give you a false impression of Linux as a daily driver OS.

I personally run a dual boot system - I have two m.2 nvme drives, one with windows and one with Linux. I barely use the windows partition now but I keep it around for rare work stuff or the rare occasion I have a game I can’t get to run in Linux. And I mean rare - booted Windows maybe 3 times in last 6 months.

PPAs are flawed and limited to the Debian/Ubuntu ecosystem. They’re a security issue as you really need to trust to the person or group who has set up the PPA (yet many people just added PPAs for all sorts of random software based on a Google search). They need to be maintained which is variable depending on the size of the project and for developers they’re only a route to support part of the entire Linux ecosystem. They can also conflict with the main system provided packages and repost which can break entire systems or break upgrades (happened to me on Mint, and I needed to do a complete system reinstall to remove legacy package conflicts).

They’ve fallen out of fashion and rightly so.

There are other ways to get software to users. Arch has its AUR which is basically a huge open repo. OpenSuSE has its OBS which is also a huge open repo. These are also not without their risks as it’s hard to curate everything on such an expansive repo. However others can take over packages if the original developer stops updating them, and you can see how the package was built rathe than just download binaries which allays some security concerns. They are also centralised and integrated into the system, while PPAs are a bit of a free for all.

Flatpaks are a popular alternative now - essentially you download and run software which runs in a sandbox with its own dependencies. Flatpaks share their sandboxed dependencies but it does lead to some bloat as you’ll have system level libraries and separate Flatpak versions of the same libraries both installed and running at the same time. However it does mean software can be run on different systems without breaking the whole system if library dependencies don’t match. There are issues around signing though - flathub allows anyone to maintain software rather than insisting on the original devs doing so. That allows software to be in a Flatpak that might otherwise not happen but adds a potential security risk of bad actors packaging software or not keeping up to date. They do now have a verified tick in Flathub to show if a Flatpak is official.

Snap is the Canonical alternative to Flatpak - it’s controversial as it’s proprietary and arguably more cumbersome. The backend is closed source and in canonical control. Snaps are also different and for more than just desktop apps and can be used to in servers and other software stacks, while Flatpak is focused only on desktop apps. Canonical arr also forcing Ubuntu users to use it - for example Firefox only comes in a snap on Ubuntu now. It has similar fundamental issues around bloat. It has mostly the same benefits and issues as Flatpak, although Flatpaks are faster to startup.

Appimage are another alternative way to distribute software - they are basically an all-in-one image. You are essentially “mounting” the image and running the software inside. It includes all the libraries etc within the image and uses those instead of the local libraries. It does and can use local libraries too; the idea is to include specific libraries that are unlikely to be on most target systems. So again it has a bloat associated with it, and also security risks if the Appimage is running insecure older libraries. Appimage can be in a sandbox but doesn’t have to be, unlike Flatpak where sandboxing is mandatory - which is a security concern. Also Appimages are standalone and need to be manually updated individually while Flatpaks and Snaps are usually kept up to date via an update system.

I used to use PPAs when I was still using Ubuntu and Mint. Now I personally use Flatpak, and rarely Appimages, and occasionally apps from the OBS as I’m on OpenSuSE Tumbleweed. I don’t bother with snaps at all - that’s not to say they don’t have value but it’s not for me.

Edit: in terms of permissions, with Flatpak you can install Flatseal and manage software’s permissions and access per app. You can give software access to more locations including system level folders should you need to or all devices etc for example. I assume you can do the same with snap but I don’t know how.

Also you can of course build software form source so it runs natively , if you can’t find it in a repo. I’ve done that a few times - can be fiddly but can also be easy.

Jellfin can be configured to use specific installed versions of ffmpeg.

If you do need the jellyfin-ffmpeg (which is needed in specific installs) then you can download releases from github or build it yourself. They do have portable releases.

You do not necessarily need root access to use software on Linux unless you’re trying to install it to be available to all users. Users can often install their own software either binaries or compile themselves (unless the system has been locked down). They could sit within your /home/username/bin directory instead of the system level folders like /usr/bin normally used for non-root executable. Your home bin folder is only accessible and so runable by you, and is viable if you do not have access or permission to install into /usr/bin.

You can configure jellyfin to run within your home bin folder or run other software within that folder.

You can get the jellyfin ffmpeg source and releases including portables from their git: https://github.com/jellyfin/jellyfin-ffmpeg

As a software developer you should have a bit of a head start - you can read the code - one of the big pluses of open source projects is it’s all there in the open. Even if not familiar with the specific language used you can see the source and get a rough idea of scope and complexity.

And look at the Github details like the age, the frequency between releases, commits, forks. Malicious projects don’t stick around for long on a host site like that, and they don’t get 1000s of stars or lots of engagement from legitimate users. It’s very difficult to fake that.

Look at the project website. Real projects have active forums, detailed wikis, and evidence of user engagement. You’ll see people recommending the project elsewhere on the net if you search, or writing independent tutorials on how to deploy or use it, or reviews on YouTube etc. Look for testimonials and user experiences.

Also look at where the software is deployed and recommended. If it’s included in big name Linux distros repos thats a good sign.

Look at all the things you’d be looking at for paid software to see it’s actually in use and not a scam.

And try it out - it’s easy to set up a VM and deploy something in a sandbox safe environment and get a feeling if it does what it claims to do. Whether that be a cut down system with docker or an entire OS in the sandbox to stress test the software and out it through its paces.

There are so many possible elements to doing “due diligence” to ensure it’s legitimate but also the right solution for your needs.

There is no reason other than greed that tech companies have to have their fingers in so many pies. Regulators could split Google up - search separated from ads and separated from other services.

It’s not the size so much as the breadth of it’s influence. We’ve gotten used to the idea that tech companies like Google and Microsoft do everything. But they’re only doing everything so they can get at every bite of our data. An email service doesn’t need to be run alongside a search engine or a news aggregator or an ad company. And certainly doesn’t need integration between all those things.

Maybe missing something but it seems like it mostly adds fancy animations like zooming out the desktop and sliding items around.

It looks nice but it looks like quite a superifical redesign of edit mode? But in fairness it may feel more effective in use.

But my issues with edit mode are not the ones described in the short post, so probably why it doesn’t speak to me much.

It’s basically GNOME specific version of GTK4. There are various issues that arise from that but one of the main ones is that it is not themeable at all at present. The GNOME adiwaita theme is built into the library and is the only theme.

It is supposedly going to have a themeing system but it will still break with existing GTK themes.

As the Mint blog alludes to, it also embeds fundamental UI choices that may make sense for GNOME but may be jarring or out of place in other desktops such as Cinnamon, or XFCE. They cite the example that GNOME could unilaterally remove the minimise button from the apps because it’s not something that exists in GNOME.

There is a concern that it effectively breaks the existing app ecosystem and will deviate further and further from the established GTK norms. To be fair is kinda what it’s supposed to do - I think it’s it’s supposed to be a better replacement that allows GNOME to forge it’s own path.

Edit: worth noting that the Mint blog post says they could make their own theme within their own version of the library but it could only fit with one GTK fheme. So it can be customise in a limited distro level way but still can’t follow the basic themeing across the desktop if you chose anything else (at present).

I’ve found the opposite as an end user with Flatpaks. It makes it easy to install an app on multiple devices with different Linux flavours and it’ll just work.

Even if you’re on a single device, if the app isn’t in your repo or the latest version is not available in the repo, then flatpak can be very convenient. Certainly easier than compiling from source.

It is secure in the sense that it runs in a sandboxed environment with its own libraries. The downside of that though is bloat as you will have duplicates of libraries you already have on your system downloaded for flatpak. That bloat diminishes to an extent the more apps you use as the apps will share and reuse the Flatpak downloaded libraries, but your first app could be 2gb just because of the libraries and dependencies.

That bloat also extends to memory - you might be running two copies of multiple libraries at a time - one for the native system and another for the Flatpak app.

So on the one side it’s convenient and allows distributions across all flavours of Linux, and it sandboxes apps which is potentially more secure but the downside is bloat, and resource use.

Ubuntu have gone too far with Snap, forcing it instead of providing native apps, and it’s proprietary. Flatpak is more open and an option for users rather than forced on them.

I don’t know the answer for definite but my assumption is because of the nature of modern websites. Most websites are not static, but rather complex mixes of static and dynamic content including various scripts running on the page. It seems like that would be complicated to duplicate, particularly without breaking something. A script running could easily break and throw unexpected errors if it’s not duplicated seamlessly in memory.

I guess also as a result if Firefox duplicated everything perfectly from active memory, the onus is on Firefox to fix it if something breaks on some random website. If Firefox reloads the page in the duplicated tab, then the onus is on the website if something doesn’t work in duplication. It’s a fundamentally simpler technique and more replicable every time.

However as I say I don’t know for definite. I do find Firefox does a reasonably good job of duplicating tabs in the current set up; I’ve not been aware of significant issues with websites and for me at least it’s the starting from the same sort of place and having the history available that is most useful.

Passively aggressively helpful.

Start by checking what windowing system you’re using as its a fundamental part of problem solving. It’s a little confusing how to do this, the top answer in this Stack exchange thread works well.

If you’re running the latest KDE then you’ve almost certainly been moved to Wayland and that will be the source of your problems. Wayland and Nvidia drivers don’t work well together, and KDE have defaulted to Wayland in the latest release. I have had very similar issues to you with the move to wayland and have not been able to fix them - they’re too fundamental and depend on updates to wayland and/or Nvidia drivers.

I know you don’t want a solution but there isn’t one at the moment, so you’d be wasting your time. The solution is to log out, then on the log in screen select Plasma (X11) as your session and log in again.

Personally I have had to abandon KDE as I get a different set of problems in X11. I’m on OpenSuSE Tumbleweed so have little choice inrolling back to the previously functioning version of KDE - I’m using Cinnamon instead and contemplating switching to a different Linux distro, probably OpenSuSE Leap in favour of stability over cutting edge.

Meanwhile I have the latest KDE running on another device with AMD GPU without issue.

In terms of when it’ll be fixed, there is a change being made to Wayland which will effect how it and the Nvidia drivers interact (something called Explicit sync). It’s just been merged into wayland so presumably will appear downstream in the coming next few months in rolling distributions. There have been articles suggesting this is going to fix most problems but personally I think this is a little brave but fingers crossed.

If you’re running Linux you could just have different logins to either your main desktop or within one VM running linux.

Each user login would have their own separate home directory, own profiles for Firefox and Thunderbird, or any other tools you use. But at the same time all apps you’d install would still be available to all accounts and kept secure and up to date with the VMs system updates.

As you’re using mint as your main desktop and if you’re not very familiar with linux, I’d just run Mint within a Virtualbox VM, probably XFCE edition of mint. That way techniques you use in your main desktop work the same in the your VM, albeit with a slightly different interface with XFCE. Once you’re more familiar with Linux you could look at other techniques? If you’re familiar with Linux then KVM would be an alternate route for virtualisation, albeit very similar in this scenario.

There are methods to run portable apps in Linux (such as Appimage) but the real key is keeping profiles separate. You could also do all this by having separate Firefox and Thunderbird profiles and set up links to run the software with the specific profile you want. Again this could be done with a VM if you want to contain all this in one place, or on your main desktop (either in your Linux profile or a dedicated work profile to separate it out more cleanly from your personal files). You’d get less overhead via this route in terms of hard drive space an RAM/CPU usage. You’d literally just have separate shortcuts like “Website 1” which runs the command “thunderbird -P /path/to/website1/thunderbird/profile”.

I work in the NHS and I wish we’d move to Linux.

The reasons we didn’t are historically due to legacy apps that were Windows only proprietary. We used to have software in different departments of different ages - literally we had a tool that went back to the 1980s (needed telnet to run).

We recently upgraded to a single uniform EPR platform and pretty much most if not all our legacy apps got replaced. Most of what we do now is either via the EPR (which runs in a streaming VM or via a Web client), or Web apps.

So we could switch to Linux. But we probably won’t - we still have inertia - IT are familiars with running windows and all our software is configured to run on Windows or authenticate using Windows domains. It’d take effort to unpick that and fix it.

Also we use Microsoft Office throughout - while that can also be web based, that would also disincentivise the switch. Having to train every member of staff (particularly the less tech savvy staff) to use a different office system would probably put off anyone in IT considering it (although I think for hospital uses its perfectly doable). Deploying office 365 via browser is doable but effort.

So previously it was legacy apps (which will still be the issue in many places, we’re unusual to have consolidated so much to one EPR platform - even among customers of the EPR) but now it is inertia. I can see no decent reason why we could not switch entirely to Linux. It’d come down to the cost savings of dumping windows licenses / ecosystem versus the alternatives including the cost of retraining and rebuilding infrastructure.

Edit: also even if we were to replace our desktops with Linux and Web interfaces, at the backend some tools are Windows server based. And it’d be up to the software suppliers whether they actually have a Linux client for our EPR or Pacs system, even if they are supposedly using Web interfaces.

Makes sense - PPAs are very platform specific, plus from a user point of view a bit of a security nightmare (not the Kodi PPA but the idea of adding lots of different PPAs, often poorly named and difficult to keep track of as a user).

I used to get fed up with PPAs when I used Ubuntu - particularly when you to go through a major distro upgrade and you have to go hunting through all of them to see if they support your new distro version. They’re just not a good distribution system for most users.

Also the Flatpak will benefit more users across other systems and has the potential to be more secure (particularly given the add ons people download and run in kodi).

Edit: worth noting they have retired the PPA but haven’t built out all their equivalent Flatpak versions. An example of the unpaid hard work and hours volunteers put in to maintain open source software.

It’s basically a privately hosted repo with a very small set of programs/libraries. PPA is a Personal Package Archive.

If you run Ubuntu (or most Debian derivatives) you can add a PPA as an extra repo and the version of software in that repo will usually be newer than the versions maintained by the distro (or even not present in the distro).

It’s not quite like the AUR - the AUR is a central public repo that people submit their packages to. Each PPA is a privately run and maintained repo with their packages in.

It is used by some projects to officially distribute their software but it is also something of a potential security nightmare.

This is misleading.

Flatpak installs sandboxed libraries and then shares them between different apps as you install them. The first app installed may seem big but often the next app will use many of the same libraries rather than redownload/reinstall them.

Appimage does not share libraries. Each Appimage is a complete image, libraries included and compressed out of necessity. It can be targeted at systems to reduce library bloat but it’s often easier just to shove everything in to ensure it works. Also that compressed file system needs to be decompressed which causes further overhead. Simple apps with few dependencies will be small, but big apps can bloat massively particularly if they’re not targeted (and that’s common as they’re treated as run-anywhere solutions for developers).

Plus Appimage can include security flawed libraries - the significance of that will depend on the App being exposed to them. I wouldn’t want to run a web browser using a poorly maintained appimage for example, but I’d consider running a random small tool or utility if that was the only option.

Both models are flawed compared to native apps - not quite to the point of installing an entire distro but close. But Flatpak installs one shared set sandboxed environment, while every AppImage is crudely it’s own distro.

Nomodeset won’t cause battery issues or ajy other significant issuea with your system.

“Mode set” just moves the video mode setting into the kernel so you can access graphic card features really early at boot (and have fancy boot screens for example and have a smoother consistent boot on the optimum graphics mode for your card). Some graphics cards don’t work well with that and a flashing black screen is a symptom of that.

“nomodeset” turns the feature off, and the boot menu uses the basic bios graphics mode settings instead. The main graphics drivers will load fully later when the X11 or Wayland call for them.

All of the Linux systems you use should work fine with nomodeset; you’ll just have a more basic boot menu. You may notice some changes in screen resolution as the system loads but that’ll be about it.

So you can pick whichever Linux spin you like rather than limit yourself.