I find this the case, but I've also found anomalies where I one day watch a movie that's been in my watchlist for years. One day something that seems stale just seems new again. Not sure why.
It also consistently insists, breaks functionality and nags you to try and get you to use the app instead of the browser. Its barely useable from a mobile browser.
They can steal a lot more data from you using the app, that's why they insist on you installing it.
I avoid native mobile apps for anything but the most essential for this reason. If it wasn't for the cars and public transportation I'd be using a feature phone by now.
At least with Go you can use "Golang" in search and get reasonable results. With Rust, I often have to write "rust programming language + [what im searching for]" which is really annoying. Not sure if anyone ever dubs Rust to "Rustlang".
Its actually not. The most recent drama was caused by the Rust Project, not the Rust Foundation, which are two completely separate entities. This seems to be a common misunderstanding which is being spread around here, including the top comment to this post.
Projects have forked over leadership issues plenty of times before; there have been cases where both parts of the fork stuck around (NetBSD/FreeBSD), and at least a couple where the projects' former leadership effectively gave up and handed the reins to the fork (egcs, a gcc fork which became the official gcc in 1999, after the FSF belatedly realized that their official version was getting stagnant, and X.org, which displaced XFree86 without a rename after users of the latter all abandoned it).
Bit of a nitpick, but I think you meant NetBSD/OpenBSD? AFAIK both FreeBSD and NetBSD independently continued the abandoned 386BSD project, but there was never any strong relation between the two projects (they did share code later on). OpenBSD did split from NetBSD, after Theo de Raadt was removed.
Other examples: FreeBSD/DragonFlyBSD, Vim/NeoVim, Mplayer/mpv, (Open)Solaris/illumos, MySQL/MariaDB, probably some more.
> Dillon started DragonFly in the belief that the techniques adopted for threading and symmetric multiprocessing in FreeBSD 5 would lead to poor performance and maintenance problems. He sought to correct these anticipated problems within the FreeBSD project. Due to conflicts with other FreeBSD developers over the implementation of his ideas, his ability to directly change the codebase was eventually revoked.
As a Web Extension dev, I can say that Chrome is definitely the go-to platform for developing new extensions, as you basically target most of the market this way (incl. Chrome, Edge, Brave, etc.). Any additional browser, means ofc additional dev time and testing, some of which can be really funky, like Safari.
That said, from the two (the other one being Safari), Firefox is much easier to port the extension to and there's even webextension-polyfill that gets you >95% of the way there (most of the time).
Yeah, I have done it twice now. Safari doesn't have as good of a support as Firefox for a lot of Web Extension API, and that's on top of various compatibility issues with Safari itself. Not to mention having to deal with Xcode to just bundle the extension into Mac app-like wrapper.
To be more precise the last time I did this I had to:
- Adjust cookie SameSite attribute (cookies didn't work properly otherwise)
- Migrate back from MV3 to MV2 (Safari DevTools are really bad for MV3 for some reason and there were also other issues that didn't appear in MV2)
- Adjust JS and CSS (some newer techniques were simply not supported in Safari)
Firefox didn't have any of those issues. On top of that, there's much more resources available online than there is for Safari - though, to be fair, it's mostly because its support for WebExtensions is newer and there aren't as many extensions for Safari. But, when you do find some resources you have to verify whether they're actually on the most recent standard - Web Extensions - since Safari supported multiple over the years, that have nothing to do with WE, and are very similarly named: Safari Extensions, Safari App Extensions, Safari Web Extensions
Safari also has random weird (read: highly annoying) things where it purports to support a given component of the WebExtensions API, and then totally doesn't. Storage.sync is a perfect example—why I should have to build my own syncing infrastructure purely to support safari (particularly given that apple always talks about wanting to protect user data)?