Debian is lange tijd mijn favoriet geweest. Niet altijd de hottest-of-the-hottest beschikbaar (loopt 1 jaar achter op bijvoorbeeld Ubuntu), maar wel erg stabiel.

Voor security: FreeBSD rules!

Uhm, nee. Je bent in de war met OpenBSD…

Primaire vraag is - wat DOE je met die workstations ?

Ze zijn er niet om een lekker gevoel te krijgen van een voorkeurs OS, maar om mee te werken.

Afhankelijk van het werk dat erop gedaan wordt is dan de vraag - vallen er (al) distributies af om die reden ?

Als er één ding is waar je als beheerder niet voor moet kiezen is het werken met onsupported kludges omdat de noodzakelijke applicatie niet goed gesupport wordt op je voorkeurs distributie.
(denk aan missende of verkeerde library versies in de distro, die je dan weer van externe sources moet gaan zitten toevoegen - dan ben je meteen het voordeel van een distro met updates die "vanzelf" gaan kwijt).

Je zou kunnen gokken op een één van de nieuwe doorstarts van "gratis Redhat" .
Rocky linux bijvoorbeeld . Niks mis met het idee, zeker als je van CentOS afkomt. Je hebt alleen de onzekerheid van een jonge distributie - zo snel als ze gestart zijn kunnen ze ook stoppen. En momenteel x86 only.
Alma Linux is geloof ik de/een andere CentOS doorstart.

OpenSuse is ook een goed onderhouden stabiele distributie met goede desktop opties.

Ubuntu is ook goed onderhouden en goed up to date - en heeft ook een focus op desktop gebruik.

Debian is een prima distributie, maar m.i. gewoon minder gericht op desktop gebruik, en Debian stable kiest wel heel oude versies van applicaties en libraries.

Met de nodige slagen om de arm denk ik dat je met een "CentOS doorstart" het beste af bent - bestaande ervaring met CentOS , en bij applicatie vendors voor Linux staat "Redhat support" in mijn perceptie bovenaan - daarna pas volgen andere distro's.

Een ander criterium kan zijn "zelfde als op de servers" - het is gewoon een extra last als beheerteam om meerdere versies in de vingers te hebben en tools en scripts net even anders te moeten doen op de ene dan wel andere Linux versie.
Je kunt het als hobbyist die 6 uur per dag besteed aan het beheren van twee machientjes leuk vinden om te doen - als je met een paar man voor honderden instances doet is het helemaal niet leuk om veel verschillende variaties te hebben.

Verder zie je als beheerder graag een distro met lange lifecycles - zowel RH klonen, Suse, Ubuntu (LTS) en Debian voldoen daaraan.

Dat geloof ik niet. OpenBSD zou het beste kunnen zijn, maar ze willen daar niet aan OpenZFS (vanwege de grote omvang van de code). En laat dat nou wel toegepast worden bij FreeBSD. Maar het grote probleem met FreeBSD dat is de lack van een GUI. Maar dat hebben ze opgelost met GhostBSD. https://en.wikipedia.org/wiki/GhostBSD

Het probleem echter van *BSD dat zijn de driver support dat niet on par is met Linux. Jouw printer of scanner die werkt misschien niet.

Maar een BSD is wel degelijk een heel stuk stabieler dan Linux.

Het probleem met Ubuntu dat is dat de eigenlijke focus van Ubuntu de server zijde is. Wanneer ben je eigenlijk nog een keer echt enthousiast van Ubuntu? Je wordt niet meer enthousiast van Ubuntu. Linux Mint lijkt mij een beter alternatief, of Ubuntu Mate en als je van Arch Linux houdt dan is Manjaro de beste keus.

CentOS zelf gaat gewoon door onder de naam CentOS Stream
Wat veranderd is dat CentOS downstream was en nu upstream model gaat volgen van Redhat.
CentOS 8 wordt vervroegd EOL verklaard in favor van de upstream strategie en CentOS 7 wordt EOL verklaard op 2024-06-30

Algemeen downstream upstream uitleg:
https://itsfoss.com/upstream-and-downstream-linux/
Redhat uitleg omtrent CentOS:
https://www.redhat.com/en/blog/transforming-development-experience-within-centos


Als dat voor jullie geen probleem is dan kun je dus ook makkelijk migreren naar het nieuwe patch model
CentOS 7
https://techviewleo.com/how-to-convert-from-centos-to-centos-stream/
CentOS 8
https://www.linode.com/docs/guides/migrate-from-centos-8-to-centos-stream/

Indien dit wel een beperkende factor is dan kun je AlmaLinux of RockyLinux overwegen.
RockyLinux is opensource en bestaat uit een reeks oud medewerkers van CentOS core team.
AlmaLinux is een collaboration tussen enkele oud CentOS medewerkers en CloudLinux welke komende jaren financial backing doet voor het project maar geen invloed mag uitoefenen op de ontwikkeling.

Lees je wel goed in voor het migratie proces van deze twee.
Ik zou niet adviseren als je Redhat infra gewend bent naar Debian te gaan tenzij er zwaarwegende onderliggende redenen zijn. Onderliggende werkt alles net iets anders en training van je gebruikers en personeel zal tijd kosten.

Qua veiligheid beschouw ik RHEL, CentOS, Debian on par. Ubuntu zou ik corporate niet inzetten ik beschouw dit gelijk aan Fedora. Naast te veel geexperimenteer zeker omtrent de GUI welke standaard in de image zit.

Je vergist je: FreeBSD was niet, is niet en wordt niet gericht op security, dat is bijzaak voor FreeBSD. OpenBSD is volledig gericht op security, en een moloch als ZFS hoort daar niet in thuis. Volledig verschillende doelgroepen. En GUI? Verdiep je eens in de diverse window managers voor linux en BSD. Die zijn in alle varianten beschikbaar. Al jaren.

Voor op de desktop is fedora ook een prima keus wanneer je in de hoek van cent os en redhat zit.

Belangrijkste opmerking die hier al gemaakt is: check vooraf of de software die je nodig hebt goed beschikbaar is voor jouw distributie.

https://elementary.io/ Elementary OS

Zie https://distrowatch.com/ ik gebruik zelf al een tijdje Manjaro als (gaming) desktop en Fedora als ontwikkel workstation en dagelijks gebruik.

Daar is natuurlijk een oplossing voor.

nano/vi(m) /etc/apt/sources.list vervang "stable/bullseye" met "sid"
apt update
apt upgrade

En tadá, Debian loopt niet meer achter op Ubuntu. Ubuntu is dan ook nog altijd weinig meer dan Debian Sid met eigen sausje.

Voor desktop gebruik is Sid fijner om te gebruiken. Mocht stabiliteit en veiligheid je voorkeur hebben, bv bij servers, lekker op stable blijven.

Rocky
Alma
Oracle
Springdale

google it...

van centos.org:
CentOS Linux 7 (2009) will reach End Of-Life (EOL) on June 30th, 2024.
CentOS Linux 8 will reach End Of Life (EOL) on December 31st, 2021. In line with the EOL of previous releases, we will NOT be automatically migrating anyone to the next version (which is CentOS Stream 8 in this case).


Dus CentOS 8 is inmiddels al EOL. of migreren naar CentOS Stream 8.

Een opmerking wat veiligheid betreft: het is zo veilig zoals je het zelf maakt, dat heb je zelf in de hand.

Dat is praktisch gezien niet helemaal waar - je wilt een distributie die security patches snel integreert en backport , en die out of the box kiest voor veilige defaults .

Dat je in theorie het allemaal zelf ook zou kunnen doen is vooral theorie of hobbyisme - dat is werk dat een goede distributie je uit handen kan nemen . Als je dat zelf moet gaan zitten doen - grote kans dat je wat vergeet , en gewoon zonde van je tijd.
Als beheerder heb je letterlijk wel wat anders en beters te doen dan het werk van een goede distrobouwer over te doen omdat je een slechte distro gekozen hebt .

(net zoals je in iedere turing-complete taal in theorie ook alles kunt schrijven - kies in praktijk vooral een taal die goed past bij het onderwerp dat je wil programmeren) .

Ik vergis me helemaal niet en jij ook niet. We hebben allebei gelijk. Maar een GUI voor *BSD zit er niet standaard in. Daarom is GhostBSD een heel leuk alternatief.

@op, als je veiligeheid wil, dan is er ook nog altijd Qubes https://en.wikipedia.org/wiki/Qubes_OS De mensen daar zijn heel goed bezig en Qubes zit heel goed in elkaar. Maar ik gebruik het zelf niet. Ik geef het alleen maar aan.

Ik heb een tijdje CentOS gebruikt als server OS onder VMware, omdat dat indertijd een gesupport OS was en Debian niet.
Gelukkig support VMware nu wel Debian en heb ik stuk voor stuk alle CentOS 6 en 8 systemen overgezet naar Debian,
er draait nu nog 1 Centos 7 systeem wat nog gedaan moet worden.
Hoofdreden voor deze stap was het ontbreken van een upgrade procedure, dat had ik verzuimd te onderzoeken bij
de keuze. Als je niet kunt upgraden van CentOS 6 naar 7 maar men je afpoeiert met "gewoon even herinstalleren"
tja dan kun je net zo goed meteen naar Debian overstappen he? Zeker omdat toen al duidelijk was hoe het zou
gaan verder (merk op dat de EOL datum van CentOS 8 nog VOOR die van CentOS 7 ligt!).

Ik heb zelf geen ervaring met *BSD, maar ik ben al heel wat keren het oordeel tegengekomen dat Debian stable een BSD-achtige stabiliteit heeft.

Ik denk ook terug aan de tijd dat XS4ALL met NewsZilla de grootste usenetserver van Europa had. Oorspronkelijk draaide dat op FreeBSD. Ze zijn ooit overgestapt op Debian omdat dat een veel hogere throughput aankon en stabieler was. XS4ALL heeft destijds trouwens meer systemen van FreeBSD overgezet naar Debian, bijvoorbeeld hun shell-servers. Dat was voordat KPN daar het roer overnam, voor alle duidelijkheid. Destijds legde Cor Bosman, een van de oprichters van XS4ALL, op usenet nog wel eens uit wat ze deden en waarom. Daar herinner ik me dit soort verhalen van.

Of dat soort oordelen eeuwigheidswaarde hebben is natuurlijk maar de vraag. Het geeft wel aan dat het beeld niet zo eenvoudig is. De BSD's zijn ongetwijfeld stabieler dan sommige, en misschien de meeste, Linux-distributies. Maar als Debian inderdaad vergelijkbaar is met of zelfs beter is dan minstens een van de BSD's dan is het zowel waar dat BSD's stabieler zijn als dat Linux even stabiel of stabieler is. Het is maar wat je precies met wat vergelijkt.

Veilige defaults? Poorten die default open staan, onnodige services die default draaien, sudo die default alles toelaat, NetworkManager die default iedere 5 minuten pingt (connectivity check)? Noem het hobbyisme, ik heb het niet zo op defaults.

Je kunt niet zomaar beslissen dat je van infra overstapt dat is vaak jaren planning en zelden ben je de gene die hier alleen over beslist. CentOS 6 naar 7 kan middels inplace upgrade via commerciele tools maar waarom je dat ooit zou willen riskeren is me een raadsel.

De reguliere methode is je draait een server parallel zet de data over test de functies en ontkoppelt na afronding de oude server en parkeert deze voor x dagen tot je zeker bent dat er geen verassingen meer zijn. Zelfs al zou je het wel inplace doen je neemt alle troep mee van de vorige installatie en je hebt geen idee wat de mogelijke effecten op langere duur zijn. Dat geldt voor alle soort systemen Windows, Linux, UNIX, Macintosh het maakt niet uit, als stabiliteit en veiligheid prioriteit hebben dan gebruik je nooit inplace upgrades.

De Redhat move met CentOS8 EOL was een drama no doubt about that maar niet onverwachts. Meeste ervaren en groot beheerders houden al rekening met dit soort geintjes. Je leert al heel gauw in deze wereld dat je nooit maar ook nooit op de laatste versie wilt draaien zolang de vorige nog ondersteunt wordt. Meeste zagen de bui al hangen toen Redhat CentOS overnam. Ze hadden RHEL ze hadden Fedora en nu dus CentOS. Fedora was de upstream Van RHEL en RHEL was de upstream van CentOS. Dat gaat tegen hun verdien model in want waarom zou je als corporate grof geld betalen voor een systeen dat minder stabiel is dan de gratis variant?

In begin was RHEL nog aantrekkelijk wegens de Satellite functies maar toen Spacewalk en Foreman mature genoeg werden als lifecycle managment platform was dat voordeel ook gauw weg. 300 dollar per jaar per workstation en 1400 dollar voor servers met support dan kan je in een grote organisatie al snel goedkoper een support provider contract los van je vendor nemen scheelt gauw duizenden euros of meer.

Maar overgaan van een CentOS gebaseerde infra infavor voor Debian is niet gauw een besparing.
Er zitten subtiele verschillen in Debian en RHEL distro's de meeste echter merk je pas bij intensieve troubleshooting en koppelingen met andere vendors.

Dat soort migratie beslissingen maak je als je in rustig vaarwater zit niet als je een storm nadert. Want als de overstap niet uitpakt dan ben je ver van huis. Leg maar eens aan finance uit waarom er dubbele uitgaves gemaakt zijn binnen je IT budget en waarom de begroting niet meer klopt van het bedrijf.

Als de TS een hobbyist, student was geweest had ik gezegd van go for it. Maar laten we realistisch zijn dit zijn voor bedrijven vergaande beslissingen en voor de TS een met mogelijke gevolgen voor zijn, haar career. Dat neemt niet weg dat er ruimte is voor het opzetten van een pilot met Debian of ander systeem lost van productie maar zonder een compleet netwerk plaatje is een complete migratie advies onverstandig.

Daar is een upgrade script voor

Enz enz enz...

Man man man wat bij jij een zwartkijker zeg! Je zult het wel moeilijk hebben op je werk als je voortdurend zo denkt...
Gelukkig kon ik nu nieuwe Debian systemen installeren ipv die CentOS (want dat moest toch wel, upgrade supporten ze niet)
en was ik van die toestanden af, draait sindsdien als een zonnetje. En daarna al upgrades gedaan zonder issues ook.

Probeer eens coherent te zijn ?

Iemand (jij ? ) zij "alles is zo veilig als je het zelf maakt"

Ik zeg " maak het jezelf makkelijk een kies er een die default al goed begint" , in plaats van "maakt niet uit welke maar doe het allemaal zelf"

En dan kom jij met commentaar op *een* - door jou niet benoemde - distro waarvan sommige defaults jou niet bevallen ?

Iets wat RH bijvoorbeeld goed doet is dat de distro gebouwd is om selinux te gebruiken - dat is fors complex om zelf uit te zoeken en bruikbaar te activeren.

Die poster heeft heeft gewoon gelijk - het is alleen het verschil tussen ruime ervaring op grote schaal en een scholieren die een enkel servertje met de hand runnen.

In een kleine omgeving met een handvol systemen doe ik dat soort keuzes ook snel , en gaat het "meestal" wel goed. En de schade als het misgaat is ook te overzien.

In een omgeving met honderden instances doen we niet "even overstappen op een andere Unix" en is dat inderdaad een fors project . En daar ben "je" inderdaad niet de enige beslisser over zo'n keuze .
De meeste mensen snappen dat verschil in perspectief tussen kleinschalig en grootschalig pas als ze er echt in werken.

Jammer trouwens dat de TS niet deelneemt en wat meer schrijft over z'n omgeving en wensen .
Alleen maar een distro flamewar uitlokken is weinig productief.

Zo zo knap hoor absoluut een sticker verdiend daarvoor. je hebt natuurlijk wel je disaster recovery protocol en draaiboeken geupdate na je inplace upgrades? Of is dat teveel zwartkijkerij?
Iedergeval wel blauwdrukken gemaakt en inventarisatie van alle geinstalleerde onderdelen met versie nummer en controle per onderdeel op juiste werking? Of heb je vertrouwd erop dat gezien het systeem nog opstart dat alles goed is gegaan?


De taak van netwerk beheerders, architecten is niet blindelings faciliteren maar ook andere behoeden van fouten. Dat houdt in dat je naast oplossingen ook de meeste potentiele problemen *op voorhand* in kaart brengt en vervolgens daarop de bijhorende oplossingen of mitigation. En nee daar is niks makkelijks aan inderdaad maar dat weet hopelijk ieder die ooit iets in netwerk beheer, architectuur doet.

We hebben veel te weinig informatie om TS te voorzien van een ander advies dan zoveel mogelijk blijven bij de huidige opzet. Hier paar wedervragen die meteen bij mij opkomen bij TS zijn, haar vraag. (in willekeurige volgorde) die nogal belangrijk kunnen zijn voor advies.

Gaat het enkel om workstations? Zo nee zit het in een domein, LDAP of andere server infra?
Zo ja dan dus serverless hoe geschied het beheer middels scripts, netwerkcommando, lokaal beheer?
Hoeveel workstations gaat het om.
Zijn alle workstations van zelfde hardeware, en software voorzien?
Draait er commerciele software op de clients.
Zo ja zitten er support contracten bij de software met een custom of standaard S.L.A?

Hoe zit de back-up infra in elkaar wordt er gemirrored, worden er snapshots gemaakt, incrementele of differentiele back-ups? Worden de back-ups regelmatig getest.
Zijn er exports beschikbaar van systeem configuraties.
Zijn indien van toepassing exports van de dnszones gemaakt.

Zitten er custom kernel modules op de workstations, servers
Wordt er gebruik gemaakt van enige IDS en geautomatiseerde file integrity checks?
Zijn er predetermined maintenance windows?

Zijn alle responsibles intern extern op de hoogte van het plan voor de upgrade en akkoord?
Is er go no go proces afgewikkeld en
Is er een projectplanning opgezet en duidelijk gedefineerde milestones?
Is er een marge beschikbaar qua resources.
Is er een budget afgesproken

En zo kan iemand anders waarschijnlijk nog wel paar honderd wedervragen verzinnen. De hoeveelheid afhankelijk van de omgeving complexiteit *waar we niks van af weten*

Maar tja zwartkijkerij natuurlijk wat kan er misgaan?

Zeg mensen men is hier niet bezig om over te stappen van Windows naar Linux ofzo, zoals jullie kennelijk denken.
Het is allemaal dezelfde software alleen in een andere verpakking. Het werkt niet anders ofzo, als het met CentOS
werkt dan werkt het met Debian ook, en makkelijker.

Ook worden er ineens allerlei zaken bij gesleept als "honderden instances" waar helemaal niemand om vroeg.
Maak je het jezelf altijd zo moeilijk?

Het is mij nog nooit gelukt om een Debian OS 10+ jaren up-to-date te houden.
OS upgrades faalden altijd, zelfs als ik exact instructies volgde.

Bij FreeBSD ging dat -zelfs met custom kernels- altijd eenvoudig, en tegenwoordig met een paar simpele (reversable) commands. En het generieke ports (pkg) systeem wordt door diverse BSD's gebruikt, en daardoor onderhouden door een grote actieve userbase. Was al lang perfect voor yum en apt-get bestonden.

Een bootloader waarmee je jezelf uit de meest onmogelijke failures kan halen.

En zoals genoemd ZFS die je nooit meer inferieure filesystems doen willen gebruiken.
En zraid die het zeer evident maakt dat hardware RAID nogal inefficient is.

En dat zijn slechts enkele argumenten voor mijn sterke voorkeur.

Het is niet zomaar dat Linus Thorvald riep dat hij Linux nooit begonnen zou zijn als hij destijds wist waar BSD nu was.
Al denk ikzelf dat die elkaar scherp houden en elkaar motiveren.

Dat denk ik eigenlijk niet, dat de BSDs stabieler zijn. Op z'n best is dat verhaal gebaseerd op de prehistorie waarin mensen een BSD draaiden op een server met kwaliteitshardware, en verschil zagen met Linux op een thuisbakkie met derderangs hardware, of half gesupporte devices - die in Linux ietwat gesupport werden en in BSD helemaal niet .

De meer obscure bugs ontdek je pas bij heel grootschalig en langdurig gebruik . Met de dominantie die Linux heeft bij de hyperscalers (FB, Google, Amazon e.a.) denk ik niet dat enig ander OS zoveel "cpu-uren" maakt als Linux .
En deel van de bugfixes voor erg zelden optredende bugs komt op basis van ervaringen uit dergelijk gebruik.

Ik zie geen reden om de BSD fanclub "maar wij zijn stabieler" zomaar te geloven.

Dan doe je toch iets verkeerd.... ik heb al heel wat Debian systemen door het wheezy->jessie->stretch->buster en
recentely bullseye traject gesleept en dat gaat altijd goed, zij het dat er altijd wel enig handwerk bij komt kijken om
de config files die je zelf gewijzigd hebt even tegen de nieuwe versie aan te houden en te besluiten wat je er mee wilt.
Dat zijn bij mij altijd minder dan 10 files, maar als je alles binnestebuiten keert op je systeem (de aanpak van "default
waardes zijn niet goed en moeten beslist aangepast worden") dan zullen het er meer zijn.
Echter in de basis werkt het gewoon goed.

Nee... Netbsd

Die is er ook niet. Laten we het maar niet over het verleden hebben want subversion is daar nog steeds cutting edge:
https://docs.freebsd.org/nl/books/handbook/cutting-edge/

Mij wel. Daarbij heb ik dezelfde installatie door de jaren heen meerdere keren van nieuwe hardware voorzien. Oude schijf in nieuwe computer, inhoud schijf overzetten naar een nieuwere/grotere schijf, het ging allemaal prima. Voor de overgang van 32-bit naar 64-bit hardware heb ik wel een nieuwe installatie gedaan. Verder werk ik lekker door met wat ik heb, en dat is altijd goed gegaan.

Of je een upgrade naar een nieuwe major release kan doen of beter kan herinstaleren staat trouwens niet bovenaan de lijst met punten waarop stabiliteit beoordeeld wordt.

En volg die voorkeur vooral, daar is niets mis mee.

Dat is echt niet waar . Als je een "redhat supported applicatie" wilt draaien is dat ontzettend makkelijk op Redhat .
En een hoop extra gedoe om het dan op Debian te draaien , als er geen dpkg van beschikbaar is.

En als je al je tools gebouwd hebt rondom Centos is het gewoon Veel Werk om naar een Debian of Ubuntu over te stappen.
Andersom is natuurlijk ook waar - van Debian naar een RH kloon kan ook veel werk zijn .

Met een enkel machientje is "hetzelfde maar een beetje anders" geen enkel probleem.


TS vroeg vanuit het perspectief van een systeembeheerder die CentOS workstations beheert . Veel of weinig , dat weten we niet .
Je kunt speculeren dat in de context van een plek met Linux Workstations en een aangestelde beheerder het al om "meer dan een paar" zal gaan.

Wat de professionals hier _wel_ weten is dat het veranderen van grootschalige omgevingen gewoon niet simpel is.

Welke versiebeheersoftware ze gebruiken zegt geen donder over de kwaliteit van de software die ze erin onderbrengen. De kwaliteit van de software ligt aan de vaardigheden van de programmeurs en testers.

Dan ben je wel met hele specifieke software bezig als er geen .deb van beschikbaar is. Zo'n beetje elke zichzelf serieus nemend Linux software heeft ook ondersteuning voor Debian. In het ergste geval is het dan vaak zelf te compileren.

Er is genoeg corporate software die specifieke OS vereisen of management software. Zeer simpel voorbeeld cPanel. ondersteuning Ubuntu sinds dit jaar en nog in beta dat is. https://blog.cpanel.com/full-cpanel-support-for-ubuntu-lts/

En dan hoor ik de mensen al zeggen ja maar dat is Ubuntu en niet Debian. Wel lees deze thread de laaste post maar even waar Ubuntu wel ondersteund wordt en Debian dus niet eens op planning staat.
https://forums.cpanel.net/threads/whm-cpanel-on-debian.688981/

Ik ga niet meer software noemen omdat dat iets zegt over de infra die ik beheer en daar hebben buitenstaanders niks mee te maken. Maar kan je wel zeggen dat er meerdere vendors zijn die hun afzet markt afstemmen op 1 type variant Linux gebaseerd OS zodat ze niet specialisten hoeven aan te nemen uit andere specialisaties want die zijn namelijk niet goedkoop.
Kan het ze ook niet kwalijk nemen als 80% van een specifiek platform afkomt dan zit daar ook simpelweg je geld. Meer ondersteunen is een risico en als uit onderzoek blijkt dat die markt te klein is om wat voor reden dan ook dan begin je er niet gauw aan.

Het idee dat sommige hier hebben dat alles van Linux besturing systemen universeel is *helaas* complete nonesense. Linux is de kernel dat is universeel maar de rest de modules het OS de software hoeft niet universeel te zijn.

Meeste kun je zelf compilen klopt maar er is ook software wat dat niet bij mag vanuit je contracten. Het ligt aan je vendors en zelf compilen wordt echt nog maar zelden gedaan tegenwoordig wegens alle liability. Je kiest dan al gauw liever voor een andere vendor dan dat je het riskeert een datalek krijgt en men zegt ja maar je software was ook niet officieel ondersteund voor je OS.

En ja een beheerder die enkel een intern netwerk hoeft te beheren zal hier probably niet tegen aan lopen maar begeef je richting datacenter management, architecture of zelf managed hosting en dat plaatje veranderd rap.

Ik hoop dat je er niet tegen aanloopt maar houdt het alsjeblieft in je achterhoofd controleer altijd of het daadwerkelijk je OS ondersteunt en niet simpel zegt geschikt voor Linux. Je zult namelijk niet de eerste zijn die daar nat op gaat

tja mensen eigen...

zij met een roze brilletje zien overal optimisme en de tegenpartij is maar pessimistisch
zij met ervaring zien overal haken en ogen en de tegenpartij is maar naïef

in dit soort discussies vraag ik mensen die me pessimistisch noemen toch altijd een te gaan nadenken waar zij zelf dan de grens tussen optimisme en naïviteit leggen


ikzelf probeer graag realistisch te zijn, niet optimistisch altijd, maar zeker ook niet meteen pessimistisch.

Ik kan je vertellen dat er veel software in de wetenschappelijke (HPC) wereld niet als .deb of als .rpm beschikbaar is en dat vele HPC omgevingen wat meer zijn dan een enkel servertje of werkstation.

In deze HPC wereld was en is RHEL / CentOS de koning en Debian / Ubuntu niet.

Nu RH/IBM met CentOS 'raar' doet zijn grote partijen overgestapt op RHEL / Rocky / Alma. SuSE zie je ook veel minder.

Bekijk zelf de TOP500 lijst anders maar eens of bekijk eens wat ze hier in NL bij SURF met Snellius doen.

De vreemde eend in die bijt is CERN die, voor de korte termijn, van CentOS naar Stream zijn gegaan en, zoals ik het inschat, een onderhandeling positie tov RH in neemt om in de toekomst RHEL te doen. Ze zullen waarschijnlijk de kat uit de boom kijken en tzt overschakelen naar Rocky / Alma al naar gelang welke populairder wordt onder hun gebruikers tenzij ze dus een 'nette prijs' voor RHEL gaan krijgen. Mijn inschatting is dat het dan anders Rocky gaat worden. Veel oude HPCers zie ik die kant uit gaan om allerlei redenen.

Mijn punt is dat er geen distro bestaat die je installeert en vervolgens niet zelf over security hoeft na te denken.

Het ligt er aan hoe stabiel centos stream wordt/blijft het is immers maar een minor versie hoger dan de rhel versie. Mijn ervaring is dat het ook rete stabiel is. Nadeel is alleen de vele pakketjes die worden ge-upgrade mara wel in perspectief blijven zien want kwa grootte is het niks vergeleken met een windows update.

het vreemde hieraan is dat CentOS Stream een EOL periode heeft van 5y tov RHEL / Rocky die 10y doet. voor grote HPC systemen met veel gebruikers en een enorme wetenschappelijke software stack (a la easybuild / spack), is dat wel een 'dingetje'. besef, met een 5y EOL periode heb je gemiddeld 2.5y support, met een 10y EOL heb je gemiddeld 5y support. HPC hardware wordt over 5 tot 8 y afgeschreven afh van financien. die 10y support die mensen hadden met CentOS was dus de key feature dnek ik voor HPC systemen naast het feit dat je niet met een subscription aan het kloten was voor elke compute node in je omgeving. key features. daarom zie je veel mensen richting Rocky gaan.

neemt niet weg dat iemand met een roze brilletje het helemaal anders kan zien en over 2y een 'aha momentje' zal hebben :).

Ik weet dat CERN iedergeval nooit hun eieren in een enkel nest donderd. De strategie mbt tot de stap naar Stream die ik zie is dat ze zich als Special Interest Group (SIG's) opstellen richting Redhat. CERN is ook bezig geweest bijvoorbeeld met ondersteuning bieden van PowerPC compatabiliy richting AlmaLinux. En zou me ook niks verbazen als ze zo soort gelijk iets doen voor Rocky en RHEL ondersteuning op een bepaald ontwikkel vlak voor mutual beneficial relationship.

Qua EOL zou me niks verbazen als ze hebben onderhandeld voor een custom Extended Life Cycle Support contract (ELS) op Stream bij Redhat. https://www.redhat.com/en/resources/els-datasheet
Officieel niet te krijgen voor Stream maar zoals menig mens weet is wat officieel niet te krijgen is niet een correct plaatje van wat er achter de deuren wordt afgesproken.

heb je bronnen of zijn het speculaties? vooralsnog is en blijft het een vreemde keuze...

Op de Alma Linux na speculaties. Bron van dat stukje bij deze.
https://almalinux.org/blog/almalinux-for-powerpc-85-stable-now-available/

Welke stabiele en veilige Linux OS zouden jullie op Workstations instaleren vanuit het perspectief van een Systeem beheerder (beheer en onderhoud is belangrijk en security ook uiteraard)?

Gast ? Wil je nou alle bovenstaande posts weer herhaald hebben ?

Dat is precies waar de discussie mee begon.

Ga gewoon deze hele discussie lezen, en vooral degenen die jou (?) al verteld hebben dat die keuze vooral afhangt van welke applicaties je draait , en ook wat je verder in de organisatie gebruikt en waar het beheerteam mee bekend is .

Gezien je vraag - laat de keuze maar aan een collega over die meer ervaring heeft, want je vraag is veel te vaag .

"Welk voertuig zouden jullie kiezen gezien vanuit het perspectief van een wagenpark beheerder".
(uhhh. zou je er niet eens bij zeggen of er koerier, taxi, invaliden vervoer, aannemer, lange afstanden, kraamhulp in de binnenstad mee gedaan gaat worden ? )