That's not quite true and your bias is showing. The company behind Loongarch is reasonably friendly to FOSS and most of their LA64 changes (to Linux, llvm, binutils, gcc, etc) are upstreamed in a timely fashion. As for the chipset, kernel drivers are all open source although not all have been accepted upstream. I have personally been maintaining the out-of-tree Linux drm driver for their onboard gpu chip and it's available on github https://github.com/cl91/linux/tree/gsgpu-devel. If you have a barebone 3A6000+7A2000 setup, as far as I know the only closed source component needed is their userspace mesa driver for the onboard gpu.
The funny thing is, the boot processes on Windows and Linux are remarkably similar, and have always been.
On Windows, firmware loads bootloader, bootloader loads ntoskrnl (NT kernel), ntoskrnl starts first user process smss.exe, smss starts security subsystem lsass.exe, lsass starts winlogon.exe, winlogon logs user on and starts the shell, explorer.exe
On Linux, bootloader loads vmlinuz (kernel), vmlinuz starts first user process (init), init starts display manager (eg gdm), gdm
logs user on and starts another copy of the X server and launches user's favorite window manager.
These have essentially stayed the same since the first NT 3.1 release and Red hat 0.9. I'm not familiar with Mac OS X or other Unices but I imagine they aren't that different. Modern desktop OS design has essentially converged to a point where there is no fundamental difference between any modern desktop OSes, because after all they are all trying to solve more or less the exact same set of problems. When a user inserts a flash drive he expects it to be mounted automatically (you can't honestly expect most end users to type in a sudo command to access his flash drive, can you), and this in fact requires careful coordinations from a ton of system components to implement securely, because mounting a filesystem is a privileged operation (you certainly don't want the end user to be able to unmount the root filesystem do you, but he should be able to unmount his flash drive). This is why things like polkit are necessary. People in Linux land love to complain about dbus --- oh it's turning Linux into the big evil M$ Windowz --- but how do you propose to solve the problem of two talking processes having to send objects between each other? With plan9's 9p? How about authentication? How do I make sure the process I'm talking to is really the process I think it is? If you try to solve all these problems, you end up with something that's essentially no different from dbus.
T420 can be modded easily to have 1080p full hd IPS screen, 4C8T ivy bridge CPU and 16GB ram. The only thing it's missing is usb3 which can be solved with a cardbus extension card. W520's full hd screen is not IPS (and can't be modded) so viewing angle is somewhat limited (but still ok for a laptop of its age). The discrete GPU on w520 is indeed better than the integrated GPU in ivy bridge but still hopelessly outdated for pretty much any graphics intensive task today so you are probably better off saving some battery life by not having it.
Btw X220 can be modded to have a 2K 16:10 display (I'm using one rn), although it's a nontrivial mod. W520 is the only model that can't (or at least hasn't) be modded at all.
It's even less than that. The duality between SYK_4 (SYK with four-fermion interactions) and AdS_2 (2D AdS spacetime) is only (conjectured to be) true at infinite N (where N is the number of fermions) and at the conformal limit (ie. the limit where temperature goes to zero). What they did is a N=7 simulation of a (sparse SYK) Hamiltonian "learned" (a much better word would have been "fitted") from a N=10 dense SYK at various (finite) temperatures. Neither 7 nor 10 is large enough to test this limit.
Now the actual quantum simulation they performed is that they constructed a thermal field double (and this allows them to make the connection with a "wormhole" because the two side of the TFD are basically the left and right quadrant of the Penrose diagram) and evolved it with the "learned" sparse SYK plus some shockwave operator $e^{i\mu V}$. The actual construction of the quantum gates is due to that Jafferis-Gao wormhole teleportaion paper. The supplementary material has some useful information (I find the actual Nature paper to be quite thin on technical details). It is indeed an interesting quantum simulation, in the sense that it demonstrated that the Google quantum computer behaves the way one expects a QC to behave.
Now does this experiment actually tell us anything about quantum gravity? No, and in this sense it is a publicity stunt. My reading of the Nature paper is that the actual paper is about 20% science (mostly due to Google's hardware) and about 80% salesmanship, which is really what you need in order to survive in academia.
> our dS space
To clarify this, our universe is asymptotically a dS spacetime in the distant future where matter and radiation density become zero and the universe becomes dominated by vacuum energy (and this is necessarily a conjecture based on current theory and cosmological observations, because nobody can live this long to see that day). It's not literally a dS spacetime right now.
There is no reverse engineering because how Windows implements things internally is totally irrelevant. We only implement the public interfaces exposed by the NT Executive. The device drivers and user applications are all taken from ReactOS source code.
The keyboard driver stack is working (we also have a PC speaker driver that makes an annoying beep). It's actually not as trivial as it seems, because passing IRPs across process boundary while maintaining the consistency of states is not that easy to get right, among other things. The goal of the very first release is to demonstrate that one can run Windows kernel drivers in seL4 user space and have a Windows (native NT, not Win32) application communicate with said Windows drivers via standard NT primitives (NtOpenFile and whatnot).
Hi, I'm the author of this project (I didn't post this on HN someone else did). We have implemented NT processes. All device drivers and user executable are NT processes (created by NtCreateProcess or RtlCreateUserProcess). What we don't have is Win32 process, because there is no Win32 subsystem yet.
is UEFI.