Or maybe you're using a distro that updates Gnome late, which may give extension makers enough time to update?
You're thinking of just one extension, one instance. Now repeat this for EVERY single Gnome release, for pretty much all extensions (not just this one), and you can understand my frustration. Which is why I've left the Gnome ecosystem.
Also, it's not like v45 came out of the blue, the beta releases were available for quite a while prior to final release, and even before the final, the Gnome developers did warn that about the upcoming extension changes. So it's not like the Material Shell devs were unaware.
Edit: Also, the PR may have been merged but the updated version hasn't been released yet. Both the versions on Github and the Gnome extensions site are still the old release.
Getting similar results with DALL-E 3 here, except for the third prompt.
(a) I couldn't resist petting the adorable little glucose
(b) The tabby gregory faced wright stretched out lazily on the windowsill
(c) The maintenance wet nose nuzzled its owner's hand
(d) The dangerous think walt growled menacingly at the stranger who approached its owner
This is the actually the thing same as Windows - in Linux you've got the which command, and it's equivalent is where in Windows. Both do the same thing - find out where a program lives.
OP meant a "program" in this context. Both Linux and Windows have specific paths where programs typically lives. For example, in Windows, if you type "notepad" in a command prompt or the 'Run' dialog, it'll search for it in known system paths such as C:\Windows, C:\Windows\system32 etc. These paths are declared in the PATH environment variable - which you may have encountered when certain applications try to (or ask you to) add their program folder to the PATH, such as say Java or Python. If a program is added to the PATH, typing 'java' or 'python' from anywhere will automatically launch it, so you don't need to specify the full path or the program.
Now whilst this is convenient, sometimes it can cause unwanted issues. For example, say you installed some other program that uses a specific version of Java or Python, and it installed that version in your system, and added that folder to the PATH - now when you type java or python in a command prompt, you wouldn't know which version you're executing. This is what OP meant by a program living in multiple places. As you can imagine, this can now cause issues, and can even break some scripts expecting a particular version of Java/Python etc and some other version is being picked up. This is where the where command in Windows comes in handy, as it tells you where exactly that program is located. And it's Linux equivalent is which.
So at least in this department, the behavior of Windows and Linux is virtually identical. :)
But if something isn't available via the package manager, I could still find it online and download and install it, but it might cause issues because it hasn't been verified by the people who maintain the distro's package manager accessible repositories.
Correct. The usual issues that you'd find is missing libraries or other package dependencies, because the versions/packages on your OS may not match what the developer complied their generic release package with. Which is why you normally don't download random apps from the web like you'd do on Windows, becuse there's no guarantee that it'd work on your distro (not to mention the security concerns).
Or I could still install it with flatpaks or snaps and something something container and it should still work? Or might cause compatibility issues?
Correct, Flatpak/Snap was invented for this very reason, to solve the library mismatch and dependency issues you might get. Flatpak/Snap works by bundling all the necessary dependencies a program might need, so it doesn't matter what your OS has. There are some issues with Flatpaks/Snaps, but these are rare and usually they come about due to the sandboxing (Flatpak/Snaps typically don't have full system access, but "just enough" to get things working. You can manually configure the permissions though if you need to give an app more/specific permissions).
AUR has more packages that have been verified for arch than OpenSUSE has with Yast?
* "packaged", not "verified", but yes being packaged for a particular distro usually implies that it works, but that's not always the case. Btw, YaST is just a system config tool, not a repo. OpenSUSE's default repos do indeed have fewer packages compared to AUR, but that's an unfair comparison since the AUR isn't even enabled by default on Arch, it's something you'll manually need to enable and even get a third-party package manager like yay/paru etc to access it. OpenSUSE also has third-party repos like Packman, and even an online Software Portal that can be used to search for and install package from several official and unofficial repos. So technically speaking you could probably find everything you need on OpenSUSE (it's hard to get an exact package count to compare), but I guess it's not as easy/convenient as simply using the AUR on Arch.
Nix (Nixpkgs) actually exceeds the AUR in the number of packages, according to this page.
And the nice thing about it is that you don't even have to be on NixOS to use it - in fact, NixOS came much later. Nix started out as a distro-independent package manager, and can still be used that way, because Nix packages do not interfere with your system's packages.
None of the comments here explain how WINE works, so allow me to elaborate a bit.
WINE is like a translator or a compatibility layer. When a Windows program tries to perform a function that would normally require Windows, WINE steps in and translates that request into something the Linux system can understand and process.
As you may know, Windows programs work by making API calls (eg using Win32 APIs) to operate and perform basic tasks. WINE takes these API calls and translates them to their Linux equivalents (POSIX calls, to be specific, which means Wine can run on several Unix-like systems). This way, when a program asks to say, open a file, or display something on the screen, WINE converts these requests into a form that Linux can execute.
WINE's approach is about providing compatibility for user-level applications rather than replicating the internal workings of the Windows kernel. It includes various libraries and components that mimic the behavior of those in Windows. This helps in executing the Windows applications as if they are running in their native environment.
-
The core of it is NTDLL. NTDLL.dll is a core Windows library that provides low-level system functions to interact with the Windows NT kernel. In WINE, ntdll.dll is adapted to work with the Linux kernel instead.
-
Then you have the Win32 API libraries, providing the basic APIs that Windows applications use for functions like window management, text rendering, and system calls. Examples include user32.dll (for user-interface functions), gdi32.dll (for graphics device interface functions), and kernel32.dll (for basic system functions).
-
Shell32.dll for handling Windows Shell API functions related to file operations and the user interface.
-
DirectX Support, for running games and multimedia applications. WINE implements parts of DirectX, like Direct3D for 3D graphics, DirectDraw for 2D graphics, and DirectSound for sound processing. Note that WINE's implementation converse Direct3D calls to OpenGL, whereas there are community projects like DXVK and VKD3D which translates these calls to Vulkan.
-
Finally there's a Registry Implementation, so that applications that need to read or write to the registry can function correctly.
Of course, there's a LOT more to it, the above is just an example of some key components. Basically Wine has reimplemented (coded from scratch) various libraries and executables that, on the outside, look like standard Windows dlls/exes, but internally they use POSIX APIs to talk to the Linux kernel and other POSIX components. This, along with the Syscall translations, bridges the gap between Windows programs and Linux.
Now naturally, this is neither a perfect, nor a complete implementation of Windows APIs; plus there are some things which Wine will never implement (such as ntoskrnl.exe), so not every program will work as expected - so check out the Wine AppDB for compatibility reports with various Windows apps.
Material Shell
Back when I was still on Gnome, I gave this a try and it was great - until Gnome got updated and it stopped working. And then they'd fix it, and Gnome got updated and it stopped working again. So I stopped using it because I couldn't deal with the constant breakages. I see that they still haven't updated it for Gnome 45, despite a bug report being opened for it over two months now. It's exactly because of breakages like this, and extension neglect from the authors, that I've stopped using Gnome and switched to KDE.
KDE worked great for me out-of-the-box, so I didn't install any third-party extensions. The only changes I've made is for aesthetics - moved the panel to the top, enabled a global menu and a side dock, for a more Gnome/macOS-style layout.
Well you don't have to buy them brand new. If you guys have a used goods market there, you could look around for some good deals on used drives there. Or even used PCs, sometime people sell entire PCs for the same cost as a hard drive, so look out for those and take the drives out, sell the rest of parts.
And if things are really desperate money wise, it doesn't even have to be a hard drive, you could even store your music on CDs/DVDs - not the most convenient option I know, but it's an option - you could move the music that you don't listen to often (or music that you're tired of playing constantly), and keep your more frequently played music on the HDDs.
Well it's Black Friday and HDDs are going for cheap. 6TB is nothing these days, when you could get a 16TB external drive for only $200, or a internal SATA one for $185. Or you could replace/supplement your entire NAS with a single 6TB drive for only $50.
Disk space is cheap now, so upgrade your storage, convert your music to FLAC, problem solved.
Are you talking about for work or home usage? And do they have any specific proprietary application/hardware requirements?
Then you're lucky I guess. I too was on Arch when I experienced the extensions breakage.