X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0t32iP4Rt/1i0TMK74/dJeofu7P60DtKgFfUOgrMdd0=; b=LQe3rZdjo9yN2vRCc7kffvulIIwN/rRAWPrZ90AoyycsSNZLgk6Kcx4QaZCmPxyC/L 1SJlldBVKAvL/6sNBFzKrZXNUy9JgL8D2DpyOO0z4Lu0oVqliThJRp/r2Zrgtqd0RDPB SOxN6Gtfgex/0iaInO5iJq/VjsPKTqSGfBbDkFSkcsYQbW+U+1L2JMv8KK9a3KXBxHG8 mQYhpjP6oE+4CVoGvKju7SDwwxJJsssAn8GSSRwaDFXpyZ1xO39C+cCmlKN5M8qzJvgy 2u2oUcqhPYwmRx8PcBZiG0NQIw1ZFjJUCd/LjQjx+244PvOPcdn2F+vdyy194ohGxDSF yEZw== MIME-Version: 1.0 X-Received: by 10.152.27.197 with SMTP id v5mr4746073lag.64.1436285116334; Tue, 07 Jul 2015 09:05:16 -0700 (PDT) In-Reply-To: References: <1435510363 DOT 682 DOT 26 DOT camel AT ssalewski DOT de> <20150703030409 DOT 32398 DOT qmail AT stuge DOT se> <1436006726 DOT 677 DOT 13 DOT camel AT ssalewski DOT de> <20150706200609 DOT GD24178 AT localhost DOT localdomain> <20150707060409 DOT GB14357 AT localhost DOT localdomain> Date: Tue, 7 Jul 2015 12:05:16 -0400 Message-ID: Subject: Re: [geda-user] gEDA/gschem still alive? From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, Jul 7, 2015 at 11:56 AM, wrote: > > > On Tue, 7 Jul 2015, Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via > geda-user AT delorie DOT com] wrote: > >> >> Rather than concentrating on what we don't like, I wonder if anyone can >> point to a FOSS Eda tool out there that you do like. What did they do >> right > > > > > My favorite EDA tool is gEDA and PCB. Among with many others, for these > reasons: We are all being critical because we are trying to find the reason development/interest has slowed. >> >> >> have changed a lot since the 1980's and some things that we did back then >> no longer work. One example is search paths. If you look in the default > > > I love that things are simple 80's stuff. For me search paths are easy to > understand and maintain. They don't always work out of the box, but it's > easy to fix them. > >> >> gEDA currently defines a dot_sch schematic file and a dot_sym symbol file >> as >> our interchange formats. These are read into gschem and stored in some >> internal data structure that gschem manipulates before it is written out >> in >> a save operation. Why not use a FOSS data base instead of internal memory? > > > And this is another major reason: I love the idea that there is no database > involved and things are just files on my system, for the same above reason. > Maybe this wouldn't scale well if I wanted to have 10 million symbols - but > really, I am not even sure about that. Anyway in the scale I work, I'd have > 100x more problems with a database. Databases can be trouble when it comes to some of the workflows people use. >> If PCB also used the same database then cross probing and back annotation >> become easier. > > > This is a good point too: I love how gschem and PCB are _not_ tied together. > I indeed miss back annotation, but I do not miss any shared database thing > between gschem and PCB. The Unix mentality these are all independent tools that we choose to combined this way. Most people have avoided binding them via a database because they want to keep things separate. > You can call simplicity and separate tools 80's technology, I'm fine with > that. I also realize that if you want to target the most common enginner of > the 21st century he will miss databases and more integration. But is it > really worth rolling out an N+1th EDA of the same kind? I vote for keeping > these unique featres of gschem as they are. > > Regards, > > Igor2 -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/