> Windows 9x was slow
because hard drives. Now we have SSDs and the desktop is slower than ever still.
because hard drives. Now we have SSDs and the desktop is slower than ever still.
A typical XFCE system on startup will allocate around 500MB of RAM, but with the way memory management works on Linux I think it doesn't really need all of that and lets go of it if something else does.
It is kind of a barebones desktop environment, but certainly has a lot more stuff packed in than Win9x did and for a little extra disk space you can cherry pick whatever Gnome and KDE utilities you want anyway.
So I think this phenomenon of slow modern desktops is a Windows/Mac problem, if you want one that's lightning fast, they're out there.
I'll try this for my new NUC, thanks for the tip!
"how fast would Windows 95 be if you ran it on modern hardware"
It is actually just astounding, to the point that you end up feeling "jesus is my hardware really that fast?".
(more or less Ubuntu sans snaps, though their Cinnamon desktop is also reasonably okay, even if not quite as snappy as XFCE)
The big one is desktops that I like, working out of the box: Cinnamon, XFCE or even MATE (can install more, of course, but these ones are supported and tested). XFCE is really snappy and lightweight, whereas Cinnamon is pretty polished and will also be familiar to folks coming from Windows (nice distro to recommend for that, for people with limited Linux experience).
Another big thing is not having snaps forced down my throat like Ubuntu increasingly seems to do. In that regard, Mint is closer to Debian, although if you want to, there is nothing holding you back from using AppImage, Flatpak or anything else (even snaps).
Compatibility that is otherwise pretty close to Ubuntu, as well as a long EOL period: after the demise of CentOS, Ubuntu remains one of those distros that you can just "install and forget about" (hopefully with regular updates), both locally on your workstation and in any of your servers. I can even base my containers on Ubuntu/run it on servers (pretty much every provider has support for it) but use Linux Mint locally and have pretty much everything work.
Now, frankly I could also opt for Debian without too many issues (they also have an LTS variety, albeit less advertised), but Mint is basically Ubuntu without some of the things that annoy me - boring and dependable, mostly just works.
Only annoying thing: if you ever need to setup an apt repo that points to packages that are compatible with Ubuntu and the script for doing that gets the release codename, it might get one that doesn't correspond to the correct Ubuntu release, but instead will grab the Mint name. Sometime need to fix that manually in the apt repository list with a text editor.
Apple adopted the UI conventions, and refined, polished, and extended them to create first the Lisa system and then the Mac. But early Mac OS ("System" in those days) was very much based on a procedural, Pascal-based API without much in the way of object orientation. Your app had to handle the close button and the resize grabber itself, for instance -- actually listen for mouse events, determine if there was a click in the appropriate region, and close the window or buzz in a loop drawing the resize rectangle. Utility functions were provided to help with this process, but it still had to be part of your main loop. Dialog boxes were defined with Pascal records.
Microsoft, by contrast, hired some of the Xerox PARC engineers away -- guys like Charles Simonyi. The design of Windows reflects this, as Windows more closely reflects the Xerox PARC work at an architectural level. It had from the very earliest days something like an object system. A window belonged to a window class, which contained a single method (the window procedure or WndProc), that processed messages from a flexible and extensible message system. Windows could even be "subclassed" by substituting a different window procedure. This more flexible design allowed the system to provide the necessary decorations (minimize and maximize buttons, a system menu, resize grips and even scrollbars) and the client window would receive messages from them to let it know that, for example, it had been resized or scrolled. The actual mechanics of how these decorations worked could be delegated to the system. The API was still in C, not OO like we know it today, and was a bit cumbersome to use -- but it had more of those object-oriented ideas than early Mac did.
Of course, Steve Jobs didn't make the same mistake twice, and for his first post-Mac system, NeXT, he had it based all around object orientation.
The turning point was MS switching to C# for everything. Now built in apps load slow because the code is not JIT compiled yet, and I bet other issues...