@Farkas: Nie gloryfikuję Archa. W ogóle odległy jestem od tego, by rozpoczynać jakąkolwiek kolejną wojenkę dystrybucją X vs. Y.
Twoje zdanie odbieram jako chęć dowiedzenia się czegoś o Archu, zatem służę informacją. Czy Arch jest stabilny? Stabilność (jeśli chodzi o “niewywalanie się”) Archa jest w głównej mierze pochodną tego jak się z nim obchodzi użytkownik. Arch też ma swoje repozytoria “unstable” (dwa - dla testowania nadchodzących wydań Gnome i KDE), “testing” oraz stabilne. To te ostatnie są dla użytkownika. Repozytorium “testing” można przyrównać do “testing” w Debianie (czy np. Factory w OpenSUSE). Oba *-unstable są repozytoriami “preview”. W okresie obu testowań powinny zostać wychwycone błędy w paczkowaniu itp. Niekiedy wychodzą również jakieś błędy upstreamowe (które są niezależnie od tego, czy mamy daną paczkę w Debianie Stable, czy w Arch Testing 
- jeśli w końcu do Debiana Stable trafi ta paczka, która ma upstreamowe błędy i które nie zostały naprawione do czasu wydania Stable, to w owym Stable pojawi się paczka z błędami; w tym czasie upstream może już przygotować jakąś poprawkę, ale dołączy ją do następnej wersji, której w Debianie Stable już nie będzie). Niezależnie od tego jest jeszcze repozytorium “oczekujące” - staging, gdzie paczki spokojnie sobie czekają na spełnienie się zależności itp., by wejść do repozytoriów stabilnych. W repozytorium testowym i stabilnym winny być (i - jeśli chodzi o to drugie - praktycznie w 100% są /tzn. nie znam innego przypadku/) paczki, które zostały względem siebie przebudowane, jeśli zachodzi taka potrzeba. Innymi słowy - to co w stable, to powinno gwarantować możliwość spokojnej pracy.
Wbrew powszechnej opinii, to repozytorium stabilnego nie są wrzucane na łapu capu wszystkie nowe programy tylko i wyłącznie dlatego, że uzyskały nową wersję. Dla przykładu pomimo tego, że kernel 4.9 został wydany 11.12.2016, to do dzisiaj tej wersji nie ma w repozytorium stabilnym (dalej w testowym jest 4.9.4) i trafi do stabilnego, gdy się stwierdzi, że nie powoduje problemów, czego obecnie powiedzieć nie można.
Czy tak w 100% jest? Nie jest. W głównej mierze wynika to z tego, że mało kto ma Archa “stable” tylko i wyłącznie. Użytkownicy nagminnie korzystają z repozytoriów nieoficjalnych, czy budują paczki z AUR, często też przez długie (zbyt długie) okresy czasu nie aktualizują systemu - i stąd wynikają problemy.
Czy nowy kernel powoduje problemy z grafiką? W danym momencie, w repozytorium znajdują się skorelowane ze sobą kernel, Xy, sterowniki, które w 99% przypadków działają prawidłowo. Ten 1% znów w dużej mierze jest zależny od użytkownika.
Używanie Archa niewiele zatem różni się od używania Debian Testing, z tą różnicą, że celowo Arch nie jest mrożony na pewnien okres, jak to ma miejsce w przypadku Debiana, gdy Testing staje się Stable. Używając jednego i drugiego, mogę powiedzieć wyłącznie tyle, że więcej miałem problemów ze “wznowieniem się” rollingowego trybu Testing po zamrożeniu niż w przypadku Archa (którego mam zresztą w wersji testing :)).
Jeśli chodzi o wcześniejsze. Zgoda. Fajnie by było mieć system, który wg nas nam odpowiada. I każdy chyba do tego powinien dążyć. Natomiast nie jest tak, że wyłącznie poprawki bezpieczeństwa są interesujące. W ramach nich nie dostaniesz np. poprawek, które usuwają jakieś błędy, które nie mają statusu “błędu bezpieczeństwa”, o polepszeniu funkcjonalności (m.in. nie otrzymasz możliwości otwarcia formatu X, choć to jest już możliwe, bowiem w “stabilnej” wersji masz jeszcze wersję, która tego nie obsługuje) już nie wspomnę. Skoro mówisz natomiast o poprawkach bezpieczeństwa, to rozmawiamy do Debianie Stable. Skoro rozmawiamy o tym w kontekście KDE, to… o żadnym “bezpieczeństwie” istniejącego tam KDE4 mówić nie można, ze względu na to, że nikt się tym nie zajmuje (z wyjątkiem jednej biblioteki, która i tak raczej nie będzie wspierana do 2020 r.). Jeśli Debian przejmie kod Qt4 i KDE4, będzie zajmował się jego bezpieczeństwem - zwracam honor.