Has anyone produced a board using Kicad?

[Lord Vain]

I was wondering if anyone here has ever designed and produced a working PCB
with Kicad, the free open-source CAE package. I've looked around but haven't
found anything.



*** ***

 

[Ian Bell]

I was wondering if anyone here has ever designed and produced a working
PCB with Kicad, the free open-source CAE package. I've looked around but
haven't found anything.

Try looking at the kicad user group at yahoo:

http://groups.yahoo.com/group/kicad-users/

I am sure you will find many users there who have successfully made boards.

Ian

 

[Hal Murray]

I was wondering if anyone here has ever designed and produced a working PCB

with Kicad, the free open-source CAE package. I've looked around but haven't
found anything.

I haven't built any board with it, but I did work with it enough to
be sure I could use it if I needed to.

I think the key idea is that the auto-router is next to useless.
Are you prepared to hand route your whole board?

 

[[email protected]]

I haven't built any board with it, but I did work with it enough to
be sure I could use it if I needed to.

I think the key idea is that the auto-router is next to useless.
Are you prepared to hand route your whole board?

I still use an older version of PCB (050318) which is fast. And I do
hand route almost everything, as it's autorouter isn't up to a high end
($30K) router either. On the other hand, I also layout very dense
boards that even OrCad/Cadence chokes badly on too, so I've gotten used
to hand layout as required, rather than optional. I wish the gEDA
integration was as good as Kicad at times, but it's never been a severe
problem either.

I've turned several high density boards with PCB without problem that
are double sided smt, small form factor (PC104+) with BGA560 FPGA,
multiple TSOP2 SDRAMs, EEPROMs, Compact Flash, and speciality analog
audio, ISA/PCI -- several thousand connections in the 3.75" x 3.5" form
factor. I gave that boards flat netlist to another designer that was
unable to get OrCad to route it with the same placement (or any
placement). Took me a little over a week to hand layout with PCB, and
he spent that much with an unusable OrCad effort after given both a
working placement and netlist.

I've also done several 16" x 22" dense double sided 6-8 layer smt
layouts with PCB that have a couple hundred thousand connections, also
hand layout, that took a couple weeks. I again had one of those already
flat netlists handed to another OrCad guy, and it was unable to route
it either. Over the years, several clients have autorouted my (and
other engineers) designs, only to end up with useless mazes that are
unmaintainable, and difficult to debug due to signal integrity issues.
Autorouting is highly over rated for high speed digital design, using
dense smd packages.

Humans, with a little practice, still do MUCH better.

 

[DJ Delorie]

I still use an older version of PCB (050318) which is fast.

The HID project is done, so you might be interested in trying the
latest snapshot (20060422). You can configure it for either Gtk or
Lesstif (or openmotif, depending on what you have). The lesstif hid
is very streamlined, and a number of our regulars claim it's much
faster and easier to use than what they were used to.

The Gtk hid looks much like what you're used to.

FYI: we've gotten the Gtk hid to build on windows, and the lesstif hid
builds on Mac OS/X (and solaris, hp/ux, aix, irix, etc).

And I do hand route almost everything, as it's autorouter isn't up
to a high end ($30K) router either.

I've commented that we need a volunteer to replace the gridless router
with a topological router. Gridless just can't keep up with today's
dense layouts. I'm sure the topological router won't be up to
everything either, but it should do a lot better than gridless.

My (hopefully) next "big" project is a global trace "puller" that lets
you be sloppy with your layout, and have PCB clean things up for you
(straight runs, graceful curves, minimum trace length). We'll see if
I ever finish (or even start) it ;-)

I wish the gEDA integration was as good as Kicad at times,

It's a common request, and we're making *some* progress with it. Dan
just offered his first pass at a "mode menu" for gschem, which lets
you do pcb-specific things right from the gschem menu. PCB also has a
listener port for remote control. He's working on tying things
together in useful ways (like cross-selecting).

I've turned several high density boards with PCB without problem
that are double sided smt, small form factor (PC104+) with BGA560
FPGA, multiple TSOP2 SDRAMs, EEPROMs, Compact Flash, and speciality
analog audio, ISA/PCI -- several thousand connections in the 3.75" x
3.5" form factor.

Pretty pictures? (and I'm always on the lookout for .pcb files for my
testing, if you have some tricky ones you can send me).

I've also done several 16" x 22" dense double sided 6-8 layer smt
layouts with PCB that have a couple hundred thousand connections,

Wow.

The lesstif hid of PCB allows boards up to about a quarter mile per
side, in case you need to go even bigger

 

[samiam]

Wow.

The lesstif hid of PCB allows boards up to about a quarter mile per
side, in case you need to go even bigger

PCB is used by serious hobbyists (like myself) and probably even
commercial groups ... my friend works in an R&D lab and uses it to
run off prototypes ... I never asked if its put into commerical
work but hes in the embedded field ... so you guess.

I am sure you (and the other developers) already know this .. if you
get regular feedback

 

[DJ Delorie]

PCB is used by serious hobbyists (like myself) and probably even
commercial groups ... my friend works in an R&D lab and uses it to
run off prototypes ... I never asked if its put into commerical work
but hes in the embedded field ... so you guess.

I know of a few companies that use it for commercial products, but
they're not all willing to disclose their EDA process to the public.
It's a competitive field out there.

 

[Hal Murray]

The lesstif hid of PCB allows boards up to about a quarter mile per
side, in case you need to go even bigger

Many years ago, my boss wrote a CAD package. When he got the
gerber output part working, he took his laptop down to the local
board house and handed them a floppy disk. They read it in to check
things. Something was off by 10^6. I forget which way. The board
was either the size of a period or it covered all of San Jose.

A few quick edits fixed that.

 

[[email protected]]

It's a common request, and we're making *some* progress with it. Dan
just offered his first pass at a "mode menu" for gschem, which lets
you do pcb-specific things right from the gschem menu. PCB also has a
listener port for remote control. He's working on tying things
together in useful ways (like cross-selecting).

It really needs to be the same tool, one netlist, one symbol library
(with referencing a schematic footprint and a pcb footprint, with
common pin naming/annotation), and two physical windows (one for the
schematic domain, and the other for the PCB domain), with a common
working file which contains the physical "tracks" and object placement
for both.

That way when you hand route the pcb assigning pins, new parts and nets
show up as unplaced symbols and rats on the schematic window. And when
you add schematic objects and connections they show up as unplaced
footprints and rats on the pcb window.

 

[DJ Delorie]

It really needs to be the same tool,

Or at least *seem* like it's the same tool. Otherwise, I agree.

 

[[email protected]]

Or at least *seem* like it's the same tool. Otherwise, I agree.

On larger designs, memory is being pushed to maintain lists and objects
instantiated already. Paging severely cuts into performance. When
running as a separate application, there is substantial page
replication introduced for every data page for a long list of shared
library instances, plus replication of the netlists. Likewise,
performance is critially tied to working set, having a second
application running concurrently with equally large working set, will
provoke substantial cache thrashing, which will show up as memory
latency induced jerkyness in the UI, as the cache is flushed out and
reloaded between contexts. While these may seem like parameters in the
application architecture that can be ignored, perceived UI performance
is heavily dependent on them. Similarly the communication between
separate applications results in context switches, which causes
additional cache thrashing by including large sections of the kernel in
the working set. Consider the processor is some 20-100 times faster
than L2/L3 cache these days, and the cache is frequently another 10-50
times or more faster than memory. Exceeding cache working sets,
effectively turns the machine into a 50MHz processor again.

There are substantial performance reasons suggesting that it should be
the same application, (just a different thread at most) to conserve
memory resources, and improve performance. While they may not be
critical for toy student projects, for many real life projects which
are much larger, they become critical UI problems. The sample
ProofOfConcept design I sent you, is about 1/5 the size of several
production designs I have done using PCB.

When the typical desktop CPU comes standard with 10MB or better of L2
cache, these issues might go away. Last time I checked, this was only
available for high end Itianum processors, well outside the reach of
most mortals in cost (or me right now).

 

[Stuart Brorson]

[email protected] wrote:

: DJ Delorie wrote:
:> [email protected] writes:
:> > It really needs to be the same tool,
:>
:> Or at least *seem* like it's the same tool. Otherwise, I agree.

: On larger designs, memory is being pushed to maintain lists and objects
: instantiated already. Paging severely cuts into performance. When
: running as a separate application, there is substantial page
: replication introduced for every data page for a long list of shared
: library instances, plus replication of the netlists. Likewise,
: performance is critially tied to working set, having a second
: application running concurrently with equally large working set, will
: provoke substantial cache thrashing, which will show up as memory
: latency induced jerkyness in the UI, as the cache is flushed out and
: reloaded between contexts. While these may seem like parameters in the
: application architecture that can be ignored, perceived UI performance
: is heavily dependent on them. Similarly the communication between
: separate applications results in context switches, which causes
: additional cache thrashing by including large sections of the kernel in
: the working set. Consider the processor is some 20-100 times faster
: than L2/L3 cache these days, and the cache is frequently another 10-50
: times or more faster than memory. Exceeding cache working sets,
: effectively turns the machine into a 50MHz processor again.

: There are substantial performance reasons suggesting that it should be
: the same application, (just a different thread at most) to conserve
: memory resources, and improve performance. While they may not be
: critical for toy student projects, for many real life projects which
: are much larger, they become critical UI problems. The sample
: ProofOfConcept design I sent you, is about 1/5 the size of several
: production designs I have done using PCB.

: When the typical desktop CPU comes standard with 10MB or better of L2
: cache, these issues might go away. Last time I checked, this was only
: available for high end Itianum processors, well outside the reach of
: most mortals in cost (or me right now).

Interesting points. My comments/questions:

* From your experience, can you quantify how large a design must be
before it begins to hit memory limits when using gEDA/PCB? How many
nets/components? This information would be interesting to the
developers. (Or if your observations are about general computer
performance as opposed to gEDA/PCB, perhaps you could make that clear,
so we don't worry about possible performance enhancements we might
make?)

* As for making schematic capture and layout separate threads of the
same process: they weren't designed together, don't share
datastructures or an API, and so therefore integration represents a
lot of work.

At the level of interoperability, the schematic capture program and
the layout program work great together. But they're not the same
program, and combining them into one program is not only difficult,
but is not necessarily a good thing. This is basically a FAQ:

http://geda.seul.org/wiki/geda:faq#...grams_and_not_a_single_integrated_application

I'll note again that a board flow commonly found in the Boston area
is ViewDraw -> Allegro. ViewDraw is totally unrelated to Allegro, and
nowadays they are products of competitors. Nonetheless, this flow
works great, since ViewDraw has the ability to netlist to Allegro
quite easily. (Let's hope Mentor and Cadence don't try to break this
link moving forward.) Gschem and PCB have the same relationship: You
can netlist quite handily from gschem to PCB. Moving forward, you
will see backward annotation as well as a feature allowing you to
select a component in PCB and see the symbol light up in gschem.
Therefore, this business about "better integration" is just nonsense.

* As for this business about "toy student projects", my experience is
that a good chunk of boards are of the 6" x 8" 4-6 layer type, both in
academia as well as in the real world. Think test boards, knock-off
boards for the manufacturing floor, quick data acquisition boards,
amplifier modules, medium-sized microcontroller boards, connector
aggregation boards, sensor boards, protocol conversion boards, boards
for test fixtures, peripherial boards, PCI boards, audio boards, ham
radio boards, hobby robot boards, motor control boards, position
sensor boards etc. etc. etc. . . .

.. . . That's the target audience for gEDA/PCB. Of course, some people
have created larger boards than that using the gEDA tools, and bully
for them! But my opinion is this: If you're designing a 15"x24" 20
layer router board with controlled impedance, high-speed,
matched-length differential busses, you should probably go out and buy
one of the fine high-end products from Mentor or Cadence.

* Next, you made this comment:

: When the typical desktop CPU comes standard with 10MB or better of L2
: cache, these issues might go away. Last time I checked, this was only
: available for high end Itianum processors, well outside the reach of
: most mortals in cost (or me right now).

My answer to you is: Which to you prefer, shelling out a few
thousand $$$ for a better computer to run a powerful open-source
design suite, or shelling out tens of thousands of $$$ to run a secret
source design suite (likely requiring a high-end work station anyway)?

* Finally, I'll point out that gEDA/PCB is an open-source project, so
people interested in new features are always welcome to submit patches
for incorporation into the code base. We get a large number of people
complaining about one or another imagined misfeature in the gEDA
suite. However, the ratio of code patches to suggestions/complaints
is pitifully small. I sometimes tell the folks with suggestions: A
patch is worth a thousand suggestions.

Stuart

 

[Ian Bell]

At the level of interoperability, the schematic capture program and
the layout program work great together. But they're not the same
program, and combining them into one program is not only difficult,
but is not necessarily a good thing. This is basically a FAQ:

http://geda.seul.org/wiki/geda:faq#...grams_and_not_a_single_integrated_application

I think Kicad goes one better than gEDA in that it is a monolith
confederacy. Its major functional programs are separate but share a common
UI and data structure.

Ian

 

[Stuart Brorson]

: Stuart Brorson wrote:
:>
:> At the level of interoperability, the schematic capture program and
:> the layout program work great together. But they're not the same
:> program, and combining them into one program is not only difficult,
:> but is not necessarily a good thing. This is basically a FAQ:
:>
:>
: http://geda.seul.org/wiki/geda:faq#...grams_and_not_a_single_integrated_application
:>

: I think Kicad goes one better than gEDA in that it is a monolith
: confederacy. Its major functional programs are separate but share a common
: UI and data structure.

Maybe. I think that the user doesn't care about datastructures or
APIs. He just wants to design a circuit, and is usually oblivious to
the way the code works.

I do agree that newbies like Kicad better since they don't
leave the comfortable graphical environment to go from schematic
capture to layout. I also think that the way you drive Kicad is a
little more similar to the normal Windoze paradigm, whereas gEDA is
more unix-y. However, gEDA is changing this ... even now there are
some patches in CVS which make gEDA more Windozey.

On the other hand, I think that Kicad is a little buggier
than gEDA -- it segfaulted a couple of time during my hour or two
playing with it. Gschem never segfaults. Also, Kicad is more limited
IMHO. That is, gEDA/PCB scales nicely to large designs with lots of
schematic pages (many nets and many components). I am not sure Kicad
scales to more than one page (although it may and I missed that
feature). I think that gEDA SPICE netlister is much more
full-featured than Kicads (which can't import external vendor
subcircuit model files). Also, due to it's extinsible architecture,
gEDA can netlist to over 20 different file formats, including 4 or 5
commercial layout packages. Can Kicad do that? (Indeed, can you
write out a netlist native to Kicad's layout editor?) Finally, I
personaly like the fact that gEDA/PCB are connected via
writing/reading files. It makes it easy to break into the flow with
scripts if need be.

I am very glad that Kicad is around, and I have recommended it to
newbies who weren't up to using gEDA/PCB. Us gEDA developers have
played with it a little bit, and are very impressed with the UI
experience. Personally, I tend to see it as more
suited to smaller boards/student projects, but I may be wrong and it
may be just as capable as gEDA of scaling up. It would be interesting
to do a head-to-head comparison of gEDA/PCB vs. Kicad to see which can
handle larger designs, more layers, more nets, larger boards, etc.
Hmmm, an interesting topic for a FreeDog get-together.

Stuart

 

[[email protected]]

Hi Stuart,

I'm also doing open source work in my free time, with very little
outside help, even though some three dozen people have asked to join
the project, and most have since been "fired" for failing to contribute
even at a discussion level (and there are a few more likely to be fired
for the same reason soon). Potentially helpful developers are certain
to look at the long list, and falsely assume there are enough people
for the project. http://sourceforge.net/projects/fpgac

The difference is that I listen very carefully to my users comments,
and suggestions, rather than argue with them that should should settle
for less, take it or leave it. I see the project as a reflection on my
skills, as the ability to do a reasonable job at real life projects
too. FpgaC has a long way to go to be commercial quality, and my goals
are nothing short of that, despite it's current (and numerous) short
commings.

I believe that hobbiests and small businesses (IE consultants) should
have access to EDA tools too ... without a $30K budget for a netlist C
compiler that has usable synthesis ability. Ditto for quality spice,
schematic, and pcb tools. When our imagination is limited by our tools
budget, our home projects, and the contracts we can bid for, are
severely limited to "toy" sized projects.

There are many, and the most notable, open source projects that don't
strive to produce a toy operating system, a toy compiler, a toy word
processor, a toy windowing system, but full featured industrial
strength projects every developer that contributes to can be proud of.

* From your experience, can you quantify how large a design must be
before it begins to hit memory limits when using gEDA/PCB? How many
nets/components? This information would be interesting to the
developers. (Or if your observations are about general computer
performance as opposed to gEDA/PCB, perhaps you could make that clear,
so we don't worry about possible performance enhancements we might
make?)

You know your design better than anyone else ... how many parts and
line segments will fit in a 128K or 256K or 512K L2/L3 cache? While it
might not seem a problem with a highly interactive (human is the major
delay) application, consider that it will be a problem as soon as you
start doing things to actually save the human time ... like
autorouting, or assisted drawing by dragging a rat, etc ... where
waling your lists will flush the caches and severely compete with X
that also has large memory requirements.

The GTK version of PCB has been "useless" for a year, and still is
today, because it generates 10-80 second delays with the mouse locked
up refreshing a drawing of a modest sized board. The older Xaw and the
current Lesstiff based version don't have that problem .... so the GTK
version pretty much is for toy designs only. Much of this delay is
memory thrashing.

The thought behind gEDA should be to build commercial quality tools,
capable of real design layouts ... motherboards, complex PCI I/O cards,
complex embedded systems designs, so that home hobbiests and small
businesses/consultants designs are not limited by their budget for
tools.

* As for making schematic capture and layout separate threads of the
same process: they weren't designed together, don't share
datastructures or an API, and so therefore integration represents a
lot of work.

I believe in do it once right. The more energy that you put into doing
it in a way that can not be used to do it right, is actually wasted in
the long term and of very little real value in that respect. If you
decide to limit your portion of gEDA to toy sized projects, someone
else someday will have the vision to replace your work completely, and
do it right. You create your own legacy with open source.

At the level of interoperability, the schematic capture program and
the layout program work great together. But they're not the same
program, and combining them into one program is not only difficult,
but is not necessarily a good thing. This is basically a FAQ:

depends certainly on your goals ... I face people every day that argue
for substandard, sometimes with very valid reasons from their
viewpoints. I also actively help others that set much higher goals, as
my time is not wasted, and the end product will be worth having my name
on.

Therefore, this business about "better integration" is just nonsense.

Actually, I don't think so ... but you are doing the job ... do it your
way, and people will certainly remember you for it.

* As for this business about "toy student projects", my experience is
that a good chunk of boards are of the 6" x 8" 4-6 layer type, both in

I'm glad most major open source developers are not that short sighted,
or else linux, gcc, gnu tools, mozilla/firefox, open office, etc ...
would all be toys and not really usable as they are today.

My answer to you is: Which to you prefer, shelling out a few
thousand $$$ for a better computer to run a powerful open-source
design suite, or shelling out tens of thousands of $$$ to run a secret
source design suite (likely requiring a high-end work station anyway)?

It has never been either/or .... for Linux, for gcc, for gnu tools, for
mozilla/firefox, for open office, for KDE/Gnome, and hundreds of other
high quality open source projects whose commercial counter parts where
also very expensive just a decade a go.

* Finally, I'll point out that gEDA/PCB is an open-source project, so
people interested in new features are always welcome to submit patches
for incorporation into the code base. We get a large number of people
complaining about one or another imagined misfeature in the gEDA
suite. However, the ratio of code patches to suggestions/complaints
is pitifully small. I sometimes tell the folks with suggestions: A
patch is worth a thousand suggestions.

not imagined ... from experience .... and from that experience I've
learned that when someone sets their sights for barely good enough,
they will always fail. When someone sets their sights very high, with
excellent standards, even when they miss the mark, what they have
produced will always be very noteworthy and worth the effort to finish
using the same high standards by others.

 

[[email protected]]

I sometimes tell the folks with suggestions: A patch is worth a thousand suggestions.

Or you may be doomed to repeatedly failing to get it right, because you
failed to listen to anothers hard learned experiences, in the form of a
helpful suggestion.

 

[Ales Hvezda]

Hi,

I'm also doing open source work in my free time, with very little
outside help, even though some three dozen people have asked to join
the project, and most have since been "fired" for failing to contribute
even at a discussion level (and there are a few more likely to be fired
for the same reason soon). Potentially helpful developers are certain

Wow. Let me get this straight, you "fire" volunteer
contributers and/or developers who want to help out on your OSS
project? An interesting management approach. The gEDA project
(especially myself) really values anybody who contributes patches /
code / documentation / suggestions etc... Even if I don't accept
something, I still value the contribution. I would never consider
"firing" a volunteer who spends their valuable free time helping the
project out.


[snip]

The GTK version of PCB has been "useless" for a year, and still is
today, because it generates 10-80 second delays with the mouse locked
up refreshing a drawing of a modest sized board. The older Xaw and the
current Lesstiff based version don't have that problem .... so the GTK
version pretty much is for toy designs only. Much of this delay is
memory thrashing.

Could you post some hard data on how you came to these
conclusions? I'm sure the PCB developers (myself as well) would love
to see your data or experimental results. Thanks.


[snip]

I believe in do it once right. The more energy that you put into doing
it in a way that can not be used to do it right, is actually wasted in
the long term and of very little real value in that respect. If you
decide to limit your portion of gEDA to toy sized projects, someone
else someday will have the vision to replace your work completely, and
do it right. You create your own legacy with open source.

I have a very different reason for working on free software.
I don't write free software to "create a legacy" for myself. I write
free software to solve real world problems and maybe somebody else will
find it useful. I make a significant effort to keep my ego out of the
process as much as possible. I find this approach works best and over
the years there have been many valuable contributions to the gEDA
project.

-Ales


PS. If somebody has the "vision" to replace gEDA completely with
something way way way better, all the power to them! Maybe
they can leverage something from the existing code base and/or
learn from my many missteps. In the meantime, work on gEDA
continues...

 

[DJ Delorie]

Could you post some hard data on how you came to these
conclusions? I'm sure the PCB developers (myself as well) would love
to see your data or experimental results. Thanks.

I have a not-for-distribution sample board which demonstrates the 10
second pause he's referring to. So far, it looks like a "catch up
with mouse events" scenario. I've also experienced the slow pre-hid
Gtk that some people complain about.

 

[[email protected]]

Wow. Let me get this straight, you "fire" volunteer
contributers and/or developers who want to help out on your OSS
project? An interesting management approach. The gEDA project
(especially myself) really values anybody who contributes patches /
code / documentation / suggestions etc... Even if I don't accept
something, I still value the contribution. I would never consider
"firing" a volunteer who spends their valuable free time helping the
project out.

Anyone "who spends their valuable free time helping the project out"
stays. Anyone who doesn't have the time to write even a half of a page
of code in several months or contribute to discussion, clearly isn't
developing anything are they? It's a team effort ... those that fail
the team by failing to produce ANY THING AT ALL, aren't team members
are they?

I don't see your project with a long list of "developers" that have
never contributed to the project.

If some one asks to be listed and doesn't contribute at all, do you
allow them to keep their name on your developers list so they can puff
their resumes?

Frankly, some find themselves in over their heads and don't feel they
can contribute at a reasonable level, and I generally ask them to stay
and spend the time training them. At least those people have the
integrity to openly communicate, rather than those that don't answer
their email after the first week, or never deliver after making a
commitment to do their part.

Could you post some hard data on how you came to these
conclusions? I'm sure the PCB developers (myself as well) would love
to see your data or experimental results. Thanks.

First are you even aware of the problem? Bug report:
1217807 pcb-20050609 is WAY WAY slower

Second, are you aware of the dynamics of the failure mode? ....

I have a very different reason for working on free software.
I don't write free software to "create a legacy" for myself. I write
free software to solve real world problems and maybe somebody else will
find it useful. I make a significant effort to keep my ego out of the
process as much as possible. I find this approach works best and over
the years there have been many valuable contributions to the gEDA
project.

Obviously your ego is highly engaged to respond this way, as was
Stuarts, to jump in attacking suggestions on what PCB should be, and
never even mentioning gschem. Gert a grip fella, why in the hell are
you attacking me for making some constructive criticism, and responding
equally lively to Stuart's little pissy bit.

Ditto for you .... my comments are what PCB should be, I could care
less about the rest of the gEDA project for the most part.

PS. If somebody has the "vision" to replace gEDA completely with
something way way way better, all the power to them! Maybe
they can leverage something from the existing code base and/or
learn from my many missteps. In the meantime, work on gEDA
continues...

I thought this was a PCB discussion ....

 

[[email protected]]

I have a not-for-distribution sample board which demonstrates the 10
second pause he's referring to. So far, it looks like a "catch up
with mouse events" scenario. I've also experienced the slow pre-hid
Gtk that some people complain about.

That DJ is why I sent the list of constructive criticisms to you
personally, to keep the advocates from getting all bent out of shape
that someone would dare consider another view of the world.