Re: [opensuse-factory] openSUSE 10.2 bug prioritization

[Carl-Daniel Hailfinger]

Just filed another bug after notification from upstream.

https://bugzilla.novell.com/show_bug.cgi?id=218948
Resizing Vista NTFS partitions may keep Vista from booting

It seems that current Windows Vista Release Candidates refuse
to boot after any of the NTFS partitions they access are resized.
Details at http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#vista
The linux-ntfs developers appreciate any testing and reports.


Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] openSUSE 10.2 bug prioritization

[Carl-Daniel Hailfinger]

Hi,

https://bugzilla.novell.com/show_bug.cgi?id=212053
Set promote_secondaries=1 by default

Rationale: If you have multiple IP addresses on one network
card and you delete the primary address, all other IP addresses
on this card vanish unexpectedly. This has bitten quite some
people in the past. Setting promote_secondaries=1 fixes this
bug.

I can provide a patch for this if needed.

Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] openSUSE 10.2 bug prioritization

[Carl-Daniel Hailfinger]

Christoph Thiel wrote:
> while going through the openSUSE 10.2 "RED bugs" (Blocker/Criticals), I
> thought it might be a good idea to ask for some help regarding bug
> prioritization.

https://bugzilla.novell.com/show_bug.cgi?id=218122

Enable more than 15 partitions for libata. I have already written a
patch for this bug. Once it is applied, we have up to 63 partitions
per libata/SCSI drive and the warning in the installer can disappear.


Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] openSUSE 10.2 bug prioritization

[Carl-Daniel Hailfinger]

Christoph Thiel wrote:
> Hi everyone,
> 
> while going through the openSUSE 10.2 "RED bugs" (Blocker/Criticals), I
> thought it might be a good idea to ask for some help regarding bug
> prioritization.
> 
> openSUSE 10.2 is going to be released rather soon. With the current bug
> count of 910 open bugs filed for 10.2, we will certainly have to postpone
> fixing some of them to 10.3.

What about bugs which have patches attached? Even if they are not red right
now, it causes less work to apply the patches than it causes to release
updates after GA. How should we tag these bugs? Keyword "Fix_is_Ready"?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] tiny-nvidia-installer removed from factory

[Carl-Daniel Hailfinger]

Stefan Dirsch wrote:
> Thanks for heading this issue in a constructive direction. Could you
> add some pointers to the reversed engineer driver for NVIDIA GPUs? I
> possibly add it to 10.2 as optional driver for testing purposes.

http://nouveau.freedesktop.org/wiki/ is the main address.

Excerpt from the status page:
DRM:Responsable for memory management, it allows 2d(DDX) and
3d(DRI) drivers to coexist.
Status: Seems to work.
DDX:2d driver
Status: Xv is now working. Both XAA and EXA(new 2d acceleration
architecture) are working. Both AGP and PCI-E cards work now.
DRI:3d driver
Status: Does not compile.

More info I got on irc.freenode.net#nouveau :
basically, nouveau is the "nv" driver, with some bits in the kernel,
and EXA..


Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SPAM: Re: [opensuse-factory] tiny-nvidia-installer removed from factory

[Carl-Daniel Hailfinger]

James Ogley wrote:
>> I agree, this is their problem, not ours.  They know exactly what they
>> must do to solve this issue, there is nothing that we can do.
> 
> Greg, are you calling on nVidia to GPL their driver code?  If so, have
> you contacted them directly and is there a formal way in which members
> of the community can assist?

Back in 1998, NVidia forced the XFree86 developers to obfuscate their
code and the situation has not improved till then. See the following
post for the details: http://airlied.livejournal.com/2006/10/12/

Relicensing of the NVidia display driver code under the GPL is not
going to happen (they may not own the code completely), but at least
it would be nice if they didn't actively hinder development. Similar
situation exists with ATI.

Greg has repeatedly made clear that binary only kernel modules are
a license violation. ATI/NVidia can't/don't want to open the sources
of their drivers. So the only thing we can hope for is that the
unavailability of binary only kernel modules will be painful enough
to get more developers involved with the reverse engineered open
source drivers.

How can the community assist?
* Test the open source graphics drivers and report bugs
* Write HOWTOs for these drivers
* Encourage/nudge NVidia/ATI to make specifications available to
  developers (optionally under NDA with source code release agreement)
* (Developers only:) Help reverse engineering closed source drivers

Most reverse engineering/driver development projects have only 2-5
developers although literally millions of people benefit from their
work. For example, the NVidia nforce network driver (forcedeth) was
created by three people (two for reverse engineering, one for writing
the new driver) and I (as part of that team) would sometimes have
killed to get feedback from more users. For the sake of such teams,
get involved and help them as good as you can.


Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] How to do an in-house top-level build of OpenSUSE?

[Carl-Daniel Hailfinger]

Hi,

Mark E Mason wrote:
> I'm strongly considering attempting a build of OpenSUSE for an
> architecture it does not support yet.  I have other Linuxes such as
> Debian and Gentoo running on this hardware, but not OpenSUSE.  There was
> a similar thread last month regarding SPARC.

Would that architecture be MIPS64? I'm quite interested in having
openSUSE run on my Extreme Networks switch which has such a CPU
(although I doubt it has enough non-volatile storage for that).

Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] tiny-nvidia-installer removed from factory

[Carl-Daniel Hailfinger]

Jonh Arson wrote:
> I wasn't what you can call happy when i found out this little software
> was removed from factory (and even less so when after reopening it 3 or
> 4 time the bug was marked as private).

You reopened the bug multiple times although you were told it was
classified as WONTFIX? Then the only way to stop you from reopening
was indeed marking the bug private.

> No real explanation given. [...]
> WONTFIX, build it in the BS. WTF!

That's a perfectly valid reason. You can build it in the build service
or wait for others to do it. SUSE has no obligation to fulfill your
wishes unless you have a very convincing reason (and no, it's not you
who needs to be convinced).

Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] 10.1 problem with xscreensaver

[Carl-Daniel Hailfinger]

jdd wrote:
> I may have found a bug of the kde screen saver.
> 
> when the "k" menu is open, the screen saver don't start and the computer
> is never protected. I'll try it on beta 1 and report

Simple cause, but nearly unsolvable. xscreensaver has to grab the keyboard
to be able to accept your password later on. Unfortunately, the "K" menu
and afaics all window manager menus in all window managers grab the
keyboard (that's necessary for them to function) and so xscreensaver can't
grab it.
The only remotely possible option I can see is to add the ability to
xscreensaver to steal the keyboard from the window manager. But that would
probably also need window manager support.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Hardware Support: Marvell 88E8056

[Carl-Daniel Hailfinger]

Bernhard Walle wrote:
> Hello,
> 
> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [2006-10-16 16:33]:
>> Bernhard Walle wrote:
>>> * Randall R Schulz <[EMAIL PROTECTED]> [2006-10-16 15:18]:
>>>>> this can be passed to the driver at runtime.
>>>> How is that done? I haven't been able to find a comprehensive 
>>>> specification or list of kernel command-line options. Or do you mean it 
>>>> can be done even after the system is running?
>>> If the driver isn't specially prepared (i.e. module paremeters), it
>>> cannot.
>> No. See new_id in sysfs once the driver is loaded.
> 
> Which kerenl introduced this? On 2.6.16 it's not present.

For your enlightenment:
# find /sys/ -name new_id

The feature is in all kernels since at least 2.6.8 (SUSE Linux 9.2),
maybe even before that.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Hardware Support: Marvell 88E8056

[Carl-Daniel Hailfinger]

Bernhard Walle wrote:
> * Randall R Schulz <[EMAIL PROTECTED]> [2006-10-16 15:18]:
>>> this can be passed to the driver at runtime.
>> How is that done? I haven't been able to find a comprehensive 
>> specification or list of kernel command-line options. Or do you mean it 
>> can be done even after the system is running?
> 
> If the driver isn't specially prepared (i.e. module paremeters), it
> cannot.

No. See new_id in sysfs once the driver is loaded.

>  Even if it is, the driver needs to be loaded manually.

Yes.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Where Is The Factory Boot CD Image?

[Carl-Daniel Hailfinger]

Randall R Schulz wrote:
> As I noted on the openSUSE Wiki page 
> , to use the Marvell 88E8001 
> Ethernet interface, you have to override the default (and blacklisted) 
> sklin98 module with skge.

sk98lin should have been dropped some time ago. No idea why that didn't
happen. Maybe open a bug to get that sorted out.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[opensuse-factory] [RFC] kernel IP configuration: promote_secondaries default setting

[Carl-Daniel Hailfinger]

Hi,

/proc/sys/net/ipv4/conf/*/promote_secondaries is currently set to 0
by default. Changing that to 1 would be a user-visible change for
users with multiple ip addresses on one interface, but the changed
behaviour is IMO less surprising than the current one.

Description for promote_secondaries:
Deleting the primary IP address of an interface forces deletion all
secondary IP addresses unless promote_secondaries is set.

This side effect of killing all secondary addresses without warning
(and without documentation about this behaviour) has caused me and
lots of others quite some grief.
Scenario: You are logged into a remote box on one of its secondary
IP addresses (to be able to change the primary IP address without
disrupting your work), delete the primary IP address to later add
the new primary IP address and suddenly find out that the secondary
IP address you were using for administration has vanished. No way
to connect to the box (it has no IP address anymore), so you have
to ask someone to flip the power switch and hope it works with
the old config after reboot.
If promote_secondaries had been set, the disaster would not have
happened.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Packages in default installation

[Carl-Daniel Hailfinger]

Andreas Jaeger wrote:
> "Terje J. Hanssen" <[EMAIL PROTECTED]> writes:
> 
>> Andreas Jaeger wrote:
>>> "Terje J. Hanssen" <[EMAIL PROTECTED]> writes:
>>>
>>> Xcdroast is not part of openSUSE, it was
>>> too hard to maintain.
>>>
>> Not really? I just searched through both
>> http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/i586/
>>
>> http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/x86_64/
>> and found the latest xcdroast-0.98alpha15-57 rpms (?)
> 
> I stand corrected,

That's my fault. I sort of seized maintainership for xcdroast because
it is the only CD/DVD burning program which conserves timestamps of
directories in backup mode. (K3b and others kill them.) And it works
very well via X-Forwarding over SSH. As a bonus, it doesn't eat too
much CPU.

Unfortunately, xcdroast is maintained in my (limited) spare time and
I have not yet managed to integrate dvd+rw-tools handling. Patches
for that are welcome: add them to bugzilla or mail me directly.
UDF support is already in my local tree, I hope to clean that up and
get it into openSUSE 10.2.

Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Multi-threaded PCI device probing now in FACTORY kernel

[Carl-Daniel Hailfinger]

Hi Greg,

Greg KH wrote:
> Again, you have been warned about this, but I would like to hear about
> any success or failure reports for people trying this out.

Works fine here (Intel Pentium M processor 1.60GHz), but I can't see
any speedup. Normally, I need 57 seconds from bootloader to kdm,
with pci_multithread_probe=1 I need 58 seconds. Such a small change
in boot time is just noise.


Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Dist Meeting 2006-09-14: Proposed Agenda

[Carl-Daniel Hailfinger]

Marc Collin wrote:
> Le mercredi 13 septembre 2006 15:59, Stephan Kulow a écrit :
>> Am Mittwoch, 13. September 2006 20:57 schrieb Marc Collin:
>>>
>>> -funroll-all-loops
>> Make sure you read http://funroll-loops.org/ - what exactly do you measure?
> 
> time to start, time to run function.
> 
> when i created some program in C for a company i used often something similar 
> to
> 
> g++ -O2 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=x86-64 
> -mfpmath=sse 
> program_name.cpp -o program_name
> 
> i get about 10% faster then the standard syntax

I have run benchmarks which suggest -funroll-all-loops makes things up to
10% SLOWER. Read that again. SLOWER.

gcc man page says:
   -funroll-all-loops
   Unroll all loops, even if their number of iterations is uncertain
   when the loop is entered.  This usually makes programs run more
   slowly.  -funroll-all-loops implies the same options as -fun-
   roll-loops,

It all depends on the code and the gcc version. And we do not want to go
down this road to optimization madness.

If you really want to optimize code, make sure it is using efficient
algorithms.


Regards,
Carl-Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Agenda for tomorrow's distribution meeting

[Carl-Daniel Hailfinger]

Kay:
* Can we have a sysfs event if the BLKRRPART ioctl() is called for
  a given device? This would help implementing more than 16 partitions
  for libata/scsi and also make partitioned fakeRAID devices easier
  to handle.
* Is there any way to find out when partition detection by the kernel
  is finished? Or can we instruct the kernel not to detect partitions
  at all via sysfs?

Carl-Daniel Hailfinger wrote:
> Olaf: You asked for a way to create one dm device per partition in
> http://lkml.org/lkml/2006/8/10/42 . See the kpartx description below
> for a solution.
> 
> Andreas Jaeger wrote:
>> Here're the agenda itmes that we plan to discuss tomorrow.  Please
>> send input/ask questions etc and I'll bring your input into the
>> meeting.
>>
>> * /dev/hd removal: http://lkml.org/lkml/2006/8/9/285
> 
> Breaks everyone using partitions above hdX15. Two possible solutions:
> - Use kpartx (and device mapper) for partitions sdX16 and greater
>   (ugly, but works. Booting from such partitions however requires
>   manual mapping in GRUB and LILO)
> - Change minor number allocation for SCSI disks in the kernel
>   (unlikely to be accepted without great opposition)
> 
> I'll test using kpartx and report back.

This was easier than I thought. You need
* partx from util-linux built with --enable-partx
* kpartx from multipath-tools

Once /sys/block/sdX/ and /sys/block/sdX/sdX[0-9]* appear, run
# partx -d /dev/sdX
# kpartx -a /dev/sdX
and every partition will appear as usual, but in a slightly different
place. /dev/sda1 becomes /dev/mapper/sda1 etc. The big difference is
that you don't depend on minor number limits anymore (except the
usual device-mapper bugs). So /dev/mapper/sda63 is indeed possible.

This would all become a lot easier if we
1a. have a way to disable partition detection in the kernel via a knob
  or
1b. disable in-kernel partition detection by default and do it in
  userspace with "partx -a /dev/$DISK" when we get a disk_appears
  event. No change of tools needed, no user-visible changes.
2. (optional) switch to kpartx for partition detection at some point
  in the future when the tools can handle it.

As long as udev works fine (and we get an event on BLKRRPART) the
safest solution is 1b and it gives us all the freedom we need to
implement the right solution.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Agenda for tomorrow's distribution meeting

[Carl-Daniel Hailfinger]

Olaf: You asked for a way to create one dm device per partition in
http://lkml.org/lkml/2006/8/10/42 . See the kpartx description below
for a solution.

Andreas Jaeger wrote:
> Here're the agenda itmes that we plan to discuss tomorrow.  Please
> send input/ask questions etc and I'll bring your input into the
> meeting.
> 
> * /dev/hd removal: http://lkml.org/lkml/2006/8/9/285

Breaks everyone using partitions above hdX15. Two possible solutions:
- Use kpartx (and device mapper) for partitions sdX16 and greater
  (ugly, but works. Booting from such partitions however requires
  manual mapping in GRUB and LILO)
- Change minor number allocation for SCSI disks in the kernel
  (unlikely to be accepted without great opposition)

I'll test using kpartx and report back.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] sata partition limit

[Carl-Daniel Hailfinger]

Felix Miata wrote:
> I just tried to install 10.1 on this SATA system that was originally
> cloned from PATA when I bought a new system with I915/ICH6 and a faster
> CPU 17 months ago. Before the clone operation, 9.2 ran from /dev/hda16,
> Mandriva from /dev/hda7, Knoppix from /dev/hda15, [...]

One solution would be to use kpartx against /dev/sda. But then all your
partitions are device-mapper devices.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Using LVM by default for new installations?

[Carl-Daniel Hailfinger]

Ulrich Windl wrote:
> On 1 Jun 2006 at 15:08, Lenz Grimmer wrote:
> 
>> [...]Logical Volumes[...]
>>
>> I'd like to propose that SUSE Linux considers switching to this scheme
>> for new installations by default, too - I now filed this as an
>> enhancement request in Bugzilla:
>>
>> https://bugzilla.novell.com/show_bug.cgi?id=180762
>>
>> What do others think about that?
> 
> If it boots... ;-)

Works perfectly for me and my configuration is even more complicated:
- GRUB on hda
- /boot on hdb5
- / on LVM on hdb
- mount-by-label for all filesystems
- I can move hdb around as I want (hdc, hdd etc.) and only have to
  change one line in GRUB, no aother changes necessary.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Using LVM by default for new installations?

[Carl-Daniel Hailfinger]

jdd wrote:
> given modern disks are large, is it possible to have LVM strictly
> assigned at one disk, or separate LVM to each disk?

Of course.

> sharing a partition between several disks don't seems so nice to me
> (when not strictly necessary), but when a drive fails, anyway all it's
> content is lost so... we could have to good and not the bad?

Yes.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Using LVM by default for new installations?

[Carl-Daniel Hailfinger]

Hi,
Lenz Grimmer wrote:
> I noticed that Fedora seems to have switched to using Logical Volumes
> for installing on the hard disk since FC4. I personally am using LVM
> myself for a very long time and must say I am very fond of it. It
> provides much more flexibility than using plain partitions, especially
> when it comes to resizing or moving file systems or taking backups.
> 
> I'd like to propose that SUSE Linux considers switching to this scheme
> for new installations by default, too - I now filed this as an
> enhancement request in Bugzilla:
> 
> https://bugzilla.novell.com/show_bug.cgi?id=180762
> 
> What do others think about that?

Only if you combine it with mount-by-{label,uuid}. That would certainly
help people who are stuck after rearranging their hard disks.

While we are on the topic of booting: How about an additional initrd
which has all storage drivers included, not only the ones you are using
on your system? Currently there is no way to boot an installation
after changing the harddisk controller (except recovery from CD which
is unknown to most). So if the system can't find its root file system,
it can emit a message "please reboot and select 'boot recovery mode'".
The "boot recovery" initrd would have the same contents as the normal
initrd, but with all storage drivers and added auto-probing.

Thoughts?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[opensuse-factory] Re: [opensuse] Re: [suse-sles-e] Re: [opensuse-factory] SUSE on Woodcrest processors

[Carl-Daniel Hailfinger]

Rafa Grimán wrote:
> [...]
> The question would be: is there a  -mtune=woodcrest?

Please leave opensuse@opensuse.org out of this discussion.
Thanks.

The gcc mailing lists may give you the information you need.
See http://gcc.gnu.org/lists.html for details.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Package Management Design and Experience

[Carl-Daniel Hailfinger]

Andreas Hanke wrote:
> Volker Kuhlmann schrieb:
>> This thread is about what's annoying about the package management. .exe
>> processes are.
> 
> .exe processes are neither specific to the package management nor can
> they be influenced by the people who are designing the package
> management architecture for SUSE Linux.

So you say that the SUSE package management designers were forced
to use mono .exe files regardless of whether it makes sense?
Interesting conspiracy theory.

> Try a Mono or, maybe even better, an ECMA mailing list.

Sorry, I googled for "ecma mailing list exe" and found nothing
relevant. However, some sites seem to suggest .exe is not the
only recommended suffix for .NET code.

>> The .exe extension is specific to the mswindows platform
>> (can one say of legendary notoriety?).
> 
> No it isn't.

Examples please? (Except mono, which seems to be a reimplementation
of windows-only .NET code. And no, being able to use wine for some
.exe files doesn't make them cross-platform either.)


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Package Management Design and Experience

[Carl-Daniel Hailfinger]

Robert Schiele wrote:
> On Tue, May 30, 2006 at 02:08:24PM +0200, Carl-Daniel Hailfinger wrote:
>> I know that. But for the initial download, a bzip2 compressed file
>> is likely to be much smaller than a gzip compressed file.
> 
> About 30% on that type of file.  Do you think this is worth the effort to
> accept having redundant data in the repository with an additional risk of
> inconsistencies?

Yes. Because if it is done right, no inconsistencies can happen.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Package Management Design and Experience

[Carl-Daniel Hailfinger]

Robert Schiele wrote:
> On Tue, May 30, 2006 at 01:50:16PM +0200, Carl-Daniel Hailfinger wrote:
>> - have the repodata available twice: uncompressed and bzip2 compressed
>> - first download gets the bz2 version
>> - further syncs use rsync to update the repodata
> 
> No need to have it twice.  If you use gzip you can make gzip to compress the
> data in a way that rsync works pretty well.

I know that. But for the initial download, a bzip2 compressed file
is likely to be much smaller than a gzip compressed file.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Package Management Design and Experience

[Carl-Daniel Hailfinger]

Marcus Meissner wrote:
> On Tue, May 30, 2006 at 01:17:12PM +0200, Andreas Hanke wrote:
>> Volker Kuhlmann schrieb:
>>> * Downloading >10MB of gziped repodata just to check what changed today
>>> is not really acceptable, and a killer for dialup. This also emphasizes
>>> the previous point.
> 
> What about:
> 
> - cache the repodata.
> - download repomd.xml (very small)
> - check if cache is current by comparing the sha1sums.

- have the repodata available twice: uncompressed and bzip2 compressed
- first download gets the bz2 version
- further syncs use rsync to update the repodata

Disadvantages:
- need rsync support on servers


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Online update issue

[Carl-Daniel Hailfinger]

Marcus Meissner wrote:
> 
> Also, if you now install a package it will check if there is a security update
> and retrieve and install the fixed package instead.

Now that is definitely great! Is this also possible during installation?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Online update issue

[Carl-Daniel Hailfinger]

Christoph Thiel wrote:
> On Tue, 16 May 2006, Marcus Meissner wrote:
> 
>>>  I'm officially confused by the new way of updating. First: are there 
>>> any updates available at this moment? If I start the "Online update" 
>>> from Yast, it says no patches available.
>> There should be an opera and a pdns security patch.
> 
> ... in case you installed thosed packages -- which isn't the default case, 
> IIUC.

It even shows the patches if opera and pdns are *not* installed.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[opensuse-factory] yast2 bootloader hangs?

[Carl-Daniel Hailfinger]

Hi,

did anybody manage to use the yast2 bootloader module in current
factory? It always hangs for me when it wants to write out the
new configuration. Last y2log line is
"bootloader/routines/lib_iface.ycp:271 Writing files to system"

IIRC it worked well in one of the later betas. Oh well...
Bug #173421

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[opensuse-factory] K3B over SSH

[Carl-Daniel Hailfinger]

Hi,

has anyone successfully used k3b via X-Forwarding over SSH?
Adding a few thousand files to an iso took over half an hour
for me (latest k3b from factory).

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] going unmaintained

[Carl-Daniel Hailfinger]

Marcus Meissner schrieb:
> On Wed, Apr 26, 2006 at 01:17:23PM +0200, jdd wrote:
> 
>>I used 9.0 for a while.
>>
>>AFAIK when it become unmaintained, there where no way to
>>know that from YOU. may be I missed something in the logs?
> 
>>but anyway, there should be be a big red messages saying
>>"this version is no more maintained from YOU", for the
>>future distros
> 
> Its a good idea, perhaps we can add the functionality for
> the next products (after 10.1).

No need to do that. Simply release a patch with the description
"security updates are discontinued" which gives the warning.
If it is installed, it can change the susewatcher button to go
red permanently, if it is not installed, users still see it as
available security update.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] SUSE Linux 10.1 RC1 Status Update

[Carl-Daniel Hailfinger]

Andreas Jaeger schrieb:
> Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes:
> 
>>Ulrich Windl schrieb:
>>
>>>On 11 Apr 2006 at 23:32, SunSunich wrote:
>>>
>>>>Is it possible to update from OSS 10 to Factory by downloading only delta 
>>>>of 
>>>>rpms? Traffic is too expensive for me.
>>>
>>>I'd guess the delta iso for updating 10.0 to 10.1 would be about 98% as 
>>>large as 
>>
>>I'd guess 50% or someting like that. Still quite a bit of data.
> 
> I created a deltaISO between these two files:
> [...]
> IMO it's not worth putting these out, the disk usage is too large to
> save that bit of download time,

Thanks for taking the time to do this! Now we indeed know that such deltas
are not worth it. I'll add some snippet to the wiki about it.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] SUSE Linux 10.1 RC1 Status Update

[Carl-Daniel Hailfinger]

Hi,

Ulrich Windl schrieb:
> On 11 Apr 2006 at 23:32, SunSunich wrote:
> 
>>Is it possible to update from OSS 10 to Factory by downloading only delta of 
>>rpms? Traffic is too expensive for me.
> 
> I'd guess the delta iso for updating 10.0 to 10.1 would be about 98% as large 
> as 

I'd guess 50% or someting like that. Still quite a bit of data.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] dependencies: single-click

[Carl-Daniel Hailfinger]

Eberhard Moenkeberg schrieb:
> Back to the former state!

Go to sleep, Eberhard. And use y2pmsh when you wake up again.
Hint: Going from beta3 to factory with y2pmsh works.

Good night!
Carl-Daniel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Package Sugestions and Driver request for SUSE 10.1

[Carl-Daniel Hailfinger]

Hi,

Nathaniel Dube schrieb:
> First off, package request.  There is a neat program called xtraceroute

Add it to http://en.opensuse.org/Wishlist_Network

> I would also like to see MythTV 

Already at http://en.opensuse.org/Wishlist_Packages_that_were_already_there

> Recently I've come to noticed that SUSE 10.0 has improperly detected my 
> Belkin 

Please consult http://en.opensuse.org/Submitting_Bug_Reports and
http://en.opensuse.org/Bug_Reporting_FAQ to check if the bugs you found
are already fixed or still unknown.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] ndiswrapper missing on the beta8 CDs

[Carl-Daniel Hailfinger]

Mauricio Teixeira schrieb:
> Christoph Thiel wrote:
> 
>>ndiswrapper was never supported, and probably never will be supported by 
>>SUSE / Novell. It's simply impossible for our kernel developers to debug 
> 
> Ok. Let me get this straight: you mean *SUSE kernel developers* or *main
> kernel developers*?

Both.

> IMHO, SUSE doesn't have to care about it, considering you (the distro)
> get the module and the binary working and loading, the rest is with
> ndiswrapper developers.

People will complain either way.
If ndiswrapper works but crashes, people will say that Linux is unstable.
If ndiswrapper is not shipped, people will say that Linux doesn't support
  their hardware.

Crashes are obviously worse for the reputation of a distribution, so it
makes very much sense to NOT support or encourage ndiswrapper. And most
people are stubborn enough to insist that ndiswrapper is not the cause
of their crashes and even falsely claim untainted kernels just to get
support. This leads to loads of wasted time for SUSE and mainline kernel
developers.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] ndiswrapper missing on the beta8 CDs

[Carl-Daniel Hailfinger]

Mauricio Teixeira schrieb:
> Since I can remember people work to have hardware supported, not simply
> drop it (unless they find problems with licenses, which is simply not
> the case).

There is a license problem. Ndiswrapper is needed for certain (windows)
closed source network drivers which cannot be legally inserted into a GPL
kernel. So if you ship ndiswrapper, you encourage license violations.

How do you intend to solve that problem?


Regards,
Carl-Daniel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] ndiswrapper

[Carl-Daniel Hailfinger]

Kenneth Schneider schrieb:
> OSS 10.1 beta 8
> Trying to compile km_ndiswrapper-1.2-2.i586.rpm from 10.0 and am getting
> errors.
> Any suggestions short of sacrificing my first born?

Use ndiswrapper from 10.1beta8.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] ndiswrapper missing on the beta8 CDs

[Carl-Daniel Hailfinger]

Ulrich Windl schrieb:
> On 27 Mar 2006 at 11:42, Andreas Jaeger wrote:
> 
> [...]
> 
>>That sounds like an option, I'm adding now "No support is available
>>for ndiswrapper based network setups, and we will not accept bug
>>reports against the kernel if the ndiswrapper kernel module is loaded."
> 
> 
> If it's unloadable: "... is or was loaded in the running kernel". However 
> you'll 
> have a hard time proving it was loaded before any crash ;-)

IIRC it taints the kernel (in recent kernels only).


Regards,
Carl-Daniel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] older versions in Factory repository ?

[Carl-Daniel Hailfinger]

David Wright schrieb:
> P.S. I'm slowly getting frustrated, since Beta 4 I haven't been able to 
> update 
> to factory using YaST or rug once :-(

Use y2pmsh. It never stopped working.

Regards,
Carl-Daniel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Auto detection screen-resolution for install

[Carl-Daniel Hailfinger]

Azerion schrieb:
> At this moment you can, in the install-bootscreen, select what resolution you 

Right. Can!=must.

> want to use. As being a 'not total-noob' I know that I have to select the 
> proper resolution for my screen. But I guess new users don't see that option 
> and they end up with an install-screen that is to small (or deformed) and 

That's unlikely.

> does have a refreshrate less then 60.

Very unlikely. You would have to spend considerable efforts trying to get
that slow refresh rates.

> We have to fix that problem, and there are a few options (maybe more then 2?):
> 
> 1.) Auto-detection, don't know i that is possible but I assume so.

The screen resolution has been autodetected since years. And it worked
for all of my beta installations on i386 and x86_64. I have different
flat panels (1024x768, 1280x1024, 1400x1050 flat panel resolutions) and
CRTs (mostly in either 1024x768 or 1600x1200) and the optimal resulution
and refresh rate were always chosen.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Q: "forcedeth.c: Reverse Engineered nForce ethernet driver..."

[Carl-Daniel Hailfinger]

Hi,

Ulrich Windl schrieb:
> for 10.0 syslog for my new PC says: "forcedeth.c: Reverse Engineered nForce 
> ethernet driver..."

Ah yes, my driver. ;-)

> Is it expected that these reverse engineered drivers are absent in 10.1 for 
> legal 
> reasons?

forcedeth will be present. I had a pleasant talk with NVidia and they are
happy about the driver, they even started to contribute to it. So no legal
problems at all.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] drpmsync boot*.iso

[Carl-Daniel Hailfinger]

Hi,

Günther J. Niederwimmer schrieb:
> 
> why, are for the  factory tree /inst-source/boot/boot*.iso no deltas, in the 
> drpmsync tree?

Because IIRC deltarpm only handles .rpm files, so boot*.iso would not benefit
at all.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Ping Kurt Garloff: non-GPL Kernel Modules, some good news?

[Carl-Daniel Hailfinger]

David Wright schrieb:
> I raised this point at the IRC Meeting last night and was asked if I could 
> take it to the open-factory list and ask Kurt Garloff if he has any 
> information on this subject.
> 
> What is required: We need some "positive spin" on the situation.

AFAIK there is already some work underway. Expect some news in the next
few days.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Serious concerns about font rendering regression

[Carl-Daniel Hailfinger]

Hans-Peter Jansen schrieb:
> Am Samstag, 18. Februar 2006 13:19 schrieb houghi:
> 
>>I looked just at the two screenshots provided in the bugreport and I
>>don't see any difference between the two. Perhaps you need to
>>describe better what the differences is that one needs to look at.
> 
> 
> The kerning is very different. Look at the distance before and after the 
> first "e" of "Bearbeiten", also the "s" of "Lesezeichen". Both appear 
> outstanding unlike those from 9.3.
> 
> Here's an * where I think, distances are to big:
> 9.3:  B*earbei*ten  A*ns*i*c*ht  Gehe z*u  Les*ez*eic*hen
> 10.0: B*e*arbe*ite*n  An*s*i*cht  G*eh*e zu  L*e*s*eze*i*ch*e*n
> 
> But maybe, it's just me, and everybody else is fine with it. I'm not a 
> typographer, but it must hurt in their eyes like it does in mine.. 

This is funny. While I agree that the rendering in 10.0 is more
inconsistent, I strongly disagree that the distances are too large.
I would want the large distances between all characters. But then
again, I'm the only one who thinks it is important to be able to
distinguish between rn and m.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Webcam Support

[Carl-Daniel Hailfinger]

Joseph M. Gaffney schrieb:
> A recent thread [1] on suseforums at  is ongoing and discussing the webcam 
> support in SUSE.
> 
> I replied to the thread with a link to the Novell Cool Solutions feature on 
> compiling kernel drivers by example [2] , which uses the pwc module [3] as an 
> example.  Is there any reason why webcam support is not included out of the 
> box yet?

IIRC, the "reverse-engineered" pwc driver was just decompiled, which is
illegal in many jurisdictions. That's also why it was removed from the
official kernel shortly after it had entered.
For details, see http://lkml.org/lkml/2005/5/2/94 and
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=88c1834633341bbb94e315433067496338bff4ad

I doubt the hi-resolution variant(*) of this driver is ever going to ship in a
SUSE product. It would be suicide to include it.

* The controversy was about the compression module. You can still use
the driver with low resolutions.


Regards,
Carl-Daniel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

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/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Re[2]: 2.6.16 serious consequences / GPL_EXPORT_SYMBOL / USB drivers of major vendor excluded

[Carl-Daniel Hailfinger]

[EMAIL PROTECTED] wrote:
> 
> The user space does not ensure the reliability of time critical analog
> services like Fax G3 or analog modem emulations. This quality of service
> can only be guaranteed within the kernel space.
> [...] To anticipate any "open vs. closed source" discussion: Only a
> handful of companies worldwide have such know-how. With regard to our
> competitive situation, we have to protect our hard-won intellectual
> property and therefore cannot open the closed source part of the driver.

Thanks for clarifying the situation.

Since your intellectual property is in the DSP algorithms, are there
any obstacles opensourcing the parts of the ISDN drivers which only
handle normal ISDN without fax/modem emulation? This would make every
distribution out there support your devices without any additional work
on your side.
You can still offer your full-featured drivers as usual.

Regards,
Carl-Daniel Hailfinger

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

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/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

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/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[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 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/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] Re: AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

Hi,

since we both seem to be interested in ISDN support out of the
box, let us try to find solutions for the situation at hand.

L T Pensch schrieb:
> Carl-Daniel wrote:
> 
>> 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.
> 
> Are you sure? Greg does not know these devices and their drivers,
> his statement may be based on some stable knowledge of successful
> transition projects from kernel to user space *for some other de-
> vices* but simply taking this as a base to judge upon these ISDN
> and DSL device is not reasonable.

OK, so what are the technical reasons to keep the drivers in the
kernel? So far the only thing I saw was high-level talk about
userspace drivers being impossible due to... wait, no reason given.
You are the first person to mention a possible technical reason.


> Do you know for sure that libusb performance meets the strict
> requirements imposed by some of the protocols involved? As far
> as I understand this game, you will run into problems when trying
> to implement the required timing and reduce lethal latencies *in
> user space* for these drivers.

So the timing is a problem. Unfortunately I can't guarantee that
libusb will have the required latencies on a 100 MHz computer. Nor
can anybody guarantee latencies below 10 ms even with kernel
implementations on very fast machines. However, if you talk to
audio professionals, it seems that they really get decent latency
in userspace with recent kernels.

Latency is a big problem regardless of whether you do it in the
kernel or in userspace. It may be more difficult to handle it in
userspace, but unless someone comes up with real numbers proving
that this can't be done, I claim it is possible.

Now if you want to do echo compensation outside of the kernel,
you may have a problem.
* Looking at ISDN cards for the S0-Bus, I can't see where echo
  compensation would be needed (except for modem emulation).
* Looking at DSL cards, echo compensation may be needed if
  the card can't handle it in hardware.

So it *seems* that ISDN cards should have simple drivers.
Please correct me if I'm wrong.


> How many context/task transactions are acceptible for such a
> monster while doing 6MB/s DSL from kernel to userspace back to
> kernel and so forth?

6 MBit/s or 48 MBit/s?


> Let's face it... Go to eBay, sell your device to some Windows guys,
> if ever, it will take a long time before you can use your hardware
> on Linux again. :-(



As I stated in another mail in this thread, it seems that many
AVM ISDN cards are supported by GPL drivers. Some others probably
could be supported by GPL drivers with a subset of features.

I would *love* it if somebody from AVM could tell us what's the
reason to keep some ISDN drivers proprietary. Maybe we could help
finding a solution better than what's possible now.


Regards,
Carl-Daniel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [opensuse-factory] AVM/SUSE/Novell long-term relationship endangered

[Carl-Daniel Hailfinger]

Hi,

please note that I speak as a happy SUSE user and not for anyone else.

[EMAIL PROTECTED] 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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]