What should be posted on the internet should be the canonical source of some content, not a proxy for it. If users prefer a proxy, they should configure their clients to redirect to the proxy. Piped instances come and go and the entire project is at the mercy of Google tolerating it/not taking action against it, so it could be gone tomorrow.
I use piped myself. I have client-side configurations which simply redirects all Youtube links to my piped instance. No need for any bots here.
This blog post misses entirely that this has nothing to do with the unstable channel. It just happened to only affect unstable this time because it gets updates first. If we had found out about the xz backdoor two months later (totally possible; we were really lucky this time), this would have affected a stable channel in exactly the same way. (It'd be slightly worse actually because that'd be a potentially breaking change too but I digress.)
I see two way to "fix" this:
Throw a shitton of money at builders. I could see this getting staging-next rebuild times down to just 1-2 days which I'd say is almost acceptable. This could even be a temporary thing to reduce cost; quickly renting an extremely large on-demand fleet from some cloud provider for a day whenever a critical world rebuild needs to be done which shouldn't be too often.
Implement pure grafting for important security patches through a second overlay-like mechanism.
It was not vulnerable to this particular attack because the attack didn't specifically target Nixpkgs. It could have very well done so if they had wanted to.
If you need languages other than "western European languages", you're SOL with this offline translator; whether you use it within Firefox or the extension.
They were mentioned because a file they are the code owner of was modified in the PR.
The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren't in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).
If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it'd be as if you tried to merge the other branch into master + your changes.
The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they're done.
Atemu @ Atemu @lemmy.ml Posts 63Comments 1,439Joined 5 yr. ago
Monitor I/O on the drive; is anything using it while your system is idle?
What's I/O like when loading an album?