I think this is something that is timeless and universal. At least now we have experience to back up our valuation. When we were young what did we have? Some basic logic that we spent a small amount of time thinking through?
This is assuming "who to audit" is even a software process or completely a software process, but fine, don't open source that if necessary. I really just want the IRS software that I personally use to be open source.
I'm not missing the value we just have a different idea of what that value is, but anyway, this is a different, more specific topic than the one I originally brought up and one that I don't feel like engaging in.
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing.
Not for public pipelines. I don't think it will be for personal private repos either. I'm sure they will add pricing plans that allow you to execute more pipelines in parallel, etc though. What makes you so sure it will be a paid feature?
Not only that but you can still program todays thermostats with the optimizations/rules that you would in the central system anyway. Program it once, set it and forget it, and of course, give maintenance staff manual access as well.
Can you give some insight on whether the master nodes are tiered and if so, how they are tiered. My DO master node doesn't respond to commands as quickly as GKE's but I don't know if that's because it's dependent on the tier I chose for the nodes in the node pool.
Kap and VS Code are Electron apps that prove you can get it “right” but it is troubling that Apple’s own apps don’t seem to have the same quality that they used to.
I would rather have a browser plugin that just removed pay walled content from search results anyway. Or one that redirected me to something I would use like Blendle.
Don't get me wrong, I believe the author's heart is in the right place. I find his willingness to be inclusive and get other people involved refreshing actually, but the problem is that he should know better. He's seemingly used npm enough to know that there is no mechanism within npm to notify downstream modules that he is transferring the package to someone else (and that there is now a new security risk that they must re-evaluate). The course of action taken was simply not thought through. I'll leave it to others to explain what the appropriate course of action should have been, but keep in mind that society is built on trust, otherwise you have nothing to build on. You're too busy doing every job instead of one that builds upon others.
You can, but this package is very low-level so chances are that it's not a direct dependency for many end-users. A lot of popular modules that may be using this module also don't pin dependencies or don't use lock files so that's one problem. A second problem is that when a npm package is transferred to someone else and then a new version is published, there is nothing notifying you that the package in under new ownership. A third problem is that sometimes users might delete their lock files and re-install dependencies when they encounter some versioning issue and are looking for a quick fix without realizing the implications of doing that.
People have to understand that the Node.js ecosystem is different than in other programming languages/platforms. Modules are composed from smaller modules with a granularity so small that it is almost unique. When you're publicly publishing something low-level to npm you really should understand that the community may build on top of it to the point where it is used by many modules and as a result used by many end-users. You are not obligated to maintain it, but it's not really fair to be totally careless either. The community is like society, if you're in it, try to be a good citizen or the community will move against you to preserve it's ideals.