From: Phil Muldoon <pmuldoon@redhat.com>
To: tromey@redhat.com
Cc: Frysk List <frysk@sourceware.org>
Subject: Re: Changes
Date: Fri, 11 Jul 2008 10:44:00 -0000 [thread overview]
Message-ID: <48773983.5050508@redhat.com> (raw)
In-Reply-To: <m33ami66rk.fsf@fleche.redhat.com>
Tom Tromey wrote:
> * GDB. A recurring question is: why not expend our efforts improving
> gdb? There are no easy answers here; the tradeoffs are complicated.
>
> This is probably more of a Red Hat internal decision (it is about
> where we want to focus our efforts, not about the frysk project per
> se) -- but it is an obvious and important question and deserves to
> be brought up here.
>
> We're open to arguments either way on this topic. Given our goals,
> what would you choose to do
My 2 euros on why a new project is a viable.
GDB is a cool project. No doubt. It has remained relevant for years, and
still does today. It has maintained the status as the best open-source
debugger - free as in beer and speech through that time. And despite
many pretenders and competitors it continues to remain as the best and
most viable. It attracts the brightest minds, and generates sometime
intense controversy; it has been described as a work of art and, well,
other things not so nicely put. GDB is great because of ALL the people
that work on it, past and present. How many visionaries, engineers,
testers and documenters have poured effort into it over the years? Often
silently, sometimes not ;)
But despite this sum effort, and the momentum, I still think there is
room for a new project. Because I seem them as complimentary. I do not
subscribe to the division-of-labour and mutual-exclusion theories in
free software. Granted, in an ideal world we should all work on one
piece of software, to fulfil one concrete goal. But we do not do that,
it seems. It is clearly evident through many projects: GNOME and KDE,
Emacs and VIM, Eclipse and Netbeans, and so on. I find this compelling
behaviour; look at the multitude of window managers that one can use
with the desktop. And what we lose in division-of-labour, we gain in a a
more vibrant community. But this is a deeper problem for debuggers, I
think. Software is a complex. Debuggers perhaps among the most complex
and challenging to write. Nobody wants a buggy debugger: the engineer
who has reached for it is already frustrated. We do not need to add to
the sum of that. And heaven help us if we further erode the stability of
the inferior beyond the state it was in when we were called. We need
more people in the open-source debugging world.
So with that being said, I do not think the "new debugger" and GDB
should exist in a vacuum. And as long as the licenses are compatible
(and I see no reason why they should not be), we should borrow, fix,
back-port and submit patches from each others software.
GDB does not do C++ well. I do not like being negative, but it just
doesn't. I am not terribly sure why, though I have tried to find out.
Maybe the problem is that it has been added over time, to an engine that
in not OOP aware? How do we solve that? I think we solve it by writing
another scriptable debugger in a research like environment. Once we
figure out why, there is no reason why we can then present the case to
the GDB community. And similarly, GDB has a very powerful urge to remain
as stable as possible. Stability over change. I do not think it is
cost-efficient to be answering research question in a release
environment, or in a product that has a powerful and strong promise of
stability to a community. On that note, I would invite the GDB people to
use this new promise of a project as a proving ground for technology.
Mature it here, then port it. If we do our homework right, we can make
cross-pollination as easy (or as hard, if we are sloppy) as possible.
Regards
Phil Muldoon
next prev parent reply other threads:[~2008-07-11 10:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-09 22:19 Changes Tom Tromey
2008-07-10 0:06 ` Changes Sami Wagiaalla
2008-07-11 17:04 ` Changes Sami Wagiaalla
2008-07-10 4:17 ` Changes Thiago Jung Bauermann
2008-07-10 5:43 ` Changes Sami Wagiaalla
2008-07-10 13:14 ` Changes Rick Moseley
2008-07-10 13:26 ` Changes Phil Muldoon
2008-07-10 17:07 ` Changes Eric Bachalo
2008-07-10 19:43 ` Changes Dodji Seketeli
2008-07-11 16:55 ` Changes Tom Tromey
2008-07-10 8:24 ` Changes Phil Muldoon
2008-07-11 10:44 ` Phil Muldoon [this message]
2008-07-17 7:51 ` Changes Jan Blunck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48773983.5050508@redhat.com \
--to=pmuldoon@redhat.com \
--cc=frysk@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).