danbreuer

Yep, forgot to mention that.

To take this further, it's also possible to enforce that executables are confined to a few well-understood directories with good permissions by using the noexec option when mounting. Directories with executables are mounted normally (with locked down write permissions) and everything else mounted with noexec.

I use this on Nix OS. There all executables live under the read-only directory /nix/store. So you can mount / with noexec, giving the nice property that all files that are writable are by definition not executable.

Not parent, but see my sibling comment re: Docker. The issue is imo that Docker is very easy to misconfigure and gives you the wrong mental model of how security on Linux works.

On SSH password auth: its secure if you use a long, random, not reused elsewhere password for every user. But it is also very easy to not do these things. SSH certs are just more convenient imo.

It can't easily, Docker should not be naively treated as a security solution. It's very easy to misconfigure it:

- The Docker daemon runs as root: any user in the docker group effectively also has sudo (--privileged)

- Ports exposed by Docker punch through the firewall

- In general, you can break the security boundary towards root (not your user!) by mounting the wrong things, setting the wrong flags etc.

What Docker primarily gives you is a stupid (good!) solution for having a reproducible, re-settable environment. But containers (read: magic isolated box) are not really a good tool to reason about security in Linux imo.

If you are a beginner, instead make sure you don't run services as the sudo-capable/root user as a first step. Then, I would recommend you look into Systemd services: you can configure all the Linux sandboxing features Docker uses and more. This composes well with Podman, which gives you a reproducible environment (drop-in replacement for Docker) but contained to an unprivileged user.

I disagree for the same reason -- how quickly the language can be picked up and used productively. Due to Lua's small footprint, a novice user can skim through the Lua docs and walk away with a useful mental model for most of the language.

This is not the case for Javascript, which has far more syntax and many duplicated subtly-different features (var/let, class/plain objects, this definition depending on lambda syntax). Not something easily grasped by a new user.

And sure, there are many Javascript snippets floating around and its possible to pick up some subset of Javascript by osmosis. However, this approach leads to a "poke it with a stick until it works, while understanding nothing and slowly going mad" UX from what I've seen. Which is not something I would aim for in the kind of productivity tools embedded scripting languages are used in.-- I find these tools are far more satisfying and productive to use when you have a simple mental model which clicks in place after a bit of effort up front, letting you work after without having to consult docs for every step.

(Of course this is not an issue if you're targetting only developers proficient with Javascript as users, but this is not the case for most applications outside of the webdev space.)

The finder in what you linked was nigh-unusable for me. My impressions:

- Where is the ability to easily split/tab for side-by-side directory comparison?

- Every directory is opened in a new window, which makes everything even more jarring

- (Do I just not know how to operate the window manager?)

- Is the not grid-aligned icon position saved? This seems like a long-term usability nightmare.

- How can I create something other than a directory?

- Where is the location bar?

Then again, I'm not familiar with old OR new macOS, so I might have a similar first experience with the new finder.

What I found nice is the UI/UX consistency. Modern systems don't really have that anymore, with all the accumulated partial UI overhauls and different UI libraries.