Debian krijgt bij versie 13 'Trixie' waarschijnlijk RISC-V-ondersteuning

Debian werkt aan ondersteuning voor RISC-V-apparaten. De ontwikkelaars zeggen aan een port te werken die waarschijnlijk uitkomt voor Debian 13. Die distro komt pas over ongeveer twee jaar als stabiele versie uit.

De ontwikkelaars schrijven dat in een maillijst voor developers van de distro. Voorlopig zeggen de makers dat RISC-V nog niet op de officiële architectuurlijst staat. Wel werken de makers aan een port voor hardware waar een RISC-V-processor met 64bit in zit. De makers zeggen 'goede voortgang' te boeken met die port.

De makers verwachten RISC-V officieel te kunnen ondersteunen in Trixie, versie 13 van de distributie. De officiële stabiele versie daarvan komt naar verwachting pas over ongeveer twee jaar uit, maar testers kunnen eerder wel aan de slag met een onstabiele versie. De ontwikkelaars zeggen dat RISC-V-ondersteuning wel afhankelijk is van architectuurkwalificaties, die pas op een onbekend later tijdstip uitkomen.

Reacties (59)

[ikhebeenvraag]

Ik vraag me al een tijdje iets af: Hoe krijg je een OS werkende op een compleet nieuwe processorarchitectuur ?

Immers om een OS te kunnen gebruiken moet je het compilen maar om te kunnen compilen heb je weer een werkend OS nodig.


Ik weet dat RISC-V niet nieuw is voor de linux community maar dacht dit is wel een handig topic.

[CAPSLOCK2000]

Ik vraag me al een tijdje iets af: Hoe krijg je een OS werkende op een compleet nieuwe cpu architectuur?

Immers om een OS te kunnen gebruiken moet je het compilen maar om te kunnen compilen heb je weer een werkend OS nodig.

Met een zogenaamde "cross-compiler". Dat is een compiler die binaries produceert voor een andere architectuur dan waar die zelf op draait. De ontwikkelaar heeft dan bv een x86-computer maar de compiler weer hoe risc-v er uit ziet en kan binaries bouwen die je op RISC-v kan draaien.

[veltnet]

Je kunt prima binaries compileren voor een ander platform. Een RISC-V compiler kunt je dus maken zonder RISC-V compiler

[84hannes]

Immers om een OS te kunnen gebruiken moet je het compilen maar om te kunnen compilen heb je weer een werkend OS nodig.

Ik kan twee oplossingen bedenken:

• Cross-compilers kunnnen code compilen voor een andere architectuur
• Een oplossing voor het "trust the compiler"-probleem is een simpele compiler in assembly schrijven, en die gebruiken om (incrementeel) complexere compilers te bouwen

De eerste is het meest waarschijnlijk. Let op dat ik het niet over een OS heb, een simpele compiler heeft wellicht geen compleet OS nodig.

[Reactie gewijzigd door 84hannes op 22 juli 2024 20:51]

[Wim Cossement]

Wel hoe denk je dat automated builds of nightlies van bijvoorbeeld GitHub werken?
De binaries worden per architectuur en soms ook nog per OS automatisch gegenereerd door verschillende compilers die waarschijnlijk allemaal op x64 Linux omgeving draaien.

[Muis666]

Daarvoor gebruik je een cross compiler. Die draait dus op een ondersteunde architectuur maar genereert code voor een andere architectuur.

[blorf]

Als je de architectuur op papier hebt en fysieke I/O kun je een testprogamma met RISC-V instructies laden dat zou moeten luisteren. Dan heb je een main loop werkend en kun je kernel-functies inhaken tot het door gaat voor een linux. Waarschijnlijk kan veel redelijk effectief geport worden van andere achtitecturen met allerlei vereiste aanpassingen.

[Reactie gewijzigd door blorf op 22 juli 2024 20:51]

[beerse]

Met de gentoo distributie kan je dat zelf proberen/ervaren. Zie uitvoering: Gentoo Linux voor tweakers informatie (helaas niet helemaal meer up-tot-date).

Tip: Eerst gentoo opzetten voor je eigen architectuur (of in een viruteel systeem). Daarna kan je het daar vandaan ook bouwen voor andere architectuur. Ooit (20 jaar terug) zelf gedaan voor pa-risc hardware in 32 en 64 bits.

[BvdW1978]

De cross-compiler is al genoemd. Uiteindelijk kun je jezelf ook aan je eigen schoenveters omhoog trekken door een compiler in Assembler -> machinecode te schrijven. Zo ging dat in de vorige eeuw ook op ponskaart/band. Je zult alles zelf moeten maken vanaf het punt dat de firmware een bootloader probeert te starten. Best hardcore dus de crosscompiler was een welkome uitvinding.

[analog_]

Wat alle reacties hier missen is dat je kan wel binaries crosscompilen maar op risc-v en platformen die die chips gebruiken (ik denk aan mango pi mq pro en dergelijke) is het boot systeem volledig afhankelijk van het 'moederbord'. De kloterij is dus dat dit tot nu toe nogal customware was omdat niet duidelijk was in welke mate er flexibiliteit tussen kernel en user-space moet zijn. Op rpi bv. wordt de bootcode in het bios van de videokaart gestoken en dat kicked het bootproces. Omdat dit met een custom binary gebeurt vanwege broadcom chipset is dat ofcourse niet open genoeg voor license mensen

[kuurtjes]

Bill Gates heeft Windows op Windows gemaakt!

[UPPERKEES]

Door zoiets als Mock te gebruiken. Voor RPM packages kan je dan voor verschillende releases en architectures packages bouwen om te testen. Daarna kan je source RPMs pushen naar de live build omgeving van Fedora.

[Reactie gewijzigd door UPPERKEES op 22 juli 2024 20:51]

[Maurits van Baerle]

Hoe werkt dit eigenlijk, is dit grotendeels een nieuwe of aangepaste compiler gebruiken die ook RISC-V code kan uitspuwen en dan kijken wat er op hoger niveau aangepast moet worden?

Het lijkt me dat het op het niveau van bijvoorbeeld Rust of Python niet of nauwelijks uitmaakt of iets op ARM of RISC-V gaat draaien.

[84hannes]

Het lijkt me dat het op het niveau van bijvoorbeeld Rust of Python niet of nauwelijks uitmaakt of iets op ARM of RISC-V gaat draaien.

Een andere processor-architectuur is meer dan alleen een ander instructieset. Je moet ook rekening houden met endianness, byte vs word allignment, padding etc. Elke architectuur kan hier anders mee omgaan, dus voor iedere architectuur moet je kijken of dit probleemloos afgehandeld wordt. Dit is voor meer dan 99% van de code niet relevant (een 64 bit unsigend integer wordt inderdaad door je compiler wel goed afgehandeld), maar als je data gaat (de)serializeren om bijvoorbeeld weg te schrijven naar bestanden of over een network stream te transporteren, dan moet je hier wel rekening mee houden.

[Reactie gewijzigd door 84hannes op 22 juli 2024 20:51]

[jorisvergeerTBA]

Dat is dan nog user space software. Denk ook aan de kernel die ondersteuning moet krijgen voor de functies in de architectuur. Denk aan hoe het ram geheugen beheerd moet worden, de hardwarematige security features, memory management, drivers voor USB, PCIe, etc...

[ikhebeenvraag]

De linux kernel heeft toch out of the box ondersteuning voor RISC-V? dan zou het een kwestie zijn van compile en testen.

[CAPSLOCK2000]

De linux kernel heeft toch out of the box ondersteuning voor RISC-V? dan zou het een kwestie zijn van compile en testen.

De kernel wel, maar je hebt ook nog applicaties nodig.
Voor een groot deel is dat inderdaad zo simpel als compilen & testen & gaan! maar niet voor alles.
Zeker de installer vereist toch wel wat architectuur specifieke aanpassingen.

[TheVivaldi]

Precies. En al is het zo simpel, het moet er wél zijn. Een beetje tweaker draait zijn hoofd niet om voor compileren, maar Debian heeft een enorme pakketbron. Dat is een van de belangrijkste redenen om Debian te gebruiken, dus het is wel belangrijk dat al die pakketten of in elk geval een groot deel ervan beschikbaar zijn.

[xajac]

Zou het niet mogelijk zijn om deze paketten geautomatiseerd te compilen? Broncode opvragen, compilen en publiceren op github of de distro site kan best in een script worden gegoten.


Als je een goede server hebt is het een kwestie van weken.

[Mijzelf]

Het lijkt me sterk dat Debian niet geautomatiseerd zou bouwen. Er zijn 9 platforms officieel ondersteund, en er zijn iets van 80000 pakketten. No way dat iemand dat handmatig gaat compileren.
Maar er komt natuurlijk mee bij kijken. Als 1% van die pakketten compiler errors geeft voor RISC-V (wat me een lage schatting lijkt), moet je alsnog een hoop werk verrichten om de automatische taak aan de gang te krijgen.

[CAPSLOCK2000]

Dat klopt, meer informatie over het auto-build netwerk van Debian kan je vinden op:
https://www.debian.org/devel/buildd/

Het leukste zijn natuurlijk de stats: https://buildd.debian.org/stats/

[84hannes]

Als 1% van die pakketten compiler errors geeft voor RISC-V (wat me een lage schatting lijkt), moet je alsnog een hoop werk verrichten om de automatische taak aan de gang te krijgen.

Maar compilen is niet genoeg. De ene architectuur heeft 2 bytes nodig om 2 uint8_t's op te slaan, een andere 8 (of zelfs 16?). Als de programmeur verkeerde aannames doet hierover gaat het compilen prima, maar kan je programma gekke dingen doen tijdens uitvoeren. Testen kan dus ook nodig zijn, of minimaal geautomatiseerde checks.

[CAPSLOCK2000]

Maar compilen is niet genoeg. De ene architectuur heeft 2 bytes nodig om 2 uint8_t's op te slaan, een andere 8 (of zelfs 16?). Als de programmeur verkeerde aannames doet hierover gaat het compilen prima, maar kan je programma gekke dingen doen tijdens uitvoeren. Testen kan dus ook nodig zijn, of minimaal geautomatiseerde checks.

Dat klopt maar Debian heeft het voordeel dat het al op twee dozijn verschillende architecturen draait waardoor de meeste van dat soort aannames er al uit zijn. De ontwikkelaars krijgen alleen nog te maken met zaken die op RISC-V anders zijn dan op alle andere architecturen.

Tests voor andere architecturen helpen ook, al is het maar om te waarschuwen dat er een potentieel probleem is.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 20:51]

[jorisvergeerTBA]

Dat kan zeker. Dat word ook gedaan.

Google eens op "dpkg-buildpackage" en "debuild". Daar vind je een scale aan regelateerde comamndo's en tools waarmee het bouwen van pakketten geautomatiseerd is.

[Xander2]

De kernel wel, maar je hebt ook nog applicaties nodig.
Voor een groot deel is dat inderdaad zo simpel als compilen & testen & gaan! maar niet voor alles.

Dat is het zeker niet.

De gegenereerde code is dan wel ISA-specifiek, er zitten altijd verrassingen per platform omdat een driver net iets anders werkt onder bepaalde omstandigheden of een compiler optimalisatie onbedoeld averechts werkt.

Dat kost veel tijd, inzet en is niet te automatiseren, je moet de test nog schrijven.

[MSalters]

De kernel heeft support voor de RIC-V ISA. Dat is totaal ongerelateerd aan hardware, waar de vraag over ging. Dit is berucht bij niet-x86 architecturen. ARM met name is onvoorspelbaar; ongeveer elk device heeft z'n eigen idee over hardware.

x86 is een uitzondering vanwege 1 simpele reden: Windows. Microsoft gaat zich niet aanpassen aan jouw idee, dus moederbord makers doen geen gekke dingen. En Intel/AMD hebben een direct lijntje.

[Olaf van der Spek]

Je moet ook rekening houden met endianness, byte vs word allignment etc.

RISC-V is niet de eerste 'andere' architectuur die Debian ondersteund dus daar wordt al rekening mee gehouden.

[CAPSLOCK2000]

Een andere processor-architectuur is meer dan alleen een ander instructieset. Je moet ook rekening houden met endianness, byte vs word allignment etc. Dit is voor meer dan 99% van de code niet relevant (een 64 bit unsigend integer wordt inderdaad door je compiler wel goed afgehandeld), maar als je data gaat (de)serializeren om bijvoorbeeld weg te schrijven naar bestanden of over een network stream te transporteren, dan moet je hier wel rekening mee houden.

Linux heeft het geluk dat het al lange tijd op meerdere architecturen beschikbaar is waardoor veel software al rekening houdt met andere architecturen. De beheerders van de RISC-V tak hebben daardoor een goed beeld van wat er haalbaar en realistisch is.

[Maurits van Baerle]

Ja, dat Endianness gedoe herinner ik me nog wel van de PowerPC naar X86 transitie. Maar X86, ARM en RISC-V zijn allemaal little-endian dacht ik dus dat leek me geen probleem.

[beerse]

Tel daar bij de verschillen in praktische/technische mogelijkheden van de cpu en vooral zaken als fpu en gpu die daar bij komen, hoe die worden aangesprokenen of just in software worden ge-emuleerd. Veel cpu-s hebben ook mogelijkheden om de mmu en nog meer van dergelijke zaken apart en netjes aan te sturen.

Daar naast zal de risc-v cpu worden opgebouwd op een moederboard met een referentie architectuur die gevolgd kan worden maar waar ook stevig van kan worden afgeweken.

Voor de liefhebbers: Kijk eens naar de gentoo-linux distributie en probeer die eens voor je eigen apparatuur op te zetten. Als/zodra je dat voor elkaar hebt, dan kan je ook een Risc-V (of andere architectuur) bouwen.

[CH4OS]

Je zult de binaries voor Rust, Python en alle applicaties natuurlijk ook moeten compileren in de RISC-V architectuur.

[Maurits van Baerle]

Uiteraard, maar ik vroeg me dus af in hoeverre je ook aan de Rust of Python code zelf moest gaan schaven om het op RISC-V te laten werken of dat je dat gewoon aan de compiler kunt overlaten. Het lijkt er dus op dat dat soms inderdaad wel nodig is om hogere code ook aan te passen.

[CAPSLOCK2000]

Uiteraard, maar ik vroeg me dus af in hoeverre je ook aan de Rust of Python code zelf moest gaan schaven om het op RISC-V te laten werken of dat je dat gewoon aan de compiler kunt overlaten. Het lijkt er dus op dat dat soms inderdaad wel nodig is om hogere code ook aan te passen.

De meeste code werkt gewoon maar uiteindelijk heb je als programmeur volledige controle en dus ook de controle om code te maken die afhankelijk is van een bepaalde architectuur. In praktijk zul je daar niet snel tegenaan lopen als je niet dicht tegen de hardware aan programmeert en wie dat wel wil kiest typisch een andere taal dan Python.
Bij "normale" software krijg je er denk ik het eerste mee te maken als je met andere systemen wil communiceren via bestanden of netwerk. Als je vertrouwt op standaard libraries zullen die dat grotendeels voor je afvangen.

[MSalters]

Nee, dit klopt niet. Als programmeur werk je soms in de sandbox van een runtime, en dan kan je alleen wat die runtime toelaat. En als je dat niet doet, dan draai je in de sandbox van een userland omgeving. Alleen kernel programmeurs hebben volledige controle, en die werken uiteraard niet in Python.

[CAPSLOCK2000]

Nee, dit klopt niet. Als programmeur werk je soms in de sandbox van een runtime, en dan kan je alleen wat die runtime toelaat. En als je dat niet doet, dan draai je in de sandbox van een userland omgeving. Alleen kernel programmeurs hebben volledige controle, en die werken uiteraard niet in Python.

Ook in een sandbox kun je code maken die niet compatible is met de architectuur waar die sandbox op draait. Een sandbox is er om de rest van de omgeving af te schermen van wat er in de sandbox gebeurt.
Er is geen garantie dat je werkende code hebt binnen die sandbox.
Ook in een sandbox kun je dicht tegen de hardware aan programmeren, zelfs als die hardware virtueel is.

Echt volledige controle bestaat natuurlijk niet. Strict genomen hebben kernel-programmeurs ook niet de volledige controle maar moet je bij de firmware of de hardware zijn

In de context waar we het hier over hebben, het porten van software & compatibility, durf ik wel te zeggen dat de programmeur volledig e(ok, "genoeg") controle heeft om code te maken die niet compatible is.

[CyBeR]

Je hebt als programmeur volledige controle over wat je schrijft, niet over wat je op het systeem kunt doen.

Als userland C programmeur kun je prima x86 asm toevoegen, alleen is dan je code meteen incompatibel met alles wat niet x86 is.

[CH4OS]

In theorie zou dat niet nodig hoeven zijn, tenzij er platform specifieke issues / bugs zijn. De scripts zelf hoeven niet tegen RISC-V gecompileerd te worden. Of dat voor Rust ook is weet ik niet, daar heb ik geen ervaring mee.

[RJG-223]

In theorie zou dat niet nodig hoeven zijn, tenzij er platform specifieke issues / bugs zijn. De scripts zelf hoeven niet tegen RISC-V gecompileerd te worden. Of dat voor Rust ook is weet ik niet, daar heb ik geen ervaring mee.

Programmeurs zijn zeer creatief. Het zou niet de eerste keer zijn dat code een lijn bevat als 'if platform == "x86" then ...'. Als je dan wel rekening hebt gehouden met x86 en ARM, maar niet met RISC-V, dan werkt je code op RICS-V niet, of niet goed.
En dat betekent dan nog niet eens dat de uit te voeren acties zeer platform-specifiek zijn. Alleen dat de programmeur op een x86 systeem iets anders wilde doen dan op een ARM systeem. Goede code schrijven is moeilijk...

Afgezien daarvan wordt sommige code (ook in hogere talen) gebruikt om platform-specifieke hardware aan te sturen. Bij RISC-V verschilt die hardware van de ARM hardware. Dus is er een nieuwe driver nodig.

[Olaf van der Spek]

Hoe werkt dit eigenlijk, is dit grotendeels een nieuwe of aangepaste compiler gebruiken die ook RISC-V code kan uitspuwen en dan kijken wat er op hoger niveau aangepast moet worden?

Yep, GCC ondersteunt al RISC-V: https://en.wikipedia.org/wiki/GNU_Compiler_Collection

[davekok]

Ik denk dat dit voornamelijk te maken heeft met inline assembly in sommige libraries. Er zal gechecked moet worden of die geschikt is. De meeste code is reeds architectuur neutraal dus zal niet zoveel uit maken. Uiteraard zullen hier en daar specifieke optimalisaties moeten worden herzien voor RISC-V.

[Bulkzooi]

De Debian-ontwikkelaars zeggen dat RISC-V-ondersteuning in "Trixie" wel afhankelijk is van architectuurkwalificaties.

Dit haal ik niet uit de aankondiging... Heeft dat iets van doen met de britney migration scripts?

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 20:51]

[!GN!T!ON]

Zie hier: https://release.debian.org/testing/arch_qualify.html

[Bulkzooi]

Zie hier: https://release.debian.org/testing/arch_qualify.html

thnx.
Daar hebben ze het over architecture requalification. Dus een nieuwe set eisen en wensen? Of wellicht een voortslepende history?

Maar blijkbaar zit de crux in de laatste 1% van de instructieset-migratie. Zal wel te maken hebben met een heel ecosysteem dat zich moet aanpassen. Met ARM erbij (bij Intel/AMD) eigenlijk 2 ecosystemen (plus nog wat exotische legacy).

@blorf we cross-posten maar we vragen ons ongeveer hetzelfde af.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 20:51]

[!GN!T!ON]

Als ik het goed snap is de qualification een lijst vragen / eisen voordat werk word gestart.

Questions for new architectures

• Are machines available to buy for the general public?
• Is full source available?
• Is this architecture related to other architectures already in the archive, or that also should be considered, either now or in the future? Can the related architectures be supported in a single architecture (eg, with a biarch arrangement)?
• Are there 3 or more developers (or NMs) actively maintaining the port? Who are they?
• What sort of architecture is this? Desktop/workstation? Mainframe/supercomputer? Embedded? Something else?
• Does it have any users? If a desktop system, are there Debian admins who run Debian systems on the arch? If an embedded system are there real systems shipping that a Debian port will be useful for? If a mainframe system are there real systems with many users that a Debian port will be useful for?
• Is there kernel and toolchain support? At what level? Are the latest versions supported, or are legacy releases required for compatibility with some hardware?
• Has the ABI stabilised, or are there major ABI changes coming up? Is the ABI stable enough to ensure users will be able just "apt-get dist-upgrade" from one version to the next?

etc. zie hele lijst hier: https://wiki.debian.org/ArchiveQualification/riscv64

De requalification is denk ik richting het einde van het process inderdaad:

This document should be a living document, but experience learns that the main part of the qualification process only happens near the end.

Oftewel, dit zou constant bijgewerkt moeten worden, maar praktijk leert dan dit alleen aan het einde word gedaan.

[Reactie gewijzigd door !GN!T!ON op 22 juli 2024 20:51]

[Bulkzooi]

etc. zie hele lijst hier: https://wiki.debian.org/ArchiveQualification/riscv64

Is there kernel and toolchain support? At what level? Are the latest versions supported, or are legacy releases required for compatibility with some hardware?

Has the ABI stabilised, or are there major ABI changes coming up? Is the ABI stable enough to ensure users will be able just "apt-get dist-upgrade" from one version to the next?

Ze engineeren dus vanaf hier: "apt-get dist-upgrade". (Wellicht vanwege enkele design-errors in APT? Vermoedelijk zal er ook veel politiek plaatsvinden aangaande repository's)

Ik denk dat de experimentele builds reeds in 99.9% van de situaties werkt.
Sommige drivers zullen zeker en vast nog wel wat hickups ondervinden maar als QT en GTK draaien verwacht ik niet al te veel bijzonderheden.

Oftewel, dit zou constant bijgewerkt moeten worden, maar praktijk leert dan dit alleen aan het einde word gedaan.

MESA-Matrix-style

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 20:51]

[CAPSLOCK2000]

De Debian-ontwikkelaars zeggen dat RISC-V-ondersteuning in "Trixie" wel afhankelijk is van architectuurkwalificaties.

Dit haal ik niet uit de aankondiging... Heeft dat iets van doen met de britney migration scripts?

Ik begrijp de zin in het oorspronkelijke artikel ook niet helemaal. Ik denk dat ze bedoelen dat ze later nog een keer kijken of de RISC-V versie wel voldoet aan de minimale eisen die Debian zichzelf stelt voordat RISC-V deel wordt van de officiele release.

Ik geloof niet dat het iets met Britney te maken heeft. (Leave Britney alone!)

[!GN!T!ON]

Jep, en of er maintainers e.d. beschikbaar zijn. https://release.debian.org/testing/arch_qualify.html

[blorf]

Wat betekent het? Mijn idee was dat een RISC-V kernel niet meer probeert dan de hardware mogelijk maakt. Ze moeten nog vaststellen waar de grenzen liggen?
Overigens ben ik wel benieuwd of die toekomstige kernel ook zonder brand-speficieke aanpassingen op echt bestaande hardware draait. Wat ik tot nu toe aan RISC-V-hardware had gezien zijn allemaal chipsets met iets anders er omheen.

[84hannes]

Ik schrok een beetje van dit artikel want ik werk nog met Debian 11, dus dacht ver achter te lopen. Blijkbaar is Debian 12 (Bookworm) een paar dagen geleden uitgebracht, zonder een meldingnieuws-artikel op Tweakers. Misschien leuk om dat er bij te vermelden, @TijsZonderH.

edit:
Zoals @basmilius vermeld heeft Tweakers wel een melding gemaakt, maar niet waar ik zocht

[Reactie gewijzigd door 84hannes op 22 juli 2024 20:51]

[basmilius]

download: Debian GNU/Linux 12.0

[SPee]

Een major release van een belangrijke distro en die wordt alleen in de "software updates" genoemd?
Bij meerdere is die op de FP verborgen achter de popup bij "... en x andere downloads".

[TijsZonderH]

Wilde ik net een los bericht van maken want dat had ik ook gemist, probleem is ook wel dat het wel een beetje laat is.

[CyBeR]

Om eerlijk te zijn moest ik dat hier ook uit de comments halen dus ik denk wel dat dat nog meerwaarde heeft.

[beerse]

TIP: Klik vanaf de debian12 aankondiging door naar de debian product pagina hier bij tweakers (uitvoering: Debian GNU/Linux). Daar selecteer je bovenaan 'hebben' en daarbij achter 'downloadalert' een vinkje bij 'krijg een notificatie bij een updates'.

Link verbeterd (er stond 'tweakers' achteraan.... een copy-paste-oeps)

[Reactie gewijzigd door beerse op 22 juli 2024 20:51]

[xFeverr]

je link geeft een 404

[bjp]

mooi! echt, wie de beste Linux kan bieden voor RISC-V, zal meesurfen op de RISC-V groei.

[CAPSLOCK2000]

mooi! echt, wie de beste Linux kan bieden voor RISC-V, zal meesurfen op de RISC-V groei.

Ja, de markt lijkt zin te hebben in RISC-V en er liggen dus grote kansen. Ik denk dat het open karakter van RISC-V ook goed past bij Debian. Dat vertaalt zich niet direct in concrete features of zo iets maar meer in een wederzijdse interesse. Met gedeelde normen & waarden gaat samenwerking net iets prettiger.

[itcouldbeanyone]

Mijn sparc machines draaien nu allemaal debian 12
Voor amd64 moet ik het een en ander nog upgraden naar debian 12. (Sommige servers vinden de nieuwe kernel niet leuk)

[Jim80]

Over Debian, Linux en Torvalds gesproken, dit blijft toch een memorabele:
https://youtu.be/5PmHRSeA2c8