Software-update: Debian GNU/Linux 10.10

Debian is een opensource-besturingssysteem, dat zowel voor desktops als servers gebruikt kan worden en waarbij de nadruk op stabiliteit en veiligheid ligt. Het wordt dan ook als basis voor diverse Linux-distributies gebruikt, waaronder Ubuntu en Linux Mint. Versie 10.x, die als codenaam 'Buster' meegekregen heeft, is een zogenaamde Long Term Support-uitgave en zal de komende vijf jaar van updates worden voorzien. De release notes voor versie 10.10 kunnen hieronder worden gevonden.

Debian 10.10 buster released

The Debian project is pleased to announce the tenth update of its stable distribution Debian 10 (codename buster). This point release mainly adds corrections for security issues, along with a few adjustments for serious problems. Security advisories have already been published separately and are referenced where available.

Please note that the point release does not constitute a new version of Debian 10 but only updates some of the packages included. There is no need to throw away old buster media. After installation, packages can be upgraded to the current versions using an up-to-date Debian mirror.

Those who frequently install updates from security.debian.org won't have to update many packages, and most such updates are included in the point release. New installation images will be available soon at the regular locations. A comprehensive list of mirrors is available here.

Versienummer	10.10
Releasestatus	Final
Besturingssystemen	Linux
Website	Debian
Download	https://www.debian.org/releases/stable/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (80)

[hooibergje]

Blijft toch een heerlijk OS. Niet die achterlijke sprongen van Ubuntu, maar wel de betrouwbaarheid die we van Linux gewend zijn.

[Clevergyno]

Wat is er mis met Ubuntu?

[Jim80]

Omdat het "latest en greatest" vaak niet het veiligste en stabielste is!

[GertMenkel]

Stabiliteit is nog wel wat van te zeggen, maar de wijze waarop Debian achterloopt en daarmee zelf alle veiligheidsplatches moet schrijven, testen en doorvoeren zijn niet bepaald geweldig voor de algemene veiligheid van de software.

Als je kijkt naar software als Python 2, waar alleen de maintainers van distributies nog aan werken en patches niet meer door de makers van Python zelf worden gemaakt, zou ik zeggen dat het ondersteunen van oude software veel mankracht kost die bij upgrades beter besteed had kunnen worden.

Ook voor de stabiliteit valt niet altijd wat te zeggen, de makers van de software zullen het grootste gedeelte van hun tijd besteden aan de nieuwere versies. Structurele wijzigingen van de applicatie om de stabiliteit te verbeteren zie je niet terug in oude versies, want die zijn niet zomaar te backporten. Als je software stabiel is zodra Debian het in hun repos toevoegt, behoud je de stabiliteit, maar als de software instabiel is op dat moment, zal het jaren instabiel blijven.

Je kiest Debian vooral omdat je het nu wilt installeren en nooit meer de config wilt hoeven aanpassen tot je over tien jaar de boel nog eens installeert. De veiligheid en stabiliteit zijn afhankelijk van de software die je draait. Je kiest Ubuntu als je Debian met iets nieuwere software wilt. Als je na twee jaar een nieuwere versie van je software wilt installeren, ga je klooien met PPA's of alternatieve repositories en dan ben je meteen alle voordelen qua stabiliteit al wel kwijt...

[vlijmenfileer]

Debian loopt niet achter. Debian liep /vroeger/, gedurende een aantal periodes van zijn bestaan, achter.

Tegenwoordig kun je kiezen uit Stable "belachelijk stabiel", en Testing "zo stabiel als de stable release van andere distributies, en qua up-to-dateheid niets mis mee.

Wat betreft het aspect van ontwikkelaars: ontwikkelaars zijn niet de enige doelgroep voor Linux distributies.

Bovendien is juist het altijd maar gebruiken van de allerlaatste versies van software en libraries door knutselende ontwikkelaars een veel grotere bron van onstabiliteit -in applicaties- dan die in distributies. Het zou dan ook aardig zijn als wat meer ontwikkelaars zich eens gingen realiseren dat distributies er niet zijn om zich te schikken naar de wensen van hippe ontwikkelaars, maar dat ontwikkelaars zouden moeten ontwikkelen voor stabiele distributies.

[GertMenkel]

Debian Stable draait systemd versie 241. Er zijn toch wel een aantal grote wijzigingen geweest sinds dat vrijgegeven is. Debian's stabiele versie van PHP is 7.3, welke in december geen upstream support meer krijgt; een nieuwere versie is momenteel niet beschikbaar tenzij je naar testing of unstable wilt gaan. Python zit op versie 3.7, Java zit op de LTS van Java 11 en niks moderners.

Het is niet zo erg als vroeger, maar Debian is en blijft verouderd door de manier waarop ze hun releases doen. Dat is voor gebruikers vaak best fijn, maar voor ontwikkelaars is dat niet altijd geweldig. Kijk maar naar het drama rond XScreenSaver waar de originele ontwikkelaar werd lastiggevallen door gebruikers van oude versies die al lang niet meer ondersteund worden omdat hij zijn mailadres in het about-venster had gezet en Debian niet wilde updaten. Toen deze een melding in wilde bouwen dat de software verouderd was, is deze weggehaald (want Debian-ontwikkelaars waren het hier niet mee eens). Nu is de ontwikkelaar van XScreenSaver niet echt de... makkelijkste in de omgang, maar zijn punt is valide.

Ontwikkelaars ontwikkelen voor de platformen waarvoor ze willen ontwikkelen. Niet iedere ontwikkelaar is van plan om hun software net als Ubuntu bepaalde versies van hun software tien jaar te ondersteunen. Aangezien ontwikkelaars geen enkele keuze hebben welke versie er precies in de volgende Debian stable release wordt meegenomen, kan zelfs de twee jaar support schedule van Debian een probleem vormen.

Laat de Debian-packagers zich neerleggen bij de keuzes van de ontwikkelaars; als de ontwikkelaars niet van plan zijn om compatible met Debian te blijven, moet Debian hun software niet in hun package repositories opnemen.

Onder de streep is Linux gewoon niet stabiel op de desktop. De Linux-oplossing voor DLL-hell is gebaseerd op het feit dat iedereen hun code aanpast en hercompileert als er grote wijzigingen zijn, wat in theorie leuk is maar in de praktijk vaak misgaat. Games compilen voor Linux wordt daarmee compleet onmogelijk want zelfs als je je eigen code statisch compileert, moet je alsnog rekening houden met de C library die gedraaid wordt, wat alles van de nieuwste release tot een vijf jaar oude versie kan zijn. Ik vind niet dat je de pogingen en problemen van "stabiele" distributies aan de ontwikkelaar moet aanrekenen. Als je nu een stuk software schrijft en vrijgeeft op Windows, weet je dat het over vijf jaar nog gewoon draait. Doe je hetzelfde voor Debian, Ubuntu, Fedora, Arch, noem maar op, dan zul je de komende jaren onderhoud moeten plegen puur om te zorgen dat je software blijft werken.

We gaan nu, met Snap, Flatpak en AppImages, een nieuwe richting op in Linuxland, een die Debian niet snel zal volgen. Het feit dat Flatpak en AppImage daadwerkelijk gebruikt worden, tonen aan dat er een echte vraag is naar een rolling-releaseschema op Linux. Het landschap is simpelweg verschoven van "ieder jaar een major update" naar "iedere maand een release, en iedere halve maand een bugfixrelease".

[Blokker_1999]

Aan de andere kant is PHP7.3 ook weer niet zo zwaar verouderd als je nu doet uitschijnen. Er zijn welgeteld 2 nieuwere versies. 7.4 en 8.0. Om maar iets te noemen. En ik geef de voorkeur voor productieservers aan de filosofie van Debian waarbij men versies stabielhoudt zodat je weet dat je gedurende de levensduur van een release je je geen zorgen hoeft te maken over compatibiliteit of configuratie.

En waarom zou Debian de software niet in hun repo mogen opnemen als zij langer ondersteuning wensen te geven? Met zo een redenering ga je net in tegen de vrijheid die je met FOSS hoort te hebben.

Ik ken ook niet veel software op Linux die spontaan breekt over tijd omdat er nieuwe versies van software beschikbaar komen daar de meeste libraries gewoon neerwaarts compatibel zijn. Vaak vereist men dus gewoon een minimale versie van iets om te werken en soms kan het zijn dat je daarvoor een ander pakket moet installeren dat een oudere versie bevat.

En ja, er zijn mensen en projecten die graag met cutting edge werken en elke paar weken nieuwe releases wensen, maar voor vele systemen gaat stabiliteit nog altijd voor. Containerized apps hebben voordelen, maar vergeet ook niet dat er ook nadelen zijn. Als er nog eens een ernstig lek opduikt in bijvoorbeeld OpenSSL dan heb je met 1 enkele update van bijv. je Debian alles op je systeem beveiligd. Met je containerized apps is dat een ander verhaal. Elke ontwikkelaar moet zijn container gaan bijwerken om het weer veilig te krijgen en je gaat ook weer situaties tegenkomen waarbij mensen bepaalde containers vergeten of net gebruik maken van containers die niet meer ondersteund worden omdat ze daar toch een goede reden voor hadden. Maar ondertussen blijf je wel weer kwetsbaar.

[GertMenkel]

"Modern genoeg" is leuk tot het niet meer goed genoeg is. Ik liep hier zelf tegenaan toen ik HTTP/2 wilde aanzetten in Apache enkele jaren terug; ik had de nieuwste Ubuntu LTS (welke nieuwer was dan Debian op dat moment) maar moest gaan klooien met PPA's om alles werkend te krijgen. Ik voorzie hetzelfde met zaken als eSNI (of hoe de opvolger daarvan ook heet) en HTTP/3, waar packages toch echt een versie zullen moeten worden gebumpt om voordelen te behalen. Sommige bedrijven hebben zelfs contractueel vastgesteld dat ze een bepaalde letter op ssllabs moeten behalen voor hun beveiliging, die kunnen straks niet anders dan upgraden zodra de A+ rating van definitie verandert.

Ik snap dat je voor productiecode stabiliteit boven features prefereert, maar onderschat niet hoe snel oudere software je vrijheid en behendigheid voor nieuwere technologieën kan beïnvloeden.

Debian mag natuurlijk prima de software opnemen, dat is hun goed recht en dat is de basis van de open source. Echter zal het Debian niet in dank worden afgenomen als ze dit doen op een manier die tegen de wensen van de originele ontwikkelaar ingaat. De mentaliteit "het mag van de licentie dus niet zo zeuren" is niet echt bevorderlijk voor open source. Ik heb van het debacle geleerd om nooit mijn eigen naam en contactgegevens in software te zetten die misschien ooit open source zal worden, en om expliciet aan te geven in mijn documentatie dat ik geen support ga leveren voor oude versies. Het is erg jammer dat dat soort dingen nodig zijn.

Ik draai zelf Ubuntu voor het meeste ontwikkelwerk en ik heb meermaals gehad dat ik compatibiliteit met een of andere tool moest repareren door broncode aan te passen of lelijke hacks uit te voeren (ln library.12.so library.13.so en bidden dat de binary compatibility in de toekomst niet kapotgaat). Veel van dit werk wordt door de maintainers van de distributie voor ons gedaan, gelukkig.

Je hebt overigens helemaal gelijk dat het statisch compilen en het gebruik van hele containers voor een applicatie verschrikkelijk zijn voor de veiligheid van je software. Dit is in mijn ogen een zwaar onderbelicht punt bij de meeste containerdistributies. Hoe vaak ik wel niet "productie"-Docker-containers zie rondwaren die gebouwd zijn op vijf maanden oude images en geen enkele updates uitvoeren tijdens het bouwproces...

Ik zie die containers niet als een oplossing maar als een symptoom van een probleem in het Linux-ecosysteem, één waar ik zelf ook geen goed antwoord op heb kunnen bedenken. Het simpele feit is dat je op Windows geen containers nodig hebt voor applicatiedeployment en op Linux blijkbaar wel. De (relatief) recente introductie van microkernels in Windows om een soort van containers te draaien lijkt niet echt populair onder ontwikkelaars, in elk geval.

Ik kijk met veel interesse naar "nieuwkomers" als NixOS die langzaam in productie worden opgenomen en productie-versies van Alpine die het absoluut minimale draaien om niet al te veel breaking changes te hoeven introduceren. Ik hoop dat Docker/snap/etc. hun populariteit verliezen doordat normale deployments beter zullen werken en makkelijker te onderhouden zullen worden in de toekomst.

[Reactie gewijzigd door GertMenkel op 24 juli 2024 11:39]

[Jerie]

Ik vergelijk graag met iOS en MacOS en ik zie dan meer heil in NixOS als oplossing voor DLL-hell dan Snap/Flatpak/AppImage/Docker of een rolling release OS. Als het specifiek om de beveiliging gaat, dan meer de kant op van Qubes.

Stable of Testing is altijd een afweging per organisatie. Wil je de laatste software, of wil je een stabiel OS. Heb organisaties gezien (en nog steeds) waar ze me toch een partij oude software gebruiken. Updaten klinkt zo makkelijk maar is het niet altijd. Het is pas ernstig als beveiligingslekken niet worden opgelost. Of men bij bijv MSIE blijft ipv Firefox/Chrome/Edge/... "omdat Microsoft zegt dat het nog onderhouden wordt en er dus geen tekenen zijn at het onveilig is". Terwijl je prima zo in kunt stellen dat MSIE alleen op interne LAN gebruikt mag worden.

[zordaz]

Backporten van patches e.d. is tijdrovend en duur, maar dat wijkt verder natuurlijk totaal niet af van wat er in de gesloten software-wereld, zoals bij MS Windows speelt. En een mission-kritisch systeem gebaseerd op een rolling release wil je echt niet...

Snap, Flatpak en AppImages kunnen in bepaalde gevallen een probleem oplossen, zeker voor eindgebruikers software waarvan jij voorbeelden geeft. Maar zoals bijv. @Blokker_1999 opmerkt hangt daar ook een flink 'prijskaartje' aan en verplaats je het probleem eigenlijk vooral. Ook zijn er genoeg mensen in Linux-land die vinden dat Snap/Flatpak/AppImages een probleem oplossen dat er helemaal niet is. En ergens kan ik dat standpunt ook wel begrijpen.

Sowieso vind ik dat voor een kaal basis systeem een klassieke installatie van binaries met een stabiel en voorspelbaar release schema in de meeste gevallen de voorkeur geniet. Voor de functionaliteit daar bovenop ben ik heel blij dat je in Linux land zoveel keuze heb en je zelfs kunt 'mengen', deels gewoon klassieke packages en waar je bleeding edge wil eventueel Snap/Flatpak etc.

[Olaf van der Spek]

Debian Stable draait systemd versie 241. Er zijn toch wel een aantal grote wijzigingen geweest sinds dat vrijgegeven is. Debian's stabiele versie van PHP is 7.3, welke in december geen upstream support meer krijgt; een nieuwere versie is momenteel niet beschikbaar tenzij je naar testing of unstable wilt gaan.

Binnenkort komt Debian 11 beschikbaar.. dat de oude software net voor een nieuwe release wat oud is, is niet zo vreemd.

Het zou wel fijn zijn als er 'native' support was voor nieuwere versies van bepaalde software zonder gelijk naar testing of unstable te moeten overstappen.

[FateTrap]

Vergeet niet dat je nog 'Unstable' kunt kiezen: https://wiki.debian.org/DebianUnstable

Nog redelijk veel mensen gebruiken effectief de 'Unstable' variant, alhoewel dit minder stabiel en probleemloos is dan bvb Arch Linux.

Ik heb vroeger jarenlang 'Testing' gebruikt en zou het aanraden, aangezien de paketten in 'Stable' werkelijk oud zijn.

[jimshatt]

Ik draai al jaaaren unstable en slechts zeer zelden heb ik een probleempje. Meestal met een of andere gebroken dependency, maar dan installeer je die update gewoon niet. Je hoeft niet altijd blind dist-upgrade te doen en te bidden dat het werkt. Maar goed, dat is niet de situatie die je je oma of buurman toewenst.

Overigens is flatpak gewoon te gebruiken, dus ik snap niet helemaal wat het probleem van @GertMenkel is.

[GertMenkel]

Flatpak werkt prima maar je verliest er alle voordelen mee van gecentraliseerde package management. Een bug in openssl patch je niet meer door openssl.so te vervangen, in plaats daarvan moet je all je flatpaks updaten, aannemende dat de ontwikkelaars nog regelmatig hun dependencies bijhouden. Standaardpakketten die dynamisch gelinkt zijn hebben dat nadeel niet, en dat is een van de hoofdreden om package managers te gebruiken.

Net als docker is flatpak de "makkelijke" optie; als de dependencies die door externe partijen worden gebruikt te oud, instabiel of juist te nieuw zijn, shippen we wel onze eigen dependencies met eenentwintigen en dames van lichte zeden. Het lost het één probleem op, en veroorzaakt weer een ander.

Als je einddoel is om een applicatie op je desktop te gebruiken en je niet zoveel geeft om kwetsbaarheden in je software, is dat natuurlijk prima. Het zorgt ook dat je software over vijf jaar nog steeds werkt, want alle benodigdheden zijn nog steeds beschikbaar. Aangezien de meestgebruikte applicaties op de Linux desktop toch steeds vaker een iets verouderde, uitgeklede versie van Chromium is, zal het in de praktijk weinig uitmaken (op het verschil in thema na, dan). Het biedt ook een fijne UI voor sandboxing, alhoewel ik me nog niet heb verdiept in hoe veilig die in de praktijk is.

[aldieaccounts]

Net als docker is flatpak de "makkelijke" optie; als de dependencies die door externe partijen worden gebruikt te oud, instabiel of juist te nieuw zijn, shippen we wel onze eigen dependencies

Maar ja, het is het een of het ander. Of je hebt dll-hell, of je hebt static linking (of alle dlls meeleveren, wat op hetzelfde neerkomt).

Ikzelf vind als gebruiker de shift richting flatpack/snap etc een slechte zaak. Maar als developer breng ik ook liever iets via snap/flatpack uit wegens het onderhoud/bijhouden voor nieuwe versies.

Die slinger gaat altijd heen en weer.

[mrmrmr]

Debian waarschuwt dat security updates niet tijdig kunnen zijn. Hangt je systeem aan internet, dan moet je het wel goed bewaken.

Soms is het wel nodig om goed bij te blijven, bijvoorbeeld met crypto libraries. Daar kun je niet jaren mee wachten. Je kan specifiek daarvoor nieuwere versies installeren uit testing (of backports) met een aantal apt configuratie aanpassingen.

Binnen afzienbare tijd verschijnt Debian Bullseye (11). 31 juli wordt als voorlopige datum genoemd.

[casberrypi]

Debian kiest ervoor om bestaande versies te patchen bij security issues, en niet een nieuwe versie van upstream te nemen. De twee redenen daarvoor zijn:

• Geen introductie van nieuwe security issues door andere wijzigingen die meekomen in een nieuwe release
• Stabiliteit staat voorop. Voorspelbaar gedrag dus. Geen toename in geheugengebruik, geen wijzigingen in configuratie files etc.

Debian package maintainers zijn developers. Ze kennen de code van de packages die ze builden en nemen de verantwoordelijkheid daarvoor.

Natuurlijk wil je soms gewoon niet de 'trage' packages van Debian. Omdat je PHP bleeding edge code wil schrijven, moeilijke dingen doet met nginx configuratie of iets dergelijks.

Niets weerhoudt je om packages zelf te bouwen, of om een repository te gebruiken die specifiek een upstream project volgt in de releases. Als PHP developer ga je dus natuurlijk naar https://deb.sury.org/ Ondrej Surý is beheerder van deze repo die de PHP.net releases volgt. Hij is óók de maintainer van de standaard PHP packages in de Debian repo.

Stel dat PHP gewoon een vereiste is omdat je een standaard oplossing installeert omdat je een klant hebt die laten we zeggen Moodle of iets dergelijks gebruikt, dan zijn de standaard Debian packages precies wat je wilt. Geen verrassingen, maar stabiliteit.

[jimshatt]

Eens. En zeker in het geval van PHP of nginx of dat soort serverachtige systemen, die kun je toch beter containerizen. Dan heb je en precieze controle over de versie die je draait, en een extra isolatielaag die ten goede van de veiligheid komt.

[casberrypi]

Ik doe dat zelf liever niet, omdat ik dan van al die containers alle versies moet bijhouden. Een 'vergeten' library versie in een container is misschien een geïsoleerd probleem, maar kan alsnog heftige gevolgen hebben.

[jimshatt]

Het hangt er natuurlijk een beetje vanaf hoeveel containers je hebt. Voor mij vind ik het een veilig gevoel dat als er een kwetsbaarheid in een van mijn containers zit, dat die niet lekt naar mijn andere applicaties.

Maar inderdaad, als je de PHP van je OS gebruikt dan wordt deze automatisch geüpdatet (mits zo ingesteld), dat heeft ook z'n voordelen.

[Guru Evi]

Als je containers ontwikkelt moet je dat in gedachten houden voordat je gaat bouwen. Het gemak van containers is dat je alles dat “oud” is gemakkelijk achter een proxy kunt zetten.

Vroeger deden we dit fysiek (de database was fysiek verbonden via een intern netwerk met de webserver) en kon de meeste productie in een datacenter niet direct naar het Internet. Dan met virtualisatie is men dit een beetje vergeten en opnieuw uitgevonden met containers.

Ik gebruik zelf Snyk daarvoor, geeft regelmatig een e-mail dat er een nieuwe versie van het een of andere dependency.

Met een “gewone” server moet ALLE pakketjes meegaan met de nieuwste libraries of je onderhoudt er meerdere versies van. In de meeste productie omgevingen wil dit echter zeggen dat alles achterloopt totdat alles tegelijkertijd kan omhoog geschroefd wonder.

[Reactie gewijzigd door Guru Evi op 24 juli 2024 11:39]

[Olaf van der Spek]

Je kiest Debian vooral omdat je het nu wilt installeren en nooit meer de config wilt hoeven aanpassen tot je over tien jaar de boel nog eens installeert.

Voor tien jaar moet je bij RHEL zijn, een Debian release wordt niet zo lang ondersteund..

[Htbaa]

Nou... Met Ubuntu ESM krijg je vanaf 18.04 of 20.04 (heb het nu niet bij de hand) nog 's 5 jaar extra updates. Kost je wel geld, maar in theorie kan je dan ook 10 jaar mee met Ubuntu.

[grrfield]

Ik denk dat je Debian kiest omdat je dit wil en Ubuntu voor dezelfde reden. Smaken, wensen en eisen willen nogal eens verschillen. Het hangt ervan af wie je bent en wat je wil. Ik ben redelijk noob, maar heb een homeserver op Debian om wat mee te spelen en wat bij te leren. Ik blijf bij Debian enkel omdat ik er meest vertrouwd mee ben. Wil jijzelf Ubuntu, please go ahead, het mag.

[rob12424]

Uhm ik ben juist bij Ubuntu weggegaan. Met MIR in plaats van Wayland destijds en Unity in plaats van GNOME. Ze maakten echt rare keuzes.

Betreft dat ze zelf de pakketten onderhouden: daardoor zit de gemiddelde kennis wat betreft distro's ook bij Debian. Outsourcen is ook kennis verlies

[saren]

Omdat het "latest en greatest" vaak niet het veiligste en stabielste is!

Want Debian met oeroude software, dat slechts een handvol security backports is wel veilig? Ik snap nooit waarom distro’s als Debian veilig worden genoemd. Stabiel, zeer zeker. Onder veilig versta ik onder andere dat je snel en frequent (security)updates krijgt. Een Fedora is bijvoorbeeld relatief veilig.

[Reactie gewijzigd door saren op 24 juli 2024 11:39]

[Tozz]

Je moet ergens een grens trekken natuurlijk. De URL die je noemt heeft ergens wel een punt, maar de security bugs die in het wild worden misbruikt hebben wel een CVE. Bovendien zijn zelfs veel CVE's eigenlijk niet heel interessant.

Het voordeel van " oeroud" is dat je niet bij elke scheet weer al je software hoeft te testen. Een Debian server die je vandaag installeert werkt met dezelfde software over 5 jaar nog. Want er staat niet ineens een nieuwe versie van - ik noem maar wat - OpenSSL op je server na een update.

En als kanttekening naar jouw URL: Nieuwe software kan ook weer nieuwe security bugs bevatten. Dus in die zin heeft het gebruik van oudere software ook nog het voordeel dat het meer ' scrutiny' heeft ondergaan.

[Jerie]

Want er staat niet ineens een nieuwe versie van - ik noem maar wat - OpenSSL op je server na een update.

Tenzij je een situatie krijgt waarbij je zegt: alles minimaal TLS 1.3 en niet minder. Als je dan met een oude Debian kist zit, dan krijg je backwards compatibility problemen. Dat is een afweging/keuze die je maakt met Stable.

[mrmrmr]

Gelukkig is Debian 10 in de basis wel up to date met TLS 1.3 tegenwoordig. Dat is ook maar goed ook, want zulke zaken moet je niet jarenlang uitstellen. Maar niet alle applicaties zijn in staat TLS 1.3 te gebruiken. Dovecot bijvoorbeeld niet en Apache2 en Exim4 wel.

[asing]

De keuze voor een distro voor een server is niet uit te leggen in de reacties onder een topic. Daar is het landschap veel te groot voor.

Voor Debian valt te zeggen dat het zeer stabiel is, maar dat nieuwerwetse frutsels er niet in zitten. Dat hoeft geen nadeel te zijn maar als je het als bijvoorbeeld webserver inzet, dan wil je juist wel de nieuwere versies van OpenSSL en bijvoorbeeld PHP. Liefst via de package manager om niet in de dependency hell terecht te komen.

Fedora heeft weer andere nadelen. Ja het is cutting edge. Het nieuwste van het nieuwste. Besef ook dat Fedora wekelijks een paar kernels uitrolt. Ook heeft men geen LTS. Het is leuk voor een werkstation (Youtube vind F34 de beste van het moment), maar het is niet geschikt als server. Daarvoor moet je over naar RedHat zelf, of wat vroeger CentOS was.

Bij mij draait inmiddels alles Ubuntu LTS. Pas bij 20.04 kwam TLS 1.3, dus zo vooruitstrevend is Ubuntu ook niet. Het is stabiel, ik heb ongeveer 1 keer per week een reboot wegens de updates en pas in 2025 wordt het tijd om naar wat anders te kijken.

[Crim]

Met een webserver wil je juist niet altijd de nieuwste software of veranderende PHP versies na een update. Je zal maar Magento of iets vergelijkbaars draaien, dan stopt je hele shop ermee na een simpele OS update.

[casberrypi]

Voor OpenSSL zat lang een betere versie in deb.sury.org, maar Ondrej heeft een paar maanden terug besloten dat zijn versie juist niet meer nodig was omdat de standaard Debian versie modern genoeg was.

[Tozz]

Ik gebruik al +/- 15 jaar Debian, en ik ben nog nooit echt in de knoei gekomen door te oude libraries. Er zijn wel eens momenten dat ik iets had van 'Oh dit of dat zou nu wel leuk zijn', zoals HTTP/2 wat nog niet in Debian 9 zat.

Maar het voorbeeld wat jij noemt, dat bv. alles TLS x.y moet zijn dat dan niet in Debian zit heb ik niet meegemaakt. De norm is nu TLS 1.2, en dat zit al sinds Debian Wheezy in Debian, uitgekomen in 2013. 8 jaar geleden alweer ondertussen.

[TrekVogel]

Ubuntu Server is zeker betrouwbaar, Debian is alleen wat conservatiever.

[Duckman51]

Zeker waar, draai thuis Ubuntu server, rock solid so far.

Ik heb Debian wel geprobeerd maar werd er vrij moedeloos van, veel dingen die in Ubuntu standaard zijn zijn dat in Debian niet, zelfs sudo is niet geïnstalleerd. Dat zal allemaal best een bewuste keuze van Debian zijn maar voor mij was het een afknapper.

Als desktop gebruik ik al jaren Manjaro Cinnamon, tot nu toe ook rock solid maar je kunt zo af en toe tegen dingen aanlopen.

[xfj]

De installatie vraagt of je een root wachtwoord wilt, zo niet wordt er sudo geïnstalleerd en het root account gesloten.

Afbeelding

[Reactie gewijzigd door xfj op 24 juli 2024 11:39]

[Blokker_1999]

Meen je dat nu? Hoe heb ik dat kunnen missen al die jaren 🤣

[Duckman51]

Mm dat is mij nooit opgevallen eerlijk gezegd, thanks!

[feico.de.boer]

Ubuntu LTS versies zijn in mijn ervaring een goede balans tussen de conservatieve Debian releases en de latest greatest.

[_JGC_]

Enige probleem bij Ubuntu is dat releases vooraf op een datum gezet worden en dan "if it compiles, ship it". Upgraden naar nieuwste LTS zou ik even een tijdje mee wachten in productie omgeving.

Maargoed, Debian hoeft niet achter te lopen. Software als MariaDB en Postgresql krijgt gewoon de laatste versie in de huidige branch, aangezien upstream hetzelfde beleid heeft als Debian. Verder hebben zowel Debian als Ubuntu 3rd party repositories die goed onderhouden worden. Zie bijvoorbeeld Percona of de PHP repo van Ondrej Sury.

[desalniettemin]

Beter is inderdaad om te wachten op de eerste point release wordt vaak geadviseerd.

[TumTum]

Ben ik niet met je eens. Ik gebruikt Ubuntu al een lange tijd met LXD en nog geen stabiliteitsproblemen gezien. Er is niets mis met Ubuntu op dit moment. Mocht je voor stabiliteit & betrouwbaarheid kiezen, dan kun je de LTS release installeren.

[NielsFL]

Daarom is er Ubuntu LTS. Gebruik zelf zowel Debian als Ubuntu LTS op servers en kan eigenlijk niet zeggen dat de een veel beter is dan de ander. De enige reden waarom wij soms de een over de ander verkiezen is dat bepaalde datacenters of applicaties de een wel officieel ondersteunen en de ander niet.

[GertMenkel]

Ik erger me persoonlijk ten zeerste aan de manier waarop Snap wordt opgedrongen. Ook heeft het net als Debian de neiging om diepgaande wijzigingen aan de software die ze verspreiden toe te voegen, die het niet altijd beter maken.

[Duckman51]

Jep dat is een van de dingen die ik in Ubuntu server er uit gesloopt heb.
Ik vind Ubuntu vwb desktop te commercieel worden, eigen (snap) programma's waaronder bijvoorbeeld Chromium (deb package is er niet meer)

Server gebruik ik wel, met de nodige aanpassingen

[desalniettemin]

Traag met opstarten de eerste keer en de theming is ook niet altijd goed. Wordt aan gewerkt, dat wel. Als je geen snaps wilt, Linux Mint of Pop OS. Heeft ook geen snaps. Kan je wel gebruiken als je wilt: sudo apt install snapd

[Archcry]

Op het moment dat je een long term support (LTS) distributie in de markt zet waar wereldwijd veel gebruik van gemaakt wordt op servers en je pakt een Linux kernel die op het moment van releasen (Ubuntu release doel ik dan op) al end of life (EOL) is dan ben je wat mij betreft gewoon af. Zo draaien de LTS releases 16.04 en 18.04 volgens mij nog op Linux kernel 4.15 die al heel lang EOL is. Dit terwijl ze er ook voor hadden kunnen kiezen kernel 4.14 te gebruiken die gewoon vanuit de Linux community als LTS gelabeld en ondersteund wordt.

En nu kan je natuurlijk wel zeggen "ja maar Ubuntu patcht deze kernel zelf" maar dat vind ik persoonlijk een slecht argument. Bij Linux moet je de kracht van de Linux community gebruiken en niet met je eigen team gaan lopen beunen aan (arguably) het belangrijkste stukje software in je distributie. Vooral niet als het je intentie is om een distributie te zijn die veilig is voor server gebruik.

Nu hebben ze het volgens mij in latere Ubuntu versies (zoals 20.04) wel anders aangepakt maar het euvel blijft dat er momenteel nog twee LTS versies in de markt staan die op een EOL kernel draaien. Het zou mij overigens ook niet verbazen dat een LTS kernel voor 20.04 een happy incident was en dat ze in toekomstige releases weer gewoon lekker hun eigen ding doen.

Lang verhaal kort. Een LTS distributie moet gewoon een LTS kernel draaien en een partij als Ubuntu moet niet zelf gaan lopen beunen aan een EOL kernel die nooit bedoeld is als LTS release.

[Reactie gewijzigd door Archcry op 24 juli 2024 11:39]

[UTMachine]

Ubuntu 18.04LTS draait hier gewoon Kernel 5.4.0 (nee, niet handmatig erop gezet - doet apt zelf)

[Archcry]

Dan hebben ze daar inmiddels een update voor uitgebracht wat het probleem oplost maar op het moment van release was dit niet het geval. Wat mij betreft nog steeds kwalijk maar goed dat het nu wel up-to-date is dan. Is dit ook het geval op 16.04LTS?

[UTMachine]

Klopt, bij release was het nog gewoon de 4.4 kernel. Qua 16.04 weet ik het niet, ik draai het niet (is ook EOS ;-) voor de normale gebruikers)

[Archcry]

Ik heb nog even wat onderzoek gedaan en de versie van je kernel is ook afhankelijk van de keuze voor hardware enablement (HWE). Wanneer je HWE gebruikt krijg je dus ook nieuwere kernel releases. Voor de LTS versies van Ubuntu ziet dit er momenteel als volgt uit:

Ubuntu 16.04 LTS: kernel 4.15 (EOL)
Ubuntu 18.04 LTS: kernel 5.4 (LTS)
Ubuntu 20.04 LTS: kernel 5.4 (LTS)

Ik vind het dan toch bezwaarlijk dat Ubuntu 16.04 LTS momenteel een EOL kernel heeft.

[Reactie gewijzigd door Archcry op 24 juli 2024 11:39]

[hooibergje]

Pulse Audio, Gnome 3, lastig upraden als je een keer een release over slaat.

[oef!]

In de praktijk ben ik blij met beide. Ik gebruik bijna altijd Debian maar het is niet optimaal voor alle applicaties. Soms lopen applicaties out of the box beter op Ubuntu.

[desalniettemin]

Debian is ook niet geschikt voor de nieuwste hardware, want oudere kernel.

[sam_vde]

Je kan ook gewoon iets bejubelen zonder over een ander te zeiken.

[hooibergje]

'rare sprongen' valt nog niet onder de categorie 'afzeiken', toch?

[sam_vde]

Je citeert jezelf verkeerd.

[hooibergje]

OK, 'achterlijke sprongen' was misschien wat overdreven...

[sfranken]

Ik hou het bij RHEL, Fedora en Gentoo. Heb een tijdje Debian als desktop os gehad, maar dat liep teveel achter waardoor hardware niet goed werkte, waardoor ik met alternatieve repos aan de slag moest, wat de ervaring toch wat verwaterde

[Jochem]

Voor desktop zou ik altijd de Ubuntu distro installeren als je in de Debian GNU/Linux hoek wilt blijven.

[TrekVogel]

Maak daar Mint van, Ubuntu zonder fratsen.

[justinkb]

Exherbo eens proberen als je gentoo fijn vindt

[desalniettemin]

Je hebt ook nog Funtoo.

[Hydranet]

Heel wat jaren terug Debian op de desktop gedraaid, daarna over gegaan naar iets anders en daarna nog een paar keer, intussen zit ik nu al weer bijna 2 jaar op Arch volgens mij. Ik hou het bij RHEL voor mijn VPSen en mijn desktop systemen gebruik ik Arch. Ik heb Gentoo nog nooit geprobeerd maar dat je constant met alle updates alles opnieuw moet compileren, daar gaat mij te veel tijd in zitten ook al doet je dat met emerge. Daarmee vind ik Arch een mooie tussen weg.

[Reactie gewijzigd door Hydranet op 24 juli 2024 11:39]

[Jim80]

Ik blijft toch hopen op een snelle release van Debian 11 (Bullseye). 2 jaar na Buster wordt dat hoog tijd.
Debian 10 begint stilaan verouderd te geraken. Zo wordt mijn netwerkkaart en video-kaart RTX3070 van mijn nieuwe pc-build niet ondersteund (ook niet in non-free).

Zo te zien werkt de hardware prima op Bullseye (testing branch) maar helaas toch nog wat bugs waardoor ik nog niet kan overstappen.

[Eärendil]

Voorlopige release datum staat op 31 juli:
https://lists.debian.org/...ase/2021/06/msg00199.html

[itcouldbeanyone]

Ik zit te wachten op een nieuwe Sparc port, buster was hier matig in

[beerse]

Tja, bij debian weet ik dat state-of-the-art hardware minder wordt ondersteund. Vooral vanwege de manier waarop deze software wordt onderhouden en vooral de voorkeur voor opensource en/of vrije drivers. Dat duurt altijd wat langer voordat het echt wordt ondersteunt.

Voor de ondersteuning van state-of-the-art hardware ben je beter af bij meer state-of-the-art linux distributies. Tussen de debian afgeleiden zou ik kijken naar ubuntu, mint of zo iets, die bieden al sneller ondersteuning voor nieuwere hardware. MIsschien zijn er voor jou hardware nog betere/snellere of zelfs een specifieke distributie.

[Marctraider]

Blijft m'n favoriete distro voor m'n x64 router :-)

[me23]

Zou je hier iets meer over kunnen vertellen?

Waarschijnlijk gebruik je liever een distro op eigen hardware vanwege de controle en mogelijkheden?

Waarom dan Debian en niet een andere? Wat maakt het beter dan gespecialiseerde distro's als pfSense bv?

Gebruik je speciale tools om te configureren of ben je gewoon tekstfiles aan het editten?

Tenslotte; op welke hardware draai je?

Zelf gebruik ik al een tijdje Ubiquity (o.a. de USG router) en ik ben daar best tevreden over maar ik kijk wel altijd naar andere mogelijkheden.

[Raven]

"Zou je hier iets meer over kunnen vertellen?"
Tuurlijk

"Waarschijnlijk gebruik je liever een distro op eigen hardware vanwege de controle en mogelijkheden?"
Jup, om IPFire als voorbeeld te nemen: Toen ik die nog gebruikte was ondersteuning voor IPv6 helemaal niet aanwezig (wel werkend te krijgen, ooit eens howto voor geschreven), ondersteuning voor VLAN beperkt en max. 4 netwerkinterfaces (incl virtueel) ondersteund. Dat laatste werd een probleem toen ik met VLAN's ging werken, met 2 interfaces aan de WAN-kant (2e is IPv6-tunnel) en 4 aan de LAN-kant is dat een probleem.

Daarbij is zelf configgen leuker en je leert er wat van

"Waarom dan Debian en niet een andere? Wat maakt het beter dan gespecialiseerde distro's als pfSense bv?"
Stabiliteit, iets waar Debian om bekend staat en voor router-doeleinden heb je niet het nieuwste van het nieuwste nodig, dan voldoet die prima. Plus, bij Debian kun je in de expert install modus een zo minimaal mogelijke install doen, alleen het (voor jou) nodige installeren en that's it. Bespaard systembronnen en updaten gaat een stuk sneller door het lage aantal pakketten dat bijgewerkt moet worden. M.b.t. gespecialiseerde distro's: IPFire, zie vorige vraag, en pfSense (heb ik voor IPFire gebruikt) heeft steeds meer tijd nodig voor er een update uit wordt gebracht, kan een nadeel zijn. Buiten dat is pfSense voor de router-pc beginner wel een goede optie en heeft een grote community.

"Gebruik je speciale tools om te configureren of ben je gewoon tekstfiles aan het editten?"
Met Notepad++ via WinSCP de config-files/scripts editten, of Nano als ik direct via SSH zit te editten en voor het opzetten heb ik een bash-script dat alles installeert en m.b.v. sed en andere commando's goed zet.

"Tenslotte; op welke hardware draai je?"
Op dit moment https://gathering.tweaker...message/62579142#62579142 , de vorige was gebouwd rond een pricewatch: Intel Desktop Board DN2800MT (retail boxed) en die daarvoor (de 1e router-pc) was https://gathering.tweaker...message/43640233#43640233

"Zelf gebruik ik al een tijdje Ubiquity (o.a. de USG router) en ik ben daar best tevreden over maar ik kijk wel altijd naar andere mogelijkheden. "
Mocht je Zelfbouw project: Firewall / Router / AP nog niet kennen, lees die maar eens door

[Reactie gewijzigd door Raven op 24 juli 2024 11:39]

[me23]

Hartelijk dank voor je reactie! Wordt gewaardeerd.

Ik ga me zeker eens verder inlezen.

[Raven]

Same, Debian op de router-pc bevalt zoveel beter dan pfSense en IPFire

[Goldwing1973]

Begonnen met Red-Hat (+25 jaar geleden), toen over naar Fedora vervolgens nog even gespeeld met SuSe en toen naar Debian.
Alleen Debian had ik te vaak rare problemen mee, dus over naar Ubuntu.
Maar, de laatste jaren vond ik dat het -naar mijn idee- rommelig werd bij Canonical, dus sinds 3 jaar toch weer naar Debian, en wat draait dat vreselijk soepel nu zeg, kan ook niet wachten op Debian 11.

[itcouldbeanyone]

Dat waren gouden tijden met linux,
Ik teste zo’n beetje elke distro uit, suse was langertijd een van me favoriete, op mandriva na dan. Helaas zijn vele distro’s verloren gegaan.
Had 20 jaar geleden een HTPC met suse vanwegen de betere audio drivers,
Die hadden een bepaalde naam, geen idee meer hoe dat toen heten.
Gouden herinneringen dus.

Edit: gevonden Alsa driver

[Reactie gewijzigd door itcouldbeanyone op 24 juli 2024 11:39]

[Goldwing1973]

Grootste nadeel van SuSe toen vond ik de configuratie in een enkel bestand.
Ik weet niet of dit nu nog zo is, maar ik prefereer toch liever het /etc/ met verschillende config bestanden, zeker als je ergens een fout gemaakt hebt.

[Verwijderd]

Edit: gevonden Alsa driver

Dude, flashback

[binbash2014]

Gebruik zelf al vele jaren Debian, eerst nog wel een tijdje testing distributie, maar al snel alleen maar stable. Het is een machine waar ik op wil werken en die het gewoon betrouwbaar moet doen. Inderdaad loop je daardoor wel eens achter op de laatste mooie versies van bepaalde software. Nu kun je met apt heel veel trucjes uithalen om bepaalde packages wel uit testing te installeren en de rest alleen stable, maar dat is wel een vak apart ;-) Of je voegt een specifieke repo source toe voor een bepaalde package (bv Google tbv Chrome of Google Earth)

Maar je kunt ook packages van Snap of Flatpak installeren binnen je stable omgeving precies voor die packages die je super actueel wilt hebben of die sowieso niet in de Debian repo zitten. Geen dependencies die je systeem overhoop halen, maar volledige gescheiden alle dependencies bijgevoegd. De moeite van het proberen waard:

https://www.flatpak.org/
https://snapcraft.io/

Flatpak heeft mijn voorkeur, want Snap maakt een zichtbare folder in je homedir en dat lijkt niet wijzigbaar (tenzij via trucje met .hidden file etc, maar dan alleen voor filemanager). Ik ben een oppervlakkige gebruiker van Flatpak, dus dieper liggende voor- en nadelen heb ik niet bekeken. Discord, Zoom, laatste OBS studio, heel handig om op deze manier die paar apps te kunnen gebruiken

[GG85]

Gebruik Debian al een paar jaar voor een pi-hole/vpn server en een torrent server.
Icm met buster-backports heb je dan alsnog actuele software voor alles wat belangrijk is en security updates. Iets als qbitttorrent-nox kun je altijd uit een externe repository halen.

Voor desktop gebruik ben ik minder een fan. Doe me dan maar Manjaro of Fedora.

[WOteB2]

Ik lees hier veel opmerkingen over verouderde zaken in de Stable versie. Niet alles, maar wel veel kan worden opgelost door de backports te gebruiken.
Met met commando (sudo) apt install -t versie-backports naam-programma kun je dan de backports installeren.
Voorbeeld voor Buster: apt install -t buster-backports vlc*
Bijvoorbeeld de nieuwste kernels die ook op Unstable en Testing worden gebruikt. Ook Libreoffice is er zo een en nog veel meer. Dan draai je Stable maar dan wel grotendeels bij de tijd.
Bijkomend voordeel is ook dat een dist-upgrade sneller verloopt, maar dat is puur ´bijvangst´.
Voor meer informatie: https://backports.debian.org/Instructions/
Je kunt voor de zekerheid ook preferences aanpassen waarbij de huidige versie voorrang heeft op de backports

Pin: release a=buster
Pin-Priority: 900
Package:*

Pin: release a=buster-backports
Pin-Priority: 300
Package:*

Pin: release a=stretch
Pin-Priority: 100
Package:*

Dit lijstje zorgt ervoor dat de normale pakketten voorrang hebben, daarna de backports (die dan wel eerst met -t buster-backports zijn geïnstalleerd) en daarna pas Stretch (als je daarvan nog programma´s van in gebruik hebt.
Het bestandje prefererces maak je aan in /etc/apt

Edit: Backports komen dus uit Testing en zijn extra nagekeken op stabiliteit zodat ze bruikbaar zijn voor Stable.

[Reactie gewijzigd door WOteB2 op 24 juli 2024 11:39]