And if you grabbed the knife and went on a violent spree, I'd absolutely expect the knife manufacturer to refuse to sell to you anymore.
The knife manufacturer isn't obligated to sell to you in either case, I'd expect them not to cut ties with you in the self defence scenario. But it is their choice.
1. Found out you used their knives to go murdering
2. Sells knives in a fashion where it's possible for them to prevent you from buying their knives (i.e. direct to consumer sales)
Would almost certainly not "be more than happy to continue to sell to you". Even if we ignore the fact that most people are simply against assisting in murders (which by itself is a sufficient justification in most companies), the bad PR (see the "found out" and "direct to consumer" part) would make you a hugely unprofitable customer.
Meh. Not sure why knife dealers would be assumed to be more moral than firearms dealers. See, e.g. Delana v. CED Sales (Missouri)
> the bad PR (see the "found out" and "direct to consumer" part) would make you a hugely unprofitable customer.
That... Doesn't happen.
Boycotts by people who weren't going to buy your product anyway are immaterial to business. The inevitable lawsuits are costly, but are generally thought of as good publicity, because they keep the business name in the news.
I am fully aware of it, there have been many 'excited' posts in HN history about various programming languages, with related rewrite X in Y, the remark still stands.
Granted, naming is hard. Routinely using a file named .deleteme or .rememberwalkthedog because it's recommended instead of a more readable solution, is not a compelling reason to switch.
> It is much much better for an API to be kinda crappy (but stable) for historical reasons
But this does more than just add a maintenance burden. If the API can't be removed, architectural constraints it imposes also can't be removed.
e.g. A hypothetical API that guarantees a callback during a specific phase of an operation means that you couldn't change to a new or better algorithm that doesn't have that phase.
Realize the "log" api is bad? Make "log/slog". Realize the "rand" api is bad? Make "rand/v2". Realize the "image/draw" api is bad? Make "golang.org/x/image/draw". Realize the "ioutil" package is bad? Move all the functions into "io".
Te stdlib already has at least 3 different patterns for duplicating API functionality with minor backwards-incompatible changes, and you can just do that and mark the old things as deprecated, but support it forever. Easy enough.
> mark the old things as deprecated, but support it forever
Is that 'supported'? A library that uses a callback that exists in 'log' but not in 'slog'; it'll compile forever, but it'll never work.
'Compiles but doesn't work' does not count as stable in my book. It's honestly worse than removing the API: both break, but one of them is noticed when the break happens.
Using VS build tools for open source development is covered by the Community licence [0], separate from this Build Tools licence change. That license is more open than you might expect, working as an individual it even permits proprietary development for commercial purposes.
Under that usage, the Community license counts as a valid Visual Studio license for Build Tools purposes, hence the second paragraph:
> This change expands user rights to the Build Tools and does not limit the existing Visual Studio Community license provisions around Open-Source development. If you already are a developer contributing to OSS projects, you can continue to use Visual Studio and Visual Studio Build Tools together for free, just like before.
That just confirms the parent comment's point. If you're just using the build tools directly, you're fine. If need to develop "with Visual Studio" i.e. the IDE, not just the command line tools, then you need the paid license.
It's actually not. It's complicated, but they're explicitly allowing Build Tools to be used to compile open source dependencies of closed source projects that do not need the MSVC toolchain for proprietary components.
It's why the example they give in the article is a Node.js application with native open source dependencies (e.g. sqlite3).
EDIT: it's clearer when read in context of the opening paragraph:
> Visual Studio Build Tools (VSBT) can now be used for compiling open-source C++ dependencies from source without requiring a Visual Studio license, even when you are working for an enterprise on a commercial or closed-source project.
I wish the post was clearer (though I'm not sure what that looks like). I've made the same mistake interpreting it, then had to go back and reread it a few times.
From memory, the virtualisation operations themselves aren't nested. The VM instructions interact with the external virtualisation hardware, so it's more of a cooperative situation, e.g. a guest can create & manage virtualisation structures that are run alongside it.
I don't know if this applies to the specific nested virtualisation AWS are providing though.
And often they’re there so no one can plausibly say they didn’t know what they were doing or stumbled into it accidentally. You can’t “accidentally” go through a door with a padlock on it.
I’d guess it’s something similar with this dongle. You can’t “accidentally” run the software without the dongle.
The knife manufacturer isn't obligated to sell to you in either case, I'd expect them not to cut ties with you in the self defence scenario. But it is their choice.
reply