Intel-Linux-Processor-Microcode-Dat
dysnomia
Intel-Linux-Processor-Microcode-Dat | dysnomia | |
---|---|---|
4 | 2 | |
- | 80 | |
- | - | |
- | 4.0 | |
- | about 1 year ago | |
Shell | ||
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Intel-Linux-Processor-Microcode-Dat
-
There is no fix for Intel's crashing 13th/14th Gen CPUs – damage is permanent
So where is the microcode update? I don't see anything for Linux yet.
https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
-
On “I don't trust microcode”
They have been sort of cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files.
https://ieeeaccess.ieee.org/featured-articles/reverseenginee...
https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
https://github.com/platomav/CPUMicrocodes
-
I Love Arch, but GNU Guix Is My New Distro
Is it anymore of a "magic incantation" than the linux-image-XYZ package which controls which OS kernel is installed?
If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
-
CPU May Have Slowed Down on Wednesday
It isn't clear if Haswell has this optimization. As an easy test you could run the zero-fill-bench linked in the post and check the fill0 vs fill1 numbers. If they are the same, Haswell probably never had this optimization in the first place.
Based on the Intel microcode release note [1] it doesn't seem like client HSW got any update this time, only HSX (Haswell Xeon).
---
[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
dysnomia
-
What are NixOS's limitations?
NixOS doesn't have much, if anything, in the way of state management for services like databases. The Nix-iest way I know of managing those things is to write Dysnomia plugins for those things. But you'll have to figure out managing their internal state yourself to do that, e.g., with something like Liquibase or Flyway or something like that.
-
I Love Arch, but GNU Guix Is My New Distro
Depends on how the state is stored. If it's in configuration, Nix generated it and it lives immutable in the Nix store, so Nix will just point out it to the old version on rollback.
If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take.
The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia
It's been around for a long time. Idk who all is using it
What are some alternatives?
Intel-Linux-Processor-Microcode-Data-Files
pacman-bintrans - Experimental pacman integration for Reproducible Builds and Binary Transparency (with sigstore/rekor)
userscan - Scans files for Nix store references and registers them with the Nix garbage collector.
iota - A terminal-based text editor written in Rust
score - ossia score, an interactive sequencer for the intermedia arts
nonguix
nixpkgs - Nix Packages collection & NixOS
cargo-crev - A cryptographically verifiable code review system for the cargo (Rust) package manager.