Linux Brief — 27 września 2026

Najnowsze informacje z ekosystemu Linux wymagają przede wszystkim porządkowania planów testowych i cykli wsparcia. Poniżej dwa tematy do weryfikacji przez administratorów: przedpremierowy PostgreSQL 19 oraz aktualne gałęzie jądra publikowane upstream.

PostgreSQL 19 Beta 4: testy oddzielone od migracji produkcyjnej

PostgreSQL 19 Beta 4 ogłoszono 24 września 2026 r. Jest to wydanie przedpremierowe przeznaczone do testów, a jego szczegóły mogą jeszcze ulec zmianie. Projekt nie zaleca wdrażania wersji beta w środowiskach produkcyjnych, lecz zachęca do sprawdzania typowych obciążeń.

Temat dotyczy zespołów utrzymujących PostgreSQL, zwłaszcza instancje nadal działające na gałęzi PostgreSQL 14. Jej wsparcie kończy się 12 listopada 2026 r. W praktyce warto rozdzielić dwa działania: testy zgodności aplikacji i workloadów z betą PostgreSQL 19 oraz przygotowanie planu odejścia od starszej, wspieranej dziś gałęzi.

Wpływ dotyczy harmonogramu utrzymania baz danych, oceny ryzyka zmian i przygotowania środowisk testowych. Jako propozycję redakcji warto sprawdzić, które instalacje pozostają na PostgreSQL 14, jaki mają plan przejścia na wspieraną gałąź oraz czy testowe środowiska odzwierciedlają typowe obciążenia. Beta nie powinna być przedstawiana jako docelowa wersja migracji produkcyjnej.

Kernel 7.2.8 i 6.18.54: weryfikacja polityki utrzymania

Kernel.org datuje wydania stable 7.2.8 i longterm 6.18.54 na 25 września 2026 r. Wydaniem mainline pozostaje 7.3-rc4 z 20 września, natomiast wydanie 7.1.13 zostało oznaczone jako EOL.

Informacja jest istotna dla administratorów systemów Linux, którzy śledzą status gałęzi upstream lub zarządzają wyjątkami od standardowego modelu aktualizacji dostawcy. Same numery wydań nie przesądzają jednak o potrzebie instalacji upstreamowego kernela w konkretnej dystrybucji. Strona projektu nie potwierdza także, jakie poprawki bezpieczeństwa znajdują się w pakietach poszczególnych dystrybucji.

Wpływ obejmuje ocenę cyklu życia używanej gałęzi oraz zgodność z polityką dostawcy systemu. Jako propozycję redakcji warto sprawdzić, jaki kernel jest utrzymywany w używanej dystrybucji, czy obowiązują lokalne wyjątki oraz czy wykorzystywana gałąź ma nadal status wsparcia. Najnowszy numer upstream warto traktować jako sygnał do porównania polityk, a nie automatyczny nakaz zmiany kernela.

W obu przypadkach kluczowe pozostaje oddzielenie informacji o publikacjach upstream od decyzji wdrożeniowych podejmowanych zgodnie z własnym cyklem zmian i wsparciem dostawcy.