This is more of a sweeping generalization than I think would be appropriate.
The command line handling as I note above is a really crufty old Unix thing that doesn't make sense now and is confusing and offputting when you get papercuts from it.
Another notable thing that they talk about to an extent is process creation -- the fork/exec model in Linux is basically completely broken in the presence of threads. The number of footguns involved in this process has now grown beyond the ability of a human to understand. The Windows model, while a bit more cumbersome seeming at first, is fully generalizable and very explicit about the handoff of handles between processes.
The file system model I think is mostly a wash -- on the one hand, Window's file locking model means that you can't always delete a file that's open, which can be handy. On the other hand, it means that you can't always delete a file that's open, which can be painful. On Linux, it's possible that trying to support POSIX file system semantics can result in unrecoverable sleeps that are nearly impossible to diagnose or fix.
> The command line handling as I note above is a really crufty old Unix thing that doesn't make sense now and is confusing and offputting when you get papercuts from it.
It's a power tool, and one whose regularity and consistent presence is appreciated by many.
If it trips you up, then configure your interactive shell and/or scripts to not glob. Bash has 'set -f', other shells surely have similar switches, and undoubtedly there are shells that do no globbing at all.
If your counterargument to this workaround is that now you definitely can't use "*?[]" and friends, whereas you could maybe do that in some Windows software, my counterargument to that would be that leaving globbing & etc up to the application software not only makes it inconsistent and unreliable, it does nothing to systematically prevent the 'cp *' problem you mentioned above.
I mean, I can't turn globbing off -- applications do not do glob expansion in unix (with rare exceptions like `find`), so they just wouldn't work. This is an intrinsic decision in how linux applications are designed to work with command line arguments. All shells need to comply with this if they expect to be able to use command line tools and allow users to use wildcards. There's simply no other choice.
The `cp *` case is annoying in that it will sometimes fail explicitly, but often will work, except that it will do something entirely unexpected, like copy all the files in the directory to some random subdirectory, or overwrite a file with another file. This is unfixable. Files that start with a dash are a minefield.
The windows approach is not without its flaws (quoting is horrible, for example), but on balance I think a little more reasonable.
> I mean, I can't turn globbing off -- applications do not do glob expansion in unix...
You can turn globbing off, you just find operating without it to be inconvenient and don't like it.
Just as I find the inconsistency and irregularity that comes from Windows demanding that software do its own glob/wildcard expansion inconvenient and don't like it.
I agree about threads a lot! Process creation and handling APIs e.g. fork, signals, exec etc. are great when working with single threaded processes and command line, but they have so many caveats when working with threads.
True, starting a process and waiting until all its threads complete is a pain on Linux but I don’t remember it being less painful on Windows (although the last time I tried that on Windows was with Windows 2000).
The command line handling as I note above is a really crufty old Unix thing that doesn't make sense now and is confusing and offputting when you get papercuts from it.
Another notable thing that they talk about to an extent is process creation -- the fork/exec model in Linux is basically completely broken in the presence of threads. The number of footguns involved in this process has now grown beyond the ability of a human to understand. The Windows model, while a bit more cumbersome seeming at first, is fully generalizable and very explicit about the handoff of handles between processes.
The file system model I think is mostly a wash -- on the one hand, Window's file locking model means that you can't always delete a file that's open, which can be handy. On the other hand, it means that you can't always delete a file that's open, which can be painful. On Linux, it's possible that trying to support POSIX file system semantics can result in unrecoverable sleeps that are nearly impossible to diagnose or fix.