Ja, maar dan is er dus iets mis met het achterliggende systeem (waar de drivers deel van uitmaken), en daarmee rommelen hoort niet thuis in de voorkeursinstellingen van de gebruiker.
En dat is waar ik naar toe wilde met mijn opmerking: Als de backend gewoon automatisch detecteert welke video modes en refresh rates werken op de hardware, dan hoeft dat niet (in xorg.conf) ingesteld te worden. Ook niet om er een uit te laten kiezen door de gebruiker, want dat kan via een gebruikersvriendelijk dialoog in de Desktop.
In die screen resolution tool kan ik niet eens een driver kiezen!
Ja, het is dan ook een screen resolution tool
Miki schreef op woensdag 16 juli 2008 @ 16:12:
Het is natuurlijk heel nobel om te denken dat alles maar openbaar moet worden gemaakt maar je kunt toch niet verwachten dat Nvidia haar complete bedrijfsgeheimen op tafel gooit om -hoe hard het ook voor je mag klinken- 1% van de desktopmarkt op haar wenken te bedienen.
Jij gaat me niet vertellen dat er zo'n boeiende bedrijfsgeheimen zitten in de hardware interface van hun videokaarten. Dat is - zeker met huidige GPUs - vergelijkbaar met de instructieset van een processor geheim houden omdat daar bedrijfsgeheimen in zouden zitten.
Heb je al naar ATi en Intel gekeken waarbij specificaties en documentatie over bepaalde hardware is vrijgegeven en zo goed als waardeloze (3d) drivers door de community zijn afgeleverd?
Ja, ik gebruik niet anders (nouja, op het moment gebruik ik nergens moderne Intel GPUs, dus het is vooral ATi).
Er zitten zeker waarheden in, maar ik zie die eerder als reden om de free drivers en infrastructuur te verbeteren. Zo werd er een tijd geleden bijvoorbeeld aan gewerkt aan een unified memory manager. En als NVidia nou had samen gewerkt met de Xorg (*) developers, dan hadden we die unified memory manager misschien al lang gehad, met als bonusvoordeel voor NVidia dat ze die niet zelf hoeven te onderhouden waarmee ze zich werk besparen.
(*) Destijds XFree86, wat misschien ook wel verklaart waarom ze dat niet gedaan hebben; De development van XFree86 was relatief gesloten, en het was niet makkelijk om patches geaccepteerd te krijgen.
Inderdaad, maar toch voegt Canonical ze toe.
Mwah, het lijkt mij sowieso wel handig om eerlijk te zijn. En zo onhaalbaar hoeft het niet te zijn, als de teams het maar ook een goed idee vinden. Ik heb geen idee of anderen hier zin in hebben.
Nouja, de haalbaarheid hangt natuurlijk af van de scope. Als het alleen om Linux, Xorg en Gnome gaat, dan is het misschien nog te doen. Maarja, dan wil je KDE ook natuurlijk voor de gelijktijdig te releasen Kubuntu. En openoffice. En Firefox. En the Gimp. En iedereens favoriete programmaatje voor dit en dat. En dat zie ik niet gebeuren. Ik denk ook dat het niet praktisch is.
Ik ben trouwens sowieso geen fan van deadline based releasen. Ik denk dat de kwaliteit van de software hoger komt te liggen door te releasen wanneer het klaar is, niet wanneer een willekeurige datum verstreken is.
Oh, en ik denk dat je Linus' medewerking in zo'n systeem wel kunt vergeten
Een kernelAPI hoeft ook helemaal niet voorgoed vastgezet te worden, maar ze zouden het best makkelijker kunnen maken voor driverontwikkelaars door voor 2.6 de api vast te stellen. Moet het over een jaar wijzigen? Fine, nieuwe branch 2.7
Ja, en een paar maanden later gooien ze het block device framework overhoop om de latency te verlagen voor flash disks. Weer een nieuwe branch? Daarna een wireless stack revamp om de verschillende aanpakken die al bestonden te verenigen. Nog maar een nieuwe branch? Dat werkt niet goed.
Development voor de kerneldevelopers ja. Da's leuk maar als dat de enige groep is die er voordeel van heeft en de rest klaagt erover, tja.
Ja, en kerneldevelopers zijn degenen die de kernel (inclusief drivers) ontwikkelen en onderhouden, en dat die taak voor hen te doen is lijkt me vrij belangrijk.
Dat zal deels wel kloppen, maar laten we vooral niet doen alsof een distro als Debian of Slackware in hun huidige vorm enig relevant marktaandeel zouden veroveren. Geheel toevallig lukt dat met een bedrijf als Canonical (in al zijn commercieelheid) een stuk beter, dat heeft echt wel een reden.
Ja, maar dat heeft niks te maken met proprietary drivers. Het installeren van die dingen is op Ubuntu niet dramatisch anders dan op de meeste andere distributies.
Het heeft het meeste te maken met hun marketing en uitstraling (die "Ubuntu is hip!" aura is goud waard), en met hun actieve pogingen Ubuntu aan de man te brengen (via Dell etc). Projecten als Debian en Slackware nemen een veel passievere houding aan; ze maken een (naar hun mening) zo goed mogelijk OS, en mensen mogen zelf langskomen om het te gaan gebruiken.
Wat Ubuntu's (huidige) marktaandeel ook helpt zijn die halfjaarlijkse releases en de algemene nieuwheid van de software. Dat promoot lekker vlotjes namelijk. Maar ironisch genoeg lijkt dat net hetgene te zijn dat bij bestaande gebruikers tot klachten begint te leiden.
Met als gevolg een driver die de grafische kaart kan aansturen, maar vanwege de bedrijfsgeheimen niet 3d kan, of niet alle features ondersteunt. Wat zeg je dan tegen een Nvidia?
"i can haz specz plz?"
Ik geloof niet dat er boeiende bedrijfsgeheimen in de hardware aansturing zitten. In de drivers? Ongetwijfeld, maar daar hoeven we de source niet van (nouja, zou leuk zijn, daar niet van). Merk op dat NVidia's twee grootste concurrenten, ATi en Intel, wel specs geven. Zo groot is voor hen het voordeel van die specs geheim houden dus niet.
Je beeldscherm instellen is wel wat meer dan alleen de resolutie anders. Ik kan aan mijn laptop nog steeds niet fatsoenlijk een extern scherm hangen en gebruiken
Je hebt gelijk, daar heb ik inderdaad niet aan gedacht, en dat is inderdaad iets dat nog gebrekkig is. Maar er wordt wel aan gewerkt aan betere hotplug + dualhead goodness.
Maar waar ik eigenlijk op aanstuurde met mijn vorige post: Er moet geen tool zijn die alle zooi in xorg.conf instelbaar maakt. De backend (Xorg) moet gewoon de mogelijkheden automatisch detecteren, en dat moet dan netjes via een preferences scherm in je DE in te stellen zijn.
Ik tel er maar twee: radeon en radeonhd?
Ik vraag me af wat voor orakel de Windows- en OSX-(kernel)devs dan wel niet gebruiken. Die krijgen het blijkbaar wel voorelkaar iets inelkaar te zetten waar ze gedurende lange tijd tevreden mee kunnen zijn.
Geen fatsoenlijk orakel blijkbaar, want zij moeten ook zulke veranderingen doorvoeren.
Leuk stukje tekst, maar teksten als “the goal is to provide the “Just Works” experience” en “that support continues through all future versions” neem ik met een flink korreltje zout.
Wat is er mis met die eerste quote? Geloof je niet dat dat het doel is? Of bedoel je dat dat niet lukt? Kernelside lukt dat volgensmij al heel aardig, behalve daar waar fabrikanten niet scheutig zijn met specs (bv wireless en 3D video). In Xorg wil het nog wat minder, maar Xorg heeft een ontwikkelachterstand.
En "all future versions" is natuurlijk een beetje overdreven, maar drivers worden over het algemeen pas verwijderd als ze kapot zijn en er niemand meer lijkt te zijn die ze gebruikt. Hardware die drivers in-tree heeft wordt over het algemeen erg lang ondersteund.
Er zit een verschil tussen een half jaar tot een jaar een compatibility-layer onderhouden (wat @ Linux nu al niet eens gebeurd), zodat iedereen de tijd heeft om zijn code aan te passen en 10 jaar (a la Windows).
Maar het idee is dus juist dat de code in-tree zit, en meteen mee aangepast wordt bij een interne interface verandering. Dan heb je geen 10 jaar van compatibility nodig.
Dat denk ik ook altijd als RMS aan het woord is. Dat slappe geouwehoer bij het vertrek van Bill Gates zijn van die momenten waarvoor hij leeft.
Maar hij loopt in ieder geval geen mensen uit te schelden, en hij onderbouwt zijn standpunten over het algemeen vrij degelijk.
Je hoeft het niet met hem eens te zijn, of je kunt hem te ver vinden doordraven, maar geen van beiden vind ik een rechtvaardiging om hem (of de mensen die het met hem eens zijn) "gestoorde kelderbewoners" te noemen.
“In de big-picture zin van het woord” zijn proprietary drivers of de enige oplossing (geen specs) of de betere oplossing (zie NVIDIA), dus ik weet niet waar je op doelt ?
Zie de klachten over de proprietary drivers; gezeik met kernel-upgrades, niet debugbaar bij crashes, geen ondersteuning op niet x86(-64) architecturen, gedropte support voor oudere kaarten. Je hardware werkt (meestal) wel, maar op lange termijn lijkt een investering in open-source drivers me beter.
Graag, maar ik ga pas volgende week op vakantie.
Sorry van mijn botte reply, maar dat "1% doet ooit wat met de source" argument schiet me meer en meer in het verkeerde keelgat. Mensen die dat argument hanteren vergeten dat de overige 99% ook voordeel heeft van die 1% die wat met de source doet. Zonder de source krijg je een soort tweede Windows, maar dan anders. En ik denk niet dat dat de reden is dat mensen GNU/Linux gebruiken.
Zo natuurlijk vind ik dat helemaal niet. Je gaat me niet wijsmaken dat al die FOSS-devs met AL hun werk na AL die jaren nog steeds niet kunnen gaan stabiliseren en standaardiseren op zoveel mogelijk vlakken.
Stabiliseren hoe? Door het tempo van veranderingen / verbeteringen omlaag te schroeven?
GTK of QT wegsnijden zou al een hoop dubbel werk en testen schelen.
Misschien, maar of het de moeite waard is? Grappig genoeg las ik er toevallig vandaag wat
speculatie op Planet Gnome over.
Jij gaat er voor het gemak vanuit dat op elke corporate desktop twee toolkits staan ? Je mag al blij zijn als je een calculator krijgt.
Ik ga er vanuit dat als een gebruiker in een corporate omgeving een applicatie wil, dat hij die aanvraagt bij systeembeheer. En dat systeembeheer de applicatie en eventuele benodigdheden installeert.
Als je geen bepaalde geluidsdaemon target kun je zomaar geen geluid hebben. Je mag er zelfs al niet vanuit gaan dat iets simpels als ALSA werkt (zie de PA-fuckup van Ubuntu).
Ik weet niet hoe het in KDE zit, maar in Gnome is het gebruikelijk voor geluid gstreamer te gebruiken. Gstreamer kan allerlei sound backends gebruiken, en welke default gebruikt wordt is ingesteld in gconf. Je hoeft dus geen bepaalde backend te targeten of zelfs maar in te stellen.
En de PA fuckup is een probleem van Ubuntu, niet van Gnome vs. KDE.
Ik had het niet persé over QT/GTK desktop-apps en ik doelde eigenlijk meer op tussenlagen als SDL.
Hoe gaat het op voor SDL dan? SDL is een alternatieve keuze voor GTK of QT, met andere eigenschappen; GTK en QT zijn voor "normale" desktop apps met knopjes enzo, SDL geeft je een vlak waarin je mag tekenen (met oa OpenGL, fullscreen en acceleratie support). SDL is daarom aardig populair voor spellen en sommige videospelers en dergelijke. Maar ook daar geldt dat geluid weg wordt geabstraheerd.
Proprietary drivers zorgen er niet voor dat ABI’s veranderen en compatibilitylagen ontbreken.
Nee, maar zo werkt Linux development. En de voor open-source drivers is het geen probleem.
Bedrijven die hun code absoluut niet willen vrijgeven zul je met constant gebombardeer echt niet het licht kunnen laten zien.
De code hoeven ze ook niet vrij te geven. De specs ook niet, maar dat zou de acceptatie wel helpen.
Ik val ze overigens niet lastig, ik stem met mijn portomonnee; ik koop gewoon geen hardware waar geen (voor mij afdoende) open-source drivers voor zijn.
shit hee, dit is volgensmij mijn langste post ooit hier
/u/130287/Naamloos.png?f=community)
:strip_icc():strip_exif()/u/37421/kt666.jpg?f=community)
/u/201651/beastie_300.png?f=community)
Maar dat is zorg voor later, dat wat eerst niet werkte werkt nu wel en dat is belangrijker, dingen die eerst wel en nu niet meer (goed) werken zijn makkelijker weer aan de praat te krijgen.
Sowieso opvallend: de nieuwe kernel is 500 MB, waar de oude maar 60 MB is, terwijl ik toch het config bestand van de oude kernel gebruikt heb, welke met een paar errors wel laadde...
/u/26742/000000751.png?f=community)
:strip_icc():strip_exif()/u/14853/bluepiSW.jpg?f=community)
/u/31090/bla.png?f=community)
/u/28429/crop59eb40ac5dc83_cropped.png?f=community)
:strip_icc():strip_exif()/u/75828/sid.jpg?f=community)
/u/164410/Untitled-2.png?f=community)
:strip_exif()/u/142088/ventura.gif?f=community)
/u/241825/Avatar_for_terrorist.png?f=community){kind=avatar}
:strip_exif()/u/112988/knipper.gif?f=community)
:strip_icc():strip_exif()/u/128039/clint.jpg?f=community)
/u/125506/link-8bit.png?f=community)
/u/83403/manuoceane-tux-romain2.png?f=community)
:strip_icc():strip_exif()/u/41669/lego-60.jpg?f=community)
:strip_icc():strip_exif()/u/264022/sharks_60x60.jpg?f=community)
. Ik snap ook niet waarom ze niet een heel klein beetje af kijken van debian en zo hun release organiseren dus een stabiele versie en testing.
:strip_icc():strip_exif()/u/65359/avatar_60.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/7307/images.jpg?f=community)
Voordat er met whatifs gewezen wordt richting NVIDIA, die met de NVIDIA-driver een prima driver neerzet (niet perfect, wel beter dan de rest): de Intel-driver en de 28318531 verschillende Ati open source drivers hebben constant te maken met regressies, presteren slechter dan closed source drivers (vooral de ati-driver (reverse engineered)) en missen functionaliteit. Twee dingen die ik redelijk recent nog langs heb zien komen op een Ubuntu-systeem : Compiz, xv + Intel = mooie blauwe filmpjes (heeft maanden geduurd voordat iemand het gepatched heeft) en 
Geen idee hoe ik het moet fixen en hoe ik het de vorige keer heb gedaan ... wordt weer dit topic doorspitten naar mijn eigen reacties.
Dit topic is gesloten.
