Previous discussion 2020-10: https://news.ycombinator.com/item?id=24671279

Or less than 24h ago: https://news.ycombinator.com/item?id=30817793 (same article, different domain) With a link therein to another post less than a month ago.

Takeout + store encrypted in AWS S3 or even Glacier? Preety cheap storage and supposedly high redundancy. I guess it's better to not use Gmail email address to create that AWS account.

NAS + automated backups to BackBlaze (Amazon S3 compatible storage, but much cheaper).

> Backups can be made independent of source control.

To be fair there's a middle ground. You can just commit as WIP and force push to save progress. Then undo that commit and start making the individual commits. Everyone's happy.

Until the opposite happens. Some big security hole is fixed in the dependency, npm gets the fixed version by default while Go is stuck in the tested unsecure version. Or Go mitigates the somehow?

Go doesn't mitigate that somehow. You get the code that you specify, not the code that someone else has decided is better.

In practice, for both npm and Go dependencies, you'll get a Dependabot PR that upgrades the dependency for you. Obviously that is Github-specific, so if you're on a different platform, you'll have to subscribe to security updates in some other way. I am guessing there are many services that you can subscribe to that do the same thing.

Some big security hole is introduced in one of thousands of dependencies, npm gets the insecure version on next npm install while Go is stuck in the tested secure version. How difficult is that to see? I'm not the one to believe in conspiracy theories but this is just nuts.

Until the secure version is tested, as it should be for anything you deploy to production.

I'm not sure why you think deploying untested updates is a good idea?

I'm not sure what you mean. Vaccine was a success, it saved millions of lives. What's becoming endemic is a less deadly variant, otherwise we would be back to square 0, confinement and developing a new vaccine. So, instead of calling it a failure I would call it success with a lucky ending, if everything continues like this of course.

It's not a lucky ending as much as it is the inevitable ending. Virus evolution tends toward becoming more contagious and less deadly. We've known this for a long time, and we have no reason to believe that this virus would be any different.

If viruses tended toward becoming more deadly as they became closer to being endemic, humanity (or any animal) would not have lasted very long.

Using Kodi in my tv box and setup SMB to a shared folder on my Windows laptop. It was an easy setup and pretty frictionless later. I usually still use VLC to get the subtitles upfront saved with the same filename as the video file. Whatever I get in my laptop I can see in the TV later. Chromecast is also an option, not sure if there's some quality loss in that case.

I consider fleshing out customer requirements part of the engineering process. You cannot expect the customer to properly communicate what they want/need. That doesn't mean Scrum, you have many other tools at your disposal, presenting the customer with scenarios to challenge their requirements, use interactive prototypes or even paper ones. All of them far cheaper than implementing the wrong thing.

I agree about the pitfalls of not seeing something usable until it's very late and how to measure progress. The opposite is also true however, you make some easy non-scalable PoC and it looks like a huge progress when it actually can't or shouldn't be used as a foundation for anything.

I'm inclined to think a PoC (or whatever you want to call it) would be useful for some things: - a tangible and cheap way of showing the customer how you think you can solve their problem - getting concrete feedback on that solution (you're both talking about the in same, tangible thing) - using it as a foundation for the "big" project. Not its code, but the ideas behind its UX, flow, treatment of data, whatever is the main crux of the solution can be made tangible in a PoC and be used as a reference for the next step, ie making a production-worthy application - the PoC can also show that what the customer wants is in fact a bad idea.

I always wonder, Are this practices creating inflation? Once the price has gone up it's difficult to ever come back to it's previous price.

So, `yarn upgrade` broke something, probably because some package down the road didn't respect SemVer. I guess failing to respect SemVer can happen in any ecosystem, now in other ecosystem you could have sealed dependencies that an upgrade can't break, but then it makes the whole upgrade action moot. In summary, you either, not upgrade, go deep in your lock-file and fix it manually, our you update your main depenency like you did. If your UI library doesn't support the new version of the framework, you either change the library or you bail out on upgrade for the time being.

It seems pretty reasonable process to me, I feel your pain on the wasted time and I wish github issues have something like "current answer" so we don't need to go through pages of comments to find out how to fix or workaround something. In any case, lock files are there to help and make everything more static like in other package managers that don't support the same kind of dynamism. Upgrade is just like wiping your lock file.

Yeah, while I think the blame lies on both Vue and the author, I feel like the author is shifting too much blame off of himself.

Vue messed up because eslint wasn't pinned I assume (looks to be pinned now at ^6.7.2, so it shouldn't happen anymore) so upgrading gave you an incompatible eslint version.

Author messed up by blindly upgrading all dependencies, jumping major versions, and expecting everything to work fine without putting in work to double check. Yarn even has a kind of `interactive-upgrade` command that shows versions/links to changelogs iirc. There is also documentation for upgrading project dependencies at [this link](https://cli.vuejs.org/guide/installation.html#project-depend...) that I came across while playing around with vue cli.

I took the liberty of generating a Vue 2 project and seeing what dependencies are in the package.json

    "dependencies": {
      "core-js": "^3.6.5",
      "vue": "^2.6.11"
    },
    "devDependencies": {
      "@vue/cli-plugin-babel": "~4.5.0",
      "@vue/cli-plugin-eslint": "~4.5.0",
      "@vue/cli-service": "~4.5.0",
      "babel-eslint": "^10.1.0",
      "eslint": "^6.7.2",
      "eslint-plugin-vue": "^6.2.2",
      "vue-template-compiler": "^2.6.11"
    },

I don't think it's too bad if you've ever seen create-react-app unloaded or whatever, although I've never used Vue so I could be missing the equivalent unload step that generates a million more dependencies.

Upgrading dependencies is never a safe operation regardless of what semver tells you. The version number is a suggestion and not a promise. I have had minor patches break things because it turns out that my app is depending on a behaviour which is a bug. But it’s no big deal, upgrading is something you plan out and spend the time on. Upgrade them all at once and spend the time testing everything and reading change logs.

Only if the joined countries don't implement some kind of differentiated tax on products and services commiting from outside the list.

If the earnings are attributed to the country of evasion, and it is secretive as they all always are, how does the country of residence even know or prove how much they need to tax. The pandora papers would not be so revealing if it wasn’t for the secrecy part.

They can add a new rate for products sold by companies in non-signing countries.

"Paying" £1,000,000 for intellectual property in the virgin islands? There's a 12.5% tax on that, not VAT, so no, you can't offset it, thanks!

The money is coming out of non-secretive countries, right? Eg. by end user credit cards o by 3rd companies buying ads or data.