Re: regression in HDA functionality - FreeBSD

This is a discussion on Re: regression in HDA functionality - FreeBSD ; Gary Jennejohn wrote: > There's seems to have been a regression in HDA functionality with the > ATI SB600 High Definition Audio Controller since the 200809 snapshot > (amd64) was made. > > With this version of the driver from ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Re: regression in HDA functionality

  1. Re: regression in HDA functionality

    Gary Jennejohn wrote:
    > There's seems to have been a regression in HDA functionality with the
    > ATI SB600 High Definition Audio Controller since the 200809 snapshot
    > (amd64) was made.
    >
    > With this version of the driver from the snapshot, the headphone output
    > works:
    > /boot/kernel/snd_hda.ko:
    > $FreeBSD: src/sys/dev/sound/pci/hda/hdac.c,v 1.55 2008/07/15 02:34:44 delphij Exp $
    >
    > With this version made from sources updated yesterday the headphones no
    > longer work:
    > /boot/amd64/snd_hda.ko:
    > $FreeBSD: src/sys/dev/sound/pci/hda/hdac.c,v 1.61 2008/09/16 20:03:34 mav Exp $


    This version was completely rewritten. That and it's consequences was
    actively discussed on this and multimedia list.

    > I can provide verbose boot output from both kernels, if desired. Basically, it looks
    > like the headphone output gets disabled with the new driver.


    Usually such problem means that you have broken BIOS. Verbose output
    usually shows where the problem is and writing some device hints usually
    allows to fix the problem. Read updated snd_hda man page and if it not
    help - send your verbose output to me.

    --
    Alexander Motin
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  2. Re: regression in HDA functionality

    On Thu, 02 Oct 2008 10:40:15 +0300
    Alexander Motin wrote:

    > Gary Jennejohn wrote:
    > > There's seems to have been a regression in HDA functionality with the
    > > ATI SB600 High Definition Audio Controller since the 200809 snapshot
    > > (amd64) was made.
    > >
    > > With this version of the driver from the snapshot, the headphone output
    > > works:
    > > /boot/kernel/snd_hda.ko:
    > > $FreeBSD: src/sys/dev/sound/pci/hda/hdac.c,v 1.55 2008/07/15 02:34:44 delphij Exp $
    > >
    > > With this version made from sources updated yesterday the headphones no
    > > longer work:
    > > /boot/amd64/snd_hda.ko:
    > > $FreeBSD: src/sys/dev/sound/pci/hda/hdac.c,v 1.61 2008/09/16 20:03:34 mav Exp $

    >
    > This version was completely rewritten. That and it's consequences was
    > actively discussed on this and multimedia list.
    >


    Well, this is a new motherboard. With the old mobo I never had any
    problems so I basically ignored the discussions.

    > > I can provide verbose boot output from both kernels, if desired. Basically, it looks
    > > like the headphone output gets disabled with the new driver.

    >
    > Usually such problem means that you have broken BIOS. Verbose output
    > usually shows where the problem is and writing some device hints usually
    > allows to fix the problem. Read updated snd_hda man page and if it not
    > help - send your verbose output to me.
    >


    I read the man page but I must admit that it didn't help me any. I
    tried setting some device hints but they didn't help either. I'm
    obviously failing to understand something.

    See dmesg_verbose_amd64 and sndstat under ~gj on freefall.

    ---
    Gary Jennejohn
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  3. Re: regression in HDA functionality

    Gary Jennejohn wrote:
    >>> I can provide verbose boot output from both kernels, if desired. Basically, it looks
    >>> like the headphone output gets disabled with the new driver.

    >> Usually such problem means that you have broken BIOS. Verbose output
    >> usually shows where the problem is and writing some device hints usually
    >> allows to fix the problem. Read updated snd_hda man page and if it not
    >> help - send your verbose output to me.

    >
    > I read the man page but I must admit that it didn't help me any. I
    > tried setting some device hints but they didn't help either. I'm
    > obviously failing to understand something.
    >
    > See dmesg_verbose_amd64 and sndstat under ~gj on freefall.


    I don't see any problem there. It is possible that you may just
    misunderstood what you have got. You have:
    pcm0 - SPDIF/HDMI on video card
    pcm1 - rear 7.1 playback and main record
    pcm2 - front headphones playback and mic record
    pcm3 - SPDIF in/out.

    So, what the problem is? What are you doing, what expecting and what
    getting?

    --
    Alexander Motin
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  4. Re: regression in HDA functionality

    Joel Dahl wrote:
    > Alexander Motin wrote:
    >> Gary Jennejohn wrote:
    >> > With the old kernel it just works.

    >>
    >> Old kernel just was unable to support even a half of that what new one
    >> can. There was no SPDIF/HDMI, was no multi codec and multi device
    >> support, often was no recording.

    >
    > But basic stuff like speakers and plugging in headphones "just worked"
    > with the old driver. Your new driver may support much, much more
    > features, but we've seen an alarming numbers of complaints about basic
    > functionality being broken now (with the new driver).


    Functionality is not broken! It has just changed and that change is
    cleanly shown in manual:
    According to HDA and UAA specifications, depending on number of HDA
    buses and codecs present in system, their audio capabilities and BIOS
    provided configuration, the snd_hda driver often provides several PCM
    audio devices.

    The only I can add is a hint to use hw.snd.default_unit sysctl.

    > Oh, and I'm not trying to flame your work. It's great that we have
    > someone that takes care of this code, but I just can't help but think
    > that this driver should have gone through a few more iterations of
    > testing before entering the tree.


    Please don't. In two weeks since this code entered the tree (CURRENT)
    there was only one complain about real driver bug. All others were
    results of or BIOS's codec misconfiguration (which could be fixed with
    documented device hints) or user's misunderstanding.

    In this specific case man has actually TWO sound cards in system: one
    with HDMI output and another with set of connectors on motherboard.
    Driver itself worked perfectly! It is not a driver problem that video
    card's codec was detected first by PCI bus while it's HDMI output is not
    connected!

    If you think that driver should have some additional logic in handling
    of such cases - describe it please. I don't see why driver should not
    use digital outputs or how independent soundcards should be ordered
    (actually it is not driver's business to enumerate soundcards).

    If you think that driver is not documented good, please feel free to
    fix. I am not a native speaker, sorry. I did all I can.

    --
    Alexander Motin
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  5. Re: regression in HDA functionality

    On Thu, Oct 2, 2008 at 2:52 PM, Joel Dahl wrote:
    > Alexander Motin wrote:
    >>
    >> Gary Jennejohn wrote:
    >> > With the old kernel it just works.

    >>
    >> Old kernel just was unable to support even a half of that what new one
    >> can. There was no SPDIF/HDMI, was no multi codec and multi device support,
    >> often was no recording.

    >
    > But basic stuff like speakers and plugging in headphones "just worked" with
    > the old driver. Your new driver may support much, much more features, but
    > we've seen an alarming numbers of complaints about basic functionality being
    > broken now (with the new driver).
    >
    > Oh, and I'm not trying to flame your work. It's great that we have someone
    > that takes care of this code, but I just can't help but think that this
    > driver should have gone through a few more iterations of testing before
    > entering the tree.
    >
    > --
    > Joel


    The new hda definitely makes basic functionality "just work" for me.
    With the previous hda when I plugged headphones into my msi wind
    laptop sound continued to play out of the speakers.


    --
    The Mafia way is that we pursue larger goals under the guise of
    personal relationships.
    Fisheye
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  6. Re: regression in HDA functionality

    On Fri, 3 Oct 2008, Alexander Motin wrote:
    > If you think that driver should have some additional logic in
    > handling of such cases - describe it please. I don't see why driver
    > should not use digital outputs or how independent soundcards should
    > be ordered (actually it is not driver's business to enumerate
    > soundcards).
    >
    > If you think that driver is not documented good, please feel free to
    > fix. I am not a native speaker, sorry. I did all I can.


    It seems that a lot of new systems now have multiple sound outputs
    (because they use HDA) so there needs to be some way to elect a default
    sound output (override by sysctl of course

    eg selecting the HDMI output is pointless if there is no HDMI link
    active (can you detect HDMI status?)

    Maybe devd can be fed events in some way? I don't know if it's possible
    but if the HDA driver could detect jack status (ie if something is
    plugged in) then it would be fairly straightforward to write a script
    to switch output when the user plugged in headphones.

    --
    Daniel O'Connor software and network engineer
    for Genesis Software - http://www.gsoft.com.au
    "The nice thing about standards is that there
    are so many of them to choose from."
    -- Andrew Tanenbaum
    GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iD8DBQBI5WQE5ZPcIHs/zowRAvJ8AKCh8DOo403FmEzHgW6uOsyLmmACZQCgn3Th
    s9pdpmeEOQeGF8ZGWcdOzLg=
    =o9je
    -----END PGP SIGNATURE-----


  7. Re: regression in HDA functionality

    On Thu, Oct 02, 2008 at 11:52:16PM +0200, Joel Dahl wrote:
    > Alexander Motin wrote:
    > >Gary Jennejohn wrote:
    > > > With the old kernel it just works.

    > >
    > >Old kernel just was unable to support even a half of that what new one
    > >can. There was no SPDIF/HDMI, was no multi codec and multi device
    > >support, often was no recording.

    >
    > But basic stuff like speakers and plugging in headphones "just worked"
    > with the old driver.


    There are several PR's against the older driver. These PR were
    neglected and are still neglected.

    > Your new driver may support much, much more
    > features, but we've seen an alarming numbers of complaints about basic
    > functionality being broken now (with the new driver).


    There were just as many against the old driver. You didn't notice
    because you were one of the fortunate users.

    > Oh, and I'm not trying to flame your work. It's great that we have
    > someone that takes care of this code, but I just can't help but think
    > that this driver should have gone through a few more iterations of
    > testing before entering the tree.


    I don't agree with your position. I'll also note that neither the
    old driver nor the new driver work with my hardware. The difference
    is that Alexander has been quite helpful in providing help in debugging
    the problems with the new driver.

    --
    Steve
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  8. Re: regression in HDA functionality

    On Thu, 2 Oct 2008 13:25:06 -0700
    George Hartzell wrote:

    > Gary Jennejohn writes:
    > > On Thu, 02 Oct 2008 16:28:12 +0300
    > > Alexander Motin wrote:
    > >
    > > > I don't see any problem there. It is possible that you may just
    > > > misunderstood what you have got. You have:
    > > > pcm0 - SPDIF/HDMI on video card
    > > > pcm1 - rear 7.1 playback and main record
    > > > pcm2 - front headphones playback and mic record
    > > > pcm3 - SPDIF in/out.
    > > >
    > > > So, what the problem is? What are you doing, what expecting and what
    > > > getting?
    > > >

    > >
    > > I'm not getting any sound on the headphones, either plugged into the
    > > back or the front. With the old kernel it just works.

    >
    > You might discover the sound on one of the other pcm devices, that's
    > what happened to me on my mac pro (it's not clear that it should be on
    > the other device, but it works...).
    >
    > Here's a message swell.k sent to the list in response to my query
    > about how to use different devices.
    >
    > g.
    >
    >
    > swell.k@gmail.com writes:
    > > George Hartzell writes:
    > >
    > > [...]
    > > > An even simpler question would be, how can I test the other pcm
    > > > devices?

    > >
    > > If you look closely at /dev/sndstat output you'll notice there is
    > > `default' keyword on one of the pcm's. To change it you have to
    > > set hw.snd.default_unit accordingly. It's documented in sound(4).
    > > Next time you'll run mpg123 it will use different /dev/dsp.
    > >


    Thanks alot for the help from both of you. With this clue I was able to
    get the headphones working.

    ---
    Gary Jennejohn
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  9. Re: regression in HDA functionality

    On Fri, 03 Oct 2008 11:12:35 +0300
    Alexander Motin wrote:

    > Alexander Leidinger wrote:
    > >> In this specific case man has actually TWO sound cards in system: one
    > >> with HDMI output and another with set of connectors on motherboard.
    > >> Driver itself worked perfectly! It is not a driver problem that video
    > >> card's codec was detected first by PCI bus while it's HDMI output is
    > >> not connected!
    > >>
    > >> If you think that driver should have some additional logic in handling
    > >> of such cases - describe it please. I don't see why driver should not
    > >> use digital outputs or how independent soundcards should be ordered
    > >> (actually it is not driver's business to enumerate soundcards).

    > >
    > > Can you change the order of pcm devices from one soundcard? I understand
    > > that you can not change the PCI probe order, but maybe the order of
    > > pcm1-3 if pcm1-3 are on the same hardware.

    >
    > Generally it is possible.
    >


    I think that in my case there's more to it than just the new HDA driver,
    but I might be wrong.

    With GENERIC from the 200809 snap HDMI was discovered _after_ the other
    devices, i.e. it was pcm1. With the new kernel the discovery order
    was reversed, which seems to have led to my problems.

    ---
    Gary Jennejohn
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  10. Re: regression in HDA functionality

    Daniel O'Connor wrote:
    > It seems that a lot of new systems now have multiple sound outputs
    > (because they use HDA) so there needs to be some way to elect a default
    > sound output (override by sysctl of course
    >
    > eg selecting the HDMI output is pointless if there is no HDMI link
    > active (can you detect HDMI status?)
    >


    Hi all,
    I'm not a dev, but may have an idea.

    As i understand, the problem is that with the new patch, more devices
    are detected which changes the numbering of the pcm devices, thus
    out-of-the-box sound output does not (always) work.

    Maybe a solution would be to *always* register pcm0, so it becomes the
    default device. This device is not a real device but rather a virtual
    device like a wrapper/link to one of the other "real" pcm devices
    starting with pcm1. An algoritm could select which device pcm0 points
    to, and be changeable in sysctl, defaulting to "auto" or something. The
    auto setting could even be extended to change default device if
    situation changes, like a new USB Audio device is plugged in or the
    headphones-output is used. It might be hard to correctly predict the
    desired behavior for everyone, but getting default audio output (front
    speakers; stereo) to work out-of-the-box would be great.

    As a sidenote i'd like to comment on Alexander Motin's work, and Joel
    Dahl's comments. What you have here is a good example of the different
    viewpoints between developers and end-consumers. Alexander Motin's work
    is not flawed, its just missing a feature. A feature that makes sure
    that out-of-the-box sound output "just works". Which may be crucial to
    new users adopting FreeBSD who might one day be a FreeBSD kernel
    developer. As a coder, you know your way around, you know what places to
    check when something doesn't work. As an end-user, even a trivial
    setting in sysctl may take a long time to lookup and fix, or the user
    will simply abandon it or abandon FreeBSD altogether. We want to
    encourange users to try FreeBSD and see its beauty. As a developer it's
    always a challenge to meet the end-users expectations. That's why there
    should be a 'end-user feedback' phase, for example when commited to
    -STABLE. That's where these issues may arise which are very important
    for end-users, but may look trivial to devs and thus overlooked.

    Just thought about sharing my thoughts, and Alexander Motin thanks a lot
    for your work. It's highly appreciated! I hope that with some additional
    functionality, which chooses default output, everyone including the
    most novice end-users will be very pleased!

    Kind regards,
    Veronica
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  11. Re: regression in HDA functionality

    Quoting fluffles.net (from Mon, 06 Oct 2008
    08:07:29 +0200):

    > Daniel O'Connor wrote:
    >> It seems that a lot of new systems now have multiple sound outputs
    >> (because they use HDA) so there needs to be some way to elect a default
    >> sound output (override by sysctl of course
    >>
    >> eg selecting the HDMI output is pointless if there is no HDMI link
    >> active (can you detect HDMI status?)
    >>

    >
    > Hi all,
    > I'm not a dev, but may have an idea.
    >
    > As i understand, the problem is that with the new patch, more devices
    > are detected which changes the numbering of the pcm devices, thus
    > out-of-the-box sound output does not (always) work.
    >
    > Maybe a solution would be to *always* register pcm0, so it becomes the
    > default device. This device is not a real device but rather a virtual


    We have /dev/dsp, which points by default to the first registered soundcard.

    > device like a wrapper/link to one of the other "real" pcm devices
    > starting with pcm1. An algoritm could select which device pcm0 points
    > to, and be changeable in sysctl, defaulting to "auto" or something. The


    The default I wrote above, can be changed with a sysctl. You specify
    the device number (0 for pcm0, 1 for pcm1, ...). So except for one
    part (auto), we already have what you suggest.

    The difficult part is the "auto". What's the right thing to choose?
    Think a little bit about it, what's right for one person is wrong for
    another one. A person which has everything connected digitally wants
    the digital by default for sure, but a person which has analog and
    digital connected, can not get a mind reading machine to see a
    sensible default. And what about those which have the soundcard
    connected to an amplifier, and the graphic card also offers the HDMI
    sound channel to the screen? Does this person want the sound only via
    the amplifier, or does he want it via the build-in speakers of the
    screen (he may want the normal stuff routed to the screen, but at some
    point turn on the amplifier and use it instead)?

    > auto setting could even be extended to change default device if
    > situation changes, like a new USB Audio device is plugged in or the
    > headphones-output is used. It might be hard to correctly predict the
    > desired behavior for everyone, but getting default audio output (front
    > speakers; stereo) to work out-of-the-box would be great.


    So everytime I connect an USB Audio device it means I want to switch
    to it? Maybe it's a headset and I only want to make phone calls with
    it (by telling the phone application to use specific devices), but for
    the rest I want to use the already existing sound output.

    Bye,
    Alexander.

    --
    Save the bales!

    http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
    http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  12. Re: regression in HDA functionality

    On Mon, 6 Oct 2008, fluffles.net wrote:
    > > eg selecting the HDMI output is pointless if there is no HDMI link
    > > active (can you detect HDMI status?)

    >
    > As i understand, the problem is that with the new patch, more devices
    > are detected which changes the numbering of the pcm devices, thus
    > out-of-the-box sound output does not (always) work.
    >
    > Maybe a solution would be to *always* register pcm0, so it becomes
    > the default device. This device is not a real device but rather a
    > virtual device like a wrapper/link to one of the other "real" pcm
    > devices starting with pcm1. An algoritm could select which device
    > pcm0 points to, and be changeable in sysctl, defaulting to "auto" or
    > something. The auto setting could even be extended to change default
    > device if situation changes, like a new USB Audio device is plugged
    > in or the headphones-output is used. It might be hard to correctly
    > predict the desired behavior for everyone, but getting default audio
    > output (front speakers; stereo) to work out-of-the-box would be
    > great.


    This is already possible - using the hw.snd.default_unit sysctl (changes
    what /dev/mixer et al do).

    That is what I was thinking - basically you watch for new sound devices
    and decide which one to use (or sound events to say something is
    plugged in) and set the sysctl accordingly.

    --
    Daniel O'Connor software and network engineer
    for Genesis Software - http://www.gsoft.com.au
    "The nice thing about standards is that there
    are so many of them to choose from."
    -- Andrew Tanenbaum
    GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iD8DBQBI6eGc5ZPcIHs/zowRAgYaAJ0bInreaBhcnfZjUbKSNig9ki0i5gCdG/pg
    sVjOh1fB5f2AN/nWur/EUwo=
    =ZLzX
    -----END PGP SIGNATURE-----


  13. Re: regression in HDA functionality

    On 10/6/08, Gary Jennejohn wrote:
    > On Mon, 06 Oct 2008 11:48:38 +0200
    > "Alexander Leidinger" wrote:
    >
    >> Quoting fluffles.net (from Mon, 06 Oct 2008
    >> 08:07:29 +0200):
    >> > Maybe a solution would be to *always* register pcm0, so it becomes the
    >> > default device. This device is not a real device but rather a virtual

    >>
    >> We have /dev/dsp, which points by default to the first registered
    >> soundcard.
    >>

    >
    > Really? I do not have any /dev/dsp.


    dspX.Y are created on request.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  14. Re: regression in HDA functionality

    On Mon, 6 Oct 2008, Alexander Leidinger wrote:
    > We have /dev/dsp, which points by default to the first registered
    > soundcard.
    >
    > > device like a wrapper/link to one of the other "real" pcm devices
    > > starting with pcm1. An algoritm could select which device pcm0
    > > points to, and be changeable in sysctl, defaulting to "auto" or
    > > something. The

    >
    > The default I wrote above, can be changed with a sysctl. You specify
    > the device number (0 for pcm0, 1 for pcm1, ...). So except for one
    > part (auto), we already have what you suggest.
    >
    > The difficult part is the "auto". What's the right thing to choose?
    > Think a little bit about it, what's right for one person is wrong for
    > another one. A person which has everything connected digitally wants
    > the digital by default for sure, but a person which has analog and
    > digital connected, can not get a mind reading machine to see a
    > sensible default. And what about those which have the soundcard
    > connected to an amplifier, and the graphic card also offers the HDMI
    > sound channel to the screen? Does this person want the sound only via
    > the amplifier, or does he want it via the build-in speakers of the
    > screen (he may want the normal stuff routed to the screen, but at
    > some point turn on the amplifier and use it instead)?


    Have an option in rc.conf read by a script that takes devd events and
    does what the user wants.

    > > auto setting could even be extended to change default device if
    > > situation changes, like a new USB Audio device is plugged in or the
    > > headphones-output is used. It might be hard to correctly predict
    > > the desired behavior for everyone, but getting default audio output
    > > (front speakers; stereo) to work out-of-the-box would be great.

    >
    > So everytime I connect an USB Audio device it means I want to switch
    > to it? Maybe it's a headset and I only want to make phone calls with
    > it (by telling the phone application to use specific devices), but
    > for the rest I want to use the already existing sound output.


    Why not just allow a user to override it in rc.conf?
    Being able to have auto (ie what I plugged in most recently) and fixed
    (manually set it to what you want) would probably cover 90% of cases
    for minimal work.

    --
    Daniel O'Connor software and network engineer
    for Genesis Software - http://www.gsoft.com.au
    "The nice thing about standards is that there
    are so many of them to choose from."
    -- Andrew Tanenbaum
    GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iD8DBQBI6fwy5ZPcIHs/zowRAv2EAJ9d/arkSmq87XPoi0yaJ9vT3HJirACgmvmI
    UE+IugJnXQjXl+cBtxS5ZKc=
    =cJQL
    -----END PGP SIGNATURE-----


+ Reply to Thread