Android used to have lighting-fast builds even when accounting for Google's quirky tooling, R.java generation and binary XML processing. After introduction of Gradle build system and Kotlin Android build times have become laughingstock of entire programming world.
This however has nothing to do with Java — Kotlin compiler is written Kotlin, and Gradle is written in unholy mix of Kotlin, Java and Groovy (with later being especially notorious for being slow).
I might be mistaken, but the brief look at code shows that the speed up appears to come from combination of async architecture (the selling point of Mold) and intelligent usage of PUNCH_HOLE/INSERT_RANGE fallocate() operations.
Surprisingly enough PUNCH_HOLE and friends have already matured to be production ready, with viable support from ext4 and xfs filesystem. The possibilities!
While this did funnel countless FOSS and commercial developers to pay MS for certificates, it didn't close even 50% of loopholes. You can still execute third party software from your own (e.g. Steam launching games you install with it). You can also use interpreters, JVM and other ways to disregard the requirement.
If fact, the reason why MS can charge for "nearly mandatory" executable signing is because it is not mandatory at all. If they really were forced to close loopholes, they would have made it free for everyone, — just like Let's Encrypt was made free of charge to establish mandatory encryption across the Web.
> most normal people... don't even understand what sideloading is
Actually, they understand it just fine. The concept is very simple too.
Before this change you could install Android apps without registering your passport/driving license with Google.
After this change you will have to tell Google your real name and home address to install anything on your Android device. This is all. It can take a convoluted form of registering Google account or a more direct form of sending Google your identity documents to confirm "developer privileges". But you will no longer be able to use non-hacked Android devices to install anything without doing those steps.
P.S. I recall that some people still believe that they can create Google account without giving Google your personal details, phone etc. This is simply a self-delusion. If Google does not immediately demand you to cough up a phone numbers under pretense of "suspicious activity", that's because they already know who you are (you probably told them yourself by registering another account elsewhere).
No, "burner SIM cards" aren't real. This is just another form of self-delusion, — this time architected by US security agencies. You don't become anonymous by using those, you become watched.
I don't see anywhere in the official announcement that you will be required to "tell Google your real name and home address to install anything on your Android device". The announcement is about developer verification, not user verification.
You already can not install applications from Google Play without Google account. Google accounts are registered with personal phone number (the one you obtained from your carrier, presumably using your ID). All Google Play users are already "verified" one way or another.
This change means that people who do not use Google Play or other sources, fully controlled by Google, will no longer be able to install applications on Android.
This isn't how I've understood the change. My understanding is that developers will need to have their ID verified before they are authorised to allow their app to be sideloaded. So long as they have done that, why would the user need to have a google account to sideload the app? Wouldn't the whole thing be transparent to the end-user (for those vendors who pass the ID verification) and the only thing they'd notice is that they can no longer install the apps from vendors who haven't passed?
But as you said, the check (and denial) is happening at the time the _user_ is trying to do something _they_ wish to do (e.g. install an APK from a project on GitHub).
Much of the ecosystem of Android apps that are only distributed outside the Play store will be affected by this, as many developers won't be able or willing to submit to this process or waive their privacy (especially young developers or those making apps that are legal but often targeted by litigious companies, e.g. emulators, YouTube clients/downloaders, BitTorrent clients, etc.)
I don't deny that there will be less apps available to sideload. However, the claim I was responding to was this one:
"After this change you will have to tell Google your real name and home address to install anything on your Android device."
As far as I can tell (and nobody who has replied has contradicted me so far), that isn't true. I won't have to tell Google my real name and home address to sideload [the now smaller selection of] apps.
Note that TCP Keep-Alive might not play well with mobile devices.
Mobile operating systems can use application-level keep-alive packets, because those can be easily attributed to individual applications: an applications receives a TCP/UDP packet during low-power CPU sleep mode, asks system to wake up (by e.g. taking a wake-lock), and the system takes note who caused the wake-up. TCP Keep-Alive happens below application level, so it may be disabled, even when application can still be reached.
This might be somewhat less threatening then it sounds, because it requires caller to fully control animations used for entering the targeted Activity.
In particular, this vulnerability might not overcome root permission prompts on rooted devices, because their windows are launched and controlled by the installed su app, not by attacker.
You have to update an application every year, even if it is just meaningless version bump. Otherwise it will be removed after 2 years. Despite saying that this policy is required to ensure user security, several recent Android releases didn't have any corresponding major security changes.
First they ousted 8chan because of something-something-terrorism something-pedophilia. Then they have banned RT, because Russia and US are clearly at war (nope). Now they are banning TikTok for "spreading propaganda".
The "wide range of national and international media" you can access is shrinking rather quickly.
20000 RPS is very little — a web app / database running on an ordinary desktop computer can process up to 10000 RPS on a bare-metal configuration after some basic optimization. If that is half of your total average load, a single co-located server should be enough to eat entire "attack" without flinching. If you have "competitors" and I assume, that this is some kind of commercial product (including running profitable advertising-based business), you should probably have multiple geographically distributed servers and some kind of BGP-based DDoS protection.
Regarding Tor nodes — there is nothing wrong with locking them out, especially if your website isn't geo-blocked by any governments and there are no privacy concerns related to accessing it.
If, like Google, you lock out EVERYONE, even your logged in users, whose identities and payment details you have already confirmed, then... yes you are "enshittifying" or have ulterior motives.
> they were using real Gmail accounts to sign up
Using Gmail should be a red flag on its own. Google accounts can be purchased by millions, and immediately get resold after being blocked by target website. Same for phones. Only your own accounts / captchas / site rep can be treated as basis of trust. Confirmation e-mail is a mere formality to have some way of contacting your human users. By the time Reddit was created it was already useless as security measure.
RPS is a bad measure. 20k RPS is a little if you're serving static files, a raspberry pi could probably do that. It's a lot if you're mutating a large database table with each request, which depending on the service, isn't unheard of.
> you can’t imagine what’s a compute heavy endpoint
Indeed, I can't. Because "compute heavy" isn't a meaningful description. Is it written in C++? Are results persisted anywhere? Is it behind a queue? What is the caching strategy?
Given that original post mentions free Cloudflare tier, there is a good chance, that "compute" might mean something like "ordinary Python application, making several hundreds database requests". This is also a kind of high-load, but not the worst one by far.
I won't be exactly saying what it is to maintain my privacy, but the compute heavy part of it is not your run out of the mill web traffic but rather performs some heavy processing of input files, this part is written in Go.
This function of the website is different from the user-generated content part of the website where the traffic resembles those of regular dynamic websites with database reads and writes.
This however has nothing to do with Java — Kotlin compiler is written Kotlin, and Gradle is written in unholy mix of Kotlin, Java and Groovy (with later being especially notorious for being slow).