I find it interesting that the author thinks "invasive user fingerprinting" would stop with WEI. If you really believe ad networks are _only_ fingerprinting users to fight fraud and will stop doing it after WEI, I have a bridge to sell you.
How else are they going to learn more about me and shove ads that they think I care about?
You are correct - I should be running chmod in the download stage and that is what I did before realizing `--chmod` existed. However, `--chmod` is still a valid solution.
The reason I did not stop with running chmod in the first stage is because this seemed like a common problem - what if I was ADDing a binary or a shell script directly from a remote source and I did not have a download stage?
I'm sure there are better ways to write that Dockerfile - I'm by no means an expert. It just so happens that I noticed this problem when the Dockerfile (it was from a different project. I was modifying it) was in this state and I had nothing better to do than ~yak shave~ investigate why the image size was a bit larger than I expected :)
If I build an image using the Dockerfile in the blog post 10 days later, there is no guarantee that my application would work. The packages in Ubuntu's repositories might be updated to new versions that are buggy/no longer compatible with my application.
OP's suggestion is to build a separate image with required packages, tag it with something like "mybaseimage:25032022" and use it as my base image in the Dockerfile. This way, no matter when I rebuild the Dockerfile, my application will always work. You can rebuild the base image and application's image every X days to apply security patches and such. This also means I now have to maintain two images instead of one.
Another option is to use an image tag like "ubuntu:impish-20220316" (instead of "ubuntu:21.10") as base image and pin the versions of the packages you are installing via apt.
I personally don't do this since core packages in Ubuntu's repositories rarely introduce breaking changes in the same version. Of course, this depends on package maintainers, so YYMV.
Well, they did offer to pay me $30 for limited data a couple of times.
They once offered to send me a Google Home Mini (retailed for ~$30 at the time) in exchange for my Spotify playlists. This was when YouTube Music launched.
Recently, they offered me $30 if I collect all the stamps in Google Pay's Spring Challenge. To get one of the rare stamps, I have to enroll my credit card in their cash back program, which I'm assuming is going to profile my purchase history.
If you search for Chrome, Chrome will not show up in that box either. And the first browser in that box is, guess what, Firefox. You just searched for it, why include it in the box?
UC Browser is pretty popular in Asia. Statcounter reports 3% market share worldwide, right between Samsung Internet and IE.
I think I understand what's happening here. If I click the temperaure on launcher, it opens the Google Search app querying for "weather" - here it is in celsius.
Temperature units preference is saved in Google Search app. Pixel launcher, even though it shows the news cards from Search app, cannot show temperature in the units of my choice unless I give it the "Web and App activity" permission. Just Google things.
Playing devil's advocate here. I feel like Play Services is necessary evil. This is the only thing that's keeping the ecosystem from fragmenting further. Look at the OEMs update cycle. If not for Play Services which are updated independently from Android OS itself, app compatability would be a nightmare. There is nothing to replace it with. Nokia tried and failed.
Other thing is, if every OEM starts writing their own API for these services, app developers will have to write apps for each OEM because they for sure will not work with each other. We will go back to the days of Symbian where apps will come with a huge list of phones it is known to work with.
Oh you may have misunderstood my comment. On my phone at least, there is an app named "Play Services" which I assume provides things like location services and other background Google platform APIs. You can disable other pre-loaded Google apps individually (Google Search/Assistant, GMail, etc).
FWIW, I too hate that there isn't a replacement for those Play Services. I'm so frustrated - Pixel launcher will not show temperature in Celsius unless I give it "Web and App Activity" permission.
On my Pixel 2, the only apps I can't disable are Settings, Phone, Messages, SIM toolkit, Pixel Launcher and Play Services. I can disable (not uninstall) rest of the Google apps that were pre-installed.
I'm not buying your first point. Within a month of OEMs releasing the Kernel sources, you can find builds of AOSP over at XDA, Lineage OS and other forums. And with the project Trebble in P, we have builds within a week. I don't think it is hard or Google is making it hard to compile.
As for your problems installing it on other boards, where are the drivers for them? Your classic desktop installation comes with drivers for almost every laptop/desktop board. Android doesn't because the vendors don't contribute. A snapdragon SoC requires a binary blob from Qualcomm. There is nothing you can do without it. It has nothing to do with AOSP being opensource or Google controlling it (Google controls other aspects, AKA the Play Services).
I usually do 'git checkout <branch/tag/sha_of_commit> -- <filename>' to revert a single file to previous state. If I ever need a gui (very, very rare), I would just use 'gitk'. Small and does the work.
How else are they going to learn more about me and shove ads that they think I care about?