In properly safe countries this is of course not true. But sadly the world stage still seems to be on the development level of ”lawless neighborhood” so there’s some merit to the idea (not that it is necessarily the best way forward though).
With JJ you can even override the ref spec of what should be considered a mutable commit. Feel free to set it to all commits and JJ will not allow you to mutate anything unless you pass the --ignore-mutable flag.
For example, I've configured it for me to make any commit by anyone else mutable regardless of branch:
[revset-aliases]
# To always consider changes by others immutable:
"immutable_heads()" = "builtin_immutable_heads() | (trunk().. & ~mine())"
I’m more curious of the claim that you don’t get podcasts pushed on you.
The last time I used Spotify (and the reason I left) podcast were constantly featured on the start page and it was impossible to remove them (and I have zero interest in podcast in my music application).
I’ve fully migrated from Sublime Text to Zed, but in these areas both are lacking things the other has.
Sublime has great language support out of the box but poor LSP support (basically outsourcing it to a user plugin instead of having a native integration).
Zed has great LSP support but ”poor” language integration (also outsourcing the language plugins to the community, which makes the vary in quality and feature set).
But Zed has great AI integration which Sublime completely lacks, if you’re into that.
But Docker said they would give away their services for free to all that meet the DSOS requirements. They did so in the past for this very organization and suddenly pulled the rug and went into radio silence.
The way I see it, Docker can’t both have their cake and eat it. They can’t both get the nice PR and goodwill of claiming to provide free access to open source, and also not do it (and require them to pay to keep using it in the existing capacity).
Fine if they don’t want to provide a free service, but then they shouldn’t be able to claim to do so either.
But they did do it. By their own admission in the post, that isn’t really in question.
The implied question is whether or not they should _continue_ to do it in perpetuity. If docker did a cost:benefit of the program and decided it wasn’t worth it (maybe they didn’t get that much good PR after all?) it’s their prerogative to end it.
There’s a perfectly valid gripe about the lack of communication, just as a matter of courtesy; but again, taking from their very own post, docker (the company) has historically burned their hands on proactive communication before.
The problem is that people believe such promises in the first place :/... if someone builds a fully-centralized ecosystem that has a network effect benefit of any kind, it would be dumb to believe they are going to do it forever without it becoming horrible, as eventually the system will become valuable enough that the people who control it will realize a tipping point has been reached that allows them to play the good old "I have altered the deal: pray I do not alter it further" card on the user community without enough ramifications.
And yet, people fall for this over and over and over again, as the centralized system tends to be slightly easier to use or slightly cheaper (but only due to subsidies) or comes to fruition slightly faster than a decentralized protocol or even a centralized system run by a non-profit could (though the latter still failed to save us from OpenAI... ;P but like, imagine if Docker Hub were pledged to and run by the battle-hardened bureaucratic non-profit, such as the Apache Foundation, with a long track record of not extracting value from this sort of situation).
> All of this has made us seriously reconsider what we do going forwards; we obviously won't pull all our images off Docker Hub, nor is it sensible to just stop pushing new images as it will seriously impact the many users we have who pull from there...
When you hand someone else control over how to find your content -- using central registries or walled gardens, both of which always now insist on controlling the URL of your content, you've given away all of your negotiating power for when the deal is eventually altered. It should be obvious before you ever get into this situation that, one day, you will get screwed; and like, for a service where it is clearly more expensive to host it per user than anyone would ever pay for it, there is absolutely no possibility that the situation is going to continue forever without careful planning and attention to monetization.
Nothing ever has to be built this way, BTW. I developed Cydia, the alternative to the App Store used on jailbroken iOS devices, and I explicitly did not host software myself: I set up a federated ecosystem based on APT/dpkg where people had the option to self-host their software or could work with larger (ad-supported) repositories (which I refused to run), and (and this is key) there was a seamless hand-off if you later migrated between repositories and you could even be hosted by multiple at the same time. To do this, though, you have to go in being a bit humble and, explicitly, not only reject dreams that one day you'll own the ecosystem, but work every day to prevent yourself from having that kind of unilateral power in the future.
Imagine if GitHub or Facebook Pages actually worked like a Web 1.0 web hosting company (which, by and large, they are, only with single sign-on for comments/reactions and an algorithmically-sorted central feed aggregator): you would expect to be able to buy a domain name and configure a CNAME for your account, and, suddenly, the service loses much (not all!) of its power to later move on to the extraction phase... of course, services never want to do this, and users who like being "the reason why we can't have nice things" will even argue that the most minuscule of downsides such decentralized (distributed or federated or democratic or merely regulated) systems might have are unacceptable and we should go all in on the centralized ecosystem.
^ A talk I gave in 2017 at Mozilla Privacy Lab on the numerous failure modes of centralized ecosystems, chock full of concrete cited examples -- every slide after the title slide, including even my "who am I?" and "any questions?" slides, is a screenshot of a news article from a reasonable source -- of the myriad situations people like to claim somehow won't ever happen --or at least wouldn't happen this time, as somehow this time is different than all the previous times-- actually happening :(. And like, if I were to do it again today, I would just have even more examples :(.
Note that the Task library in Elixir uses supervised processes so it adds a lot more overhead. It would be interesting to see the benchmark with just normal Erlang processes.
Doesn't fit the requirement of "between two devices". Email involves a lot of other servers on the way (pure network devices like routers doesn't really count I guess) :-P
I wonder if this can be used to detect code similarity between e.g. function or files etc.? Or are the existing algorithms overly trained on written prose?
If you are on macOS and mainly use the link hints, Homerow (paid) gives you link hints for the entire OS (including browsers and web pages): https://www.homerow.app
It's one of my favorite macOS apps that I can't live without.
