/u/79245/gentoomf_icon.png?f=community){kind=icon}
:strip_icc():strip_exif()/u/48952/Ultraman-60x60-Ray-Animated.jpg?f=community)
Wat leuk om te zien dat een dermate oude driver module voor een erg oud kaartje toch nog een patch krijgt
Laat ik de 3c509 nou net gebruiken in een antiek systeempje hier. Even kijken of die zijn heeft om weer anderhalf uur lang een kernel te bakken
Als je stil blijft staan, komt de hoek wel naar jou toe.
Heeft dat systeem een EISA bus dan?:
[...]
Wat leuk om te zien dat een dermate oude driver module voor een erg oud kaartje toch nog een patch krijgt
Laat ik de 3c509 nou net gebruiken in een antiek systeempje hier. Even kijken of die zijn heeft om weer anderhalf uur lang een kernel te bakken
:strip_icc():strip_exif()/u/6754/image.jpg?f=community)
3c509 FTW! idd best geinig om te zien dat zulke ouwe meuk toch nog aandacht krijgt:
[...]
Wat leuk om te zien dat een dermate oude driver module voor een erg oud kaartje toch nog een patch krijgt
Laat ik de 3c509 nou net gebruiken in een antiek systeempje hier. Even kijken of die zijn heeft om weer anderhalf uur lang een kernel te bakken
Nu met Land Rover Series 3 en Defender 90
:strip_icc():strip_exif()/u/2269/icon-kerst.jpg?f=community){kind=icon}
:strip_icc():strip_exif()/u/96747/gnu_linux_poster_60.jpg?f=community)
"You smell that, son? What sir? Napalm, I love the smell of napalm in the mornin!" || Children of Bodom fan!
* Ultraman gaat 2.6.16 even binnenslepen en compileren op een oud testbakje 
Heeft toch een nieuwe kernel nodig en dan heb ik gelijk die patch voor de 3c509.
Ben benieuwd hoe lang de compilatie gaat duren...
Heeft toch een nieuwe kernel nodig en dan heb ik gelijk die patch voor de 3c509.
Ben benieuwd hoe lang de compilatie gaat duren...
Als je stil blijft staan, komt de hoek wel naar jou toe.
Verwijderd
Ik draai Debian Testing, maar -zo- vaak kom je nou ook weer niet nieuwe kernels tegen. Recent kwam wel 2.6.15 binnen (bij mij een paar keer zelfs als identieke versie), maar de voorgaande was 2.6.12. Vergeleken met Debian Stable is het relatief natuurlijk wel vaak, want daar komt gewoon -geen- nieuwe kernel versie voor tussen de major releases.:
[...]
Ik run Debian Testing en Unstable en dan kom je regelmatig nieuwe kernels tegen.
Even op gevoel komt bij Debian Testing zo elke 4 maanden een kernel update.
Verwijderd
Zal best. Unstable is leuk om in een VM of aparte bak erbij te draaien en even te spieken wat er binnenkort allemaal naar je desktop gaat komen. Laatst nog was gnome bijvoorbeeld nog totaal broken in unstable, dat is dus niet iets wat je ook maar voor prive 'computeren' (mail, surfen etc) wil draaien
Nouja daar ben ik het niet mee eens.:
[...]
Zal best. Unstable is leuk om in een VM of aparte bak erbij te draaien en even te spieken wat er binnenkort allemaal naar je desktop gaat komen. Laatst nog was gnome bijvoorbeeld nog totaal broken in unstable, dat is dus niet iets wat je ook maar voor prive 'computeren' (mail, surfen etc) wil draaien
Ik draai testing al een aardige tijd op mijn normale werkpc en dat gaat prima. Natuurlijk moet je de updates goed in de gaten houden en wil het gebroken zijn dan ga je terug en hou je die pakketten on hold totdat het probleem is opgelost... Maar wanneer er veel pakketten gebroken zijn dan is dat in mijn ervaring vrij snel weer gefixed.
Elke dag dronken is ook een geregeld leven.
Verwijderd
Uhm, lees je nu verkeerd of maak je hierboven een typo?
Ik had het over UNSTABLE
Zelf draai ik ook testing als mijn normale config voor mijn werk PC (development). De 'huiskamer' PC (surfen en emailen) is een Windows bak. Ik vind de stabiliteit van testing ongeveer gelijk aan Windows grofweg. Ondanks de naam zie ik testing als het 'gewone' OS voor de werk of prive desktop. Stable is (IMHO) alleen nodig voor servers, en unstable voor als je zelf Linux software developped en wilt testen.
2.6.16 is er al een tijdje
Is er een reden om dan 2.6.15.7 te gaan doen?
Als je stil blijft staan, komt de hoek wel naar jou toe.
Ja. Er zijn toch ook nog 2.4 releases terwijl 2.6 er al is?:
[...]
2.6.16 is er al een tijdje
Is er een reden om dan 2.6.15.7 te gaan doen?
Das wel een heel groot verschil dan wat Cybersteef bedoelde
[ Voor 3% gewijzigd door webfreakz.nl op 29-03-2006 14:17 ]
"You smell that, son? What sir? Napalm, I love the smell of napalm in the mornin!" || Children of Bodom fan!
Maar dan praat je ook echt over een wezenlijk verschil.
Is het serieus nuttig om 2.6.15.7 te gebruiken als 2.6.16 gewoon normaal beschikbaar is?
Ik heb verder geen changelogs door zitten nemen maar ik mag aannemen dat 2.6.16 dezelfde wijzigigen/fixes/features bevat als 2.6.15.7. Toch?
Als je stil blijft staan, komt de hoek wel naar jou toe.
Denk het niet, aangezien het niet logisch is dat 2.6.16 ooit nog aangepast wordt? Het is die uitgave en die zal over 100 jaar nogsteeds hetzelfde zijn? Uiteraard 2.6.16.x wél maar je snapt wat ik bedoel
[ Voor 24% gewijzigd door webfreakz.nl op 29-03-2006 14:23 ]
"You smell that, son? What sir? Napalm, I love the smell of napalm in the mornin!" || Children of Bodom fan!
Dat lijkt me niet.:
Maar dan praat je ook echt over een wezenlijk verschil.
Is het serieus nuttig om 2.6.15.7 te gebruiken als 2.6.16 gewoon normaal beschikbaar is?
Ik heb verder geen changelogs door zitten nemen maar ik mag aannemen dat 2.6.16 dezelfde wijzigigen/fixes/features bevat als 2.6.15.7. Toch?
Nadat 2.6.15 gereleased is worden er geen features meer aan toegevoegd (gok ik). Daar heb je dus 2.6.16 voor nodig. Er worden echter nog wel (kritieke) bugs gefixed.
Voor gebruikers die niet het risico willen lopen op extra bugs door die nieuwe features is dus 2.6.15.
Hmm ja het puntje van Olaf kan ik helemaal volgen
Als je stil blijft staan, komt de hoek wel naar jou toe.
/u/5838/nos-meeting-54-icon.png?f=community){kind=icon}
Hij heeft wel gelijk, het nut van 2.6.15.7 is dat er geen nieuwe "experimentele" dingen aan toegevoegd worden die nog niet zoveel getest zijn.:
Hmm ja het puntje van Olaf kan ik helemaal volgen
(al is alles wat in de mailline kernel komt al behoorlijk goed getest in bijvoorbeeld -mm kernels)
Heeft sinds kort zijn wachtwoord weer terug gevonden!
:strip_icc():strip_exif()/u/75828/sid.jpg?f=community)
Verwijderd
Toevallig dat je dat zegt, want ik merk zonet dat mijn geluid op de laptop niet meer werkt... (kernel 2.6.16-ck5).:
Nog altijd geen patch voor de hda-intel module blijkbaar.
Is dit een bug in 2.6.16?
:strip_icc():strip_exif()/u/154021/razr-icon.jpg?f=community){kind=icon}
IMHO heeft het geen zin om steeds updates te posten voor een kleine update van 2.6.16.13 naar 2.6.16.14. Die kernel mensen releasen sneller kernels dan onze package maintainer ze kan packagen en uploaden 
:strip_icc():strip_exif()/u/19241/2.jpg?f=community)
:strip_icc():strip_exif()/u/49396/icoon.jpg?f=community)
:strip_exif()/u/26373/anim4.gif?f=community)
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
:strip_exif()/u/19799/lotr01_6060.gif?f=community)
:strip_icc():strip_exif()/u/6697/gerco-icon.jpg?f=community){kind=icon}
- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!
/u/27682/icon2.png?f=community)
/u/12038/crop5a51514a4dec1_cropped.png?f=community)
Dat nVidia en VMWare bokken is geen technische maar juridische issue. En dat is ook direct waarom er geen officiele Debian packages zijn. Van nVidia mag het repackaged worden, maar Debian wil niets hebben wat incompatibel is met de licentie van de kernel. Andere distro's zijn minder streng wat dat betreft. Met Gentoo kan ik op mijn bakken met nVidia videochip gewoon het volgende doen:
code:
1
| make && make modules_install && emerge nvidia-drivers && cp arch/i386/boot/bzImage /boot/kernel-x.x.x |
Dan breekt niets. Maar het probleem zit gewoon in een paar bedrijven die weigeren mee te doen aan de standaardmethodes van het OS. Gelukkig is er op videogebied waarschijnlijk binnenkort meer beweging aangezien Intel (videochipfabrikant #1 als je alle integrated meuk meetelt) source gereleased heeft van hun driver en AMD aangegeven heeft ATi's policy van closed drivers te heroverwegen
VMWare moet vooral oppassen voor Xen - Xen is ondertussen best volwassen en werkt uiteraard wel volledig samen met de kernel. Misschien iets om uit te proberen?
Ja, die is er: modules moeten gewoon tegelijk met kernel gecompileerd worden.
Euh, microkernels waren anno 1991 hot (vooral dankzij Tanenbaum), maar de enige vorm waarin ze bruikbaar geworden zijn in de mainstream is met een monster van een monolithische service module erboven die voor applicaties er verdacht uitziet als een monolithische kernel (cf. Darwin met een Mach microkerneltje). Maar de micro<>monolithische discussie staat hier gewoon los van. Als je een GNU/Hurd port van de nVidia drivers zou hebben zou je tegen hetzelfde aanlopen. Linus heeft gekozen voor een interface op sourceniveau, niet eentje op binary niveau. Dat werkt prima met alle modules die als source aangeboden worden en *is* gewoon practisch...
Oslik blyat! Oslik!
het punt is gewoon dat als je BLOBs gebruikt je afhankelijk bent van de leverancier van die BLOBs. Ook onder windows, maar daar past iedereen zich er volledig aan aan, inclusief alle nadelen. Windows is om oa die reden veel minder flexibel, en is de afgelopen jaren veel minder hard gegroeid dan bijvoorbeeld Linux.
Wat jij eigenlijk wilt is dat de kernel devvers support op zich nemen voor BLOBs die door anderen uitgegeven zijn. Dat ze iedere keer dat ze iets veranderen kijken of t nog wel werkt met al die BLOBs. Wat is het voordeel voor die kernel devvers? zij willen gewoon een goede kernel maken, en als dat betekent dat ie niet compatibel is met de vorige release dan is dat zo.
De verantwoordelijkheid voor een goed systeem, met onderdelen die elkaar kennen, ligt bij de distributie. Dus biedt bijvoorbeeld ubuntu de mogelijkheid om allerlei modules te installeren. Als je die gebruikt moet je er vanuit kunnen gaan dat het ook na een update werkt allemaal.
Maar nogmaals, ik zie echt het probleem niet. Mensen die er verstand van hebben doen t goed, mensen die er geen verstand van hebben ook, het gaat alleen mis bij mensen die er een beetje verstand van hebben, maar zichzelf niet goed kunnen inschatten. De vrijheid om je systeem te mollen als je dat perse wilt hoort ook bij Linux
Wat jij eigenlijk wilt is dat de kernel devvers support op zich nemen voor BLOBs die door anderen uitgegeven zijn. Dat ze iedere keer dat ze iets veranderen kijken of t nog wel werkt met al die BLOBs. Wat is het voordeel voor die kernel devvers? zij willen gewoon een goede kernel maken, en als dat betekent dat ie niet compatibel is met de vorige release dan is dat zo.
De verantwoordelijkheid voor een goed systeem, met onderdelen die elkaar kennen, ligt bij de distributie. Dus biedt bijvoorbeeld ubuntu de mogelijkheid om allerlei modules te installeren. Als je die gebruikt moet je er vanuit kunnen gaan dat het ook na een update werkt allemaal.
Maar nogmaals, ik zie echt het probleem niet. Mensen die er verstand van hebben doen t goed, mensen die er geen verstand van hebben ook, het gaat alleen mis bij mensen die er een beetje verstand van hebben, maar zichzelf niet goed kunnen inschatten. De vrijheid om je systeem te mollen als je dat perse wilt hoort ook bij Linux
It sounds like it could be either bad hardware or software
/u/92525/me.png?f=community)
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
-zucht- Ik had kunnen weten dat je meteen op Java zou gaan hameren als ik dat als voorbeeld zou gaan gebruiken.
Plug-in systemen zijn net zo goed van toepassing op applicaties die in C/C++ zijn geschreven. Jaren geleden heb ik eens in een project gewerkt waarbij we een workflow engine hadden gebouwd, waarbij concrete tasks via een plug-in systeem toegevoegd konden worden. Als compiler gebruikte we Intels icl.exe, maar de gebruikers konden ook gewoon Microsoft's cl.exe (in verschillende versies) gebruiken voor hun eigen tasks. Verzamelingen van tasks konden meteen gedownload worden en gebruikt, ook door niet technische gebruikers. Geen probleem... pfff.. binary compatibility...
Als jij je gebruikers wilt dwingen om een compilatie stap te moeten doen, dan zul je je in veel gevallen moeten beperken tot een technische markt. Wil je ook een meer mainstream markt aanspreken dan zul je -of- moeten zorgen dat die compilatie stap volledig transparant werkt (dwz, dat de de C/C++ runtime source bundles accepteerd en on-the-fly kan compilen en linken) OF dat je gewoon een binaire API hebt.
Ik snap dat het moeilijk voor je is om te begrijpen, maar een stabiele binaire API kan heel goed samengaan met open source; een module (lib) lever je binair aan. met daarnaast (of eventueel in het zelfde archive) de source. Dan heb je de best of both worlds: de source EN het gemak om je lib meteen te kunnen gebruiken.
Een wereldwijd compleet homogeen grid??? r u kidding!?
Ik heb een aantal jaren geleden op een globus 2 grid gewerkt. Zelfs met een beperkt aantal variabelen in je job request (architectuur + os) zit je al met een grote complexiteit. Jij wilt daar dan ook nog even een -exacte- software configuratie aan toevoegen? Weet je wel hoeveel nodes een wereldwijd grid kan hebben? Wil jij real-time, under load, voor alle nodes een software update gaan doen omdat gcc bij elke minor.minor [...] minor het nodig vind om weer de ABI te breken?
Zelfs op het relatief kleine grid waar ik toen op zat (512 nodes, verpreid over slechts 4 locaties) was het al een kleine ramp. Er zat toen niets anders op dan een hele zooi maar gewoon statisch te linken, iets wat niet helemaal de bedoeling was.
Heel erg practisch gezien wil zelfs die vriendin van jou trouwens een ABI; in firefox kun je leuke extentions direct via de interface downloaden en installeren. Er is hier geen gelegenheid om make in te tikken, dus heb je een... juist ja, ABI nodig
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
ik wil mijn gebruikers juist niet dwingen een compilatiestap te doen, ze hebben helemaal geen compiler als t aan mij ligt. En toch wil ik wel dat mijn gebruikers hun software binnen krijgen op een manier dat het helemaal bij *hun* systeem past. zelfs met patches om te zorgen dat het allemaal goed werkt binnen hun specifieke systeem. De developer hoeft zich namelijk helemaal niet druk te maken om het compileren, die moet gewoon code produceren. De packagers kiezen hoe ze de sources willen compilen, en stellen het binary beschikbaar aan hun gebruikers.
dan heb je niet het beste van de source wereld, er zijn al keuzes gemaakt die ik misschien wel anders zou maken.
Het idee bij grid computing is dat je je grid als een grote computer ziet. Zo raar is het toch niet om te verwachten dat de stukjes dan nog bij elkaar passen? je hoeft gcc helemaal niet te updaten als je gewoon overal dezelfde gebruikt en blijft gebruiken. wil je updaten, ja, dan moet je ze ook allemaal doen. C++ kan helemaal geen ABI hebben die op elk OS en elke architectuur hetzelfde is. binnen OS/architectuur zou kunnen, maar levert zo weinig op.
en dan moet ik maar hopen dat mijn vriendin dezelfde CPU heeft als de maker van de extension? Of heeft ze gewoon pech als ze op PPC draait, of Alpha, of MIPS? dit is ervan uitgaande dat die ABI zelfs over OS grenzen heen gaat, anders wordt het nog veel erger.Heel erg practisch gezien wil zelfs die vriendin van jou trouwens een ABI; in firefox kun je leuke extentions direct via de interface downloaden en installeren. Er is hier geen gelegenheid om make in te tikken, dus heb je een... juist ja, ABI nodig
Lijkt mij beter als ze bij firefox kiezen voor java, of python ofzo. Los je bijna alle OS/architectuur problemen mee op.
It sounds like it could be either bad hardware or software
Hehehe... het lijkt me vrij essentieel dat een developer tenminste 1 maal z'n eigen code compileerd, maar ik hoop dat je wat anders bedoeld
Opzich waar, maar zelfs in deze situatie wil je nog een stabiele ABI hebben. Wat als ik een gedeelte van mijn systeem wil updaten en niet alles? Als de vriendelijke mensen van mijn distributie besloten hebben om die packages met een nieuwe gcc te compileren, en die is weer afhankelijk van andere libs die opzich niet veranderd zijn, maar wel ge-hercompileerd, dan hang ik alsnog. Als het om major revisies gaat kan ik er af en toe mee weg komen door voor een specificiek programma een specificieke shared lib eerder in het path te zetten, maar deze truuk werkt niet altijd.
Dat snap ik niet. Je hebt een nette default in de vorm van een bin, en tevens de source voor als je het anders wilt doen en/of de source wilt bekijken.
En dat is gewoon praktisch niet mogelijk als je op een wereldwijde schaal werkt, met lokale clusters die niet in handen zijn van 1 organisatie maar door allemaal losse mensen wordt beheerd.
Technisch was slechts het architectuur/os onderscheid genoeg geweest. Helaas wilde (oa) gcc niet mee werken. Gebruik maar lekker wat anders dan zei men zo ongeveer, en dat is ook wat Globus (www.globus.org) heeft gedaan. Was het in 2.x nog een C implementatie, tegenwoordig zijn in Globus 4 alle of bijna alle interfaces in Java.
Of het er direct mee te maken heeft weet ik niet, dus mischien maak ik nu een onzin statement, maar ik zie ook dat onder Linux een groeiend aantal developpers mono/C# aan het gebruiken is.
Je kunt als monopolist (wat gcc op zijn gebied toch wel is) wel hier stoer je poot stijf houden, maar als de gebruikers (zowel developpers als end users) toch wat anders willen dan is je arrogatie maar zo lang vol te houden. Op een gegeven moment komt er of een alternatief of een fork. Dan kun je wel zeggen dat users je niks kunnen schelen en dat je alleen maar voor fun developped, maar geen enkele 'fun developper' vind het leuk om iets te maken wat door niemand meer gebruikt wordt. Zie oa xfree86.
C++ zelf is nog een heel ander verhaal, dat weer los staat van de versies van gcc. De C++ ABI moet er voor zorgen dat verschillende (linkers van) compilers elkaars modules/libs kunnen gebruiken. Hier is al zeer veel kritiek op geweest, en het dwingt je ook om in je C++ code C interfaces te gaan maken (extern "c"); een vrij onzinnige praktijk die ons developpers veel tijd kost.
Indirect zou dit wel helpen om het gcc team in toom te houden. Een dergelijke ABI spreek je namelijk af met alle compiler implementors en de maker(s) van de hardware architectuur. Gcc kan dan niet meer in z'n eentje even lekker de boel gaan breken, omdat dat pas kan na samenspraak met de anderen.
Ik ben me daar zeer wel van bewust. Vraag maar eens aan een mod met welk os en op welke architectuur ik hier post
Mischien wel ja, hoewel een concept als een "c/c++ source bundle" die real-time door de loader zou worden gecompileerd dmv een minimalistische in memory compiler chain ook zou kunnen werken. Voor een shared library moet een dynamische loader nu al allemaal truukjes gaan uithalen voor oa relocations en symbols. Lijkt me dat je hier uitstekend kunt opvangen dat als de loader alleen een (gestandaardiseerde) source bundle vindt, hij deze makkelijk voor de applicatie transparant kan compilen. Het mechanisme lijkt dat in zekere zin op het JIT compilation aspect van oa C# en Java, met het verschil dat het moment van compilen natuurlijk niet opeens de aard van de taal veranderd. Ook al zou de loader pas compilen, dat zal C/C++ dan niet opeens 'managed' maken.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
dat zou niet zo handig van die mensen van jouw distributie zijn, en blijkbaar voor jou een reden om over te stappen naar een andere distributie
mja, op zich maakt het natuurlijk niet zoveel uit, behalve dat je dan de lagen die ik net voorstel door elkaar laat lopen, mensen moeten doorhebben dat ze voor software bij de makers van hun distro moeten zijn. Kijk hoeveel mensen hun systeem mollen door zelf dingen te compileren terwijl een simpele apt-get install package hetzelfde doet, maar dan gegarandeerd goed.
blijkbaar wil gcc zich exclusief richten op ander gebruik, en als deze keuze betekent dat ze die andere dingen beter doen sta ik daar achter.
ondergetekende is er ook zo een
ik vind .NET een fantastische techniek, en ook strategisch heel prettig om mensen uit de windows wereld naar linux te helpen.de overgang van xfree naar xorg is toch een perfect voorbeeld hoe goed vrije software werkt? ik ben erg blij met de uitkomsten iig. Als er inderdaad voldoende vraag is naar deze features komt het er wel. Je hebt mij iig niet overtuigd om mee te doen aan je project
(ook omdat ik geen C kan trouwens)dat zie ik als een nadeel, ik wil graag dat gcc de best mogelijke techniek kiest, ook als ze daarvoor de ABI moeten veranderen. Ik heb daar nu geen last van omdat ik hoop dat de makers van mijn distro updates voor mijn distro gewoon dezelfde gcc blijven gebruiken, maar bij de volgende release werkt het dan beter.
waarom zo moeilijk doen als er talen zijn die dat allemaal overbodig maken? en die talen ook nog eens veel toegankelijker zijn dan C/C++? Kost je misschien wel wat performance, en de mogelijkheid om die plugins op elkaar te laten bouwen, maar dat is helemaal niet erg bij plugins?
It sounds like it could be either bad hardware or software
Ik heb nu kernel 2.6.18 nodig, hoe kan ik deze het beste op mijn machine krijgen?
ik draai debian unstable en zit nu op 2.6.17-2-686 deze heb ik zelf geupgraded. maar voor .18 zijn er nog geen kernel packages beschikbaar.
apt-get install linux-image-2.6.17-2-686
ik kan de kernel wel downloaden van kernel.org, maar hoe dan verder?
ik heb kernel .18 nodig voor mijn PVR-500 icm IVTV zie ook:
[KnoppMyth] Alleen ruis met PVR-500
https://f1nerd.nl
:strip_exif()/u/82743/oie_65db33670bfc783018710e4e78a7cf0251b.gif?f=community)
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
:strip_icc():strip_exif()/u/111342/crop59c23ae9896fe_cropped.jpeg?f=community)
| Olympus OM-D EM10 mk2 | m.Zuiko 14-42mm f/3.5-5.6EZ | m.Zuiko 40-150mm f/4-5.6 R | m.Zuiko 60mm f/2.8 | 2x Godox v860 | Godox X1 |
Verwijderd
Ik ben er niet zeker van of de persoon die oorspronkelijk met dit argument kwam nu alleen op de kernel doelde, of ook op de services en user applications er boven op. De scheidslijnen van wat 'kernel' is en wat niet zijn ook al meerdere keren heen en weer geschoven.
Daarnaast is het helemaal geen gek idee dat bepaalde delen van de kernel zichzelf runtime kunnen optimizen. Managed talen doen dit van huis uit en kunnen daarmee een hogere performance halen dan talen die eenmalig off-line gecompiled worden. Hier tussen in heb je ook nog de zogenaamde native recompilers. Deze gebruiken net als managed talen runtime informatie om het compilatie process real-time te sturen.
"Nooit niet, basta"... dat hebben door de gescheidenis al velen concervatieven mensen gezecht. Waarschijnlijk is er ooit wel eens een holenman geweest die dat zei over het gebruik van vuur. Als de wereld in handen was van mensen zoals jij zaten we nu nog in dat hol.
Wie zegt dat dat over 5 jaar nog zo is? Wie zegt dat er over 10 jaar niet een andere volledige open source C++ compiler gemaakt wordt die -wel- stabiel is?
Om nog even een andere bekende anekdote naast het al gegeven Motif voorbeeld te geven wat iets beter in deze context past:
Ooit, lang geleden vond men dat een operating system en haar kernel in het bijzonder alleen in assembly geschreven diende te worden. Een high-level taal gebruiken was domweg ondenkbaar. "Je wilt geen high-level taal in je kernel. nooit niet, basta.", dit werd toen inderdaad in bijna exact deze woorden gezegt.
Op een goede dag kwam daar een zekere Ritchie en Thompson die in weerwil van alle aards-conservative kernel hackers van toen, wel een high-level taal gingen gebruiken.
De rest van het verhaal ken je vast wel...
Verwijderd
Precies. Je hebt vast mijn post op de FP gelezen.
Het kwartje valt
Daarom kun je nu niet zo stellig zeggen dat Java (of andere managed taal) NOOIT in de kernel zal komen.Wel kun je leren van het verleden, juist door dingen in het perspectief van toen te zien. In 1973 was C high-level, of je nu wilt of niet. Iedereen die er verstand van dacht te hebben zei dat je geen operating system in een high-level taal kon bouwen, maar dat het low level moest (in 1973 dus assembly).
Vandaag de dag is C low-level en Java of C# high-level. Je ziet dat de geschiedenis zich herhaalt en dat men nu ook weer heel stellig zegt dat er geen high-level (nu dus java) in de kernel kan en dat het low-level moet (nu dus C).
In het algemeen zie je dat er conservatieven mensen zijn die altijd willen vasthouden aan de huidige werkwijze en dat er andere mensen zijn die vooruit willen en open staan voor nieuwe dingen. In 1973 waren gehele operating systemen assembly en dus dacht een groep dat het altijd assembly moest blijven. Nu zijn de meeste operating systemen C en heb je weer een groep mensen (zie reactie hierboven) die denkt dat het dus altijd C moet blijven.
[ Voor 18% gewijzigd door Verwijderd op 27-09-2006 23:46 ]
Verwijderd
Waarop basseer je dat dan exact? In 1965 werd er hier en daar ook al wel wat gepraat over operating systems in een high level taal, maar het duurde tot 1973 tot men er aan begon. Als je ziet dat er nu al mensen over praten om managed talen te gaan gebruiken en dat er zelfs al experimenten mee gedaan worden.
Denk jij dat over 10 jaar Linux nog volledig C is?
En over 20 jaar?
En over bloat, je kent het gezegde: "some call it bloat, I call it a feature"
Als je totaal geen bloat wilt dan moet je maar een real-time embedded kernel voor iets gaan ontwikkelen.
/u/2801/crop5ccb23f820755.png?f=community)
Precies de reden waarom de development fora op GoT voor mij nooit interessant geweest zijn
Ik kan geen PHP en Java meer zien.
"Logica brengt je van A naar B, verbeelding brengt je overal." - Albert Einstein
:strip_icc():strip_exif()/u/26770/crop579890778b812_cropped.jpeg?f=community)
Goede timing hebben ze, ben deze week op lokatie bij mijn servers en wil graag een *stable* kernel met de CFS scheduler gaan draaien, maar altijd toch zo fijn om erbij te zijn mocht er iets mis gaan . (Gelukkig hebben de meeste machines goede remote management, maar je zult altijd zien dat net eentje die dat niet heeft erop blijft hangen).
. (Gelukkig hebben de meeste machines goede remote management, maar je zult altijd zien dat net eentje die dat niet heeft erop blijft hangen).
/u/10874/sp.png?f=community)
Heeft iemand al de mogelijkheid gehad om CFS te benchen tegenover ck-sources en O(1) ? Ik ben wel benieuwd, maar ik zit nog te twijfelen of ik het wil backporten naar .20 op mijn laptop
Welke patches gooi je erover dan?:
2.6.23 werkt als stroop hier, maar misschien ligt dat wel aan de patches
Ik ben hem nu ook even aan het compilen.
Kamikaze patchset, al was die gisteren nog in progress (kamikaze1, ik heb er wat uit kamikaze0 en 1 gemixt). Ik haal er een beetje uit wat me interesseert.
Ik ga straks effe de timer van die fameuze 864 naar 1000 Hz zetten, en zien of dat iets oplevert. Mijn ervaringen met de laatste CK schedulers (2.6.20 en hoger) waren niet positief, CFS leek me jammer genoeg niet veel beter in dat opzicht. Met een beetje belasting voelt je PC als stroop, zeker met een transfer over het netwerk (NFS). Maar misschien ligt het dan ook wel weer aan NFS... Getest op een Turion64 TL-32 en een Core 2 Duo T7300.
Ik ga straks effe de timer van die fameuze 864 naar 1000 Hz zetten, en zien of dat iets oplevert. Mijn ervaringen met de laatste CK schedulers (2.6.20 en hoger) waren niet positief, CFS leek me jammer genoeg niet veel beter in dat opzicht. Met een beetje belasting voelt je PC als stroop, zeker met een transfer over het netwerk (NFS)
. Maar misschien ligt het dan ook wel weer aan NFS... Getest op een Turion64 TL-32 en een Core 2 Duo T7300.
[ Voor 11% gewijzigd door Borromini op 10-10-2007 22:27 ]
Got Leenucks? | Debian Bookworm x86_64 / ARM | OpenWrt: Empower your router | Blogje