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.
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.
They left at 11am because they realized how bad the problem was and just gave up? Or left at 11am as a normal thing (e.g. before they noticed the problem) ?
I don't think it's the treatment one way or the other of those that write C# code. I think it's just the Microsoft Bubble at work. I think there are just fewer .NET developers here than the other ecosystems.
I personally shy away from .NET shops because they seem to be such a mono-culture.
--- This is totally off-topic so feel free to downvote into oblivion...
Sorry, I wasn't clear. I understand SNI and SSL without SNI.
What I'm not seeing is why it's a problem when a host such as DO doesn't allow multiple IP addresses on a single machine.
Is it because you may want to host multiple sites on that machine and use one IP address for SSL?
Oh, nevermind. It's because you may want to support multiple SSL sites on the same box without requiring your clients support SNI. That makes sense.
We really need to just EOL everyone who has a browser without SNI. People like to say that there's still a lot of XP users out there but surely even a reasonable chunk of them are using Chrome or Firefox with SNI support, right?
I don't think it's at all obvious or universally true that it's better to get an 'Unable to connect' error message than a certificate warning (btw, the default site could tell the user they arrived there by accident should they continue past the warning). Depends on the context.
I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.
One benefit to something like async/await is letting you get on with other stuff without having to murk up your code with callbacks/delegates which read more like GOTOs than async/await.
Isn't the problem that the end of the day never comes? A site is never 'done'. It always needs to be changed and this is why 'clean code' matters. It reduces the cost of change.
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.