userscan
Intel-Linux-Processor-Microcode-Data-Files | userscan | |
---|---|---|
19 | 1 | |
604 | 35 | |
1.8% | - | |
4.4 | 3.8 | |
about 2 months ago | over 3 years ago | |
Rust | ||
GNU General Public License v3.0 or later | BSD 3-clause "New" or "Revised" 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-Data-Files
- Intel Issues New CPU Microcode Going Back To Gen8 For New, Undisclosed Security Updates
-
N100 wait or done with it ?
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md looks like they released a new microcode (24000024) affecting these units on Feb 14th this year.
-
Why is intel-microcode missing in the unstable repo?
Package: intel-microcode Version: 3.20221108.1 Priority: optional Section: non-free/admin Maintainer: Henrique de Moraes Holschuh Installed-Size: 6460 kB Depends: iucode-tool (>= 1.0) Recommends: initramfs-tools (>= 0.113~) Conflicts: microcode.ctl (<< 0.18~0) Homepage: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files Tag: hardware::TODO, role::app-data, use::driver Download-Size: 4509 kB APT-Sources: http://deb.debian.org/debian testing/non-free amd64 Packages Description: Processor microcode firmware for Intel CPUs
-
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
-
Westworld - 4x06 "Fidelity" - Post-Episode Discussion
Not to “well aktchually”, but all modern processors do have regularly updated microcode that’s uploaded at boot time - https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
-
My CPU's microcode is missing
6-94-3 would become 6-5E-3. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/6c0c4691e5bb446e0e428ebca595164709c59586/intel-ucode/06-5e-03
-
amd cpu firmware microcode ? (-current)
OpenBSD kernel has no support for loading microcode on AMD CPUs, A number of issues/errata on AMD systems may be fixed as part of AGESA updates, in addition to microcode as part of BIOS/firmware updates. While there have been microcode updates released for Zen+ or newer CPUs, but these seem to be less frequent than Intel.
- Will you still use Cloudready? Yes/No and why? Please...
- Why is it assumed that microcode updates improve security?
-
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...
userscan
-
I Love Arch, but GNU Guix Is My New Distro
* having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan )
The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly.
For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’.
It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable.
But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.
What are some alternatives?
nonguix - Nonguix mirror – pull requests ignored, please use upstream for that
pacman-bintrans - Experimental binary transparency for pacman with sigstore and rekor
iota - A terminal-based text editor written in Rust
dysnomia - Dysnomia: A tool for deploying mutable components
Intel-Linux-Processor-Microcode-Dat
score - ossia score, an interactive sequencer for the intermedia arts
nonguix
cargo-crev - A cryptographically verifiable code review system for the cargo (Rust) package manager.