To be explicit about why, for others, this means your shell will search for executables in a 'bin' sub directory of whatever directory you happen to be in BEFORE it searches your normal path.
This allows for common commands like 'ls' to be executed from ./bin, if they're present, instead of /bin (from your system).
Once you've done this you've opened yourself up to an attack where you download a zip from the internet, extract it, cd into the directory and type 'ls' and you may have potentially executed something from that zip which you didn't intend to do.
tldr - relative paths in your $PATH is a bad idea.
Yeah, I wondered if I should add a caveat in there about this. I forewent it because I thought it would confuse people more than anything, and because I've never found this particular concern all that worrisome for the average developer. But maybe it's worth mentioning, in a footnote if nothing else.
Well, my point was more that I do want a single password storage solution across the board. I use Linux, Windows, OSX, and Android regularly. I tried 1Password in the past but dropped it as it didn't have a Linux client. I now use KeePass as I can sync my DB across all my devices.
Depends on what the product itself is and from which perspective you're asking the question. At any rate, those are almost never the only two choices...
I don't see tinco saying it is simple to replace these things. Where do you see that? I suspect you're unconsciously framing tinco's position this way...
Another possible way to interpret the 'ashamed' statement is that tinco is simply saying we should be trying harder to move forward when we are using such old technologies with such warts. Why can't we get rid of the warts? We should try harder. Perhaps this is what tinco is saying? I think at least equally plausible to the naive position you're projecting onto tinco...that it's 'simple' to replace these things.
Kudos to Neovim for making the effort! It is certainly appreciated.
This is an important point, regardless. Sometimes new projects are started and it's not a matter of switching. Sometimes verbosity, and the things it negatively impacts, are worth switching. That's what.
It doesn't have to be explicit "use X% of your time to contribute to open source" to count as getting paid to do it.
When using OSS libraries on commercial products I've found the need to fix bugs or other problems and have sent pull requests with those changes afterwards. Granted not all clients approve this, but I wouldn't describe it as "few-to-no other companies" that allow it.
The servers in this example were configured to be asynchronous. The clients were not. You may still be using asynchronous clients in your code but James's argument is that Java developers don't tend to do this because it requires a lot of boilerplate. Scala developers do this because it's very low syntatic overhead and frameworks+libraries embrace it.
Developers who don't do something that would give them incredible performance and resilience because "it requires a lot of boilerplate" are bad developers.
Not necessarily, more code means more maintenance which translates to more cost. Adding new features requires more research, more work, more time, more cost. Fixing anything requiring a patch after going production with a new feature would likely be more expensive. Testing tools have to be verified to work with the additional code. This all increases costs which might be OK for some organizations and not so much for others.
That's a different argument though than just "it's more code so I won't do it". If we are discussing performance then the assumption is you have a performance problem you need to fix.
To be explicit about why, for others, this means your shell will search for executables in a 'bin' sub directory of whatever directory you happen to be in BEFORE it searches your normal path.
This allows for common commands like 'ls' to be executed from ./bin, if they're present, instead of /bin (from your system).
Once you've done this you've opened yourself up to an attack where you download a zip from the internet, extract it, cd into the directory and type 'ls' and you may have potentially executed something from that zip which you didn't intend to do.
tldr - relative paths in your $PATH is a bad idea.