[opensuse-factory] Nvidia now requires devel packages ?!
Hi, I don't know if this is a packaging bug but: Loading repository data... Reading installed packages... Computing distribution upgrade... The following NEW packages are going to be installed: gcc gcc47 glibc-devel kernel-default-devel kernel-devel linux-glibc- devel The following packages are going to be upgraded: nvidia-computeG02 nvidia-gfxG02-kmp-default x11-video-nvidiaG02 3 packages to upgrade, 6 new. Overall download size: 43.3 MiB. After the operation, additional 64.3 MiB will be used. Continue? [y/n/?] (y): n Why gcc and *-devel for binary driver ? bug/change/something for next opensuse ?! -- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Thu, 08 Nov 2012 18:32:57 +0100 Daniele <kailed@kailed.net> пишет:
Hi, I don't know if this is a packaging bug but:
Loading repository data... Reading installed packages... Computing distribution upgrade...
The following NEW packages are going to be installed: gcc gcc47 glibc-devel kernel-default-devel kernel-devel linux-glibc- devel
The following packages are going to be upgraded: nvidia-computeG02 nvidia-gfxG02-kmp-default x11-video-nvidiaG02
3 packages to upgrade, 6 new. Overall download size: 43.3 MiB. After the operation, additional 64.3 MiB will be used. Continue? [y/n/?] (y): n
Why gcc and *-devel for binary driver ?
bug/change/something for next opensuse ?!
I noticed that since 304.60 (I skipped previous version) nvidia-gfxG02-kmp actually compiles kernel module during installation. I honestly do not remember how it was in the past; may be I just did not pay attention. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
Hi, I don't know if this is a packaging bug but:
Loading repository data... Reading installed packages... Computing distribution upgrade...
The following NEW packages are going to be installed: gcc gcc47 glibc-devel kernel-default-devel kernel-devel linux-glibc- devel
The following packages are going to be upgraded: nvidia-computeG02 nvidia-gfxG02-kmp-default x11-video-nvidiaG02
3 packages to upgrade, 6 new. Overall download size: 43.3 MiB. After the operation, additional 64.3 MiB will be used. Continue? [y/n/?] (y): n
Why gcc and *-devel for binary driver ?
The GLUE layer is source and needs to be compiled.
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany -------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In data giovedì 08 novembre 2012 18:41:03, Stefan Dirsch ha scritto:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Ok, thanks ! -- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/08/2012 06:41 PM, Stefan Dirsch wrote:
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Just curious... How this is done? Hopefully `make' is not run as root. As it might damage the system like it was proven several times already. - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQnDVaAAoJEL0lsQQGtHBJPHAP/1V1PEeYjL4Hu45uvefiBW6F Byf1bqwcYj7EDRDMxTe/LxImclfMI/VzkiQo58BxP0AX0MgWsOVL5/vmbPMPH65I ZFbjX4WijULsWau9ouYbYpyVtNULgERMDbViDw1w4b8kxPHXn40UYSMs2TUe9KRr Ci6zs77fcGBF8fR9F6fByOe+Cv6gslrdRWIcisWIWmttesu2L0rVbSvbK0TVnvkB Sjl6LyldT+Om0yDQkgM8RQA79Un3FCAjF2xF/LkBe2sgIaCYeqMS5pVpcJPfHscK /HO7NP0dCJ6IivDFbrBBPD7Pcim6d09RpKFxxV1gx62awFRadSWEIPo7ouzaTV2m Z3auaCX+Agvp3hp0tkX9AbWjomIzb+JjmuGbLJF7rCrxpFVzmBkOvOGoLA2phUw0 veKhH+pxHe09C/tNZFhzMLAphuNd95TRZTANxK1AhWJnUGBtQTgn3jZNiK8rHY0r 3gCx7Dsx9nKgcD+kBl3ZsmHQcnioSuBZu81EwSyRRAokd302ozFuQtHa+cXmRfi3 liQN2J7cgmJjWC9fqsrgrOesobCIg0Ist5lFISrm5Itm4F9wC85fam8yebzOIPv8 gpLAoV9HVJeV6xPp9Ose8Quc7aUzcsM05v43kaghD3XpaZLLjmIqph5HTgg7vqVJ scFTf6wi4AGngP2cht6D =KTAP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Thu, 08 Nov 2012 23:42:34 +0100 Jiri Slaby <jslaby@suse.cz> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/08/2012 06:41 PM, Stefan Dirsch wrote:
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Just curious... How this is done? Hopefully `make' is not run as root. As it might damage the system like it was proven several times already.
nvidia-gfxG02-kmp-desktop-304.64_k3.4.6_2.10-21.1.x86_64 postinstall scriptlet (using /bin/sh): arch=x86_64 flavor=desktop make -C /usr/src/linux-obj/$arch/$flavor \ modules \ M=/usr/src/kernel-modules/nvidia-304.64-$flavor \ SYSSRC=/usr/src/linux \ SYSOUT=/usr/src/linux-obj/$arch/$flavor pushd /usr/src/kernel-modules/nvidia-304.64-$flavor make -f Makefile.kbuild \ nv-linux.o \ SYSSRC=/usr/src/linux \ SYSOUT=/usr/src/linux-obj/$arch/$flavor popd ... etc Also name/version of package is rather misleading now. It is not kmp any more, it is src package. Basically it became DKMS in disguise. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCcdOYACgkQR6LMutpd94zaOgCg1HLtMDKKe0vhTzR46y5dc7T/ tdMAn2QWCu1az9ULDYFHXmGlrkc6FhAt =pwKV -----END PGP SIGNATURE-----
On 9.11.2012 04:13, Andrey Borzenkov wrote:
Also name/version of package is rather misleading now. It is not kmp any more, it is src package. Basically it became DKMS in disguise.
No, it still is a KMP. It still uses the weak-updates machanism and it has the same kABI dependencies as before. It's just that nvidia.ko is a %ghost file and it does not have an average %post script. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Michal Marek <mmarek@suse.cz>:
On 9.11.2012 04:13, Andrey Borzenkov wrote:
Also name/version of package is rather misleading now. It is not kmp any more, it is src package. Basically it became DKMS in disguise.
No, it still is a KMP. It still uses the weak-updates machanism and it has the same kABI dependencies as before. It's just that nvidia.ko is a %ghost file and it does not have an average %post script.
We could also call ourselves Gentoo and do this in all %pre/%post scripts for all packages... Frankly, What exactly is the advantage of having the workstation compile a .ko in this situation? What are we trying to resolve by doing this? Except 'offloading' build failures to the customers system instead of spotting them on OBS? I somewhat fail to see a rational to do so (except for the fact of being 'different'). Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.11.2012 11:33, schrieb Dominique Leuenberger:
I somewhat fail to see a rational to do so (except for the fact of being 'different').
It is legal to ship this package. It is illegal to ship the precompiled nvidia.ko. Yes, I think it's messy. Yes, I guess that DKMS would be better suited for this (but I have never taken a look at it before). -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 12 Nov 2012 13:55:57 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> пишет:
Yes, I guess that DKMS would be better suited for this (but I have never taken a look at it before).
If you will accept this I will prepare testing version including DKMS package (I take it we do not yet have one?) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/12 Andrey Borzenkov <arvidjaar@gmail.com>:
В Mon, 12 Nov 2012 13:55:57 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> пишет:
Yes, I guess that DKMS would be better suited for this (but I have never taken a look at it before).
If you will accept this I will prepare testing version including DKMS package (I take it we do not yet have one?) --
This DKMS package will be usefull for the ATI Catalyst driver? Because the trend is that Nvidia disappears from the desktop, because on one hand almost no manufacturer is actually using Nvidia/Nforce chipset, and on the other hand, as Intel and AMD are incorporating the GPU within the microprocessor. Only the gamers adding a video card for high performance gaming, and of them, most prefer the ATI video cards. Nvidia's future appears quite dark. Cheers, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 1:40 PM, Juan Erbes <jerbes@gmail.com> wrote:
If you will accept this I will prepare testing version including DKMS package (I take it we do not yet have one?) --
This DKMS package will be usefull for the ATI Catalyst driver?
Because the trend is that Nvidia disappears from the desktop, because on one hand almost no manufacturer is actually using Nvidia/Nforce chipset, and on the other hand, as Intel and AMD are incorporating the GPU within the microprocessor. Only the gamers adding a video card for high performance gaming, and of them, most prefer the ATI video cards.
Nvidia's future appears quite dark.
Sounds quite offtopic, but from someone that develops GPU-intensive games, nVidia's OpenGL drivers are far more mature than ATI's, crash a lot less when strained, and are a lot more robust regarding shader capabilities. For development, I prefer nVidia every time. However, a DKMS for ATI's Catalyst would indeed be quite useful. We get tons of bug reports for ATI that sound like ATI open source drivers issues, and we can't easily tell people to test with Catalyst since installing it is not for newbies. This really hurts bug hunting. Having it as a package would help a lot there. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/12 Claudio Freire <klaussfreire@gmail.com>:
On Mon, Nov 12, 2012 at 1:40 PM, Juan Erbes <jerbes@gmail.com> wrote:
If you will accept this I will prepare testing version including DKMS package (I take it we do not yet have one?) --
This DKMS package will be usefull for the ATI Catalyst driver?
Because the trend is that Nvidia disappears from the desktop, because on one hand almost no manufacturer is actually using Nvidia/Nforce chipset, and on the other hand, as Intel and AMD are incorporating the GPU within the microprocessor. Only the gamers adding a video card for high performance gaming, and of them, most prefer the ATI video cards.
Nvidia's future appears quite dark.
Sounds quite offtopic, but from someone that develops GPU-intensive games, nVidia's OpenGL drivers are far more mature than ATI's, crash a lot less when strained, and are a lot more robust regarding shader capabilities. For development, I prefer nVidia every time.
You are a game developer for Linux desktops? I'm not, and other guys that really knows about Linux, say the opposite than You: "During the Q&A, a person asks why NVIDIA does not play well with Linux. Torvalds explained shortly that NVIDIA has been one of the WORST companies to work with Linux project — which makes it even worse that NVIDIA ships a high number of chips for Android devices (which use Linux inside). Torvalds even summarized that ('Nvidia, fuck you!') in a playful manner. What has been your experience on NVIDIA drivers with Linux?" http://linux.slashdot.org/story/12/06/17/1415250/torvalds-slams-nvidias-linu...
However, a DKMS for ATI's Catalyst would indeed be quite useful. We get tons of bug reports for ATI that sound like ATI open source drivers issues, and we can't easily tell people to test with Catalyst since installing it is not for newbies. This really hurts bug hunting. Having it as a package would help a lot there.
Years ago, while I used Nvidia video, until I burned two Nvidia cards, and one Nvidia/Nforce chipset, I installed the Nvidia propietary drivers in the same way than I install the ATI Catalyst drivers the last years, and when I changed from the Nvidia propietary drivers to the ATI Catalyst drivers (because the hardware change), I hatte less problems with the Catalyst installer, than with Nvidia. Today the ATI open source drivers, perform very well, I changed only because under 64 bits, I could'nt use the Google Earth with it. I found that for Opensuse 12.1 and 12.2 they are no propietary repo drivers. Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 9:16 PM, Juan Erbes <jerbes@gmail.com> wrote:
2012/11/12 Claudio Freire <klaussfreire@gmail.com>:
Sounds quite offtopic, but from someone that develops GPU-intensive games, nVidia's OpenGL drivers are far more mature than ATI's, crash a lot less when strained, and are a lot more robust regarding shader capabilities. For development, I prefer nVidia every time.
You are a game developer for Linux desktops?
I'm not, and other guys that really knows about Linux, say the opposite than You:
"During the Q&A, a person asks why NVIDIA does not play well with Linux. Torvalds explained shortly that NVIDIA has been one of the WORST companies to work with Linux project — which makes it even worse that NVIDIA ships a high number of chips for Android devices (which use Linux inside). Torvalds even summarized that ('Nvidia, fuck you!') in a playful manner. What has been your experience on NVIDIA drivers with Linux?"
You missed Linus's point. That nVidia is uncooperative and OSS-unfriendly doesn't make their drivers bad. They're good. They're just closed source, and they try not to contribute to the kernel.
However, a DKMS for ATI's Catalyst would indeed be quite useful. We get tons of bug reports for ATI that sound like ATI open source drivers issues, and we can't easily tell people to test with Catalyst since installing it is not for newbies. This really hurts bug hunting. Having it as a package would help a lot there.
Years ago, while I used Nvidia video, until I burned two Nvidia cards, and one Nvidia/Nforce chipset, I installed the Nvidia propietary drivers in the same way than I install the ATI Catalyst drivers the last years, and when I changed from the Nvidia propietary drivers to the ATI Catalyst drivers (because the hardware change), I hatte less problems with the Catalyst installer, than with Nvidia.
Again, nVidia's installer is buggy and troublesome, yes. And it seldom works with the latest kernel. Again, this is nVidia being uncooperative. But when you make them work, they work a ton better than ATI's.
Today the ATI open source drivers, perform very well, I changed only because under 64 bits, I could'nt use the Google Earth with it.
AMD open source drivers crash (kill X) when presented with some unexpected shaders/API usage. I don't own an AMD GPU so I can't debug myself, if I did, I would file bugs. And I cannot afford to buy one GPU of each maker to do the testing. But our users report tons of those crashes, both in the open source drivers and in Catalyst. They're even worse than intel drivers.
Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES:
Amen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 13, 2012 at 6:08 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
On Mon, Nov 12, 2012 at 9:16 PM, Juan Erbes <jerbes@gmail.com> wrote:
2012/11/12 Claudio Freire <klaussfreire@gmail.com>: "During the Q&A, a person asks why NVIDIA does not play well with Linux. Torvalds explained shortly that NVIDIA has been one of the WORST companies to work with Linux project — which makes it even worse that NVIDIA ships a high number of chips for Android devices (which use Linux inside). Torvalds even summarized that ('Nvidia, fuck you!') in a playful manner. What has been your experience on NVIDIA drivers with Linux?"
You missed Linus's point. That nVidia is uncooperative and OSS-unfriendly doesn't make their drivers bad. They're good. They're just closed source, and they try not to contribute to the kernel.
Not only that.. the discussion was around the nVidia Optimus chips... it had little to do with the mainstream dedicated cards. People love quoting that event without zero realy understanding of what was going on, what was being discussed, or why he said what he said (plus.. he's not God.. .so what he was cranky with a vendor).
However, a DKMS for ATI's Catalyst would indeed be quite useful.
DKMS in general for both nVidia and Catalyst would be a great idea! C. -- openSUSE 12.2 x86_64, KDE 4.9.2 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/13 Claudio Freire <klaussfreire@gmail.com>:
On Mon, Nov 12, 2012 at 9:16 PM, Juan Erbes <jerbes@gmail.com> wrote:
2012/11/12 Claudio Freire <klaussfreire@gmail.com>:
Sounds quite offtopic, but from someone that develops GPU-intensive games, nVidia's OpenGL drivers are far more mature than ATI's, crash a lot less when strained, and are a lot more robust regarding shader capabilities. For development, I prefer nVidia every time.
You are a game developer for Linux desktops?
I'm not, and other guys that really knows about Linux, say the opposite than You:
"During the Q&A, a person asks why NVIDIA does not play well with Linux. Torvalds explained shortly that NVIDIA has been one of the WORST companies to work with Linux project — which makes it even worse that NVIDIA ships a high number of chips for Android devices (which use Linux inside). Torvalds even summarized that ('Nvidia, fuck you!') in a playful manner. What has been your experience on NVIDIA drivers with Linux?"
You missed Linus's point. That nVidia is uncooperative and OSS-unfriendly doesn't make their drivers bad. They're good. They're just closed source, and they try not to contribute to the kernel.
And do'nt provide drivers for the Tegra based Android movile devices. Only a developer kit: http://www.nvidia.com/content/devzone/tegra-android-developer-pack.html
However, a DKMS for ATI's Catalyst would indeed be quite useful. We get tons of bug reports for ATI that sound like ATI open source drivers issues, and we can't easily tell people to test with Catalyst since installing it is not for newbies. This really hurts bug hunting. Having it as a package would help a lot there.
Years ago, while I used Nvidia video, until I burned two Nvidia cards, and one Nvidia/Nforce chipset, I installed the Nvidia propietary drivers in the same way than I install the ATI Catalyst drivers the last years, and when I changed from the Nvidia propietary drivers to the ATI Catalyst drivers (because the hardware change), I hatte less problems with the Catalyst installer, than with Nvidia.
Again, nVidia's installer is buggy and troublesome, yes. And it seldom works with the latest kernel. Again, this is nVidia being uncooperative. But when you make them work, they work a ton better than ATI's.
Today the ATI open source drivers, perform very well, I changed only because under 64 bits, I could'nt use the Google Earth with it.
AMD open source drivers crash (kill X) when presented with some unexpected shaders/API usage.
The only problem, as I reported, is with Google Earth, which make a mix of 32 and 64 libraries. Google Earth appear as 64 bits, but when it's installed, one must to install a plenty of 32 bits libraries, in a system of 64 bits, and in this case, when Google Earth sturts up, with the open source Radeon driver crashes. I found online, that with Nvidia graphics Google Earth has problems. http://forums.fedoraforum.org/showthread.php?t=271230
I don't own an AMD GPU so I can't debug myself, if I did, I would file bugs. And I cannot afford to buy one GPU of each maker to do the testing. But our users report tons of those crashes, both in the open source drivers and in Catalyst.
We can make a statistics on bugzilla, and see what graphics has more registered bugs!
They're even worse than intel drivers.
In this list and in the last 2 years, a see more troubles related to the nvidia and intel drivers, than the Radeon. I do'nt remember in this list 1 problem related to the Radeon driver. Cheers, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 13, 2012 at 9:01 AM, Juan Erbes <jerbes@gmail.com> wrote:
They're even worse than intel drivers.
In this list and in the last 2 years, a see more troubles related to the nvidia and intel drivers, than the Radeon. I do'nt remember in this list 1 problem related to the Radeon driver.
Because the problems I mention are related to high-complexity shaders. You seldom see that in linux (too few really sophisticated games). I write shaders, and I know many things I could write for nVidia I can't write for ATI. A while ago, it was loops. Loops killed ATI drivers while nVidia could handle them fine (and loops were part of the GLSL spec). Mesa has gotten way better since then, and open source AMD drivers are MESA-based AFAIK, so it may be different now. I just have no hardware to test with. In any case, both MESA and Catalyst break in a bad way when you invoke the API in unexpected (yet correct) ways. Mesa 7, for instance, segfaulted if you sent a vec4 for a float uniform. It shouldn't segfault, it should return an error code. Mesa 8 has that fixed, but has other issues I couldn't identify yet. It's not the kinds of bugs a graphical desktop runs into - only games. Not even blender makes such heavy use of shading capabilities. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/13 Claudio Freire <klaussfreire@gmail.com>:
On Tue, Nov 13, 2012 at 9:01 AM, Juan Erbes <jerbes@gmail.com> wrote:
They're even worse than intel drivers.
In this list and in the last 2 years, a see more troubles related to the nvidia and intel drivers, than the Radeon. I do'nt remember in this list 1 problem related to the Radeon driver.
Because the problems I mention are related to high-complexity shaders. You seldom see that in linux (too few really sophisticated games). I write shaders, and I know many things I could write for nVidia I can't write for ATI. A while ago, it was loops. Loops killed ATI drivers while nVidia could handle them fine (and loops were part of the GLSL spec).
Mesa has gotten way better since then, and open source AMD drivers are MESA-based AFAIK, so it may be different now. I just have no hardware to test with.
In any case, both MESA and Catalyst break in a bad way when you invoke the API in unexpected (yet correct) ways. Mesa 7, for instance, segfaulted if you sent a vec4 for a float uniform. It shouldn't segfault, it should return an error code. Mesa 8 has that fixed, but has other issues I couldn't identify yet. It's not the kinds of bugs a graphical desktop runs into - only games. Not even blender makes such heavy use of shading capabilities.
Mesa 7 works right with the nouveau driver? I could place some links to ilustrate what You say? Or Linus Torvalds is wrong in what his said? Cheers, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Nov 13, 2012 at 11:53 AM, Juan Erbes <jerbes@gmail.com> wrote:
In any case, both MESA and Catalyst break in a bad way when you invoke the API in unexpected (yet correct) ways. Mesa 7, for instance, segfaulted if you sent a vec4 for a float uniform. It shouldn't segfault, it should return an error code. Mesa 8 has that fixed, but has other issues I couldn't identify yet. It's not the kinds of bugs a graphical desktop runs into - only games. Not even blender makes such heavy use of shading capabilities.
Mesa 7 works right with the nouveau driver?
No, I always had to install nVidia's proprietary driver. You could say it was a MESA thing and not an ATI thing, but then again, our users report similar problems with Catalyst, so...
I could place some links to illustrate what You say?
Um... I think we could have some old discussions in our forums[0], or perhaps our tracker[1]. I could dig it up. But it would be a chore. It's old news anyway.
Or Linus Torvalds is wrong in what his said?
Again, from what I remember of the article, Linus didn't speak about the quality of the drivers, only the quality of collaboration. I'm 100% sure nVidia's drivers would be even better if they opened their sources so developers could look inside and spot bugs when they happen. But they already do a good job by themselves. AMD drivers got way better when they opensourced. I'm sure the same would happen for nVidia, but nVidia doesn't seem to agree. The whole matter is centered around that. [0] http://forums.vega-strike.org/ [1] http://sourceforge.net/tracker/?group_id=19507&atid=119507 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/13 Claudio Freire <klaussfreire@gmail.com>:
AMD drivers got way better when they opensourced. I'm sure the same would happen for nVidia, but nVidia doesn't seem to agree. The whole matter is centered around that.
[0] http://forums.vega-strike.org/ [1] http://sourceforge.net/tracker/?group_id=19507&atid=119507
What You mean about the future of Nvidia in the desktop, with the adoption of the GPU inside the microprocessor encapsulate by AMD and intel, and the use by the motherboards manufacturers of chipsets from AMD and intel only? In the next 3 years You mean that Nvidia will continue to developing Linux drivers for the hardware with 3 years old? Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Juan Erbes wrote:
2012/11/13 Claudio Freire <klaussfreire@gmail.com>:
On Tue, Nov 13, 2012 at 9:01 AM, Juan Erbes <jerbes@gmail.com> wrote:
They're even worse than intel drivers.
In this list and in the last 2 years, a see more troubles related to the nvidia and intel drivers, than the Radeon. I do'nt remember in this list 1 problem related to the Radeon driver.
Because the problems I mention are related to high-complexity shaders. You seldom see that in linux (too few really sophisticated games). I write shaders, and I know many things I could write for nVidia I can't write for ATI. A while ago, it was loops. Loops killed ATI drivers while nVidia could handle them fine (and loops were part of the GLSL spec).
Mesa has gotten way better since then, and open source AMD drivers are MESA-based AFAIK, so it may be different now. I just have no hardware to test with.
In any case, both MESA and Catalyst break in a bad way when you invoke the API in unexpected (yet correct) ways. Mesa 7, for instance, segfaulted if you sent a vec4 for a float uniform. It shouldn't segfault, it should return an error code. Mesa 8 has that fixed, but has other issues I couldn't identify yet. It's not the kinds of bugs a graphical desktop runs into - only games. Not even blender makes such heavy use of shading capabilities.
Claudio invested his time to write a very good state-of-the-art expericience report, concerning advanced graphics support on Linux. Claudio, thanks a lot for this; this was enlightening and well appreciated.
Or Linus Torvalds is wrong in what his said?
You obviously either didn't read Claudio's post or didn't understand it. Linus complained about NVidia coorporation in kernel development, caused by Notebook graphics chip configurations (Optimus issues) -- something that has *nothing* to do with the info Claudio gave. Are you ignorant, or are you a troll? Sorry to ask so frankly, but I'd like to know if I should put you in my KILL file. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/13 Joachim Schrod <jschrod@acm.org>:
Juan Erbes wrote:
2012/11/13 Claudio Freire <klaussfreire@gmail.com>:
On Tue, Nov 13, 2012 at 9:01 AM, Juan Erbes <jerbes@gmail.com> wrote:
They're even worse than intel drivers.
In this list and in the last 2 years, a see more troubles related to the nvidia and intel drivers, than the Radeon. I do'nt remember in this list 1 problem related to the Radeon driver.
Because the problems I mention are related to high-complexity shaders. You seldom see that in linux (too few really sophisticated games). I write shaders, and I know many things I could write for nVidia I can't write for ATI. A while ago, it was loops. Loops killed ATI drivers while nVidia could handle them fine (and loops were part of the GLSL spec).
Mesa has gotten way better since then, and open source AMD drivers are MESA-based AFAIK, so it may be different now. I just have no hardware to test with.
In any case, both MESA and Catalyst break in a bad way when you invoke the API in unexpected (yet correct) ways. Mesa 7, for instance, segfaulted if you sent a vec4 for a float uniform. It shouldn't segfault, it should return an error code. Mesa 8 has that fixed, but has other issues I couldn't identify yet. It's not the kinds of bugs a graphical desktop runs into - only games. Not even blender makes such heavy use of shading capabilities.
Claudio invested his time to write a very good state-of-the-art expericience report, concerning advanced graphics support on Linux. Claudio, thanks a lot for this; this was enlightening and well appreciated.
Or Linus Torvalds is wrong in what his said?
You obviously either didn't read Claudio's post or didn't understand it. Linus complained about NVidia coorporation in kernel development, caused by Notebook graphics chip configurations (Optimus issues) -- something that has *nothing* to do with the info Claudio gave.
Are you ignorant, or are you a troll? Sorry to ask so frankly, but I'd like to know if I should put you in my KILL file.
I'm sorry because my english is not so good! What You mean as "trol"? I used the Google translate, and appear trol = gnomo (in spanish)
From my point of view, they are wasting their time if programmed only for nvidia, because according to the current state of PC hardware, with the adoption of the gpu in the microprocessor by Intel and AMD, and any manufacturer of motherboards uses chipset nvidia / nforce.
On the other hand, those who use the PC for gaming, prefer Windows over Linux, and have better performance with Directx the cards ATI / AMD than Nvidia, which is why most gamers prefer ATI / AMD video cards. Cheers, Juan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 14, 2012 at 9:19 AM, Juan Erbes <jerbes@gmail.com> wrote:
From my point of view, they are wasting their time if programmed only for nvidia, because according to the current state of PC hardware, with the adoption of the gpu in the microprocessor by Intel and AMD, and any manufacturer of motherboards uses chipset nvidia / nforce.
I never said I programmed only for nVidia. I develop on nVidia, which is quite a different thing. When I develop shaders, I don't know the final form it will take. I also need tools to measure its performance, and I need to see the output of all detail levels as it would be seen on compliant OpenGL implementations. Only when I'm content with the technique itself, that I can go to other implementations and tweek the shader there. I can successfully do this on Intel GPUs only up to GLSL 1.2. Any higher, and MESA craps on me, arguably because the hardware lacks the capabilities (1.3 and above mandate support for some operations that doesn't seem supported by most intel GPUs). For AMD... I only use my experience with older models, and bug reports that tell me what not to do. I don't have the hardware (drivers don't work without the hardware) to test. AMD doesn't have linux profiling tools either (for nVidia, I can user nvshaderperf in wine, and it works even without an nVidia GPU as it has a built-in emulator. AMD's version doesn't work with wine or without the hardware).
On the other hand, those who use the PC for gaming, prefer Windows over Linux
Well, that's moot. I use linux. I prefer linux. I develop for linux. And this is a linux mailing list.
and have better performance with Directx
That's false. Steam already published comparison results, and OpenGL sometimes is even better than DirectX. At worst there's no difference (other than cross-platformness). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/14 Claudio Freire <klaussfreire@gmail.com>:
On Wed, Nov 14, 2012 at 9:19 AM, Juan Erbes <jerbes@gmail.com> wrote:
From my point of view, they are wasting their time if programmed only for nvidia, because according to the current state of PC hardware, with the adoption of the gpu in the microprocessor by Intel and AMD, and any manufacturer of motherboards uses chipset nvidia / nforce.
I never said I programmed only for nVidia. I develop on nVidia, which is quite a different thing.
When I develop shaders, I don't know the final form it will take. I also need tools to measure its performance, and I need to see the output of all detail levels as it would be seen on compliant OpenGL implementations. Only when I'm content with the technique itself, that I can go to other implementations and tweek the shader there.
I can successfully do this on Intel GPUs only up to GLSL 1.2. Any higher, and MESA craps on me, arguably because the hardware lacks the capabilities (1.3 and above mandate support for some operations that doesn't seem supported by most intel GPUs).
For AMD... I only use my experience with older models, and bug reports that tell me what not to do. I don't have the hardware (drivers don't work without the hardware) to test. AMD doesn't have linux profiling tools either (for nVidia, I can user nvshaderperf in wine, and it works even without an nVidia GPU as it has a built-in emulator. AMD's version doesn't work with wine or without the hardware).
On the other hand, those who use the PC for gaming, prefer Windows over Linux
Well, that's moot. I use linux. I prefer linux. I develop for linux. And this is a linux mailing list.
and have better performance with Directx
That's false. Steam already published comparison results, and OpenGL sometimes is even better than DirectX. At worst there's no difference (other than cross-platformness).
As I know, most of the windows games uses Directx, not OpenGL. Here are about 25 benchmarks based on many applications, games and tests: http://www.tomshardware.com/charts/2012-vga-gpgpu/benchmarks,135.html In most of the cases performs better the ATI/AMD cards, than the Nvidia based cards For example this: http://www.tomshardware.com/charts/2012-vga-gpgpu/15-GPGPU-Luxmark,2971.html Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Juan Erbes <jerbes@gmail.com>:
Regards, Juan --
My [....] is better than your [...] still this thread goes far off topic and should be stopped in my opinion. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Nov 14, 2012 at 1:10 PM, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
My [....] is better than your [...]
still this thread goes far off topic and should be stopped in my opinion.
My on-topic point: working DKMS for both Catalyst and nVidia's driver are good to have -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 09:16:39PM -0300, Juan Erbes wrote:
I found that for Opensuse 12.1 and 12.2 they are no propietary repo drivers.
There are: http://en.opensuse.org/SDB:AMD_fglrx http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.2/ http://en.opensuse.org/SDB:AMD_fglrx_legacy http://geeko.ioda.net/mirror/amd-fglrx-legacy/openSUSE_12.2/ Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany -------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/11/13 Stefan Dirsch <sndirsch@suse.de>:
On Mon, Nov 12, 2012 at 09:16:39PM -0300, Juan Erbes wrote:
I found that for Opensuse 12.1 and 12.2 they are no propietary repo drivers.
There are:
http://en.opensuse.org/SDB:AMD_fglrx http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.2/
http://en.opensuse.org/SDB:AMD_fglrx_legacy http://geeko.ioda.net/mirror/amd-fglrx-legacy/openSUSE_12.2/
Thank You! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 01:51:41PM -0300, Claudio Freire wrote:
However, a DKMS for ATI's Catalyst would indeed be quite useful. We get tons of bug reports for ATI that sound like ATI open source drivers issues, and we can't easily tell people to test with Catalyst since installing it is not for newbies. This really hurts bug hunting. Having it as a package would help a lot there.
We have fglrx driver packages. http://en.opensuse.org/SDB:AMD_fglrx http://en.opensuse.org/SDB:AMD_fglrx_legacy AFAIK the repo can also be found among "Community Repositories" in YaST. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany -------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 01:40:16PM -0300, Juan Erbes wrote:
2012/11/12 Andrey Borzenkov <arvidjaar@gmail.com>:
В Mon, 12 Nov 2012 13:55:57 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> пишет:
Yes, I guess that DKMS would be better suited for this (but I have never taken a look at it before).
If you will accept this I will prepare testing version including DKMS package (I take it we do not yet have one?) --
This DKMS package will be usefull for the ATI Catalyst driver?
Actually, the package we have is very much similar to what DKMS is doing. It recompiles the kernel module during boot if required. BTW, Sebastian Siebert, who is maintaing the build scripts for openSUSE (which are used to create the openSUSE packages) is doing an excellent job here! Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany -------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 12 Nov 2012 13:55:57 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> пишет:
Am 12.11.2012 11:33, schrieb Dominique Leuenberger:
I somewhat fail to see a rational to do so (except for the fact of being 'different').
It is legal to ship this package. It is illegal to ship the precompiled nvidia.ko.
Yes, I think it's messy. Yes, I guess that DKMS would be better suited for this (but I have never taken a look at it before).
Actually I am not sure anymore. I have more or less complete DKMS package and test dkms-nvidia-gfxG02 package, but the main issue is dependencies. nvidia-kmp knows for which kernel it is built and can request correct -devel package. But neither DKMS itself nor DKMS driver package knows for which kernel it will be built. I do not think RPM can express "if dkms is installed require kernel-$flavor-devel for each kernel-$flavor". Such logic probably belongs to zypper/YaST2. And at least in case of nVidia DKMS does exactly the same - it will install weak updates for each module built. It does have advantages of not needing to wait for RPM, of course. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Dirsch wrote:
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
[...] Why gcc and *-devel for binary driver ?
The GLUE layer is source and needs to be compiled.
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
That looks really broken. Why? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2012 09:24 AM, Ludwig Nussel wrote:
Stefan Dirsch wrote:
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
[...] Why gcc and *-devel for binary driver ?
The GLUE layer is source and needs to be compiled.
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
That looks really broken. Why?
possibly to allow people to run more than just the openSUSE kernel. Could also come very handy to have a working nvidia driver rpm on Factory which was rare in the past. Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcyUYACgkQSTYLOx37oWRwXgCguyhTKqhFDFGaQh8eh8xnt/UC N4wAnAhorgsgWtrk8TB3bJ8VbRbF/8wD =NvSG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Nov 9, 2012 at 1:13 PM, Bernhard M. Wiedemann <bernhardout@lsmod.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/09/2012 09:24 AM, Ludwig Nussel wrote:
Stefan Dirsch wrote:
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
[...] Why gcc and *-devel for binary driver ?
The GLUE layer is source and needs to be compiled.
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
That looks really broken. Why?
possibly to allow people to run more than just the openSUSE kernel.
That's what DKMS is for. It does not belong to package that is called KMP and is stamped with exact openSUSE kernel version -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2012 10:44 AM, Andrey Borzenkov wrote:
On Fri, Nov 9, 2012 at 1:13 PM, Bernhard M. Wiedemann <bernhardout@lsmod.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/09/2012 09:24 AM, Ludwig Nussel wrote:
Stefan Dirsch wrote:
On Thu, Nov 08, 2012 at 06:32:57PM +0100, Daniele wrote:
[...] Why gcc and *-devel for binary driver ?
The GLUE layer is source and needs to be compiled.
bug/change/something for next opensuse ?!
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
That looks really broken. Why?
possibly to allow people to run more than just the openSUSE kernel.
That's what DKMS is for. It does not belong to package that is called KMP and is stamped with exact openSUSE kernel version
we don't seem to have DKMS in Factory? http://software.opensuse.org/package/dkms might be good to have it Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCc0p8ACgkQSTYLOx37oWQRSwCgmsip6X4uS2VcCZr7512HvCzK lFoAnRlWwfeqwXCmOMRDW0A/belOsx0N =iDgI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Nov 08, 2012 at 06:41:03PM +0100, Stefan Dirsch wrote:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Uh, doesn't that conflict with the new UEFI secure boot where all kernel modules have to be signed? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Schroeder wrote:
On Thu, Nov 08, 2012 at 06:41:03PM +0100, Stefan Dirsch wrote:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Uh, doesn't that conflict with the new UEFI secure boot where all kernel modules have to be signed?
Cheers, Michael.
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion. I got a heads-up on this due to a faulty UEFI bios that occasionally complains about my not having a license to upgrade my memory configuration (which my Dell machine doesn't 'currently' need), but in the future, the UEFI Bios will allow the vendor have a lock on what HW you can put into your computer and have it boot as well as what SW. The DKMS system isn't a conflict if the vendor allows your kernel to load modules, but say your vendor uses Windows RT (which doesn't allow HW to be shipped with an "open boot" and keep it's 'Windows RT ready' sticker... In such a case, DKMS wouldn't do you much good -- you can lock down linux at least as much as windows. You wouldn't be able to add after-purchase upgrades like a larger HD unless you pay the vendor for the privilege. We know some people will likely hack the systems to get root, but for the average person, it will take away their ability to repurpose or reuse a computer for anything other than what the manufacturer. Seems like a large segment of the population is fine with not really owning their electronics, and only getting usage from it as they pay for such "by the App"... I posted something similar to this when OSuse spoke out about providing a shim layer and 'buying into' this setup, in response to the announcement. Unfortunately, responses required "approval" before they were posted (I was logged in with my registered account). My response detailing the above and a few other similar scenarios enabled by vendors supporting signed-boot (vs. requiring PC's to be shipped with a toggle switch), was never approved for publication among the responses, though others appeared. I thought that odd, but not entirely surprising. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 04:00:11AM -0800, Linda Walsh wrote:
Michael Schroeder wrote:
On Thu, Nov 08, 2012 at 06:41:03PM +0100, Stefan Dirsch wrote:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Uh, doesn't that conflict with the new UEFI secure boot where all kernel modules have to be signed?
Cheers, Michael.
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion.
Not at all, I want secure boot for my systems, with a key that I have control over, to ensure that no one else has installed a boot loader on it that I do not know about. For that reason alone, you should want it as well.
I got a heads-up on this due to a faulty UEFI bios that occasionally complains about my not having a license to upgrade my memory configuration (which my Dell machine doesn't 'currently' need), but in the future, the UEFI Bios will allow the vendor have a lock on what HW you can put into your computer and have it boot as well as what SW.
No, not at all, you have control over this, you can put your own keys in the BIOS just fine. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion.
Not at all, I want secure boot for my systems, with a key that I have control over, to ensure that no one else has installed a boot loader on it that I do not know about.
Who has access to the machine first? You or the vendor? Who has the first opportunity to lock it down? It has been openly discussed in the media that with Win8, MS is not requiring computers to be locked down prior to consumer sale in order to qualify for the Win8-ready, but for Win-RT HW, (portable, not PC, that is not true). It was also clear that MS said they were not requiring lock down *this* release. Additionally, it was noted that any vendor could use this to lock down the bios before sale so that you had to go through them for upgrades. Where did you get the idea that this was for your benefit? You will only have the opportunity to make use of this if it hasn't been already intialized by the vendor (as MS already requires on MS-RT-ready HW), and is speculated may require on some future version of PC HW. Those features won't be available to you if they are already locked down by the vendor.
I got a heads-up on this due to a faulty UEFI bios that occasionally complains about my not having a license to upgrade my memory configuration (which my Dell machine doesn't 'currently' need), but in the future, the UEFI Bios will allow the vendor have a lock on what HW you can put into your computer and have it boot as well as what SW.
No, not at all, you have control over this, you can put your own keys in the BIOS just fine.
You are conflating the TPM and the UEFI BIOS -- though they may interact and the latter may rely on the former for key storage. That said, the UEFI bios is about being able to enable or disable each piece of HW in the machine and to assess it's integrity (that it hasn't' been tampered with). This allows guarantees of secure boot to a secure platform, as defined by *vendors* not by users... as it can be used to allow access to online services and licenses only after they verify that you aren't using a compromised machine that could be used to copy their content or obtain un-paid-for-access to something. Sure you can put keys in it *now*... but if it was initialized and password before sale to you, you wouldn't be able to. You might say, well, I wouldn't buy a computer that way... indeed, I might say that -- but if 80-90% of the market goes with mainstream OS's like appleOS or MS, that might require a locked down computer, then the prices for that 10-20% (if they are that many), will sky rocket as the market for those computers will be small -- computer-savvy folk only -- mainstream consumers won't care. You only have control as long as not practical to take it away from you.
thanks,
You're welcome. *sigh* -l -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 03:59:51PM -0800, Linda Walsh wrote:
Greg KH wrote:
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion.
Not at all, I want secure boot for my systems, with a key that I have control over, to ensure that no one else has installed a boot loader on it that I do not know about.
Who has access to the machine first? You or the vendor?
With a response like this, it's obvious this conversation isn't going to go anywhere fruitful, sorry. Best of luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg KH wrote:
On Mon, Nov 12, 2012 at 03:59:51PM -0800, Linda Walsh wrote:
Greg KH wrote:
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion. Not at all, I want secure boot for my systems, with a key that I have control over, to ensure that no one else has installed a boot loader on it that I do not know about.
Who has access to the machine first? You or the vendor?
With a response like this, it's obvious this conversation isn't going to go anywhere fruitful, sorry.
??? Don't read more into that it wasn't the "personal you", but the generic. I.e. this wasn't about you personally, nor about openSuSE, though it _could_ apply to openSuSE, I was thinking more about OEM's -- remember I mentioned the problem of not being able to restart my machine after a power cycle due to the license enforcement mechanism refusing to acknowledge 3rd party memory -- memory that had been installed in the machine. Fortunately I was able to reset it by removing all power from the machine (unplugging both of it's power supplies) and draining the capacitor -- it wasn't something stored in the EPROM, though I'm sure if it was intentional, it very well could be.
Best of luck,
--- Best of luck to you too, as depending on how it is used, and the OEM uptake on using the more restrictive features, availability of open-pc's and parts could get more pricey... Most assuredly, that would be harmful to end-users, and open-distro's... Linda -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/12/2012 1:35 PM, Greg KH wrote:
On Mon, Nov 12, 2012 at 04:00:11AM -0800, Linda Walsh wrote:
Michael Schroeder wrote:
On Thu, Nov 08, 2012 at 06:41:03PM +0100, Stefan Dirsch wrote:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Uh, doesn't that conflict with the new UEFI secure boot where all kernel modules have to be signed?
Cheers, Michael.
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion.
Not at all, I want secure boot for my systems, with a key that I have control over, to ensure that no one else has installed a boot loader on it that I do not know about.
For that reason alone, you should want it as well.
I got a heads-up on this due to a faulty UEFI bios that occasionally complains about my not having a license to upgrade my memory configuration (which my Dell machine doesn't 'currently' need), but in the future, the UEFI Bios will allow the vendor have a lock on what HW you can put into your computer and have it boot as well as what SW.
No, not at all, you have control over this, you can put your own keys in the BIOS just fine.
It's in the spec that the user can manage keys, and vendors have an impeccable history of implementing specs fully and correctly instead of just enough to satisfy Windows. That's why acpi was never a problem for anyone for instance. MS, Apple, large hardware vendors, they're all honest nice considerate principled guys who would never use their position to limit your options in their benefit. That's why vendor lock-in is a term I had to invent just now because no one ever did it for real. And if they do, well, small guys with principles can make hardware just as good and just as cheap as the big guys. Those System76 laptops are just as good as a macbook or a vaio. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Nov 16, 2012 at 5:41 PM, Brian K. White <brian@aljex.com> wrote:
No, not at all, you have control over this, you can put your own keys in the BIOS just fine.
It's in the spec that the user can manage keys, and vendors have an impeccable history of implementing specs fully and correctly instead of just enough to satisfy Windows. That's why acpi was never a problem for anyone for instance.
I guess there are 2 issues: 1) Getting past the UEFI Secure Boot authentication layer to access the bios key management API. 2) Using the API to actually update the keys. For the first issue, I believe that's one reason why Linux Foundation is getting a fully Microsoft Signed pre-boot loader out the door for anyone to use: http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundat... As I understand it, it should solve issue 1) above. If the bios doesn't actually provide a way to update the bios keys, I suspect even Microsoft will eventually be screwed. (ie. Assume with Windows 9 they need to change the signing key, how will they do it if the vendors don't have that API in their BIOSes?) Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 16 Nov 2012 18:33:48 -0500 Greg Freemyer <greg.freemyer@gmail.com> wrote:
how will they do it if the vendors don't have that API in their BIOSes?
You get BIOS update :) Problem solved. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-17 01:02, Rajko wrote:
You get BIOS update :) Problem solved.
No you don't. No vendor does a BIOS update a year after they sold the box (and W9 will come later). They do a machine update instead, and you pay for it in full. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCm53cACgkQja8UbcUWM1zDMAD/XvVl0wZBLN9fGd0/QptbpKR2 PYuXotN110DgO6x/E74A/RYf4AsGdb1uJOfOaPGAVUWQuCGHGQm2D0qVMkzghcTG =EyBa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat 17 Nov 2012 02:25:11 AM CST, Carlos E. R. wrote:
On 2012-11-17 01:02, Rajko wrote:
You get BIOS update :) Problem solved.
No you don't.
No vendor does a BIOS update a year after they sold the box (and W9 will come later). They do a machine update instead, and you pay for it in full.
Hi This notebook is a couple of years old, and had a BIOS update in May... BIOS Information Vendor: Dell Inc. Version: A12 Release Date: 05/09/2012 Not secure boot... but I can run TPM. -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.2 (x86_64) Kernel 3.4.11-2.16-desktop up 5 days 0:00, 5 users, load average: 0.21, 0.09, 0.06 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-17 03:10, Malcolm wrote:
This notebook is a couple of years old, and had a BIOS update in May...
Lucky you, or good vendor (or very bad bug) :-) - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCm8wcACgkQja8UbcUWM1z3jQEAlXGuwsSdFhikaf39RheYcPLu PJzV2iyAZntg/xcgvDwA+QE4QykDQb0GD3dnx7kseyR5iT1l6i9LwtJUlxVOMdqh =GIJG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat 17 Nov 2012 03:14:31 AM CST, Carlos E. R. wrote:
On 2012-11-17 03:10, Malcolm wrote:
This notebook is a couple of years old, and had a BIOS update in May...
Lucky you, or good vendor (or very bad bug) :-)
Just checked and there is another version A13 available... Latitude E5510 System BIOS A13 Release Date: 9/8/2012 This is just a management engine update, the previous ones were UEFI related booting and coming out of hibernation when running UEFI.... -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.2 (x86_64) Kernel 3.4.11-2.16-desktop up 5 days 0:10, 5 users, load average: 0.16, 0.10, 0.06 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2012-11-12 at 04:00 -0800, Linda Walsh wrote:
Michael Schroeder wrote:
On Thu, Nov 08, 2012 at 06:41:03PM +0100, Stefan Dirsch wrote:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Uh, doesn't that conflict with the new UEFI secure boot where all kernel modules have to be signed?
Cheers, Michael.
Secure boot is for HW vendors who want to turn PC's into locked-down pieces of HW that are only upgrade-able at the vendors' discretion.
Secure boot and UEFI are not required to do this if a vendor really wants. Some vendors have been doing this to varying degrees for ages using legacy BIOS. Using secure boot as a new ability to lock down at the SW level _might_ be arguable, but the HW has always been in control of the HW vendor.
I got a heads-up on this due to a faulty UEFI bios that occasionally complains about my not having a license to upgrade my memory configuration (which my Dell machine doesn't 'currently' need), but in the future, the UEFI Bios will allow the vendor have a lock on what HW you can put into your computer
Again, why would they need secure boot or UEFI to do this?
and have it boot as well as what SW.
The DKMS system isn't a conflict if the vendor allows your kernel to load modules, but say your vendor uses Windows RT (which doesn't allow HW to be shipped with an "open boot" and keep it's 'Windows RT ready' sticker... In such a case, DKMS wouldn't do you much good -- you can lock down linux at least as much as windows. You wouldn't be able to add after-purchase upgrades like a larger HD unless you pay the vendor for the privilege.
We know some people will likely hack the systems to get root, but for the average person, it will take away their ability to repurpose or reuse a computer for anything other than what the manufacturer. Seems like a large segment of the population is fine with not really owning their electronics, and only getting usage from it as they pay for such "by the App"...
I posted something similar to this when OSuse spoke out about providing a shim layer and 'buying into' this setup, in response to the announcement. Unfortunately, responses required "approval" before they were posted (I was logged in with my registered account). My response detailing the above and a few other similar scenarios enabled by vendors supporting signed-boot (vs. requiring PC's to be shipped with a toggle switch), was never approved for publication among the responses, though others appeared. I thought that odd, but not entirely surprising.
This happened on an openSUSE mailing list? -Scott -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Nov 12, 2012 at 11:48:15AM +0100, Michael Schroeder wrote:
On Thu, Nov 08, 2012 at 06:41:03PM +0100, Stefan Dirsch wrote:
This is *not* a bug, but an intentional change. ;-) The GLUE layer is now built on the target system.
Uh, doesn't that conflict with the new UEFI secure boot where all kernel modules have to be signed?
UEFI secure boot does not mandate signed kernel modules at all, that is a separate option that some distros are enabling because they want a more "secure" system than others. Please don't confuse the two, they are independant options. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (23)
-
Andrey Borzenkov -
Bernhard M. Wiedemann -
Brian K. White -
C -
Carlos E. R. -
Claudio Freire -
Daniele -
Dominique Leuenberger -
Dominique Leuenberger a.k.a DimStar -
Greg Freemyer -
Greg KH -
Jiri Slaby -
Joachim Schrod -
Juan Erbes -
Linda Walsh -
Ludwig Nussel -
Malcolm -
Michael Schroeder -
Michal Marek -
Rajko -
Scott Bahling -
Stefan Dirsch -
Stefan Seyfried