altfredd

I have seen few cases where UEFI was not actually usable on non-OEM configurations.

In fact, my current ASUS laptop did not allow me to install Windows until I have performed a sophisticated dance to update/flash some sort of low-level disk-related Intel bloatware. The laptop was sold without OS and was accompanied by a small paper referencing a website with instruction how to flash the firmware to actually make the laptop usable.

They are fully supported almost everywhere. XFS, ext4, tmpfs, f2fs and a bunch of misc filesystems all support them.

Ext4 support dates as early as Linux 3.15, released in 2014. It is ancient at this point!

What an absolute boatload of lies.

I am currently in process of "verifying" my identity with Android Developer console.

In addition to proof of identity (e.g. passport/driver license) Google is demanding a proof of address, government registration, this month's rental agreement, foreign passport... The process is stuck in limbo because months-old documents are deemed "outdated", and I am constantly threatened that my verification request (!) will be denied because of "exceeding allowed number of attempts" (!!)

It shares the same principle as silent Discord account bans and other "verification" harassment schemes, such as Upwork account verification. The excess developers — Google's potential competitors — need to be banished from platform as quickly and cheaply as possible, so that Google can peddle their own spyware unimpeded.

Android has entire API for handling driver failures:

https://developer.android.com/reference/android/net/wifi/Wif...

Hardware can have issues, but firmware and drivers usually work around those issues. When firmware and drivers crash, you get "masterpieces" like the one above.

intentionally hostile kernel interface

If open-sourcing your entire kernel is being "hostile", I don't think that there is or ever was a "friendly" OS.

You mean "Google has to perform final action after user petitions it to install"

(not really final, Google can uninstall your apps anytime if they are deemed undesirable)

Cloudflare will disconnect you from their free plan just as quickly.

Especially when you are facing "infected machines by the millions".

Given that Google owns Web, it can be argued that any web tech killed by Google is a part of Google Graveyard

You can always render blink and marquee with Canvas.

Just kidding, Canvas is obsolete technology, this should obviously be done with WebGPU

Approval is tied to individual apps. From https://developer.android.com/developer-verification:

You'll need to prove you own your apps by providing your app package name and app signing keys

Needless to say, Google will throw out NewPipe, ad-blockers and anything else that might endanger their profits. For example, Google does not allow F-Droid to be published in Google Play (distributing competing app stores is against their ToS). This policy was in action as long as Google Play/Android Market existed.

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).

Arch (and most FOSS Linux distributions) are highly resistant to ddos attacks.

Good luck trying to ddos their mirrors and mailing lists.

this is where most of the speed up comes from

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!

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.

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.

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.

Google already dumps old apps from store for no reason whatsoever:

https://android-developers.googleblog.com/2022/04/expanding-...

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.

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.

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.

F-Droid compiles and signs all the apps on behalf of the application developers

At least they are open and honest about it. As opposite to Google, who promised to let developers do the signing, but soon (after gaining worldwide popularity) took over with extremely shoddy justification.

WTF? Sure you can do on top of even pipes. Even XDR could...

Of course, you "can". Implement message-based communication on top of streaming. Emulate blocking calls on top of non-blocking socket API. Implement authentication via ancillary data (try not to throw up in process). Use some clever tricks to solve priority inversion. Somehow distinguish your fds from all others file descriptors to ensure that no confused deputy problems arise.

Congratulations! You have reached feature parity with Binder.

Binder was not even designed for Linux.

Neither are Berkeley sockets.

Not really.

Binder solves a real-world problem — priority inversion. It is also the only IPC on Linux that allows to perform a blocking call from process A to process B (and have process B synchronously call back to process A if needed).

D-Bus, Varlink and other "IPC solutions" on top of sockets can not do those things. Android uses synchronous Binder calls for 90% of it's application APIs, so there is clearly a real use case for it.

Incidentally, Binder itself does not specify message format. A message is a simple memory buffer. Android runtime uses a custom binary serialization format, but you can use JSON or whatever. Binder is an alternative to sockets/pipes, not D-Bus or other wrappers on top of them.

rename() doesn't cause a fsync of the parent directory?

It does not.

At best it will schedule a journal commit asynchronously (I recall that ext4 maintainer complained about adding this "workaround for buggy user code" on lkml). If you want to receive an IO error when renaming fails, make sure to call fsync() yourself.

it's difficult to change while keeping compatibility

Actually, it is trivial to change. Just embed a ReentrantLock into every object and rewrite all calls to "synchronized"/"Object.wait" to use that lock.

Unfortunately, this would result in a bit of performance regression (increasing per-object memory footprint). To solve that would require turning ReentrantLock into a magical intrinsic, fully integrated with lock bytes in the object header. Which is actually not that hard either — other runtimes like Golang or Android VM solve problems like this on daily basis. Oracle, however…

Operating systems notwithstanding, there should definitely be such option for every OS widget, that displays text (including Android TextView). And it should default to disabling all BiDi backdoors unless developer explicitly vetted specific text span to enable them.

Making entire text rendering stack vulnerable by default under pretext of catering to less than 1% of world population is ridiculous.

The "data" setting of ext filesystems isn't replacement for fsync().

More likely, the reason why ChatGPT can do it is because all necessary code is available on StackOverflow.

I don't understand unbound excitement about using a paid online tool (!) that does not have reproducible source code (!!) and can sometimes (!!!) generate correct implementations of extremely well-known algorithms if given perfect description.