Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: How does intel-ucode depend on systemd? (Read 1006 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How does intel-ucode depend on systemd?

Hey guys! How does intel-ucode depend on systemd? If it doesn't depend on systemd, then why do you have intel-ucode in the world repo?
 

Re: How does intel-ucode depend on systemd?

Reply #1 –
Please direct this question: "why do you have intel-ucode in the world repo?" to Archlinux team since we follow their structure as close as we can.

Re: How does intel-ucode depend on systemd?

Reply #2 –
Quote from: SGOrava – on
Please direct this question: "why do you have intel-ucode in the world repo?" to Archlinux team since we follow their structure as close as we can.
Apparently, I asked the question incorrectly. Artix users can easily install intel-ucode from Arch's extra repo. There is no reason for intel-ucode being in Artix's repositories.

Re: How does intel-ucode depend on systemd?

Reply #3 –
Try -Si and at this moment you'll see the versions in world and extra are at different versions. This happens with many packages to ensure they remain at compatible versions. And Artix has a long term goal to provide all packages from Artix repos.
(It's also worth checking what ucode version your BIOS provides vs what's in intel-ucode, on some machines it has the latest version already if your BIOS is up to date so this doesn't need to be installed.)

Re: How does intel-ucode depend on systemd?

Reply #4 –
Quote from: ####### – on
This happens with many packages to ensure they remain at compatible versions.
In case with intel-ucode, it doesn't have to be compatible with something, afaik. I don't see any reason not to update it to the mainstream version.
Sorry for being obtrusive.

Re: How does intel-ucode depend on systemd?

Reply #5 –
EDIT:
Quote from: fehigax145 – on
Apparently, I asked the question incorrectly. Artix users can easily install intel-ucode from Arch's extra repo. There is no reason for intel-ucode being in Artix's repositories.

There are some critical packages (including the processor's firmware) that we just need to have  (regardless of archlinux).

Re: How does intel-ucode depend on systemd?

Reply #6 –
Well in the general case that may be true, but I think for example when the Meltdown and Spectre modified ucode was released there were also changes to the kernel that complimented it, and you might have got poor performance otherwise. The kernel loads the microcode, and the microcode can affect how the CPU behaves, so it's probably just easier to keep the versions in sync with what has been tested elsewhere, because the Artix kernels are usually slightly behind the Arch versions and some minor releases are skipped. It's not really easy to test either unless you have or can emulate every type of hardware it supports to check it with.  If you want the Arch version then just specify the repo name before the package to pull from the alternate location:
Code: [Select]
$ pacman -S extra/intel-ucode
(I'm not sure how that works over upgrades though, or if any additional config would be needed.)
Anyway if you got the file direct from Intel as soon as it was released, (it's just a bunch of files you copy to the relevant directory, and you usually only need one of them) you would be ahead of Arch too I expect, because they run things though testing first.

Re: How does intel-ucode depend on systemd?

Reply #7 –
If you want the latest microcode in a package there's the AUR package intel-ucode-platomav-git but on it's repo here:
intel-ucode-platomav-git
it says:
"It is generally advised to request and/or wait for your OEM/OS to release newer fixes. Latest is not always better or tested. Manufacturers and OS maintainers usually have some insider/confidential info from microcode vendors on what got changed/fixed at newer microcode releases so if they ship older microcodes, it could be that newer versions have not been thoroughly tested, have been retracted/downgraded by the microcode vendor or not contain anything important enough to warrant an update."
(I'm not saying you shouldn't make your own decision what to use personally, but it's an explanation why the official version is what it is.)