zaxcellent

It seems like Mozilla negotiated with the EU to assuage their security concerns[0].

[0] https://securityriskahead.eu/

There are accounts out there which can function this way, often called Cash Management Accounts. Fidelity has one that works this way: https://accountopening.fidelity.com/ftgw/aong/aongapp/intere...

I remember reading about the conceptualizing of a Bevy editor of some kind a while ago. I recently tried to find information about its progress but came up empty. What's the current status of the game editor for Bevy?

What you're describing sounds like a superscalar processor which utilizes instruction level parallelization: https://en.wikipedia.org/wiki/Superscalar_processor

The experimental webgl backend support is particularly exciting as browsers still feature-gate WebGPU. Chrome 94 has an origin trial open, but it seems somewhat limited.

I think people are missing the point of supporting this much wattage as a USB-IF standard. There are already 130W power supplies from Dell, so it's going to happen with or without standardization, and I'd rather it happen with. It's also not just laptops that might be powered by this. The article mentions all-in-one computers like Mac might use this, and I could imagine it replacing those awful AC adapters used on monitors with no internal power supply.

I don't think the kernel guarantees that if X runs against Linux today, then it will run against the same X on new kernels on new hardware in perpetuity. It's more along the lines of, "if I one calls the read syscall with parameters a, b, c, it won't suddenly require a 4th parameter, or demand they be in a, c, b order."

Anyways, if the kernel developers decided they wanted to invent a brand new uAPI that does graphics, I wouldn't at all be surprised if new GPU drivers only implemented the new uAPI if their target userspace programs all use the new uAPI instead of an older uAPI. Nothing in userspace is "broken" because it will seem to the old uAPI using userspace as if there is no driver for the new GPU.

I suppose that theory is possible. A proxy for developer availability might be to check the primary mailing list of xorg for the full month of march: https://lists.x.org/archives/xorg-devel/2021-March/thread.ht.... There wasn't much directly related to xorg-xserver itself. As a point of comparison, here is March for QEMU: https://lists.nongnu.org/archive/html/qemu-devel/2021-03/thr...

There is a lot of detail about this in the kernel docs: https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#ope...

The gist of it is that breakage is OK if the userspace isn't open-source and that new uAPIs come around every few years due to the rapid pace development of GPUs.

I worked on Chrome OS graphics for years on and one of my earliest projects was to bring DRM/KMS (then a newish interface) to the Cirrus display card (an ancient card that QEMU happens to emulate).

The kernel can choose to not support new hardware with old interfaces. If the X11 can't interface with new hardware, that's game over. No broken userspace necessary.

That link seems to imply they embracing GBM by implementing a backend for it.

The issue is X11 as we know it has no developers left. If nobody is around to maintain it, the world will move on, no ramrod necessary. More info: https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...

Totally agree about the keyboard and processor/ram. Originally thought about getting the X13, but I recall the screens options weren't that good, and I prefer the larger size and bigger battery anyways.

As for Linux, I fully intended to dual boot Arch and Windows. Due to circumstance, I am stuck with a tiny 128GB NVMe and so I am using the default Windows for now. I've been watching this playlist of a user installing Arch on their T14s to help prep me on some of the quirks: https://www.youtube.com/watch?v=ihFPynCqfzc&list=PLiKgVPlhUN.... I hope that helps answer some of your questions.

I first checked which panels were the good ones here: https://www.notebookcheck.net/Lenovo-s-Panel-Lottery-continu..., which indicates Innolux is the panel to get. Then I went to https://support.lenovo.com/ie/en/partslookup and punched in my serial number, located near the bar code on the bottom of the laptop. From the "Parts" tab select the "Commodity Type" as "LCD PANELS" and you should see something like "FRUofAUO14.0FHDIPSAG" indicating I get the "AUO" manufactured LCD panel. If you are particular about getting the Innolux, you can use the substitutes button to figure out the lenovo replacement part number for the desired LCD Panel. For the Innolux on the T14s, it could be ordered here: https://lenovo.encompass.com/item/12401836/Lenovo/01YN156/, but it seems to be currently out of stock.

I just got my T14s that I customized with 32GB, Ryzen 4750u (8c/16t), and the 400nit display (sadly lost the display lottery, but I didn't notice until I checked the part#). However, it took 60+ days to ship as I ordered it Sep 1st. I suppose the shortage of the Ryzen chips mean long delays for Lenovo laptops which are customized as opposed to the preconfigured variants. All of the preconfigured ones had the 250nit screen and 8-16GB however.

ChromeOS uses Rust for crosvm, which Amazon's firecracker was derived from.

I had the same exact effect on my Pixel 3a. Happened 3 times in a row.

The crosvm project which powers crostini is both open source ( https://chromium.googlesource.com/chromiumos/platform/crosvm... ) and on many people's machine (most Chromebooks) which might fit some definition of not controlled and not uniform.

Indeed it was that lwn article that I used as a reference to write the very first code in crosvm. Excellently written.

When I found this sight, I was uncertain if one could still buy this device or if the owner was even still active, but then I checked the front page: "March, 2020: Orders may be delayed due to the COVID-19 situation. Thank you for your patience and understanding." The previous news post was from 2017. I think the owner's commitment to this project is amazing. I think that that the owner had to explicitly call out delays due to COVID-19 is also noteworthy.

As someone who wrote a precursor to that code (I work on crosvm), any language other than C has to write binding code for KVM (or any kernel interface for that matter). Are you suggesting that the only language that should get to use KVM is C (and other languages that can consume C headers)?

Additionally, when KVM gets new features, the hard part will not be adding more bindings to that crate; it will be utilizing that feature, which would have to happen in any langauge.

This topic is also of interest to me. I work on a compositor integration protocol called virtio-wayland that is intended to allow Wayland apps running inside of VMs to communicate with a Wayland compositor on the host, shared memory and all. It's used for the Linux apps support for Chrome OS.

This MVP already looks very polished and I think the design is innovative. I coincidentally noticed the gap in open-source for motion graphics, but never got passed the notebook phase. One of the pieces I kept getting stuck on was the way to correctly model all that timeline data and applying it to the scene. Could you comment on your approach to that for this product? I also would like to echo the desire to see it open-sourced.

We felt the same way about QEMU before we started crosvm. Glad to see you all found some use out of it.

In case you're interested in the technical guts of crostini, I gave a recorded talk to the NYLUG: https://www.youtube.com/watch?v=WwrXqDERFm8

(I'm crostini developer) Chrome OS has some natural advantages as an OS e.g. it's always updated and secure, device drivers just work. Chrome OS is also the only desktop OS with Android support maintained by Google. Because Crostini uses Linux containers, more Linux programs can be used in development than MacOS, and any linux distribution that runs under LXD can be used. Chromebooks can also be found in certain places more commonly than macbooks, e.g. at schools or as part of a company's fleet of hardware.

The Wayland compositor was added to the Chrome OS UI to support Android, but it was very convenient for us to glob onto that for the Linux desktop apps support.

https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...

Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS.

Sadly, not many of the components within crosvm would make good crates in crates.io. The crates in crosvm tend to be laser focused on solving a specific use case within crosvm. There are more general versions of lots of the functionality we have in crosvm that exist in crates.io (e.g. eventfd or memory maps) that we skipped to avoid excessive external dependencies.

Also, the Wayland stuff looks cool but I'm not sure how you are managing the buffers with just the wl protocol.

The virtio wayland I designed is intended to be somewhat agnostic of the underlying wayland protocol for simplicity. It just passes along the protocol bytes to the host's wayland compositor. In order to share FDs with the host (to support e.g. buffers and keymaps), crosvm has a mapping of virtual file descriptor IDs known to the guest kernel to host FDs that get passed along to the wayland compositor.

though it would be cool to support the virtio p9fs as a root filesystem.

We considered it, but for our application, 9pfs was not going to be optimal. That being said, we'd welcome patches that added support for it. :)

And, I know you can't say anything about this, but I'm happy to see the arm support in there

The ARM support is rather preliminary. crosvm will compile for ARM but it has yet to succesfully boot a VM.

Thanks! I've really appreciated your Rust guides over the years. It's been so handy that we pre-ordered 5 copies of your Rust Programming Language book a few months back. I can't wait to get my hard copy. :)

There is a somewhat expanded README that has yet to be reviewed and checked in here: https://chromium.googlesource.com/chromiumos/platform/crosvm...