Linux-kernel 5.12 krijgt officieel ondersteuning voor de Nintendo 64

De Linux-kernel gaat na een onofficiële port nu een officiële versie krijgen met ondersteuning voor de MIPS-processor van de Nintendo 64. De aanvulling is aanwezig vanaf Linux-kernelversie 5.12, die in april moet verschijnen.

Lauri Kasanen, de ontwikkelaar die ook achter de onofficiële, aangepaste kernel van afgelopen december zat, is ook de auteur van de code die in de officiële kernel wordt verwerkt. Kasanen tekende in december echter al wel aan dat zijn port 'continu flirt' met out of memory-errors, wegens de karige 4MB aan geheugen. Echter lijken zijn aanpassingen inmiddels goed genoeg te werken voor officiële verwerking in de kernel.

Hoewel Kasanen in december al twijfelde aan het nut van het mergen van zijn werk met de mainline Linux-kernel, omdat het in zijn woorden een 'oud, niche en gelimiteerd platform' is, gaat dat dus toch gebeuren. Een mogelijke serieuze toepassing voor de kernel, is het draaien van Linux-based console-emulators op de console. Wellicht dat een Nintendo 64 bijvoorbeeld kan functioneren als een emulator voor alle Nintendo-consoles die eraan vooraf gingen.

Momenteel zit het releasekanaal van de Linux-kernel op versie 5.10 en van 5.11 is release candidate 4 beschikbaar. Deze code wordt verwerkt in 5.12. Wie dus echt niet kan wachten tot de release van 5.12 in april om Linux te draaien op zijn Nintendo 64, kan beter nog even met de onofficiële kernel aan de slag gaan. Installatie van Linux op de console moet wel gaan via een custom flashcart, aldus Phoronix.

De Nintendo 64 werd in 1996 voor het eerst uitgebracht en verscheen een jaar later op de Europese markt. De console beschikte over een 64-bits MIPS R4300-cpu met een kloksnelheid van 93,75MHz en een RCP-gpu van Silicon Graphics, die draaide op 62,5MHz. De N64 had standaard 4MB aan geheugen, hoewel dit verdubbeld kon worden met een 'expansion pak', die vereist was voor enkele games als The Legend of Zelda: Majora's Mask.

Tweakers blikte in 2019 terug op de Nintendo 64

Reacties (74)

Jerie

24 januari 2021 13:15

Draait ook op NetBSD

https://lobste.rs/s/hhkrn...root_netbsd_on_nintendo64

Die port is al langer aan de gang

https://mail-index.netbsd...2009/04/29/msg000090.html

De Sega Dreamcast (met Hitachi SH-3) draaide ook op NetBSD (en Linux!). Ook OpenBSD wordt nog wel eens geport naar obscure platformen.

Zo'n port is, tegenwoordig -met alle respect- niet zo nuttig meer. De hardware is te verouderd, terwijl de software van tegenwoordig alleen maar zwaarder is. Je kunt beter investeren in architecturen met momentum. Dat zijn deze drie: AMD64, ARM64, RISC-V. MIPS gaat op den duur vervangen worden door RISC-V (voor zover het nog niet is vervangen door ARM).

johnkeates @Jerie • 24 januari 2021 17:32

Het gaat hier niet over een 'investering' in de zin van schaal of geld of succes, dat is juist het mooie hier. Het kan gewoon een curiositeit zijn om om dat er geen 'winst' gemaakt hoeft te worden kan dat gewoon.

SuperDre @johnkeates • 24 januari 2021 19:22

Nee, maar om zulke onzin in de officiele kernel te bakken gast me dan toch echt te ver, men moet dit dus ook onderhouden. En degene die het willen genruiken kunnen het al via de onofficiele weg, en ook daar gaat het dan meer omdat het kan, niet omdat ze er wat zinvols mee willen doen. Door dit soort onzin in de officiele kernel op te nemen maak je jezelf gewoon belachelijk IMHO. Ik zou er mee eens zijn als er nu veel devices zouden zijn die hier baat bij hebben, maar die zojn er niet, nu is het dus nog meer useless bagage wat onderhouden moet worden.

johnkeates @SuperDre • 24 januari 2021 19:46

"men" is hier dus de maintainer, zonder maintainer komt het er niet in, en als de maintainer weggaat nadat het er al in zit gaat het er weer uit. Het is niet alsof er een groot bedrijf een kernel aan het bouwen is en alles er in moet en er een vast aantal FTE dan verantwoordelijk is om het te onderhouden.

Met de kernel ben je vrij te doen wat je wil, en wat er 'in' zit (de kernel source tree dus) heeft dan ook geen zak te maken met de kernel die jij waarschijnlijk zelf zou draaien gezien dat nagenoeg nooit de mainline kernel is, en als het dat wel is vaak ook nog eens een die geconfigureerd is met specifieke targets in gedachten, en ook dan nog flink wat modules in plaats van static compiled-in heeft. Met andere woorden: 90% van wat er in de kernel (sources) zit gebruik jij niet je weet waarschijnlijk niet eens dat het bestaat.

Het enige wat 'slecht' zou zijn is code zonder maintainer in de source laten zitten, of niet-optionele toevoegingen maken.

kevinvz 24 januari 2021 13:01

Superleuk en lekker geeky. En tegelijk kan ik me ook voorstellen dat er ook mensen zijn die die dit als “bloat” beschouwen en dood gewicht om mee te zeulen in de kernel wat betreft bytes maar ook nog meer regels code die maintenance nodig hebben en problemen kunnen geven. Maar er zijn slimme lui die hierover gaan, dus kennelijk is dat niet echt een bezwaar. Weet iemand hoe dat zit? Wat zijn de “kosten” van zo’n toevoeging?

[Reactie gewijzigd door kevinvz op 23 juli 2024 01:19]

carlpls @kevinvz • 24 januari 2021 13:17

Zonder veel inhoudelijke kennis te hebben over deze specifieke wijzigingen; bij het compilen van Linux kan je aangeven wat je precies wil compilen. De meest gebruiksvriendelijke manier is dmv 'menuconfig'. De opties die in dit menu getoond worden zijn op basis van de verschillende Kconfig files in de Linux source code.

Als je in het artikel op "code" drukt ga je hierheen:

https://git.kernel.org/pu...0c91fb2113f0&anzwix=print

En als je daar op "arch/mips/Kconfig" klikt ga je naar:

https://git.kernel.org/pu...99ad7a91773350c91fb2113f0

Dit is dus een optie die wordt toegevoegd aan 'menuconfig' om support voor de Nintendo 64 in gecompileerde kernels uit te schakelen. Verder (omdat de Nintendo 64 een MIPS processor heeft, welke al ondersteund werd door Linux) voegt deze commit niet bijzonder veel code toe of heeft fallout/'bloat' naar onderdelen buiten dit specifieke stukje voor de Nintendo 64.

Nu ik deze reactie zo teruglees is het volgensmij geen eenduidig antwoord op je vraag, maar hopelijk kan je er iets mee.

RSpliet @carlpls • 24 januari 2021 16:58

Nee wat je zegt klopt! Deze MIPS-toevoegingen hebben geen invloed op een niet-MIPS build. Daar komt bij dat het buiten de x86(-64) wereld gebruikelijk is om de kernel te specialiseren voor het doelplatform adhv de kernel config opties die je noemt. Voor embedded platforms met beperkte opslag en RAM is dat nogal waardevol. Dit specialiseren hoeft men niet geheel handmatig te doen, daar zijn "default config" bestanden voor in de kernel om daarmee te helpen. De "binary" bloat is dus minimaal.

Dorank @kevinvz • 24 januari 2021 13:39

ook nog meer regels code die maintenance nodig hebben en problemen kunnen geven

Dat is geen probleem, op het moment dat niemand zich geroepen vindt om deze code te onderhouden en op het moment dat er problemen ontstaan wordt deze code gewoon verwijderd. Dat gebeurd met enige regelmaat, 2 weken geleden is er geopperd om oude meuk te verwijderen, zie https://www.phoronix.com/...=2021-Linux-Drop-Old-CPUs

Jogai @Dorank • 25 januari 2021 13:50

Oh no! 486 code gaat er uit, wel jammer hoor.

Sando @kevinvz • 24 januari 2021 13:26

De source code omvat van alles, maar bij het compileren worden alleen de target hardware en ondersteunde flags meegenomen.

De binaries zijn dus nooit bloated.

De source code zelf, ach maintainers zonder interesse in mips negeren dat mapje gewoon. Als het niet meer onderhouden wordt dan merkt niemand daar wat van zolang ze niet voor die target compileren.

Dus de "kosten" zijn vrijwel niets, behalve wat extra kilobytes in de source code die alle developers klonen. De winst is dat Linux voor ontzettend veel targets te compileren is.

84hannes @Sando • 24 januari 2021 15:41

Dus de "kosten" zijn vrijwel niets, behalve wat extra kilobytes in de source code die alle developers klonen.

En de kosten van onderhoud; code die niet gebruikt/getest wordt rot weg. Dus moet je de code regelmatig daadwerkelijk compileren en testen anders kun je er donder op zeggen dat het binnen een paar jaar niet meer werkt. Als de code niet meer werkt is het per definitie bloat, maar ik betwijfel of de moeite van het continu testen het wel waard is.

ViTO_xp @84hannes • 24 januari 2021 16:34

Denk niet dat de MIPS voor de N64 nog erg veel zal wijzigen

VNA9216 @ViTO_xp • 24 januari 2021 16:43

Maar andere interne dingen in de kernel misschien wel, met als gevolg dat die code die niet onderhouden word, en afhankelijk is van de veranderde code in de basis van de kernel, het best nog eens zou kunnen stoppen met werken.

fastedje @ViTO_xp • 24 januari 2021 16:44

Het gaat hierbij niet om dat de code voor de Nintendo 64 zelf wijzigingen nodig heeft, echter als er algemene.wijzigingen in de kernel worden gedaan, dan zal.je deze code deels herschreven moeten worden. 84hannes heeft in mijn ogen echt een punt dan oude code daardoor wegrot.

johnkeates @84hannes • 24 januari 2021 17:38

Ook dat klopt niet helemaal, code die binnen een target valt en altijd meekomt zal wel bloat genoemd kunnen worden, maar op de manier waarop je het nu uitlegt is alle arm-specifieke code in de kernel 'bloat' als je op POWER draait, of als je op MIPS-draait de x86-specifieke code weer bloat is. Of dat het rot zodra je het zelf niet gebruikt. Of als je van targets afstapt en het over drivers hebt, dan is de sg-driver ook bloat als je alleen nvme gebruikt? Of alle code die AVX512 gebruikt, die zou ook bloat kunnen zijn als je CPU dat niet kan. Of andersom: je CPU kan het, maar de code maakt op runtime nog steeds de keuze om het wel of niet te gebruiken, 'bloat branch' (of jump).

Ik denk eerder dat het gewoon binnen de levenscyclus van de code past en daar voldoende rekening mee gehouden is:

- Te weinig tests/controle
- Geen onderhoud maar wel bugs
- Maintainers te weinig

Als een of meerdere van die zaken waar zou zijn dan is de code er in no-time weer uit.

84hannes @johnkeates • 24 januari 2021 17:44

alle arm-specifieke code in de kernel 'bloat' als je op POWER draait,

Met ‘werkende code’ bedoel ik code die je kunt compileren en dan doet wat hij moet doen. Ik gebruik Linux, het lijkt me vreemd als ik daarom beweer dat de source code van Windows niet werkt.

johnkeates @84hannes • 24 januari 2021 17:55

Volgens mij heeft dit niks met Windows te maken. En werkende code is inderdaad code die werkt (zoals de omschrijving doet vermoeden

) Maar code die werkt is niet wat de criteria van de kernel omschrijven, daar gaat het over usage en maintainers (niet eens over contributors).

[Reactie gewijzigd door johnkeates op 25 juli 2024 11:56]

84hannes @johnkeates • 25 januari 2021 07:10

24 januari 2021 17:55
Volgens mij heeft dit niks met Windows te maken.

Klopt.

En werkende code is inderdaad code die werkt

Ik hoop niet dat je hier iets mee wilde verduidelijken.

johnkeates @84hannes • 25 januari 2021 10:20

Dan zal je toch iets moeten uitleggen:

het lijkt me vreemd als ik daarom beweer dat de source code van Windows niet werkt.

Want waar dat Windows dan vandaan komt blijft me een raadsel.

84hannes @johnkeates • 25 januari 2021 10:57

Want waar dat Windows dan vandaan komt blijft me een raadsel.

Windows wordt gemaakt door Microsoft, in Redmond.

Ik stel dat jij stelt dat ik stel... Dit gaat nergens heen als jij niet duidelijk maakt wat je onder "werkende code" verstaat. Ik heb mij definitie gegeven, maar wil hem best herhalen:

"Werkende code is code die gecompileerd kan worden en dan de gewenste functionaliteit biedt (aan de gestelde eisen voldoet)."

Met die definitie kan ik niet beweren dat code niet werkt, zuiver omdat je het niet compileert/gebruikt.

Troepje @kevinvz • 24 januari 2021 13:55

Wat ik een beetje mis in de commentaren (of ik kijk er overheen); alle code die in de kernel zit, moet worden onderhouden. Stel iemand maakt een interface wijziging ergens wat die code ook raakt, dan al hij ook die code moeten updaten. Dat is een beetje jammer als die code nooit gebruikt wordt.
Zoals gezegd heeft het op de uiteindelijke binary van de kernel geen impact als je het niet gebruikt.

NielsFL @Troepje • 24 januari 2021 22:59

Het voor de hand liggende alternatief op “onderhouden” is natuurlijk “verwijderen”.

Wanneer iets niet werkt door wijzigingen in andere code en niemand dient zich aan om het te repareren dan gaat het er gewoon uit.

Wat mij betreft een vrij natuurlijk proces. Het vinden van vrijwilligers correleert toch meestal met de belangrijkheid of populariteit.

84hannes @Troepje • 24 januari 2021 17:38

Stel iemand maakt een interface wijziging ergens wat die code ook raakt, dan al hij ook die code moeten updaten.

Of erger: hij/zij update het niet en er zit code in de kernel die het niet eens doet. Daarom zou ik kwa kosten ook niet kijken naar de performance of opslagruimte, maar naar de kosten van onderhoud, zoals ik elders al zei.

Troepje @84hannes • 27 januari 2021 19:02

Oopsie dan keek ik er overheen. Maaruhh hebben ze geen fatsoenlijke testen in de kernel dan? En vaak als jeen api aanpast dan krakt een compiler wel. Het doel van mn tekstje was iig de impact iets concreter te maken.

Adion

@kevinvz • 24 januari 2021 13:12

Ik heb de code niet bekeken, maar ik vermoed dat die zowiezo niet mee gecompileerd word voor linux-kernels gecompileerd voor processors anders dan de MIPS R4300.
Voor alle ARM en x86 versies van de kernel veranderd er dus mogelijk helemaal niets.

CH4OS @kevinvz • 24 januari 2021 14:28

Bij Linux kun je het zo licht maken als je zelf wilt. Je kunt zelfs voordat je 'de boel' gaat installeren alles eerst zelf compilen, inclusief kernel. Daarin heb je dan absolute vrijheid, je compiled dan bijvoorbeeld enkel alles wat je nodig hebt, zodat je een zo licht mogelijk systeem hebt, bijvoorbeeld. Dat geldt dan uiteraard ook voor de kernel die je compileert.

HollowGamer @kevinvz • 24 januari 2021 13:25

Het is niet zo leuk voor die mensen die steeds door Linus worden afgebrand omdat hun code is niet goed is of documentatie ontbreekt en hij het daarom niet wilt mergen. Ik vind dat zeker een valid punt en de Linux-kernel moet gewoon te onderhouden zijn, echter heb ik begrepen dat dit ook maar een proof of concept was en nog steeds zaken ontbraken.. tja, dan zakt je de moet wel in de schoenen als BUS1 of alternatieve schedular maker lijkt me.

Duckman51 @HollowGamer • 24 januari 2021 14:24

Off topic
Dat afgebrande gevoel herken ik wel, heb ook vaak zat met maintainers van een opensource project in discussie gelegen, alleen als je letterlijk aan alle voorwaarden hebt voldaan zijn ze wellicht misschien bereid om op de knop merge te drukken..
Het voelt dan alsof jij al het werk mag doen, alles zelf uitvinden, testen en dergelijke en hun leunen achterover en wachten tot jij alles gedaan hebt en hun alleen nog op de knop hoeven drukken als ze daar zin in hebben.

Zo zwart/wit zal het niet zijn maar het gevoel is er wel

Ontopic
Persoonlijk heb ik niks met Nintendo en snap niet waarom dit dan in een Linux kernel zou thuishoren. Aan de andere kant zal het zeker nuttig zijn voor iemand die wel iets met Nintendo doet.

Navi @Duckman51 • 24 januari 2021 15:00

Dat is toch niet meer dan normaal? Waarom zou een ander werk moeten verrichten voor jouw aanpassing? Zorg dat het compleet is, netjes, goed werkt en getest is, dan kan het mee.

Ririshi @Navi • 24 januari 2021 15:57

Omdat zij ook baat hebben bij jouw aanpassingen. Anders zou je ze sowieso niet hoeven / willen mergen. Dan kan je verwachten dat "de community" op z'n minst een beetje betrokken is.

Moet zeggen dat de meeste open source maintainers daar wel vriendelijk in zijn en op z'n minst de code met / voor je kunnen doornemen.

Duckman51 @Ririshi • 25 januari 2021 10:49

Precies, zij en dus iedereen die er gebruik van maakt heeft er baat bij.

Voor dingen die ik dan specifiek zou willen toevoegen snap ik dat ik dan het werk ga doen. maar soms is het zelfs zo erg dat men ook voor een bug report een pull request verwacht, dat gaat mij echt te ver.

xFeverr @Duckman51 • 25 januari 2021 07:43

Het is soms gewoon niet anders mogelijk dan een harde lijn te trekken, anders is de maintainer al zijn beschikbare tijd kwijt aan het aanpassen en complementeren van PR's.

Als er voorwaarden worden gesteld, en je denkt: "Ach... Voor mij een keertje niet hoor." Dan zit daar de fout. Niet bij degene die je erop wijst.

svenk91 @HollowGamer • 24 januari 2021 14:12

Aan de andere kant, de N64 toestaan genereert wat positieve media aandacht en heeft dus meer waarde dan alleen de paar kb code zelf. Dat gebeurd ook niet door het werk van elke ontwikkelaar. Ik denk dat de media waarde hier zeker is meegenomen en je zou het moeten toejuichen, misschien trekt Linux nu nog meer (jonge en enthousiaste) ontwikkelaars aan.

svenk91 @84hannes • 24 januari 2021 20:04

Die jonge mensen die via interesse in gaming verder de IT / dev wereld in komen. Ook jongere gamers vinden oude consoles nog wel eens interessant natuurlijk

Jerie

@kevinvz • 24 januari 2021 13:17

Niets, deze code wordt alleen gebruikt op MIPS. Een Linux kernel programmeur mag helemaal zelf weten waar hij of zij de tijd aan besteed. Het staat ons geheel vrij zoiets nuttig of nutteloos te vinden.

HollowGamer @Jerie • 24 januari 2021 13:30

Dat is niet helemaal waar, Linus en greg bepalen altijd nog of het uiteindelijk in de kernel komt. Ja, je kunt prima de Linux-kernel forken en je eigen ding doen, maar zij bepalen uiteindelijk of het nuttig of nutteloos is als je het wilt laten mergen.

84hannes @Jerie • 24 januari 2021 17:41

Een Linux kernel programmeur mag helemaal zelf weten waar hij of zij de tijd aan besteed.

Als die Linuxkernelprogrammeur wil dat zijn wijzigingen geaccepteerd worden zal hij of zij moeten zorgen dat andere code die door deze wijzigingen beïnvloed worden ook nog steeds werkt. De volgende keer dat iemand een wijziging wil maken in bijvoorbeeld de Mips-ondersteuning, zal die persoon na moeten gaan of deze wijziging invloed heeft op de N64-implementatie; dat is niet bepaald gratis.

Jerie

@84hannes • 24 januari 2021 22:47

Als N64 port stuk gaat is dat niet van belang. Er zijn immers praktisch geen gebruikers, de hardware is al jaren obsolete. Een emulator is de enige legacy van belang. Plus dat je de machine op orig. firmware kunt draaien. Leuk voor een museum.

84hannes @Jerie • 24 januari 2021 22:49

Als N64 port stuk gaat is dat niet van belang.

Ik ben niet bekend met het beleid van maintainers, maar denk jij dat de kernel vol zit met code die jaren geleden al kapot is gegaan maar waar niemand iets of geeft?

Jerie

@84hannes • 24 januari 2021 22:55

Bitrot is real.

Sterker nog dat is de reden waarom dergelijke ports in Net- en OpenBSD discontinued zijn. Wat weer het gevolg is van een gebrek aan gebruikers en ontwikkelaars.

84hannes @Jerie • 25 januari 2021 07:19

Bitrot is real

Exact. Daarom zou ik geen code in de kernel opnemen waar zowel geen vraag als geen aanbod voor lijkt te zijn.

psychicist @84hannes • 24 januari 2021 22:58

Dat denk en weet ik wel zeker, omdat ik regelmatig dergelijke problemen tegenkwam en nog steeds tegenkom. Wat dat betreft zouden er nog wel meer automatische tests gedraaid kunnen worden.

Ik heb bovendien gekeken of QEMU een machinetype Nintendo 64 bevat, maar dat lijkt dus niet het geval te zijn. Dat zou een mooie toevoeging kunnen zijn om deze kernel te kunnen draaien en testen.

En als het dan uiteindelijk door een gebrek aan onderhoud weer uit de kernel wordt verwijderd, is er nog steeds geen man overboord. De commits staan nog steeds in de geschiedenis en zouden gebruikt kunnen worden om een andere kernel naar de hardware te porten.

Ik zou dan wel eerder kiezen voor BSD code van OpenBSD of NetBSD dan voor GPLv2 code puur vanwege het feit dat het dan kunt samenvoegen met meer code onder andere licenties, waaronder (A)GPLv3.

sspiff @kevinvz • 24 januari 2021 14:03

Deze dingen zitten vaak in een apparte submap met eigen maintainer. Opname in de mainline vereist vaak een trackrecord van ondersteuning en updates, wat de auteur wellicht vorig jaar heeft aangetoond.

Wanneer niemand meer aan deze code werkt en de code zorgt voor problemen bij een nieuwe ontwikkeling, dan verdwijnt deze ondersteuning weer.

Omega @kevinvz • 24 januari 2021 16:21

De patch is maar 223 lijntjes aan code, het zit niemand in de weg en is prima te onderhouden.

L0g0ff

24 januari 2021 13:03

Wat ik typisch vind dat de kernel opgeblazen wordt met iets wat nog niet helemaal stabiel kan draaien.

Voor de hackers die met deze kernel aan de slag willen kunnen toch gewoon een eigen kernel compilen op basis van de kernel module code van Kasanen?

[Reactie gewijzigd door L0g0ff op 25 juli 2024 11:56]

The Third Man @L0g0ff • 24 januari 2021 13:12

Je blaast er niks mee op, want dit soort code is alleen van toepassing voor een mips-build. Een build voor een andere CPU architectuur zoals de bekende x86_64 heeft hier geen last van.

L0g0ff

@The Third Man • 24 januari 2021 13:31

Daar blaas je de MIPS kernel toch op?

En als ze dit soort edge cases in de MIPS kernel zetten dan zullen ze dat misschien ook voor de x86_64 en ARM kernels doen voor soortgelijke projecten.

Maar dat is een aanname wat ik nu doe. Mogelijk zijn die regels strenger omdat die kernels veel meer gebruikt worden.

The Zep Man

Besturingssystemen
Linux

@L0g0ff • 24 januari 2021 13:39

Daar blaas je de MIPS kernel toch op?

Alleen als je specifiek een MIPS kernel compileert met de N64 als 'target'. Voor andere systemen wordt de betreffende code niet meegecompileerd.

Lang geleden werd er ook ondersteuning voor de allereerste Xbox toegevoegd, maar die code had nul invloed op gewoon gecompileerde kernels. Voor Xbox accessoires (controllers, het FATX file system) waren er losse modules die je mee kon compileren met elke kernel, zodat je die ook op andere systemen kan gebruiken. Dat was uiteraard optioneel. De code om een kernel te booten op een Xbox (met name om PCI bus scanning te vermijden, wat een Xbox niet goed kon doen) zat echter alleen in de Xbox kernel.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 11:56]

NielsFL @L0g0ff • 24 januari 2021 23:03

Het tegendeel is waar. De Nintendo specifieke delen zul je alleen in een Nintendo kernel mee compileren.

Tegelijkertijd krijgt de generieke MIPS code nu meer aandacht dan voorheen.

HollowGamer @The Third Man • 24 januari 2021 13:27

Ik weet niet of @L0g0ff het bedoelt als opblazen als in code. Je voegt code toe die je ook weer moet onderhouden. Voor mij kan dit prima in een eigen repo en als het stabiel genoeg is mag het in de Linux-kernel.

The Third Man @HollowGamer • 24 januari 2021 23:58

Heb je de code bekeken? Het zijn slechts tientallen regels waarvan hoofdzakelijk wat parameters definiëren en een paar korte initialisatiefuncties. Het is geen functioneel onderdeel dat nog ‘stabiel’ moet zijn alsof je het over een soort framework van duizenden regels code hebt...

En los hiervan heeft het enkel effect op een build specifiek voor een n64 target, dus de enige getroffenen van een bug zijn n64 gebruikers. Het slaat nergens op om die dan te isoleren, voor elke andere toegevoegde ondersteuning aan de Linux kernel gaat het op deze manier. Zo hou je ook de verdere ontwikkeling centraal de in Linux kernel cvs in plaats van allerlei ‘eilanden’ in andere third party repo’s die ook tzt weer kunnen verdwijnen.

[Reactie gewijzigd door The Third Man op 25 juli 2024 11:56]

Xfade @L0g0ff • 24 januari 2021 22:13

wat nog helemaal stabiel kan draaien?

L0g0ff

@Xfade • 24 januari 2021 22:53

Sorry my bad. Ik bedoelde natuurlijk "niet helemaal stabiel". Ik heb het aangepast. Tnx!

harley 24 januari 2021 13:11

Ik snap dus serieus niet dat dit wordt opgenomen in de kernel. De ontwikkelaar geeft zelf al aan dat het onstabiel is, en het lijkt me zo'n kleine niche dat het sowieso toch niet in de main kernel hoeft.

HollowGamer @harley • 24 januari 2021 13:31

Lijkt me ook een klap in het gezicht van andere contributors, die krijgen regelmatig 'netjes' te horen van Linus dat hun code/contributie niet goed is of niets toevoegd.

[Reactie gewijzigd door HollowGamer op 25 juli 2024 11:56]

johnkeates @HollowGamer • 24 januari 2021 17:31

Of de code is gewoon goed, Linus maakt het echt niet uit wat de schaal van de usecase is, die gaat vooral over technisch en functioneel correcte code die onderhouden wordt. Een Mesa-ontwikkelaar is waarschijnlijk wel in staat om dat te level voor een zelfstandig target, en als het ook nog eens makkelijk te verwijderen is maakt dat de merge een stuk aannemelijker.

Andere contributors bedoelen het vaak niet slecht ofzo, maar leveren ook gewoon prut aan en dan krijg je daar wel een reactie op ja.

TheVivaldi @HollowGamer • 24 januari 2021 16:39

Het heeft wellicht ook met status te maken. Veel dingen die Linus afwijst zijn van kleine (al dan niet onbekende) ontwikkelaars, terwijl deze port gedaan is door één van de mensen achter Mesa, een zeer belangrijk Linux-project, en deze ontwikkelaar is ook nog één van de bekendste van dat team.

tonkie_67 @TheVivaldi • 24 januari 2021 19:37

Is toch niet zo gek dat een bijdrage van een ontwikkelaar die al veel heeft bijgedragen en bewezen heeft dat hij goede bijdragen levert eerder serieus genomen wordt dan een newbie die nog geen trackrecord heeft?
Respect op dat gebied moet je opbouwen; meestal door te beginnen met (kleine) bijdragen binnen een bepaalde groep/project en bij bewezen kwaliteiten een steeds grotere rol binnen zon project. Kan best een keer gebeuren dat een newbie met een uniek goed idee komt, maar je moet ook functioneren in een community waar je niet altijd je zin krijgt en bij nieuwelingen weet je niet hoe zon persoon functioneert in groepsverband.
En Linus zelf is een voorbeeld dat een goede techneut niet perse goede social skills heeft die ook belangrijk zijn in een groeps-effort zoals de kernel ontwikkelingen

TheVivaldi @tonkie_67 • 24 januari 2021 19:56

Is toch niet zo gek dat een bijdrage van een ontwikkelaar die al veel heeft bijgedragen en bewezen heeft dat hij goede bijdragen levert eerder serieus genomen wordt dan een newbie die nog geen trackrecord heeft?

Dat zeg ik toch ook niet? Ik legde alleen uit hoe het mogelijk zat aan de persoon boven mij. Je hele uitleg had dus aan die persoon gericht moeten zijn en niet aan mij.

tonkie_67 @TheVivaldi • 24 januari 2021 21:03

Was ook meer een aanvulling en zeker geen aanval.
Als ik reageerde op de opmerking erboven had ik een groot deel moeten herhalen; maar mn openingszin had beter gekund om dat duidelijk te maken..

cricque @HollowGamer • 24 januari 2021 14:00

Yups dacht ik ook, er is al veel dat niet in de kernel komt, maar een n64 wel, begrijpen wie begrijpen kan. Nu zoveel impact voor de "gewone" gebruiker heeft dit niet, omdat dit niet in je kernel zal zitten. Maar het wilt wel zeggen, dat als je wilt compilen voor alle platformen, je met extra dingen rekening gaat moet houden. En dat kan een mogelijk issues zijn in de toekomst. Nu dit zal wel goed afgewogen zijn. Maar hoeveel mensen hebben nog een n64 staan. En van die mensen die dit nog gebruiken, hoeveel interesse zou er dan nog zijn om dit te kunnen ...

Mijzelf @harley • 24 januari 2021 15:09

De ontwikkelaar zegt niet dat het onstabiel is. Hij zegt dat het 'continu flirt met out of memory-errors'. De kernel kan best stabiel zijn, maar met het toepassen moet je terdege rekening houden met het gelimiteerde geheugen.
Dat ligt niet aan deze port. Je kunt elk systeem plat krijgen door alle geheugen op te gebruiken.

Chris_147 24 januari 2021 13:00

Een mogelijke serieuze toepassing voor de kernel, is het draaien van Linux-based console-emulators op de console. Wellicht dat een Nintendo 64 bijvoorbeeld kan functioneren als een emulator voor alle Nintendo-consoles die eraan vooraf gingen.

Nou, als ik de termen "emulatie" en "N64" hoor, dan is het eerder de N64 emuleren op PC, Raspberry Pi of ander recenter platform, niet de N64 als host gebruiken voor emulatie.
Daarmee hou je de nadelen van ouder platform (beschikbaarheid, snelheid, aansluiting voor TV, I/O, ...) en heb je weinig van de voordelen die nieuwer platform brengt.

Caviatjuh @Chris_147 • 24 januari 2021 13:12

Dat zou zeker niche zijn. Om een Nintendo 64 een beetje proper aan te kunnen sluiten (ook op een beeldbuis) moet je een RGB of HDMI mod uitvoeren. De N64 ondersteund namelijk alleen maar s-video. De controllers zijn ook niet bepaald ideaal. Alleen al een beetje deftige RGB-Scart kabel kost je bijna net zoveel als een RPi, en daar kan je dan ook nog de N64 op emuleren.

[Reactie gewijzigd door Caviatjuh op 25 juli 2024 11:56]

AmigaWolf @Caviatjuh • 24 januari 2021 15:12

Dat zou zeker niche zijn. Om een Nintendo 64 een beetje proper aan te kunnen sluiten (ook op een beeldbuis) moet je een RGB of HDMI mod uitvoeren. De N64 ondersteund namelijk alleen maar s-video. De controllers zijn ook niet bepaald ideaal. Alleen al een beetje deftige RGB-Scart kabel kost je bijna net zoveel als een RPi, en daar kan je dan ook nog de N64 op emuleren.

Je hoef helemaal niet een RGB of HDMI mod uit te voeren op de N64, ik ga gewoon naar retrogamingcables, en daar heb je gewoon high quality kabels voor de N64, zo als DEZE, nogmaals ze zijn niet goedkoop, maar je krijgt fantastische kwaliteit, heb er zelf ook meerdere gekocht bij ze, en volledig RGB, en gaat van N64 aansluiting naar HDMI aansluiting.

Caviatjuh @AmigaWolf • 24 januari 2021 16:31

Als je dat aansluit op een ongemodificeerde N64 heb je niet eens S-Video ondersteuning, maar moet je het doen met composite. Als je dat fantastische kwaliteit vind dan wordt je leven als retrogamer in ieder geval een stuk makkelijker en goedkoper, maar ik hecht iets meer waarde aan een fatsoenlijk videosignaal. Zoals ook in de specs staat:

N64 - Composite video Mode or RGB if modified (For best results use an RGB modified N64 console).

AmigaWolf @Caviatjuh • 24 januari 2021 17:01

Natuurlijk voor het beste resultaat gebruik je een RGB aangepaste N64 console, maar het is niet nodig, daar heb ik het over, een onaangepaste N64 vind ik het beste (in zijn originele staat houden), en dat er niks fout kan gaan als je je N64 gaat aanpassen, nu is het met deze kabel plug n play, en nog steeds hele goede beeld en audio kwaliteit.

Ik gebruik zelf de Retrotink-2x Scart en dan heb ik een Vivanco SBX 84 Scart Switch box, en al me consoles daarop aangesloten met Scart RGB kabels, en dan op me versterker, en dat ziet er heel goed uit, en klinkt ook goed, en ja al die apparaten geven ook echt RGB door, heb ik ook een optie voor, hij laat dan alleen beelden zien die RGB zijn, Ik gebruik een Amiga CD32 + TF330, een Sega Multi Mega, en een SNES, en ja de beeld en audio kwaltijd is heel goed, maar ja de kabels en apparaatje zijn heel duur, maar heb je wel goed kwaltijd beeld en audio.

Al heb ik wel de Otaku-Games 6 Port RGB Scart Auto Switch (with housing) besteld, die is van een stuk betere kwaliteit dan de Vivanco SBX 84, die ik nu heb.

[Reactie gewijzigd door AmigaWolf op 25 juli 2024 11:56]

Verwijderd @Caviatjuh • 24 januari 2021 21:52

Ik heb als retro gamer liever alles origineel, zoals ik het toen ook speelde. Dus gewoon simpel video signaal op m'n oude 63cm 4:3 crt tv

AmigaWolf @Verwijderd • 24 januari 2021 23:07

Ik heb als retro gamer liever alles origineel, zoals ik het toen ook speelde. Dus gewoon simpel video signaal op m'n oude 63cm 4:3 crt tv

Waarom niet met betere beeld gaan retro gamen?

Ik vind de extra scherpe beeld wel een bluspunt als ik eerlijk ben, en zelf op 16:9 zetten vind ik ook niet erg, alles woord wat breder maar ik vind dat helemaal niet erg.

SuperDre 24 januari 2021 19:18

En dat terwijl ze meer oude cpu support wilde gaan schrappen. Zinloze toevoeging voor de officiele kernel, onnodig extra onzin om te moeten onderhouden. Het kan al onofficiel voor die paar mensen die het interessant vinden.

NaliXL 25 januari 2021 08:10

Zonder dollen, levert dit allemaal (voor Lauri Kasanen, de betrokkenen bij de Linux kernel en eventueel tweakers) niet veel gezeik van Nintento op? Die zijn immers best wel actief met een team advocaten om nintendo-gerelateerde content (en met name hacks) te censureren?

Verwijderd @NaliXL • 25 januari 2021 08:53

Nee, mods en hacks voor de oude consoles (lees: alles behalve de Switch, en misschien de 3DS nog) zit Nintendo niet zo veel achteraan. Voor de oude consoles zijn het voornamelijk de ROMs waar ze DMCAs voor uitdelen. Flashcarts voor de oude consoles worden bijvoorbeeld al jaren zonder problemen verkocht.

IrBaboon79 25 januari 2021 14:07

Ach, leuk voor de mensen die ermee willen stoeien; het zit niet in de weg en het lijkt goed te onderhouden qua afmeting vd patch... thuis-kernel-bakkers zullen ook wel snappen hoe ze dat spul eruit moeten vlaggen tijdens build dus feitelijk weinig mis mee.

Maar support voor elke random oude console/fluitketel/grasmachine met een LCD display hoeft er - voor mij persoonlijk - niet in want uiteindelijk sterft die HW toch wel een keer ivm leeftijd en gebrek aan onderdelen; wel leuk dat het kan natuurlijk.

Op dit item kan niet meer gereageerd worden.

Lees meer

Reacties (74)

Sorteer op:

Weergave: