Kicad vs gEDA

Abstuerze hatte ich hier mit Ubuntu hingekriegt, aber es ist schon recht robust sonst. Doch das nutzt mir nichts, denn ich muss die Software benutzen die meine Kunden bevorzugen. Diese gibt es nur selten in einer Linux Version.

Ok, das musste ich selbst bei Orcad wo sie mit zigtausenden Lib-Teilen werben. Ist normal. Bei fast jedem mir neuen CAD ziehe ich mir zuerst rein wie der Library Editor funktioniert. Bei gEDA koennte es sich lohnen in verschiedenen Repositories nachzusehen. Leute wie Kai-Martin oder D.J.Delorie haben etliches an Library Parts geschaffen.

Sehe ich anders. Manchen Firmen vertraue ich dass sie intern adaequate Massnahmen zur Qualitaetssicherung haben, anderen dagegen nicht. Wiederum andere sind behoerdlich stark kontrolliert und muessen sauber arbeiten. Daher sage ich oft dass sich Leute an Medizintechnik oder Flugzeugbau ein Beispiel nehmen koennen. Dort muss eine lueckenlose Design History vorliegen oder es gibt eines Tages gepfefferten Zoff.

Ist wie bei Autos, heutzutage muessen die einen Motor-Computer haben, sonst kommen sie nicht durch die Abgastests. Nun gibt es Firmen die ihre Sache gut machen und welche die das nicht packen. Ich kaufe meine Autos nur von ersteren. Kein Hersteller wird den Source Code fuer den Prozessor da drin offenlegen, allerhoechstens nach richterlicher Anordnung wenn was passiert ist.

Habe ich nicht benötigt. Aber Multitasking konnte ich damit schon lang...

Und wenn DOS unbedingt mal sein mußte, dann halt in der Emulation.

-ras

Ich rätsle, was Du mit dem Zeug machst. Dein System muß echt Schrott sein...bei uns in der Firma tut das, ebenso Altium, WSCAD, Solid Works.

-ras

Altium lief hier auch sauber, ebenfalls Eagle, LTSpice, DesignCad-3D, SCADA Software, diverse Programmierumgebungen, Gerber Viewer, Mathcad, und so weiter. Es gibt nur zwei Programme die so schlimm und oft abstuerzen: Orcad und Acrobat. Letzterer flog raus, Problem erledigt. Bei Orcad kann das aufgrund eines groesseren Auftrags erst naechsten Monat geschehen, dann aber achtkantig.

Die (uebrigens sehr netten) Support-Leute haben sich das System per Ferndiagnose eine ganze Stunde angesehen und sagten es sei alles astrein, wesentlich ordentlicher als was sie sonst so vorfaenden. Peu a peu kam dann spaeter raus "Oh ja, das muss wohl ein Bug sein".

Ok, die Simulationen gehen ins Eingemachte, aber dafuer ist diese teure Software ja da. Mit LTSpice habe ich schon aehnliche Dinge angestellt und das hat dabei nie Kruke gemacht. Ist nach meinem Eindruck auch eine Ecke flotter.

Manchmal fragen mich Start-up Kunden wenn sie anfangen Erfolg zu haben: Was nimmt man denn so als CAD fuer eine groessere Truppe? Die Antwort faellt mir inzwischen echt schwer. Derzeit mag ich nur Eagle leiden und die haben ja noch keine Hierarchie (soll in V6 kommen). Wenn das Problem weg ist fiele mir die Antwort leicht, auch wenn Eagle keine direkte SPICE-Anbindung hat.

In der Praxis stürzen Programme aber nun mal beim Anwender ab. Dafür sorgt zum einen schon Murphy (schließlich gibt es beim Kunden ja viel mehr Daten zu zerstören als auf den QA-Systemen) zum anderen kann man auch mit noch so viel Testen nicht die gleiche Abdeckung hinbekommen wie eine große Anwenderschar.

Deswegen ist es essentiell, daß eine Software im Falle eines Crashs eine aussagekräftige Fehlermeldung produziert. Im Idealfall ist das ein Stackdump. Und weil Anwender Fehlermeldungen sowie immer nur wegklicken, gehört diese Info in ein Logfile. Und man akzeptiert keinen Bugreport und kein Serviceticket ohne das Logfile.

XL

Am 24.04.2011 20:50, schrieb Joerg:

Kannst du halten wie ein Dachdecker - mir persönlich wäre die Option, die zu benutzende Soft zu verifizieren, deutlich sympathischer als bloßes Vertrauen. Egal wie toll die Typen sind, von denen die Soft kommt, Fehler kann jeder machen.

Hanno

Nu ja, wenn Du im Alleingang durch 50000 Software Routinen pfluegen moechtest koennte es natuerlich sein dass Du in 20-30 Jahren mit der Verifizierung durch bist :-)

Aber wenn man einen Bug nicht reproduzieren kann, dann kann man ihn auch nicht reparieren. Deswegen braucht man exakte Rückmeldungen.

Bei Reifen ist das Problem nicht so ausgeprägt. Man kann die Einsatz- bedingungen hinreichend genau reproduzieren, um Fehler schon vor der Auslieferung zu finden. Und trotzdem passieren noch Pannen wie bei Firestone(?) wo mal eine ganze Charge F1-Reifen kaputt ausgeliefert wurde.

XL

Nicht nur bei Betriebssystemen. Im Prinzip könnte man jede Software beweisbar sicher machen. In manchen Bereichen wird das auch gemacht. Steuerungssoftware für Kernkraft-Anlagen etwa. Oder das, was an Software zum Mars fliegt.

Aber das ist teuer. Richtig teuer. Und wird exponentiell teurer mit den Features, die in der Software stecken. Die Apollo-Missionen hatten ca. einen C64 an Bord. Ein Word verbrät ein mehrfaches dieser Rechen- leistung alleine dafür, Menüs pixelweise rauszufahren. Angesichts der Komplexität der Software in einem Desktop-System ist es ein kleines Wunder, daß das überhaupt einen Tag lang durchläuft.

Der andere Ansatz ist rigoroses Testen, am besten in Verbindung mit viel Disziplin beim Programmieren selber. Nach einer Weile kann da sehr stabile Software bei rauskommen. Kanonisches Beispiel ist TeX, wo der Autor gefundene Bugs schließlich mit Schecks honoriert hat [1] (jedes Jahr eine Verdopplung der Summe) ohne dabei arm zu werden. Allerdings ist aktuelle Software zu kurzlebig, um über die Kinder- krankheiten hinaus noch so lange reifen zu können.

XL

Du meinst da wo Stuxnet laeuft? ;)

'Beweisbar sicher' ist eine sehr harte Anforderung... Alles was über triviale Software rausgeht oder aus einem Compiler fällt und auf aktuell verkaufter Hardware läuft fällt da eher nicht drunter.

Fängt schon bei der CPU an. Bei welcher aktuell erhältlichen CPU ist denn die Implementierung komplett getestet? Welcher Compiler ist komplett verifiziert?

Gerrit

Am 24.04.2011 23:30, schrieb Joerg:

Es ging um automatische Verifikation.

Hanno

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Genau das ist es woran es oft mangelt.

Es gibt Teams die das ganz ohne solche Schecks hinkriegen. Ein Beispiel ist die Firma IMSI. Ich bin nicht gerade als besonders geduldiger PC-Nutzer bekannt und einige benutzen mich als SW-Tester. Wenn etwas auch nur ein wenig wackelt kriege ich das meist zum Absturz. DesignCAD von IMSI habe ich nie zum Absturz gebracht, und das ist immerhin ein 3D CAD Programm.

Weiss eigentlich jemand was heutzutage von Zuken zu halten ist?

Das funktioniert nicht weil sie die Schnittstelle zur realen Welt (Benutzer, Umwelt) nicht gescheit simulieren kann, und wird ergo von vielen Zulassungsstellen auch nicht akzeptiert. Die wollen die Design History und Testberichte sehen.

Ist bei Hardware aehnlich. Es gibt Leute die meinen man koenne alles brav nach Normen entwickeln und in den Markt geben. Dann kommt die harte Realitaet und es scheppert rechts und links.

Tja, und selbst da wäre ich mir nicht sicher, dass die keine Sicherheitslücken hat.

In KKWs oder Marsflügen geht es nur darum, dass die Software unter normalen Bedinungen das tut, was sie soll. Gezielten Angriffen muss sie nicht standhalten - ganz im Gegensatz zu normalen PCs.

Guck' dir mal an, welches wirtschaftliche Interesse hinter Spielekonsolen und DRM-Systemen steht. Microsoft, Sony und Konsorten treiben einen riesen-Aufwand, um ihre Systeme dicht zu kriegen.

Die Bootloader- und Hypervisor-Teile sind teilweise nur wenige hundert Byte lang und garantiert mit größter sorgfalt entwickelt worden.

Trotzdem wurden bisher alle Systeme gehackt. Siehe auch:

Hallo Thomas.

Mal eine Spekulation? Sie sollten alle von Hersteller her eine versteckte Backdoor haben....und diese ist dann der Schwachpunkt. Der Fehler k=F6nnte also gewollt sein, allerdings sollte er auch nicht gefunden werden. ;-)

Mit freundlichem Gru=DF: Bernd Wiebus alias dl1eic

Am 25.04.2011 00:43, schrieb Joerg:

Das gibt es überhaupt noch nicht in der vorgeschlagenen Form. Lies doch einfach mal meine Artikel, bzw. guck den verlinkten Vortrag. Wenn du das nicht magst - was ich voll verstehen kann - dann gibt es allerdings auch keine Pflicht darüber zu posten.

Wenn du auf verifizierter Hardware ein verifiziertes OS hast und darauf die Werkzeuge für die automatisch Verifikation von zu benutzender Soft nach bestimmten Regeln, dann kanns du eine Menge Fehler absolut (das ist quasi Mathematik!) ausschließen. z.B. daß Daten, die von deiner Platte gelesen werden, nach außen gelangen, sich das Prog in einer Endlosschleife weghängt etc.

Natürlich kannst du nicht verhindern, daß das Programm B tut, wo es eigentlich A tun sollte, weil der Programmierer zu tief ins Glas geguckt hat und B geschrieben hat, wo er eigentlich hätte A schreiben wollen - solange B nach den Verifikationsregeln legal ist. DWIM gibts halt nicht und das entbindet auch nicht von Sorgfalt beim Programmieren, aber eine riesige Klasse an Bugs und Sicherheitsproblemen ausschließen zu können hätte schon was.

Hanno

Gucken ging nicht, aber hoeren. Nach gut der Haelfte riss es allerdings ab. Wuerde mir wuenschen dass alle so fluessig Englisch koennen :-)

BTW, der erste Link mit der Ankuendigung produzierte hier nur eine Latte an Sicherheitswarnungen, diese Version geht:

Klar, aber die Verifikation verlangt nicht unbedingt Open Source. Das war es was ich sagen wollte. Man sieht das am Betriebssystem QNX, was IME das robusteste ist was ich je kennenlernte. Es ist nicht Open Source. Natuerlich bin auch ich kein SW-Profi, sondern auf der Anwenderseite. Die Anwender sind es jedoch die sowas oft am besten beurteilen koennen.

Wollte man einen Teil der Verifizierung in Verbindung mit einer Anwendung bei Closed Source machen so muesste das z.B. der Hersteller des OS tun. Manchmal ist es wie in einem naechsten Monat anliegenden Fall (Hard- plus Software), wo es inklusive mir drei Parteien gibt die das nur zusammen koennen. Dazu wird ruckzuck ein gemeinsames NDA aufgesetzt und feddich, kann jetzt jederzeit losgehen.

Genau das ist der Knackpunkt. Nur saubere Dokumentation was mit A und B gemeint ist, plus Design Review unter Beteiligung von Leuten ausserhalb des Team, plus intensive Tests helfen wirklich was.

Sage ich ja, was nutzt DWIM wenn die automatische Verifizierung nicht rausbekommt "but what you meant was wrong". Einige der Bugs die ich in den letzten Wochen in einem CAD Programm mit ueber 20 Jahren (!) "Reifezeit" fand gehoerten eindeutig zu der Kategorie. Das ist weitgehend vermeidbar. Wenn man nur will, die passenden Manager einstellt und das Budget dafuer bereitstellt.

wir hatten ja nix damals. Nichtmal Schnee im Winter, um ohne Schuhe zur der Schule zu gehen, die wir nicht hatten.

VG ;) hmw