The monomorphization of CLR generics is what NativeAOT does, though it doesn't support some C# features.

TypeScript is essentially C#, but with type-erasure and lacking the low-level struct & pass-by-reference features.

I do think the C#/CLR struct implementation is better though.

That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java.

And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.

Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users.

Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.

https://news.ycombinator.com/item?id=48599273

C# copies C++ behavior where you can pass a struct by value or reference, and you can mark the parameter as readonly. C# also has in/out parameters. Essentially, you can program in C# exactly like you would in C++.

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

The footgun with C# structs are that you can accidentally box them onto the heap. To avoid that you can define `ref struct`s that cannot be boxed. `ref struct`s follow the C# disposable pattern.

https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

If you have backup power for your router and ONT/Modem, you should also still have internet service during a power outage. The ISP-owned ONT for a place I lived had a little lead-acid battery attached to it, and during power outages I still had internet service.

And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.

Playing devil's advocate here. Why should software developers be allowed to restrict where/how their software is used, while hardware developers can't restrict where/how their hardware is used?

> https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...

Looking at just that small list, they mark some vulnerabilities as not vulnerable because it's "In-VM attack only". That's disingenuous.

> There is no way to use the discussed vulnerability, if one uses Qubes according to docs

It's like saying you're not vulnerable to cutting yourself with a knife, as long as you use it correctly.

You can say your risk is low, but you can't say you're not vulnerable.

---

> Moreover, there is no sudo password by design

The POC uses `/usr/bin/su`, but that's besides the point.

The vulnerability itself can affect other things. The POC just used root-privilege escalation as an example.

https://access.redhat.com/security/cve/cve-2026-31431

RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.

We're talking about different operating systems on devices, not the same operating system on different devices. Also, it's not the same as modifying the stock OS that does work with a non-stock OS that doesn't.

The hardware analogy would be closer to having a computer, replacing the GPU, then getting angry that there isn't a driver for the GPU that supports that operating system.

> Microsoft Office shouldn't be allowed to just ban Framework computers running Windows just because they don't think Framework is big enough, right?

Apple doesn't allow their operating systems to run on non-Apple devices. Likewise, Microsoft does have the right to restrict what systems Windows can run on. Any software provider has the right to limit their software's usage.

Conversely, device manufacturers have the right to restrict what operating systems can run on them. E.g. the majority of devices other than desktops and laptops.

Whether or not you should be able to run any software on any hardware is another debate. Even if you support that stance, there is a hard limit to user freedom via government regulations on hardware/software such as any RF transmitting device and cryptographic devices.

---

Google Android and iOS are regulated by governments.

With the upcoming age verification requirements made by governments (let’s not debate that here), only the corporate entities that governments can regulate will be allowed.

We can regulate to allow alternative Android OSes, but the alternatives will be ones that follow government regulations.

You can check your DomU kernels using this guide:

https://doc.qubes-os.org/en/latest/user/advanced-topics/mana...

If your Dom0 or DomU is running kernel < 6.18.22, or between 6.19.0 and 16.19.12 you are vulnerable.

https://github.com/QubesOS/qubes-linux-kernel/pull/1272 commit fafe0fa2995a of the kernel mirror

Currently stable version of QubeOS does not have the patched kernels. https://yum.qubes-os.org/r4.3/current/dom0/fc41/rpm/

But considering it as a separate OS, I wouldn’t consider it mainstream. It’s not on any device by default. And it has an estimated 250k users out of ~3.9 billion Android users, or 0.0064%. It might seem mainstream for the tech community, but it goes to show how small the tech community is.

It might be mainstream once Motorola, a corporation, starts releasing phones preinstalled with it.

Though with a username of fsflover, I think you'll be biased.

Also, another relevant thread (that you were even a part of!) discussing the pointlessness of what Purism did to fit the technicalities: https://news.ycombinator.com/item?id=29841267

It's actually worse than I thought. There's the initramfs /lib/firmware loading workaround for the FSF certification of the OS.

But even before that there is code run by the main CPU that loads instructions for the secondary core to load a blob from separate flash memory to pass to the memory controller to initialize it.

All that just to attempt to fit the technicalities of the FSF RYF hardware certification while still loading a blob like every other phone microprocessor.

---

It's interesting that I could make a device that burns efuses to make it obsolete and it could still be considered FSF Respects Your Freedom certified.

> If anything, it makes it harder to audit and figure out which firmware version is being run than if the firmware were to be shipped along with the OS.

Yep. https://docs.puri.sm/Hardware/Librem_5/Maintenance/Modem.htm...

"These files are controlled by a third-party and are not publicly accessible. Contact Purism Support to request these files for a firmware update"

---

Don't bother arguing with fsflover. They're a Purism evangelist that refuses to view things objectively.

https://hn.algolia.com/?dateEnd=1777075200&dateRange=custom&...

https://hn-wrapped.kadoa.com/fsflover

---

Damn. They even argued with marcan (Hector Martin known for Asahi Linux) in 2022. At this point I'm guessing they're a bot.

https://news.ycombinator.com/item?id=29841267

---

For fsflover, what Purism is doing is moving the non-auditable part of the OS onto a separate storage device so that they can claim that the OS is "Fully Auditable" and FSF certified even though the non-auditable and non-free part is mounted into the OS filesystem during boot. It's deceptive marketing and you're spreading that marketing.

Other open mobile OSes aren't trying to hide the fact that there needs to be proprietary components for hardware.

The only thing I concede is that the drivers are FOSS, which is why some performance and functionality is degraded compared to phones using non-free drivers. You could develop an AOSP phone using the same FOSS drivers as well, you'll just have the same issues.

It seems to be mainly fsflover. You can search “Librem 5” messages in HN and it’s flooded with messages by them.

https://hn.algolia.com/?dateEnd=1777075200&dateRange=custom&...

https://hn-wrapped.kadoa.com/fsflover

iOS existed before the Microsoft Store. The apps developed were brand new. No backlash from a new SDK and platform.

Windows RT is closer to iPadOS though. For iPadOS, apps just worked since it’s based off of iOS.

The Microsoft Store only supported a new half-baked SDK that limited what applications were capable of. Developers already had Win32 apps and rewriting them with the new SDK seemed pointless just to support what seemed like a needless limitation.

If you want a successful mainstream operating system. It needs to work within the rules of society. It needs to comply with regulations. It needs to cooperate with mobile device manufacturers and network operators.

These small grassroots operating systems fail because, to do all those things, you need to be pragmatic.

The next major operating system will be backed by a business or government.

The software may be built by consumers for consumers, e.g., AOSP distros. But, the hardware and mobile infrastructure, probably not.

It’s a bit obvious when you look at the supply chain where “competitors” supply each other with parts.

RF hardware is heavily regulated by governments, so a truly open-for-consumer hardware solution won’t exist.

From the Open Handset Alliance:

“The Android platform will be made available under one of the most progressive, developer-friendly open-source licenses, which gives mobile operators and device manufacturers significant freedom and flexibility to design products.”

Give mobile operators and device manufacturers freedom, not consumers.

If anything, the people claiming that Android was created for freedom for consumers are rewriting history.