Kicad vs gEDA

Wenn ich mich in einen Virenprogrammierer versetze, sehe ich keinen Vorteil darin, zufällig mitlaufende Software zu nutzen. Die gewünschte Funktionalität schreibe ich dann lieber selbst.

Das ist der Trick der Sysadmins um sich Arbeit vom Hals zu halten. Da sie nur für Office zuständig sind, drohen sie eben mit "neu aufsetzen

-geht ja schnell" und schon hat der Entwickler Angst, 3 Tage lang seine Spezialsoftware installieren zu müssen. ;-)

Ich hatte eine Stunde Fern-Debugging, wo die CAD Firma meinen Rechner fernbediente nachdem ich denen ein Problem per Web Meeting vormachte. Erst war es einer. Der holte dann den naechsten Experten hinzu. Dann einen dritten. Zwischendurch hoerte man Aussprueche wie "Das kann doch einfach nicht wahr sein". Inzwischen duerften aufgrund meiner Support-Anrufe intern mindestens vier harte Bugs an die Programmier-Crew gemeldet worden sein.

Interessant war z.B. als sich dann auch noch rausstellte dass die Save Funktion offenbar, ahem, nun ja, nicht so ganz funzt. Man solle bis auf weiteres unbedingt "Save as" benutzen, hiess es danach.

...

Ich bin (dort) nicht Entwickler und der PC ist "sauber", im Sinne von "nichts installiert, was die Gurus nicht freigegeben haben".

Falk

Am 23.04.2011 22:41, schrieb Raimund Nisius:

Um bei deinem Beispiel zu bleiben: Genau so ein Feature (Warnlampe bei Druckverlust des Reifens) gibt es, IMHO habe ich das beim Passat gesehen. Ein Feature, das eingebaut wurde, weil die Hersteller wissen, dass Reifen und Reifenhersteller nicht unfehlbar sind und trotz bester Wartung und Tests halt doch mal etwas passieren kann.

Dann ist es besser, wenn ich das rechtzeitig merke, statt dass mir auf der Autobahn mit 160 km/h der Reifen platzt (das ist *mir* schon mal passiert und es war *sehr* hässlich, drei Autos Totalschaden, nur leicht Verletzte).

Schon. Aber man bekommt halt die Software, für die man bezahlt. Und wenn du das Geld nicht hinlegen willst dafür, dass die Software so funktioniert, wie du das erwartest, dann ist es wenigstens gut, ein Sicherheits-Netz zu haben, dass dir die Infos liefert, die dem Entwickler ohne viel Aufwand ermöglichen, das zu reparieren.

Man muss sich von dem Gedanken verabschieden, dass Software zu funktionieren *hat* und sich damit anfreunden, dass Sofware *immer* Fehler beinhalten wird. Die Komplexität bei solchen Projekten ist unglaublich hoch, da arbeiten hunderte von Mitarbeitern und drüber sitzt meist eine Chef-Riege, die nach außen wild Features verspricht und das den Entwicklern mal eben so im Statusmeeting mitteilt ("ach, das muss noch ins nächste Release rein"). Da braucht man sich nicht wundern.

Naja gut, dann kann man aber auch nichts mehr machen. Wenn selbst ein Techniker die Info weglässt, ist Hopfen und Malz halt verloren. Ist mir aber auch schon passiert, im Bugtracker schlägt ein Bugreport auf, der nur eine Zeile beinhaltet: "Unter manchen (seltenen) Umständen kommt es beim Gerät zu einem Reset. Hänge ein Log ASAP an." Danach 4 Wochen Funkstille. Das war bestimmt auch nicht gelogen. Und da ist wahrscheinlich ein Bug drin, wahrscheinlich einer von mir. Und der ist da wahrscheinlich immernoch drin. Aber wenn ich ihn nicht finde und er nur so selten auftritt, dass ich ihn nicht reproduzieren kann, kann ichs nicht reparieren, selbst wenn ich wollte.

Deswegen haben ja moderne Programme so eine "ich-bin-abgestürzt-willst-du-den-Fehler-direkt-übers-Internet-wegschicken" Funktion, die eigentlich recht prima ist. Für den Anwender nur ein Klick, der Entwickler sieht sofort wo es am häufigsten knallt (weil er die Infos vieler User hat), kann also sogar priorisieren und dann reparieren (mit sinnvollen Fehlermeldungen).

Viele Grüße, Johannes

Was habe ich damals als Amiga-Nutzer über die DOSler gelacht...

-ras

Dann sind die Gurus nur Halbgötter.

Gut, aber sie haben vorher dafür gesorgt, daß kaum einer mehr mit einer Reifenpanne rechnet. Im Bereich der Bananensoftware dient die Warnlampe als Alibi. "Wir konnten ja nicht wissen, daß das passiert".

Bist du sicher, daß Du eine Warnlampe vor dem Platzen noch bemerkt hättest?

Das lasse ich für Auftragsarbeit gelten.

Man darf das nicht als Generalausrede verwenden.

Das Mittel dagegen ist weder MMU, noch " nach Hause telefonieren".

Vielleicht hat er den Fehler nicht mehr hinbekommen - auch gut, wenn es so selten ist. Nebenbei, sogar on topic: Auch die Hardware kann seltene Fehler auslösen. Da hilft Dir u.U. gar kein Softwaretool.

Mich hat sie jetzt wochenlang genervt. .net ist so freundlich, meine Software von MS debuggen lassen zu wollen. Dabei war es ein Hardwareproblem...

Nana! Reparieren würd ich eher als Fehlerbehebung verstehen.

Ich würde das übrigens als Unfähigkeit bezeichnen.

Nö, StandarT-Götter. So kann man bspw. keine ".exe" o.ä. aus dem Internet laden. Verpackt in einem passwortgeschütztem ZIP-Archiv geht das aber. Umbenennen in "Virus.exe.txt" funktioniert nicht per WEB, dafür per Email, wo Anhänge anhand des Dateinamens entfernt werden.

Der am wenigsten umständliche Weg ist aber immer noch der USB-Stick ;-)

Falk

Am Sun, 24 Apr 2011 12:21:37 +0200 schrieb Raimund Nisius:

Beim platzen vielleicht nicht, aber ich bin mal nachts über irgend was herumliegendes auf der Autobahn gefahren. Ein paar Kilometer später sprang das Lämpchen an (war beim Octavia nur per Software realisiert die die Umdrehungen der Räder auswertete), und noch bevor ich am Fahrverhalten etwas bemerkte konnte ich die Geschwindigkeit auf 80 reduzieren und an der nächsten Abfahrt den dann schon fast platten Reifen wechseln.

In stockfinsterer Nacht ist das übrigens auch eine interessante Erfahrung, am meisten war der Tastsinn am Erfolg beteiligt.

Lutz

Michael Welle schrieb:

Ich erinnere mich an den Mann noch recht gut. Allerdings hat er sich intensiv an diesem Flamewar um Detlef Bosau beteiligt, Beschwerden geschrieben, Betreibern von Newsservern rechtliche Schritte angedroht, und so weiter. Nachdem seine Artikel in Sachen Bosau dann wie Trophäen herumgereicht wurden, hat er sich offensichtlich aus dem Usenet ganz zurückgezogen, jedenfalls korreliert das zeitlich.

Einerseits bedauerlich. Bartels hat eine Menge auf dem Kasten und kann dir ex ärmelo mal eben so sämtliche digitale Filter mathematisch herleiten, und zwar so, daß du die Kniffe hinter diesen Entwürfen sofort verstehst.

Andererseits verständlich. Wenn du im Umgang mit Bartels den falschen Knopf drückst, beschwert er sich halt überall recht nachdrücklich. Der Mann wird sich den Umgang mit einer bestimmten Klientel einfach nicht leisten wollen. Hat er ansich auch überhaupt nicht nötig, bei all dem, was er macht und kann.

Schade eigentlich. Zumal die Software aus seinem Hause recht gut ist, und man natürlich wohl auch die eine oder andere Frage haben könnte, die jetzt nicht mehr beantwortet wird.

Holger

Am 24.04.2011 12:21, schrieb Raimund Nisius:

Die Chance ist ganz gut. IIRC sind die meisten Reifen"platzer" eigentlich schleichender Druckverlust, der dann als Platzer wahrgenommen wird, wenn die fast drucklos schlabbernde Karkasse irgendwo an der Karosserie anschlägt und mglw. zerfetzt wird.

Hanno

Am 24.04.2011 10:12, schrieb Johannes Bauer:

Ich hab letztens einen interessanten Vortrag zu dem Thema gehört. Der Fokus lag da eher auf Sicherheit, aber letztendlich sind es ja auch Programmierfehler, die ein Programm unsicher machen, insofern ist das Thema vergleichbar. Sich mit Fehlern abzufinden ist mittel- und langfristig gar keine gute Idee, weil die Programme immer komplexer werden und das schnell ein sicherheitstechnisch nicht mehr beherrschbarer Alptraum wird. Ist es ja eigentlich jetzt schon.

Laut meiner Erinnerung meinte der Vortragende, unsere Rechner- und Softwarearchitekturen sind so 40 Jahre alt und da hat sich in der Praxis wenig getan. In der Forschung gibt es jedoch einige interessante Entwicklungen, sowohl sichere Architekturen als auch verifizierte Betriebssysteme, und automatische Verifikation von Programmen. Problem dabei: Für die automatische Verifikation muß das Programm im Source vorliegen. Mit closed source Software ist das ganze nicht zu machen. Vielleicht ein echter Marktvorteil von OSS... (ok, das war jetzt meine Interpretation).

Zuerst dachte ich, das sei ziemliche Zukunftsmusik, aber bei den verifizierten Betriebssystemen, die als Fundament für ein solches System dienen müßten, ist man deutlich weiter, als ich geglaubt hätte.

(Ich bin kein Informatiker, sondern nur interessierter Laie, also bitte nicht zu doll hauen, wenn ich die Terminologie nicht ganz richtig auf die Reihe bekommen hab.)

Das hier ist der Vortrag:

und hier gibt es eine Aufzeichnung:

Hanno

Am 24.04.2011 14:33, schrieb Hanno Foest:

Sagen wir mal so: Es gibt bereits länger Betriebssystem-Ansätze (beziehungsweise Ansätze für Betriebssystem-Grundlagen), die deutlich weiter gehen, als das, was wir heute so auf dem Desktop sehen. Und da ist es egal, ob man in die Windows-, Linux- oder BSD-Ecke schaut.

Wenn ich meinen Thunderbird heute hier aufmache und diese Nachricht tippe, kann der Newsreader problemlos beispielsweise meine Urlaubsbilder öffnen und übers Netz heraussenden. Oder meinen GPG-Private-Key. Wieso soll der das können? Da gibts keinen guten Grund.

Capability-basierte Betriebssysteme (z.B. HYDRA, das ist von 1971!) haben solche Probleme nicht. Da ist sehr feingranular (sogar bei jedem Funktionsaufruf!) bestimmbar, wer was darf und was verboten ist. Hat sich nur nie durchgesetzt.

Insofern müssen wir zunächst momentan damit leben, was wir haben, und das so gut es geht nutzen. Ein sicheres Betriebssystem wird aber nie einen dummen oder faulen Programmierer daran hindern können, schlechten Code zu schreiben. Die Einfallsvektoren verschieben sich nur.

Viele Grüße, Johannes

Lief denn Orcad-SDT und PSpice auf dem Amiga?

Das ist definitiv nicht der Fall. Ich erlebe es gerade mit Orcad, welches gegenueber Eagle suendhaft teuer ist. Nun, Orcad ist bei mir alle paar Tage so fest in den Sand gefahren dass eine Neuinstallation notwendig wird und sich der Support die Haare rauft. Wobei ich sagen muss dass der Support recht gut ist, allerdings die haben wahrscheinlich mehr Arbeitszeit in meinen Fall gesteckt als sie an meiner Lizenz verdient haben. Gestern war es mal wieder soweit, es laedt noch DSN Files, aber nach dem letzten harten Vollabsturz haengt es sich beim Laden von Projekten so auf dass CTRL-ALT-DEL noetig ist. Ein dreifach Hoch auf diese Tastenkombination ;-)

Eagle und LTSpice laufen seit Jahren ohne Support und ohne Absturz. Es duerfte seine Gruende haben warum Cadsoft den Support fuer Eagle ohne kostenpflichtigen Wartungsvertrag bietet und andere nicht. Soviel von meiner Seite zu diesem Thema :-)

Bei Autos ist es aehnlich. Die teuren sind nicht immer die besten. Ergo sieht man bei uns in der Garage auch keine Nobelkarosssen.

Natuerlich ist das zu machen. Bzw. waere es zu machen, egal ob Open oder Closed Source. Die meiste Software hat in der Hauptsache diesen Fehler: Mangelhafte Dokumentation. Viele Programmierer meinen, dass ein paar Kommentare oder ein automatisches Doku-Extrahierprogramm ausreichend seien. Das ist jedoch nicht der Fall. Darueberhinaus gibt es in vielen SW-Teams keine oder viel zu selten Design Reviews.

Man koennte in dem Metier eine Menge lernen wenn man mal ueber den Tellerrand guckt, wie die HW-Leute in sicherheitskritischen Bereichen sowas machen. Medizintechnik, Flugzeugbau und so weiter.

Der Fairness halber muss man sagen dass es SW-Teams gibt die ihre Sache sehr gut machen. Neben Firmen wie QNX und Cadsoft auch kleine Teams oder "Einzelkaempfer", wie Mike Engelhardt bei Linear Technology.

Am 24.04.2011 16:57, schrieb Joerg:

Wnn ich Andreas Bogk richtig verstanden habe, dann braucht man den Source, damit du das Programm nach deinen eigenen Kriterien selber verifizieren kannst, beispielsweise "es werden nie Daten von meiner Platte nach draußen gesendet, außer ich mache vorher x, y. und z". Ohne Source dürfte das schwierig werden, oder zumindest noch aufwendiger als so schon, mit vorheriger Dekompilierung etc.

Hanno

Am 24.04.2011 15:05, schrieb Johannes Bauer:

Das liegt einfach daran, daß der Verwaltungsaufwand für sowas manuell nicht zu leisten ist: Je feingranularer, desto mehr Aufwand.

Hanno

Hallo Johannes.

Ich beobachte h=E4ufig als Beifahrer, das Leute, die so schnell fahren, sich sehr konzentrieren m=FCssen. Das f=FChrt nach einiger Zeit zu einer Art Trance, in der sie einen Tunnelblick und eine Fixierung auf den Strassenverlauf und den Verkehr vor ihnen bekommen.....und bei unerwarteten Ereignissen gar nicht oder sehr langsam reagieren. Eine rote Warnlampe w=FCrden die nicht bemerken. Sinnvoller w=E4re eine Hupe. Noch sinnvoller w=E4re nicht so schnell zu fahren, da=DF ein Reifenplatzer kritisch wird.

Mit freundlichem Gru=DF: Bernd Wiebus alias dl1eic