kuhsaft

Not necessarily. You can ignore the reified generic system in the CLR and monomorphize it in the CIL output for your language. Debugging for users is usually a nightmare though due to the monomorphization. The benefit of a type-erased runtime is the interop between the languages built on the runtime.

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.

I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages.

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

I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java.

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.

The gotcha is the potential boxing of structs onto the heap, but that can be avoided using `ref struct`s.

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

Like @layer8 said, pass by copy and pass by value are the same.

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

Cell phone towers and communication systems have backup power for emergency communication during power outages.

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.

> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.

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.

> My point is that they shouldn't. I am saying that it would be better for society if we regulated that.

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?

So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.

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

> What would you say if your bank banned your Fairphone (that runs Stock Android signed by Google) just because it is a Fairphone, and "a few hundred thousands of users is marginal"? I think even the regulators would directly understand how that is a problem.

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 know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable.

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/

I would group GrapheneOS with Android. If you handed a layperson a GrapheneOS phone and asked them what OS was on the phone, they would probably say Android.

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.

Relevant conversation about those technicalities: https://news.ycombinator.com/item?id=30042576

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.

A bit aggressive, but understandable.

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

> I only mention that because a contingent of voices as high in volume as they are few in number endlessly shoehorning the Librem 5 into numerous threads no matter how much of a non-sequitur it takes, has me suddenly paying more attention these days to what's coming from the Purism camp. The more I do the more disingenuous the rhetoric seems.

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

Sorry, the statements were a bit disjointed.

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.

Ironically, I think regulation is what keeps them in power. They are major companies that comply with government regulations. Why would the government regulate to allow people to have devices that forgo government regulations?

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.

Right. Phones won’t be built open for consumers because they aren’t built by consumers. They’re built by corporations for consumers.

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

I’d say that it’s more of a cartel. The mobile network operators, the mobile device manufacturers, the mobile OS developers. They all work together in their consortiums to make money together.

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.

I don’t know what you’re going on about “rewriting history”. I never mentioned the history of open source.

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.

> We are not on a normies forum but on HN.

Being on HN does not mean that you are familiar with the intricacies of hardware and low-level software.

> I only say, that if you want to have a third option, you can have it today. There will be compromises, which can be dealt with by technical users.

I think it’s irresponsible to promote it as an alternative device without noting that it’s less secure and full of footguns. Also, disingenuous to promote it as FOSS when it only fits that definition under FSF technicalities. And lastly, to promote it as more open than phones with AOSP distros that utilize the same set of proprietary hardware, just with different communication mechanisms/boundaries.

> Fortunately I do not open random websites on my phone

That's the main use for almost everyone. You're suggesting people use a less secure device and are stating that it's more secure if they don't use it in the way it's mostly used?

That doesn't sound like freedom. That sounds like living in paranoia. You bring up FUD in so many comments, but you seem to be living it. Ironically though, you choose to use systems that enable FUD when there are systems that let you not worry.

There are people building secure software and hardware, so people don't have to live in fear when using their devices. That's the freedom that many people care about.

There's the freedom to shoot yourself in the foot. Most people don't care about that.

I'll take his word that no blobs are running on the main CPU. But the process itself is error prone. It's mounting flash storage with blobs into the filesystem of the OS. The OS can load modules directly from the storage.

> There is not a single non-free blob in the OS that runs there once the bootloader is up (unless you put some there by yourself, which you're of course free to do).

"unless you put some there by yourself, which you're of course free to do" also means unless someone else puts one there.

---

I think the "firmware jail" loader also uses Smart Direct Memory Access (SDMA)?

---

You can run blobs on the main CPU with strong isolation with TEE and other hardware security features.

> The kill switches will work independently on a compromise. Why are they moot?

Kill switches only work as a security feature when you activate them before you know you're compromised. But that's impossible.

It's a reactive "security" feature not a proactive one.

> For example, if I use Firefox with NoScript, then it is not very easy.

Security vulnerabilities aren't only JS related.

https://www.mozilla.org/en-US/security/advisories/mfsa2026-3...

https://www.mozilla.org/en-US/security/advisories/mfsa2026-3...

Adding an extension that can access all your browsing data doesn't seem very secure either.

Required permissions:

- Access browser tabs

- Access browser activity during navigation

- Access your data for all websites

Not OP, but

> This is false. Please stop writing false statements without any links. NXP promises to produce the i.MX 8M Quad until Jan. 2033. The support will be even longer.

I think they meant that the processor itself is old. It supports ARMv8 and is lacking the enhanced memory protection and execution features of the ARMv9-A processors on newer phones.

> This is false again. It doesn't matter how much my device might be compromised. The attacker will not get any access to the shut down sensors, radios or voice/video, if I use the three kill switches.

The problem is that your device can be compromised quite easily and without you knowing. The kill switches are moot at that point.

> Which blobs are running on the Librem 5 CPU?

https://source.puri.sm/Librem5/fw

https://source.puri.sm/Librem5/fw/firmware-librem5-nonfree

https://source.puri.sm/Librem5/librem5-fw-jail/-/tree/pureos...

> Which blobs are running on GrapheneOS CPU?

Depends on the phone. Arguably though, GrapheneOS has the legacy of years of thousands of security researchers working to secure Android from third-party network and GNSS modules.

---

Just so you know, I'm not using Librem or GrapheneOS. I'm looking at this objectively and have no skin in the game.

> When a platform ditches openness, you lose more than a seemingly insignificant market segment that makes no money.

Openness for users/consumers was never a goal for the Open Handset Alliance.

> Using money as the only metric is stupid and myopic.

Publicly traded companies will be publicly traded companies.

I think the common masses just expect it in the first place. If you told someone that leaving their phone unattended could lead them to getting their data stolen, they would probably be surprised. I know this isn't a surprise to the HN crowd, but it is for regular people.

I would also guess that the common masses would choose the opposite as shown by them choosing convenience over openness. It's convenient to not have a separate key to prevent evil-maid attacks.

>> An important consideration for consumers is that their data is secure if they lose their phone

> Well, it's a good thing that PureOS is LUKS-encrypted by default then.

My bad, I meant leave their phone unattended. Wherein someone can compromise the device from boot, so that when unlocked, the device is fully compromised.

I see. So it is better in the sense that the drivers are open-source. Though the drivers in Android/GrapheneOS are not open-source, I believe the drivers are also isolated from full kernel-level access.

But it still brings the point that you can't make a phone without proprietary chips and firmware from the mobile industry giants.

> You want to reflash it before use, obviously.

I think that is non-obvious to the majority of users buying a phone.

> The SoC supports High Assurance Boot, you can burn your key into its efuses and have it only ever accept software that's cryptographically signed by you.

An important consideration for consumers is that their data is secure if they lose their phone. Without a secure boot process by default, that's a hard sell for the common masses.