"Project X" - Pure Open-Source Coreboot Support On AMD Zen

[R41N3R]

Exactly, my MSI X570 mainboard takes 23 seconds to be ready. This is the worst board I've ever had. And there is nothing you can do about this proprietary shit.

[f0rmat]

Paranoia increases as big companies' data collection practices (e.g. Microsoft and Google) get worse.

Not just them - social media, too - which is why I stay away from almost all of them. Hell, it is so bad, I can sometimes tell what my wife is shopping for by seeing adds when I on the internet. I have had my identity stolen once - and that was due to a data breach, not anything that I did.

And do not forget the censorship practices - but I do not think Coreboot will help for that.

[Old Grouch]

While I'm a long-time C/C++ developer with little love for Rust, would my key interest in this be how much faster a machine is able to boot under Project X. If Project X manages to get faster boot times then this would be great, but any slower than it already is would not interest me. I rather keep the closed-source, proprietary BIOS blobs over any free, open-source Rust-based but slow code. So I'm hoping it allows for significantly faster boot times.

Could you possibly satisfy my curiosity and describe what you use faster boot times for? What part of your workflow is affected by slower boot times? It is not often I need to restart my bare metal, but it is possible you do; and similarly, I don't make extensive use of VMs that need to be spun up on demand.

Demand-led booting of VMs strikes me as odd. If boot time is on the critical path, I'd look at starting a pool of VMs in advance and holding them in reserve ready to be used when the demand hits. The technology should exist to allow a quiescent VM to use almost zero resources, but be available to be connected to once demand arrives. If this is not the case, then VM technology is not mature.

[deusexmachina]

Would this mean having the ability to minimize/disable PSP too?

Good question!

[deusexmachina]

While I'm a long-time C/C++ developer with little love for Rust, would my key interest in this be how much faster a machine is able to boot under Project X. If Project X manages to get faster boot times then this would be great, but any slower than it already is would not interest me. I rather keep the closed-source, proprietary BIOS blobs over any free, open-source Rust-based but slow code. So I'm hoping it allows for significantly faster boot times.

You're making no sense... "Please keep it closed because it might increase boot times." You're welcome to use AMD without Project X, Mr. Rusty Programmer. Servers don't need fast boot times, but we do really like verifiable security. Not that there is any evidence that this would decrease boot speed.

[Mathias]

"if it boots faster, I'm all for it. If slower: keep your crap"

You're making no sense...

You're making no sense... Why does it make no sense to only care about boot speed? Might not be what you care about, but it is a legitimate thing to care about.

[jo-erlend]

Demand-led booting of VMs strikes me as odd. If boot time is on the critical path, I'd look at starting a pool of VMs in advance and holding them in reserve ready to be used when the demand hits. The technology should exist to allow a quiescent VM to use almost zero resources, but be available to be connected to once demand arrives. If this is not the case, then VM technology is not mature.

You can SIGSTOP a VM, of course, but allocated RAM is still allocated and that's a bottleneck. But a more important point is you want to shutdown your hypervisors when you don't need to have them running.

[Guest]

An open firmware is an essential piece that AMD should support sooner than later. For me this would be as well a reason to replace several systems. UEFI is one of the worst things that is enforced on every system. It is terribly slow and insecure. Plus many vendors refuse to provide proper support.

You'd still be using UEFI, just an open source implementation instead of a closed source one.

[pal666]

It would be a huge gamechanger if amd could be booted blob-free.

amd doesn't produce open hardware. it's one large blob of dozens of billions of transistors over which you have zero control

[pal666]

Demand-led booting of VMs

has nothing to do with board firmware