Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Debian GNU/Linux 10.1

Debian logo (80 pix) 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 deze update kunnen hieronder worden gevonden.

Debian 10.1 buster released

The Debian project is pleased to announce the first 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.

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

Door Bart van Klaveren

Downloads en Best Buy Guide

08-09-2019 • 16:44

29 Linkedin Google+

Submitter: 8088

Bron: Debian

Reacties (29)

Wijzig sortering
Sinds Debian 6 heeft elke major release na 3 jaar reguliere updates 2 jaar extra Long Term Support ( https://wiki.debian.org/LTS , https://wiki.debian.org/DebianReleases#Production_Releases ).

Er is dus niets wat Buster / Debian 10 onderscheidt als een LTS release, in tegenstelling to wat de samenvatting hier suggereert.
Mijn systeem boot niet meer met 4.19.0-6-amd64, maar nog wel met 4.19.0-5-amd64. Even opletten dus.
Ik draai nu nog debian 9, krijgt die nog updates of moet ik echt upgraden naar debian 10?
Als je in /etc/apt/sources.list stretch vervangt door stable ga je altijd over zodra een release stable wordt. Mocht je dat niet willen kan je het ook vervangen door buster. (Of: vervangen door oldstable of testing of unstable). Ik zit vanaf Jessie al in de stable, nooit geen centje pijn bij overgangen van stable releases.

Hier meer info: https://wiki.debian.org/SourcesList
Is het aan te raden om elke stable release mee te pakken in plaats van een upgrade door middel van een herinstallatie te doen? Weet namelijk dat het vanuit de Debian maintainers wordt aangeraden om een clean install te doen, en meerdere keren heb ik bepaalde packages tijdelijk om zeep geholpen tijdens een upgrade omdat de configbestanden van de packages opeens een totaal andere layout of mappenstructuur kregen. Is wel te fixen met wat moeite, maar is het de hoofdpijn waard?

EDIT:
Heb het al enigszins een antwoord gevonden in de link die je zelf gaf:
Avoid using stable in your sources.list as that results in nasty surprises and broken systems when the next release is made; upgrading to a new release should be a deliberate, careful action and editing a file once every two years is not a burden.

[Reactie gewijzigd door stuiterveer op 10 september 2019 11:22]

Ik heb hier nog nooit problemen mee gehad. Mocht de vraag tijdens een update komen dat systemfiles vernieuwd zijn (betreft meestal files in /etc) dan kies ik ervoor om de file te overschrijven met de nieuwe versie van de package maintainer. Volgens mij gebeurt dit bijna alleen maar als je er zelf in hebt zitten editten, en dan weet je hopelijk ook wat je opnieuw moet veranderen. Heb je er nooit aangezeten dan zou ik sowieso de file laten overschrijven met de nieuwe.

Ik ben hiermee op een ander systeem ook wel eens van stable naar testing gegaan zonder gedoe.
Dat kan worden gezien op deze pagina: https://wiki.debian.org/LTS
Dus er is nog volledige support tot 2020, en extra LTS support tot 2022 zo'n beetje.

Ik zou zo'n 3 jaar op een stable release van Debian blijven. Wanneer er langer nodig is, dan is CentOS weer iets interessanter met de 10 jaar gratis. Debian upgraden tussen releases is dan weer niet heel vervelend. Al helemaal niet als er veel met containers wordt gewerkt.

[Reactie gewijzigd door xfj op 8 september 2019 20:16]

Ja ik draai voornamelijk zaken in Docker op een paar packages na.

Ik denk dat ik eerst een diskimage maak voor upgrade. Dan heb ik altijd een snelle herstel beschikbaar
Prima idee! Als het lokaal of hybride is, kan men ook de root op btrfs (wellicht mirror 120G SSD afhankelijk van budget? Of 1 SSD met dubbele data en metadata optie) zetten voor periodieke snapshots, voor een snellere upgrade path.
Ik vraag me af of de Debian ontwikkelaars zich ervan bewust zijn dat de installer niet meer werkt op andere architecturen dan x86. De manier waarop ik eromheen heb gewerkt is door vanaf 9.x te upgraden naar 10.0, maar dat zou niet de enige mogelijkheid moeten zijn om een up-to-date systeem te installeren.
Ik vraag me af of de Debian ontwikkelaars zich ervan bewust zijn dat de installer niet meer werkt op andere architecturen dan x86.
Waarom vraag je je dat af maar submit je niet gewoon een bug report?
De bug is gerapporteerd voor ppc64le,
Dan zijn ze toch op de hoogte en hoef je je dat niet af te vragen?

[Reactie gewijzigd door Olaf van der Spek op 8 september 2019 17:53]

Omdat dit geen incident is, maar een structureel probleem met Debian. Ik ga er niet achteraan zitten, terwijl ik zelf geen invloed kan uitoefenen op het project. Bovendien hebben andere mensen met wie ik heb gesproken, zelf de bug al gemeld bij Debian. Waarom zou ik het dan opnieuw doen en duplicates aanmaken in hun database?
Dan zullen ze zich er wel bewust van zijn ?
En als je meer informatie kunt bieden die kan helpen kun je dat als nog aan bestaande bug reports toevoegen. Kan zeker van belang zijn als het in sommige gevallen wel werkt en in sommige niet.

Maar goed je schijnt iets te doen met technische informatica, ik gok dat je dan in de toekomst nog wel eens blij kan gaan worden van goede bug reports, dus ze zelf maken lijkt me dan een aardige wederdienst.
Dat is inderdaad wel zo, maar ik werk het liefst direct met upstream projecten in plaats van distributies. Ik zal nog eens informeren of die bugreports daadwerkelijk zijn doorgekomen, maar ik hoorde ook al dat er vanuit de Debian ontwikkelaars niet veel animo was om ernaar te kijken en er zelfs werd gezegd dat er geen bug was. Daar schiet ook niemand iets mee op.

Maar goed, nu weten meer mensen hier ervan en als ze echt geïnteresseerd zijn in Debian, kunnen ze er zelf ook achteraan gaan. Het zal vast niet zo zijn dat ik toevallig de enige ben die hier last van heeft, hoewel ik alleen bevestiging heb gekregen van leden uit de Talos community, die het dan ook kunnen testen op echte hardware, terwijl ik het moet doen met een onvolmaakte emulator. Daarom heb ik het aan hen overgelaten.
Kortom je bent niet echt geïnteresseerd in Debian ?
Hoe weet je dan dat het een structureel probleem is en bijvb niet specifiek voor jouw platform en instellingen ?

Op zich niet onverstandig om bij bugs te kijken of het upstream al gefixt is of daar gefixt kan worden zodat het vervolgens in distributies eventueel gebackport kan worden. Maar goed voor installers is de distributie doorgaans zelf "upstream".

En hoe je het ook wendt of keert, het blijft "scratch your own itch" bij FOSS.
Je kunt hooguit proberen anderen het werk voor je te laten doen door vriendelijke te zijn en ze zo veel mogelijk te helpen. Als je daar niet toe bereid bent bij Debian dan zul je of een andere distrubutie moeten gaan gebruiken of je eigen distro gaan bakken uit alle upstream projecten. Maar dan denk ik dat een bugreportje bakken (en opvolgen / testen) een veel geringere inspanning is met meer resultaat.
Ik ben inderdaad niet voornamelijk geïnteresseerd in Debian en heb het vele jaren lang vermeden, maar ik sta er ook niet vijandig tegenover. Iets meer dan 2 jaar geleden bleek het de enige distributie te zijn die ik überhaupt op mijn laptop geïnstalleerd kreeg en daarnaast heb ik nu ook Ubuntu en OpenSUSE draaien.

Ik weet dat het een structureel probleem is in ieder geval op PPC64LE, omdat ik daarover heb gesproken met de CTO van Raptor Computing Systems. Ze gebruiken nu zelf debootstrap, omdat de installer teveel problemen heeft gehad door de jaren heen. Op ARM64, s390x en andere officieel ondersteunde architecturen moet dat nog maar blijken, maar voorlopig heb ik niet de tijd om dat uit te proberen.

Ik heb het juist voor iemand uit de Talos gemeenschap getest, omdat die helemaal geen technische achtergrond heeft en zodoende ben ik erachter gekomen. Bovendien is een andere persoon uit dezelfde gemeenschap die momenteel veel meer tijd heeft dan ik, ermee bezig om het probleem te verhelpen en wellicht ook een Debian developer te worden. Hij weet ook van mijn tests op ARM en s390x en gaat daar ook achteraan, dus het is niet zo zwart wit als het hier door sommigen gesteld wordt.

Mijn interesse gaat veel meer uit naar andere projecten zoals Redox, Helenos, Openindiana en Unleashed en daarnaast sta ik in contact met de ontwikkelaars van Adélie en Void Linux. Juist omdat ze dit soort (mag ik toch wel zeggen) triviale zaken wel serieus nemen. Dat neemt niet weg dat Debian toch wel een van de pijlers van in ieder geval de GNU gemeenschap is door de jaren heen.
Als je een soort van +1 doet op die bestaande bugmeldingen, dan weten ze toch dat er meer mensen zijn die er last van hebben?

Je zegt nu een beetje het volgende: mijn buurman en ik hebben dezelfde auto, maar de buurman is er al voor naar de garage geweest om het te melden. De auto (van de buurman) wordt gerepareerd, die van jou niet, want jij bent niet naar de garage geweest, zal jouw auto dan ook magisch gerepareerd worden denk je?

[Reactie gewijzigd door CH4OS op 8 september 2019 22:32]

Jouw houding is ergerlijk, maar niet onoverkomelijk. Luister goed.

Als jij (of iemand anders) een bug tegenkomt in FOSS, en je meldt deze niet, dan heb jij niet je steentje bijgedragen om het probleem op te lossen. Als je deze wel meldt, dan zoek je eerst of de bug al gemeld is. Het is even leren hoe dat moet (want niet iedere bugtracker werkt hetzelfde) maar het is geen hogere wiskunde.

Op het moment dat er niets gedaan wordt met zo'n bugreport dan is dat vervelend. Dan nog is men jou niets verschuldigd (het zijn immers onbetaalde vrijwilligers die hier aan werken, en jij betaald niets). Maar dan heb je wel je steentje bijgedragen.

Op het moment dat jij -zoals hier blijkt- niet wenst mee te werken aan dit proces, maar wel op een website als deze er over loopt te zagen, dan ben je wat mij betreft een parasiet. Als jij die tijd nou 'ns in je bug report had gestopt...

[Reactie gewijzigd door Jerie op 8 september 2019 19:25]

Luister hier eens heel goed. Ik heb meer dan genoeg aan verscheidene FOSS projecten bijgedragen. Wat ik in beginsel heb gedaan is alleen even een test gedraaid van een paar minuten in een emulator. Ik heb ook vaak genoeg bug reports voor individuele problemen aangemaakt. Maar als een project zijn quality assurance zo verwaarloost en doet alsof er niets aan de hand is, dan voel ik ook zelf niet de behoefte om er achteraan te gaan zitten.

Dus om mij hier de les te gaan lopen lezen, slaat helemaal nergens op. Het Debian project zit ook niet te wachten op nieuwe ontwikkelaars, het is echt meer een club van 'ons kent ons'. Ik ga het met de nieuwe 10.1 releases volgende weekend nog een keer proberen en zal dan wel eenmalig een bugreport aanmaken. Maar ik ga er verder niets mee doen, want dit is wat standaard bij de quality assurance van een besturingssysteem hoort dat op vele architecturen draait.

Men is mij ook helemaal niets verschuldigd en daar heb ik ook nooit iets over gezegd. Maar op het moment dat gebruikers het niet eens kunnen installeren, dan is er wel iets vreemds aan de hand. En dat hoeven ze niet voor mij te doen, maar wel voor die gebruikers die niet weten hoe ze het dan toch op hun machine kunnen krijgen. Als het jou zo boeit, dan zul je waarschijnlijk een of meerdere uitgebreide bugreports aangemaakt hebben, voordat ik daar aan toegekomen ben.
Dus om mij hier de les te gaan lopen lezen, slaat helemaal nergens op. Het Debian project zit ook niet te wachten op nieuwe ontwikkelaars, het is echt meer een club van 'ons kent ons'.
Dat is niet mijn ervaring. Mijn ervaring is een fantastische gemeenschap waar iedereen welkom is. Maar als het jou niet zint, waarom draai je dan niet iets anders?

Je originele post:
Ik vraag me af of de Debian ontwikkelaars zich ervan bewust zijn dat de installer niet meer werkt op andere architecturen dan x86. De manier waarop ik eromheen heb gewerkt is door vanaf 9.x te upgraden naar 10.0, maar dat zou niet de enige mogelijkheid moeten zijn om een up-to-date systeem te installeren.
Je doelt waarschijnlijk op x86-64/AMD64, en niet op x86-32.

Afgezien van dat schrijf jij: "Ik vraag me af of de Debian ontwikkelaars zich ervan bewust zijn dat [...]"

Weet jij wat dat impliceert? Dat er niet is gereageerd op de bugreport(s) die jij of iemand anders heeft/hebben gemaakt of dat jij geen bugreport hebt aangemaakt.
Ik ga het met de nieuwe 10.1 releases volgende weekend nog een keer proberen en zal dan wel eenmalig een bugreport aanmaken.
Alvast bedankt.
Maar ik ga er verder niets mee doen, want dit is wat standaard bij de quality assurance van een besturingssysteem hoort dat op vele architecturen draait.
Het proberen installeren van iedere versie op iedere architectuur kost hedendaags (tov CI/CD oplossingen) enorm veel tijd en moeite. Van een gemeenschap die geheel uit vrijwilligers bestaat kun je dat niet verwachten; jij verwacht dat wel.
Het proberen installeren van iedere versie op iedere architectuur
Iedere versie hoeft niet, maar major versies zouden (geautomatiseerd) door iets als QEMU gehaald kunnen worden. Daar moet iemand dan wel een omgeving voor opzetten, maar het zou prima iets kunnen zijn dat een groepje vrijwilligers zou kunnen doen. Daar komt natuurlijk ook onderhoud bij, en dat is vaak het pijnpunt. De tijd van vrijwilligers is inderdaad beperkt.

Het aantal ondersteunde architecturen is bij Debian nog best wel groot (ondanks dat het verminderd is in de afgelopen zoveel versies). Gecombineerd met de toegenomen complexiteit krijg je dit soort problemen.

Mogelijk moet Debian ook naar het model van bijvoorbeeld Arch Linux kijken: maar een enkele architectuur officieel ondersteunen (Zie Arch Linux, enkel AMD64) en voor de rest overgaan op onofficiële forks (zie Arch Linux 32, Arch Linux ARM...).

[Reactie gewijzigd door The Zep Man op 9 september 2019 07:51]

Zeg nou zelf, op de index pagina van https://www.debian.org/ zie je toch niets van waar je direct een bug kan melden?

Helemaal onderaan in kleine lettertjes:
Stuur, om een probleem met de website te rapporteren, een e-mail (in het Engels) naar de openbare en gearchiveerde mailinglijst debian-www@lists.debian.org of (in het Nederlands) naar debian-l10n-dutch@lists.debian.org. Problemen met de Nederlandse vertaling kunnen eveneens naar het tweede adres worden gestuurd. Zie de contactpagina voor andere contactinformatie. De broncode van de website is beschikbaar.
Heb je dus ook geen klap aan.

En https://www.debian.org/contact moet je flink wat doorlezen om te weten te komen waar je over je probleem moet miepen.

Als ze nou eens met een soort decision tree werken, dan sturen ze iig de mensen naar de juiste communicatieplekken.
Het staat gewoon in het grote menu op de front page:

Ondersteuning -> Bugrapporten -> Hoe u in Debian een bug kunt melden
Een probleem in Debian rapporteren met reportbug

We raden sterk aan om problemen (bugs) in Debian te rapporteren met behulp van het programma reportbug.

etc etc etc

[Reactie gewijzigd door CAPSLOCK2000 op 8 september 2019 18:21]

Zeg nou zelf, op de index pagina van https://www.debian.org/ zie je toch niets van waar je direct een bug kan melden?

Helemaal onderaan in kleine lettertjes:
[...]

Heb je dus ook geen klap aan.

En https://www.debian.org/contact moet je flink wat doorlezen om te weten te komen waar je over je probleem moet miepen.

Als ze nou eens met een soort decision tree werken, dan sturen ze iig de mensen naar de juiste communicatieplekken.
En daar moet het dus NIET heen, dat is voor zoals er staat, alleen voor bugs in de website.
Bovenin kun je onder het kopje "support" de link voor "bug reports" vinden.
Ernstig. Is het mogelijk IRC te gebruiken en te kijken bij het betreffende architectuur kanaal of het bekend is? https://wiki.debian.org/IRC#Debian_IRC_channels
De bug is gerapporteerd voor ppc64le, maar het zou onderdeel moeten zijn van de QA procedure om het minstens (automatisch) op een aantal QEMU machines te testen. Iemand die ik ken vanuit het Talos II project, gaat samenwerken met de Debian ontwikkelaars om het probleem te verhelpen.
Welke precies? Dit klinkt alsof je meerdere platformen/architecturen geprobeerd hebt.
Ik heb aarch64, ppc64le en s390x geprobeerd en ook met enkele Talos II eigenaars geverifieerd. Fedora heeft ook soortgelijke problemen met zijn installer. De installers van Ubuntu en OpenSUSE (behalve s390x voor deze laatste, omdat die niet bestaat) werken wel op al deze architecturen.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Formule 1

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True