AVM/SUSE/Novell long-term relationship endangered
SUSE/Novell has announced that non-GPL kernel modules will no longer be part of future Novell products. Since SUSE Linux 6.3, AVM has been providing pre-compiled drivers for SUSE Linux. Since the release of SUSE 8.1 in September 2002, AVM drivers have been integrated into SUSE Linux distributions. Each time a new SUSE Linux Version beta cycle starts, AVM provides the latest drivers and Karsten Keil does an excellent job integrating those drivers. Therefore, a new SUSE Linux release goes hand in hand with the latest AVM driver development. At present, nearly the entire AVM product portfolio comes up with SUSE pre-compiled modules for ISDN and DSL devices and as such is part of the SUSE distribution: AVM ISDN-Controller FRITZ!Card Classic AVM ISDN-Controller A1 AVM ISDN-Controller FRITZ!Card PnP AVM ISDN-Controller FRITZ!Card PCI / PCI v2.x AVM ISDN-Controller FRITZ!Card PCMCIA AVM ISDN-Controller A1 PCMCIA AVM ISDN-Controller FRITZ!Card USB AVM ISDN-Controller FRITZ!Card USB v2.x AVM DSL/ISDN-Controller FRITZ!Card DSL AVM DSL/ISDN-Controller FRITZ!Card DSL v2.0 AVM DSL/ISDN-Controller FRITZ!Card DSL USB AVM DSL/ISDN-Controller FRITZ!Card DSL USB v2.0 AVM DSL-Controller FRITZ!Card DSL USB analog AVM DSL-Controller FRITZ!Card DSL SL AVM DSL-Controller FRITZ!Card DSL SL USB AVM ISDN-Controller B1 v1.4/v2.0/v3.0 (ISA) AVM ISDN-Controller B1 PCI / B1 PCI v4.0 AVM ISDN-Controller B1 PCMCIA AVM ISDN-Controller C2 AVM ISDN-Controller C4 AVM ISDN-Controller T1 AVM ISDN-Controller T1-B AVM FRITZ!X USB/ v2.0/ v3.0 AVM FRITZ!X ISDN AVM FRITZ!Box (AVM WLAN-Controller FRITZ!WLAN USB Stick) consequences In the past, the customer bought a fully functional distribution with the release of the brand new SUSE Linux. He could use ISDN fax G3, analog modem emulations or simply surf the internet via DSL/ISDN right away out of the box. For most users, that is the most important point in the distribution decision process. "Easy to use and right away surf the internet", that is the feedback we receive from our customers, when they visit AVM at fairs. The market share SUSE gained over past years is also based on SUSE's user-friendly policy of AVM driver integration. For six years now this strategic partnership with SUSE/Novell payed off for all parties. With Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The customer then needs to have an internet connection to download AVM's drivers or other packages. But without drivers the customer cannot download anything from the internet. conclusion This process will lead to our no longer being able to provide driver packages to the end user with a new SUSE/Novell box release. Our driver build and QS process will be subsequent to the box release instead of parallel to the beta cycle. The process is extended. Moreover, if the Novell decision is implemented as stated, the unique selling proposition of the SUSE Linux Distribution is diminished. And ultimately this decision will generate more support for both of us. This mail is not intended to provoke a discussion of open vs. closed source. The only intention of this mail is to make you aware of the consequences of such a decision. Kind regards Sven Schmidt AVM Audiovisuelles Marketing und Computersysteme GmbH Alt-Moabit 95, D-10559 Berlin http://www.avm.de Andreas Jaeger <aj@suse.de> An 09.02.2006 17:14 opensuse-announce@opensuse.org Kopie Thema [opensuse-announce] SUSE Linux 10.1 Update I'd like to give you an update on our beta process with the following list of topics: * Deliverable of Beta4 and further schedule * non-GPL kernel modules * Kernel Changes km_ packages * Major bug in Beta3: Fontconfig * Package manager major changes * XGL Deliverable of Beta4 and Further Schedule ========================================= Beta4 did not pass our internal tests, we have to delay it by one week. The FACTORY distribution has been updated with our current packages that everybody can use, but doing a complete installation from the current FACTORY tree is NOT recommended. You should just update single packages as needed. We have decided to release Beta 4 on 2006-02-16 and Beta 5 on 2006-02-23. We'll finalize the schedule after testing and evaluating these two betas. non-GPL kernel modules: ======================= Most developers of the kernel community consider non-GPL kernel modules to be infringing on their copyright. Novell does respect this position, and will no longer distribute non-GPL kernel modules as part of future products. Novell is working with vendors to find alternative ways to provide the functionality that was previously only available with non-GPL kernel modules. Kernel Changes / km_, kmp, and kernel-flavor-nongpl packages: ============================================================= We added support to cleanly handle packages that contain kernel modules by representing the dependencies of mouldes on the kernel ABI as rpm dependencies. This allows third party modules to be provided and integrated cleanly. Modules that were previously included in our kernel packages using the km_ package mechanism [1] have been converted to the new package format [2]; the km_ mechanism is no longer supported. Packages that contain additional kernel modules are now named name-kmp-kernelflavor (e.g., wlan-kmp-default. lirc-kmp-smp). The kmp mechanism [2] supports creating and using additional Kernel Module Packages easily and reliably. The kernel-kernelflavor-nongpl packages which contained modules that had non-GPL licenses have been removed. [1] The km_ package mechanism is described at http://www.suse.de/~agruen/kernel-doc/. [2] Kernel Module Packages Manual for CODE10, http://www.suse.de/~agruen/KMPM/ Major Bug in Beta3: Fontconfig ============================== It might be that X11 apps just crash or are really slow (installation of some packages took rather long), which was due to a bug in fontconfig. A first fix is in fontconfig packages in the Beta3 fixed-rpm directory on ftp.opensuse.org . Beta4 will fix most known bugs. Current packages are available at: ftp://ftp.suse.com/pub/projects/m17n/10.1 - If you use them, update to both fontconfig and fonts-config. The packages in there are newer than what is currently in the FACTORY tree. If you find bugs in the m17n packages, please report them in bugzilla stating the exact version you're using. Package Manager Major Changes ============================= We're replacing our package manager resolver library with a new version called "libzypp". libzypp is the integration of SUSE's yast2 Package manager and Ximian's libredcarpet. At Novell we used two solutions so far - Red Carpet and YaST package manager - and decided to merge both in a best of breed approach. The advantages for SUSE Linux are: * A better resolver than before * More information about why a package is installed or no solution is found * A better integration of all those feature that were added over the years to our package manager. * A command line interface ("rug") * A common handling of packages *and* patches * Dependency handling for update packages * A better way to handle selections (we call them now "patterns") * Remote management (not yet in SUSE Linux 10.1) * Additional repositories during installation (no GUI in SUSE Linux 10.1) * More flexibility in handling of different repositories, e.g. it is possible to have additional patterns for each repository. The new library handles yum metadata, YaST sources (both also remote via ftp, http, nfs and smb) and additionally Zenworks, Opencarpet and RCE (Red Carpet Enterprise) servers as installation sources. The alternatives smart and apt-get will also work as they did on SUSE Linux 10.0. Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. In addition to the existing packages, we're adding these new packages: * zmd: system daemon used by rug, zen-* * rug: Command line client * web-updater: Updater with more features than zen-updater * zen-updater: Simple updater * zen-remover: Tool to remove packages * zen-installer: Tool to add packages We're still working on the integration of "libzypp" into our tree, the package manager in our FACTORY tree is not yet fully functional. XGL === Xgl is an Xserver that uses OpenGL for its drawing operations. Xgl engineer David Reveman has posted enhancements to Xgl and a new compositor, 'Compiz' with a request that it be added to the freedesktop.org CVS repository. Some operations like antialiased font rendering is noticeably faster with this technology, and future graphics hardware might only have support for 3D operations and no 2D core any more. These additional packages have now been added to the SUSE Linux FACTORY tree. Note that compiz has a couple of build problems that need to be fixed before it will go out. For details on XGL, please check http://www.opensuse.org/Xgl . Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 [Anhang "att3brm9.dat" gelöscht von Sven Schmidt/AVM]
Hi, On Tue, 14 Feb 2006 s.schmidt@avm.de wrote:
SUSE/Novell has announced that non-GPL kernel modules will no longer be part of future Novell products. Since SUSE Linux 6.3, AVM has been providing pre-compiled drivers for SUSE Linux. Since the release of SUSE 8.1 in September 2002, AVM drivers have been integrated into SUSE Linux distributions. Each time a new SUSE Linux Version beta cycle starts, AVM provides the latest drivers and Karsten Keil does an excellent job integrating those drivers. Therefore, a new SUSE Linux release goes hand in hand with the latest AVM driver development. At present, nearly the entire AVM product portfolio comes up with SUSE pre-compiled modules for ISDN and DSL devices and as such is part of the SUSE distribution:
AVM ISDN-Controller FRITZ!Card Classic AVM ISDN-Controller A1 AVM ISDN-Controller FRITZ!Card PnP AVM ISDN-Controller FRITZ!Card PCI / PCI v2.x AVM ISDN-Controller FRITZ!Card PCMCIA AVM ISDN-Controller A1 PCMCIA AVM ISDN-Controller FRITZ!Card USB AVM ISDN-Controller FRITZ!Card USB v2.x AVM DSL/ISDN-Controller FRITZ!Card DSL AVM DSL/ISDN-Controller FRITZ!Card DSL v2.0 AVM DSL/ISDN-Controller FRITZ!Card DSL USB AVM DSL/ISDN-Controller FRITZ!Card DSL USB v2.0 AVM DSL-Controller FRITZ!Card DSL USB analog AVM DSL-Controller FRITZ!Card DSL SL AVM DSL-Controller FRITZ!Card DSL SL USB AVM ISDN-Controller B1 v1.4/v2.0/v3.0 (ISA) AVM ISDN-Controller B1 PCI / B1 PCI v4.0 AVM ISDN-Controller B1 PCMCIA AVM ISDN-Controller C2 AVM ISDN-Controller C4 AVM ISDN-Controller T1 AVM ISDN-Controller T1-B AVM FRITZ!X USB/ v2.0/ v3.0 AVM FRITZ!X ISDN AVM FRITZ!Box (AVM WLAN-Controller FRITZ!WLAN USB Stick)
consequences In the past, the customer bought a fully functional distribution with the release of the brand new SUSE Linux. He could use ISDN fax G3, analog modem emulations or simply surf the internet via DSL/ISDN right away out of the box. For most users, that is the most important point in the distribution decision process. "Easy to use and right away surf the internet", that is the feedback we receive from our customers, when they visit AVM at fairs. The market share SUSE gained over past years is also based on SUSE's user-friendly policy of AVM driver integration. For six years now this strategic partnership with SUSE/Novell payed off for all parties. With Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The customer then needs to have an internet connection to download AVM's drivers or other packages. But without drivers the customer cannot download anything from the internet.
conclusion This process will lead to our no longer being able to provide driver packages to the end user with a new SUSE/Novell box release. Our driver build and QS process will be subsequent to the box release instead of parallel to the beta cycle. The process is extended. Moreover, if the Novell decision is implemented as stated, the unique selling proposition of the SUSE Linux Distribution is diminished. And ultimately this decision will generate more support for both of us.
This mail is not intended to provoke a discussion of open vs. closed source. The only intention of this mail is to make you aware of the consequences of such a decision.
Kind regards Sven Schmidt
AVM Audiovisuelles Marketing und Computersysteme GmbH Alt-Moabit 95, D-10559 Berlin http://www.avm.de
You better should try to find a way which is acceptable for the Linux kernel developer community. As i understand it, Novell is offering active help to you if you are ready to go this way. Trying this, the "consequences" for you (AVM) would be much better. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On 02/14/2006 02:26 PM Eberhard Moenkeberg wrote:
As i understand it, Novell is offering active help to you if you are ready to go this way.
That is also what I heard.
Trying this, the "consequences" for you (AVM) would be much better.
I must say, this decision is a punch in the face for companies, that have linux drivers. Those that dont care about linux wont have a problem with this decision. So I find it a hard decision, but I guess it had to be made. Best all of us can do is try to support those companies. And hope they will continue to support linux. OJ -- Carpe diem - Seize the day. Carp in denim - There's a fish in my pants! (unknown)
Johannes Kastl schrieb:
On 02/14/2006 02:26 PM Eberhard Moenkeberg wrote:
I must say, this decision is a punch in the face for companies, that have linux drivers. Those that dont care about linux wont have a problem with this decision.
This decision is no problem for companies supporting linux (they have free drivers). It is, however, indeed a big problem for companies trying to profit from linux and giving nothing back in return. Using closed source linux drivers or windows drivers with ndiswrapper is similar. In both cases, the kernel becomes tainted and the result is not debuggable. However, companies creating closed source linux drivers claim to support linux. I fail to understand how they can make that claim. I'm happy that Windows Vista will force most drivers into userspace, thereby invalidating all claims that it can't be done. SOLUTION for fax servers with passive ISDN cards: ================================================= Regarding the original topic, there are a few possible solutions at hand for passive ISDN cards. An opensource driver without DSP algorithms should be simple to implement (no patented/secret code needed) and for faxing there are possible solutions mentioned in http://lists.debian.org/debian-user-german/2006/01/msg00080.html That leaves high-speed fax (supported by 2-3% of faxes on the market) and modem emulation to be solved. For fax servers this should be enough. Regards, Carl-Daniel
On 21 Mar 2006 at 15:23, Carl-Daniel Hailfinger wrote:
Johannes Kastl schrieb:
On 02/14/2006 02:26 PM Eberhard Moenkeberg wrote:
I must say, this decision is a punch in the face for companies, that have linux drivers. Those that dont care about linux wont have a problem with this decision.
This decision is no problem for companies supporting linux (they have free drivers). It is, however, indeed a big problem for companies trying to profit from linux and giving nothing back in return.
I disagree: developing a driver for Linux is a significant amount of work, and you get something (the driver). You don't get the sources, but you didn't pay for. I'm sure you could get the sources if you are paying for them.
Using closed source linux drivers or windows drivers with ndiswrapper is similar. In both cases, the kernel becomes tainted and the result is not debuggable. However, companies creating closed source linux drivers claim to support linux. I fail to understand how they can make that claim.
I'm happy that Windows Vista will force most drivers into userspace, thereby invalidating all claims that it can't be done.
Is it really user space, or is it a different ring of protection? [...] Regards, Ulrich
On Tue, Mar 21, 2006 at 04:00:17PM +0100, Ulrich Windl wrote:
I disagree: developing a driver for Linux is a significant amount of work, and you get something (the driver). You don't get the sources, but you didn't pay for. I'm sure you could get the sources if you are paying for them.
By buying the hardware, you inderectly pay for the software. If the hardwareseller decides to not use OSS, then he should also play buy the rules and either open the source or place them in such a way that it does not infringe the rights of others. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On 21 Mar 2006 at 16:18, houghi wrote:
On Tue, Mar 21, 2006 at 04:00:17PM +0100, Ulrich Windl wrote:
I disagree: developing a driver for Linux is a significant amount of work, and you get something (the driver). You don't get the sources, but you didn't pay for. I'm sure you could get the sources if you are paying for them.
By buying the hardware, you inderectly pay for the software. If the hardwareseller decides to not use OSS, then he should also play buy the rules and either open the source or place them in such a way that it does not infringe the rights of others.
Actually if I need the hardware, I prefer having a closed source driver very much over having no driver at all. For example: My Polaroid SprintScan 120 (discontinued product) is not supported by Linux, the vendor did not give away any programming information (not made by Polaroid), and there is a danger that "wild programming" will damage the hardware. So I have to use MS-Windows to use the scanner. The price you are paying for the hardware is hardly worth a few weeks work of some engineer. The real problem is the Chinese marketing: The build hardware for half of the costs and distribute the software they haven't developed for free. So the original vendor of hard- and software will not earn money. Regards, Ulrich
On Tue, Mar 21, 2006 at 04:52:46PM +0100, Ulrich Windl wrote:
Actually if I need the hardware, I prefer having a closed source driver very much over having no driver at all. For example: My Polaroid SprintScan 120 (discontinued product) is not supported by Linux, the vendor did not give away any programming information (not made by Polaroid), and there is a danger that "wild programming" will damage the hardware. So I have to use MS-Windows to use the scanner.
I am not saying that there should be no closed source programs. I am saying that if the producer decides to have a closed source program to protect his rights, he should also be concerned about the rights of others. <snip>
The real problem is the Chinese marketing: The build hardware for half of the costs and distribute the software they haven't developed for free. So the original vendor of hard- and software will not earn money.
Having closed source will hardly change that. And again, if the producer decides to have a closed source driver. please go ahead, but play by the rules and respect others rights as you wish them to respect yours. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Tuesday 14 February 2006 15:10, s.schmidt@avm.de wrote:
Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The
Is this really true? I would think that closed source drivers will only be missing from the OSS downloadable .iso images. They would probably be found in the supplemental CD and in the retail box DVD media. So how is it?
Am Dienstag, 14. Februar 2006 14:33 schrieb Silviu Marin-Caea:
On Tuesday 14 February 2006 15:10, s.schmidt@avm.de wrote:
Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The
Is this really true? I would think that closed source drivers will only be missing from the OSS downloadable .iso images. They would probably be found in the supplemental CD and in the retail box DVD media.
Reading really makes a difference some times. I quote once again:
Most developers of the kernel community consider non-GPL kernel modules to be infringing on their copyright. Novell does respect this position, and will no longer distribute non-GPL kernel modules as part of future products.
The retail box DVD _is_ a future product and as such included in the above statement. Greetings, Stephan
Am Dienstag, 14. Februar 2006 14:37 schrieb Stephan Kulow:
Am Dienstag, 14. Februar 2006 14:33 schrieb Silviu Marin-Caea:
On Tuesday 14 February 2006 15:10, s.schmidt@avm.de wrote:
Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The
Is this really true? I would think that closed source drivers will only be missing from the OSS downloadable .iso images. They would probably be found in the supplemental CD and in the retail box DVD media.
Reading really makes a difference some times. I quote once again:
Most developers of the kernel community consider non-GPL kernel modules to be infringing on their copyright. Novell does respect this position, and will no longer distribute non-GPL kernel modules as part of future products.
The retail box DVD _is_ a future product and as such included in the above statement.
Greetings, Stephan
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
I keep seeing this referred to, but I can't find any reference to it anywhere, I've glanced through the opensuse mail archives, opensuse news, Novell news, searched the Novell site (kernel remove/ban closed source/non-GPL), same with Google, for such a big change, it doesn't seem to have hit any news sites... Either that or the announcement doesn't include any of the keywords above... I would like to understand exactly what is involved in this decision and how it may affect me (E.g. I need the nVidia drivers currently for dual head and 3D, will these still be on YOU updates, or are they totally not available to SUSE customers through official channels? If the latter, how are SUSE getting around such restrictions to ensure their customers are unaffected by such a decision?). The only thing I found in the notes was the bit about kpm_ modules in Beta 4 in the announce list. I don't want to start ranting without knowing the facts, I also don't want to upgrade my dual-head set-up to 10.1 only to find I don't get any X afterwards... Dave
Is this really true? I would think that closed source drivers will only be missing from the OSS downloadable .iso images. They would probably be found in the supplemental CD and in the retail box DVD media.
Reading really makes a difference some times. I quote once again:
Most developers of the kernel community consider non-GPL kernel modules to be infringing on their copyright. Novell does respect this position, and will no longer distribute non-GPL kernel modules as part of future products.
The retail box DVD _is_ a future product and as such included in the above statement.
Greetings, Stephan
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
I keep seeing this referred to, but I can't find any reference to it anywhere, I've glanced through the opensuse mail archives, opensuse news, Novell news, searched the Novell site (kernel remove/ban closed source/non-GPL), same with Google, for such a big change, it doesn't seem to have hit any news sites... Either that or the announcement doesn't include any of the keywords above...
http://lists.opensuse.org/archive/opensuse-announce/2006-Feb/0004.html Ciao, Marcus
Am Dienstag, 14. Februar 2006 17:54 schrieb Marcus Meissner: <snip>
Reading really makes a difference some times. I quote once again:
Most developers of the kernel community consider non-GPL kernel modules to be infringing on their copyright. Novell does respect this position, and will no longer distribute non-GPL kernel modules as part of future products.
<snip> I keep seeing this referred to, but I can't find any reference to it anywhere, I've glanced through the opensuse mail archives, opensuse news, Novell news, searched the Novell site (kernel remove/ban closed source/non-GPL), same with Google, for such a big change, it doesn't seem to have hit any news sites... Either that or the announcement doesn't include any of the keywords above...
http://lists.opensuse.org/archive/opensuse-announce/2006-Feb/0004.html
Ciao, Marcus
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Yep, I found that, but that just refers to a change in the mechanism due to this concern. It doesn't explain what exactly is meant by this removal and its implications for end users, and what Novell/SUSE will be doing to ensure their customers aren't affected by this change. Dave
I keep seeing this referred to, but I can't find any reference to it anywhere, I've glanced through the opensuse mail archives, opensuse news, Novell news, searched the Novell site (kernel remove/ban closed source/non-GPL), same with Google, for such a big change, it doesn't seem to have hit any news sites... Either that or the announcement doesn't include any of the keywords above...
http://lists.opensuse.org/archive/opensuse-announce/2006-Feb/0004.html
Ciao, Marcus
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Yep, I found that, but that just refers to a change in the mechanism due to this concern. It doesn't explain what exactly is meant by this removal and its implications for end users, and what Novell/SUSE will be doing to ensure their customers aren't affected by this change.
Several modules will be gone from the shipping media. There will be an interface between 3rd party vendors and Novell to provide kernel modules (in the KMP style described there), making it easy for those 3rd party vendors to build modules. They can be offered by those vendors as easily installable resource (RPMs). Nothing is stopping normal packagers (like the packman guys, or who ever) to not just also offer kernel modules in this way. I understand (don't know for sure) that we are working with NVIDIA and ATI to make downloading their drivers possible this way. This is btw one reason for the packagemanager changes, that this package installation from multiple external sites is possible. Ciao, Marcus
Am Dienstag, 14. Februar 2006 18:06 schrieb Marcus Meissner:
I keep seeing this referred to, but I can't find any reference to it anywhere, I've glanced through the opensuse mail archives, opensuse news, Novell news, searched the Novell site (kernel remove/ban closed source/non-GPL), same with Google, for such a big change, it doesn't seem to have hit any news sites... Either that or the announcement doesn't include any of the keywords above...
http://lists.opensuse.org/archive/opensuse-announce/2006-Feb/0004.html
Ciao, Marcus
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Yep, I found that, but that just refers to a change in the mechanism due to this concern. It doesn't explain what exactly is meant by this removal and its implications for end users, and what Novell/SUSE will be doing to ensure their customers aren't affected by this change.
Several modules will be gone from the shipping media.
There will be an interface between 3rd party vendors and Novell to provide kernel modules (in the KMP style described there), making it easy for those 3rd party vendors to build modules.
They can be offered by those vendors as easily installable resource (RPMs).
Nothing is stopping normal packagers (like the packman guys, or who ever) to not just also offer kernel modules in this way.
I understand (don't know for sure) that we are working with NVIDIA and ATI to make downloading their drivers possible this way.
That's good news, especially if ATi drivers can be delivered in the same way as the nVidia drivers currently are (i.e. autoscript from YOU)! I love SUSE with my nVidia machines, run YOU during install and everything is up and working. With ATi it is a nightmare, tried installing the beta on my laptop and the ATi's driver installer barfed somewhere along the line :-(
This is btw one reason for the packagemanager changes, that this package installation from multiple external sites is possible.
Ciao, Marcus
Thanks Marcus. OK, things are starting to make sense. The way this information is slowly leaking out in snippets in emails and during the IRC meeting is frustrating and could lead to a lot of confusion and doubt. Something of this importance really should be communicated on the news or roadmap pages with detailed information on what it means for users. Dave
On Tue, Feb 14, 2006 at 06:35:14PM +0100, David Wright wrote:
The way this information is slowly leaking out in snippets in emails and during the IRC meeting is frustrating and could lead to a lot of confusion and doubt.
I agree. I still hear the tremours of the failed explantion on the fact that Gnome would be default instead of KDE on Novell Desktop. So perhaps a clear and unmistakable press-release is in order. When done rightly, it can be a lot of goodwill from the Linux comunity. When done wrong, it can hurt bad, real bad and explaining afterwards will be impossible. Perhaps suse-people can push the marketing people into action. houghi -- Death is nature's way of telling you to slow down
Am Dienstag, 14. Februar 2006 18:59 schrieb houghi:
On Tue, Feb 14, 2006 at 06:35:14PM +0100, David Wright wrote:
The way this information is slowly leaking out in snippets in emails and during the IRC meeting is frustrating and could lead to a lot of confusion and doubt.
I agree. I still hear the tremours of the failed explantion on the fact that Gnome would be default instead of KDE on Novell Desktop. So perhaps a clear and unmistakable press-release is in order.
When done rightly, it can be a lot of goodwill from the Linux comunity. When done wrong, it can hurt bad, real bad and explaining afterwards will be impossible.
Perhaps suse-people can push the marketing people into action.
houghi
I've just started a thread on the main opensuse list about this very topic. Dave
David Wright <david.wright@wright-is.com> writes:
Am Dienstag, 14. Februar 2006 18:06 schrieb Marcus Meissner:
[...] I understand (don't know for sure) that we are working with NVIDIA and ATI to make downloading their drivers possible this way.
That's good news, especially if ATi drivers can be delivered in the same way as the nVidia drivers currently are (i.e. autoscript from YOU)! I love SUSE with my nVidia machines, run YOU during install and everything is up and working. With ATi it is a nightmare, tried installing the beta on my laptop and the ATi's driver installer barfed somewhere along the line :-(
For 10.1 we will make a minor change regarding Nvidia due to the updated package manager: During installation there's only an automatic update of important packages. So, the optional Nvidia patch can only get downloaded from the Nvidia side after installation. Note that the new packagemanager does not support this in Beta4, we're working on it... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Dienstag, 14. Februar 2006 18:06 schrieb Marcus Meissner:
Several modules will be gone from the shipping media.
There will be an interface between 3rd party vendors and Novell to provide kernel modules (in the KMP style described there), making it easy for those 3rd party vendors to build modules.
They can be offered by those vendors as easily installable resource (RPMs).
Nothing is stopping normal packagers (like the packman guys, or who ever) to not just also offer kernel modules in this way.
I understand (don't know for sure) that we are working with NVIDIA and ATI to make downloading their drivers possible this way.
This is btw one reason for the packagemanager changes, that this package installation from multiple external sites is possible.
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet? Sure, hopefully you already ordered the big fat red warning sticker for the boxed product which explains, that things which just worked before, won't do anymore! While I understand SUSE/NOVELLs standpoint concerning nongpl modules/packages, I also see, that you're in fact loosing a unique selling proposition, like Sven Schmidt noted by imposing a chicken/egg problem to your users, which can only be circumvented, if carefully planning an install/upgrade process. As a consequence, a bulk of reasons to choose SUSE Linux as preferred OS and to recommend that to customers is lost, since you enqueue yourself in the broad range of arbitrary LINUX Products without outstanding differences and continously loosing on the user friendliness front. Yes, I feel kind of bitterness, since I was responsible for a couple of XYZ Linux to SUSE Linux (9.3) server transitions in the last few month exactly because the avm drivers are included. The main reason was, that this critical part has to be recompiled on kernel updates, which isn't something, I can expect from those customers. I really hope, that SUSE get the package manager - before 10.1 release - to the point, where it prevents kernel updates, unless external kernel modules, which are tagged as critical for it's proper operation, are available. Otherwise, automatic updates cannot work, which is the real selling point here.. Even if I'm not in a position to comment the way, this decision was made, but it's bad style to do it very shortly before a release - actively preventing concerned parties to catch up / work around the newly imposed issues. Really bad style. Pete
Am Dienstag, 14. Februar 2006 19:50 schrieb Hans-Peter Jansen:
Am Dienstag, 14. Februar 2006 18:06 schrieb Marcus Meissner:
Several modules will be gone from the shipping media.
There will be an interface between 3rd party vendors and Novell to provide kernel modules (in the KMP style described there), making it easy for those 3rd party vendors to build modules.
They can be offered by those vendors as easily installable resource (RPMs).
Nothing is stopping normal packagers (like the packman guys, or who ever) to not just also offer kernel modules in this way.
I understand (don't know for sure) that we are working with NVIDIA and ATI to make downloading their drivers possible this way.
This is btw one reason for the packagemanager changes, that this package installation from multiple external sites is possible.
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet?
[fecicious] Down load it before updating/installing? [/fecicious] See my comments elsewhere, this sort of information needs to be made generally available so people can prepare for the update, or wait until AVM (or other manufactuers) have re-written their drivers to comply.
Sure, hopefully you already ordered the big fat red warning sticker for the boxed product which explains, that things which just worked before, won't do anymore!
Hopefully this sort of change (dropping non-GPL Kernel modules) will soon be described on the News page, with some sort of impact anaylsis for existing users - what the likely scenarios are for things not working "out of the box" any more.
While I understand SUSE/NOVELLs standpoint concerning nongpl modules/packages, I also see, that you're in fact loosing a unique selling proposition, like Sven Schmidt noted by imposing a chicken/egg problem to your users, which can only be circumvented, if carefully planning an install/upgrade process.
As a consequence, a bulk of reasons to choose SUSE Linux as preferred OS and to recommend that to customers is lost, since you enqueue yourself in the broad range of arbitrary LINUX Products without outstanding differences and continously loosing on the user friendliness front.
Yes, I feel kind of bitterness, since I was responsible for a couple of XYZ Linux to SUSE Linux (9.3) server transitions in the last few month exactly because the avm drivers are included. The main reason was, that this critical part has to be recompiled on kernel updates, which isn't something, I can expect from those customers.
It first came to my attention a week or so ago (that the non-GPL Kernel modules were being dropped), so I would expect people like AVM have known for longer. There are alternatives which AVM can work towards, either open sourcing their drivers or using the KPM route described by AJ in the IRC meeting minutes from 6 Feb. Putting all the blame on SUSE is unfair, AVM have had time, and still have more time until the release of 10.1, to "get their act together" in this regard. That said, I was very impressed with AVM's customer support, I bought a Fritz!Box DSL WLAN/VOIP box and it looked like somebody in the shop had opened the packaging and removed the CD, 24hrs. after purchase AVM had delivered a replacement driver CD. If they can put this sort of commitment into working with the Linux community to provide drivers which are acceptable, I can't see this being a long term problem...
I really hope, that SUSE get the package manager - before 10.1 release - to the point, where it prevents kernel updates, unless external kernel modules, which are tagged as critical for it's proper operation, are available. Otherwise, automatic updates cannot work, which is the real selling point here..
Even if I'm not in a position to comment the way, this decision was made, but it's bad style to do it very shortly before a release - actively preventing concerned parties to catch up / work around the newly imposed issues. Really bad style.
Pete
Personally I would like to see a commitment by the driver makers, such as AVM, nVidia and Ati to move towards either OS'ing their drivers (ideal world) or at least moving to User Level drivers or KPM and if the driver makers are showing true commitment to get the conversion done, then including the old style as an interim measure for the next release if the new style drivers can't be made available on time. This would act as a carrot and stick approach for them, if they genuinely make an effort, they have a little more time to get their acts together (10.2 beta) and if they appear unwilling to make any effort, just drop their drivers. But I guess this would be too tricky to judge fairly... I also don't know when this measure was actually announced, I just "picked it up in passing" at the 6 Feb IRC meeting, so I don't know if the manufacturers have already had a reasonable amount of time... Dave
On 14 Feb 2006 at 19:50, Hans-Peter Jansen wrote: [...]
Sure, hopefully you already ordered the big fat red warning sticker for the boxed product which explains, that things which just worked before, won't do anymore! [...]
I'd say that the media only includes GPL software now, and that Internet access is needed to download packages from non Novell-supported sites to complete the installation (media players, MP3, graphics drivers, modem drivers, printer drivers, ISDN, webcams, tuners, etc.). Maybe some would see that equivalent with "don't buy". Regards, Ulrich
Hello, Ulrich Windl wrote:
I'd say that the media only includes GPL software now, and that Internet access is needed to download packages from non Novell-supported sites to complete the installation (media players, MP3, graphics drivers, modem drivers, printer drivers, ISDN, webcams, tuners, etc.).
Maybe some would see that equivalent with "don't buy".
I'm sorry to say, but I agree. The main selling point of SUSE was in my experience, that everything worked out of the box. And not just worked, but worked very well. My colleagues worked sometimes literally weeks to get Debian/Fedora/etc running at all on a hardware, and then to get it running STABLE. When they gave up, I installed SUSE on it without needing to download extra sources, patch the installation sources, building my own kernel (to make quick security fixes difficult) etc. On their notebooks even Debian fans use now SUSE ;-) And they provided very good feedback on SUSE, as they are seasoned sysadmins. But if we get back to stone age and support only a smaller subset of drivers, and a lot others will just go away, as the main selling point: easy installation and exceptional hardware support just go away. Bye, -- CzP http://peter.czanik.hu/
On Wednesday 15 February 2006 09:30, Peter Czanik wrote:
Maybe some would see that equivalent with "don't buy".
I'm sorry to say, but I agree. The main selling point of SUSE was in my experience, that everything worked out of the box. And not just worked,
I think the issue is having proprietary binary-only drivers in the kernel vs. userspace. If those drivers are modified to be in userspace, SUSE will ship them on the media and it would work out-of-the-box. Is this right?
Am Mittwoch, 15. Februar 2006 08:47 schrieb Silviu Marin-Caea:
On Wednesday 15 February 2006 09:30, Peter Czanik wrote:
Maybe some would see that equivalent with "don't buy".
I'm sorry to say, but I agree. The main selling point of SUSE was in my experience, that everything worked out of the box. And not just worked,
I think the issue is having proprietary binary-only drivers in the kernel vs. userspace. If those drivers are modified to be in userspace, SUSE will ship them on the media and it would work out-of-the-box.
Is this right?
With no official statement, just the dev notes and what was said at the last IRC meeting, that is how I read the situation, yes. Dave
Silviu Marin-Caea <silviu_marin-caea@fieldinsights.ro> writes:
On Wednesday 15 February 2006 09:30, Peter Czanik wrote:
Maybe some would see that equivalent with "don't buy".
I'm sorry to say, but I agree. The main selling point of SUSE was in my experience, that everything worked out of the box. And not just worked,
I think the issue is having proprietary binary-only drivers in the kernel vs. userspace. If those drivers are modified to be in userspace, SUSE will ship them on the media and it would work out-of-the-box.
Is this right?
According to my understanding of the GPL, if there is a GPL kernel driver that interacts somehow with a binary-only user-level program, this would be fine - and Novell could add the GPL kernel driver in any case - and the binary-only user-level program if we have the rights to distribute it (note: it would go to the FACTORY-EXTRA tree), Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Mittwoch, 15. Februar 2006 08:30 schrieb Peter Czanik:
Hello,
Ulrich Windl wrote:
I'd say that the media only includes GPL software now, and that Internet access is needed to download packages from non Novell-supported sites to complete the installation (media players, MP3, graphics drivers, modem drivers, printer drivers, ISDN, webcams, tuners, etc.).
Maybe some would see that equivalent with "don't buy".
I'm sorry to say, but I agree. The main selling point of SUSE was in my experience, that everything worked out of the box. And not just worked, but worked very well. My colleagues worked sometimes literally weeks to get Debian/Fedora/etc running at all on a hardware, and then to get it running STABLE. When they gave up, I installed SUSE on it without needing to download extra sources, patch the installation sources, building my own kernel (to make quick security fixes difficult) etc. On their notebooks even Debian fans use now SUSE ;-) And they provided very good feedback on SUSE, as they are seasoned sysadmins. But if we get back to stone age and support only a smaller subset of drivers, and a lot others will just go away, as the main selling point: easy installation and exceptional hardware support just go away. Bye,
I agree in part with what you say. One of the main reasons I use SUSE is I just plug it in and go on most of my machines, my recalcitrent ATi chipsetted laptop is another story... My desktops are usually installed and patched and 100% working within an hour of shoving in the SUSE DVD. But as I have said elsewhere in this thread, I'd like more information before starting to really rant. When was this decision made? How long have suppliers had to work on alternatives? (This is no different to MS changing the driver architecture for Windows ME or XP after 95/2000 driver models, or the current changes for Vista, and the suppliers rallied round and provided new drivers for them, eventually.) Until we have all the facts, we can rally against Novell as much as we want, but if they informed the hardware manufacturers 6 months ago and they are saying now that they haven't started on the alternatives, then that is their fault, not Novell's/the community's; if however they announced this in January/February and expect everything to be complete in time for the next Beta, then they obviously have a screw loose, and junking the non-GPL Kernel drivers without waiting to see if anybody can provide replacements seems like a bad idea. Please see my reply elsewhere on this. We need full disclosure from Novell/opensuse on exactly what the implications are, when this decision was made and who is co-operating, who isn't and what contingencies they have in case the suppliers aren't able to meet the deadlines for 10.1... Marcus said yesterday, for example, that he believes nVidia and ATi are working with Novell on providing alternative drivers for their video cards, if this is true, then this great news, but it is just more rumour, we need hard facts. The current situation just lends itself to more and more FUD from those with a vested interest in the "old ways". Dave
Hi, Peter Czanik schrieb:
But if we get back to stone age and support only a smaller subset of drivers, and a lot others will just go away, as the main selling point: easy installation and exceptional hardware support just go away.
This only affects a *small* subset of ISDN and DSL cards and exactly one wireless chipset (atheros). I fully expect that the GPL driver for the wireless chipset will soon be stable enough to be shipped with the media and that the ISDN case can be completely resolved with GPL drivers if you don't need analog modem emulation. That means the only with a possible support problem are the Fritz-DSL cards (I don't have enough information about these). Proprietary graphics drivers are not affected as they were not shipped on the media anyway. So let's summarize: Short-term changes: Less WLAN/ISDN/DSL cards supported out of the box. Long-term changes: Less DSL cards supported out of the box. Personally, I think this is entirely acceptable since it reduces support load on SUSE kernel developers (less tainted oopses) and respects the express will of the kernel developing community. I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments? Regards, Carl-Daniel -- http://www.hailfinger.org/
On Wed, Feb 15, 2006 at 12:29:18PM +0100, Carl-Daniel Hailfinger wrote:
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
Drop the "New" from the title. If you insist on the New, you must make an "Old driver architecture" as well. Just one aliea describing how it is up untill 10.0 should be enough and would be, I asume, on that page anyway. houghi -- So far as I can remember, there is not one word in the Gospels in praise of intelligence. -- Bertrand Russell
Am Mittwoch, 15. Februar 2006 12:29 schrieb Carl-Daniel Hailfinger:
Hi,
Peter Czanik schrieb:
But if we get back to stone age and support only a smaller subset of drivers, and a lot others will just go away, as the main selling point: easy installation and exceptional hardware support just go away.
This only affects a *small* subset of ISDN and DSL cards and exactly one wireless chipset (atheros). I fully expect that the GPL driver
The only wireless chipset/pci card, which handles wpa encryption - cool. Especially, since a SuSE colleague actively recommended such cards: https://bugzilla.novell.com/show_bug.cgi?id=104662#c2
for the wireless chipset will soon be stable enough to be shipped with the media and that the ISDN case can be completely resolved with GPL drivers if you don't need analog modem emulation. That means the only with a possible support problem are the Fritz-DSL cards (I don't have enough information about these). [...]
So let's summarize: Short-term changes: Less WLAN/ISDN/DSL cards supported out of the box. Long-term changes: Less DSL cards supported out of the box.
You're expressing an attitude here that may be adequate for an independent kernel developer, but cannot be accepted by a serious product manager for a product with such a wide propagation. This is in no way an exceptable solution for anybody owning any of these pieces. Imagine - some companies I advised SUSE Linux - depend on a e.g. working fax solution. Sure, 10.1 disqualifies in this discipline. I don't believe, that AVM will/is able to provide any userspace solution for ISDN fax emulation in the 10.1 timeframe. AFAICS, there's even a framework missing - if possible at all - which would allow this and meet the tight timing requirement of such a task. IOW, if a customer asks me for an upgrade of his SUSE and Fritzcard!PCI based fax solution, I have to tell him, that he has to buy an expensive AVM B1 card and throw away the old one, what do you think they will reply to me?
Personally, I think this is entirely acceptable since it reduces support load on SUSE kernel developers (less tainted oopses) and respects the express will of the kernel developing community.
Sure, disappointing customers definitely reduces the support load in every company. Such an attitude will actively damage the reputation of SUSE and you know - one disappointed customer has much more weight (and will spread the word louder) than ten satisfied ones.
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
How about "New driver architecture - Novells disaster seekers strike back" Pete
On Wed, Feb 15, 2006 at 10:31:33PM +0100, Hans-Peter Jansen wrote:
IOW, if a customer asks me for an upgrade of his SUSE and Fritzcard!PCI based fax solution, I have to tell him, that he has to buy an expensive AVM B1 card and throw away the old one, what do you think they will reply to me?
Install 10.0 or wait for 10.2 in 6 to 8 months. Or is this customer going to upgrade each and every 6 months?
How about "New driver architecture - Novells disaster seekers strike back"
How about trying to work at a solution? As long as the OP does not reply on any in this threat, I am asuming he is just trolling. I hope he can prove me wrong and work with those who can on a solution. houghi -- You should never bet against anything in science at odds of more than about 10^12 to 1. -- Ernest Rutherford
Hi, On Wed, 15 Feb 2006, Hans-Peter Jansen wrote:
Am Mittwoch, 15. Februar 2006 12:29 schrieb Carl-Daniel Hailfinger:
Peter Czanik schrieb:
But if we get back to stone age and support only a smaller subset of drivers, and a lot others will just go away, as the main selling point: easy installation and exceptional hardware support just go away.
This only affects a *small* subset of ISDN and DSL cards and exactly one wireless chipset (atheros). I fully expect that the GPL driver
The only wireless chipset/pci card, which handles wpa encryption - cool. Especially, since a SuSE colleague actively recommended such cards: https://bugzilla.novell.com/show_bug.cgi?id=104662#c2
for the wireless chipset will soon be stable enough to be shipped with the media and that the ISDN case can be completely resolved with GPL drivers if you don't need analog modem emulation. That means the only with a possible support problem are the Fritz-DSL cards (I don't have enough information about these). [...]
So let's summarize: Short-term changes: Less WLAN/ISDN/DSL cards supported out of the box. Long-term changes: Less DSL cards supported out of the box.
You're expressing an attitude here that may be adequate for an independent kernel developer, but cannot be accepted by a serious product manager for a product with such a wide propagation.
This is in no way an exceptable solution for anybody owning any of these pieces. Imagine - some companies I advised SUSE Linux - depend on a e.g. working fax solution. Sure, 10.1 disqualifies in this discipline.
I don't believe, that AVM will/is able to provide any userspace solution for ISDN fax emulation in the 10.1 timeframe. AFAICS, there's even a framework missing - if possible at all - which would allow this and meet the tight timing requirement of such a task.
IOW, if a customer asks me for an upgrade of his SUSE and Fritzcard!PCI based fax solution, I have to tell him, that he has to buy an expensive AVM B1 card and throw away the old one, what do you think they will reply to me?
Personally, I think this is entirely acceptable since it reduces support load on SUSE kernel developers (less tainted oopses) and respects the express will of the kernel developing community.
Sure, disappointing customers definitely reduces the support load in every company. Such an attitude will actively damage the reputation of SUSE and you know - one disappointed customer has much more weight (and will spread the word louder) than ten satisfied ones.
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
How about "New driver architecture - Novells disaster seekers strike back"
At all, a very good statement. Let's hope Novell has success with their help offer to the driver vendors. It is Novell's own interest, not that of the driver vendors... Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Wed, Feb 15, 2006 at 11:21:00PM +0100, Eberhard Moenkeberg wrote:
Let's hope Novell has success with their help offer to the driver vendors. It is Novell's own interest, not that of the driver vendors...
The help has been offerd. There has not yet been any reaction, as far as I can see. houghi -- It is better for civilization to be going down the drain than to be coming up it. -- Henry Allen
Hi, On Thu, 16 Feb 2006, houghi wrote:
On Wed, Feb 15, 2006 at 11:21:00PM +0100, Eberhard Moenkeberg wrote:
Let's hope Novell has success with their help offer to the driver vendors. It is Novell's own interest, not that of the driver vendors...
The help has been offerd. There has not yet been any reaction, as far as I can see.
You won't see it here. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Thu, Feb 16, 2006 at 12:13:47AM +0100, Eberhard Moenkeberg wrote:
The help has been offerd. There has not yet been any reaction, as far as I can see.
You won't see it here.
Why not? Does the above mean that there won't be any solution, or that you are working on a solution behind the screens? If the latter a `we are currently working with ... on a solution.` should be enough. Communication should really go up. Especially when you notice that it is such an important issue. houghi -- There was a gay countess of Bray, And you may think it odd when I say, That in spite of high station, Rank and education, She always spelled cunt with a "k".
Hi, On Thu, 16 Feb 2006, houghi wrote:
On Thu, Feb 16, 2006 at 12:13:47AM +0100, Eberhard Moenkeberg wrote:
The help has been offerd. There has not yet been any reaction, as far as I can see.
You won't see it here.
Why not? Does the above mean that there won't be any solution, or that you are working on a solution behind the screens?
If the latter a `we are currently working with ... on a solution.` should be enough. Communication should really go up. Especially when you notice that it is such an important issue.
My guess is: AVM just has dropped a statement here, they won't discuss here. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Thu, Feb 16, 2006 at 09:12:16AM +0100, Eberhard Moenkeberg wrote:
My guess is: AVM just has dropped a statement here, they won't discuss here.
Ah, it was a guestimate. Misread that, sorry. houghi -- We have reason to believe that man first walked upright to free his hands for masturbation. -- Lily Tomlin
On Thu, Feb 16, 2006 at 09:08:03AM +0100, houghi wrote:
On Thu, Feb 16, 2006 at 12:13:47AM +0100, Eberhard Moenkeberg wrote:
The help has been offerd. There has not yet been any reaction, as far as I can see.
You won't see it here.
Why not? Does the above mean that there won't be any solution, or that you are working on a solution behind the screens?
If the latter a `we are currently working with ... on a solution.` should be enough. Communication should really go up. Especially when you notice that it is such an important issue.
Nah! Consulting work with closed source driver vendors is nothing that is part of the _open_SUSE project and thus not necessarily done in public. But actually it would be a smart move of AVM to publicly state it if they are working on a solution if they publicly announced the problem because otherwise they leave the impression that they whine in public but are not actually interested in a solution which in my opinion does not really support their good reputation. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Thu, Feb 16, 2006 at 09:19:31AM +0100, Robert Schiele wrote:
Nah! Consulting work with closed source driver vendors is nothing that is part of the _open_SUSE project and thus not necessarily done in public.
I agree, however ...
But actually it would be a smart move of AVM to publicly state it if they are working on a solution if they publicly announced the problem because otherwise they leave the impression that they whine in public but are not actually interested in a solution which in my opinion does not really support their good reputation.
AVM _made_ is something that _can_ be discussed by posting here. Naturaly I can understand that there is a NDA. At least for the technical part. As I see it now AVM is just another troll stirring things up with a hit and run posting, trying to preasurise Novell in putting presure on the Kernell people, so everybody will do what AVM wants. Wankers. (Please proove me wrong.) houghi -- The very ink with which all history is written is merely fluid prejudice. -- Mark Twain
On 16 Feb 2006 at 0:02, houghi wrote:
On Wed, Feb 15, 2006 at 11:21:00PM +0100, Eberhard Moenkeberg wrote:
Let's hope Novell has success with their help offer to the driver vendors. It is Novell's own interest, not that of the driver vendors...
The help has been offerd. There has not yet been any reaction, as far as I can see.
I can foresee statements like "Linux doesn't work" with the upcoming releases, thereby wondering how much Microsoft did pay to Novell for these decisions. (Because many users will dump Linux and go back to Microsoft). Maybe there are other products that fit the users' needs better. For less good hardware support you could use Debian years ago already. Regards, Ulrich
houghi -- It is better for civilization to be going down the drain than to be coming up it. -- Henry Allen
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Hi, On Thu, 16 Feb 2006, Ulrich Windl wrote:
On 16 Feb 2006 at 0:02, houghi wrote:
On Wed, Feb 15, 2006 at 11:21:00PM +0100, Eberhard Moenkeberg wrote:
Let's hope Novell has success with their help offer to the driver vendors. It is Novell's own interest, not that of the driver vendors...
The help has been offerd. There has not yet been any reaction, as far as I can see.
I can foresee statements like "Linux doesn't work" with the upcoming releases, thereby wondering how much Microsoft did pay to Novell for these decisions. (Because many users will dump Linux and go back to Microsoft). Maybe there are other products that fit the users' needs better. For less good hardware support you could use Debian years ago already.
Don't paint it black. Novell has started a "process" and has offered migration help to the vendors. Maybe the current lack of features will speed up the solution. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
Hans-Peter Jansen schrieb:
Am Mittwoch, 15. Februar 2006 12:29 schrieb Carl-Daniel Hailfinger:
Peter Czanik schrieb:
But if we get back to stone age and support only a smaller subset of drivers, and a lot others will just go away, as the main selling point: easy installation and exceptional hardware support just go away.
This only affects a *small* subset of ISDN and DSL cards and exactly one wireless chipset (atheros). I fully expect that the GPL driver
The only wireless chipset/pci card, which handles wpa encryption - cool. Especially, since a SuSE colleague actively recommended such cards: https://bugzilla.novell.com/show_bug.cgi?id=104662#c2
Yes, the state of wireless under Linux is bad. Fortunately, a bunch of developers have pooled their efforts to get wireless support for every available chipset into mainline. I expect this project to be finished within the next 6 months. If you want WPA under Linux with GPL drivers, try the Intel PRO/Wireless 2200BG chipset. Prism54.org seems to have preliminary WPA support as well.
for the wireless chipset will soon be stable enough to be shipped with the media and that the ISDN case can be completely resolved with GPL drivers if you don't need analog modem emulation. That means the only with a possible support problem are the Fritz-DSL cards (I don't have enough information about these). [...]
So let's summarize: Short-term changes: Less WLAN/ISDN/DSL cards supported out of the box. Long-term changes: Less DSL cards supported out of the box.
You're expressing an attitude here that may be adequate for an independent kernel developer, but cannot be accepted by a serious
Exactly.
product manager for a product with such a wide propagation.
Because I'm an independent kernel developer, it is not my task to comment on project management decisions.
This is in no way an exceptable solution for anybody owning any of these pieces. Imagine - some companies I advised SUSE Linux - depend on a e.g. working fax solution. Sure, 10.1 disqualifies in this discipline.
So 10.1 will work perfectly for you.
I don't believe, that AVM will/is able to provide any userspace solution for ISDN fax emulation in the 10.1 timeframe. AFAICS, there's even a framework missing - if possible at all - which would allow this and meet the tight timing requirement of such a task.
If they don't want to provide a userspace solution, they can still ship binary only kernel modules. And the infrastructure for that is in place. Please look at the following link for details. http://www.suse.de/~agruen/KMPM/KernelModulePackagesManual-CODE10.pdf
IOW, if a customer asks me for an upgrade of his SUSE and Fritzcard!PCI based fax solution, I have to tell him, that he has to buy an expensive AVM B1 card and throw away the old one, what do you think they will reply to me?
It will work, see above.
Sure, disappointing customers definitely reduces the support load in every company. Such an attitude will actively damage the reputation of SUSE and you know - one disappointed customer has much more weight (and will spread the word louder) than ten satisfied ones.
I hope this will not damage the reputation of SUSE. I expect that you will be able to download all binary only drivers in RPM packages before 10.1 hits the shelves. So the only people disappointed will be those who don't download the drivers before installing SUSE Linux 10.1 and have no other way to obtain these drivers. Does this answer your questions? Regards, Carl-Daniel -- http://www.hailfinger.org/
Dear Carl-Daniel, Am Donnerstag, 16. Februar 2006 00:49 schrieb Carl-Daniel Hailfinger:
Hans-Peter Jansen schrieb:
Am Mittwoch, 15. Februar 2006 12:29 schrieb Carl-Daniel Hailfinger:
Peter Czanik schrieb:
This only affects a *small* subset of ISDN and DSL cards and exactly one wireless chipset (atheros). I fully expect that the GPL driver
The only wireless chipset/pci card, which handles wpa encryption - cool. Especially, since a SuSE colleague actively recommended such cards: https://bugzilla.novell.com/show_bug.cgi?id=104662#c2
Yes, the state of wireless under Linux is bad. Fortunately, a bunch of developers have pooled their efforts to get wireless support for every available chipset into mainline. I expect this project to be finished within the next 6 months. If you want WPA under Linux with GPL drivers, try the Intel PRO/Wireless 2200BG chipset. Prism54.org seems to have preliminary WPA support as well.
Try to buy a PCI card with PRO/Wireless 2200BG chipset. At least as I found out in my awful trail last year, it's just not available! (not talking about miniPCI adapters, btw). I'm heavily commited to SUSE since a decade, I've learned the hard way to try to select hardware, which simply runs out of the box, and avoid preliminary driver stuff most of the day, since I'm forced to get some real work done by the help of computers, but still using much time by instructing computers to behave..
I don't believe, that AVM will/is able to provide any userspace solution for ISDN fax emulation in the 10.1 timeframe. AFAICS, there's even a framework missing - if possible at all - which would allow this and meet the tight timing requirement of such a task.
If they don't want to provide a userspace solution, they can still ship binary only kernel modules. And the infrastructure for that is in place. Please look at the following link for details. http://www.suse.de/~agruen/KMPM/KernelModulePackagesManual-CODE10.pdf
That's the theory with pronouncement of the words "they can still"! I already tried to rebuild the AVM driver rpm for 9.3 with current stuff because of some problems with the DSL PCI card, and it was such a mess, that I finally resigned to build a proper rpm (and just used the .ko, I needed)! [I do build a lot RPMs, even before breakfast and caffeination ;)] I fear, AVM is just missing the man power to provide a stable long term SUSE kernel support for such a critical mission (kernel modules are a delicate mission, no matter how much support is given by SUSE/community in this regard!). And the quietness in the course of this thread doesn't turn me optimistic either..
Sure, disappointing customers definitely reduces the support load in every company. Such an attitude will actively damage the reputation of SUSE and you know - one disappointed customer has much more weight (and will spread the word louder) than ten satisfied ones.
I hope this will not damage the reputation of SUSE. I expect that you will be able to download all binary only drivers in RPM packages before 10.1 hits the shelves. So the only people disappointed will be those who don't download the drivers before installing SUSE Linux 10.1 and have no other way to obtain these drivers.
I really hope, AVM prove me wrong, and prove you right. ATM, I only find you overly optimistic, which is an attribute, I must have lost somewhere over the last two decades where I've been involved in that business. Pete
I don't believe, that AVM will/is able to provide any userspace solution for ISDN fax emulation in the 10.1 timeframe. AFAICS, there's even a framework missing - if possible at all - which would allow this and meet the tight timing requirement of such a task.
If they don't want to provide a userspace solution, they can still ship binary only kernel modules. And the infrastructure for that is in place. Please look at the following link for details. http://www.suse.de/~agruen/KMPM/KernelModulePackagesManual-CODE10.pdf
That does not help the folks owning a USB device, does it? ;-) A kernel module stays a kernel module even if wrapped nicely! If it the upcoming kernels really prohibit loading non-GPL USB drivers, there is no way out: Userspace or being disconnected. IMHO, userspace won't happen.
IOW, if a customer asks me for an upgrade of his SUSE and Fritzcard!PCI based fax solution, I have to tell him, that he has to buy an expensive AVM B1 card and throw away the old one, what do you think they will reply to me?
It will work, see above.
Not for everyone, see above.
I hope this will not damage the reputation of SUSE. I expect that you will be able to download all binary only drivers in RPM packages before 10.1 hits the shelves. So the only people disappointed will be those who don't download the drivers before installing SUSE Linux 10.1 and have no other way to obtain these drivers.
... plus those unable to understand that even with a driver at hand, no connection to the internet can be made. I know, this update to the kernel USB API is not mainly SUSE's problem (although Greg, the originator of the patch, works for SUSE/NOVELL ;-)), but the bottom line is clear: 10.1 will be the no-go-box for many users out there. I can only hope, that they have a second running installation (i.e. an installation with Internet connection) available to them... Take care, Lysander Pensch -- DSL-Aktion wegen gro�er Nachfrage bis 28.2.2006 verl�ngert: GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
Lysander Pensch schrieb:
I don't believe, that AVM will/is able to provide any userspace solution for ISDN fax emulation in the 10.1 timeframe. AFAICS, there's even a framework missing - if possible at all - which would allow this and meet the tight timing requirement of such a task.
If they don't want to provide a userspace solution, they can still ship binary only kernel modules. And the infrastructure for that is in place. Please look at the following link for details. http://www.suse.de/~agruen/KMPM/KernelModulePackagesManual-CODE10.pdf
That does not help the folks owning a USB device, does it? ;-) A kernel module stays a kernel module even if wrapped nicely! If it the upcoming kernels really prohibit loading non-GPL USB drivers, there is no way out: Userspace or being disconnected. IMHO, userspace won't happen.
No, the upcoming kernels don't prohibit loading non-GPL USB drivers, but from 2008 or so it (don't remember the exact date) will do that, so this won't affect the next few SUSE releases (assuming the normal schdule).
I hope this will not damage the reputation of SUSE. I expect that you will be able to download all binary only drivers in RPM packages before 10.1 hits the shelves. So the only people disappointed will be those who don't download the drivers before installing SUSE Linux 10.1 and have no other way to obtain these drivers.
... plus those unable to understand that even with a driver at hand, no connection to the internet can be made. I know, this update to the kernel USB API is not mainly SUSE's problem (although Greg, the originator of the patch, works for SUSE/NOVELL ;-)), but the bottom line is clear: 10.1 will be the no-go-box for many users out there. I can only hope, that they have a second running installation (i.e. an installation with Internet connection) available to them...
If there are drivers, they will work. Greg was simply unaware of these USB modules and his reaction to the first mail from AVM was: "Have you asked Greg why he did this?" http://marc.theaimsgroup.com/?l=linux-kernel&m=113917300232535&w=4 That patch now has been reversed by Greg and is scheduled for reinclusion in 2008. It seems AVM did not attempt to communicate with anyone before making (nearly identical) press releases both times they felt affected. Regards, Carl-Daniel
On Wednesday 15 February 2006 23:31, Hans-Peter Jansen wrote:
This is in no way an exceptable solution for anybody owning any of these pieces. Imagine - some companies I advised SUSE Linux - depend on a e.g. working fax solution. Sure, 10.1 disqualifies in this discipline.
Why do you recommend to *companies* a product designed for home use/enthusiasts? NLD9 and SLES9 are the right product for companies. If NLD10 and SLES10 would come out without support for hardware that worked with NLD9 and SLES9, then yes, your complain is justified. Otherwise, you should complain that it doesn't work anymore for private individuals.
IOW, if a customer asks me for an upgrade of his SUSE and Fritzcard!PCI
Silviu Marin-Caea wrote:
On Wednesday 15 February 2006 23:31, Hans-Peter Jansen wrote:
This is in no way an exceptable solution for anybody owning any of these pieces. Imagine - some companies I advised Suse Linux - depend on a e.g. working fax solution. Sure, 10.1 disqualifies in this discipline.
Why do you recommend to *companies* a product designed for home use/enthusiasts?
Suse Linux professional for years has been used in business, with excellent reliability. One could count on Suse Linux to work "out of the box", and to keep running for years. If the plan is to introduce disturbances and annoying perturbations into Suse linux, so as to point buyers to the comparatively stale, but more expensive enterprise offerings, that would be rather shabby. It reminds me of the way shrink-wrapped or downloadable redhat linux used to be used in businesses, until redhat killed off the reasonably priced version, and pointed people to the $2500 enterprise version. They also trotted out fedora core 1, which was basically redhat 9 + bugfixes, and denigrated it vigorously, claiming it was only "for hobbyists", and that any real use of linux should involve their enterprise version. I left redhat behind, and began a massive migration to Suse in the wake of that fiasco, so it's disturbing to begin to hear the same smug little catchphrases and buzzwords again, that Suse linux is only for "hobbyists", and that serious users must buy the enterprise version if they want things to "just work", as they used to on Suse linux professional for so many years. Frankly, the enterprise version is rather stale, and has a lot less software included, and also a lot less software available from 3rd party repositories. The build toos and infrastructure has been showing it's age as well - upgrading my Suse 10 servers to dovecot-1.0 was a snap, but getting the rpm to build on SLES has been frustrating and fruitless so far. I think the popularity and good reputation of Suse linux professional has greatly helped the sales of SLES. I fear that, as Suse linux is seen increasingly as just another "me too" fedora-like OS, shipping with serious regressions, and causing annoyance, disappointment and extra work for users, that the former Suse faithful will decide to switch to kubuntu or xandros, and in a ripple effect, the uptake of SLES will also be adversely affected. I certainly don't want to see that, and I certainly hope the smart people inside Suse/Novell have a plan. Joe
Silviu Marin-Caea wrote:
On Wednesday 15 February 2006 23:31, Hans-Peter Jansen wrote:
This is in no way an exceptable solution for anybody owning any of these pieces. Imagine - some companies I advised SUSE Linux - depend on a e.g. working fax solution. Sure, 10.1 disqualifies in this discipline.
Why do you recommend to *companies* a product designed for home use/enthusiasts?
There's nothing about opensuse 10.x that suggests it is designed for home use or enthusiasts only. I've used SuSE Professional and now 10.x for business purposes for at least 3 years.
NLD9 and SLES9 are the right product for companies.
I disagree. They're the right product for companies that require the kind of support and stability that accompany those products. Typically those are larger enterprises with strict change-management policies and such - smaller companies are often much more nimble ships that have no problem working with the normal release-frequency of SUSE Linux. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
On Thu, 16 Feb 2006, Per Jessen wrote:
Silviu Marin-Caea wrote:
On Wednesday 15 February 2006 23:31, Hans-Peter Jansen wrote:
NLD9 and SLES9 are the right product for companies.
No. There are a lot of cases, where I can't use SLES a server (even if really would like to), because there are too many packages missing. If you try to run typo3, bugzilla, squirrellmail or some forum with latex extensions, then you have to install too many packages from other sources. The even bigger problem is to maintain them (bugfixes, security updates ...) The same for NLD: no lam, mpich, libraries for development. (But our domino servers run on SLES). Bye, -- Andreas Klein Andreas.C.Klein@physik.uni-wuerzburg.de
I'd recommend reading this. It describes some of risks associated with having the closed, binary modules in the kernel. http://thread.gmane.org/gmane.linux.kernel/354704 I was skeptical about Novell's approach before reading it - but now I agree with it more. Martin Schlander / cb400f
* Silviu Marin-Caea (silviu_marin-caea@fieldinsights.ro) [20060216 14:42]:
If NLD10 and SLES10 would come out without support for hardware that worked with NLD9 and SLES9, then yes, your complain is justified.
Code for SL 10.1, NLD10 and SLES10 have the same base, so drivers missing in SUSE Linux will also miss in NLD and SLES. Philipp
Hi H-P, On Wed, Feb 15, 2006 at 10:31:33PM +0100, Hans-Peter Jansen wrote:
Am Mittwoch, 15. Februar 2006 12:29 schrieb Carl-Daniel Hailfinger:
This only affects a *small* subset of ISDN and DSL cards and exactly one wireless chipset (atheros). I fully expect that the GPL driver
The only wireless chipset/pci card, which handles wpa encryption - cool.
My prism2 works with WPA, as did ipw2x00 when I last tested. [...]
Personally, I think this is entirely acceptable since it reduces support load on SUSE kernel developers (less tainted oopses) and respects the express will of the kernel developing community.
Sure, disappointing customers definitely reduces the support load in every company. Such an attitude will actively damage the reputation of SUSE and you know - one disappointed customer has much more weight (and will spread the word louder) than ten satisfied ones.
I don't think Carl-Daniel wanted to make the point that SUSE kernel developers want to work less. But they can lose a lot of time with trying to work on issues that can not be resolved due to the presence of closed kernel modules. No theory, sad fact of life. I think their time is better invested if they work on improving the open-source drivers and get more of them into Linux and the distribution. Long-term it means better hardware support, not worse. [...]
How about "New driver architecture - Novells disaster seekers strike back"
Cynicism is always nice :-) Best, -- Kurt Garloff, Head Architect, Director SUSE Labs (act.), Novell Inc.
Hi Carl-Daniel, On Wed, Feb 15, 2006 at 12:29:18PM +0100, Carl-Daniel Hailfinger wrote:
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
I have prepared some information at http://en.opensuse.org/Kernel_Module_Packages/ I think you could refer to it. Thx, -- Kurt Garloff, Head Architect, Director SUSE Labs (act.), Novell Inc.
Hi Kurt, Kurt Garloff schrieb:
On Wed, Feb 15, 2006 at 12:29:18PM +0100, Carl-Daniel Hailfinger wrote:
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
I have prepared some information at http://en.opensuse.org/Kernel_Module_Packages
Great! I'll add more info (mostly non-technical "how does this affect users and what can they do about it") to it over the weekend. It seems there is even a mechanism to use vendor-supplied drivers and firmware during installation, so installation over WLAN/DSL/ISDN is possible. Regards, Carl-Daniel
On Fri, Feb 17, 2006 at 04:50:01PM +0100, Carl-Daniel Hailfinger wrote:
Hi Kurt,
Kurt Garloff schrieb:
On Wed, Feb 15, 2006 at 12:29:18PM +0100, Carl-Daniel Hailfinger wrote:
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
I have prepared some information at http://en.opensuse.org/Kernel_Module_Packages
Great! I'll add more info (mostly non-technical "how does this affect users and what can they do about it") to it over the weekend. It seems there is even a mechanism to use vendor-supplied drivers and firmware during installation, so installation over WLAN/DSL/ISDN is possible.
It would be nice if people who make a new page include them in at least one catagory from http://en.opensuse.org/User_Documentation houghi -- Nutze die zeit. Sie ist das Kostbarste was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Wert und Arbeit, und das Sein wichtiger als das tun. Johannes Müller-Elmau
houghi schrieb:
On Fri, Feb 17, 2006 at 04:50:01PM +0100, Carl-Daniel Hailfinger wrote:
Hi Kurt,
Kurt Garloff schrieb:
On Wed, Feb 15, 2006 at 12:29:18PM +0100, Carl-Daniel Hailfinger wrote:
I will prepare a wiki page about the topic so that we can point to it for future flamewars. Suggested title is "New driver architecture". Comments?
I have prepared some information at http://en.opensuse.org/Kernel_Module_Packages
Great! I'll add more info (mostly non-technical "how does this affect users and what can they do about it") to it over the weekend. It seems there is even a mechanism to use vendor-supplied drivers and firmware during installation, so installation over WLAN/DSL/ISDN is possible.
It would be nice if people who make a new page include them in at least one catagory from http://en.opensuse.org/User_Documentation
Yes, however the current text is not user documentation, but developer documentation. I will add a link to it once I have added some user- oriented paragraphs to it. Regards, Carl-Daniel -- http://www.hailfinger.org/
Am Mittwoch, 15. Februar 2006 08:11 schrieb Ulrich Windl:
On 14 Feb 2006 at 19:50, Hans-Peter Jansen wrote:
[...]
Sure, hopefully you already ordered the big fat red warning sticker for the boxed product which explains, that things which just worked before, won't do anymore!
[...]
I'd say that the media only includes GPL software now, and that Internet access is needed to download packages from non Novell-supported sites to complete the installation (media players, MP3, graphics drivers, modem drivers, printer drivers, ISDN, webcams, tuners, etc.).
Maybe some would see that equivalent with "don't buy".
Regards, Ulrich
Aha, you mean just like Windows? :-P (Setting up my AMD64 machine I needed internet access for Windows to get the Promise S-ATA driver so Windows would actually admit there was a hard disk attached to the machine, and the Yukon NIC driver, that's not to mention it didn't recognise the audio, video, processor, southbridge, DVD-RAM, PDA, MS Gamevoice, mouse and keyboard correctly - I suppose I should consider myself lucky the video card, mouse and keyboard worked with the default drivers, even if poorly. Come to think of it the only things which were 100% recognised were the floppy drive for loading the S-ATA driver (and I had to buy one of those, it was a legacy free PC before XP got its grubby mits on it :-( ) and the DVD-ROM. Then I had to download the video and audio codecs and install a DVD player and codec...) Well, not quite that bad then, I suppose, SUSE still has thousands more drivers included than Windows does, even when excluding the non-GPL Kernel stuff... But if you are using a piece of hardware (especially modem/ISDN adapter) that is affected, I guess that it is no consolation that the manufacturers haven't pulled the thumbs out and worked with Novell/SUSE on a solution to this problem... And from what I read on the IRC, it is no non-GPL kernel modules, but we need clarification on that... Dave
Hans-Peter Jansen <hpj@urpla.net> writes:
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet?
The kmp packages can be made available as a package installation source that can be put on a media.
[...] I really hope, that SUSE get the package manager - before 10.1 release - to the point, where it prevents kernel updates, unless external kernel modules, which are tagged as critical for it's proper operation, are available. Otherwise, automatic updates cannot work, which is the real selling point here..
This is the goal and we'll test this as soon as all pieces are together.
Even if I'm not in a position to comment the way, this decision was made, but it's bad style to do it very shortly before a release - actively preventing concerned parties to catch up / work around the newly imposed issues. Really bad style.
I agree that communication wise we have not done a good job :-( Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, Feb 15, 2006 at 10:10:41AM +0100, Andreas Jaeger wrote:
Hans-Peter Jansen <hpj@urpla.net> writes:
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet?
The kmp packages can be made available as a package installation source that can be put on a media.
As I understand, they won't be put on suse.ftp or opensuse.ftp and thus won't be available on e.g. CD 6. Is that correct, or am I wrong? houghi -- To invent, you need a good imagination and a pile of junk. -- Thomas Edison
houghi <houghi@houghi.org> writes:
On Wed, Feb 15, 2006 at 10:10:41AM +0100, Andreas Jaeger wrote:
Hans-Peter Jansen <hpj@urpla.net> writes:
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet?
The kmp packages can be made available as a package installation source that can be put on a media.
As I understand, they won't be put on suse.ftp or opensuse.ftp and thus won't be available on e.g. CD 6. Is that correct, or am I wrong?
Correct in the case of non-GPL drivers - but e.g. AVM or any developer could make their own CD and ship it with their products like they do for Windows. Now we only need a stable kernel ABI ;-( Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, Feb 15, 2006 at 01:26:14PM +0100, Andreas Jaeger wrote:
Correct in the case of non-GPL drivers - but e.g. AVM or any developer could make their own CD and ship it with their products like they do for Windows. Now we only need a stable kernel ABI ;-(
They could do both. Having the drivers on teir CD would be a great thing. They then could put a Penguin on their box and just suport it as anything else. :-) houghi -- Kirkland, Illinois, law forbids bees to fly over the village or through any of its streets.
On Wed, 2006-02-15 at 13:55 +0100, houghi wrote:
On Wed, Feb 15, 2006 at 01:26:14PM +0100, Andreas Jaeger wrote:
Correct in the case of non-GPL drivers - but e.g. AVM or any developer could make their own CD and ship it with their products like they do for Windows. Now we only need a stable kernel ABI ;-(
They could do both. Having the drivers on teir CD would be a great thing. They then could put a Penguin on their box and just suport it as anything else. :-)
houghi
Ever thought of the possibility that they will ditch support for linux enterly? -- pgp-id: 926EBB12 pgp-fingerprint: BE97 1CBF FAC4 236C 4A73 F76E EDFC D032 926E BB12 Registered linux user: 75761 (http://counter.li.org)
On Wednesday 15 February 2006 17:08, Hans Witvliet wrote:
On Wed, 2006-02-15 at 13:55 +0100, houghi wrote:
On Wed, Feb 15, 2006 at 01:26:14PM +0100, Andreas Jaeger wrote:
Correct in the case of non-GPL drivers - but e.g. AVM or any developer could make their own CD and ship it with their products like they do for Windows. Now we only need a stable kernel ABI ;-(
They could do both. Having the drivers on teir CD would be a great thing. They then could put a Penguin on their box and just suport it as anything else. :-)
houghi
Ever thought of the possibility that they will ditch support for linux enterly?
Am I the only one who believes in not purchasing hardware that isn't directly supported by the manufacturer for linux, and as a the last possibility, not even supported by OSS drivers? You're saying a company ditching linux support means that people have to scramble to appease the company? I demand the opposite. I use Linux, and I demand they appease me by providing Linux drivers. If they don't, I won't use there hardware. And I don't mean I won't use their hardware on a Linux machine. I mean I _won't_ use their hardware. Joseph M. Gaffney aka CuCullin
Am Mittwoch, 15. Februar 2006 23:13 schrieb Joseph M. Gaffney:
You're saying a company ditching linux support means that people have to scramble to appease the company? I demand the opposite. I use Linux, and I demand they appease me by providing Linux drivers. If they don't, I won't use there hardware.
You surely soon start learn using a braille display, don't you? Alternately, you may prepare a kernel patch, that redirects the serial console output to a line printer, before graphic adaptors with 2D interfaces vanish..
And I don't mean I won't use their hardware on a Linux machine. I mean I _won't_ use their hardware.
While I feel with you and try to cope with that demand (*), it just won't work in all aspects on current hardware. Pete
Sorry, hit <Ctrl+Return> too fast.. Am Mittwoch, 15. Februar 2006 23:37 schrieb Hans-Peter Jansen:
Am Mittwoch, 15. Februar 2006 23:13 schrieb Joseph M. Gaffney:
And I don't mean I won't use their hardware on a Linux machine. I mean I _won't_ use their hardware.
While I feel with you and try to cope with that demand (*), it just won't work in all aspects on current hardware.
Pete
(*) e.g. by using matrox GA's and resign from useful 3D abilities, even for common screen saver..
On Wednesday 15 February 2006 17:37, Hans-Peter Jansen wrote:
Am Mittwoch, 15. Februar 2006 23:13 schrieb Joseph M. Gaffney:
You're saying a company ditching linux support means that people have to scramble to appease the company? I demand the opposite. I use Linux, and I demand they appease me by providing Linux drivers. If they don't, I won't use there hardware.
You surely soon start learn using a braille display, don't you?
Alternately, you may prepare a kernel patch, that redirects the serial console output to a line printer, before graphic adaptors with 2D interfaces vanish..
Ok, I think I get what you're saying.... And you mean analog displays, with HDMI using HDCP on the way, right? The thing is, there are solutions in the works. I will also not support HDCP in any way. I'm an AV consultant, and I've voiced the reasons for this to my clients, keeping them far clear of HDCP. Will I be left behind? I doubt it, I've told NEC, Panasonic, and Mitsubishi some of the many reasons (beyond DRM mind you) why HDCP is a technology doomed to cause the consumer nothing but problems, and some of them are listening. Point being, if you don't like it, say something - if enough do, a company will always do something about it.
And I don't mean I won't use their hardware on a Linux machine. I mean I _won't_ use their hardware.
While I feel with you and try to cope with that demand (*), it just won't work in all aspects on current hardware.
Pete
I understand there are unavoidable situations, but they are exceptions - and exceptions never make the rule. Thats what makes them an exception, and why I will never consider an exception as a point for or against an argument. Something will only happen if you do something about it. Don't complain to the developers, complain to the company. Send them emails, letters, etc, etc. Seriously, will it take so much time to write a letter, by comparison to screwing around with a wierd piece of hardware for hours trying to get the most basic functionality? I never understood this mindset, honestly. Joseph M. Gaffney aka CuCullin
On Wed, 15 Feb 2006, Andreas Jaeger wrote:
Correct in the case of non-GPL drivers - but e.g. AVM or any developer could make their own CD and ship it with their products like they do for Windows. Now we only need a stable kernel ABI ;-(
The stable kernel ABI won't happen (soon), the changing ABI is used to make it difficult to provide binary only kernel modules and it's getting more difficult every time. I'm personally searching for a laptop with GPL only drivers and that's not easy, it used to be GPL only drivers in the past when you bought a laptop which supported Linux but this is not always the case these days. And I don't want to be stuck with an older or specific distribution just because then all my hardware will work. Any tips are appreciated! Are SUSE certified laptops always free of binary drivers?
Andreas
See you at FOSDEM, Aschwin Marsman -- aschwin@marsman.org http://www.marsman.org
On Wed, Feb 15, 2006 at 01:55:42PM +0100, Aschwin Marsman wrote:
On Wed, 15 Feb 2006, Andreas Jaeger wrote:
Correct in the case of non-GPL drivers - but e.g. AVM or any developer could make their own CD and ship it with their products like they do for Windows. Now we only need a stable kernel ABI ;-(
The stable kernel ABI won't happen (soon), the changing ABI is used to make it difficult to provide binary only kernel modules and it's getting more difficult every time.
The goal of the changing ABI is however not to break binary only drivers, but to make the Linux kernel stay fast, clean, and innovating.
I'm personally searching for a laptop with GPL only drivers and that's not easy, it used to be GPL only drivers in the past when you bought a laptop which supported Linux but this is not always the case these days. And I don't want to be stuck with an older or specific distribution just because then all my hardware will work. Any tips are appreciated!
Especially WLAN and graphics card requirements have crept in... yes. Previously it was just winmodems... Ciao, Marcus
Marcus Meissner schrieb:
On Wed, Feb 15, 2006 at 01:55:42PM +0100, Aschwin Marsman wrote:
On Wed, 15 Feb 2006, Andreas Jaeger wrote:
I'm personally searching for a laptop with GPL only drivers and that's not easy, it used to be GPL only drivers in the past when you bought a laptop which supported Linux but this is not always the case these days. And I don't want to be stuck with an older or specific distribution just because then all my hardware will work. Any tips are appreciated!
Especially WLAN and graphics card requirements have crept in... yes. Previously it was just winmodems...
My Samsung P35 works out of the box without any binary only drivers except for winmodem and card reader which I both don't need. Regards, Carl-Daniel -- http://www.hailfinger.org/
On Wed, 15 Feb 2006, Marcus Meissner wrote:
The stable kernel ABI won't happen (soon), the changing ABI is used to make it difficult to provide binary only kernel modules and it's getting more difficult every time.
The goal of the changing ABI is however not to break binary only drivers, but to make the Linux kernel stay fast, clean, and innovating.
That's correct, it's not the goal but a wanted side effect that is promoted actively in the last months (I'm reading the kernel mailing list since 1993 and these issues get overheated once in a while).
I'm personally searching for a laptop with GPL only drivers and that's not easy, it used to be GPL only drivers in the past when you bought a laptop which supported Linux but this is not always the case these days. And I don't want to be stuck with an older or specific distribution just because then all my hardware will work. Any tips are appreciated!
Especially WLAN and graphics card requirements have crept in... yes. Previously it was just winmodems...
And I don't care about a modem but do care about WLAN and graphics. Card readers are also an issue, as is working suspend. Leaves my question: which laptops are/will be SUSE certified who only need open source drivers? Especially with 10.1 on the horizon without binary modules out of the box this will become a FAQ.
Ciao, Marcus
Best regards, Aschwin Marsman -- aschwin@marsman.org http://www.marsman.org
Hi Hans-Peter, On Tue, Feb 14, 2006 at 07:50:51PM +0100, Hans-Peter Jansen wrote:
Am Dienstag, 14. Februar 2006 18:06 schrieb Marcus Meissner:
This is btw one reason for the packagemanager changes, that this package installation from multiple external sites is possible.
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet?
Sure, hopefully you already ordered the big fat red warning sticker for the boxed product which explains, that things which just worked before, won't do anymore!
This is not new. We've always been fighting to get as much support for new hardware in by e.g. using the latest kernels, trying to add newer drivers from various sources and integrating them. And along the way, sometimes a piece of hardware stopped working, as the driver had not been ported to a newer kernel or because tests exposed that it was more a danger to the user than a help.
While I understand SUSE/NOVELLs standpoint concerning nongpl modules/packages, I also see, that you're in fact loosing a unique selling proposition, like Sven Schmidt noted by imposing a chicken/egg problem to your users, which can only be circumvented, if carefully planning an install/upgrade process.
I don't think that increasing the amount of supported hardware by a small amount by violating the rules of the community by supplying non-GPL kernel modules is the right differentiator. I think that fighting to get more hardware supported with GPL drivers is the better way to go. This is the strategy that the creators of Linux are setting and Linux has come to where it is now by most people supporting this. SUSE has always been supporting this as well -- just it has been somewhat generous with exceptions. SUSE has invested some work to support such exceptions in the past. Are you telling me that the handful of drivers that we can not support any more the same way we did are the key differentiator that made you chose SUSE Linux? I actually believe that we improve on the driver side rather than making it worse by allowing others to provide kernel modules that cleanly integrate into the system and survive kernel updates. This way, more parties can contribute kernel modules and not everything needs to go via the bottleneck of our kernel team. [...]
I really hope, that SUSE get the package manager - before 10.1 release - to the point, where it prevents kernel updates, unless external kernel modules, which are tagged as critical for it's proper operation, are available. Otherwise, automatic updates cannot work, which is the real selling point here..
I have good news for you: This already exists. It's part of the way we handle kernel module packages, see http://en.opensuse.org/Kernel_Module_Packages/ The extra modules have dependencies on the kernel ABI, and the new update tool does handle dependencies for updates. Best, -- Kurt Garloff <kurt@garloff.de> [Koeln, DE] Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL] Linux: SUSE Labs (Director) <garloff@suse.de> [Novell Inc]
Am Freitag, 17. Februar 2006 14:06 schrieb Kurt Garloff:
Hi Hans-Peter,
On Tue, Feb 14, 2006 at 07:50:51PM +0100, Hans-Peter Jansen wrote:
Am Dienstag, 14. Februar 2006 18:06 schrieb Marcus Meissner:
This is btw one reason for the packagemanager changes, that this package installation from multiple external sites is possible.
Hmm, how do you download something, if the e.g. AVM DSL/ISDN Combo Card driver is missing (like it's the situation here), and that's the only way to internet?
Sure, hopefully you already ordered the big fat red warning sticker for the boxed product which explains, that things which just worked before, won't do anymore!
This is not new.
We've always been fighting to get as much support for new hardware in by e.g. using the latest kernels, trying to add newer drivers from various sources and integrating them. And along the way, sometimes a piece of hardware stopped working, as the driver had not been ported to a newer kernel or because tests exposed that it was more a danger to the user than a help.
While I understand SUSE/NOVELLs standpoint concerning nongpl modules/packages, I also see, that you're in fact loosing a unique selling proposition, like Sven Schmidt noted by imposing a chicken/egg problem to your users, which can only be circumvented, if carefully planning an install/upgrade process.
I don't think that increasing the amount of supported hardware by a small amount by violating the rules of the community by supplying non-GPL kernel modules is the right differentiator. I think that fighting to get more hardware supported with GPL drivers is the better way to go. This is the strategy that the creators of Linux are setting and Linux has come to where it is now by most people supporting this. SUSE has always been supporting this as well -- just it has been somewhat generous with exceptions.
I think the problem isn't that openSUSE are aiming to remove non-GPL drivers from the Kernel. This is a good aim. The problem, at least for me, is just in the way it is being communicated, or not. It appeared, for me, as part of the last IRC meeting as fait-acomplie: openSUSE are dropping all non-GPL drivers forthwith, no discussion, no announcement of how this would affect existing users and not that it would be from the next version (10.2), but the currently developed version due for release in the next couple of months. No information on how they were going to cope with non-GPL drivers that couldn't be replaced in time for release, no information on whether we would still be able to get/install the packages through YOU or as extra packages in a YAST repositories or whether we would need to scavenge the net for binaries and compile them into custom kernels for ourselves. And also that it was let-slip, as opposed to announced formally, when Beta 4 was due for release, I would expect such a major change to be announced as the first alpha for 10.2 would be announced, so that suppliers who currently have non-GPL drivers had a decent amount of time to ramp-up a development stream to work on a solution. The way it came out, it looks like everybody has "a few weeks" to get all of this sorted. Of course, this is just how it appears to the "public", when the decision was made and when the suppliers were informed is another matter. I've only been on the lists for a month or so, so sorry if I missed this being announced in November or December, for example, although looking at the mail subject lines in the archive nothing sprang out about it, and it hasn't appeared on any news feeds I subscribe to, and something like this would be fairly big news I would have thought. That is why companies like Novell have a PR department, although the fiasco they caused with using Gnome desktop as a default for Novell Linux isn't reassuring...
SUSE has invested some work to support such exceptions in the past. Are you telling me that the handful of drivers that we can not support any more the same way we did are the key differentiator that made you chose SUSE Linux?
Yes. All, or most, distros can be made to use KDE or Gnome, they can all run the same apps. The key differentiators for using SUSE for me were: a) It works, it recognises and installs all of my hardware without me having to scavenge the net and search out drivers and rebuild kernels. I've been using SUSE since 2001 and I haven't had to touch gcc for anything that I've needed so far, only for my own work. b) Auto-scripts for things like loading the nVidia drivers during install (well, this is an extension of the previous point), but the OSS nVidia drivers don't, or didn't, support 3D and dual-head. Without the official nVidia drivers, I wouldn't have a desktop. That SUSE automatically installs all of that for me is a big reason to stay loyal to it. c) YAST, I find it very easy to use and configure many aspects of my machine. For some aspects, there are better tools, but having everything "under one roof" is very useful. d) It just works... Well, apart from on my new laptop, which has an ATi Radeon Mobility X700 chip and the OSS Radeon driver cannot seem to control this chip and get it to display anything, I had to download and manually install the ATi fglrx driver, but on over 20 different machines I've installed SUSE on, this is the first time that SUSE hasn't just installed and worked... With my old laptop I tried SUSE, Ubuntu, Debian and a couple of others. SUSE installed, and worked. The rest stalled the installation at some point and required manual intervention to complete the install, something I wouldn't expect from an installation package from the mid 80's on. That said, Marcus Meissner from SUSE did respond that they are working with the likes of ATi and nVidia to solve these problems, so lets hope that they have a solution in time for 10.1 release.
I actually believe that we improve on the driver side rather than making it worse by allowing others to provide kernel modules that cleanly integrate into the system and survive kernel updates. This way, more parties can contribute kernel modules and not everything needs to go via the bottleneck of our kernel team.
It is a great goal, but the information that has trickled out through "unofficial" sources (i.e. there has been no official statement on how this will affect users, just a few lines in the IRC log on KPM packaging, and what appears like FUD from an AVM source) is causing uncertainty, and it gives the impression of: "We are going to do this, and to hell with whether it plunges SUSE back into the dark ages of hardware support in the short term." I'm sure this isn't what they mean, but without an official statement they are letting AVM and the likes implant FUD in this direction. The PR department for Novell/SUSE/openSUSE really need to get their act together in this. (And if openSUSE haven't assigned somebody/a team to act in this role, they really should think about it, releasing this sort of information in a controlled manner, and in a format that is understandable to the average user, is really important these days.) <snip> Dave
Hi Marcus, On Tue, Feb 14, 2006 at 06:06:35PM +0100, Marcus Meissner wrote:
There will be an interface between 3rd party vendors and Novell to provide kernel modules (in the KMP style described there), making it easy for those 3rd party vendors to build modules.
I have drafted a description on this on http://en.opensuse.org/Kernel_Module_Packages
They can be offered by those vendors as easily installable resource (RPMs).
Yes. Best, -- Kurt Garloff, Head Architect, Director SUSE Labs (act.), Novell Inc.
On Tue, Feb 14, 2006 at 05:51:07PM +0100, David Wright wrote:
I keep seeing this referred to, but I can't find any reference to it anywhere, http://en.opensuse.org/2006-02-07-status-meeting#SUSE_Linux_10.1_Status_.2F_...
I don't want to start ranting without knowing the facts, I also don't want to upgrade my dual-head set-up to 10.1 only to find I don't get any X afterwards...
The also read http://en.opensuse.org/2006-02-07-status-meeting-transcript from 20:09 on. Perhaps it would be nice to have links inside the transcript, so you can go to the part directly instead of browsing through it. houghi -- Missionary Position: The missionary on top.
Am Dienstag, 14. Februar 2006 14:33 schrieb Silviu Marin-Caea:
On Tuesday 14 February 2006 15:10, s.schmidt@avm.de wrote:
Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The
Is this really true? I would think that closed source drivers will only be missing from the OSS downloadable .iso images. They would probably be found in the supplemental CD and in the retail box DVD media.
They are droped completely. -- Mit freundlichen Grüßen, Marcel Hilzinger
On Tue, Feb 14, 2006 at 02:10:02PM +0100, Sven Schmidt wrote:
This mail is not intended to provoke a discussion of open vs. closed source. The only intention of this mail is to make you aware of the consequences of such a decision.
It is not helpful if you whine about a change/decision if you are not willing to do discuss with people about alternative solutions. Your last mail to linux-kernel and this mailing list was answered by Greg Kroah-Hartman who suggested to implement the drivers in user space. To be honest I see no reason why this should not be possible for you. But this is not the main point but the main point is that you did not react to Greg's mail. The solution he suggested (and that would be much cleaner than the current way of doing it in my opinion anyway) would also solve this problem for you without the need to open source the critical parts of your drivers. I am a content users of some of your products. But I am a bit confused about what you expect from your mails here if you don't work together with people offering their assistance. Are these mails just to form an angry mob of frustrated users to do some pressure on Novell/SUSE or are you really willing to find solutions? The point that I also did not like about the whole GPL kernel drivers issue is that it was not announced in time but that it was announced only after everything was already broken without having a replacement installed at that time. But apart from that it was the way to go if some of the kernel developers consider it a problem to have binary-only modules linked to the kernel. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Tue, Feb 14, 2006 at 02:38:17PM +0100, Robert Schiele wrote:
I am a content users of some of your products. But I am a bit confused about what you expect from your mails here if you don't work together with people offering their assistance. Are these mails just to form an angry mob of frustrated users to do some pressure on Novell/SUSE or are you really willing to find solutions?
We will see what the intend what by his replies here. houghi -- Everything you know is wrong!
I see the problem from the vendor's view: With ever cheaper hardware (just look at these GDI printers), more and more know-how goes into the software (drivers). To keep competitors out, you don't want to give away your software to the public. (Also you think it's quite unlikely that someone out there will improve your software once you would make it GPL). I saw some companies making a hybrid approach: A GPL driver uploads some "hexdump- like" firmware to the cards. I don't know if this applies to you (AVM). Another approach might be that you offer downloadable ISO images for "driver update media (CD/DVD) which Novell/SuSE can integrate during installation (there are some docs around at Novell's site). For Novell I see the advantage to ensure their products do not include any hidden patented algorithms for their customer protection (talking about evil lawyers). Just like AVM is unhappy for the ISDN/GPL thing, I'm unhappy with the patent-free media player mess: If I buy refill ink for my printer, I cannot view the instruction video CD, because it uses a patent-protected (subject to licensing) video codec. The commom way to avoid this might be the GPL. However, you can hardly convince any Windows user not to use patented algorithms. For PGP even now the IDEA algorithm used prevents use of GPG instead. While I understand, I'm unhappy. Regards, Ulrich On 14 Feb 2006 at 14:10, s.schmidt@avm.de wrote:
SUSE/Novell has announced that non-GPL kernel modules will no longer be part of future Novell products. Since SUSE Linux 6.3, AVM has been providing pre-compiled drivers for SUSE Linux. Since the release of SUSE 8.1 in September 2002, AVM drivers have been integrated into SUSE Linux distributions. Each time a new SUSE Linux Version beta cycle starts, AVM provides the latest drivers and Karsten Keil does an excellent job integrating those drivers. Therefore, a new SUSE Linux release goes hand in hand with the latest AVM driver development. At present, nearly the entire AVM product portfolio comes up with SUSE pre-compiled modules for ISDN and DSL devices and as such is part of the SUSE distribution:
AVM ISDN-Controller FRITZ!Card Classic AVM ISDN-Controller A1 AVM ISDN-Controller FRITZ!Card PnP AVM ISDN-Controller FRITZ!Card PCI / PCI v2.x AVM ISDN-Controller FRITZ!Card PCMCIA AVM ISDN-Controller A1 PCMCIA AVM ISDN-Controller FRITZ!Card USB AVM ISDN-Controller FRITZ!Card USB v2.x AVM DSL/ISDN-Controller FRITZ!Card DSL AVM DSL/ISDN-Controller FRITZ!Card DSL v2.0 AVM DSL/ISDN-Controller FRITZ!Card DSL USB AVM DSL/ISDN-Controller FRITZ!Card DSL USB v2.0 AVM DSL-Controller FRITZ!Card DSL USB analog AVM DSL-Controller FRITZ!Card DSL SL AVM DSL-Controller FRITZ!Card DSL SL USB AVM ISDN-Controller B1 v1.4/v2.0/v3.0 (ISA) AVM ISDN-Controller B1 PCI / B1 PCI v4.0 AVM ISDN-Controller B1 PCMCIA AVM ISDN-Controller C2 AVM ISDN-Controller C4 AVM ISDN-Controller T1 AVM ISDN-Controller T1-B AVM FRITZ!X USB/ v2.0/ v3.0 AVM FRITZ!X ISDN AVM FRITZ!Box (AVM WLAN-Controller FRITZ!WLAN USB Stick)
consequences In the past, the customer bought a fully functional distribution with the release of the brand new SUSE Linux. He could use ISDN fax G3, analog modem emulations or simply surf the internet via DSL/ISDN right away out of the box. For most users, that is the most important point in the distribution decision process. "Easy to use and right away surf the internet", that is the feedback we receive from our customers, when they visit AVM at fairs. The market share SUSE gained over past years is also based on SUSE's user-friendly policy of AVM driver integration. For six years now this strategic partnership with SUSE/Novell payed off for all parties. With Novell's decision to have non-GPL drivers no longer integrated, AVMs drivers will not be included on the distribution media anymore. The customer then needs to have an internet connection to download AVM's drivers or other packages. But without drivers the customer cannot download anything from the internet.
conclusion This process will lead to our no longer being able to provide driver packages to the end user with a new SUSE/Novell box release. Our driver build and QS process will be subsequent to the box release instead of parallel to the beta cycle. The process is extended. Moreover, if the Novell decision is implemented as stated, the unique selling proposition of the SUSE Linux Distribution is diminished. And ultimately this decision will generate more support for both of us.
This mail is not intended to provoke a discussion of open vs. closed source. The only intention of this mail is to make you aware of the consequences of such a decision.
Kind regards Sven Schmidt
AVM Audiovisuelles Marketing und Computersysteme GmbH Alt-Moabit 95, D-10559 Berlin http://www.avm.de
Andreas Jaeger <aj@suse.de> An 09.02.2006 17:14 opensuse-announce@opensuse.org Kopie
Thema [opensuse-announce] SUSE Linux 10.1 Update
I'd like to give you an update on our beta process with the following list of topics:
* Deliverable of Beta4 and further schedule * non-GPL kernel modules * Kernel Changes km_ packages * Major bug in Beta3: Fontconfig * Package manager major changes * XGL
Deliverable of Beta4 and Further Schedule =========================================
Beta4 did not pass our internal tests, we have to delay it by one week.
The FACTORY distribution has been updated with our current packages that everybody can use, but doing a complete installation from the current FACTORY tree is NOT recommended. You should just update single packages as needed.
We have decided to release Beta 4 on 2006-02-16 and Beta 5 on 2006-02-23. We'll finalize the schedule after testing and evaluating these two betas.
non-GPL kernel modules: =======================
Most developers of the kernel community consider non-GPL kernel modules to be infringing on their copyright. Novell does respect this position, and will no longer distribute non-GPL kernel modules as part of future products. Novell is working with vendors to find alternative ways to provide the functionality that was previously only available with non-GPL kernel modules.
Kernel Changes / km_, kmp, and kernel-flavor-nongpl packages: =============================================================
We added support to cleanly handle packages that contain kernel modules by representing the dependencies of mouldes on the kernel ABI as rpm dependencies. This allows third party modules to be provided and integrated cleanly.
Modules that were previously included in our kernel packages using the km_ package mechanism [1] have been converted to the new package format [2]; the km_ mechanism is no longer supported. Packages that contain additional kernel modules are now named name-kmp-kernelflavor (e.g., wlan-kmp-default. lirc-kmp-smp).
The kmp mechanism [2] supports creating and using additional Kernel Module Packages easily and reliably.
The kernel-kernelflavor-nongpl packages which contained modules that had non-GPL licenses have been removed.
[1] The km_ package mechanism is described at http://www.suse.de/~agruen/kernel-doc/.
[2] Kernel Module Packages Manual for CODE10, http://www.suse.de/~agruen/KMPM/
Major Bug in Beta3: Fontconfig ==============================
It might be that X11 apps just crash or are really slow (installation of some packages took rather long), which was due to a bug in fontconfig. A first fix is in fontconfig packages in the Beta3 fixed-rpm directory on ftp.opensuse.org .
Beta4 will fix most known bugs. Current packages are available at: ftp://ftp.suse.com/pub/projects/m17n/10.1 -
If you use them, update to both fontconfig and fonts-config. The packages in there are newer than what is currently in the FACTORY tree. If you find bugs in the m17n packages, please report them in bugzilla stating the exact version you're using.
Package Manager Major Changes =============================
We're replacing our package manager resolver library with a new version called "libzypp".
libzypp is the integration of SUSE's yast2 Package manager and Ximian's libredcarpet. At Novell we used two solutions so far - Red Carpet and YaST package manager - and decided to merge both in a best of breed approach.
The advantages for SUSE Linux are: * A better resolver than before * More information about why a package is installed or no solution is found * A better integration of all those feature that were added over the years to our package manager. * A command line interface ("rug") * A common handling of packages *and* patches * Dependency handling for update packages * A better way to handle selections (we call them now "patterns") * Remote management (not yet in SUSE Linux 10.1) * Additional repositories during installation (no GUI in SUSE Linux 10.1) * More flexibility in handling of different repositories, e.g. it is possible to have additional patterns for each repository.
The new library handles yum metadata, YaST sources (both also remote via ftp, http, nfs and smb) and additionally Zenworks, Opencarpet and RCE (Red Carpet Enterprise) servers as installation sources. The alternatives smart and apt-get will also work as they did on SUSE Linux 10.0.
Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages.
In addition to the existing packages, we're adding these new packages: * zmd: system daemon used by rug, zen-* * rug: Command line client * web-updater: Updater with more features than zen-updater * zen-updater: Simple updater * zen-remover: Tool to remove packages * zen-installer: Tool to add packages
We're still working on the integration of "libzypp" into our tree, the package manager in our FACTORY tree is not yet fully functional.
XGL ===
Xgl is an Xserver that uses OpenGL for its drawing operations. Xgl engineer David Reveman has posted enhancements to Xgl and a new compositor, 'Compiz' with a request that it be added to the freedesktop.org CVS repository. Some operations like antialiased font rendering is noticeably faster with this technology, and future graphics hardware might only have support for 3D operations and no 2D core any more.
These additional packages have now been added to the SUSE Linux FACTORY tree. Note that compiz has a couple of build problems that need to be fixed before it will go out.
For details on XGL, please check http://www.opensuse.org/Xgl .
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 [Anhang "att3brm9.dat" gelöscht von Sven Schmidt/AVM]
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Hi, please note that I speak as a happy SUSE user and not for anyone else. s.schmidt@avm.de schrieb:
SUSE/Novell has announced that non-GPL kernel modules will no longer be part of future Novell products. Since SUSE Linux 6.3, AVM has been providing pre-compiled drivers for SUSE Linux. Since the release of SUSE 8.1 in September 2002, AVM drivers have been integrated into SUSE Linux distributions. Each time a new SUSE Linux Version beta cycle starts, AVM provides the latest drivers and Karsten Keil does an excellent job integrating those drivers. Therefore, a new SUSE Linux release goes hand in hand with the latest AVM driver development. At present, nearly the entire AVM product portfolio comes up with SUSE pre-compiled modules for ISDN and DSL devices and as such is part of the SUSE distribution:
AVM ISDN-Controller FRITZ!Card Classic AVM ISDN-Controller A1 AVM ISDN-Controller FRITZ!Card PnP AVM ISDN-Controller FRITZ!Card PCI / PCI v2.x AVM ISDN-Controller FRITZ!Card PCMCIA AVM ISDN-Controller A1 PCMCIA AVM ISDN-Controller FRITZ!Card USB AVM ISDN-Controller FRITZ!Card USB v2.x AVM DSL/ISDN-Controller FRITZ!Card DSL AVM DSL/ISDN-Controller FRITZ!Card DSL v2.0 AVM DSL/ISDN-Controller FRITZ!Card DSL USB AVM DSL/ISDN-Controller FRITZ!Card DSL USB v2.0 AVM DSL-Controller FRITZ!Card DSL USB analog AVM DSL-Controller FRITZ!Card DSL SL AVM DSL-Controller FRITZ!Card DSL SL USB AVM ISDN-Controller B1 v1.4/v2.0/v3.0 (ISA) AVM ISDN-Controller B1 PCI / B1 PCI v4.0 AVM ISDN-Controller B1 PCMCIA AVM ISDN-Controller C2 AVM ISDN-Controller C4 AVM ISDN-Controller T1 AVM ISDN-Controller T1-B AVM FRITZ!X USB/ v2.0/ v3.0 AVM FRITZ!X ISDN AVM FRITZ!Box (AVM WLAN-Controller FRITZ!WLAN USB Stick)
And all the following drivers are GPL and are still included: ISDN4Linux: PCMCIA client driver for AVM A1/Fritz!PCMCIA cards AVM Fritz!PCI/PnP ISDN driver CAPI4Linux: PCMCIA client driver for AVM B1/M1/M2 CAPI4Linux: Common support for active AVM cards CAPI4Linux: Driver for AVM C2/C4 cards CAPI4Linux: Driver for AVM PCMCIA cards CAPI4Linux: Driver for AVM T1 HEMA ISA card CAPI4Linux: Driver for AVM T1 PCI card CAPI4Linux: DMA support for active AVM cards CAPI4Linux: Driver for AVM B1 ISA card CAPI4Linux: Driver for AVM B1 PCI card (the strings above are the module descriptions) The following drivers have a proprietary license and are gone: CAPI4Linux: Driver for AVM FRITZ!Card Classic CAPI4Linux: Driver for AVM FRITZ!Card DSL v2.0 CAPI4Linux: Driver for AVM FRITZ!Card DSL CAPI4Linux: Driver for AVM FRITZ!Card DSL SL CAPI4Linux: Driver for AVM FRITZ!Card DSL SL USB CAPI4Linux: Driver for AVM FRITZ!Card DSL USB v2.0 CAPI4Linux: Driver for AVM FRITZ!Card DSL USB analog CAPI4Linux: Driver for AVM FRITZ!Card DSL USB CAPI4Linux: Driver for AVM FRITZ!Card PCI CAPI4Linux: Driver for AVM FRITZ!Card PCMCIA CAPI4Linux: Driver for AVM FRITZ!Card PnP CAPI4Linux: Driver for AVM FRITZ!Card USB v2 CAPI4Linux: Driver for AVM FRITZ!Card USB CAPI4Linux: Driver for OEM FRITZ!X USB CAPI4Linux: Driver for AVM FRITZ!X USB/FRITZ!X ISDN Of the proprietary drivers, all USB drivers could be migrated to userspace with libusb as Greg Kroah-Hartman suggested. This would allow to keep them proprietary yet keep them out of the kernel. Problem solved for them. This leaves the following drivers with a problem: CAPI4Linux: Driver for AVM FRITZ!Card Classic CAPI4Linux: Driver for AVM FRITZ!Card DSL v2.0 CAPI4Linux: Driver for AVM FRITZ!Card DSL CAPI4Linux: Driver for AVM FRITZ!Card DSL SL CAPI4Linux: Driver for AVM FRITZ!Card PCI CAPI4Linux: Driver for AVM FRITZ!Card PCMCIA CAPI4Linux: Driver for AVM FRITZ!Card PnP What exactly was the reason to keep the drivers proprietary? * telecom regulations? * patents? * proprietary code from a third party? * technical reasons? Besides the code for fax/modem emulation, is there anything that requires proprietary code? If not, then users could at least have basic functionality with a GPL driver, enough to download the proprietary driver with all the features. Regards, Carl-Daniel
participants (25)
-
Andreas Jaeger -
Andreas Klein -
Aschwin Marsman -
Carl-Daniel Hailfinger -
David Wright -
Eberhard Moenkeberg -
Hans Witvliet -
Hans-Peter Jansen -
houghi -
J Sloan -
Johannes Kastl -
Joseph M. Gaffney -
Kurt Garloff -
Lysander Pensch -
Marcel Hilzinger -
Marcus Meissner -
Martin Schlander -
Per Jessen -
Peter Czanik -
Philipp Thomas -
Robert Schiele -
s.schmidt＠avm.de -
Silviu Marin-Caea -
Stephan Kulow -
Ulrich Windl