I see this mentioned again and again, but I don't buy it.

For power users or users with niche use cases, sure there might be specialized software that lock you into Windows or Mac.

But for most casual home users, I think Linux would be perfectly adequate, and familiarity being the only real detractor.

Assuming someone can help install a friendly Linux distribution (and that the hardware is compatible), then what are the big blockers? Gaming maybe, for those where it is relevant.

But looking at all my not so tech savvy family members and friends, a browser, online versions of MS Office (or Libreoffice for sure), maybe Spotify or the like, would really be enough. Being able to install apps via an (actually useful) app store is a big win in itself.

Looking at those friends/family members, it is not like they are able to support their Windows machines either when something goes wrong or needs to be changed - I (or someone else technical) always need to help out anyway, fixing driver issues, installing software, changing any non-trivial settings, and so on. And I could just as well do that on Linux - and whether I need to pull up a terminal is irrelevant.

I see this argument again and again, but I would imagine most people reading this have separate work and home computers?

For the average home user I can see gaming - while hugely improved in recent years - could still be a showstopper.

But surely for the average user Libreoffice or online versions of MS Office will suffice? Surely there cannot be _that_ many average PC users that need the full power of Photoshop?

Of course I expect the average HN user to be quite different from the average user in general, but I really do think that many casual users get no advantages from Windows apart from familiarity.

I think the above post must refer to how it works in MacOS. In Gnome, the app quits when the last window is closed (by default at least).

I guess this is a matter of taste, but personally I strongly dislike the way MacOS works here.

This is not a macOS issue, it’s an app developer issue. If the app developer likes the behavior that the app still runs after closing the last app window, this is how the app will act. Some newer Apple apps close the application when the window is closed.

This is the appropriate behavior if and only if the app has only one “main” window (e.g., System Preferences).

So then why is it so common on MacOS?

because that’s how it used to be on older versions of OSX and older Macs. There’s a lot of inertia because launching a program to read files off a disk and load them into memory was more costly timewise in those days so e.g. having Photoshop open and loaded even if you didn’t have a picture open you didn’t want to have to wait for the program to open unless you really were done with photo editing.

Oh... :/ I guess when I read that I interpreted it as being directed towards people switching from macOS to Gnome. I haven't booted into a system running Gnome in a while...

If I remember correctly, in old UNIX desktop environments apps still ran after closing the last app window.

A bit of a shameless plug, but maybe it could be of interest. Having been through a similar journey some years ago I spent some time back then to design a variation of Knizia’s Battle Line/Schotten Totten for a standard deck:

https://boardgamegeek.com/filepage/191552/vassal

It is not the first such variant, but one that I felt a bit more pleased with than the other variants I found.

I use Mac for work, Linux/Gnome for personal use, and have used Windows up to and including 11 both personally and professionally in the past (although a lot less recently).

In terms of the desktop environment, I feel Mac is severely lacking behind. I know there are very mixed opinions on Gnome, but to me the Gnome UX feels extremely well thought out in comparison.

The apple ecosystem might be very well integrated, but in terms of the macOS UX it feels the exact opposite. Why can’t I close an app from mission control? Why can’t I launch apps from mission control, but need to e.g. open launchpad first? In Gnome the activities view unities all of those experiences in a way that is seamless and just clicks for me, but in macOS everything seems to be separate apps/features that don’t play together at all (out of the box at least). Add to that all the other small frustrations that you need to address with third party tools, it is - for me at least - a very unproductive out-of-the-box experience.

Of course this is subjective, and might be partially an issue of (my lack of) skill/experience.

This is entirely a skill issue. I don't mean that dismissively, let me teach you the Mac way to close apps.

You hit ⌘-Tab, this brings up a list of every app you have open. Keep the thumb on the ⌘. More tabs go right, ` goes left. For every app you want to close, hit Q. When done, release ⌘.

My preferred way to launch an app is ⌘-Space and the first few letters of its name. This can have some frustrating delays of a second or two, but it will for the most part remember what you've opened. Other users are much more dock-oriented, I keep it hidden on the side and use it seldom.

> ` goes left. For every app you want to close, hit Q

I didn't know about either of these, thanks.

Also apparently, up or down brings up a view of all the windows for that app.

A while ago I put together some hammerspoon lua for making cmd-tab go by window instead of by app because that's how my brain works, but it's slower than the native cmd-tab. Are there other similar hidden tricks for Dock.app (which, I presume, is the thing that makes the cmd-tab overlay appear)?

You can two-finger drag to make the selected app move around, although I rarely do so.

You can also three-finger drag down on the selected app to get Mission Control view for that app, to select a window directly. I do that somewhat more often.

Those are the other ones I know. Discoverability of the various affordances in the macOS interface is terrible, but it stays pretty consistent over the years.

There should be a manual of a couple hundred pages. I miss the days when that was standard.

Not to disregard your remarks, I suspect they are valid, but they come from habits of uses of others systems, and there's also the good practice to avoid introducing too much ways to do the same thing, because it's dramatically augments your chances that it is known by all (in the end), works well and as expected.

Hence launchpad is only here to shortcut finding your apps in the finder or the dock, mission control just an increment over spaces. Those are not replacement for dock. So quitting app, aside the app shortcut and menu, goes through the dock, either by dock app menu or ⌘+Q on the ⌘+tab app switcher.

I can recommend Timendus test suite (which includes the one mentioned as well), as a more thorough set of tests and verification utilities: https://github.com/Timendus/chip8-test-suite

There are a lot of other useful references and tools worth mentioning, depending on how much hand-holding you want when implementing the emulator:

  - http://johnearnest.github.io/Octo/
  - https://laurencescotford.com/chip-8-on-the-cosmac-vip-index/
  - https://tobiasvl.github.io/blog/write-a-chip-8-emulator/

Additionally, note that there are lot of variants of the instruction set / system-specific quirks, which you probably don't want to entirely ignore in an implementation. In particular, the Cowgod's reference doesn't cover this fully (Matt Mikolay's is more thorough, but doesn't cover everything either).

Once you get the hang of at least one programming language where nulls do not exist, you realize just how much unnecessary pain they cause.

There are of course several ways to represent the absence of a value, fit for different paradigms and programming styles, but I think most of us can agree at this point that having untyped null values is a very bad idea in most cases.

Whenever I program in C#, I always have to be overly paranoid, as more or less anything can be null. Option types certainly introduce some development overhead up front, by forcing the developer to handle the possibility of an absent value, but in my experience this is still far less than the amount of defensive programming necessary to handle nulls correctly.

As a response, I decided to implement a practical and safety-focused C# option type, and now use it more or less everywhere.

Reference: https://github.com/nlkl/Optional

Certainly, this does not guarantee that values are not null, but it allows you to be explicit about absent values in your own APIs, which is of great value. In turn, null checks become much easier as you do not have to accept nulls as legal values (except at boundaries to external code), and working with potentially absent values become much less cumbersome, due to a convenient API.

Interesting things are happening to programming languages these days, and I am quite curious to see the next steps. The C# language team as well has some focus on this (https://github.com/dotnet/roslyn/blob/features/NullableRefer...).

Just as a note: I am aware that this is yet another maybe monad implementation in C#. However, this is one that suits my needs, while staying simple and easy to use.