W AUR znajdują się dwa skrypty umożliwiające budowę kernela z dość popularnym patchem -pf. Patch ten nie tyle jest autorskim rozwiązaniem Natalenki, ale po prostu zestawieniem kilku patchy w jeden (podobnie jak to ma miejsce przy lqx). Niekiedy Natalenko robi jakieś własne zmiany, niekiedy implementuje tam patche rozwijane obok głównego ich źródła (np. patch BFS, który często jest tam w wersji Chena a nie Kolivasa). Jednym z takich patchy, który znajduje się w -pf jest "graysky GCC optimization patch". Jest to patch rozszerzający możliwości kompilatora gcc o inne jeszcze, niż tradycyjne, optymalizacje (m.in. dla nowszych procesorów AMD i Intela). Od jakiegoś czasu, autorski patch Natalenki zawiera rozwiązanie Graysky'ego, którego minimalne i maksymalne wymogi odnośnie kernela i gcc są następujące:
- kernel nie może być w wersji niższej niż 3.15,
- gcc musi być w wersji co najmniej 4.2 i nie wyższej od 4.9.0.
Tymczasem w Archu mamy obecnie taką sytuację:
- kernel "zwykły" to 3.18.x (i nadchodzący 3.19),
- kernel LTS to 3.14.x
- GCC jest w wersji 4.9.x.
W AUR linux-pf jest w wersji 3.19, czyli buduje kernel w oparciu o najnowszy, stabilny kernel 3.19, natomiast linux-pf-lts oparty jest o wersję 3.14.
Wykorzystanie możliwości optymalizacji kernela pod określony jego rodzaj/rodzinę jest zatem iluzoryczne (aczkolwiek, przynajmniej w przypadku linux-pf jest ono możliwe, o czym później).
Jedną ze zmian, które przyniosło wydanie gcc w wersji 4.9 była zmiana nazewnictwa tzw. flag kompilatora, szczególnie dla procesorów Intela. Patch GCC, który został zaimplementowany do patcha -pf jest dostosowany do GCC w wersji od 4.2 do 4.8 (włącznie) i stosuje ich nazewnictwo flag. Jeśli zatem będziemy próbować zbudować kernel dla procesora Intel z użyciem możliwości, jakie daje patch -pf na obecnym oprogramowaniu dostępnym w Archu, to wówczas otrzymamy wadliwy kod wynikowy dla kernela (będzie on bowiem "obarczony" budową z wadliwą flagą). Taki kernel może, ale nie musi poprawnie działać. Wydaje się, że jeszcze gorsza sytuacja występuje w przypadku kernela linux-pf-lts, albowiem tutaj nie tylko, że niedostosowane są flagi kompilatora, ale również patch ten został przygotowany z myślą o nowszej wersji kernela, niż ta w oparciu o którą tworzony jest kernel pf-lts.
Oczywiście, jeśli nie włączymy (podczas swojej pracy, patch Natalenki zadaje nam pytania) optymalizacji GCC, to wówczas otrzymamy prawidłowo działający kernel (bo będzie to tzw. generic, czyli bez optymalizacji).
Możemy też pokusić się - przynajmniej w odniesieniu do kernela linux-pf - o próbę mimo wszystko zbudowania zoptymalizowanego kernela. Jedną z możliwości, jakie daje ten patch jest bowiem możliwość uruchomienia narzędzia do "ręcznego" dostosowania kernela (*config np. gconfig, nconfig czy xconfig). Wówczas jeśli chcemy dokonać dostosowania swego kernela do rodzaju procesora musimy wybrać "Native" (a nie nazwę rodziny naszego procesora). Podobną możliwość daje odpowiedź na jedno z pytań dotyczących optymalizacji, a mianowicie odpowiedź, że chcemy budować "natywny" kernel. Wówczas zostanie on zbudowany z flagą -march=native -mtune=native.
EDIT:
1.03.2015 r. Oleksandr Natalenko wypuścił nową wersję swego patcha dla kernela 3.19, która zawiera patch graysky'ego (GCC) w najnowszej, dostosowanej do GCC 4.9, wersji. Jednocześnie w AUR pojawiło się dziwacznie numerowane wydanie kernela linux-pf, noszącego numer. 3.19.2 (czyli - wg przyjętej numeracji kerneli - jakby drugiego wydania poprawkowego z linii 3.19, którego jeszcze nie ma), które zawiera już patch w nowej wersji.
Teraz problem trafił do tych dystrybucji "pacmanowych", które nie mają jeszcze gcc w wersji 4.9.x, bądź będzie udziałem osób, które z jakichś powodów, nie zaktualizowały go do wersji obecnie istniejącej w repozytoriach.
W zakresie kernela pf-lts - nie zaszły żadne zmiany.
