LNX Kroeg - Deel 2

[RobertMe]

Hero of Time schreef op vrijdag 13 februari 2026 @ 19:41:
[...]

Ah, ik druk niet zomaar op willekeurige knoppen, ik klik op de sessie die ik wil als ik iets anders dan de default wil (oftewel, verandert nooit) en typ dan m'n wachtwoord in. Maar heb je zoals op de Arch wiki staat ook '--no-global-shortcuts' toegevoegd aan het kwin commando in sddm.conf snippet?

Nah, ik weet ook niet meer wat het was. Of het nu een shortcut of iets anders was. Ik deed semi random iets en toen dacht ik "huh? Owja, is gewoon Kwin".
Ga me er verder ook niet druk om maken Als de release schijnbaar komende woensdag is zal ik het volgend weekend wel kunnen upgraden

[Hero of Time]

Ik denk dat ik minstens een week of langer moet wachten, de Debian package maintainer voor KDE is niet altijd de snelste. Het heeft ook een paar maanden geduurd toen 6.0 uit kwam.

[Hero of Time]

Nou lekker dan, had net weer dat Plasmashell onderuit ging. Journal heeft dan deze regel:

code:

kernel: amdgpu 0000:03:00.0: amdgpu: VM memory stats for proc plasmashell(1643) task plasmashel:cs0(1631) is non-zero when fini

Ja, het eindigt echt met 'fini'. Device adres is van m'n 7900 XTX. Een vram memory leak zou onwaarschijnlijk zijn, met 24 GB vram en op dit moment maar 3,1 GB in gebruik.

[Shinji]

Hero of Time schreef op vrijdag 13 februari 2026 @ 19:41:
[...]

Ah, ik druk niet zomaar op willekeurige knoppen, ik klik op de sessie die ik wil als ik iets anders dan de default wil (oftewel, verandert nooit) en typ dan m'n wachtwoord in. Maar heb je zoals op de Arch wiki staat ook '--no-global-shortcuts' toegevoegd aan het kwin commando in sddm.conf snippet?


[...]

KDE Neon, wat niet meer is dan Ubuntu LTS met upstream PPA. Elke dag, of iig met grote regelmaat, updates van minstens 1 GB op Fedora is best bizar eigenlijk. Je ziet welke packages er bijgewerkt worden? Je kan altijd zien wat er is gedaan met 'dnf history'.

Ah ja, die idd, ik zal straks eens in die history kijken, vandaag was het 1,9GB ofzo. Zoveel bijzonders heb ik niet draaien, Firefox, Chromium, VS Code, Zed, OBS en teams4linux maar die update niet automatisch.

[HollowGamer]

Shinji schreef op vrijdag 13 februari 2026 @ 16:08:
Wat me opvalt, ik draai nu een jaar Fedora (43 nu) en daarvoor KDE Plasma, of hoe heet hun eigen distro ook alweer. Maar dat er gewoon elke dag een update is van 1 - 3GB ongeveer. Ik vind dat best veel.

Dat is helaas (nog) normaal. Er is werk voor delta updates, maar voor nu zou ik kiezen voor Fedora of Ublue images als alternatief.

[Shinji]

HollowGamer schreef op vrijdag 13 februari 2026 @ 21:49:
[...]

Dat is helaas (nog) normaal. Er is werk voor delta updates, maar voor nu zou ik kiezen voor Fedora of Ublue images als alternatief.

Ik draai ook Fedora, en dan nog steeds zijn het gewoon vaak updates en die zijn dan ook vaak vrij groot.

Net even gekeken, en heb op mijn laptop denk ik eergisteravond updates gedaan, en nu staan er weer een kleine 500MB. Via dnf history list zie ik alleen mijn cli geschiedenis en ik doe meestal via de package manager updaten en die zie ik niet in de dnf history terug, zal vast ook wel ergens te vinden zijn.

In elk geval, die bijna 500MB is dus niet wat die gaat downloaden, maar de geinstalleerde grote lijkt het, dus dat vertekend misschien al wat.

[ Voor 51% gewijzigd door Shinji op 13-02-2026 22:09 ]

[surcharge]

Hero of Time schreef op vrijdag 13 februari 2026 @ 21:19:
Nou lekker dan, had net weer dat Plasmashell onderuit ging. Journal heeft dan deze regel:

code:

kernel: amdgpu 0000:03:00.0: amdgpu: VM memory stats for proc plasmashell(1643) task plasmashel:cs0(1631) is non-zero when fini

Ja, het eindigt echt met 'fini'. Device adres is van m'n 7900 XTX. Een vram memory leak zou onwaarschijnlijk zijn, met 24 GB vram en op dit moment maar 3,1 GB in gebruik.

Probleem met AMD in ieder geval, niet KDE.

[RobertMe]

Hero of Time schreef op vrijdag 13 februari 2026 @ 20:04:
Ik denk dat ik minstens een week of langer moet wachten, de Debian package maintainer voor KDE is niet altijd de snelste. Het heeft ook een paar maanden geduurd toen 6.0 uit kwam.

Eigenlijk weet ik ook helemaal niet hoe snel Arch is Vroeger lange tijd de kde-testing (+ testing zelf) repos gedraaid, maar dat doe ik ook al jaren niet meer. Vandaag even gekeken en blijkbaar is het sowieso wat aangepast. Het is nu kde-unstable (maar nog steeds releases, alpha, beta, rc, geen git nightly of zo), en na release gaat het eerst nog langs extra-testing. Kan dus zomaar wat langer overheen gaan. (Met release naar extra-testing en dan paar dagen / weekje later naar extra?)

Van Manjaro op mijn werk laptop kan ik mij wel herinneren dat die super traag zijn. Laptop heb ik in ~april '24 gekregen, KDE 6.0 release was zo te zien in februari. En ik heb die toen met de unstable repos op gezet om in een keer KDE 6 te krijgen. En het heeft toen ook nog maanden geduurd meen ik voordat die in stable zat. En ook de minor releases lopen ze gevoelsmatig minimaal een maand of zo achter. IIRC is er nog een release geweest met wat flinke verbeteringen die ik wel op mijn prive systemen had maar lang geduurd heeft voordat het in Manjaro zat.

[HollowGamer]

RobertMe schreef op vrijdag 13 februari 2026 @ 22:15:
[...]

Eigenlijk weet ik ook helemaal niet hoe snel Arch is Vroeger lange tijd de kde-testing (+ testing zelf) repos gedraaid, maar dat doe ik ook al jaren niet meer. Vandaag even gekeken en blijkbaar is het sowieso wat aangepast. Het is nu kde-unstable (maar nog steeds releases, alpha, beta, rc, geen git nightly of zo), en na release gaat het eerst nog langs extra-testing. Kan dus zomaar wat langer overheen gaan. (Met release naar extra-testing en dan paar dagen / weekje later naar extra?)

Van Manjaro op mijn werk laptop kan ik mij wel herinneren dat die super traag zijn. Laptop heb ik in ~april '24 gekregen, KDE 6.0 release was zo te zien in februari. En ik heb die toen met de unstable repos op gezet om in een keer KDE 6 te krijgen. En het heeft toen ook nog maanden geduurd meen ik voordat die in stable zat. En ook de minor releases lopen ze gevoelsmatig minimaal een maand of zo achter. IIRC is er nog een release geweest met wat flinke verbeteringen die ik wel op mijn prive systemen had maar lang geduurd heeft voordat het in Manjaro zat.

Arch wacht meestal altijd op de .1 release. Dit deden ze bij Gnome ook altijd, bij KDE was dit dacht ik ook zo.

Debian is voor mij niet serieus te nemen. Waarom mensen het super stabiel noemen met allemaal oude meuk, snap ik niet. Dan heb je ook nog de non-free repo voor codecs en firmwares, iets dat Arch wel gewoon kan.

Ik vind juist dat Debian de Linux markt tegenhoud met hun trage updates. Geloof dat 90% van hun users nog op Xorg draait, want 'het werkt', maar wel zeurt als een app ontwikkelaar zegt geen tijd meer heeft het nog te ondersteunen.

[Out.of.Control]

Jazzy schreef op vrijdag 13 februari 2026 @ 19:57:
[...]

Gast. Bakje koffie gegeven, half uurtje gekletst, paar honderd euro in ontvangst genomen en meegelopen naar de auto.

Tweede systeem is inmiddels in België bij iemand met 100 (!) oude Unix machines die nu zijn eerste RS/6000 bij mij kwam ophalen. Ook best bijzonder. Had ook een AS/400 trouwens.

Geweldig. Doet me denken aan deze gozer.
Tot een kleine 10 jaar geleden had ik ook een verzameling van zo'n 50 machines, maar op een gegeven moment bijna alles weggedaan/weggegeven. Ook voornamelijk oude unix machines: Vax, PA-RISC, SGI, Sun, Alpha, Itanium, zat best bijzonder spul tussen.
Van de nieuwprijs van het hele spul zou je een aardig huis kunnen kopen, maar in de huidige tijd kun je er weinig mee. Behalve een beetje nostalgisch mee prutsen of wachten op een bijzonder moment totdat iemand er echt eentje nodig heeft die nog draait

[synoniem]

HollowGamer schreef op vrijdag 13 februari 2026 @ 22:24:
[...]

Arch wacht meestal altijd op de .1 release. Dit deden ze bij Gnome ook altijd, bij KDE was dit dacht ik ook zo.

Debian is voor mij niet serieus te nemen. Waarom mensen het super stabiel noemen met allemaal oude meuk, snap ik niet. Dan heb je ook nog de non-free repo voor codecs en firmwares, iets dat Arch wel gewoon kan.

Ik vind juist dat Debian de Linux markt tegenhoud met hun trage updates. Geloof dat 90% van hun users nog op Xorg draait, want 'het werkt', maar wel zeurt als een app ontwikkelaar zegt geen tijd meer heeft het nog te ondersteunen.

Ik ben juist blij met Debian stable. Ik heb met andere distro's regelmatig gezeik gehad dat spullen niet werkte of dependency problemen opleverde. Voor een experimenteer desktopsysteem of mijn server homelab maakt het me niet zoveel uit maar alles wat in productie staat moet gewoon stabiel draaien.

[Hero of Time]

surcharge schreef op vrijdag 13 februari 2026 @ 21:56:
[...]

Probleem met AMD in ieder geval, niet KDE.

Nou.... het is al vaker gebeurt dat KDE iets deed dat uniek was en daardoor de videodriver liet crashen of iig instabiliteit veroorzaakte. Het is dus niet helemaal aan AMD te rekenen. Bovendien had ik dit een aantal Plasma versies terug niet. Maar tegelijkertijd is ook de kernel en andere libraries bijgewerkt.

HollowGamer schreef op vrijdag 13 februari 2026 @ 22:24:
Debian is voor mij niet serieus te nemen.

Dan kunnen we jou ook niet serieus nemen met zo'n kortzichtige opmerking.

Waarom mensen het super stabiel noemen met allemaal oude meuk, snap ik niet. Dan heb je ook nog de non-free repo voor codecs en firmwares, iets dat Arch wel gewoon kan.

En Arch heeft de reputatie regelmatig om te vallen. Leuk dat je codecs hebt, maar als je systeem zo instabiel is al wat heb je er alsnog geen fluit aan.

Dat is uiteraard wat gechargeerd gezegd. Maar Debian heeft een duidelijke filosofie en houd zich hier aan. Arch doet maar wat en lijkt geen enkele richting of regels te hebben voor het toelaten van software. Vrijheid of anarchie, het is maar net hoe je er naar kijkt.

Ik vind juist dat Debian de Linux markt tegenhoud met hun trage updates. Geloof dat 90% van hun users nog op Xorg draait, want 'het werkt', maar wel zeurt als een app ontwikkelaar zegt geen tijd meer heeft het nog te ondersteunen.

Werkelijk? Volgens mij moet je je beeld eens vernieuwen en niet vast houden aan hoe het in de jaren '90 en '00 was. Debian is vele malen stabieler dan Ubuntu ooit zal zijn, zelfs dan hun LTS. En vind je hetzelfde van Red Hat, dat ze traag zijn met updates en de markt tegenhouden?

De markt wil stabiele systemen hebben. En er is een hele goede reden waarom RHEL en Debian het meest gebruikt worden hiervoor en niet iets als Arch.

[Borromini]

HollowGamer schreef op vrijdag 13 februari 2026 @ 22:24:
[...]

Arch wacht meestal altijd op de .1 release. Dit deden ze bij Gnome ook altijd, bij KDE was dit dacht ik ook zo.

Debian is voor mij niet serieus te nemen.

Ah, weer een Arch fanboy. Die denken altijd het evangelie te moeten prediken 🤣. Alleen is het hier niet de Bible Belt...

Er zijn Linux-gebruikers die wat anders te doen hebben dan elke dag updates te draaien en dan dingen te moeten fiksen omdat je per sé de laatste release moet hebben. Mijn systemen moeten werken, mijn hobby's zijn de dingen die op die systemen draaien, niet die systemen zelf. Ik wil mijn tijd niet in mijn OS steken.

Been there, done that. Got the T-shirt.

Ik vind juist dat Debian de Linux markt tegenhoud met hun trage updates. Geloof dat 90% van hun users nog op Xorg draait, want 'het werkt', maar wel zeurt als een app ontwikkelaar zegt geen tijd meer heeft het nog te ondersteunen.

'De markt'? Waar heb je het in godsnaam over.

Ik draai al jaren Wayland, maar dat ging gelukkig op AMD GPU's sneller dan op andere. Zodra Debian dat aanbood omgeschakeld (ook al omdat Gnome dat als harde eis had op bepaald punt) en niet meer omgekeken. Geen centje pijn.

Als jij Arch geweldig vindt dan is dat goed voor jou, maar probeer het anderen niet door de strot te rammen.

[surcharge]

Hero of Time schreef op zaterdag 14 februari 2026 @ 00:27:
[...]

Nou.... het is al vaker gebeurt dat KDE iets deed dat uniek was en daardoor de videodriver liet crashen of iig instabiliteit veroorzaakte. Het is dus niet helemaal aan AMD te rekenen. Bovendien had ik dit een aantal Plasma versies terug niet. Maar tegelijkertijd is ook de kernel en andere libraries bijgewerkt.

De meeste interactie tussen Plasma en de kernel driver gaat via libraries zoals vulkan en GBM.
Gezien de foutmelding zou ik toch echt zeggen of de kernel driver zelf.
Warschijnlijk praat plasma alleen direct met de driver voor het configureren en presentatie op het beeldscherm.

[ Voor 5% gewijzigd door surcharge op 14-02-2026 10:27 ]

[Hero of Time]

surcharge schreef op zaterdag 14 februari 2026 @ 09:06:
[...]

De meeste interactie tussen Plasma en de kernel driver gaat via libraries zoals vulkan en GBM.
Gezien de foutmelding zou ik toch echt zeggen of de kernel driver zelf.
Warschijnlijk praat plasma alleen direct met de driver voor het configureren en presentatie op het beeldscherm.

Goed mogelijk hoor. Wilde alleen aangeven dat KDE in het verleden via libraries dingen wilde dat in de driver niet lekker kon. Om de kernel module (driver) uit te sluiten zou ik een oudere kernel moeten installeren van de tijd toen dit niet gebeurde en zien of Plasmashell nog steeds herstart. Het is alleen heel lastig te reproduceren, want ik doe niks speciaals. Zit video's te kijken en dat is 't. Meestal in fullscreen, maar niet altijd.

Na de kernel regel in het log staat daarna dat plasmashell sloot en 3,1 GB geheugen gebruikte. Dat zou natuurlijk ook gewoon kunnen, memory leak en crasht daardoor omdat het niet meer kan/mag gebruiken door opgegeven beperkingen.

[surcharge]

De foutmelding geeft een indicatie dat het gebeurt tijdens het vrijmaken van de adresruimte zelf, dus als het onvrijwillig is dan let AMD niet op bij het opruimen nadat een proces gekilld is.

[HollowGamer]

Borromini schreef op zaterdag 14 februari 2026 @ 08:18:
[...]

Ah, weer een Arch fanboy. Die denken altijd het evangelie te moeten prediken 🤣. Alleen is het hier niet de Bible Belt...

Er zijn Linux-gebruikers die wat anders te doen hebben dan elke dag updates te draaien en dan dingen te moeten fiksen omdat je per sé de laatste release moet hebben. Mijn systemen moeten werken, mijn hobby's zijn de dingen die op die systemen draaien, niet die systemen zelf. Ik wil mijn tijd niet in mijn OS steken.

Been there, done that. Got the T-shirt.


[...]

'De markt'? Waar heb je het in godsnaam over.

Ik draai al jaren Wayland, maar dat ging gelukkig op AMD GPU's sneller dan op andere. Zodra Debian dat aanbood omgeschakeld (ook al omdat Gnome dat als harde eis had op bepaald punt) en niet meer omgekeken. Geen centje pijn.

Als jij Arch geweldig vindt dan is dat goed voor jou, maar probeer het anderen niet door de strot te rammen.

Op dit moment draai ik helemaal geen Arch Linux, dus die woorden zou ik terugnemen. Momenteel draai ik Fedora op al mijn devices, waarvan sommige de Ublue stable images (het is Fedora, maar met drivers voor NVIDIA included).

Fedora is wat mij betreft de sweetspot. Je pushed redelijk op tijd updates, maar pas met een nieuwe release, ga je over op iets nieuws.

Dus ik ben helemaal geen Arch fanboy. Heb het jaren gedraaid, maar ik ben nu wel klaar met al dat tweaken en te veel zelf doen. Zelf heb ik nooit instabiliteit ervaren op Arch. Sterker nog, met backports van Debian/Ubuntu had ik juist issues, aangezien zij dus een fix hadden toegepast op een oudere versie. Dat was ook raar voor de developer, die zei het in 3.1.1 te hebben gefixed, en Debian deed dan allemaal patches toepassen op 3.0.

Mijn probleem met Debian is duidelijk. Mensen blijven op Xorg steken, die wordt niet meer onderhouden, maar diezelfde doelgroep zeurt dan wel als een ontwikkelaar zegt zich enkel te focussen op Wayland bijvoorbeeld. Daar is ook nog genoeg mis mee, maar het is vrijwel identiek aan Xorg en alternatieven bestaan ook. Gelukkig heeft Debian ook een unstable flow, maar dan kan je het zo goed overstappen op iets anders, want die worden vrijwel niet getest.

Ik snap waarom Debian bestaat, het is voor mensen die hun systemen nooit willen rebooten, Wayland pas willen hebben als het echt niet anders kan, Gnome libadwaita wordt teruggedraaid, KDE stopt met experimentele features als HDR, Rust is overkill, .. de doelgroep van Debian ken ik maar al te goed: Verandering is moeilijk, als het werkt laat het met rust. Ze vergeten daarbij dat een version freeze echt niet iets meer stabiel maakt. Koop maar eens een nieuwe laptop, en installeer daar dan Debian Stable op, de helft gaat niet werken.. kennelijk is dat stabiliteit?

Voor containers vind ik Debian super, voor desktop users snap ik het totaal niet. Maar zo te lezen ligt dat inderdaad aan mij. :)

[ Voor 12% gewijzigd door HollowGamer op 14-02-2026 10:57 ]

[Hero of Time]

@HollowGamer, het is al duidelijk, enorm bord voor je kop en oogkleppen op. Kom eens met bronnen van wat je nu beweert. Rust overkill? Ze gaan eisen dat apt juist Rust gebruikt. Zie https://www.phoronix.com/news/Debian-APT-Will-Require-Rust.

Dus stop even met onzin uitkramen aub. Je hebt duidelijk geen idee waar je het over hebt.

[HollowGamer]

Hero of Time schreef op zaterdag 14 februari 2026 @ 10:56:
@HollowGamer, het is al duidelijk, enorm bord voor je kop en oogkleppen op. Kom eens met bronnen van wat je nu beweert. Rust overkill? Ze gaan eisen dat apt juist Rust gebruikt. Zie https://www.phoronix.com/news/Debian-APT-Will-Require-Rust.

Dus stop even met onzin uitkramen aub. Je hebt duidelijk geen idee waar je het over hebt.

Heb je de mailinglist en ook comments erover gelezen (vooral die op Phoronix)? Mijn punt was niet dat Debian ontwikkelaars dat willen doen, de doelgroep ervan (dus ook gewoon users) maken zich zorgen of alles dan nog wel werkt als daarvoor.

[RobertMe]

Als Debian gebruikers geen Rust willen dan moeten ze uberhaupt geen Linux gebruiken. Immers zit Rust nu al experimenteel in de Linux kernel en vanaf 7.0 is het experimenteel stickertje er ook vanaf.

Daarnaast meen ik dat Debian sid nog steeds getest wordt? (/updates getest worden voordat ze in sid komen). Iets wat van Arch niet valt te zeggen (alleen core packages en grote updates (Python bv) gaan via de testing repos).

Overigens kan ik mij in de afgelopen 15 jaar dat ik Arch gebruik niet herinneren dat zaken stuk gingen "door Arch". En ook het aantal algemene bugs door steeds bleeding edge te draaien valt reuze mee (/"valt bijna niet op" / zeer zeldzaam dat ik issues heb). Daarmee wil ik niet zeggen dat alles altijd perfect werkt, maar voornamelijk dat ik mij geen concrete voorbeelden meer kan herinneren. Laatste serieuze was continu gezeik met de AMD GPU + USB-C. Dat tot (grafische) crashes / hangs leide bij het (un)pluggen van de USB-C monitor. Maar daar heb ik wellicht ook al een jaar geen last meer van. En ik vraag mij af of dat een bleeding edge issue was of puur een "hardware is te nieuw en werkt niet lekker" issue en dus ook op oudere software niet zou werken.

Edit:
Overigens doe ik Arch op desktop en laptop ook al jaren updaten zoals Debian op mijn servers. Eens in de X weken/maanden. Leidt maar zeer zelden tot issues / vragen (eens per zoveel maanden of wellicht zelfs jaar) waarbij ik even op de site moet kijken wat verwacht wordt bij een bepaalde update. Het is dus zeker niet zo dat je dagelijks moet updaten om problemen te voorkomen.

[ Voor 13% gewijzigd door RobertMe op 14-02-2026 11:14 ]

[surcharge]

Ik snap de haat naar rust niet zo. Het is maar een programmeertaal. Met als voordeel ten opzichte van C is dat een bug niet betekend dat je automatisch het hele systeem kan overnemen en dat duidelijk geannoteerd wordt of je exclusief of gedeelde toegang hebt tot data. Dit wordt afgedwongen terwijl je de code schrijft, in plaats van dat je er jaren later achter komt terwijl het niet meer vers in je geheugen zit.

[HollowGamer]

surcharge schreef op zaterdag 14 februari 2026 @ 11:35:
Ik snap de haat naar rust niet zo. Het is maar een programmeertaal. Met als voordeel ten opzichte van C is dat een bug niet betekend dat je automatisch het hele systeem kan overnemen en dat duidelijk geannoteerd wordt of je exclusief of gedeelde toegang hebt tot data. Dit wordt afgedwongen terwijl je de code schrijft, in plaats van dat je er jaren later achter komt terwijl het niet meer vers in je geheugen zit.

Het is een verandering, net zoals Typescript bij JavaScript, daar was ook haat en verwarring bij.

Iedereen heeft niets met TS, maar snapt ook dat het daardoor stukken veiliger en duidelijker is wat iets teruggeeft en kan doen.

Zoals gezegd zitten Debian gebruikers vaak daar niet op te wachten (lees de comments maar eens daar). Het is een verandering en het kan dus zijn dat iets het niet meer doet of kan, maar wel juist veel beter, efficiënter en veiliger is.

[surcharge]

De grootste terechte kritiek op rust in debian is het gebrek aan ondersteuning voor hardware. In de lange tijd dat C gebruikt werd, is het mogelijk geworden om die op bijna alle platforms te draaien via GCC. Dit is helaas niet het geval voor rust, waarbij GCC qua ondersteuning enorm achterloopt en je moet terugvallen op LLVM's beperktere ondersteuning.

[RobertMe]

HollowGamer schreef op zaterdag 14 februari 2026 @ 14:14:
[...]

Het is een verandering, net zoals Typescript bij JavaScript, daar was ook haat en verwarring bij.

Iedereen heeft niets met TS, maar snapt ook dat het daardoor stukken veiliger en duidelijker is wat iets teruggeeft en kan doen.

Uhm... Typescript vs JavaScript vergelijken met Rust vs ??? (C?) loopt wel heel erg manco. TypeScript an zich is geen volledige programmeertaal. Het is meer wat syntatic sugar over JavaScript heen. En TS heeft ook geen runtime, TS voer je uit door het te transpilen naar JS en daarna wordt het gewoon door een JS runtime uitgevoerd.

Je zou TypeScript vs JavaScript niet eens kunnen vergelijken met bv F# vs C# vs VB.NET, of Java vs Kotlin vs Scala. Want die 6 zijn allemaal volwaardige talen dir door een eigen compiler heen gaan, alleen resulteert die compiler of in MSIL of in ??? (Java bytecode) en worden beide varianten uitgevoerd binnen dezelfde runtime (.NET something something en de JVM). En zelfs dat is bij TypeScript niet aan de orde, want de TypeScript "compiler" zet TS code om naar JavaScript code, niet naar een of andere bytecode, laat staan assembly zoals bij Rust of C het geval is.

[HollowGamer]

RobertMe schreef op zaterdag 14 februari 2026 @ 14:31:
[...]

Uhm... Typescript vs JavaScript vergelijken met Rust vs ??? (C?) loopt wel heel erg manco. TypeScript an zich is geen volledige programmeertaal. Het is meer wat syntatic sugar over JavaScript heen. En TS heeft ook geen runtime, TS voer je uit door het te transpilen naar JS en daarna wordt het gewoon door een JS runtime uitgevoerd.

Je zou TypeScript vs JavaScript niet eens kunnen vergelijken met bv F# vs C# vs VB.NET, of Java vs Kotlin vs Scala. Want die 6 zijn allemaal volwaardige talen dir door een eigen compiler heen gaan, alleen resulteert die compiler of in MSIL of in ??? (Java bytecode) en worden beide varianten uitgevoerd binnen dezelfde runtime (.NET something something en de JVM). En zelfs dat is bij TypeScript niet aan de orde, want de TypeScript "compiler" zet TS code om naar JavaScript code, niet naar een of andere bytecode, laat staan assembly zoals bij Rust of C het geval is.

Ik vergelijk de taal niet, het enige is dat ik zeg dat de ene strikter is dan de ander. Dus dat je in beide een verandering hebt van hoe je programmeert. Dus ja, TS != Rust. Het principe is ongeveer het zelfde.

[RobertMe]

HollowGamer schreef op zaterdag 14 februari 2026 @ 15:28:
[...]

Ik vergelijk de taal niet, het enige is dat ik zeg dat de ene strikter is dan de ander. Dus dat je in beide een verandering hebt van hoe je programmeert. Dus ja, TS != Rust. Het principe is ongeveer het zelfde.

Nee. Het principe is niet hetzelfde. TS is gewoon JS maar stricter. Rust is een van de grond af aan opgebouwde programmeertaal, met een eigen standaard library, tooling, .... Rust geeft echt veel meer verschillen dan alleen maar "stricter". Dus ja, bij TS kan er weerstand zijn omdat iemand niet op de strictness zit te wachten en dan heeft TS 0,0 voordelen. Rust is iets totaal anders dan C/C++ dat veel meer voordelen heeft dan alleen maar "strict".

[HollowGamer]

RobertMe schreef op zaterdag 14 februari 2026 @ 16:41:
[...]

Nee. Het principe is niet hetzelfde. TS is gewoon JS maar stricter. Rust is een van de grond af aan opgebouwde programmeertaal, met een eigen standaard library, tooling, .... Rust geeft echt veel meer verschillen dan alleen maar "stricter". Dus ja, bij TS kan er weerstand zijn omdat iemand niet op de strictness zit te wachten en dan heeft TS 0,0 voordelen. Rust is iets totaal anders dan C/C++ dat veel meer voordelen heeft dan alleen maar "strict".

Het is een verandering toch t.o.v. de vorige situatie?

[synoniem]

HollowGamer schreef op zaterdag 14 februari 2026 @ 10:50:
[...]

Op dit moment draai ik helemaal geen Arch Linux, dus die woorden zou ik terugnemen. Momenteel draai ik Fedora op al mijn devices, waarvan sommige de Ublue stable images (het is Fedora, maar met drivers voor NVIDIA included).

Fedora is wat mij betreft de sweetspot. Je pushed redelijk op tijd updates, maar pas met een nieuwe release, ga je over op iets nieuws.

Dus ik ben helemaal geen Arch fanboy. Heb het jaren gedraaid, maar ik ben nu wel klaar met al dat tweaken en te veel zelf doen. Zelf heb ik nooit instabiliteit ervaren op Arch. Sterker nog, met backports van Debian/Ubuntu had ik juist issues, aangezien zij dus een fix hadden toegepast op een oudere versie. Dat was ook raar voor de developer, die zei het in 3.1.1 te hebben gefixed, en Debian deed dan allemaal patches toepassen op 3.0.

Mijn probleem met Debian is duidelijk. Mensen blijven op Xorg steken, die wordt niet meer onderhouden, maar diezelfde doelgroep zeurt dan wel als een ontwikkelaar zegt zich enkel te focussen op Wayland bijvoorbeeld. Daar is ook nog genoeg mis mee, maar het is vrijwel identiek aan Xorg en alternatieven bestaan ook. Gelukkig heeft Debian ook een unstable flow, maar dan kan je het zo goed overstappen op iets anders, want die worden vrijwel niet getest.

Ik snap waarom Debian bestaat, het is voor mensen die hun systemen nooit willen rebooten, Wayland pas willen hebben als het echt niet anders kan, Gnome libadwaita wordt teruggedraaid, KDE stopt met experimentele features als HDR, Rust is overkill, .. de doelgroep van Debian ken ik maar al te goed: Verandering is moeilijk, als het werkt laat het met rust. Ze vergeten daarbij dat een version freeze echt niet iets meer stabiel maakt. Koop maar eens een nieuwe laptop, en installeer daar dan Debian Stable op, de helft gaat niet werken.. kennelijk is dat stabiliteit?

Voor containers vind ik Debian super, voor desktop users snap ik het totaal niet. Maar zo te lezen ligt dat inderdaad aan mij. :)

Dat er een vocale groep users op een mailinglist zit zegt niet zoveel natuurlijk. Ik draai zelf geen bleeding edge hardware dus de behoefte aan een bleeding edge distro heb ik niet. Mijn daily driver draait op Debian en het boeit mij niets of die xorg of wayland gebruikt sterker nog ik weet geeneens wat die draait. En mijn servers zijn allemaal headless dus daar staat geen van beide op geïnstalleerd. Ik ben al sinds ik Red Hat gedraaid heb op een Dec Alpha machine geen fan van Red Hat en derivaten zeker niet na de overname door IBM. Een commercieel bedrijf dat puur voor aandeelhoudersbelang gaat is nu eenmaal wat anders dan een stichting die een distro onderhoudt.

[Shinji]

Mijn issue met de kleuren van chromium hebben zich vanzelf opgelost overigens, ik denk de update naar chromium 144 of een Fedora update ergens.

[HollowGamer]

Shinji schreef op zondag 1 maart 2026 @ 09:25:
Mijn issue met de kleuren van chromium hebben zich vanzelf opgelost overigens, ik denk de update naar chromium 144 of een Fedora update ergens.

Zit je toevallig ook op KDE? Het is een bug in het Wayland Color protocol.

[Shinji]

HollowGamer schreef op zondag 1 maart 2026 @ 09:26:
[...]

Zit je toevallig ook op KDE? Het is een bug in het Wayland Color protocol.

Yes! Maar ben blij dat het is opgelost, was lastig leesbaar af en toe.

[HollowGamer]

Shinji schreef op zondag 1 maart 2026 @ 10:06:
[...]


Yes! Maar ben blij dat het is opgelost, was lastig leesbaar af en toe.

Ik heb het helaas nog steeds, stukken minder, maar het lijkt hier en daar nog wat bugs te hebben.

[L0g0ff]

Ik dacht dat het een issue op mijn systeem. Maar ik had een build terug moeten zetten deze week naar naar een oudere versie. Vanwege een upstream issue in freeipa. SELinux blokkeerde daarna de rpm-ostree layer.

https://bugzilla.redhat.com/show_bug.cgi?id=2332433

Door de rollback was ook het kleuren issue opgelost. Maar ik had het voornamelijk in signal desktop.

Maar is het issue met wayland color nu opgelost? Anders blijf ik nog een weekje plakken.

Is er een issue tracker?

[Reveal!]

Vraag hoop dat iemand het weet, ik draai nu Omarchy (Arch Linux)
Erg tevreden over en ook gaming werkt vrij goed tot nu toe.
Maar bij ARC Raiders valt het op dat de FSR Frame gen optie ontbreekt (ook in het menu)
Ik heb een 9070XT, hoe kan je frame gen enablen?
FSR 4 upgrade lijkt het wel te doen.

[himlims_]

Reveal! schreef op maandag 2 maart 2026 @ 08:22:
Vraag hoop dat iemand het weet, ik draai nu Omarchy (Arch Linux)
Erg tevreden over en ook gaming werkt vrij goed tot nu toe.
Maar bij ARC Raiders valt het op dat de FSR Frame gen optie ontbreekt (ook in het menu)
Ik heb een 9070XT, hoe kan je frame gen enablen?
FSR 4 upgrade lijkt het wel te doen.

heb je TAAU (?) die doet bij mij 10-15fps meer dan FSR/DLSSR

[HollowGamer]

L0g0ff schreef op zondag 1 maart 2026 @ 16:35:
Ik dacht dat het een issue op mijn systeem. Maar ik had een build terug moeten zetten deze week naar naar een oudere versie. Vanwege een upstream issue in freeipa. SELinux blokkeerde daarna de rpm-ostree layer.

https://bugzilla.redhat.com/show_bug.cgi?id=2332433

Door de rollback was ook het kleuren issue opgelost. Maar ik had het voornamelijk in signal desktop.

Maar is het issue met wayland color nu opgelost? Anders blijf ik nog een weekje plakken.

Is er een issue tracker?

Het beste is gewoon blijven gebruiken, bij mij was alles met de laatste updates vrijwel opgelost (behalve soms wat issues uit slaapstand - die ook gefixed moeten zijn nu). Omdat het Wayland Color protocol V2 vrij nieuw is, moeten nu apps/developers mogelijk wat fixes pushen.

Je kunt de Chromium bug tracker checken, al vind ik het een van de meest complexe trackers die ik ken lol.

[ Voor 6% gewijzigd door HollowGamer op 02-03-2026 11:50 ]

[HollowGamer]

himlims_ schreef op maandag 2 maart 2026 @ 08:38:
[...]

heb je TAAU (?) die doet bij mij 10-15fps meer dan FSR/DLSSR

Is dit een Steam ding? Op de Steam Deck weet ik dat je dit kan forceren. Zit dit niet de Proton versie?

[himlims_]

HollowGamer schreef op maandag 2 maart 2026 @ 11:49:
[...]

Is dit een Steam ding? Op de Steam Deck weet ik dat je dit kan forceren. Zit dit niet de Proton versie?

geen idee, ik snap geen drol van die kunstmatige FPS, klik een beetje en kijk of verschil maakt. bij mij werkt die TAAU (icm bazzite/steamos) voor ARC-raiders beter dan DLSS

[HollowGamer]

himlims_ schreef op maandag 2 maart 2026 @ 11:52:
[...]

geen idee, ik snap geen drol van die kunstmatige FPS, klik een beetje en kijk of verschil maakt. bij mij werkt die TAAU (icm bazzite/steamos) voor ARC-raiders beter dan DLSS

Op Bazzite zit dat dacht ik in de Proton versie die ze gebruiken. Geen idee of dat klopt, het is wel iets dacht ik dat een patch nodig had.

Voor mij maakt het nog weinig verschil op de SD. Forza Horizon 5 draait even snel, niet betere fps of beeld.

[himlims_]

TAAU = Unreal Engine specifiek (weer wat geleerd)

Temporal Anti-Aliasing Upsampling (TAAU) is an Unreal Engine rendering technique that improves performance and image quality by upscaling lower-resolution frames. It functions as a form of spatial upscaling combined with TAA, which is used on Linux systems for rendering games, sometimes in conjunction with AMD GPU sharpening.

volgens mij klopt de ubb ....

misschien maar weer eens linux gaming distro op de game-bak zetten, met windows-11 is de FPS in games er niet bepaald op vooruit gegaan. helaas is aantal games nog niet in verhouding. (ctrl+a gedaan in steam, en dan rechtermuis 'install')

[ Voor 102% gewijzigd door Hero of Time op 02-03-2026 19:31 . Reden: doe geen \ voor de [ van de tag, dat gaat dan stuk ;) ]

[True]

himlims_ schreef op maandag 2 maart 2026 @ 12:27:
TAAU = Unreal Engine specifiek (weer wat geleerd)

[quote]Temporal Anti-Aliasing Upsampling (TAAU) is an Unreal Engine rendering technique that improves performance and image quality by upscaling lower-resolution frames. It functions as a form of spatial upscaling combined with TAA, which is used on Linux systems for rendering games, sometimes in conjunction with AMD GPU sharpening.[/quote]

volgens mij klopt de ubb ....

misschien maar weer eens linux gaming distro op de game-bak zetten, met windows-11 is de FPS in games er niet bepaald op vooruit gegaan. helaas is aantal games nog niet in verhouding. (ctrl+a gedaan in steam, en dan rechtermuis 'install')

offtopic:
Je hebt een backslash voor je quote open en quote sluit tags dan werkt het niet.

[Hero of Time]

Heb de quote maar gefixt voor 'm.

[True]

Hero of Time schreef op maandag 2 maart 2026 @ 19:32:
Heb de quote maar gefixt voor 'm.

Held.

[L0g0ff]

Ik moest vandaag even een fortigate ipsec vpn testen voor een klant. Blijkbaar zit dat als sinds 2022 in de Windows vpn cliënt maar in 2026 nog steeds niet in de linux vpn cliënt. Dus ik start winboat en maak verbinding met mijn Windows 11 vm die een maand of 2 niet gestart had. Installaties beginnen te draaien van o.a. een citrix cliënt die erop stond, Windows updates begonnen te lopen, ik kreeg fortigate niet installed vanwege de achtergrond installatie van citrix, ram gebruik blies op, cpu's hard aan het werk, fans beginnen te blazen en dan weet je het weer. Windows voor desktop is eigenlijk echt waardeloos. Voor windows server OS ben ik best nog wel redelijk tevreden. Dat is wanneer je controle hebt over het update proces en de 3e party apps. Maar Windows desktop is echt waardeloos. Eigenlijk snap je niet dat er zoveel Windows fans zijn. Elk stukje software op een Windows desktop claimt je aandacht en wil in je startup om CPU en mem te claimen.

En dan besef je het echt. Nooit meer terug.

[Hero of Time]

Huh? Hoezo zou je niet met Linux standaard IPSec naar een FG kunnen maken? Heb je wel Libreswan of Strongswan geïnstalleerd staan? Want ik heb vorig jaar nog IPSec dial-up verbinding getest op m'n werklaptop, met Linux. Werkte gewoon. En heb ook met Linux een site-2-site opgebouwd naar een Fortigate. Enige wat je moet weten zijn de cipher suites en of er PFS wordt gebruikt en welke groep dat is.

[L0g0ff]

Hero of Time schreef op donderdag 5 maart 2026 @ 22:05:
Huh? Hoezo zou je niet met Linux standaard IPSec naar een FG kunnen maken? Heb je wel Libreswan of Strongswan geïnstalleerd staan? Want ik heb vorig jaar nog IPSec dial-up verbinding getest op m'n werklaptop, met Linux. Werkte gewoon. En heb ook met Linux een site-2-site opgebouwd naar een Fortigate. Enige wat je moet weten zijn de cipher suites en of er PFS wordt gebruikt en welke groep dat is.

Klopt ja. Libreswan of strongswan moet je hebben. Maar dit ging om een stukje testen en documentatie voor een klant. Dan wil ik eerst de native tools werkend gezien hebben voordat ik met alternativen aan de gang ga.

[Hero of Time]

En OpenConnect deed het niet? Sowieso, NetworkManager heeft plugins voor de twee 'Swan opties, zodat je niet een eigen config moet maken e.d. Dat is hoe ik het aan de praat had, als ik al iets daarvan had geïnstalleerd. Heb nou niet echt op m'n netvlies staan wat ik precies op m'n laptop heb geïnstalleerd.