Dell OptiPlex GX200 og 10.04

[Jakob77]

@AJenbo


Angående de koder til driveren til mit grafikkort, som Nvidia ikke vil udlevere.
Jeg er ikke meget for konspirationsteorier, og jeg vil helst fortsat pege på de samme, fordi de i forhold til mig er første led i ansvarskæden.
Men det slog mig lige, at maskinen jo er udviklet til Windows, og at Microsoft derfor måske kan have haft et ord at skulle have sagt om, hvordan hardwarekoderne skulle håndteres.
Er det helt usandsynligt, at der ligger en fortrolig aftale om det, og Nvidia derfor er bundet af Microsoft..?
Eller i hvert fald med de lidt grovere firkantede briller kan man måske forvente, at hvis Microsoft får et vink med en forbrugervognstang om, at sådan en lumsk planlagt forældelse af deres windowscomputere på grund af en stump hemmeligholdt software, det vil de ganske enkelt ikke finde sig i, så vil Nvidia nok hurtigt komme på andre tanker.
Jeg er nok så småt ved at opbygge den forestilling, at hvis Bill Gates forlanger, at de koder skal på forsiden af New York Times i morgen tidlig, så kommer de det. Tror du det er helt forkert..?


Med hensyn til 50 års reservedelsgaranti, så er det ikke altid relevant som et tilbud til kunderne, fordi der er mangel på varerne. Men nærmere for at få virksomhederne til at tænke sig mere om, før de udgiver noget elendigt skrammel.





@zob

I hvert fald i så høj grad, at regeringen anbefaler folk at varme deres huse op med den.
Og det er jo egentlig også, hvad man gør, når man bruger en PC. Den EL-energi, der spildes, den bliver til varme. Der forsvinder en smule ud af huset i form af stråling fra netkort mv., men hvad skulle den ellers blive til..?

[zob]

Jeg er glad for at høre at den tid hvor jeg skulle tænke på at spare på strømmen er forbi. Så er jeg fri for at gå at have dårlig samvittighed overfor miljøet på den konto.

[Jakob77]

@zob

Det var vist ikke helt præcist det, der var at høre.
Tror måske, du i stedet hørte en bette stråmand.

[zob]

Ja ja. Hvis det giver mening for dig, så er jeg glad.

[AJenbo]

Hvis der er højt forbrug af vind enagi betyder det blot at flere af dem der ikke går op i det kommer til at trække på kuld.

Hade Microsoft noget at skulle have sagt omkring hvordan Nvidia håndterede deres drivere tror jeg ikke der ville have være en Linux driver. Dog udfaser de driverne til begge styre system samtidig, men det har mest at gøre med alderen og udbredelsen af hardware, men det kan også have noget at gøre med hvilke interfaces der er blevet udfaset i d.v.s. styresystemer.
Som du nævner var din maskine jo ikke lavet med Linux i tankerne og det er kun pga. Nvidia hade interesser andre steder at der blev lavet en Linux driver, Dell hade 0 interesse i om der blev lavet en Linux driver. Hvis du mens der var garanti og support på maskinen hade beklaget dig om Linux problemer hade Dell henvist dig til at geninstallere den udgave af Windows som maskinen kom med.

Jeg kan desværre ikke rigtig komme på mere for at ændre opløsningen.

[Jakob77]

@AJenbo

Ok, vi stiller den på pause, og jeg retter teksten tilbage til XUbuntus valg igen.
Om ikke før, så kan der måske ske noget nyt om få år, når patentet udløber.
Og du får indtil videre mange tak for dine anstrengelser.

Jeg tror ikke, at du behøver være så bekymret for, at dine medborgere vil bruge mere kul, fordi du mest bruger din strøm, når det blæser, og der derfor er overskud af vindstrøm.

[AJenbo]

Det er ikke et patent fra afholder andre fra at lave en driver. Det er manglende dokumentation af chippen. Et patent kræver at det der patenteres også offentligt dokumenteres.

[Jakob77]

@AJenbo

Ok, så er det måske bare en god hacker, der er brug for.


Jeg glemte forresten at vise dig terminalsvaret fra grub updaten:

Generating grub configuration file ...
Advarsel: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Fandt linux-aftryk: /boot/vmlinuz-3.13.0-29-generic
Fandt initrd-aftryk: /boot/initrd.img-3.13.0-29-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
færdig

Og efter at have rettet linjen tilbage til "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"" så den således ud:

Generating grub configuration file ...
Advarsel: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Fandt linux-aftryk: /boot/vmlinuz-3.13.0-29-generic
Fandt initrd-aftryk: /boot/initrd.img-3.13.0-29-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
færdig

Så det er altså begge indstillinger, der giver en advarsel.

[AJenbo]

Advarslen du får har ikke noget med linjen du ændrede at gøre så det er ikke så mærkeligt at den kommer begge gange. Du kan blot se bort fra den.

Ok, så er det måske bare en god hacker, der er brug for.

Ja, men en hacker i ordets oprindelige betydning og ikke en cracker (ulovlig indtrængen), og så skal det være en med pasion for ældre hardware

[AJenbo]

Det ser ud til at Debian vil forsøge at genoplive Debian 6 og holde den kørende frem til 2016. Debian 6 ser faktisk ud til at være gammel nok til at den kan fungere sammen med den Nvidia driver der passer med dit grafikkort:
https://www.debian.org/News/2014/20140616

Debian 6 support ophørte oprindeligt 31 maj i år.

Ubuntu er baseret på Debian så der vil være mange fælles træk.

[Jakob77]

@AJenbo


Tak for informationen om Debian.


Jeg har tænkt lidt mere over det med den forældede grafikdriver, og hvorfor den forældes, for jeg forstår det stadig ikke så godt, at det vil falde til ro og holde op med at nage mig.
Lad mig lege advokat for Nvidia og angribe dig som forsvarer for Ubuntu Desktop 14.04 og lad mig se, om dit svar vil gøre mig klogere:
"Nvidia har allerede givet Ubuntu de grafikdrivere een gang, de vil ikke afsløre chippen for konkurrenterne, og de har andet at lave end at sidde og omprogrammere deres tolk ( driveren ) igen og igen bare fordi ubuntu i tide og utide får lyst til at tale et andet sprog."

Afslører den påstand, at der noget, som jeg ikke har forstået..?


Grafikdriveren må vel være den tolk, som skal omsætte koderne fra styresystemet til grafikkortet, så det tegner de streger og farver på skærmen, som styresystemet giver den besked på..?

Vi trænger vist også til lidt afveksling fra bilmetaforerne:

Altså lidt, som en dansk/arabisk tolk i København.
Ham flytter man af uransagelige grunde til Bornholm, hvor han ikke forstår dialekten og derfor ikke kan oversætte et ord. Hvad gør man..? Man fyrer tolken, og så er det bal forbi. Eller skaffer man lige hurtigt en lille vaks Bornholmer, som forstår bornholmsk og selv kan tale rigsdansk, og så kører det igen på trods af, at nogen var så fjollede at flytte tolken til Bornholm..?
Eller er det ganske enkelt bare alt for omstændigt at lære en Bornholmer rigsdansk..?

[AJenbo]

Nvidia udgiver jævnligt opdateringer af deres drivere. Disse driver opdateringer inkluderede både forbedret ydeevne, ny funktionalitet, sikkerheds rettelser og understøttelse af ny software og nye grafikkort. I 2009 valgte Nvidia ikke længere at understøtte TNT2 i fremtidige driver versioner. På dette tidspunkt var den højest understøttet Xorg version 1.7.
I efterfølgende Xorg versioner er der kommet understøttelse af yderligere funktionalitet og lukket flere sikkerhedshuller. Ved ikke at inkludere understøttelse af TNT2 i deres opdateret driver udelukker Nvidia brugeren fra at opdatere til en nyre udgave af Xorg og der med få fuld udnyttelse af funktionaliteten på TNT2 kortet samt at sikre sig mod kendte sårbarheder.
Yder mere stoppede Nvidia i 2011 med at udgive sikkerheds rettelser af den legacy driver der understøttede TNT2, det vil sige at brugeren igen udsættes for sikkerhedsmæssige problemer som Nvidia ene og alen er skyld i.

TNT2 chippen er nu så forældet at den ikke kan siges at have nogen markeds mæssig fordel og sælges heller ikke længere, der for burde der ikke være noget i vejen med at afsløre hvordan chippen programmeres (dette er ikke det samme som hvordan man laver selve chippen). Nvidias konkurrenter (AMD/ATI og Intel) har formået at åbne op for dokumentationen for deres chips, både nye som gamle, uden at det har påvirket deres konkurrencedygtighed.
Når Nvidia vælger at holde programmerings specifikationerne for deres chip hemmelig må det også være deres ansvar at vedligeholde den driver der er nødvendig for at udnytte chippen.
Nvidia udgav med jævne mellemrum driver med understøttelse af nye software til TNT2 i næsten et årti og der med 17 versioner af Xorg serveren, det kan der med ikke komme som et chok at denne udvikling fortsætter efter 2009, og fortsat er nødvendig for at være på forkant med funktionalitet og sikkerhed.
Det er der med også forkert at sige at de har fået 1 driver, der er nok nærmere tale om flere 100 og denne strøm af opdateringer er nødvendig for at ved holde sikkerhed og funktionalitet på begge sider.
Der er desuden ikke tale om en omskrivning men blot tilpasning af hvordan man kommunikere med enkelte funktionaliteter.

Yder mere kræver nyre drivere til nyt hardware nyre udgaver af eks. Xorg og Nvidia stiller der med operativ systemer i et dilemma hvor de kan vælge enten at understøtte moderne computere, eller kun at fungere med ældre computere.

Canonical har fået 0 kroner for at understøtte TNT2, Nvidia har fået betaling for hvert enkelt kort der er solgt, så her må Nvidia igen vær den ansvarlige omkring deres produkt. Der til skulle man måske tilføje at Xorg er ældre end Nvidia og Ubuntu er yngre end TNT2. Nvidia var der med klar over hvordan landet lå før de lavede deres første grafikkort og de kan ikke hænge den på Ubuntu specifikt, men det kan være du mener hele open source miljøet når du skriver Ubuntu?

Nettop i dag fylder X11 (det som Xorg implementere) i øvrigt 30 år. Det er 30 år med forbedringer og sikkerheds opdateringer.
Nvidia kræver for dit grafikkort at det er en Xorg fra mindst 2000 og senest 2009, hvad så med dem der ønsker at køre systemer fra 1984 eller 2014?

Risdansk udvikler sig også og der er der for nødvendigt for en tolk at følge med i disse ændringer hvis han ønsker at beholde sit job på længere sigt. Viser det viser sig at han har en tendens til godtroende at tage fremmedes bagage med sig når han rejser ud og ind af lande må der også gøre noget ved hans forståelse af sikkerhed.

Din ide med at ansætte flere og flere tolke ville i øvrigt også sløve kommunikationen voldsomt og det gør sig også gældende for en computer. Et punkt hvor analogien heller ikke holder er at det ville være nødvendigt for nogen at udvikle en driver-driver de kan oversætte fra en version til en anden, det gøres ikke lige så let og ville være letter blot at opdatere den egentlige driver, hvis altså man kunne. Med 30 år på bagen ville der også efterhånden skulle være rigtig mange driver-drivere, og der skulle jo helst være en der kan oversætte fra alle udgaver til alle udgaver så det ikke går for langsomt med driver-driver-driver-driver-driver-driver-driver-driver-driver-driver, for så bliver det nok hurtigt så langsomt at du lige så godt kunne undvære den. Det samme skal jo så også gøre sig gældende ikke kun for Xorg komponentet men også Linux komponentet og interkomunikationen mellem disse 2. Til sidst ender vi i en situation hvor ingen laver andet en kompatibilitets drivere.

Jeg kan slet ikke forstå hvordan du kan skælde ud på Ubuntu for at opdatere deres software så sikkerheden er i orden, mens du klappe I dine hænger over at Nvidia kun valgte at udgive opdateringer til deres eget grafikkort fra 2000 til 2011. Det er jo ikke fordi driveren opnåede en form for perfektion og der for ikke bør opdateres. Canonical har ingen interesse i at Ubuntu ikke at fungere med TNT2, tvært i mod, men Nvidia kan sælge nye grafikkort. Så er der nogen der tænker i planlagt forældelse må det være Nvidia.

Her er en liste af de fejl Nvidia anerkendte da de udgave den sidste driver for TNT2 brugere:

o LCD/CRT hotkey switching is not currently functioning on any
Toshiba laptop, with the exception of the Toshiba Satellite
3000 series.
o TwinView on Satellite 2800 series Toshbia laptops is not currently
functioning.
o The video overlay only works on the first display device on which
you started X. For example, if you start X on the internal LCD,
run a video application that uses the video overlay (uses the
"Video Overlay" adaptor advertised through the XV extension), and
then hotkey switch to add a second display device, the video will
not appear on the second display device. To work around this,
you can either configure the video application to use the "Video
Blitter" adaptor advertised through the XV extension (this is always
available), or hotkey switch to the display device on which you want
to use the video overlay *before* starting X.
The following problems still exist in this release and are in the process
of being resolved.

o OpenGL + Xinerama
Currently, OpenGL will not display to anything other than the
first head in a Xinerama environment.

o OpenGL and dlopen()
There are some issues with older versions of the glibc dynamic
loader (e.g., the version that shipped with Red Hat Linux 7.2) and
applications such as Quake3 and Radiant, that use dlopen().
See the FREQUENTLY ASKED QUESTIONS section for more details.

o DPMS and TwinView
DPMS Modes "suspend" and "standby" do not work correctly on
a second CRT when using TwinView. The screen becomes blank
instead of the monitor being set to the requested DPMS state.

o DPMS and Flat Panel
DPMS modes "suspend" and "standby" do not work correctly on a
flat panel display. The screen becomes blank instead of the
flat panel being set to the requested DPMS state.

o Multicard, Multimonitor
In some cases, the secondary card is not initialized correctly
by the NVIDIA kernel module. You can work around this by enabling
the XFree86 Int10 module to soft-boot all secondary cards. See
"APPENDIX D: X CONFIG OPTIONS" for details.

o FSAA
When FSAA is enabled (the __GL_FSAA_MODE environment variable
is set to a value that enables FSAA and a multisample visual is
chosen), the rendering may be corrupted when resizing the window.

o Interaction with pthreads
Single threaded applications that dlopen() NVIDIA's libGL
library, and then dlopen() any other library that is linked
against pthreads will crash in NVIDIA's libGL library. This does
not happen in NVIDIA's new ELF TLS OpenGL libraries (please see
(app-c) APPENDIX C: INSTALLED COMPONENTS for a description of
the ELF TLS OpenGL libraries). Possible work arounds for this
problem are:

1) Load the library that is linked with pthreads before
loading libGL.so.
2) Link the application with pthreads.

o libGL DSO finalizer and pthreads
When a multithreaded OpenGL application exits, it is possible for
libGL's DSO finalizer (also known as the destructor, or "_fini")
to be called while other threads are executing OpenGL code. The
finalizer needs to free resources allocated by libGL. This can
cause problems for threads that are still using these resources.
Setting the environment variable "__GL_NO_DSO_FINALIZER" to
"1" will work around this problem by forcing libGL's finalizer
to leave its resources in place. These resources will still
be reclaimed by the operating system when the process exits.
Note that the finalizer is also executed as part of dlclose(3),
so if you have an application that dlopens(3) and dlcloses(3)
libGL repeatedly, "__GL_NO_DSO_FINALIZER" will cause libGL to
leak resources until the process exits. Using this option can
improve stability in some multithreaded applications, including
Java3D applications.

o XVideo and the Composite X extension
XVideo will not work correctly when Composite is enabled. See
(app-u) APPENDIX U: THE COMPOSITE X EXTENSION.

o Cache Aliasing

Cache aliasing occurs when multiple mappings to a physical page
of memory have conflicting caching states, such as cached and
uncached. Due to these conflicting states, data in that physical
page may become corrupted when the processor's cache is flushed.
If that page is being used for DMA by a driver such as NVIDIA's
graphics driver, this can lead to hardware stability problems and
system lockups.

NVIDIA has encountered bugs with some Linux kernel versions that
lead to cache aliasing. Although some systems will run perfectly
fine when cache aliasing occurs, other systems will experience
severe stability problems, including random lockups. Users
experiencing stability problems due to cache aliasing will
benefit from updating to a kernel that does not cause cache
aliasing to occur.

NVIDIA has added driver logic to detect cache aliasing and to
print a warning with a message similar to the following:

NVRM: bad caching on address 0x1cdf000: actual 0x46 != expected 0x73

If you see this message in your log files and are experiencing
stability problems, you should update your kernel to the latest
version.

If the message persists after updating your kernel, please send a
bug report to NVIDIA.

o 64-Bit BARs (Base Address Registers)

Starting with native PCI Express GPUs, NVIDIA's GPUs will
advertise a 64-bit BAR capability (a Base Address Register stores
the location of a PCI I/O region, such as registers or a frame
buffer). This means that the GPU's PCI I/O regions (registers and
frame buffer) can be placed above the 32-bit address space (the
first 4 gigabytes of memory).

The decision of where the BAR is placed is made by the system
BIOS at boot time. If the BIOS supports 64-bit BARs, then the
NVIDIA PCI I/O regions may be placed above the 32-bit address
space. If the BIOS does not support this feature, then our PCI
I/O regions will be placed within the 32-bit address space as
they have always been.

Unfortunately, current Linux kernels (as of 2.6.11.x) do not
understand or support 64-bit BARs. If the BIOS does place any
NVIDIA PCI I/O regions above the 32-bit address space, the kernel
will reject the BAR and the NVIDIA driver will not work.

There is no known workaround at this point.

For ACPI, only S3 "Suspend to Ram" is currently supported. This means that
S4 "Suspend to Disk", otherwise known as "Software Suspend" or "swsusp"
does not currently work reliably.

[Jakob77]

@AJenbo


Tak for din forklaring og din tålmodighed.

Når jeg leger advokat for Nvidia, så rusker jeg selvfølgelig i Ubuntu, fordi de har sådan nogle krævende brugere, der ikke synes, at det er ok at omdanne klodens råstoffer til affald før tiden.

Et af mine problemer er nok at forstå, hvordan en driver til et grafikkort kan udgøre en nævneværdig sikkerhedsrisiko, så det er nødvendigt at opdatere den. Der kommer jo intet input udefra til grafikkortet, det er underlagt styresystemet, og det skal kun modtage noget og sende det videre til skærmen. Eller er det for simpelt eller forkert beskrevet..?
Er der nærmere tale om en dialog med styresystemet, hvor driveren får fuld adgang til at læse og skrive alle mulige steder..?
Det er den der med bagagen ind i landet, for jeg ser ikke, at driveren har grund til at hente noget udefra, og derfor ser jeg heller ikke, at styresystemet eller hardwaren skulle tillade det.


Det er rigtigt forstået, at jeg fløjter for en driver til driveren, som ligger i styresystemet, og denne driver til driveren skal måske skrives om eller tilrettes ( jeg ser ikke grund til at lave en driver til driverens driver, så der bliver tre led ), hvis styresystemet ændrer sig ( det er der nok også pænt meget andet, der skal alligevel ), men grafikkortet og den gamle driver ændrer sig jo ikke mere, så der kan vel næppe blive noget at ændre.
Det er muligt, at du har ret i, at det vil blive for sløvt. Men jeg tænker på normalen, hvor jeg med een driver oplever nul reaktionstid, og så er det fristende at sige, at hvis der i stedet er to drivere, så bliver reaktionstiden nok fordoblet, men det dobbelte af nul er jo stadig nul, så jeg vil næppe opleve en større forskel.

[AJenbo]

Et grafikkort har direkte adgang til at skrive og læse fra system hukommelsen, faktisk er både Playstation og Xbox blevet hacket gennem deres grafikkort. En grafik processor er ganske fleksibel og kan bruges til andet en blot at tegne streger og kasser. De bliver også benyttet til at accelerere tunge regne stykker der egner sig mere til den parallel struktur i grafikkortet end den mere serielle måde CPU'en arbejder på.
Forstil dig eksempel vis et lille spil på en hjemme hvor en virus er blevet forklædt som et stykke af spildets grafik. Virusen udnytter en fejl i driveren og skriver sig over i system hukommelsen og får adgang til CPU og resten af systemet. Systemet kan ikke analysere grafikstumpen da den ikke forstår hvordan denne skal eller kan behandles, det er der for driverens ansvar at holde styr på de programstumper der bliver kørt på grafikkortet.
Et andet senarie kunne være en skole computer hvor flere har adgang til systemet, men kun som brugere. En elev har så hentet et hacker værktøj, da dette ikke kræver administrator adgang at sende kommandoer til grafikkortet (man skal jo kunne se noget på skærmen), overtager hun computeren ved at sende onde kommandoer til et grafikkort hvor der er fejl i driveren. Hun kan nu kopiere alle de andre elevers lektier eller aflure lederens adgangskode.

Forsinkelsen på driveren kan du måske sammen ligne lidt med RAM så længe du ikke har nået grænsen køre alting fint, men når du krydser den bliver systemet utroligt sløvt. Der er flere af disse flaske halse for grafikkort og lige for tiden er der meget i røre for at formindske forsinkelsen i driver (især Windows og på iPhone) da det er ved at begrænse yde evnen for grafikkort.

Hvis der skal være en driver-driver mellem Xorg 1.7 og den aktuelle version så skal der vel også være en mellem 1.10 og den nuværende så jeg kan få glæde af mit GeForce 4 MX som Nvidia valgte at droppe support for i 2012. Og hvad med folk der har en bærbar med poulsbo som PowerVR næsten droppede lige så hurtigt som de fik udgivet en driver, så der bliver også nød til at være en driver-driver til Xorg 1.9. Der er sikkert også flere gamle drivere jeg ikke kender, og så skal man også huske at en grafikdriver også skal være kompatibel med Linux kernen så der ville højest sandsynligt bruges 2 driver-drivere for hver grafikdriver. Men hvad egentlig med andet hardware, jeg mener også der findes nogle WiFi drivere der ikke længere er understøttet.
Jeg er også temmelig sikker på nogle af ændringerne ikke blot kan oversættes, især når vi taler sikkerhed omkring ram adgang, her ville det være nødvendigt at emulere dele af systemet i software hvilket er yder omstændigt og temmelig sløvt og der efter analysere hvad grafikkortet laver og så genstarte grafik systemet hvis det ser ud til at den laver noget den ikke skal. Det ville så ikke være muligt for en hacker at få adgang til systemet vi et gammelt hul, men de kan stadig gøre livet surt for brugeren og uanset hvad er brugerens computer altid travlt beskæftiget med at undersøge om der skulle være noget galt.

Et andet aspekt man også bør tage med er at hvis man tilleder en sådan udvikling kan driver producenter finde på kun at målrette deres drivere mod en oldnordisk udgave hvor man så kun får halvdelen af den funktionalitet produktet har og kun 1/10 ydeevne.

En af de ting der gør at Linux kan være en løsning for ældre maskiner som har svært ved at trække Windows er også alt det ekstra software der er nødvendigt på Windows for at holde øje med om der er nogen der forsøger på noget de ikke må, så hvis vi begynder at byde den slags løsninger velkommen frem for at rette tingende på den rigtige måde, forsvinder denne egenskab måske fra Linux.

[AJenbo]

P.s. Nvidia har kun udgivet en x86 og x64 driver så hvis man eks har en ældre Mac med PowerPC så kan man overhovedet ikke bruge deres driver til noget. Ja og hvis man måske brugte 100% CPU på at emulere en x86 PC og køre driveren der i, men så mangler man lige som resten af maskinen...