It is also at least some level of defense against malicious npm packages (doesn't eliminate threat completely, but at least less sophisticated attacks will be thwarted).
CSP headers are a very useful tool and I encourage everyone to use them. They are a PITA to set up though. Fortunately at least Firefox clearly communicates in console log when a CSP rule is hit, and how to relax it (if it was by mistake).
Note that CSP can be set as META tags too. There's a gotcha though: if they are set in both places (HTTP headers and HTML META tags), an intersection of the rules is used.
You can exchange for Monero to gain anonymity, and there will always be a way if you're willing to pay for it. 80% of a few millions is still a good sum.
I'm glad they didn't. HASS isn't very user friendly to setup and very unstable in use.
I spent far too much time trying to maintain a setup of HASS. It's schizophrenic with it's MQTT support and the two paths don't play well. It "supports" SSL through Let's Encrypt but it was problematic with MQTT. It's kind of awful to configure with files being scattered all over the filesystem. It frequent updates and frequently breaks configurations. It also has weird limitations with certain Smarthome integrations (e.g. Insteon) that make it unusable.
No, you can't. Not when more and more phones ship with locked bootloaders and a smaller and smaller percentage of phones actually work well with some AOSP spin and none of the apps you use work without an unrooted, closed-source-Google-API-infested phone.
I strongly disagree. Git rebase is a very useful command, but of course you need to know what you are doing. Git becomes very weird if you try to avoid its core concepts... as far as I'm concerned, use rebase, get yourself cut (or better yet, learn about it before using it) and try not to repeat mistakes.
That said, git porcelain is simply awful. It is inconsistent and full of dangers - there is no way I would dare try new commands without reading up on them, because the names are often misleading. Sometimes I really wish GitHub / GitLab used Mercurial as their foundation. I think the world of programming would be much easier....
Wrong answer. Selling support means that the developer is incentivized to make product unnecessarily complex. Also, with recent developments it turns out that other entities might be better at providing support than original developers, taking away the option to monetize OSS. Why bother writing your own software, when you can just sell services and provide support for a different one?
Note that RedHat, often quoted as success story, is really a services company that just happens to write an occasional piece of software, and support them when their customers need it.
There's a lot more going on than just incentives to make a product "unnecessarily complex". It's certainly a concern but many companies make it work. I judge this an acceptable answer, not a wrong answer.
> It's certainly a concern but many companies make it work.
They do? Maybe. But they are walking a thin line between their short term (make it complex so we can, you know, sell support) and long term (make it simple enough that people don't jump ship) commercial interests. This is the reason I call it "unnecessarily" complex - it is in the interest of companies who sell support services that the product is not as easy to use as it could be.
Do we really need this? I think not, and I actually prefer what Redis Labs, MariaDB and others have been doing with the licenses for their modules. Sure, Business Source license and similar are not open-source (as in "freedom to take the product you have built and sell services on top of it, driving you out of similar business as collateral damage"), but at least they provide developers with the incentive to produce easy to use software, and not just because they feel like it, but because they can actually earn their living from it.
There might be some exceptions that "make it work", but this is in spite of just selling services on top of their product, not because of it. The cards are stacked against them - it is much easier (and profitable) to take other persons' product and build on it that it is to build your own.
In my experience, selling support is an acceptable answer only in the eyes of would-be competitors. Otherwise it is just plain wrong. </rant>
> So you're excluding deploying/maintaining Open Source Software as a service. That basically excludes how Open Source is supposed to get monetized.
Is it? This means that incentives would be wrong, because then developers would be incentivized to produce difficult to use (but useful!) software - with various poorly documented features, multiple ways to solve the same problems, poor and inconsistent UX... Oh wait... </s>
I am sorry Redis labs got the heat for their license change and I really hope some solution crops up. I appreciate opensource, but I am getting tired of poorly implemented systems, just because there is no incentive to do it differently.
I think the solution lies in "free-to-use (but not free-to-sell), source available" licenses. I haven't seen one that would convince me yet, but I am certain that with big-tech companies behaving like they do, more and more developers will think twice before giving away their work for free just so others can make billions off it (and take away income from the very companies providing bread and butter to FOSS developers - coughAWScough).
