True. Personally I didn't fall for their show and I have continued not to use many of their technologies. .Net Core? No thanks, I have Go, Java, Racket, even Haskell.
It's not binary. I can name _many_ governments far less corrupt than China. Humans will always be corrupt to some degree; the amount and type of corruption present in a government is what makes all the difference.
I'm not sure I understand what you're saying. My point is that China is amongst the worst actors in the world. The fact that corruption exists elsewhere doesn't create a moral equivalence.
I think we need a Geneva convention on microelectronics and informatics products. We are growing tired of this spy bullshit by the so-called super powers.
They are destroying the information age. We need machines and software we can trust and who don't go around spilling our secrets.
Never underestimate the value of backward compatibility.
Any architecture that wants to take a decent swing at replacing x86 will either have to be x86-compatible or do a good job at emulating it accurately and efficiently.
In mobile devices, ARM has an almost(?)-monopoly indeed, but x86 never was a serious contender in that space to begin with. The same goes for "IoT" devices. In new areas of computing, Intel is just one vendor among many (well, several), and the more the market tends to demand low-power chips, Intel's advantage melts away. In that sense, I agree with you. In HPC, I could see ARM become a serious alternative, because the trend seems to be to delegate the heavy lifting to GPUs, anyway, and the GPU does not care what kind of CPU feeds it, so to speak.
But in the traditional desktop area, if you cannot run Windows and the huge number of third-party applications available there, you might as well give up. And to completely "replace" x86/x64, you have to compete in the desktop market as well.
I'm astonished too. The section on use cases doesn't help to justify why we need all this complexity. Maybe they are trying to compensate for the inefficiency of the Unix permission system ( having user, group and world is lacking in a lot of situations by today standards ).
The other solution is to implement a totally different mechanism ( ACL + some other thing, Capabilities ) but then you lose retrocompatibility.
> having user, group and world is lacking in a lot of situations by today standards
A process has supplemental group membership. If you were only limited to the above, then, yes, you would need to share resources through world or utilize a special broker if you wanted multiple privilege domains for a service.
But with supplemental groups you can be as fine-grained as you want. Just create a group for each domain with a unique membership set and make that a supplemental group for each user with access to that domain. When you want to share a file, just chown and chmod appropriately.
To see how this works in practice, look at BSDAuth (OpenBSD's alternative to PAM). Rather than using dynamically loadable modules for authentication methods--which effectively means that any program that wants to use authentication services needs root permissions--BSDAuth uses setuid and setgid helpers in /usr/libexec/auth.
$ ls -lhd /usr/libexec/auth/
drwxr-x--- 2 root auth 512B Mar 24 13:23 /usr/libexec/auth/
$ doas ls -lh /usr/libexec/auth/
total 372
-r-xr-sr-x 4 root _token 21.3K Mar 24 13:23 login_activ
-r-sr-xr-x 1 root auth 9.0K Mar 24 13:23 login_chpass
-r-xr-sr-x 4 root _token 21.3K Mar 24 13:23 login_crypto
-r-sr-xr-x 1 root auth 17.2K Mar 24 13:23 login_lchpass
-r-sr-xr-x 1 root auth 9.0K Mar 24 13:23 login_passwd
-r-xr-sr-x 1 root _radius 17.1K Mar 24 13:23 login_radius
-r-xr-xr-x 1 root auth 9.0K Mar 24 13:23 login_reject
-r-xr-sr-x 1 root auth 9.0K Mar 24 13:23 login_skey
-r-xr-sr-x 4 root _token 21.3K Mar 24 13:23 login_snk
-r-xr-sr-x 4 root _token 21.3K Mar 24 13:23 login_token
-r-xr-sr-x 1 root auth 21.0K Mar 24 13:23 login_yubikey
In this scheme, for any user who you want to grant permission to test basic system authentication you add the auth group to their supplemental group. Et voila, they can now use the framework, but without root permissions. For mechanisms that you may want to grant separately you use a separate group (e.g. _radius).
Like many bad ideas, Docker basically won because you can use it to isolate and package pre-existing, broken software. And because it's easier to find examples of how to [abuse] Docker for sharing files across security domains than on how to use supplemental groups to do this.
I just recalled an interesting difference between BSD and SysV (including Linux[1]) regarding group ownership.
On BSD when you create a file the group owner is set to the group owner of the directory. From the BSD open(2) manual page:
When a new file is created it is given the group of the
directory which contains it.
But on Linux the [default] behavior is to set the group owner to the creating process' effective group. From the Linux open(2) man page:
The group ownership (group ID) is set either to the
effective group ID of the process or to the group ID of the
parent directory (depending on file system type and
mount options, and the mode of the parent directory, see
the mount options bsdgroups and sysvgroups described in
mount(8)).
The BSD behavior is more convenient when it comes to using shared supplemental groups because you can often invoke existing programs with a umask of 0002 or 0007 and files they create (without subsequently modifying permissions) will usually have the desirable permissions--specifically, writable by any process which has a supplemental group of the directory they're located in. For example, with BSD semantics Git technically wouldn't have needed a special core.sharedRepository setting. But because of SysV semantics on Linux Git had to be modified to explicitly read the group of the parent directory and explicitly change the group owner of newly created files.
Profits and censorship. The oligarchs want money and want to shut the mouths of those who denounce their crimes. And yes, it isn't only Russia who has a problem with oligarchs.
Is this so shocking? The US government messes with everyone everywhere in the world.
That said, I don't condone fascist governments ( yes, our governments, west and east, are going in fascist mode ). We need a new wave of activism by the people.
You must pin them to specific cpu cores. But then you lose a big part of the convenience offered by VMs. It is like using gpu passthrough vs virtual 3d card.
Not that big part at all, you can change these settings at will. Sharing the CPUs (overcommiting) is probably out of the question though.
Just most VM management UIs lack the functionality.
GPU passthrough is special because they have weird initialization and shutdown handling. Plus are chunky (all our nothing) until SR-IOV variants become commonplace.
CPU cores don't have these problems.
