Linux 4.14 komt uit als volgende lts-kernel

Linus Torvalds heeft de release van Linux 4.14 bekendgemaakt. Deze kernel vormt de basis van de volgende lts-versie. De nieuwe versie bevat onder meer heterogeneous memory management en verbeteringen voor gpu-drivers.

Jérôme Glisse, de ontwikkelaar die voor heterogeneous memory management, oftewel HMM, verantwoordelijk is, legt uit dat hiermee de gpu toegang krijgt tot de address space van processen. Andere wijzigingen in de nieuwe versie zijn onder meer grotere geheugenlimieten, waardoor het maximale virtuele geheugen naar 128PiB gaat op x86-64-systemen.

Verder krijgt de Raspberry Pi bijvoorbeeld hdmi cec-ondersteuning, waarmee aansturing via hdmi mogelijk is. Op AMD-gebied is er ondersteuning voor secure memory encryption voor Epyc-cpu's naast enkele verbeteringen in de amdgpu-driver. Amdgpu DC zit volgens Phoronix in versie 4.15 van de kernel. Ten slotte is er nog zstd-ondersteuning in btrfs en squashfs bijgekomen.

Torvalds schrijft bij de release dat er geen grote verrassingen inzitten, maar dat de geautomatiseerde tool voor het vinden van zerodays steeds beter wordt. Hij wijst nog op een aanpassing op het laatste moment waarmee code werd geschrapt die de MHz-waarde in /proc/cpuinfo moest weergeven. De code werkte wel, maar zorgde voor problemen op systemen met honderden cpu-kernen.

Reacties (59)

[Zezura]

Interessant hoe Linux zich ontwikkeld op GPU gebied. Met OpenGL zullen ze waarschijnlijk nooit de volle efficiëntie kunnen bereiken als Windows Met DirectX12. Maar dit zijn welkome verbeteringen. Een interessante benchmark zou zijn, Vulkan game geschreven met exact dezelfde graphics code, en zowel testbaar op Windows en Linux.
Daar wil ik wel het resultaat van weten.

[cdwave]

DirectX is een veel prettigere interface om tegen te programmeren dan OpenGL. Dat is het voornaamste voordeel.

Qua performance zou Linux vs Windows niet uit moeten maken, dat zou vrijwel geheel door de hardware begrensd moeten zijn.

Ik heb drivers voor zowel Windows als Linux geschreven, en de drivers in Linux integreren veel dieper in het systeem omdat ze niet tegen een bepaalde kernel "API" hoeven te bouwen. Onder Windows moeten alle drivers met een behoorlijke range van kernels kunnen werken, waardoor er een extra laag tussen de windows kernel en de drivers zit. Dat merk je goed aan de interrupt latency: Waar ik in Linux na een "buffer halfvol" interrupt doorgaans een buffer aantrof die net iets meer dan halfvol was, kwam ik bij Windows steevast bij een volle buffer aan (met stagnerende communicatie dus) en moest ik de hardware buffers aanzienlijk vergroten om te compenseren voor de extra latency in Windows.
Dat in aanmerking nemende zou ik zelfs stellen dat de GPU onder Linux beter zou moeten kunnen presteren dan onder Windows.

[atlaste]

... kwam ik bij Windows steevast bij een volle buffer aan (met stagnerende communicatie dus) en moest ik de hardware buffers aanzienlijk vergroten om te compenseren voor de extra latency in Windows.

Bijzonder... en best interessant eigenlijk... Ik heb zelf nog nooit van zoiets last gehad. Kan je meer details geven?

Dat in aanmerking nemende zou ik zelfs stellen dat de GPU onder Linux beter zou moeten kunnen presteren dan onder Windows.

Ligt er natuurlijk wel aan waar de bottleneck zit. Een groot deel van de API calls voor DirectX zijn behoorlijk uitgeoptimaliseerd, incl. samen met de hardware vendors zelf, die hardware en software ook nog eens hebben aangepast zodat het naadloos aansluit in de wijsheid dat vrijwel alle spellen DirectX gebruiken. Het is bijzonder lastig om daar tegenaan te concurreren qua performance. Ik vermoed daarom eigenlijk dat Windows beter zal presteren in de praktijktests...

Maar goed, het is op zich best een interessant experiment.

[rlKoekie]

Je kan die latencies goed terug zien als je kijkt naar GP-GPU performances (CUDA bijvoorbeeld). In Windows is het starten van een CUDA-kernel een flink duurdere operatie (levert veel latency) dan op Linux.
NVidia heeft hiervoor op windows ook voor de echte GP-GPUs (de Tesla series) een speciale compute-modus, waarbij de GPU zichzelf niet als een display adapter presenteert aan Windows, maar als compute device.

[cdwave]

[...]
Bijzonder... en best interessant eigenlijk... Ik heb zelf nog nooit van zoiets last gehad. Kan je meer details geven?

Nou ja, wat wil je weten? 't Was een FPGA die via PCIe data aan de PC leverde. De FPGA schreef met DMA in het memory en trok aan de interrupt halverwege en aan het eind. De PC kopieert de data na een interrupt naar de gebruiker buffer toe en meldt aan de FPGA dat dat deel van de buffer weer vrij is. Onder Linux was de buffer 128k, toen ik de Windows driver schreef heb ik daar maar 512k van gemaakt omdat de buffer vaak al helemaal vol was voordat de driver de IRQ kon afhandelen. Beide drivers zijn op dezelfde machine ontwikkeld (dual boot).

[Reactie gewijzigd door cdwave op 22 juli 2024 16:40]

[atlaste]

Dat wilde ik ongeveer weten Thanks.

Was het wel een vrij recente versie van Windows? Als ik me niet vergis waren er flink wat wijzigingen gedaan in de kernel in W10 die hier effect op kunnen hebben. (Kan het artikel van het kernel team zo snel niet meer terugvinden...)

[cdwave]

Driver getest op Windows 7, 8.1 en 10.

[cdwave]

Ligt er natuurlijk wel aan waar de bottleneck zit. Een groot deel van de API calls voor DirectX zijn behoorlijk uitgeoptimaliseerd, incl. samen met de hardware vendors zelf, die hardware en software ook nog eens hebben aangepast zodat het naadloos aansluit in de wijsheid dat vrijwel alle spellen DirectX gebruiken. Het is bijzonder lastig om daar tegenaan te concurreren qua performance. Ik vermoed daarom eigenlijk dat Windows beter zal presteren in de praktijktests...

Ik vermoed dat zolang Linux nog geen goed antwoord op DirectX heeft, Windows nog wel een voordeeltje heeft qua performance. IRQ latencies spelen niet of nauweljiks een rol bij videokaarten, die hebben hun queues al flink diep gemaakt om dat op te lossen. IRQ latency op PCIe is (ook op Linux) gruwelijk hoog als je dat vergelijkt met bijvoorbeeld embedded platformen.

Ik heb wel iets over Vulcan gehoord en nog wat van die dingen, maar 't is al meer dan tien jaar geleden dat ik me nog serieus met 3D spul bezig heb gehouden.

[Zezura]

Zeer interessant, dit veranderd mijn blik op de prestatie tussen de twee OS’en.
Ik ben zelf fan van beide OS’en maar verwachte altijd dat graphics beter presenteren op Windows (en onder D3D) dan Linux met Vulkan of OpenGL.

[Particlebox]

DirectX is een veel prettigere interface om tegen te programmeren dan OpenGL. Dat is het voornaamste voordeel.

Hé wat? Na meerdere applicaties in OpenGL en DirectX geschreven te hebben is OpenGL toch een stuk gemakkelijker (wel zorgen dat je alleen Core gebruikt en dus de legacy meuk weg laat)

Toegegeven, de structuur van OpenGL kan beter. Maar je eerste triangle op het scherm krijgen t/m het complete verhaal is vele malen gemakkelijker dan in DirectX imho.

[tzunix]

Zeker een interessant artikel over DirectX vs OpenGL (beide 'middleware') is te vinden op https://softwareengineeri...developers-prefer-windows, in het geaccepteerde antwoord. In short, competitie tussen twee technieken die hetzelfde doen: hardware abstract maken voor developers. De ene wat efficienter dan de ander, maar daarin zeker beinvloed door marktwerking, bedrijfsstrategie, en andere spelers. Een boeiend stukje historie in ieder geval. En dit geeft ook aan dat OpenGL vergelijken met DirectX behoorlijk appels met peren is.

Verder: Vulkan - De volgende evolutie stap in graphics interface API's. Dezelfde graphics code onder twee OS'en, das dus alleen een vergelijking tussen de efficiente afhandeling van het grafische code deel van een game. Echt boeiend? Voor mij niet hoor.

[rbr320]

Dezelfde graphics code onder twee OS'en

Het zijn er meer, onder andere de Nintendo Switch gebruikt namelijk ook Vulkan. Ik neem aan dat je Android volledig als Linux rekent, maar dat zal niet iedereen met je eens zijn. Bovendien is de specificatie van Vulkan volledig open en staat Apple dus niets in de weg om hun eigen implementatie te maken voor MacOS en iOS. Er is via Molten een implementatie van Vulkan op MacOS via hun Metal API, dus potentieel is Vulkan op veel meer platformen beschikbaar.

[tzunix]

Je hebt helemaal gelijk, maar mijn reactie was een reactie op Zezura, die blijkbaar een Windows-Linux met Vulkan shootout erg boeiend vind. Ik vind zelf Vulkan (als next-gen graphics API) erg interessant, en het is natuurlijk boeiend hoe verschillende implementaties zich ten opzichte van elkaar gaan verhouden. Altijd tof, een potje haasje-over .

[Zezura]

Voor mij is het grafische gedeelte wel interessant want ik ben een graphics game programmers.

[Becquerel]

Ooit kleine opsomming gezien met games die beter draaien op Linux dan op Windows.
Beetje outdated nu, maar misschien zijn de makers van de youtube links in deze post wel bezig moderne games te testen.

https://voat.co/v/Linux/1261134

[Zezura]

Thats amazing, Ubuntu heeft inderdaad betere framerates dan Windows.
Ok ik ben best wel overtuigd van de game mogelijkheden binnen Linux. En zal binnen mijn mogelijkheden het ook zeker ondersteunen als Game platform. geweldig. Vulkan staat hierbij ook op mijn agenda.

[Becquerel]

Er zijn zelfs games die smoother en stabieler werken op Linux die windows only zijn. Maar ik zie dat je junior gamedeveloper bent, freelance of werk je vast?

[Zezura]

Student momenteel.

[Becquerel]

Tentamens goed gedaan van de week?

[Zezura]

Mijn school heeft geen tentamens.
Je krijgt per periode wel één cijfer, en natuurlijk de benodigde studiepunten, die je moet verzamelen om bachelor diploma te behalen.

Mijn project ging goed, en met een mooi resultaat.

[Becquerel]

Top!

[rbr320]

In de nieuwe Doom heb je vrijwel dezelfde FPS op Windows als op Linux als je Vulkan gebruikt, waarbij Linux dan nog extra overhead heeft omdat je Wine moet gebruiken voor alle niet grafische zaken.

Croteam is momenteel bezig om hun games (Serious Sam 3, The Talos Principle) van een Vulkan renderer te voorzien en ook bij die games is de FPS onder Windows en Linux ongeveer gelijk. Helaas nog wel lager dan bijvoobeeld onder DirectX 11, maar dat komt omdat Vulkan nog jonge technologie is die nog verder doorontwikkeld en geoptimaliseerd moet worden.

Ik weet niet hoe ver de mensen achter Ashes of the Singularity zijn met hun Vulkan renderer, ik heb er in ieder geval nog geen benchmarks van gezien, maar dat is er ook 1 om in de gaten te houden als het draait onder Wine of als ze met een native Linux versie komen.

De bottom line is dat Vulkan erg goede prestaties neer zet, onafhankelijk van het platform en over het algemeen beter dan [url="https://https://www.youtube.com/watch?v=ApvTaSAG--4"]DirectX 12[/url].

[Zezura]

Beter dan DirectX12, echt waar ?
Dat had ik niet verwacht, ook omdat DirectX12 makkelijker te Implementeren is dan Vulkan.

[rbr320]

Beter dan DirectX12, echt waar ?
Dat had ik niet verwacht, ook omdat DirectX12 makkelijker te Implementeren is dan Vulkan.

Ik zou graag je bron weten, want voor zover ik weet klopt dat niet. DX12 en Vulkan zijn beide behoorlijk low-level grafische API's die een vergelijkbare moeilijkheidgraad hebben qua implementatie (lees: moeilijk). Ik heb zelfs een keer op de Steam fora een developer zien posten dat ze zo erg op elkaar lijken dat als je de ene gebruikt, je met weinig moeite ook de andere kan implementeren. Over tijd zal dat waarschijnlijk minder makkelijk worden als de organisaties achter beide API's hun eigen koers gaan varen.

[Zezura]

bron: ik, en mijn klasgenoten ik ben een student graphics game developer.

[rbr320]

Nu ben ik wel benieuwd wat er dan zoveel eenvoudiger aan is

Nog afgezien van daadwerkelijke code schrijven heeft Vulkan als voordeel dat het daadwerkelijk "write once, run anywhere" is. DirectX 12 zou dat in theorie ook moeten zijn, in de praktijk blijkt er toch weer een implementatieverschil te zijn tussen DX12 voor Windows 10 en DX12 voor Xbox One.

Daarnaast, waarom zou je jezelf limiteren tot Windows 10 en eventueel Xbox One als je een vergelijkbare API hebt waarmee je ook meteen mensen bedient die nog Windows 7/8 draaien, gamen op Linux of op de Nintendo Switch?

[Reactie gewijzigd door rbr320 op 22 juli 2024 17:07]

[Zezura]

DirectX12 is niet makkelijk, en Vulkan en DX12 liggen dicht bij elkaar in de buurt.

Het basis concept is hetzelfde, maar de randzaken erom heen maken het verschil.

Waarbij sommige dingen die je verwacht, dus echt totaal anders zijn. Documentatie en informatie van Vulkan minder goed beschikbaar is dan voor DirectX12, en met betrekking tot graphics Debugging tools heeft DirectX12 betere support. Pix is ongelofelijk tof in verhouding tot RenderDoc.

[rbr320]

Het voordeel van Vulkan met betrekking tot de tooling lijkt me dat het een open standaard is, en dus iedereen die daar belang bij heeft kan nieuwe tooling ontwikkelen. Ik verwacht dat er nog wel het een en ander in de planning staat bij de Khronos groep, of misschien komt er nog iets uit de koker van Epic of Valve. Tot nu toe is de praktijk dat deze tooling vrij beschikbaar komt, wat me voor "arme studenten" erg prettig lijkt. Vergeet niet dat de Vulkan standaard nog niet eens 2 jaar goud is, terwijl DX12 al ruim 3 jaar beschikbaar is voor ontwikkelaars.

[maxxie85]

De Raspberry Pi kan toch al heel lang overweg met HDMI-CEC?

[SampleUser]

Het kan zijn dat het in het verleden een patch/kernel mod was en nu onderdeel is van de standaard Linux. lijkt mij het meest logische

[supersnathan94]

Lijkt mij heel raar dat dit in de kernel wordt gestopt. Wat moet een server nou met HDMI cec? Dat soort dingen moeten juist als extensie worden teoegevoegd zodat de kernel lekker licht kan blijven. Beetje onzinnig om dit op deze manier toe te voegen. De grap is namelijk dat de Pi bijvoorbeeld helemaal geen officiele “uit” heeft anders dan low power suspend waar hij alleen uitkomt met powerloss of een harde uit. HDMI-CEC werkt dus altijd maar 1 kant op. Uitzetten kan ongeveer, maar aan... dat gat niet zonder eerst de stekker eruit te trekken.

[Reactie gewijzigd door supersnathan94 op 25 juli 2024 18:33]

[cdwave]

Net als alle drivers in de kernel is het gebruik ervan optioneel. Een doorsnee "server" zal zelfs geen behoefte aan HDMI of welke vorm van beeldschermuitvoer dan ook hebben, dus die kun je weglaten. Drivers die niet tijdens boot nodig zijn (zoals harddisk) kunnen als module gebouwd worden en worden dan alleen geladen als de bijbehorende hardware aanwezig is. Anders zou je PC kernel ook wel heel erg groot worden. Wie voor embedded systemen ontwikkelt bouwt de kernel doorgaans helemaal zelf met daarin precies alleen de benodigdheden.

[supersnathan94]

Tuurlijk. Alleen wie gaat er voor zijn servers nu een kernel zelf bij elkaar compileren? Precies. Dat zijn er erg weinig. Je bent dus afgeleverd aan de distri bouwer of ze er wel of niet inzitten. Een CentOS of redhat enterprise zal deze bijvoorbeeld minder snel integreren. Dat is natuurlijk prima maar om dit dan later toe te voegen aan een OS die het niet in de kernel heeft zitten is wel weer heel veel moeite terwijl het met een normale plugin veel makkelijker gaat.

Ik zie dus nog steeds niet het nut dat dit in de kernelsource zelf zit.

[Blokker_1999]

Omdat je zelf kiest of je hem in de kernel zelf integreert of als module mee compileerd die je kan laden wanneer noodzakelijk. Het is bij Linux, itt Windows, net zeer belangrijk dat je kernel modules (je drivers zeg maar) gecompileerd zijn met dezelfde tools als de kernel zelf. En dat wordt net zeer eenvoudig gemaakt door de integratie in de kernel source. Heb je een aanpassing nodig dan neem je gewoon even de source erbij, selecteer je de driver als module en compileer je snel even die module zonder dat je al de rest moet meecompileren. Eenvoudiger kan bijna niet. En heb je het toch tijdens het booten nodig kan je het direct integreren in de kernel en bij het opstarten mee in laten laden. Op deze manier blijf je beide opties gewoon behouden.

En wanneer ga je een kernel zelf compileren? Exact, wanneer het dus nodig is omdat je ofwel functionaliteit erin wenst die in de standaard kernel van je distro niet aanwezig is of wanneer je er net iets uit wenst te halen. En het compileren van een kernel onder Linux is echt geen rocket science hoor. Dat kan iedereen en ik denk dat vele gebruikers van Linux het al wel gedaan hebben.

[Zaffo]

Volgens mij valt dat laatste wel mee. In mijn 10+ Linux jaren heb ik in ieder geval nog nooit de behoefte gehad een kernel te (her)compileren. De modules die ik nodig hadden waren te vinden in de packages.

[lezzmeister]

Ik hercompileer altijd, installeer van source waar mogelijk. Met alle optimalisaties. Sneller is altijd beter.

[CAPSLOCK2000]

Je kan zelfs nog nieuwe servers kopen met een Matrox G200 chipset er in. Dat is een ontwerp uit 1998! Voor de meeste servers is dat ruim voldoende, net als dat een toetsenbord uit 1998 nog voldoet.

[pookie79]

offtopic:
G200/G400 was voornamelijk leuk voor de TV-out. Alle 3d programmeurs gingen toen opeens voor NVidea werken.

[Gurd]

Niet iedereen koopt een grafische kaart voor 3D, al helemaal niet in die tijd. Als ik denk aan de Matrox G200 dan denk ik aan het kunnen aansluiten van vier monitoren op één kaart.

[Brousant]

Lijkt mij heel raar dat dit in de kernel wordt gestopt. Dat soort dingen moeten juist als extensie worden teoegevoegd zodat de kernel lekker licht kan blijven.

Het zit in de source code, maar dat hoeft niet te betekenen dat het in je gecompileerde kernel zit.

[supersnathan94]

Nee dat klopt, maar als het er niet in zit en je wil het later wel toevoegen dan is dat niet zo simpel als apt-get install

[Zaffo]

Het kan best zijn dat de al gecompileerde module beschikbaar is maar niet standaard geinstalleerd. Dan is een apt install voldoende.

[willemd]

HDMI-CEC wordt niet alleen voor aan/uit gebruikt, maar ook bijvoorbeeld voor commando's zoals play/pause of menuknoppen. Dus dat je met de TV-afstandsbediening ook Kodi op je Pi kunt bedienen.

[Campo di Casa]

Idd. Had dat al op mijn pi b 512 met kodi.

[- peter -]

Zit als Kodi plugin er al lang in ja. Nu dus via de kernel.

Zou graag willen dat de Xbox One ook eens HDMI CEC gaat ondersteunen. T is zo relaxed.

[84hannes]

Volledig offtopic, maar:
Ik heb een receiver die voor CEC op 'nooit echt uit'-modus moet. Dat omdat samen met HDMI-CEC ook HDMI-passtrough en wat andere features aan staan. Daarnaast ging mijn televisie aan als ik mijn Blu-rayspeler aanzette. Als ik mijn televisie uit wilde zetten omdat ik alleen een CD wilde luisteren, dan ging de Blu-rayspeler ook uit. Tel daar bij op dat mijn receiver in 'nooit-echt-uit' modus 40W scheen te gebruiken en ik heb niet echt genoten van CEC. Ondertussen zal er wel een heleboel verbeterd zijn, maar ik geef het pas weer een kans als ik een nieuwe receiver koop, en daar heb ik voorlopig geen argumenten voor.

[Reactie gewijzigd door 84hannes op 25 juli 2024 18:33]

[mclegodude]

Waarschijnlijk zit het nu in de kernel, Ipv dat er een losse extensie vanuit kodi voor nodig was

[desalniettemin]

Als ik het goed begrijp dan is deze kernel geschikt voor de nieuwste generaties processoren zoals Haswell, Kaby Lake en Coffee Lake?

[rbr320]

Ja, met de kanttekening dat Coffee Lake ondersteuning verder verbeterd zal worden in kernel 4.15 en verder, met name de ondersteuning van de geïntegreerde GPU.

[desalniettemin]

Is deze kernel eigenlijk geschikt voor elk Linux besturingssysteem? Ik gebruik bv Peppermint 8.

[rbr320]

In principe wel. De kernel developers zijn al lang geleden het pad in geslagen waarbij ze nooit de userspace API's wijzigen als het niet hoeft (en dat is feitelijk nooit), dus je zou in theorie iedere kernel onder een bestaande installatie moeten kunnen schuiven en booten.

Persoonlijk zou ik proberen altijd alles via je package manager te doen. Dus installeer vooral de nieuwste kernel die via je package manager beschikbaar is, die zou goed moeten werken. Ubuntu maakt nieuwe kernels beschikbaar via hun Hardware Enablement programma, wellicht dat dat op Peppermint OS ook beschikbaar is aangezien dit van Ubuntu is afgeleid.

Dat gezegd hebbende, het zelf compileren en installeren kan een leuk en erg leerzaam proces zijn.

[desalniettemin]

Bedankt. Compileren ga ik maar niet doen. Gentoo is veel te moeilijk. Dat vond ik het mooie aan Peppermint 8. Ik installeerde het en alles werkte meteen.

[lezzmeister]

Gentoo installatie vind ik best wel ruk. Arch is veel makkelijker en de instructies kloppen ook, itt Gentoo handboek. Ik kan Arch aanraden.

[desalniettemin]

Ik gebruik sinds een maand of drie nu Peppermint 8 en ben er erg blij mee. Doet alles wat ik normaal met W10 ook deed en zie voorlopig geen reden om iets andere te proberen.

[Brothar]

Nu ben ik sinds eindjaren '90 wel al hap-snap bezig met linux (installeren en simpel configureren), maar de essentie in de boodschap "Linus Torvalds heeft de release van Linux 4.14 bekendgemaakt" ontgaat mij toch.
Wil dit zeggen dat de release nu goedgekeurd, uitgetest, en uitgerold is/wordt ?
Of in ontwerp gereed ?
Of slechts als kernel gereed/uitgetest en gepubliceerd, en de rest van elke distributie moet nu aangepast en uitgetest worden ?
En ja, ik zal zeer zeker bij de distributie(s) kijken ....
(Maar voor mij is de informatie nu niet eenduidig noch volledig)

[Bergen]

De release is inderdaad getest en goedgekeurd, maar niet zozeer 'uitgerold'. De broncode zit in een source code management systeem met de naam Git. Ontwikkelaars van over de hele wereld leveren code aan in de vorm van patches. Iedereen mag meedoen, jij ook. Soms wordt een eenvoudige bugfix van 1 regel geleverd, maar ook grote complexe features zoals het heterogeneous memory management waar dit nieuwsbericht onder andere over gaat. De kernel is constant in ontwikkeling.

Zo wijzigt de kernel elke dag. Een logboek van wijzigingen ('commits') kun je hier vinden: https://git.kernel.org/pu...t/torvalds/linux.git/log/
Je kunt daar zien dat er meerdere aanpassingen op een dag zijn. Stel nu dat er een belangrijke wijziging is, zoals een grote nieuwe feature of een belangrijke driver, dan kan Linus Torvalds (de Linux eindbaas) besluiten om er een versienummer aan te hangen. Dit is niets meer dan een labeltje (een 'tag') dat hij aan een bepaalde commit toevoegt. In het logboek wat ik noemde zie je de "4.14" tag er momenteel ook tussen staan.

Het is dan ook niets meer dan een referentiepunt, met als doel/gevolg dat nieuwsites erover berichten, dus iedereen weet even dat er wat belangrijks is toegevoegd. Maar een uur later kan de volgende patch alweer zijn toegepast... Het nut is dus maar betrekkelijk.

[MisterE]

Hier mis je toch een paar dingen. Er is nu een LTS versie.
Maw, ze maken een afslag (branch).
Hierbij garanderen ze een stabiele API en geen wijzigingen. Alleen security fixes verwerk je later terug in de LTS (backporten)

[Verwijderd]

verkeerde topic

[Reactie gewijzigd door Verwijderd op 25 juli 2024 18:33]