And that absurdity of a name that was Microsoft Endpoint Manager Configuration Manager aka MEMCM. Just eew.
I know, but you can't install it directly on a MacBook - you have to use a VM like Parallels or UTM.
They also run Windows
They no longer do (since the switch to ARM) - unless you count running under a VM.
I'm a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:
Usability issues
GearLever solves all the problems mentioned.
Updates
There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don't want to use GearLever, there are other updaters like AppImageUpdate.
The lack of repositories
Appimages don't even have a central place where you can find them, not to mention download them.
This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.
Lack of Sandboxing
That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would've at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you're actually running an untrusted app.
Random location
[..] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.
I completely disagree with making the entirety of /home as non-executable, when $HOME/.local/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is in the XDG spec, I'll continue storing my executables there. If you disagree, go argue with the XDG guys.
Duplicated libraries
This is a fair point but "they include all the libraries they need" is the entire point of AppImage - so mentioning this is pointless.
If users would really install every Software as Appimages, they would waste insane amounts of storage space.
Then it's a good thing that they don't right? What's the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn't really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn't be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn't be using Flatpaks either.
Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don't even need to do anything special to get AppImages integrated nicely in your system, and there's nothing stopping other distros adding these packages as optional dependencies - but it's kinda moot at this point I guess since Flatpak has already won the war.
Personally, I'm pro-choice. If AppImage doesn't work for you, then don't use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it'll die a natural death and you don't have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution...
Mercury is worth checking out - it's based on Librewolf but has additional privacy and performance patches.
Yep it's a BSD thing (and deviations down the line), but you can amend your $PATH so that the homebrew GNU variants take precedence. Obviously you'd only set this for your user/shell, otherwise it'd cause issues with system-wide tools that expect the macOS variants.
Even in an IT job I prefer using my own gear (laptop+keyboard+mouse). Corporate laptops (+ peripherals) almost always universally suck. Therfore I won't accept a job unless they have a decent BYOD scheme. At my current workplace for instance, most of our core apps are cloud-based already, and for the few legacy apps, we can access via Citrix; plus they also reimburse me (to an extent) for using my own laptop, which is nice. With my own gear, I can spec it however I want and use my own favorite apps, without needing to go thru approvals and red tape, and more importantly - I can use my own distro/DE of choice. Like, imagine if a company offered Linux laptops, but you were forced to use Ubuntu or something worse like Oracle Linux... So yea, BYOD FTW.
@[email protected] if I were you, I'd ask if BYOD is an option, and if so what their BYOD scheme is like. As a Linux person, it's always better to use your own gear, than whatever el cheapo locked-down system the company offers.
- The gestures are pretty much on par with Gnome, which means A LOT.
Are the gestures (I'm assuming trackpad gestures) finally customisable now?
I have, actually. I've converted both my elderly parents and aunt and uncle, over a decade ago, to Linux. They were first running Xubuntu, and now they've been running Zorin for the past couple of years. Both of them use an pure-Intel PC/laptops (no nVidia, no proprietary drivers) and they have zero issues. All they need is a browser for Facebook/email/etc, some light document editing, and the occasional prints/scans.
Linux works 100% perfectly for their needs, since all they're doing is basic computing tasks. In fact the whole reason why I switched them over in the first place back then was because I got tired of doing tech support every time their Windows crapped out.
Why do you assume you're going to do tech support? Does your MIL have any specific proprietary software or hardware requirements?
Really? Well, I'm from Utica and I never heard anyone use the term "upstate."