For that you need a very centralized VCS, not a decentralized one. Perforce allows you to lock a file so everybody else cannot make edits to it. If they implemented more fine-grained locking within files, or added warnings to other users trying to check them out for edits, they'd be just where you want a VCS to be.
How, or better yet, why would Git warn you about a potential conflict beforehand, when the use case is that everyone has a local clone of the repo and might be driving it towards different directions? You are just supposed to pull commits from someone's local branch or push towards one, hence the wording. The fact that it makes sense to cooperate and work on the same direction, to avoid friction and pain, is just a natural accident that grows from the humans using it, but is not something ingrained in the design of the tool.
We're collectively just using Git for the silliest and simplest subset of its possibilities -a VCS with a central source of truth-, while bearing the burden of complexity that comes with a tool designed for distributed workloads.
It's fully caused by management mindset. There are companies that are investing hard on the AI trend, but the message is clear: all code pushed is your ultimate responsonsibility, and if it lacks quality or causes problems, you're on the hook for it; using AI hasn't changed that.
So if Spotify had a modicum of AI usage hygiene, plus accountability expectations for code quality, this would still mean a bad performance review for whoever introduced this issue (person or team; poor results and mistakes are never something that come from a single source)
I would enjoy this so much. Always keeping electronic parts around home, "just in case". It feels so profoundly satisfying when you finally get to put some switch or random piece to use for a repair, after having kept it stored for 13 years in a drawer (and through moving houses 3 times!)
As a Kodi user, I must say it is very good on its core, and very bad on the addons side (which arguably is the part for which it gets recommended mostly)
It forces its limited model of text-based folders-with-files to everything. Also it's all Python, and I don't know if it's me but I always find quality issues first in Python projects than anything else. Error control is usually very lacking, and it's so frequent to see error pop-ups showing on here and there. You enter a menu and the first entry selected is ".." which is to go back to the previous menu (poor UX). All in all, Kodi for me has always been a player with good tech (it all basically works, surround sound, codecs, integration with hardware, etc), exposed as very amateurish UI experiences.
Depends on the needs of the licensor. AGPLv3 solves the problem of other players taking the code, improving it privately, and not sharing those improvements. But AGPLv3 is not a silver bullet for people who write Open Source code and pretend to make a living from it. "Open Source is not a business plan".
I know the topic won't probably be about this -and I'll be reading the article next-, just wanted to share that this title perfectly reminded me the feeling of attempting the speed reading technique explained in this old gem of a video (minute 20:15)
BOOKSTORES: How to Read More Books in the Golden Age of Content
Why does the Window Manager have to provide focus and even visibility info to the application? I could foresee an evolution of runtime controls where "Is Focused" is a user-selectable permission for apps, just like how the browser requires user approval to allow web notifications or PeerConnection access to network or webcams.
I think this case was the browser was active, but not the tab, so the browser reports that.
Many, many telemetry metrics have been added in the name of power and efficiency. If a page refreshes every 30 seconds, is it still worthwhile doing it when the tab isn’t active? It would be better to wait until the tab is active again, then refresh immediately.
That being said, all of these capabilities are a privacy nightmare, only increasing the precision of browser fingerprinting and user monitoring. Firefox could have taken a stance on refusing to implement them, but I don’t think it has an easy opt out.
With default uBlock Origin filters on mobile Firefox, all Medium blogs show up as a blank page. Which in this day and age is akin to saying that the page is utterly broken.
The only meaningful informed decision, but sadly much less known (and I think we should talk and insist more on it), is to be wary if you see a CLA. Not all do, but most perform Copyright Assignment, and that's detrimental to the long-term robustness of Open Source.
Having a FOSS license is NOT enough. Idealy the copyright should be distributed across all contributors. That's the only way to make overall consensus a required step before relicensing (except for reimplementation).
Pick FOSS projects without CLAs that perform Copyright Assignment to an untrusted entity (few exceptions apply, e.g. the FSF in the past)
You should be wary always. CLA or not, nothing guarantees that the project you depend on will receive updates, not even if you pay for them and the project is 100% closed source.
What you’re suggesting is perpetuating the myth that open source means updates available forever for free. This is not and never has been the case.
Was I, really? Maybe, if you feel so... but I'd have to say that I had no idea.
What I'm suggesting is that a FOSS project without CLAs and a healthy variety of contributors does belong to the broad open source community that forms around it, while a FOSS project with such CLA is just open to a bait-and-switch scheme because the ownership stays in a single hand that can change course at a moments notice.
Whether the project stops receiving updates or not, is an orthogonal matter.
How, or better yet, why would Git warn you about a potential conflict beforehand, when the use case is that everyone has a local clone of the repo and might be driving it towards different directions? You are just supposed to pull commits from someone's local branch or push towards one, hence the wording. The fact that it makes sense to cooperate and work on the same direction, to avoid friction and pain, is just a natural accident that grows from the humans using it, but is not something ingrained in the design of the tool.
We're collectively just using Git for the silliest and simplest subset of its possibilities -a VCS with a central source of truth-, while bearing the burden of complexity that comes with a tool designed for distributed workloads.
reply