On this note, GitHub does reach out to customers with Monorepos and is aware of their short comings. I think overtime we will see them change to have better support. It's only a matter of time.
So, I understand the basis of your comment. You have the knowledge to know that there are other things that may be "the right way" given your situation. I think what the author is getting at is that there are users who don't have that knowledge. Giving them a hint that is verbose and non arcane can make a world of difference.
Speaking from personal experience, there are many developers that I have met who don't have basic *nix knowledge, much less knowledge of a terminal. The reality of the situation is that a business is going to hire people regardless of that ability. They want someone who can move the features out the door. Whether this is good or bad is probably beyond this conversation. I think, for those users, these sorts of helpful hints are extremely important because it makes them feel like they aren't stuck and helpless.
I think that, to your point, it may be useful to have the CLI offer a "pro" mode in which you could set a config to not give you as verbose error messages. Annoying? Yes. However, it would strike a balance and serve both needs.
Then again, on a recent linux system, the non-ability to write to the file might be permissions. Or an immutable attr, or selinux, or apparmor, or setfacl flags or a RO mount where it lies. As soon as you decide to print out the solution to "can't write to: X" you are in for a page full of advice on what to look for. Perhaps the disk was full, perhaps uid was wrong, perhaps the 5% reserved-for-root-only kicked in.
You'd end up writing a unix sysadmin guide, and then perhaps the parent dir had too strict perms to allow you to write to a file in it...
Also, on an unrelated note, I would never ever suggest novice users to blindly just give `chmod +w` to random locations. This is only marginally better than the `chmod 777 <root-folder-name>` that used to be so spread out in many (e.g. PHP-related) tutorials a decade or two ago.
Agreed, though perhaps it is just a bad example. I could imagine a situation where a single line of advice could be useful outside the realm of filesystem security or disk usage.
I understand what you're saying, but this conversation is about the best way to design CLIs.
I agree that you can do lots of stuff suboptimally and still have a usable tool, but I disagree with the author on what the ideal error output looks like.
In practice, "being verbose" is usually the opposite of "human friendly". I much prefer a spot-on one-line error message over dozens of lines of logs with an error somewhere hidden in them. Verbose error messages usually mean that you didn't have time to design succinct ones.
I hate that stupid stuff-animates-as-you-scroll crap that's been all over the web in the last few years. If I'm on a web page it's because I think it has information that I might need, not because I want to admire artistic fades and be drip-fed single lines of text.
I appreciate them capitalizing on people looking to switch. I think they could have done a better job of describing how to switch instead of talking about what people love. I think it would have been better for them to talk about some main sticking points, like how to get out of the ecosystem (say iTunes or Photos). Either way, nice to see the competition stepping up and capitalizing on the situation.
While I agree, I can also understand why they would want to give people coming from macOS an impression of what they can expect from the switch in terms of apps, etc.
"Exiting the ecosystem" is a guide crying out to be written though.
LOL! I doubt many people are looking to switch, the article just said that as it is trying to market something. Funny that HN readers are buying it so gullibly.
I'm still convinced this is an excuse to bring Touch ID to a Mac, and to allow for more secure login. I don't think the Touch Bar is useful for people who are already adept at not looking at their keyboard. But who knows...
I was under the impression that Touch ID is actually less secure than a sufficiently complex passcode/phrase. It's certainly easier to find a good fingerprint from someone than it is to read their mind and extract a password.
Security measures are defined around threat models. People worried about the government getting access to their electronics probably won't rely on Touch ID. People worried about their stoner roommate using their machine can probably rely on Touch ID.
Especially since a password can't be forced out of you by the government, but they can force you to touch your phone. Touch ID is not protected by the Fifth Amendment, apparently.
The flip side is that entering a strong password is tedious and incentivizes people to use shorter, easier to type passwords or disable / increase the time delay for things like their screensaver locks.
That means that the question is really whether Touch ID is more secure than the passwords which people will actually use in practice. As criddell noted, how you answer that is going to come down to threat models and resources. Biometrics really put you into some pretty different trade-offs: e.g. a camera can record you typing in your password but not your fingerprint, but someone can force you to touch the sensor or maybe pull it off of a glass, a password can be faked safely while someone watches you but that fake fingerprint is much riskier, etc.
