I had the same suspicion that it probably doesn't work well for seasoned linux users but its nice to see its otherwise fine. I have used ublue in the past and my experience was similar.
Did you use the linux-surface kernel? It has additional community maintained patches for surface devices and detailed installation instructions for the best linux experience. From their feature matrix they seem to have full support for sgo2.
sorry its OT but what has been your experience so far with VanillaOS? I remember there was a lot of discussion about it a while back but haven't heard much since then.
The MAU of lemmy.world is ~18,600 which is a bit greater than the combined MAU of the next 7 instances (a big help here is lemm.ee which has ~7000 MAU). This is a really healthy spread of users and it means we don't lose lemmy if the biggest instance goes down.
Compare that to Mastodon, where mastodon.social has more MAU (~372,000) than the combined MAU of the next 30 instances at least (I gave up counting). Thats not healthy for the ecosystem. Though tbf the total MAU of mastodon is ~899,000 so without mastodon.social they will still have ~527,000 but it will be very spread out.
I feel like its just the first step in completely removing the off option (like how on Windows you cant turn off Defender, only pause it). Am I being too cynical?
I wonder if immutable systems could negate the need for kernel anti cheat. If the game can ensure the current kernel and image is one from a list of acceptable ones, it doesn't need to kernel anti cheat. They could do this by comparing the checksum or something.
This paper presents the design and implementation of HongMeng kernel (HM), a commercialized general-purpose microkernel that preserves most of the virtues of microkernels while addressing the above challenges.
Another interesting tidbit from the paper:
We started the HongMeng kernel (HM) project over 7 years
ago to re-examine and retrofit the microkernel into a general
OS kernel for emerging scenarios. To be practical for production deployment, HM achieves full Linux API/ABI compatibility and is capable of reusing the Linux applications and
driver ecosystems such that it can run complex frameworks
like AOSP [42] and OpenHarmony [35] with rich peripherals.
thats a very fair point, I had not seen anyone else make this one
But the problem is that in this case, this functionality was entirely undocumented. I dont think it was intended for programmers.
Now if the firmware was open source, people would have gotten to know about this much sooner even if not documented. Also such functionality should ideally be gated somehow through some auth mechanism.
Also just like how the linux kernel allows decades old devices to be at the very least patched for security risks, open firmware would allow users of this chip to patch it themselves for bugs, security issues.
It was a skin, now its a completely different OS. The initial version, HarmonyOS, was based on Android/Linux, the new HarmonyOS Next, is a proprietary version (or successor) of HarmonyOS based on an open source project/OS, OpenHarmony. It uses a new microkernel instead of the linux kernel.
OpenHarmony is essentially an open source base for making an operating system on top. Its not like the Linux kernel, in the sense that its not just a kernel (in fact you can use the linux kernel with it), but rather a bunch of components people can build upon. And since it uses a permissive license, you can build a proprietary OS on top of it (like the HarmonyOS Next).
Huawei actually launched OpenHarmony many years back but it was not ready for phone usage yet. It was only with the launch of the 5th version that Huawei was confident enough in it to start using it on their own phones.
So the data of the 24 people, who signed for the beta program, were accessible to each other, to all the 24 people? Sounds like nothing burger to me. The odds of someone in the 24 people knowing about this issue beforehand I would say are pretty low.
We really should be pushing for fully open source stack (firmware, os) in all iot devices. They are not very complicated so this should be entirely possible. Probably will need a EU law though.
Also matrix has calls (at least element does), though not sure about screen share. And since when was discord e2e?
I ll admit matrix was for a long time really slow but matrix 2.0 largely solves this and other usability issues. Calls and screen share are still not standardized but its all being worked on.
With matrix, its not just about building one app, its about building a decentralized ecosystem all connected by the matrix protocol. So things tend to take more time.
I had the same suspicion that it probably doesn't work well for seasoned linux users but its nice to see its otherwise fine. I have used ublue in the past and my experience was similar.
Thanks for the comprehensive answer.