It may be dumb but I had things to manage like work and children in their teens, so tinnitus management had a low priority. Still, I look avidly at discussions about tinnitus. I tried the method of tapping on the neck, but it did not work for me. I tried hearing aids, but it didn't help either.
I'm not a doctor, and I couldn't give you medical advice if I was, but tinnitus can be caused by health conditions you really should get checked out. High blood pressure etc.
Same exists with laws. And in most languages if I want to avoid the type system and hand you a goldfish instead of an int, I can. It just may take more effort. Other language will blow up too if you hand them strange things. Just like python those languages have ways to verify you're not passing goldfish, You just may need more or less effort to use them
Did you get "connection reset by peer" when you sent a bit too many requests perchance? I've never found the source of that in my programs. There's no server logging about it, connections are just rejected. None of the docs talk about this.
Every datapoint reduces the number of people it could belong to. CPU + browser + browser version + OS + major OS version can narrow it down by a lot.
Then add resolution, IP address location (which VPN they use is also a datapoint), which time they are active at, etc. and you can get a good almost-unique identifier.
Slightly off-topic: why does git have such a near-monopoly on VCS? Mozilla might use something different, but I haven't come across a new project that used something other than git in at least years.
Usually there are at least a few choices with different compromises. Browsers, OSes, languages, editors, all have multiple actually popular choices.
Does git win because of the decentralized, everyone-has-a-local-repo aspect? Or the staging area, which I understand other VCSes don't have? Or just speed or reliability? Or just being in the right place at the right time?
In my opinion Git won because it was fast. It is fast because it is decentralized. It is fast because it was done by serious C hackers (there I said it). It may have a problematic UX/UI for many, but it is good enough. But it is fast.
How fast is Git? Do you remember or have you tried other VCS-es older than Git? Try getting the first working copy, try looking at changes for a file through all its history, try making a new branch, try tagging. Git is fast.
Because it is fast it was selected by many and the rest is network effects. Now you can do something just as fast or maybe even faster, but everyone else is on git. You may do something with better UX/UI, but this rarely is enough. You have to do something much better and you will not be orders of magnitude faster than git, but that is now a basic requirement.
Big names using it and GitHub. There are alternatives like mercurial, fossil, darcs, etc. but GitHub basically took over the social interaction side and majority of integrations. Nothing is better enough to displace it now. (Even if you think some specific feature in another VCS is cool, it's not cool enough to replace it where git's already deployed)
You'll still find different solutions in companies that really need it though, like Google.
Techs often maintain their position because of their spread which causes a self-sustaining environment . In my region of the world C# was very popular in the early 00’s and most companies who used it then still use it today. As a result the local job-market is pretty C# heavy, with around 30-40% of developer jobs involving working with dotnet. I’m not sure any newer organisations have gone that way, Python/Go/TypeScript has seen a huge increase, but it’s not like C# won’t be around for another few decades (especially if it continues being good). I think Git maintains its monopoly in a similar fashion, but on a much larger scale where basically the entire “western” world uses it. With places like GitHub that monopoly is only strengthen as other mention.
How it got there is a different story. I’m old enough to have been around the Danish CS scene back when computer clusters were just an experimental thing at universities and when CVS arrived around the millennium. While it was mind blowing for its time, it was also terrible to work with. Similarly subversion wasn’t very nice (for many people) and it’s likely because the centralised model just isn’t very work friendly for a lot of organisations. Then came Git, which wasn’t the first decentralised version control, I believe Microsoft came first with their hellish team foundation which proved that distributed systems aren’t good by default. Anyway, at the time Git was such a breath of fresh air in how great it was to use. It was both easy and productive and it held such an increase in quality of life that it was a no brainier to transition to git for most organisations. At least the ones which didn’t have expensive team foundation or subversion contracts.
Which birthed the circle or dominance that might never get broken. I doubt any of the old players will in any case. If they were capable of building great version control they would’ve done so from the start, and since Gits only major problem is its multitude of options it’s hard to imagine that Subcersion would ever cut 90% of their features. Team Foundation mostly trundles along because some organisations still haven’t given up on their licenses (which is the reason a lot of Microsoft things exists), but with Microsoft owning GitHub it’s not likely that they want to do anything other than to keep it good enough to keep that revenue.
The current git-saturated market certainly makes it quite challenging for other options to take off. That said jj[0] is super nifty, and it's git-compatible backing store means you can transparently use jj while the rest of your team uses git. This kind of model might give other VCS tools a fighting chance at iteration.
I think it's the latter. most people don't care about decentralization. Staging is more of a nuisance, there're some projects which try to eradicate it (https://github.com/martinvonz/jj). But I think git won the last decade because it is conceptually simple and elegant. You can reason about it in the case of any trouble. You can reimplement it if needed and be absolutely sure that reimplementation is fully compatible, because it is THAT simple.
Git seems to have it all. It's hard to imagine what anyone else can compete with, how they can differentiate. There's such a variety of ways to work & rework git repos, so much sheer capability available to use as you will that it's hard to imagine what more one could want.
Indeed it feels like most competitors are competing by offering less. This is our way! This is easier! But you're not going to win the alpha geeks over with that path. Better needs to be bigger, needs to enable more, and we're just not seeing those offerings materialize; it's unclear how you would be better or bigger.
Having the core abstractions that work & are flexible enables bountiful innovation & improvements. Git not only started with sufficiently malleable core ideas, but it's had endless features, optimization, and tuning baked in over the years. It's almost too much to comprehend. Shout out to Taylor Blau writing on the Github Blog: the man has been doing an amazing job covering what's happening in with the Highlights From Git series, since September 2018. It's really given me a sense of how much work keeps being poured into git, has given me a view of how incredibly expansive the git ecosystem is. https://github.blog/2018-09-10-highlights-from-git-2-19/https://github.blog/tag/git/
I think that GitHub is a massive factor here. The emergence of distributed version control created the battle ground, but GitHub meant that the entire world of open source and sharing code online would be dominated by git. It was their execution (marketing as well as good tech) that was better than bitbucket and attracted more and more of the open source world to GitHub and therefore git.
There's a powerful network effect with choice of version control tool, because others need to collaborate with you (even if just to pull or browse your repository) so the tool that starts to dominate will likely monopolize. This isn't the same with browsers.
Probably a combination of all of the above. When git won the VCS war, the local repo aspect was very important compared to prior options. It's fast enough, generally, except when using large files like in game dev where people prefer perforce.
Git is very much "good enough" for many people. The number of foot guns and lack of a well trodden path for many centralized corporate devs is quite high, but many people are content with it.
Personally, I think if the only advantage is git formalizes a merkle tree and sha based text comparisons with a poor cli ui, it's not very good. But many people think this is sufficient.
The thread discusses the main points. I also think that the performance is a big deal. It's fast enough to open up new workflows which didn't exist before this.
But being a monopoly doesn’t mean others can’t use other clients. I was using a Subversion repository in university but really I was just using Git and git-svn (probably). One can do the same today.
So, besides the obvious drawback of having to know two VCS, why does it seem that not many people are doing this? Because I don’t hear that much about it.
For the same reason HTTP has a near-monopoly on websites. There is a network effect with protocols and file formats. The success of github cemented these formats of git as the winners. Even so, why aren't other VCS at least somewhat popular? Because they refused to invest into supporting the git protocol and file formats.
>Does git win because of the decentralized, everyone-has-a-local-repo aspect? Or the staging area, which I understand other VCSes don't have? Or just speed or reliability? Or just being in the right place at the right time?
Your questions are actually covering 2 different categories:
(1) Why did (past tense) git win?
(2) Why does (current tense) git have a monopoly of usage now?
For (1), the various theories for git winning mindshare to create an insurmountable lead include technical and social differences:
- Git being faster than Mercurial. It had "cheaper" branches than Mercurial. And some blamed it on Mercurial being built with python instead of Git's C.
- index/staging area
- the Github free tier being more generous than Bitbucket(Mercurial)
- intangibles such as being created by Linus and high-profile usage by the Linux kernel contributors
Google Trends shows that Git+Github almost immediately outpaced Mercurial+BitBucket from 2008:
For (2) today, you mostly have inertia. Most developers are not going to bother to research and re-evaluate the VCS landscape and make a deliberate choice on any technical merits. Git is already too massively popular so just go with what everybody else is already using and just move on to something else. Even if another DVCS has some technical superior aspects (e.g. Fossil?), it doesn't matter because git is already too entrenched in the ecosystem.
An example of the network effects of (2) is Python's creator Guido van Rossum suggesting the move from Mercurial to git/Github:
One more point I'd add to (2): given its massive inertia / network effect, the tooling and the resources are leagues ahead of everything else. I'm using Darcs for a few personal projects and while the core ideas are great, the tooling is just worse. From the ways to customize the diff utilities to use, to integrations with text editors (the vc-darcs module for Emacs is pretty barebones, especially compared to Magit, but even compared to the basic vc-git).
Darcs is a name that always makes me a little nostalgic, it was such an obvious idea of approaching a VC system. Unfortunately when I used it 10+ years ago we did hit the "merge of doom" problem too often.
I was sorry to see it go away, but mercurial took over for a while, and then later I switched to git because everybody else had done so.
Safari has a special interface for content blockers to work without any permissions. They provide blocklists and the browser does the blocking itself. [1] Don't know if that's an option in Firefox.
(It's also the thing everyone is angry at Chrome for as their 'plan to kill ad blockers' by replacing the current blocking APIs with declarativeNetRequest.)
This is kind of an important point with Manifest V3: having more permission options is a good thing. It's good that declarativeNetRequest exists. Active Tab permissions are cool, I love being able to scope extensions to specific domains. Non-persistent background pages are a nice performance/security feature. The only problem with Manifest V3 is that Google is shutting down everything else and removing other APIs.
Safari's extension model kind of goes in its own direction, but it's based on similar principles to Manifest V3 and my contention with it is the same -- it's not a problem that you can build a permission-less adblocker in Safari, that's good. It's a problem that you have to, because getting rid of those permissions makes adblockers slightly less effective, which may or may not be worth it for every user. I can say with relative certainty that there is no adblocker on Safari that is as powerful as uBlock Origin on Firefox.
People bundle criticism of Chrome under the Manifest V3 label but aside from some more techy-type complaints around how Service Workers are being handled, in my experience at least a lot of Manifest V3 is really good. What's not good is that Chrome used Manifest V3 as an opportunity to get rid of a lot of other important APIs. So you don't see the same criticism levied at Mozilla because with Firefox you get most of the same benefits of Manifest V3 (and some additional benefits, Firefox's event-system is imo a better way to handle temporary background pages than Chrome's service-worker system) without the downsides of Chrome removing blocking web requests for the extensions that need them.
I'm using Manifest V3 for private extensions that I maintain for myself on Firefox. Manifest V3 is great and I enjoy trying to cut down my permissions as much as I can even though I'm basically just running the code myself. But none of my private extensions would work in Chrome or Safari or would be portable to either browser; they lack the APIs that I need and don't have any realistic equivalents.
Some things are impossible to destroy immediately. KMS keys take 60 days to remove.
You can also start the close account process which takes 60 days and just pay the fees for anything not torn down and then it all gets nuked at the end of that period.
There can be resources created implicitly, even when using IaC tools. One example, create a lambda, without an explicit log group, one will be automatically created for you outside of the tracked state.
The function would be destroyed (guessing running instances would finish their handlers and then no longer be accessible) but the log group it created would still be present, holding logs from the dead function.
I wonder what customer sizes really matter to them. Are the bulk of their revenue a lot of small/medium-sized companies paying a few 10-100k a year, or do they have a few government/bigcorp whales subsidizing the service for the rest?
Edit: I mean someone who specializes in hearing.