Re: SBCL just turned 1.0!

On Dec 1, 2:57 pm, Charlton Wilbur <cwil...@xxxxxxxxxxxxxx> wrote:
"KT" == Ken Tilton <kentil...@xxxxxxxxx> writes: KT> But if I trace a problem using SBCL /to/ SBCL and make a bug
KT> report and someone from the dev team responds "The open source
KT> fairy has left the building, we eagerly await your patch. You
KT> can download the sources here, the build instructions here,
KT> and... hello? hello? Kenny?", I'll be on the phone to
KT> Lispworks or begging Franz for forgiveness.

Ah, but that's preferable to the situation I've been in before - I
trace the problem to the vendor, make a bug report, and the vendor
responds "Thanks, it's entered in our bug database."

At my first professional programming job, I tracked down a bug in the
shared library code in a certain OS. Proprietary OS, but we had a
magical support contract, so I filed a support request and included
the code needed to consistently reproduce it. They thanked us and
informed us that a fix was planned for a later release at an
unspecified date. This was a show-stopping bug; while it persisted,
we could not get our database to talk to our webserver.

But wait! We had paid umpty-thousand more for a source code license!
Armed with that and gdb, another programmer managed to find the line
of code with the bug and fix it! We then submitted a patch to the
vendor, who at least gave us credit when they finally got around to
issuing the update.

I don't know what we would have done without that support contract!
Thank goodness the vendor was responsive to our needs! I don't know
what would have happened if we had gone with an open-source operating
system with no support!

There are cases in which the feature set is so compelling that there
is no free alternative -- I use OS X on my desktop for that reason.
But I prefer the honest lack of a support guarantee, plus available
source code, to a guarantee of support that's only enforceable because
I can walk away from that product. If I have access to the source
code, I can fix the problem or pay someone else to fix it for me; if I
don't have access to the source code, I'm completely at the mercy of
the vendor. You apparently trust the vendor much more than I do.

Charlton

I also have had past experiences like Charlton. I have three
experiences with vendors/software.
1) Small company vendor. We paid a boatload of money for a file system
that "will just work". I spend many months getting it working and
feeding back bug fixes, it was obvious that their code had never run on
ARM processsor before. They were extremely receptive of the patches, I
had full code access and they rolled my fixes in. However, this was a
product we paid a lot of money for so that we wouldn't need to fix it,
and they got our fixes for free! We ended up ditching the system and
using an open source filesystem. Not really a bad experience, but not
good either.

2) Microsoft. I had partial access to code, which is the biggest issue
- you can't even really determine how to work around bugs. MS will
only talk to you if you pay them to or are a huge customer. Even when
we hand MS the backtraces, steps to reproduce and a possible fix they
may or may not look at it. If they do fix it, you don't get the fix
until the next release cycle and you can't ship your product until you
get the official MS binaries - ie, no way for us to patch it.

3) Linux kernel & other opensource projects. You have the code and you
are able to fix it given enough motivation. You may or may not get
help from mailing lists, but in generally it is pretty good. Your
patch if it is good will go into the main source. You don't need to
wait for the maintainer to bless the patch for you to ship.

Number 1 and 3 were pretty much the same in terms of support and
feedback, though giving time and effort to something that you paid big
money for hurts.
Trying to get support from MS is like getting blood from a stone.

So, like all things, it is not a case of Free Software is better/worse
than propriety software - it is shades of grey.

This thread started as a simple "well done for hitting 1.0, an
important milestone", but somehow got trolled into a free/propriety
flame fest.

Anyhow - well done to the SBCL devs. I appreciate the hard work you've
put in, and I'm glad you're all having fun working on free software.

Cheers
Brad

.

Relevant Pages

  • Re: [ofa-general] Updated InfiniBand/RDMA merge plans for 2.6.24
    ... My user_mad P_Key index support patch. ... Pradeep's IPoIB CM support for devices that don't have SRQs. ... is not strictly a fix and you send it to me after the merge window ... IB/ehca: Make output clearer by removing some debug messages ...
    (Linux-Kernel)
  • Updated InfiniBand/RDMA merge plans for 2.6.24
    ... My user_mad P_Key index support patch. ... Pradeep's IPoIB CM support for devices that don't have SRQs. ... is not strictly a fix and you send it to me after the merge window ... IB/ehca: Make output clearer by removing some debug messages ...
    (Linux-Kernel)
  • Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly
    ... Which is why the vendor NEEDS TO PROVIDE A REPORTING MECHANISM ... >>support customers, on their website and to reputable groups such as CERT) ... >Our customers knew better than to just blindly patch an executable. ...
    (comp.os.vms)
  • Linux 2.4.37-rc1
    ... PCI updates to support recent IDE/SATA/AHCI controllers commonly found ... unplugging USB devices. ... Accompanying this patch is another one to add the "rootdelay" command ... Fix SMP ordering hole in fcntl_setlk ...
    (Linux-Kernel)
  • Re: [PATCH -mm] fix per-device dma_mapping_ops support
    ... This patch fixes a bug in per-device dma_mapping_ops support. ... ready so we need this fix in -mm. ...
    (Linux-Kernel)