Melyik a leghosszabb támogatási időtartamot ígérő disztro most?

Linux-haladó

Kellene frissíteni pár gépet és lehet, hogy szempont lenne, hogy melyik az a disztro, amelyikhez a legjobb eséllyel a legtovább nem kell hozzányúlni, csak frissítgetni. Linux Mint vagy Debian Bookworm lenne enélkül a szempont nélkül, a Mint Virginia 2027 áprilisig írja magát, a Bookworm meg ha jól értem valamikor 2026 és 2028 júniusa között... szóval nem tudom. Olvastam olyat, hogy RedHat vagy Suse a leghosszabb LTS, igazán nincsen olyan használati szempont ami alapján ne lehetne bármi, de mondjuk a wireguard-dal szeretnék lehetőleg nagyon keveset szopni... ebből a szempontból a Mint lenne a nyerő, azt hiszem. Hogy látjátok?

  • 1855 megtekintés

( zrubi v | 2024. 01. 15., h – 21:37 )

Szerkesztve: 2024. 01. 15., h – 21:41

Attól függ, mit értesz támogatás alatt.

Ha céges, fizetős support-ot, akkor a RedHat Esetében erre számíthatsz:

https://access.redhat.com/support/policy/updates/errata

 

Ubuntu:

https://ubuntu.com/about/release-cycle

 

De a többi disztró is biztosan egyértelműen leírja mire lehet számítani náluk, google a barátod ;)

 

Hozzátéve, hogy a wireguard egy viszonlyag friss cucc, nem lepődnék meg ha 1-2 évvel később már fájni fognak a régi csomagok akármelyik LTS disztóban :D

zrubi.hu

( gelei v | 2024. 01. 15., h – 21:56 )

Szerkesztve: 2024. 01. 15., h – 21:56

Ubuntu Pro, 5 gepig ingyen van, vagy valami ilyesmi. 10 ev support.

( arpi_esp v | 2024. 01. 15., h – 22:27 )

Slackware 14, tobb mint 10 eves es most jart le a supportja. Bar tulzasba azert nem vittek az updateket :)

[memories]

Úú, én nagyon szerettem a Slackware disztrót. Főleg a live jött jól sokszor. Liveslak volt a neve talán? Volt egy weboldal, ahol a modulokat is össze tudtam hozzá válogatni, s úgy kaptam belőle .iso-t!

Pofás is volt és minden helyzetben működött, nem mint a társai anno.

[/memories]

( gabrielakos v | 2024. 01. 16., k – 08:12 )

Nagyon jó kis kérdés ez.
Egyik kedvenc témám: rendszerhatárok.

Nézzük meg ezt a wireguard-ra.

Ha 6 év múlva a wireguard kitalálja hogy ők kijönnek a 3.0-val és az nem lesz kompatibilis a mostanival akkor értelemszerűen a régi disztribúciódon belül "jó leszel".
De ha van egy windowsos vagy mac-es kliensed vagy nas-od vagy bármi amire az akkori oprendszerére csak a wireguard 3.0 fog kijönni akkor leszel bajban. Hogy a wireguardosok "épeszűen upgradelnek" arra 6-8 év távlatában semmilyen garanciád nincsen.

Ha a wireguard verziók csak az együtt upgradelt rendszereden belül érdekesek, akkor jó vagy.
Mindegyik tud ugyanolyan (aktuális vagy elmaradott) lenni. De disztribúción belül supportált leszel.

Én azt gondolom hogy a jelenlegi IT színvonalon nem tervezünk 1 évnél messzebbre kizárólag egy termék/cég ígéreteire alapozva.

Úgy építjük fel a rendszereinket hogy bármelyik komponens (relatív) meghülyülése esetére legyen viszonylag fájdalommentes kiutunk (aka vendor agnostic).

 

zászló, zászló, szív

Jep.

Én egyébként azt mondanám, hogy feltéve, hogy az RH egyébként featurenek tartja a wireguardot, akkor az talán egy jó bet, nekik azért van historyjuk arra nézve, hogy valójában nem öntenek betonba mindent ~10 évre, hanem backportolnak erősen, szóval van esély rá, hogy ha érdemi dolgok történnek a wireguard háza táján (ami esélyes), akkor pont legalább a kompatibilitás megtartásáig fognak valamit tenni, a többieknél ezt nem nagyon látom tendenciózusan.

Cserébe, ha nem feature, akkor le se fogják szarni. És ott a tech preview is azt jelenti, amit, simán volt már, hogy kidobtak olyat, pl btrfst (ráadásul nem is vagyok biztos benne, hogy legalább megrohadni megtartották-e abban a főverzióban, vagy simán csak kibaszták egy pointreleassel)

Ebben nagy igazságod vagyon. Az egy dolog, hogy a disztró mennyit ad rá, de maga az adott szoftver viszont korlátozhat, nem csak Wireguard, de PHP, Java, Python, Perl, stb. verzióknál is elő szokott lenni írva, hogy az adott verzió meddig támogatott. Használhatod utána is, de ha valami gond van vele, nem segítenek, nem vesznek be bugreportot az upstream fejlesztők, azt fogják hajtogatni, hogy tedd fel belőle a még támogatott verziót.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( bennyh | 2024. 01. 16., k – 08:56 )

De nem erre lenne jó egy rolling release disztró? Nem értek hozzá, csak kérdem :)

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Igen is, meg nem is.

Leginkabb igenyektol es hasznalattol fugg.

En a 6 havonta frissitos disztrokat mar kerulom, vagy LTS, vagy rolling.

Rolling eseten minden mas is frissul, es esetleg kompatibilitasi problemak johetnek elo. LTS eseten meg minden regi marad, mert csak security update-eket kap.

Ha nincs teleszemetelve, akkor egy ubuntunal is elvileg eleg egy `do-release-upgrade` par evente, es megy tovabb az elet.

Egyebkent en az alabbi opciokbol valasztanek:

  • Ha nem gond, hogy a program is regi, akkor LTS rendszer alap repositorykkal.
  • Ha kell friss program, akkor vagy rolling distro
  • vagy LTS rendszer + backports repo vagy flatpak/snap/appimage/docker

Midegyiknek megvan az elonye es a hatranya, a kerdes az, hogy mik a prioritasok, es az igenyek.

( persicsb | 2024. 01. 16., k – 10:22 )

RHEL, Van hozzá Developer Subscription, 16 gépig ingyen van.

( Raynes v | 2024. 01. 16., k – 12:42 )

Szerkesztve: 2024. 01. 16., k – 12:44

Én is azokat tudom említeni, amit előttem már írtak:

Ubuntu Pro (5 gépig ingyenes)
RHEL (erre is van ingyenes lincenc), Rocky, Alma

Illetve Slackware, ezen nincs soha hivatalosan beígért és számon kérhető támogatási idő, de a főverziók annyira ritkán jönnek ki belőle, hogy pl. az utolsó 14-es verzió 12 évig volt támogatott, gyaníthatóan a 15-ös mostani kiadás is húzza minimum addig, amíg a 16-os verzió ki nem jön. Nem céges disztró, nem igényel külön előfizetést, de nagyon lassan mozgatja a dolgokat, a világ legkonzervatívabb disztrója. Az RHEL, Debian stable, Ubuntu LTS, Mint hozzá képest rohanó, modern valami, pedig azok is lassúak.

A SUSE-nél eléggé meg van variálva, hogy melyik termékükre mennyi támogatási idő van, Enterprise Server és Desktop vonalnál 10+extra 3 évet látok, de ez szerintem fizetős, passz, hogy mennyibe kerül.

Esetleg Arch. Ha jól értem, csak újratelepíteni nem akarod, az oké, ha helyben frissítgeted a meglévő telepítést, erről szól a full rolling. Ilyen metodikával az Arch örökké frissíthető, mert bár támogatás nincs rá, ahogy kijön egy csomagból egy új verzió, az előző máris nem támogatott, ez néha van, hogy csak 24 óra! Viszont sose kell újratelepítened, ha jól csinálod, csak rendszeres (pl. havi) ütemezésben nyomatni rá a pacman -Syu parancsot, más teendőd nincs. Ha megnézed a redditen, meg néhány fórumon, vannak userek, akik 10+ éves Arch telepítést görgetnek maguk előtt, és még mindig működik nekik.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ha van tapasztalatod, nem kell vele foglalkozni. Én már majdnem 9 éve használom, idestova már a 6 gépen, szaros netbooktól, laptopokon át a desktopig, mindenféle gépre, vegyesen Intel, AMD, mindenféle GPU, integrált, dedikált, különböző Wi-Fi, desktop, gaming, programozás, most ráadásul hozzájött egy spéci DAC-os, audio interface-es, gitáros, DAW és pluginezős, JACK felhasználás is, teljesen simán veszi az akadályokat, még ilyen Pulseaudio-Pipewire-Wireplumber váltás is teljesen simán ment, zökkenőmentes vele a Wayland, stb.. Szerveren még annyi gond se lenne vele.

Nagyon ritkán van az, mikor a pacman frissítésnél be kell avatkozni, mert nem tud valamit felülírni, vagy meg kell engedni neki kézileg körkörös függőség, stb. feloldását, évente 1-2 alkalommal van ilyen, nem is mindenkit értint, ilyen az Arch oldala szokta írni, hogy mit kell beavatkozni, nem egy nagy szám, pontosan írják mit futtass, nem neked kell nyomozni meg debugolni. Annyira érdemes figyelni, hogy azért kb. havonta nem árt frissíteni, afölött okozhat gondot, tipikusan fél-egy évnél van az a választó, ha valaki olyan ritkán frissít (lehet az automatizálva is), akkor belefutnak némi gondba, de azok is általában rutinból megoldhatók, ha valaki nem nagyon egység sugarú.

Csak azért mertem említeni, mert egyértelmű, hogy a kollégának nem a támogatási idő a fontos, hanem újratelepíteni nem akar, meg fő kiadások között upgrade-elni (Debian, Ubuntu származékok, stb., Fedora is hiába rolling, csak félrolling, kiadások között kell ugrálni ott is, és csak egy kiadáson belül lesz rolling). Természetesen nem csak az Arch full rolling, Artix, Void, Gentoo, stb. is ugyanez. Az Archnak most már a telepítése sem problémás, mivel nem hogy van már archinstall hivatalos szkript, de már jó pár verzió óta, néhány éve kiforrotta magát, így még normibbaknak is teljesíthető, nem kell már Arch Wiki alapján szenvedniük, meg megtanulniuk olvasni, technikai szöveget értelmezni, parancsokat megtanulni felparaméterezni, ahogy előtte.

Pont ez a rolling titka, rendszeresen frissítesz, egyszerre csak pár csomag újul meg, így folyton csak kicsi lépésekben változik a rendszer. Pont az a kockázatos, amit a kiadás alapú disztrók csinálnak, hogy mikor distupgrade-del főkiadást ugorsz, akkor hirtelen 2000+ csomag változik meg nagyon durván a rendszeren, és ilyenkor tudnak igazán dolgok látványosan eltörni, félremenni.

Ez ráadásul nem csak az én véleményem, redditen, Phoronixon is elég sokan megerősítik, hogy használtak már minden disztrót, és összességében az Arch volt nekik a legproblémamentesebb. AUR-ban megvan minden, nem kell külső tárolózni, PPA-kat vadászni, nonfree/fusion tárolókkal szenvedni, nincs dependency hell, meg flatpakozási kényszer, mivel a tárolókban minden verzió új, nem keletkezek kielégíthetetlen függőségek, normálisak a deafult konfigos beállítások, stb.. Nyilván egy minimális skill azért kell hozzá, teljesen kezdő Linuxosnak nem ajánlanám, de a kolléga nem tűnik annak.

Ha valakinek nem tetszik az archinstall, hogy az továbbra is csak egy tty-ban futó shell script, akkor felteheti az Arch-ot Arco Linux formájában is, az rendes grafikus Calamares telepítővel is tudja ugyanazt, Ubuntu normi módra. Esetleg az Endevour is ugyanaz, mindkettő az Arch tárolókat, pacmant, stb. használja, nem tartanak vissza csomagokat, ahogy a Manjaro.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ha van tapasztalatod, nem kell vele foglalkozni. 

...

Nagyon ritkán van az, mikor a pacman frissítésnél be kell avatkozni, mert nem tud valamit felülírni, vagy meg kell engedni neki kézileg körkörös függőség, stb. feloldását, évente 1-2 alkalommal van ilyen, nem is mindenkit értint, ilyen az Arch oldala szokta írni, hogy mit kell beavatkozni, nem egy nagy szám, pontosan írják mit futtass, nem neked kell nyomozni meg debugolni. 

Jól láthatóan nem érted a problémát (de legalább megint egy hosszas mindenfélét tartalmazót iderittyentettél, jackkel meg anyámmal egy láthatólag szerveres topicba). De igen, kell vele foglalkozni. Amikor random időpontban bekerül egy szoftver új főverziója, tehát nekem akkor azzal foglalkozni kell, hogy lekövessem a változásokat, rögtön de azonnal, mert addig nem tudok frissíteni, az nem jó. Az, hogy a random update úgy megy le, hogy a leírt módon meg kell kalapálni, az szintén nem jó.

Értem én, hogy a redditen meg a phronixon mindenki örül ennek, mert összességében jó (egyébként rolling desktopnak valószínűleg tényleg az), de azt nem érted, hogy üzleti környezetben sokkal könnyebb kezelni azt, hogy mikor kijön az új nagy release, akkor fogom a saját dolgomat átállítom, letesztelem, rolloutolok. Ha kell, akkor hosszan reszelve, mert nem ég a nyakamba a ház, ez egy tervezhető feladat.

A csak firssíteni kell az azt jelenti, hogy nem kell félnem, hogy random időben megbicsaklik a futó szolgáltatásom, mert nem fog egy frissítés ilyet hozni a nyakamba.

AUR-ban megvan minden, nem kell külső tárolózni, PPA-kat vadászni, nonfree/fusion tárolókkal szenvedni

Ez is hallod, ja szeretném a prod környezetben a fasztudja módon karbantartott AUR csomagot használni, és fordítani! a prod rendszeren.

Az a baj, hogy életedben nem láttál még rendes üzemeltetést, és fingod nincs, mik ott az igények, aztán extrapolálsz valami marhaságot. 

Valamilyen szintig foglalkozni minden rendszerrel kell, ezzel ne is áltasd magad. A leglassabb, legstabilabb LTS, meg corporate rendszereken is össze tudja bármi fosni magát update-kor, GRUB-tól elkezdve az X-en át, a fene tudja miig, láttam már erre példát Debianon, Ubuntun, Minten, stb.. Csak maximum ilyenkor várhatod valakitől a támogatást, meg hogy megoldják helyetted, míg Archon neked kell elkezdeni Wiki-t, man-t nyálazni, vagy a fórumon kuncsorogni, ahol ha találsz valaki rendesebb embert, akinek megesik rajta a szíve, lehet segít, vagy kifogsz egy isten komplexusos, elitista archer modot, aki meg csak lelámáz és elküld vissza a női felmenődbe meg RTFM olvasgatni.

Főleg szerveren nem nagy szám az Arch, mert ugye egy headless szerver az még kisebb komplexitású, nincs hangrendszer, USB, Blutooth, X, login manager, GPU gyorsítás, gaming, media codec, stb., a bootolás egyszerűsíthető, belövöd azt az 1-2 csomagot, konfig fájlt, service-t, és onnan néha csak ránézel SSH-ban, nagyságrendekkel kevesebb csomag és komplexitás van egy szerveren, ennél a felhasználásnál még kisebb eséllyel futhatsz bele akármibe.

Sőt, hova ne tovább, az Archnak további előnye, hogy csak az kerül fel rá, amit felteszel, emiatt még soványabb, mint egy Ubuntu Server alaptelepítés, amibe beletoltak egy csomó szutykot, Snap-tól elkezdve a kutyafüléig. Igaz ezt egy Debian minimal telepítéssel is meg lehet csinálni. Az egész Arch túl van régről misztifikálva, tök átlag systemd-s disztró lett mára, átlag defultokkal, épp ugyanaz a szoftver elérhető rá, mint Debian/Ubuntu variánsoknál, max. annyi, hogy apt helyett pacman-t használsz, meg ahhoz megtanulsz 1-2 új kapcsolót, aki nem debil, meg tegnap kezdte ezt a műfajt, simán belejön nagyon rövid idő alatt.

Ezt az üzemeltetést is hagyjuk, láttam én már olyat, nyugi. Az esetek többségében épp olyan komolytalan vergődések, mint egy home user desktopja. Láttam én már nem egy rendszert, szerencsétlen, elavult, Ubuntu tutorialok, meg rosszul beállított Proxmox webmines gányolás mentén összehekkelve, hogy épp csak menjen, utána teljesen elhanyagolva, meg más se mert hozzányúlni, mert nem érették mi hatja, mihez kezdenek, ha eltörik. Még a legkomolyabb multik is 99%-ban amatőr gányolásokat tolnak le, legtöbbször egy /var/log, vagy i-node beteléses, vagy fstab felcsatolásos, GRUB javítós, ZFS scrubos alap dolgot nem tudnak az idiótáik megoldani, megy egy top, iotop, lsof, load average, dmesg, journalctl kimenetbe belenézni, azt értelmezni, amit nem hogy egy komoly sysadmin vagy unixos veterán simán megold, de még egy rutinos linuxos desktopos user is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Valamilyen szintig foglalkozni minden rendszerrel kell, ezzel ne is áltasd magad. A leglassabb, legstabilabb LTS, meg corporate rendszereken is össze tudja bármi fosni magát update-kor, GRUB-tól elkezdve az X-en át, a fene tudja miig, láttam már erre példát Debianon, Ubuntun, Minten, stb..

Azt nem érted,, hogy nem a hibákról, hanem a verziókról, inkompatibilis változtatások lifecycle managementjéről van szó. Ha holnapután az kijön az apacheból a 2.6, akkor pénteken benne lesz az Archban, neked pedig most azonnal kell kezdened valamit az összes mindeneddel, átírni a konfigokat, megkalapálni a tökömet is. Egy release alapú disztrónál meg majd a következő releassel, tervezhetően. És ez egy featureje az Archnak ami ugyan teljesen jó bizonyos szempontból, de más szempontokból meg rohadtul nem. 

 ennél a felhasználásnál még kisebb eséllyel futhatsz bele akármibe.

Egy normális nem rolling disztrónál meg az ígéret szerint soha. És amikor igen, akkor az bug, ezért ellentétben az archal, ahol az lesz a teljesen jogos válasz, hogy ez van, frissíts be mindent, addig egy LTSnél meg fogják jó eséllyel rugdosni, hogy ne törjön. 

Ezt az üzemeltetést is hagyjuk, láttam én már olyat, nyugi. Az esetek többségében épp olyan komolytalan vergődések, mint egy home user desktopja. Láttam én már nem egy rendszert, szerencsétlen, elavult, Ubuntu tutorialok, meg rosszul beállított Proxmox webmines gányolás mentén összehekkelve, hogy épp csak menjen, utána teljesen elhanyagolva, meg más se mert hozzányúlni, mert nem érették mi hatja, mihez kezdenek, ha eltörik.

Szóval nem láttál, csak egy rakás balfaszt. :)

A többire nem reagálnék, mert a téma szempontjából irreleváns.

Bocs, hogy beleszólok, de még mindig nem érted.

Röviden: Már egy CC EAL2 auditon se lököd át az Arch-t. Sok sikert hozzá.

Bővebben: Az üzlet kockázatot és kiesést akar minimalizálni. Az üzemeltetés is. Nagyon nem mindegy, hogy a frissítés jól tervezhető minden körülménnyel együtt (miről mire, mi változik meg, mihez kell hozzányúlni, mekkora kiesés várható) vagy egy "ahogy esik, úgy puffan" alapon megy, ami okozhat 1 perces és 1 hetes kiesést is, amíg a probléma megoldódik.

hat se az en cegem se az ugyfeleim nem szuntek meg 20+ eve, ezalatt nemhogy az ubi de meg a slackware is eol lett!

persze ha az atlagot ugy szamolod mint az atlagbert szokas, hogy a minimalbereseket es a millios fizetesueket atlagolod, akkor kijohet, mert tenyleg sok a par honap alatt bedontott szamlagyar...

2019-ban majdnem 90 ezer tarsas vallalkozast jegyeztek be. Miert olyan hihetetlen, hogy ennek a fele nem eri meg a 10 eves kort? Nem csak bedolt szamlagyarok vannak. Tiz ev alatt megunhatod a vallalkozosdit, csodbe mehetsz, felvasarolhatnak, osszeveszhetsz a tulajdonostarsakkal, stb.

Btw a tiedet sem talalom Optenen, nem lehet, hogy megis megszunt? :P

Így van, ezt mondom mindig én is. Meg egyáltalán a linuxos világ annyira gyorsan változik, hogy 10 év túl sok idő benne leragadni verziókon. 10-15 év alatt teljesen megváltozott csak a Linux ökoszisztémája, rengeteg CPU sérülékenység patch-elése, systemd, Wayland, Pipewire, Proton/DXVK, nyílt GPU driverek, univerzális csomagformátumok (Snap, Flatpak, Appimage), megjelentek az immutalble disztrók, az UI framework-ök ugrottak 3 főverziót átlagban, Python/Perl a következő főverzióval nagyot változott, bejöttek az Electron-alapú megoldások, böngészőkből kikoptak a szutyok pluginek (Java, Adobe Flash, MS Silverlight), bejöttek új formátumok. Na most, egy 10 éves telepítés kb. már 5 év után használhatatlan, nem hogy a 10. év végére.

Plusz ez a támogatási idő istenítése egy régebbi korszakból származik. Amikor még a Linux disztrók, különösen a közösségi kisebb, amatőrebb disztrók (Arch alapúak, Gentoo, stb.) még gyerekcipőben jártak, sok volt velük a gond a kiforrottabb, nagyobb (Debian) vagy nagy tőkével fejlesztett corporate disztrók ellenében (Suse/RHEL, valamint Ubuntu), így akkor sok emberbe belekövült a szemlélet, hogy a verziók változatlansága meg az LTS az a minden, meg fosni kell minden update-től, mert jajj, minden el fog törni. Közben meg ahogy volt fejlődés, szépen felzárkóztak a kisebb, alternatív közösségi disztrók is, megbízhatóságban, frissítések, mirrorok, csomagok biztosításában, fejlesztők és userek számában, meg a fejlesztők többsége átállt eleve a rolling/git-dev kiadási szemléletre. Ma már a disztrók közötti szakadék jóval lecsökkent, amit a distrowatch top50-ében talál az ember, az mind használható, ha valaki hajlandó beletanulni, újat megszokni.

Egyébként ha valaki tényleg elavult, változatlan rendszert akar, annak ma már egyenesen a FreeBSD-t ajánlom, ha az a hardverére, felhasználására opció. Teljesítményre kevésbé optimalizált, hardvertámogatása gyengébb, de ha az mindig okés az adott felhasználásra, akkor viszont biztonságosabban unalmasabb. Kevésbé változik a BSD-s világ, nem csinál akkora ugrásokat, mint a Linuxnál a systemd, Wayland, Pipewire, hanem szigorúbban megmarad a POSIX kompatibilitásnál, fapadosságnál, egyszerűségnél, nem erőlteti a konténerizációt, nem hajkurássza annyira a verziószámokat, a kiadási és kernelfejlesztési ütem is kevésbé hajtottabb, agresszívebb, így nyugodtabban, kisebb lépésekben változnak csak a dolgok, minden sokkal kiszámíthatóbb. Ha nincsenek nagy extra igények, és valaki hajlandó kicsit megtanulni a különbségeket a Linuxhoz képest, akkor simán opció lehet. Mivel épp úgy POSIX kompatibilis, meg unixlike, meg a GNU ökoszisztéma is elérhető rá, ezért nem kell túl sok mindent újratanulni, elég egy-két apróbb eltérést megszokni (rc, sndio, pgk/ports, bhyve, stb.).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( hajbazer v | 2024. 01. 17., sze – 00:16 )

Szerkesztve: 2024. 01. 17., sze – 00:19

RockyLinux 8 - 2029-ig támogatott, tehát még 5 évig ugyanaz a rendszered maradhat, ha most felrakod.

RockyLinux 9 - 2032-ig támogatott, tehát még 8 évig ugyanaz a rendszered maradhat, ha most felrakod.

Binárisan kompatíbilis az RHEL8 és RHEL9 disztrókkal. Teljesen ingyenes.

https://rockylinux.org/ | https://endoflife.date/rocky-linux

Mindkettőre 10 év támogatás van egyébként, csak ebből ugye már eltelt valamennyi idő.

Igen, de:

Differences with Upstream RHEL:

https://endoflife.date/rocky-linux#differences-with-upstream-rhel

( mraacz | 2024. 01. 19., p – 17:55 )

Nagyon köszönöm a válaszokat és a tippeket. Nálam a Rocky nyert, de mégis a Mint Virginia lett a nyertes, MATE, mert abban a wireguard a panelen is menedzselhető (amire mondjuk nincs szükség, de mégis) meg még ezeregy okból. És egy gépre felment a RHEL 9.3, hogy lássuk, tényleg ingyenes-e a developer licensz és meddig.

2032-ben folytatjuk a kiértékeléssel, Windows 23-mon.