Stabiele Debian 11-release met exFAT-ondersteuning verschijnt

The Debian project heeft de eerste stabiele versie van Debian 11 'Bullseye' uitgebracht. Deze versie van het OS verscheen hiermee ruim twee jaar na Debian 10 en brengt verschillende verbeteringen met zich mee, waaronder ondersteuning voor het exFAT-bestandssysteem.

Debian 11 krijgt onder andere een nieuw thema, genaamd Homeworld. Dat thema is geselecteerd na een poll onder gebruikers, waarin die optie als meest populair werd aangemerkt. Het Homeworld-thema is minimalistisch en geïnspireerd door de bauhaus-beweging die in het begin van de vorige eeuw begon.

De nieuwe versie wordt daarbij geleverd met verschillende geüpdatete package base, blijkt uit de releasenotes. Deze package base bestaat uit ruim 59.000 packages, waarmee deze release ruim 11.000 nieuwe packages meebrengt en ook nieuwere versies van bestaande packages bevat, zoals LibreOffice, GIMP, Nginx, Inkscape, PHP en meer. Het OS wordt daarnaast geleverd met versie 5.10 van de Linux-kernel. Dat is een LTS-versie, die tot december 2026 wordt ondersteund. Debian 10 maakte gebruik van Linux 4.19.

Met de nieuwe kernel krijgt het OS onder andere ondersteuning voor het exFAT-bestandssysteem, dat is bedoeld voor flashopslag. Debian 11 ondersteunt driverloos printen via IPP-USB en gebruikt standaard yescrypt-hashing.

De release van Debian 11 komt vlak voor de 28ste verjaardag van het besturingssysteem. Ian Murdock kondigde op 16 augustus 1993 aan dat de release van zijn Debian Linux Release nabij was, waarna Debian 0.01 op 15 september in datzelfde jaar uitkwam. De eerste stabiele release volgde in 1996. Inmiddels is het op Linux-gebaseerde besturingssysteem erg populair. Debian vormt onder andere de basis voor verschillende andere populaire Linux-distributies, waaronder Ubuntu.

Reacties (73)

Het OS wordt daarnaast geleverd met en versie 5.10 van de Linux-kernel. Dat is een LTS-versie, die tot december 2026 wordt ondersteund.

2026 lijkt niet zo heel ver weg en dat is het ook niet, maar een vrijwilligersorganisatie kan moeilijk dingen beloven die ver in de toekomst moeten gaan gebeuren. Die 2026 is vooral een minimum, als er genoeg mensen zijn die er tijd/geld in willen steken kan het langer worden.
De kernel van Debian 8 (dat in 2015 uit kwam) wordt nog steeds ondersteunt via het Debian Extended Long Time Support project en zal in ieder geval tot 2022 worden ondersteunt.

Ik kan het niet nalaten om op te merken dat je daar vooral geen gebruik van moet maken. Software heeft nu eenmaal onderhoud nodig. Hoe ouder de software hoe moeilijker dat onderhoud is en hoe groter de stappen zijn die je moet nemen. Na een jaar of vijf is het vaak makkelijker om een systeem helemaal opnieuw te bouwen dan het te upgraden. Nieuwbouw is vaak heel onvoorspelbaar. Ik heb al te vaak gezien dat dat soort projecten hopeloos vast komen te zitten. Na een aantal jaar is de kennis weggezakt, hebben de beheerders een andere baan, en is het oorspronkelijke budget op en niet verlengd want die oude applicatie zou toch vervangen worden. En dat is het moment dat iemand aandraagt dat je wettelijk verplicht bent om de data nog 5 jaar te bewaren.

Mijn advies is dus om vaak en snel te upgraden. Wacht niet dat het nodig is want als er dan iets mis gaat dan heb je een groot probleem. Als je vaak ugprade dan blijven de stappen klein en overzichtelijk, blijft de kennis en vaardigheid van je beheerders op orde en zijn tegenslagen nog oplosbaar.
Maak nooit gebruik van extended of long-time support als je het kan voorkomen. Upgrade zodra er een nieuwe major versie is. Het beste kun je al beginnen met testen voor er een release is, dan kun je nog makkelijk verandering doorvoeren als dat nodig is of bugs laten fixen als je ze tegen komgt.

Die extra support is er voor je archief. Als je helemaal klaar bent met een applicatie/systeem en niemand er nog actief gebruik van maakt, dan kun je over gaan op die extra support. Die is er voor het geval dat je er over 5 jaar er achter komt dat je toch nog iets nodig hebt van dat oude systeem, bijvoorbeeld omdat de belastingdienst of een of andere inspectie je komt controleren.
Als je dat anders doet dan moet je op zo'n moment een systeem aanzetten dat misschien wel 10 jaar geen groot onderhoud heeft gehad en kwetsbaar is voor alle grote exploits. In theorie kun je dat dan weer mitigeren door zo'n systeem in een afgeschermd netwerk te starten of in een geisoleerde VM, maar laten we eerlijk zijn, als puntje bij paaltje komt hebben we daar geen tijd, buget of kennis voor. Op dat moment gaat niemand nog eens in zo'n systeem investeren. Dan wordt het gewoon aangezet zodat er data uit getrokken kan worden. Alle ssl-certificaten, wachtwoorden en licenties zijn dan verlopen en je bent eerst een tijd bezig om de laatste restjes beveiliging van je eigen systeem af te slopen.
Niet doen dus, snel upgraden zodra het kan.

Meer voor desktop en niet debian laatste keer dat ik naar kernel 5.10 upgrade werkte bijna al mijn drivers niet meer. Terwijl op kernel 5.4 alle features van mijn moederbord out of the box werken.
Dit met een gigabyte x570 moederbord.

Ik draai op dit moment Debian 11.0 met kernel 5.11.22-3 met daar bovenop Proxmox en ik heb totaal geen problemen. Debian draait echter alleen als een host omdat ik verder gewoon virtueel draai maar desondanks met alles verder pass-through nog steeds perfect.

Gebruik jij dan apt om te upgraden of is er proxmox specifieke upgrade procedure ?

Nee, gewoon apt. Proxmox gebruikt ook Debian. Enige reden dat ik apart Debian geinstalleerd heb is vanwege de full disk encryptie omdat dit niet (of te lastig) in te stellen is via een Proxmox only installatie.

Zou ook interessant zijn om file server (samba, NFS) bare metal te draaien ipv via een VM guest en virtualised storage.

je kan ook een LXC configureren als fileserver, met de storage van proxmox als mount points. Wel gevirtualiseerd maar minimale overhead.

bijv webmin erop, en alles via gui configureren (FTP, SFTP, Samba, NFS etc).

[Reactie gewijzigd door Rayures op 16 augustus 2021 09:19]

je kan ook een LXC configureren als fileserver, met de storage van proxmox als mount points. Wel gevisualiseerd maar minimale overhead.

Ja dat is mogelijk een manier. Ik wil namelijk zfs snapshots met de shadow_copy2 vfs object in samba. En ZFSinVMStorageBlobOnZFS zie ik niet zitten.

bijv webmin erop, en alles via gui configureren (FTP, SFTP, Samba, NFS etc).

Je bedoelt ... cockpit ... Ik heb slechte herrineringen met Webmin.

[Reactie gewijzigd door goarilla op 15 augustus 2021 21:58]

Ik heb een paar file shares (Samba) op mijn bare metal Debian systeem. En die benader ik virtueel. Maar het is niet voor belangrijke storage. Daarvoor heb ik een Synology NAS.
Een hypervisor is specifiek ontworpen om een zo kleine mogelijke footprint te hebben. Maar desondanks vind ik het wel fijn om de vrijheid te hebben deze uit te breiden met dingen die ik interessant vind.
Virtueel draaien was voor mij een logische stap. Wanneer benut je nou volledig jouw desktop systeem (even buiten het evt gamen - hoewel een cpu dan meestal ook niet 100% benut wordt want die zijn toch meer gpu based).

Ik heb de Proxmox update gedraaid naar Proxmox 7 met Debian 11. Is redelijk vlotjes verlopen, ware het niet dat er iets mis ging met het networking service. De bonding van twee kabels werd niet meer goed ingesteld in de interface config, waardoor de server geen netwerkverbinding had. Als je - net als ik - de update via de web-gui of ssh laat lopen, dan kun je de update niet afronden. En dat is wel ruk. Na lokaal een scherm en een toetsenbord te hebben aangesloten kon ik het afmaken. Vast een beginnersfoutje. Verder is Proxmox ideaal. En ook diverse VMs heb ik al geüpdatet naar debian 11. Werkt vooralsnog als een zonnetje.

Ik weet niet vanaf welke versie je kwam, maar vanaf 10? is netplan de default network manager. Dat was daarvoor op Ubuntu/Debian een andere. Zo verloor ik ook na een upgrade networkconnectie. Een manier om dit te voorkomen, mocht je meerdere oude machines hebben, is netplan eerst installeren+configureren, en daarna een in-place upgrade te doen. Of de correcte yaml voor netplan meegeven in je update-script. (mocht je het via cloud-init, Ansible o.i.d. doen)

[Reactie gewijzigd door ItsNotRudy op 16 augustus 2021 00:09]

Debian gebruikt standaard geen netplan. Proxmox gebruikt het ook niet.

Met Fedora heb ik bijna elke dag een nieuwe kernel. Nog nooit dat probleem gehad, ook niet met de 5.10 kernel. Inmiddels zit ik op 5.13.8.

Edit: Alweer update binnen voor 5.13.9-200.fc34

[Reactie gewijzigd door UPPERKEES op 15 augustus 2021 15:04]

Dus virtualbox, nvidia drivers, zfs, ... wordt iedere keer middels dkms en dracut vermoed Ik lekker succesvol herbouwt en in een nieuwe initrd geplaatst. Dat is sterk want ik deed dat manueel vroeger (Slackware) en dat brak toch regelmatig door bv: nieuwe, gewijzigde of verwijderde kernel structuren.

Dat zijn dingen die niet met de Linux kernel te maken hebben Je bouwt een 3rd party module. Probeer eens virt-manager te gebruiken of GNOME Boxes ipv. Virtualbox. Dat maakt gebruik van KVM, de native virtualisatie in de kernel. nVidia is altijd brak geweest op Linux, sinds ik de native open-source Intel drivers gebruik werkt alles perfect. ZFS is zover ik weet nog steeds geen standaard binnen Linux.

[Reactie gewijzigd door UPPERKEES op 15 augustus 2021 19:41]

Idem, echt nooit een probleem mee gehad en ook steeds het laatste.

Ik had hier ook een partij problemen mee. Ik had mijn laptop lange tijd niet gebruikt. (Kubuntu 21) en heb eens een keer blind geupgrade waarmee ook de kernel mee kwam. Dat was even schrikken. Ik dacht toen van ja ik heb er toch eigenlijk niks op staan dus opnieuw installeren is helemaal zo'n ramp niet. Toch vervelend.

Opstarten met de oudere kernel werkte ook niet? Bij Ubuntu blijft in ieder geval de voorlaatste kernel beschikbaar, voor dit soort problemen.

Yes, werkte wel. Het was precies zoals bij de persoon waar ik op reageerde. 5.10 sloopte de boel, de vorige kernel, 5.4.nogwat werkte dikke prima. Had er geen zin meer in tho. Besides, distro hoppen is leuk, zeker op een device wat niet mega vaak meer wordt gebruikt.
Het wordt eens tijd om Pop_OS een eerlijke kans te geven nu ik die laptop af en toe weer nodig ga hebben.

Dat is bijzonder en niet wat ik gewend ben. Ik tik dit vanaf een Gigabyte X570 Auros Pro die momenteel kernel 5.10.0-8 draait en al sinds januari versies van 5.10.0 draait. Natuurlijk kan er altijd ergens iets stuk gaan, maar als meerdere drivers tegelijk uitvielen denk ik dat er iets geks aan de hand is geweest. Al houdt het natuurlijk snel op als de ene stukke driver de PCI-ondersteuning is

Ik zou me daar dus niet te veel zorgen over maken.

Merci, ik heb dezelfde mobo, dus ik kan veilig upgraden naar 5.10, mocht M20.2 dat ondersteunen. Iets voor een ander weekend.

Vreemde hardware dan. Mijn eigen desktop draait al vanaf Fedora 20 en heeft dit issue nog nooit gehad. Let op, Fedora 20 was Linux 3.11. Draai nu Fedora 34 met 5.13 geen issues..

Correctie: typo

[Reactie gewijzigd door sfranken op 15 augustus 2021 16:21]

Daarbij moet opgemerkt worden dat het Debian Extended Long Time Support project alleen tegen betaling (2040 euro / 6 maanden) updates levert. De reguliere Debian LTS levert ongeveer vijf jaar support na de releasedatum.

Daarnaast wordt door onder extended LTS de originele Linux 3.16 uit Debian 8 niet meer ondersteund, maar wordt een backport van Linux 4.9 gebruikt.

[Reactie gewijzigd door praseodymium op 15 augustus 2021 17:01]

Daarbij moet opgemerkt worden dat het Debian Extended Long Time Support project alleen tegen betaling (2040 euro / 6 maanden) updates levert. De reguliere Debian LTS levert ongeveer vijf jaar support na de releasedatum.

Om precies te zijn betaal je voor het werk van de beheerder, de "levering" is gratis, als de packages er eenmaal zijn mag iedereen ze gebruiken. Je kan de instructies hoe je dat doet hier vinden: https://deb.freexian.com/.../how-to-use-extended-lts/

Je betaalt om (mee) te bepalen welke packages er worden bijgewerkt. Mensen die voor deze dienst betalen zijn bijvoorbeeld typisch niet geinteresseerd in spelletjes maar bijvoorbeeld wel in webservers, databases en PHP. Als je zo'n contract afsluit dan maak je afspraken over op welke packages je precies support wil hebben. Freexian (het project waar het hier om gaat) maakt een inschatting van hoeveel betalende gebruikers er voor ieder package zijn, verdeelt de kosten en doet je dan een aanbod. Zo van "de apache, mysql en php packages die vraagt worden door 100 klanten gebruikt dus die kunnen we allamaal samen voor 1000 euro ondersteunen, maar je bent de enige die ook de ene gekke plugin wil, dat kost je 500 euro extra".

Maar je mag dus alle packages gewoon gebruiken, of je nu betaalt of niet. Maar als er problemen zijn dan helpen ze uiteraard en alleen de betalende klanten met de packages waar ze voor betalen.

[Reactie gewijzigd door CAPSLOCK2000 op 15 augustus 2021 14:09]

Ik wist niet dat de updates wel gratis worden aangeboden, dankjewel!

LTS is bedoeld voor het langdurig supporten zonder grote upgrades uit te voeren. Als LTS eol is. Zal deze ruim van te voren geüpgraded worden door een nieuwe versie.

Dat een OS 5 jaar ondersteund wordt is alleen maar fijn ipv elk jaar je omgeving volledig te upgraden wat meer geld en tijd kost dan eens in de 5 jaar en dan hier te genieten van security en feature updates.

Dat een OS 5 jaar ondersteund wordt is alleen maar fijn ipv elk jaar je omgeving volledig te upgraden wat meer geld en tijd kost dan eens in de 5 jaar en dan hier te genieten van security en feature updates.

Daar ben ik het dus niet meer eens. Eens in de 5 jaar upgraden betekent dat al je kennis en ervaring met het systeem 5 jaar oud is en waarschijnlijk moet je dan twee of drie major upgrades tegelijk doet wat het niet makkelijker maakt. Daarbij heb je weinig tijd om het te doen want je oude systeem zit zonder support.
Ik zeg daarom dat beter veel en vaak kan upgraden zodat je kleine stappen kan maken en je kennis en vaardigheden actueel houden. Als het dan een keer niet direct lukt of niet kan dan zit je niet direct met een systeem dat onveilig is en waarbij je geen hulp meer kan krijgen met je problemen. (Nou ja, als je maar genoeg betaalt kun je altijd support krijgen, maar dat kan duur worden).

Nou zijn er zelfs releases die wel 10 jaar ondersteuning krijgen, dus je hoeft niet direct zonder support te zitten. Maar we weten allemaal hoe IT projecten uit de hand kunnen lopen doordat ze moeilijke te plannen zijn. Als je mikt op iedere 5 jaar upgraden dan zal dat in praktijk betekenen dat er ook een hoop systemen zijn die langer nodig hebben. Dan wordt de upgrade eerst een jaartje uitgesteld, dan kost het een jaar om alles te testen en voor te bereiden en tegen de tijd dat het helemaal klaar is ben je 8 jaar verder. En dan wil de belastingdienst dat je alle oude data nog 7 jaar bewaart en terwijl je systeem nog maximaal 2 jaar support heeft en moet je alsnog extra gaan investeren om dat oude systeem ook draaiend te houden.

Nu kan het allemaal meevallen als je zorgt dat alles klaar staat zodat je op het moment dat een nieuwe LTS uitkomt alles al getest hebt met de prereleases. Maar ik zie toch meestal dat organisaties wachten tot de nieuwe versie definitief is voor ze er voor het eerst naar kijken. En daarna beginnen ze pas met een upgrade-traject te plannen. Natuurlijk is het overal anders en sommige organisaties hebben hun IT zo strak op orde dat ze nooit dit soort problemen hebben.
Maar volgens mij hebben de meeste organisaties wel een paar lijken in de kast. Als je mikt op 5 jaar dan is dat het minimum, dan zal het gemiddelde eerder 6 of 7 jaar zijn en de uitschieters meer dan 10 jaar.

Ik vind dus dat je vaker een major upgrade moet doen, iedere twee jaar ofzo. Dat is best vaak. Als er een ruim traject een testen en voorbereiden bij zit dan ben je eigenlijk fulltime bezig. Je zal het dus moeten automatiseren, inclusief het testen. Dat sluit mooi aan bij de Continuous Integration/Continuous Deployment en DevOps en Test Driven Development bewegingen.
Volgens mij heb dat toch steeds meer nodig, IT-systemen zijn complex en verweven met andere systemen die in hun eigen tempo veranderen dat echt statische systemen eigenlijk niet bestaan. Je moet dus toch voortdurend monitoren en testen.

Je vergeet dat lts versies de continuïteit waarborg. Als jij een server park heb met een paar honderd machines wil je niet elk half of heel jaar een upgrade van je omgeving uitvoeren.

Voor cliënt devices is het een heel ander verhaal. Maar je database server of web applicaties zullen eerst door een test straat heen moeten lopen. Je bent zo een half jaar tot een jaar bezig met het testen van je applicaties. In de tussen tijd wil je dat je systemen online blijven.

Dat betekend dus dat veel bedrijven en ook ITers er voor kiezen om een aantal jaar de machines te onderhouden security op orde te houden en bij de volgende lts versie die elke 3 a 4 jaar uitkomt de omgeving te migreren vaak valt dat dan ook samen met hardware vervanging voor bepaalde systemen.

Je kan niet zomaar van een op de andere dag in een Enterprise omgeving zeggen oh. Vorige week is een nieuwe versie van Het OS uitgekomen. Laten we even alle servers upgraden. Dat is een tamelijk zwaar process waar maanden voorbereiding en uitzoek werk noodzakelijk is.

Ik ben het met je eens dat je wel mee moet met de tijd. Je moet upgraden om bij te blijven. Maar in het tempo elk jaar een nieuwe versie dat gaat gewoon niet. Eer je klaar bent met je migratie kan je opnieuw migreren. Je hebt dan geen tijd om verbeter slagen te maken.

Upgraden wanneer je omgeving uit support loopt ja dan ben je te laat. Dat moet je in calculeren. Je bent een jaar bezig met je omgeving te migreren. Je gaat dan twee jaar support leveren en verbeteringen doorvoeren. Hierna ga je opnieuw bekijken of je moet gaan upgraden en nieuw upgrade plan maken. Soms vervallen applicaties soms is de software die je gebruikt nog niet zo ver.

Het automatisch testen wordt al vaak gedaan. Veel resultaten worden overgenomen om uiteindelijk de laatste testen te doen. Veelal werkt containerized applicaties hier ook al goed in mee. Maar dan nog grote omgevingen met soms wel duizenden servers kan je niet elke twee jaar van een major upgrade voorzien.

[Reactie gewijzigd door To_Tall op 15 augustus 2021 20:11]

Het OS wordt daarnaast geleverd met en versie 5.10 van de Linux-kernel. Dat is een LTS-versie, die tot december 2026 wordt ondersteund.

een vrijwilligersorganisatie kan moeilijk dingen beloven die ver in de toekomst moeten gaan gebeuren

Als ik die laatste zin letterlijk neem, gaat dat niet over Debian (Extended LTS) maar de kernel.
De LTS kernel zitten ook betaalde krachten achter (oa Linux Foundation), en het was opgerekt naar 6 jaar vooral omdat bedrijven daar behoefte aan hadden (bijv Android en embedded).
Weet niet uit mn hoofd hoe dat geld allemaal stroomt, maar ik mag aannemen dat die daar ook wat aan bijdragen.

Dan hoeft Debian alleen nog maar het resultaat daarvan te compilen, simpel gezegd.
Er zal mss hier en daar nog n bug gevonden worden in het Debian-deel, maar dat is niet bijzonder veel als je t vergelijkt met andere niet-kernel pakketten waar datzelfde voor geldt.

[Reactie gewijzigd door N8w8 op 15 augustus 2021 17:10]

Wil graag inbrengen dat zo'n upgrade na meerdere jaren bij mij nooit voor problemen heeft gezorgd in het geval van Debian. In de praktijk heb ik niet de resources om zo'n server elk jaar over de kop te gooien. Alle applicaties die erop draaien moeten dan ook weer opnieuw getest worden en er is downtime.

LTS is juist perfect als je niet de latest en greatest hoeft te draaien, maar gewoon de zekerheid wilt dat een applicatie jarenlang blijft werken. Ik vind het veel belangrijker dat de upgrade gepland wordt dan hoe vaak deze wordt uitgevoerd. Debian geeft uiterste data aan dus dat kan jaren van tevoren al worden bepaald.

Bij de tijd blijven moet iedereen, of je nu je servers een upgrade geeft of niet. Ik besteed liever tijd aan het lezen van nieuwe ontwikkelingen in Linuxland, dan dat daarvoor geen tijd heb omdat ik voortdurend operationele en testtaken uitvoer.

[Reactie gewijzigd door Ablaze op 15 augustus 2021 19:40]

Vroegâh, in de tijd dat er nog best veel nieuwe ontwilkkeling in linux zat (reken tot ongeveer 2000) zou ik ook gesteld hebben dat een systeem niet steeds met de nieuwste versie mee moet. Toen was het nog reëel om het 'nu' werkende te laten werken.

Wel was het toen ook zo dat na 3 of 5 jaar ook de hardware zo ver was door ontwikkeld dat het zin had om zowel nieuwe hardware als ook nieuwe software te gaan gebruiken. Dan was een upgrade gewoon vervangen door wat nieuws. Wel zo makkelijk omdat de oude kon blijven draaien tot de nieuwe klaar was.

Tegenwoordig kan de hardware rustig 5 ot 8 jaar mee komen, zeker als het ruim genoeg in het jasje is begonnen. Dus zou je voor de software wel een keer een complete update of upgrade kunnen gebruiken. Daarmee is ook de software al zeker 10 jaar volwassen genoeg om gewoon mee te kunnen groeien. Er zitten niet zo heel veel grote wijzigingen meer in linux en de meeste open source software, het is gewoon groei, misschien hier en daar wat evolutie. maar beslist geen revolutie zoals we eind vorige eeuw nog in linux zagen.

Dat gezegd hebbende denk ik dat een long-term-support versie zeker wel zin heeft maar voor de gewone systemen gewoon een beetje bij houden ook heel goed kan. Dan is de update/upgrade misschien wel 1 of 2 keer per jaar maar beslist geen grote stap met grote gevolgen. De stappen die je moet zetten als een lts versie moet worden bijgewerkt naar de volgende lts versie zijn veel groter.

Er kunnen genoeg redenen zijn om snel te upgraden en ook om dat niet te doen. Dat moet je echt per geval cq. organisatie bekijken. Ik kan daarom niet meegaan in je advies. Daarnaast is er een groot verschil tussen zakelijk en niet zakelijk gebruik. Mijn niet zakelijke Debian knutselsysteem heb ik in 2001(!) geinstalleerd en sindsdien altijd geupgraded zonder al te veel problemen, dat ka n dus echt.

En dat is het moment dat iemand aandraagt dat je wettelijk verplicht bent om de data nog 5 jaar te bewaren.

Maar op zich kun je het systeem wel van het internet of netwerk halen. Dan is het minder van belang dat de boel veilig is.

Maar op zich kun je het systeem wel van het internet of netwerk halen. Dan is het minder van belang dat de boel veilig is.

Tot je de data nodig hebt, in de meeste gevallen wordt zo'n systeem dan gewoon weer online gebracht. In theorie kun (nee, moet) je het naar een andere netwerk verhuizen of geisoleerd starten maar in praktijk is dat al snel een hoop gedoe waar we liever niet aan beginnen. Bijvoorbeeld omdat je dan eerst op de server moet inloggen om het wachtwoord te veranderen en dat gaat niet want het ssl-certificaat is verlopen of het admin wachtwoord is niet meer geldig of het systeem kent je nieuwe SSH-key nog niet of firewall/acl regels verhuizen, of zo iets. Er is altijd wat. Dus wordt het systeem "gewoon even" aangezet, ondanks alle beloftes die vooraf zijn gedaan.

Dat vind ik opmerkelijk. Vroeger, als je obscure data moest hebben, dan moest iemand in een archief duiken. Dat kon best even duren.

Het zou helemaal niet gek zijn om hetzelfde toe te passen in geval van belastingonderzoek of AVG-verzoek. Zelfs niet in geval van COVID-19 waarbij remote toegang de standaard is geworden. Dan kun je namelijk beargumenteren (en bewijzen) dat het overmacht betreft.

Inderdaad is Debian een stabiele en wellicht Saaie Linux distributie.

Wat ik wel interessant vind (en niet alleen van Debian) is het aantal packages. 59 duizend !
Natuurlijk zit je al snel op hinderden. Maar 59000?
En dan ook nog 11000 nieuwe op 59000 totaal, en dat in twee jaar tijd?
Dat lijkt dan helemaal weer niet saai. 24 % extra packages.
Kan iemand uitleggen waarom zo veel ‘verandering’?
Of is het de drang naar microservices, dus in feite hetzelfde maar dan in kleinere brokken?

Of is het de drang naar microservices, dus in feite hetzelfde maar dan in kleinere brokken?

Een DB server als MariaDB bestaat uit iets van tien packages, een C++ library als Boost bestaat uit 100+ packages, PHP bestaat ook uit tig packages. Dan loopt het snel op.
11000 nieuwe packages betekent dus niet 11000 nieuwe apps.

Plus veel libraries met api-breaks komen als nieuw package met een versienummer in de package naam erbij, zodat op een systeem twee verschillende versies van de library te installeren zijn.

Het aantal packages is ook niet zo relevant. Belangrijker is dat ik zo min mogelijk van buiten de standaard repo nodig heb. Dat gebeurt natuurlijk wel regelmatig helaas. Gelukkig zijn we qua libraries met Debian goed voorzien, en is de rest wel bij te houden.

Ik denk niet dat er een enkel antwoord is, maar er wordt natuurlijk veel ontwikkeld in de linux wereld. Veel van die packages hoeven natuurlijk ook geen binaries te zijn. Libraries, source packages e.d. worden ook gepackaged. Dikke kans dus dat een groot percentage van die groei dependency packages zijn. Maar dat is een aanname zonder gekeken te hebben naar de package list.

Of is het de drang naar microservices, dus in feite hetzelfde maar dan in kleinere brokken?

Volgens mij speelt dat wel een rol maar is het geen bewuste keuze van Debian maar een van de upstream ontwikkelaars. Sommige programmeeromgevingen splitsen dingen graag in hele kleine stukjes op, bv veel javascript spul. Logischerwijs krijg je dan ook veel Debian packages. Die worden semi-automatisch en in bulk aangemaakt.
Ik zie al meer dan 1000 node js packages, al heb ik geen idee hoeveel daarvan nieuw zijn in deze relese.

Er zijn verschillende redenen voor, in tegenstelling tot andere distros splits Debian hun software vaak op om installaties minimaal te houden. Als je GTK installeert dan worden de development files niet mee geleverd, veel andere distros zoals Arch die doen dit wel. Daarnaast valt het ook op dat Debian zeer veel development files in de repos heeft. GTK heeft 12 gtk-dev packages voor AMD64, in tegenstelling heeft OpenSUSE er maar 5, en Arch 0.

Ik heb zelf nog even een snel gekeken uit nieuwsgierigheid, en in de Debian AMD64 main data repo staan exact 59633 packages. En hou dan in het achterhoofd dat al deze packages meerdere malen worden gebouwd voor verschillende architecturen (i386, MIPS, RISC-V, PowerPC etc..) en zelfs voor Debian GNU/Hurd. Wat een werk om dit allemaal geautomatiseerd te krijgen en het draaiende te houden.. respect.

Wat veel mensen hier beschrijven als "saai" noem ik kneedbaar, ik kan er zelf van maken wat ik wil. Dat is waarom Debian zo geweldig is.

Hoeveel sofware is er niet wereldwijd voor windows?
Zoals iemand anders in dit draadje al zegt, zijn al die paketten niet allen software paketten.Veel packages zijn libraries waarvan de paketten afhankelijk zijn om te kunnen draaien.

Het is altijd bijzonder wanneer een nieuwe Debian major release is omdat dit zo'n rots in de woelige Linux branding is. Debian releases lijken af en toen een beetje saai omdat ze zelden iets nieuws introduceren maar vooral doen wat anderen al jaren eerder hebben gedaan. Maar Debian zet de standaard. Als iets in Debian is aangekomen dan is meestal bewezen techniek die heeft laten zien klaar te zijn voor productie. Ala het onder Debian werkt dan werkt het ook op de meeste andere Linux-distributies of is in ieder geval werkend te krijgen.

En dat is precies waarom Debian een goede distro voor servertaken en doorgaans een minder goede keuze voor je desktop ervaring is. Natuurlijk kan je Debian prima als desktop distro gebruiken, maar je hebt dan vaak de keuze uit of verouderde software, of je systeem volzetten met meer cutting-edge software wat er direct voor zorgt dat Debian zijn kracht kwijt is. Als je een distro voor je desktop wil zijn er betere alternatieven die OOTB al met cutting-edge of bleeding-edge packages komen. Natuurlijk 'zoveel mensen, zoveel wensen' maar ik kies dan liever voor een Ubuntu Server distro waarop ik mijn eigen spul installeer. Dan heb je de bloat van Ubuntu Desktop niet en gelijk support voor de meeste moderne packages.

Als server distro blijf ik wel fan van Debian, al het soms wel vrij frustrerend kan zijn dat ze achter lopen op bepaalde zaken als PHP of libvirt. Gelukkig is dat sinds Debian 9 niet meer zo'n probleem als de versies daarvoor though. Fijn dat 11 nu uit is. Nu nog even een paar weken wachten en dan kunnen wij onze productie ook weer gaan upgraden .

al het soms wel vrij frustrerend kan zijn dat ze achter lopen op bepaalde zaken als PHP

https://deb.sury.org/

Ik ben me inderdaad bewust van third party repos, maar dat is precies wat ik bedoel in mijn eerste post. Third party repos zijn niet altijd te vertrouwen en wil je vaak het liefst zoveel mogelijk weghouden van productieomgeving bij zakelijk gebruik. De kracht van Debian is dat juist zulke packages in de main repos goed doorgetest worden en de distro het voor een groot deel van zijn stabiliteit daarvan krijgt. Zoals ik al zei, zoveel mensen, zoveel wensen. Dit is puur mijn kijk erop

Dan symlink je toch? Je kan 2 versies van PHP naast elkaar draaien. Als je ze maar pinned met upgraden enz. en symlinken en de juiste programma's naar de juiste symlinken/paden enz. Verwijst.

Ik ben het met je eens het is in het begin heel veel werk als je alles uit moet zoeken maar als het 1 maal draait. Dan niet meer als het goed is. Ik heb het vroeger met PHP en Debian ook een keer moeten doen.

Wat heeft symlinken te maken met het toevoegen van een 3rd party repo en daaruit software installeren?

De 3rd party repo is niet nodig dan. Je kan ook offiele repo's gebruiken bijvoorbeeld van testing. Enz

Wat het te maken heeft. Stel programma A heeft PHP 4 nodig dan installeer je PHP 4 en maak je de pathways van programma A (symlink) je naar PHP 4 daarnaast pin je de upgrade vast enz. Dat hij niet verwijderd wordt maar ook niet geüpgrade.

Terwijl de rest gewoon op PHP 5 draait. Dit kun je met apt en Debian gewoon doen al is wat kennis van DPKG enz. Wel vereist. 😉

Ik heb even gezocht. Ik noemde het slinken maar het heet eigenlijk Pijpen volgens mij. In sommige gevallen moet je ook je pakketten hercompileren met nieuwe cflags (,oude methode)

https://stackoverflow.com...sions-on-the-same-machine

Package Managers - user-level

For a package manager that can install and manage multiple versions of python, these are good choices:

pyenv - only able to install and manage versions of python
asdf - able to install and manage many different languages

The advantages to these package managers is that it may be easier to set them up and install multiple versions of python with them than it is to install python from source. They also provide commands for easily changing the available python version(s) using shims and setting the python version per-directory.

This disadvantage is that, by default, they are installed at the user-level (inside your home directory) and require a little bit of user-level configuration - you'll need to edit your ~/.profile and ~/.bashrc or similar files. This means that it is not easy to use them to install multiple python versions globally for all users. In order to do this, you can install from source alongside the OS's existing python version.
Installation from source - system-wide

You'll need root privileges for this method.

See the official python documentation for building from source for additional considerations and options.

/usr/local is the designated location for a system administrator to install shared (system-wide) software, so it's subdirectories are a good place to download the python source and install. See section 4.9 of the Linux Foundation's File Hierarchy Standard.

Install any build dependencies. On Debian-based systems, use:

apt update
apt install build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libsqlite3-dev libreadline-dev libffi-dev libbz2-dev

Choose which python version you want to install. See the Python Source Releases page for a listing.

Download and unzip file in /usr/local/src, replacing X.X.X below with the python version (i.e. 3.8.2).

cd /usr/local/src
wget https://www.python.org/ftp/python/X.X.X/Python-X.X.X.tgz
tar vzxf Python-X.X.X.tgz

Before building and installing, set the CFLAGS environment variable with C compiler flags necessary (see GNU's make documentation). This is usually not necessary for general use, but if, for example, you were going to create a uWSGI plugin with this python version, you might want to set the flags, -fPIC, with the following:

export CFLAGS='-fPIC'

Change the working directory to the unzipped python source directory, and configure the build. You'll probably want to use the --enable-optimizations option on the ./configure command for profile guided optimization. Use --prefix=/usr/local to install to the proper subdirectories (/usr/local/bin, /usr/local/lib, etc.).

cd Python-X.X.X
./configure --enable-optimizations --prefix=/usr/local

Build the project with make and install with make altinstall to avoid overriding any files when installing multiple versions. See the warning on this page of the python build documentation.

make -j 4
make altinstall

Then you should be able to run your new python and pip versions with pythonX.X and pipX.X (i.e python3.8 and pip3.8). Note that if the minor version of your new installation is the same as the OS's version (for example if you were installing python3.8.4 and the OS used python3.8.2), then you would need to specify the entire path (/usr/local/bin/pythonX.X) or set an alias to use this version.

[Reactie gewijzigd door rob12424 op 15 augustus 2021 19:47]

Goed, als je dus software handmatig moet builden vernietig je het nut van je pakketbeheer totaal, en is er een zeer reële kans dat je je distro om zeep helpt, en zou ik dus absoluut niet zo doen of aanraden. Dan nog liever 3rd party repo's..

Beste @rob12424 ik begrijp dat iemand je toevoeging nuttig vind, maar dit is echt niet handig. Ik heb ook het copy-paste gelezen hieronder maar de vraag is uit 2010 en het (m.i. zwakke) antwoord heeft op stack overflow dan ook maar 2 votes up.

Iemand aanraden om zelf maar een applicatie tot een package te compilen kan heel soms de beste oplossing zijn, maar meestal zijn er betere oplossingen.

Zelf compilen betekent namelijk ook dat je zelf de updates moet bijhouden.

Ik heb maar 1 third party repo ingesteld op mijn servers, en dat is mijn eigen repo. Met reprepro onderhoud ik een repository met de packages die ik uit verschillende third party party repo's binnen haal, soms uit testing, soms zelfs zelf gebouwd. Zo zie ik alle updates langskomen, eventuele nieuwe dependencies moet ik handmatig toevoegen. Zo weet ik precies wat er op mijn servers geïnstalleerd is.

Als je meer dan een handvol servers hebt is het heel handig.

Voor geïnteresseerden kan ik eventueel mijn configuratie wel delen, via een persoonlijk bericht.

[Reactie gewijzigd door casberrypi op 15 augustus 2021 22:45]

Een goed gemaakt package heeft altijd een source die ook mee gaat. Dat bestaat uit een upstream tarbal waarvan de hash te verifiëren is, en een diff. Die diff bevat alle packaging en eventuele patches.

Als dat niet gedistribueerd is dan hebben we al snel een probleem inderdaad. PPA's zijn dus vaak wél ok, en ik gebruik dus soms ook PPA source packages die ik rebuild voor Debian. Dat gaat best vaak goed.

Tuurlijk, het grootste deel gaat erom hoe je er zelf mee om gaat. PPA's en andere third party repo's zijn voornamelijk gevaarlijk voor mensen die niet precies weten wat ze doen

En daarom Ubuntu en linuxmint,etc

Voor developers of fanatiekelingen is achterlopen mss onwenselijk, maar dat is lang niet iedereen.
De software is ca 1-2 jaar oud gemiddeld (over de levensduur tot de volgende stable).
Nou, zoveel revolutionairs gebeurt er echt niet in die tijd hoor; na elke 2-jaarlijkse upgrade blijkt het OS nog voor 95% hetzelfde te functioneren voor mn dagelijkse bezigheden.

Soms zou ik wel n nieuwe shiny feature willen hebben, maar dat ik daar per definitie al mn hele leven zonder mee heb gedaan, maakt dat ik daar dan best nog n jaartje op kan wachten.
Maar idd, als je Debian volzet met backports enzo, dan kan je beter n ander OS zoeken.
Nieuwe software en stabiliteit (NB in de Debian zin van t woord!) sluiten elkaar nou eenmaal uit.

En dat is precies waarom Debian een goede distro voor servertaken en doorgaans een minder goede keuze voor je desktop ervaring is.

Heb je gehoord van Ubuntu? Die is op Debian gebaseerd

Dat is wel een heel zwart op wit manier om ernaar te kijken. Ubuntu deelt dezelfde package manager en zal hier en daar nog wat vergelijkenissen hebben met Debian, maar is inmiddels verder een compleet eigen distributie. Een derivative betekent niet per definitie dat het erop gebouwd wordt, maar kan ook betekenen dat het enkel bepaalde onderdelen van gebruikt. Jouw statement klopt alleen voor early builds van Ubuntu, maar klopt al zeker niet meer sinds Ubuntu 8.04.

Het betekent ook dat Debian best wat moderner kan zijn en kan komen met een wat luxere desktop-ervaring, Ubuntu bewijst immers dat dat kan.

Niet vervelend bedoeld, maar heb je mijn initiele reactie wel volledig gelezen? Ik zeg ook niet dat het niet kan, maar dat je het doel van de distributie dan een beetje voorbij schiet. Waarom zou je moeite doen om een distributie als Debian klaar te maken voor je desktop ervaring terwijl distributies als Ubuntu, Mint, Pop of rpm-based distributies als Fedora dat al reeds voor je gedaan hebben? Ik zie de meerwaarde dan niet om Debian te gebruiken.

Kijk, uiteindelijk, linux is linux en je kunt elke distributie wel naar je smaak inrichten, hoe je 'm ook wil gebruiken. Voor mij is een distributie een keuze per type apparaat. Voor een laptop gebruik ik bijvoorbeeld Ubuntu omdat er OOTB al alle tooling bij zit die mij daarin een optimale ervaring biedt. Voor een mediacenter gebruik ik ook ubuntu omdat het me gemak biedt en meer garantie dat spul blijft werken na een update. Voor mijn PC gebruik ik dan weer Archlinux, omdat ik minder componenten heb om rekening mee te houden. Wat ik al zei, zoveel mensen, zoveel wensen en dit is puur mijn kijk erop. Het is prima dat een ander een andere mening heeft

Debian voor de desktop gaat ook prima. Wil je bij de tijd blijven, dan gebruik je de backports. Blijf je op de stabiele ondergrond en heb je toch nieuwe programma's als VLC, Libreoffice en wat je meer wil hebben. Dus ook een nieuwere kernel als je dat per se wil gebruiken. Zo werk ik zelf al jaren.

Dat is wat ik al 2 keer heb herhaald. Het kan prima, maar waarom de moeite doen als het onnodig is?

Ah ik dacht nog exFAT is toch propriatair maar ik lees dat het sinds 2019 vrijgegeven is

https://en.wikipedia.org/wiki/ExFAT#Adoption

Klopt. Er zijn best veel Linux distros die het al vrij lang ondersteunen. Voornamelijk de bekende desktop distro's.

Debian ook na installatie van een paar pakketten. https://linuxize.com/post...an-exfat-drive-on-debian/
Het verschil is dat het nu in de kernel gebouwd zit in plaats van met Fuse. het zal wellicht een prestatievoordeel geven.

[Reactie gewijzigd door Soldaatje op 15 augustus 2021 20:45]

exFAT File-System Performance On Linux 5.9

Bedankt voor de benchmark link.
exFAT in de kernel is dus inderdaad een stuk sneller dan bij gebruik van Fuse.

En binnenkort ook Slackware 15.0 als we de ChangeLog bekijken http://ftp.osuosl.org/pub...e64-current/ChangeLog.txt
En het gaat letterlijk een dikke release worden (15 GB full install !).
Bijna 2 keer zo groot als de vorige.

Nu nog systemd vrij maar dat is voornamelijk uit pragmatisme en wanneer eudev ermee zou stoppen of wanneer het simpelweg te moeilijk wordt om werkend te krijgen, zal ook Slackware meegaan.

Leuk voor desktop gebruik misschien, maar ik blijf lekker op Debian 10 voor m'n x64 router en VPS.

Wat draai je als router software?

😩Huh nu pas EXFAT ondersteuning in Debian?

Ik gebruik al jaren USB sticks om bestanden over te zetten van Windows naar mijn Linux Mint computer. Er is zelfs software waarmee NTFS partities gelezen kunnen worden.

Waarom is het zo bijzonder dat dit nu ook met Debian 11 kan?🤔.

[Reactie gewijzigd door LEX63 op 16 augustus 2021 10:33]

Voor zover ik begrijp gaat het erom dat de exFAT filesystem nu in de kernel zit en niet meer via (trage) userspace fuse hoeft te draaien

"bullseye" becomes our first release to provide a Linux kernel with support for the exFAT filesystem and defaults to using it for mount exFAT filesystems. Consequently it is no longer required to use the filesystem-in-userspace implementation provided via the exfat-fuse package.