The -a models are typically released in the spring, the Pixel 9a was only just released in April of this year, so I wouldn't expect to see a Pixel 10a until March or April of 2026.
I think it's pretty much indisputable that the FTC was making huge progress in consumer rights and antitrust work. What, specifically, are you talking about in your comment. It's easy to make comments like this based on general 'feelings' without saying anything at all.
Giving OP the benefit of the doubt, there were issues with how the Windows kernel had little guardrails and restrictions.
That said, that was the EU's fault, as the EU in 2009 forced Microsoft to fully expose their OS internals to outside vendors during an anti-trust settlement, and with little ability to enforce vendor standards:
""Microsoft shall make available to interested undertakings Interoperability Information that enables non-Microsoft server Software Products to interoperate with Windows Server Operating System on an equal footing with other Microsoft Server Software Products.
"Microsoft shall ensure on an ongoing basis and in a Timely Manner that the APIs in the Windows Client PC Operating System and the Windows Server Operating System that are called on by Microsoft Security Software Products are documented and available for use by third-party security software products that run on the Windows Client PC Operating System and/or the Windows Server Operating System.
These APIs will be documented on the Microsoft Developer Network, unless open publication would create security risks. In such circumstances, Microsoft will provide third-party security vendors with access to such APIs pursuant to a royalty-free license and on fair, reasonable and non-discriminatory terms." [0]
This meant that by offering Microsoft Defender for Endpoint, Microsoft needs to give similar access to the underlying kernel to competing vendors like CRWD and S1.
Well, I hate Microsoft as much as the next person, but I'm not sure "writing a buggy kernel module can crash the kernel" is much of an indictment of Windows in particular...
The EU defense is something they claim to shirk responsibility, best left to their PR team. Nothing prevented Microsoft from following Apple’s lead in having safer APIs to perform filtering. Note how it refers to “equal footing”? That means that they have to let other people do what Defender does, not that they can’t secure Windows at all.
The obvious answer would've been to create a secure public API and have defender use that. But like always, corporations throw a hissy fit and implement the worst possible version of the ruling. Then people hate the EU instead of the corporation for no good reason.
It's the exact same thing as with Google Maps in Google Search. The EU did NOT say "Remove Google Maps" it said "Give competitors equal opportunity". The most user-hostile choice was removing the Google Maps integration entirely (because "no access" is still "equal access"), instead of offering users the choice.
Personally, the digital policies are one of the few things the EU generally gets right, and (as unrealistic as it is) I hope all the Googles and Apples go choke on it and di...solve.
> Giving OP the benefit of the doubt, there were issues with how the Windows kernel had little guardrails and restrictions.
This also wasn't Microsofts fault. It was bad kernel code, and don't say you would like microsoft to audit everyone else's code before it can be deployed somewhere.
Security by obscurity is a bad security concept. If anything making that information available prevented things from lurking in there and doing even more damage.
I agree with your position on security via obscurity being uslesss, but the issue was the settlement didn't allow Microsoft to add limits such as additional validation checks on vendors offerings, as those actions could be construed as violating the "non-discriminatory terms".
Any vendor's legal team worth their mettle could then argue that any additional validation on vendors is unfair given that MS would always have significant internal knowledge about how the Windows Kernel operated.
It's yet another example of the EU getting in the way of itself.
The Dell Streak (shoutout to the other 3 people who bought one) had a 5 inch screen in 2010, a notable jump from contemporary phones like the iPhone 4 which was still 3.5", and other Android devices like the HTC Droid series which were around 3.7" and slowly starting to creep upwards to differentiate themselves from the iPhone. I think the largest Android devices you could get at the time were still smaller than 4".
I remember Dell showing this off at the All Thing D conference and Walt Mossberg of the Wall Street Journal asked the Dell spokesperson to put it up to his head, and told him it looked like a waffle. To this days it’s all I think of when I see someone holding a massive phone up to the side of their head.
That thing could really stand out in a crowd. I was at a baseball stadium for a concert that year, and spotted someone with a Dell Streak as I was heading down to the field. In a sea of people that was the one phone I spotted. I stopped to ask the guy about it briefly.
I remember Steve Jobs berating phablets as "the Hummer of phones" and dissing 7-inch Android tablets as too small, and disparagingly saying users would need to "file down their fingers" to use them - without considering how much smaller Apple users' fingers would need to be to use 3.5-inch iPhones.
I also remember the viral, doctored image showing the reachability of phone screens which "proved" that 3.5 inches was the "ideal" phone size.
I'm convinced that the lack of a stable ABI and the lack of a hardware abstraction layer (requiring drivers to be in the kernel source tree) is what's preventing The Year of the Linux Desktop from ever arriving. I understand the principles behind both decisions, but at some point I think pragmatism should win out. I guess I'm just a bit surprised that no distro has taken up the mantle of providing these things; it seems to me it should be possible to build a stable ABI and HAL on top of the existing Linux kernel.
The problem is that as soon as you do that you're stuck with whatever architecture you already have, which incurs precisely the performance and maintenance burdens that Windows already suffers.
Which is a reasonable design choice for many things. But Linux can move fast in part because it can decide to discard bad ABI and HAL conventions.
I understand that, but I think for an operating system it's more valuable to provide stability for applications than to be able to move fast.
Secondarily, do the same issues not apply to the Linux API as to a hypothetical ABI? If the API changes, don't userspace applications still need to be updated and/or recompiled accordingly, or suffer breakage? At some level, whether it's an ABI, a statically linked API, or a dynamically linked API, there always has to be some interface between applications and the operating system, and breaking changes to that interface must be managed with care.
It comes down to where you decide to draw that interface, and I think the ABI is just a better place to draw it from a user's perspective. This way, applications don't need to be recompiled to work on newer operating system versions, and given how challenging and painful it can be to compile applications reproducibly, and how many applications are only provided in binary form to begin with, this seems like a worthy goal.
> I guess I'm just a bit surprised that no distro has taken up the mantle of providing these things; it seems to me it should be possible to build a stable ABI and HAL on top of the existing Linux kernel
Doesn't that distro already exist and it is called WINE?
As funny as it is to pattern the stable ABI and HAL so directly after Win32, it's also a hardened, well battle tested one. Rather than needing to design something from whole cloth and then get user and driver code buy in for it, why not just use an ABI and HAL with a lot of existing code? WINE is a funny answer, but it is a respectable one. (I appreciate the "overnight success 20 years in the making" joke above, too, about it.)
Docker on macOS also runs a Linux VM under the hood, just like WSL2 does, they're no different in that respect. WSL1 used the more exotic approach of translating Linux system calls to and from NT kernel system calls, but for various reasons (compatibility, performance, complexity) Microsoft abandoned that technique and adopted a Linux VM running under the Hyper-V hypervisor for WSL2.
There is a difference in Hyper-V itself. The Windows hypervisor is underappreciated as one of the better VM hypervisors in some scenarios, and WSL2 uses a few Hyper-V tricks [0] to really shine if your machine's Hyper-V isn't interfered with by other hypervisors. (Sadly not uncommon given how many us have things like old VirtualBox VMs that still need Hyper-V to run in a compatibility mode with Oracle-maintained hypervisors of the past.)
(Also, WSL1 isn't as actively maintained as it was when WSA [Windows Subsystem for Android] was an active Windows 11 feature driving it, but it hasn't been entirely abandoned either and there is some community support ongoing [open source PRs].)
[0] Among other things, Windows likes to run itself at all times as a guest in Hyper-V when Hyper-V is active (and other ancient hypervisors aren't interfering), making Hyper-V VMs like WSL2 "peers" with Windows itself for Hyper-V resources/attention. (It's one of the funnier things about Hyper-V being a "Pro" feature still today because even consumer-focused Windows Home is often still running in Hyper-V [because it's also sometimes a defense-in-depth security/sandboxing in some consumer use cases], it just won't let you configure other VMs in it than your main Windows OS.)
I agree, Hyper-V is a pretty cool technology! I wasn't aware WSL1 was still supported at all, let alone receiving pull requests. Windows Subsystem for Android was a neat feature, but not something I used regularly, especially since it lacked Google Play Services which made many popular apps fail to function on it.
Yeah, it is often mentioned that WSL1/WSL2 are bad names when 2 isn't a direct successor as much as a peer that works well side-by-side. Something like WSLA and WSLB might been useful to help it feel less abandoned. The number of scenarios where WSL1 is better than WSL2 are fewer and weirder, so it will always feel "second ran", but Microsoft still seems to want to support it for the few weird use cases that are left (just not huge new ones that would need massive rewrites or compatibility lab teams to run more massive suites of Linux applications).
Also, yeah the lack of Google Play Services sure was a big issue with WSA, no matter how much Amazon want people to believe their replacements for Google Play Services are fine enough for most users/apps. Google Play Services is quite a moat today.
Maybe companies should provide some sort of incentive for the juniors they trained to stay with them. As it is, the obvious and rational choice is always to leave for another company that will pay you 25% more whenever you feel undervalued.
