[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: [RFC 1/6] Non-Turing-complete configuration files.
Hi All,
[snip]
> 1. Non-Turing-complete configuration files.
> 2. Plugin system.
> 3. Embedding system revamp.
> 4. "New window" functionality.
> 5. Use of X server clipboard.
> 6. Generation of log files.
I am glad some experienced gEDA/EDA/user/EE-designers, such
as John Doty, r, Árpád Magosányi and others have stated some
of their opinions, most of which reflects mine too. So I
would not repeat here.
In general, I am interested in the outcome and
the consequences if the above were to be implemented.
As people say, "the devils are in the details".
Please note "Outcome and Consequences":
a) What we can do with current gEDA that we won't be
able to do if the above get implemented ? Or what
features would get elimiated ? What obstacles they may
have put for the future of gEDA? Are the features neccessary
or it is just another way to do things which we can already
do easily and with more flexibilities?
b) What do we gain in flexibilities from doing the above.
c) From first glance. by item (n):
(5) As a GTK based program, a "GTK lib based" clipboard
for gEDA is natural to be implemented. GTK drag and
drop can be implemented too.
(6) Can be made configurable: yes/no, where. Simple
(1-4) If it takes away gEDA flexibilities, then
definitely NO, thanks.
d) There=2
0are many ways to design gEDA. IMHO, we should always
strive for generic ways and solutions for the core if possible.
Application specific backends can be customized to their
unique requirements by interface thru core API. Not to forget
rapid adaptation of application specific changes should
be a criteria, since backends requirments change often.
e) If I am not mistaken, gEDA is not only for PCB flows.
Just because gEDA can be used for PCB flows, and majority
of the gEDA users here are PCB users, gEDA should
not be designed narrowly to support PCB type of features
only. We are smart enough to design it genericly, with
powerful scripting capabilities to accomodate app specific
functions. So far it has worked quite well, though a
lot more need to be done.
A side note:
Scritping is here to stay for all modern computer. When
Java was first used en masse, people blamed Java for security
problems, now when everyone knows the benefits of it and know
how to deal with Java security, people accepts it as a way of
life. C#, J#, Python, and others spring into full action.
In fact EDA programs were one of the first to use scripts
en masse, way before Java was invented.
If you want to know more about "Secure Programming for Linux
and Unix", please check out
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html
Best Regards,
Paul Tan
0A
-----Original Message-----
From: Árpád Magosányi <magwas@xxxxxxxxx>
To: gEDA user mailing list <geda-user@xxxxxxxxxxxxxx>
Sent: Sat, 17 Jan 2009 8:53 am
Subject: Re: gEDA-user: [RFC 1/6] Non-Turing-complete configuration
files.
Hi!
Sorry if I will be too long, but this is an important question.
Short version: Don't Do That!
Long version:
Once upon a time we did a firewall software development project, which
had horribly failed. When we analyzed the causes, we identified
numerous management problems, and some technical ones. The most
important technical problem was that we have invested disproportional
resources into the configuration parser.
The project ended, the development team split. And both teams decided
that they want to make living from firewall software. Our team
restarted the whole project from the ground up. We have decided that
python shall be the configuration language (I strongly lobbied for
scheme that time, but nowadays I am very grateful that the final
decision was python). The software uses python not just for
configuration, but the high-level policy decisions and also the glue
uses it. And the beast is still fast as hell.
Our team is now called Balabit Inc, and we have nearly 70 employees,
and doubling in sales every year, the overwhelming majority of it
being from Zorp, the most advanced firewall software of the world.
The other team continued on the original codebase. They are still
exists I think, but=2
0nowadays they are actually invisible on the
market.
I think the moral of the story is straightforward: mixing a scripting
language in is not just saves precious development efforts, but also
opens numerous possibilities to get off cheap with in various
unforeseen areas. And here I mean not just development time: the
overviewable.
However it might be worthwile to think about changing to a more widely
used and more expressive language like python, ruby, or ada.
If you have security concerns, sandboxing the implementation can be a
solution, as others have already mentioned it.
2009/1/16 Peter TB Brett <peter@xxxxxxxxxxxxx>:
>
> Currently, the gEDA configuration files are executed by a Scheme
> interpreter. This has a number of flaws:
>
> 1. An error in a configuration file will cause it not to be fully
> interpreted. This can potentially leave gEDA applications in an
> unusable state or even cause it not to start at all. Furthermore,
> this can be confusing to a new user, who might not be familiar with
> Scheme or the quirks of gEDA configuration and thus more at risk of
> making mistakes configuring gEDA.
>
> 2. Per-project configuration files may legitimately be required. For
> instance, they may be used to customize libraries of symbols or
> hierarchical schematics. However, they currently pose a security
risk
> in that downloading and opening a set of schematics from the
Internet0D
> can easily result in arbitrary code being executed.
>
> My proposal is to use a Scheme-like syntax for the configuration
files,
> but to parse rather than execute them. Naturally, it would be
necessary
> to design the system carefully to ensure that all configuration
> parameters can be specified in the reduced syntax.
>
> Peter
>
> --
> Peter Brett
>
> Electronic Systems Engineer
> Integral Informatics Ltd
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user