oder Bascom? oder Java? http://www.heise.de/newsticker/meldung/Kritische-Luecke-in-etlichen-Routern-2655271.html
:
Verschoben durch Moderator
Jon schrieb: > oder Bascom? oder Java? Nein, aber nicht weil diese Sprachen so viel besser sind, als C, sondern weil man damit keine Treiber schreibt.
ach schreibt man nicht?? Das ist mir neu! Abgesehen von Maustreibern...gibt es noch grundlegendere Treiber in Pascal...und nur weil jemand das heute nicht macht, bedeutet es ja nicht das es in Pascal nicht geht! http://www.amazon.de/Systemnahe-Programmierung-Borland-Pascal-vollst%C3%A4ndiger/dp/3322872394
hierzu sei noch gesagt das Buch bezieht sich auf eine steinalte Version von Pascal..in freepascal spräche aber ganz sicher nichts dagegen
In vielen Sprachen - aber eben nicht in C - kann bei Array-Zugriffen Code eingebaut werden, der Indices auf zulässigen Wertebereich überprüft. Das spielt bei Thema "buffer overflow" eine nicht unerhebliche Rolle.
Kim Schmidt schrieb: > Das ist mir neu! Hast du denn dann auch zumindest ein Beispiel für ein Gerät, dessen Betriebssystem in Pascal geschrieben wäre? Im Gegensatz zu einem PC ist ja so ein Gerät ein eher in sich abgeschlossenes System, bei dem es nun nicht auf umfängliche Kompatibilität zu existierenden Anwendungsprogrammen ankommt, die der Nutzer haben möchte. Insofern sollte es dort sehr viel leichter sein, alternative Betriebssyteme zu benutzen als auf einem PC.
Eigentlich ist die Krux nicht in der Programmiersprache zu suchen, sondern in dem hier benutzten Prinzip, den Router als Server zu missbrauchen. Schon seit Urgedenken des Internets gilt eine Grundsatzregel: Ein Router ist kein Server. Dienste haben auf einem Router nichts zu suchen. Leider halten sich die Hersteller von Routern für den Heimgebrauch daran immer weniger - einfach um einen Mehrwert zu erzeugen. So werden dann Drucker-, NAS- und andere Schnickschnack-Server in den Router integriert, obwohl das eigentlich ein No-Go ist. Otto Normaluser möchte sich aber neben seinen Router keinen weiteren Netzwerkserver stellen - warum eine weitere Kiste? P.S. Als Gründer des fli4l-Router-Projekts kann ich von dem Thema ein Lied singen...
:
Bearbeitet durch Moderator
Frank M. schrieb: > Ein Router ist kein Server. Naja, einen DHCP-Server habe ich auf dem Router auch noch mit drauf. Einfach, weil bei ihm die verschiedenen Netze zentral auflaufen. Aber ansonsten volle Zustimmung.
>Hast du denn dann auch zumindest ein Beispiel für ein Gerät, dessen >Betriebssystem in Pascal geschrieben wäre? die Frage war ja, was wäre wenn.. also WENN ein in pascal geschriebenes (U)nix drauf laufen WÜRDE..
Robert L. schrieb: > die Frage war ja, was wäre wenn.. Die hilft uns nur leider in der Praxis nicht.
Frank M. schrieb: > Ein Router ist kein Server. > Dienste haben auf einem Router nichts zu suchen. Mal abgesehen von DHCP: Auf meiner Fritz!Box habe ich auch NAS- und andere Schnickschnack-Server. Da ich damit bisher keine Probleme hatte und falls ich als Mitleser mal fragen darf: Warum dürfen Server und Router nicht zusammen in ein Gerät? Einigkeit scheint in diesem Punkt ja zu herrschen.
Robert L. schrieb: > die Frage war ja, was wäre wenn.. > also WENN ein in pascal geschriebenes (U)nix drauf laufen WÜRDE.. Zugegebnermaßen schützt Pascal den Programmierer eher gegen Buffer-Overflows als C. Aber man sollte immer bedenken: Man kann sich mit jeder Programmiersprache ins Knie schießen... da kommts immer auf die eigene Blödheit an. Außerdem kann so eine automatische "Sicherheit" zu Leichtsinn verführen: "Ich bin ja angegurtet, also kann mir nichts mehr passieren" .... sagte derjenige, der mit 200 gegen die Wand fuhr... Natürlich könnte man auch in C eine Lib schreiben, die Array-Zugriffe (wie z.B. Buffer für Strings) komplett kapselt und jeden Zugriff prüft. Das geht dann halt auf Kosten der Geschwindigkeit und wird sich dann eher mit der Geschwindigkeit eines Pascal-Programms messen lassen. Der Programmierer müsste sich dann extremst disziplinieren: Die Verwendung von Pointern wäre zwar gestattet, jedoch nicht der Zugriff auf den Speicher über den Pointer. Array-Zugriffe müssten ebenso über die Lib abgewickelt werden. Also: Theoretisch bekäme man das schon so "sicher" wie in Pascal. Aber zu Kosten von Freiheit, die ein C-Programmierer eher nicht aufgeben möchte. Denn sonst wäre er eher ein Pascal-Programmierer geworden ;-)
:
Bearbeitet durch Moderator
Torsten C. schrieb: > Warum dürfen Server und Router nicht zusammen in ein Gerät? Aus Sicherheitsgründen, damit ein Bug im Router nicht so leicht durch andere ausnutzbar wird. Je mehr Dienste es gibt, um so angreifbarer ist ein System. Ein Router / Firewall sollte daher möglichst wenig Angriffspunkte bieten.
die Frage war ja, was wäre wenn.. Die hilft uns nur leider in der Praxis nicht. !?!?!?! Was ist denn das für Ein Argument? Klar ist was wäre wenn wichtig..das ist ja die Frage von ganz oben!?! Es spricht nichs dagegen ein System in PAscal zu schreiben, also bleit die frage..wäre es damit auch passiert!? Denn dieses Problem ist ja nun ein Fortlaufenden bei C, in C++ soll das ja angeblich besser geworden sein? Ich frage mich nur deshalb, weil gerde in sicherheitsrelevanten bereichen Pascal ähnliche Sprachen verwendet werden, wieso nicht bei Routern? Gibt es keine brauchbaren Programmierer mehr die diese Sprachen beherschen? Bequemlichkeit? Aber ganz sicher sind es kosten...den ein programmeirer der diese sprachen beherscht ist nunmal teurer als ein C Mensch die es wie Sand am Meer gibt.
Torsten C. schrieb: > Da ich damit bisher keine Probleme hatte und falls ich als Mitleser mal > fragen darf: Warum dürfen Server und Router nicht zusammen in ein Gerät? > Einigkeit scheint in diesem Punkt ja zu herrschen. Ein Router hat genau eine Aufgabe, nämlich Netze voneinander zu trennen und den Datenverkehr zwischen den Netzen zu regeln. Dabei muss er oft gewissen Sicherheitskonzepten genügen. Jedenfalls sollte ein Netzwerkadministrator solche Sicherheitskonzepte für die Szenarien, für die er verantwortlich ist, entwickeln. Das Sicherheitskonzept wird dann umgesetzt durch Anwendung von Topographie, Routing- und Firewall-Regeln. Damit wird der Datenverkehr zwischen den Netzen auf das beschränkt, was tatsächlich notwendig ist. Die Wirklichkeit sieht bei den Heimroutern aber ganz anders aus. Hier gibt es eigentlich meist nur nur ein Werkzeug zur Umsetzung eines sehr allgemein gehaltenen Sicherheitskonzeptes (nämlich das des Herstellers): Das nennt sich IP-Masquerading. Aber genau das ist kein Ersatz für eine Firewall. Zu den Schwächen von IP-Masquerading und das falsche Wiegen in Sicherheit gibt es genügend Stoff im Internet. Darauf will ich gar nicht eingeghen. Andere Mittel wie Portfilter sind dem Otto-Normal-User als Firewall-Werkzeug viel zu kompliziert. Was macht er also? Er schaltet die Firewall ab ("weil, das lief vorher nicht richtig") oder aktiviert sie erst gar nicht ("weil, wozu brauche ich die, versteh ich eh nicht?") oder konfiguriert sie entweder komplett kaputt ("Hilfe, nix geht mehr") oder leitet versehentlich sämtliche Zugriffe von außen auf seinen Hauptrechner ("das Spiel XYZ läuft nur, wenn ich meinen Rechner als 'exponierten Server' im Router freigebe"). Also: Ein Heimrouter muss so allgemein vom Hersteller vorkonfiguriert sein, dass er von Otto-Normal-User in Betrieb genommen werden kann. Denn dieser ist ja kein Netzwerk-Administrator. Solange von außen keine Ports offen sind, ist das alles kein Problem. Dann macht der Router ja genau, was er soll - hoffentlich. Die Gefahr eines Einbruchs in das interne Netzwerk ("Heimnetzwerk") ist dann minimal. Wenn nun aber Dienste auf dem Router aktiv sind, dann sind Ports offen, über die ein Angriff stattfinden kann. Idealerweise sind es Ports, die nur im internen Netz zugänglich sind. Aber auch das kann bereits eine Schwachstelle sein. Schafft man es nämlich, einen PC aus dem internen Netzwerk zu "überreden", von "innen" aus den Router anzugreifen, hat man eventuell schon verloren. Vielleicht mag jetzt der eine oder andere ungläubig den Kopf schütteln, aber es gab solche Fälle bereits in der Vergangenheit. Krasser wird die ganze Sache, wenn Dienste auch "versehentlich" im äußeren Netz zugänglich gemacht werden. Das kann durch die Blödheit des Users geschehen, der eine Anleitung missverstanden hat oder auch durch tatsächliche Verwundbarkeit von Diensten wie der sog. "Fernwartung", die nachweislich schon bei AVM-Routern (Fritz!Box) von außen geknackt werden konnte. Ergo: Dienste auf einem Router stellen immer ein mögliches Einbruchsszenario und damit ein erhöhtes Sicherheitsrisiko dar. Ein Einbruch in ein Netz über solch einem Router kann fatal sein, denn meist "vertrauen" die Rechner im internen Netz diesem Router, d.h. es sind keine weiteren Sicherheitsmaßnahmen vorhanden, um sich gegen den eigenen Router zu schützen.
Jörg Wunsch schrieb: > Aus Sicherheitsgründen, damit ein Bug im Router Danke für die Antwort. Dann halte ich mich mit der OT-Frage auch wieder raus. BTT: Der Antwort von Frank M. (ukw) ist kaum was hinzuzufügen und sagt schon alles. Kim Schmidt schrieb: > Ich frage mich nur deshalb, weil gerde in sicherheitsrelevanten > bereichen Pascal ähnliche Sprachen verwendet werden, … In den sicherheitsrelevanten Bereichen die ich kenne, wird aus einem Simulink-Modell mit TargetLink C-Code erzeugt. Dabei ging es aber nur um 'Automotive Safety Integrity Level C', wenn ich mich recht erinnere. Kennst Du Beispiele mit Pascal?
:
Bearbeitet durch User
Kim Schmidt schrieb: > Es spricht nichs dagegen ein System in PAscal zu schreiben Nun, warum tut's dann keiner? Irgendeinen Grund muss es geben. Am Erlernen der Sprache selbst liegt es ganz gewiss nicht, in dieser Hinsicht ist Pascal ja eher einfacher als C.
Jörg Wunsch schrieb: > Irgendeinen Grund muss es geben. Ja, den suche ich da auch. > Am Erlernen der Sprache selbst liegt > es ganz gewiss nicht, in dieser Hinsicht ist Pascal ja eher einfacher > als C. Da gebe ich Dir vollkommen Recht. Es kann nur daran liegen, daß seit einigen Jahren die Leute in Schule, Berufsschule und / oder Universität "C" gelehrt bekommen. Die Leute nehmen dann, was sie kennen und können. Früher hätten sie Pascal genommen. MfG Paul
Paul Baumann schrieb: > Die Leute nehmen dann, was sie kennen und können. Früher hätten sie > Pascal genommen. Wenn, dann eher Modula-2. Gibts auch schon seit "früher[tm]" und ist wesentlich formaler und komfortabler als Pascal ("Labersprache") ausgelegt. Wirth hat da so ziemlich alle Fehler, die er in Pascal (bzw. Modula) reinsteckte, ausgemerzt. Ich könnte mir vorstellen, dass damit eher die Implementation eines OS möglich wäre. Aber auch Modula-2 ist längst altes Eisen und ist von Oberon (ebenfalls von Wirth) abgelöst worden. Und wenn man da mal schaut, wird man auch fündig: "Das ETH Oberon System ist ein eigenständiges Betriebssystem der ETH Zürich, das in der Sprache Oberon implementiert ist, als Entwicklungsgrundlage für die Sprache diente und ebenso wie der Compiler kostenlos erhältlich ist." (aus http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29 ) P.S. Was ist für Dich "früher"? Unix - größtenteils in C programmiert - gibts seit 1970. Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, also nicht praxisrelevant.
:
Bearbeitet durch Moderator
warum es keiner tut?" Na also damals zu DOS Zeiten wurden doch viele Treiber in Pascal geschrieben und mittlerweile ist halt C populärer
Kim Schmidt schrieb: > Na also damals zu DOS Zeiten wurden doch viele Treiber in Pascal > geschrieben und mittlerweile ist halt C populärer Das ist meines Erachtens falsch. C war immer populärer. In den 70ern gab's noch kein DOS - und damit auch kein Pascal für DOS. Unix gab es aber schon - in C programmiert.
Frank M. schrieb: > C war immer populärer. Und MS-DOS war (zumindest treibermäßig) zu großen Teilen noch in Assembler programmiert.
> ... Ich frage mich nur deshalb, weil gerde in sicherheitsrelevanten
bereichen Pascal ähnliche Sprachen verwendet werden, wieso nicht bei
Routern?
Router .. sicherheitsrelevant ? Router sind Devices vom Grabbeltisch,
die erst mal billigst sein muessen...
na aber allmählich lernen doch auch die letzten das Internetkomponenten sehr wohl als sicherheitsrelevant einestuft werden sollten
Paul Baumann schrieb: > Es kann nur daran liegen, daß seit einigen Jahren die Leute in Schule, > Berufsschule und / oder Universität "C" gelehrt bekommen. Bloedsinn. Schau doch mal in die Plaene von Unis/FH, da steht Java ganz oben, und ganz vielleicht noch C++, wenn ueberhaupt. Manchmal noch Python oder Ada, C wird nur in wenigen Studienfaechern angeboten (z.B. IT-Sicherheit an der Uni Bochum).
Jetzt Nicht schrieb: > Router .. sicherheitsrelevant ? Router sind Devices vom Grabbeltisch, > die erst mal billigst sein muessen... Redest Du jetzt von Routern im Heimbereich oder Routern in einem Rechenzentrum beispielsweise? Wenn jemand von "sicherheitsrelevanten Bereichen" spricht, meint er dabei nicht unbedingt das Netz zu hause... Ich käme da jedenfalls nicht unbedingt als erstes auf diese Idee.
Die Überprüfung der Array-Grenzen zur Laufzeit ist sicher ein gutes Mittel, um Buffer-Overflows zu erkennen und weiteren Schaden zu verhindern. Auf den Routern läuft üblicherweise Linux als Betriebssystem. Linux ist einschließlich seiner Treiber in C programmiert, wobei es sicher mit ein paar Verrenkungen auch möglich wäre, einen Treiber in Pascal zu schreiben. Der Router-Hersteller würde aber mit hoher Wahrscheinlichkeit das Range-Checking in Pascal deaktivieren, um den damit verbundenen Speicher- und Laufzeit-Overhead zu minimieren und damit möglicherweise ein paar Cents beim Prozessor und Flash-Speicher einzusparen. Solche Sicherheitsüberprüfungen werden oft nur während der Entwicklungs- und Testphase aktiviert. Treten bei den Tests keine Fehler auf, wird die Software als ausreichend fehlerfrei betrachtet, so dass in der Release- Version auf die Prüfungen verzichtet wird. Vielleicht macht sich der (schlampige) Hersteller auch überhaupt keine Gedanken um solche Dinge. Dann wird er, was die Sicheheitsabfragen betrifft, einfach die Defaulteinstellungen des Compilers verwenden. Bei vielen Pascal-Compilern (bspw. bei Free Pascal) ist das Range-Checking (zusammen mit etlichen anderen Sicherheitsüberprüfungen) aber default- mäßig deaktiviert (vermutlich, um bei Benchmarks besser abzuschneiden). Somit ist also auch bei Pascal-Treibern trotz der prinzipiell höheren Sicherheit von Pascal gegenüber C die Chance recht groß, dass es so ein Bug bis ins Serienprodukt schafft.
Frank M. schrieb: > Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, > also nicht praxisrelevant. Bei uns im Betrieb (sogar im ganzen Kombinat) wurde sämtliche Anwendungssoftware in Pascal geschrieben. Frank M. schrieb: > In den 70ern > gab's noch kein DOS - und damit auch kein Pascal für DOS. In den 70ern gab es CP/M und damit ein System, auf dem Pascal-Kompiler liefen. >> Es kann nur daran liegen, daß seit einigen Jahren die Leute in Schule, >> Berufsschule und / oder Universität "C" gelehrt bekommen. Kaj G. schrieb: > Bloedsinn. Vorsicht µit den jungen Pferden! > Schau doch mal in die Plaene von Unis/FH, da steht Java ganz > oben, und ganz vielleicht noch C++, wenn ueberhaupt. Ich sprach auch von Schule und Berufsschule. Liest man hier jeden Tag, wie Kinder und Jugendliche sich mit dem Kram befassen müssen und über deren "Freude" darüber. MfG Paul
Kim Schmidt schrieb: > warum es keiner tut?" > Na also damals zu DOS Zeiten wurden doch viele Treiber in Pascal > geschrieben und mittlerweile ist halt C populärer Damals hat man Treiber im ASM geschrieben. Die Rechner waren einfach nicht schnell genug, als dass man sich den Luxus einer Hochsprache fürs OS hätte erlauben können, ohne dass das die ganze Kiste nur mit sich selbst beschäftigt gewesen wäre. Das frühe C war eine Art Super-Assembler und deswegen prädestiniert dafür, ASM im Betriebssystembau abzulösen. Wie oben schon gesagt, gab es von Wirth auch experimentelle Betriebssysteme, die in Pascal und Nachfolgern geschrieben waren - das waren aber alles Lehrprojekte, die nie praktische Relevanz erlangten.
Paul Baumann schrieb: > Bei uns im Betrieb (sogar im ganzen Kombinat) wurde sämtliche > Anwendungssoftware in Pascal geschrieben. Treiber sind keine Anwendungssoftware...
Uhu Uhuhu schrieb: > Treiber sind keine Anwendungssoftware... Echt jetzt? /Loriot Ach?! \Loriot Pass auf, ich erkläre es Dir noch einmal haarklein: Frank M. schrieb: >> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, >> also nicht praxisrelevant. Daraufhin schrieb ich: >> Bei uns im Betrieb (sogar im ganzen Kombinat) wurde sämtliche >> Anwendungssoftware in Pascal geschrieben. ->Schlussfolgerung: Die Sprache ist sehr wohl praxiasrelevant gewesen, denn sonst hätten sich nicht Dutzende Progarmmierer im ganzen Land damit produktiv beschäftigt. Nein, es ging nicht um Treiber. MfG Paul
A. K. schrieb: > In vielen Sprachen - aber eben nicht in C - kann bei > Array-Zugriffen > Code eingebaut werden, der Indices auf zulässigen Wertebereich > überprüft. Das spielt bei Thema "buffer overflow" eine nicht > unerhebliche Rolle. Bounds Checking bringt massig Overhead mit sich und hilft nicht immer. In C ist das eh kein Problem, man muss nur die n-Funktionen (also z.B. snprintf statt sprintf benutzen) und ein paar einfache Regeln beachten. Nur weil C schlechte Programmierer nicht vor sich selbst schützt ist es nicht per se "gefährlich".
Paul Baumann schrieb: > ->Schlussfolgerung: Die Sprache ist sehr wohl praxiasrelevant gewesen, > denn sonst hätten sich nicht Dutzende Progarmmierer im ganzen Land damit > produktiv beschäftigt. Ich habe auch schon Anwendungsprogramme in Pascal geschrieben - das war aber zu 8080/Z80-Zeiten. Es gab auch im Westen eine Pascal-Gemeinde, die wurde aber den Ruch der Software-Esoterik nie so recht los... Uhu Uhuhu schrieb: > Wie oben schon gesagt, gab es von Wirth auch experimentelle > Betriebssysteme, die in Pascal und Nachfolgern geschrieben waren - das > waren aber alles Lehrprojekte, die nie praktische Relevanz erlangten. Ich hoffe, du kennst den Unterschied zwischen einem Betriebssystem und Anwendungssoftware...
Uhu Uhuhu schrieb: > Ich hoffe, du kennst den Unterschied zwischen einem Betriebssystem und > Anwendungssoftware... Nein. Erklär doch mal! ;-) MfG Paul
Malignes Melanom schrieb: > Bounds Checking bringt massig Overhead mit sich Nicht unbedingt. Das muss nicht bei jedem Zugriff stattfinden, wenn der Compiler feststellt, dass es ausreicht, vor der Schleife zu kontrollieren statt drinnen beim Zugriff. Bei einem auf 0 basierten Index ist das z.B. ein Vergleich und ein komplett ignorierter Sprung oder eine Exception. Bei heutigen Prozessoren ist das kein grosser Aufwand und wird als unabhängiger Seitenpfad oft nur gering in die Laufzeit eingehen. > und hilft nicht immer. Hat niemand behauptet. Ist nur ein Baustein. > In C ist das eh kein Problem Manuell programmiert ist das auch in Assembler kein Problem. Perfekt programmiert funktioniert alles. Aber wer programmiert schon perfekt?
:
Bearbeitet durch User
Paul Baumann schrieb: > In den 70ern gab es CP/M und damit ein System, auf dem Pascal-Kompiler > liefen. Der erste Release von Turbo-Pascal (für CP/M) war im November 1983. Alles davor hat keiner freiwillig auf CP/M benutzt, weder C-Compiler noch Pascal-Compiler. Da konntest du während des Compilierens ja in Ruhe einen Kaffee aufbrühen und trinken. 1983 war UNIX bereits beim legendären System V angelangt und bestand vermutlich schon zu mehr als 95 % aus C-Code. Ich habe Turbo-Pascal für CP/M auch gern benutzt, nicht dass du mich falsch verstehst, Paul. Aber ich wäre nicht auf die Idee gekommen, damit das BDOS oder BIOS meines CP/M zu schreiben – um mal so zumindest annähernd auf das zurückzukommen, um das es eingangs ging.
Jörg Wunsch schrieb: > Alles davor hat keiner freiwillig auf CP/M benutzt, weder C-Compiler > noch Pascal-Compiler. Doch. Man hat das genutzt was es gab und hatte nicht die heutigen Ansprüche an die Zykluszeit bei der Entwickung. Es war aber noch nicht die Zeit von C, damals waren ausserhalb der Unix-Szene andere Sprachen üblich. C gab es m.W. nur als Tiny-C. So gab es beispielsweise UCSD P-Code Pascal. Mit dem Auftritt von Turbo-Pascal war das natürlich tot, aber bis dahin eine durchaus für Anwendungen nutzbare Sprache. Ich habe testweise auch mal PL/I für CP/M ausprobiert. In Anbetracht der überschaubaren Leistung eines solchen Systems war das sogar einigermassen brauchbar (abgesehen von Eigenheiten der Sprache selbst) und hatte trotz Subset einen beachtlichen Funktionsumfang.
Jörg Wunsch schrieb: > Paul Baumann schrieb: >> In den 70ern gab es CP/M und damit ein System, auf dem Pascal-Kompiler >> liefen. > > Der erste Release von Turbo-Pascal (für CP/M) war im November 1983. Das war aber das Teufelszeug vom Klassenfeind. Vielleicht hatten sie ja was Eigenes. Die waren ja nicht doof. mfg.
Thomas Eckmann schrieb: > Das war aber das Teufelszeug vom Klassenfeind. Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut war? Nicht nur Chinesen haben ein Faible für technische Abkürzungen ;-)
Uhu Uhuhu schrieb: > Thomas Eckmann schrieb: >> Das war aber das Teufelszeug vom Klassenfeind. > > Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut > war? Wikipedia sagt dazu: Die PDP-11 wurde wegen ihrer technischen Bedeutung auch in der Sowjetunion und ihren verbündeten Staaten ohne Lizenz nachgebaut. Beispiele dafür sind: - SM-4, SM-1420, IZOT-1016 (Bulgarien). - K 1600 (DDR) - Mera (Polen) - I-102 (Rumänien) - SM-4, SM-1420, SM-1600, Elektronika BK-0010, DVK, UKNC (Sowjetunion) TPA-51 (Ungarn) "TPA" (ung. Abk.) "Speicherprogrammierbarer Analysator". Exakter Nachbau des PDP 11/40 vom Institut für Kernphysik (KFKI) der Ungarischen Akademie der Wissenschaften (MTA). "TPA-11/40" wurde später in "TPA-51" (11+40) umbenannt. Ich selbst habe in den 80ern an einer PDP11 gearbeitet - im Institut für Kernphysik in Köln. Der Kernspeicher, wo Magnete auf einer Drahtmatrix aufgezogen waren und man jedes Bit noch einzeln sehen konnte, hat mich bis heute fasziniert... Betriebssystem war RSX-11, ein Realtime-OS. Aber auch unixoide Systeme wie Ultrix, Unix System 7 und BSD waren für die PDP11 verfügbar. Womit wir wieder bei C und nicht bei Pascal wären ;-)
:
Bearbeitet durch Moderator
Thomas Eckmann schrieb: > Das war aber das Teufelszeug vom Klassenfeind. Vielleicht hatten sie ja > was Eigenes. Ja, hatten sie. SCP, CPA und MCP. Dann gab es auch noch "UDOS" (Nein, nicht Lindenbergs und Jürgens) ;-) MfG Paul Edith sagt gerade noch: Frank M. schrieb: > - K 1600 (DDR) PDP11 kenne ich nur vom Namen, aber der K1600 hatte m.E.n. keine Kernspeicher mehr, sondern rauhe Mengen an dynamischen RAMs vom Typ U6164
Uhu Uhuhu schrieb: > Nicht nur Chinesen haben ein Faible für technische Abkürzungen ;-) Yep. Hardware musste umständlich nachgebaut werden, weil in nennenswerten Stückzahlen schwer zu kriegen. Software musste nur einmal geklaut werden und brauchte beim Schmuggel weniger Platz (ja, ich weiss, nicht alles war stibitzt...). Aber wenn man in der Geschichte ein wenig zurück blickt, dann kann man das auch anderswo finden. So hat auch dein Lieblingsfeind und heutiger Vorreiter beim geistigen Eigentum im 19. Jahrhundert von den Europäern geklaut was sich zu klauen lohnte. Das findet gewöhnlich dann allmählich ein Ende, wenn der Schaden zu gross wird, der durch Klau innerhalb des Emporkömmlings entsteht. Das merken allmählich auch die Chinesen, die sich ja auch selber beklauen was das Zeug hält.
:
Bearbeitet durch User
Paul Baumann schrieb: > PDP11 kenne ich nur vom Namen, aber der K1600 hatte m.E.n. keine > Kernspeicher mehr, sondern rauhe Mengen an dynamischen RAMs vom Typ > U6164 Die PDP-11 Reihe hatte lange genug Bestand, um mit Kernspeicher anzufangen und später auf Halbleiterspeicher zu überzugehen. 1970 kamen die ersten Modelle als TTL-Gräber raus, 1990 die letzten mit vollintegriertem Prozessor. Eingesetzt werden sie z.T. noch heute. Geplant bis 2050: http://www.theregister.co.uk/2013/06/19/nuke_plants_to_keep_pdp11_until_2050/
:
Bearbeitet durch User
Uhu Uhuhu schrieb: > Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut > war? Wobei die Hardware meines Wissens nicht geklaut war. Bspw. hatte der K1630 von robotron NMOS-Bitslice-CPUs. Waren leider nicht die schnellste, die TTLs der PDP dürften einiges schneller gewesen sein. Die Software hatte allerdings auf irgendwelchen Kanälen ihren Weg zu robotron gefunden … allerdings gab es auch da Eigenentwicklungen teilweise von Unis, die beliebter waren als der robotron-Krams (OS/RW). Paul Baumann schrieb: > Ja, hatten sie. > SCP, CPA und MCP. > > Dann gab es auch noch "UDOS" (Nein, nicht Lindenbergs und Jürgens) > ;-) War aber alles nichts „eigenes“. ;) SCP war nur ein umgelabeltes CP/M, bei CP/A hatte sich die AdW viel Mühe gemacht und viel eigenes drin, aber das BDOS war auch original. UDOS hieß westlich von Werra und Elbe „RIO“. Eine (meines Wissens) wirkliche Eigenentwicklung von robotron war SIOS: http://www.robotrontechnik.de/html/software/sios.htm
Jörg Wunsch schrieb: > wirkliche Eigenentwicklung von robotron war > SIOS: SIOS! Ja, -das hatte ich ganz vergessen. MCP war vom Mansfeld Kombinat in Eisleben entwickelt. MfG Paul
Jörg Wunsch schrieb: > Eine (meines Wissens) wirkliche Eigenentwicklung von robotron war > SIOS: > > http://www.robotrontechnik.de/html/software/sios.htm Nette Formulierung: "Zu SIOS gibt es kein kompatibles westliches Betriebssystem." D.h. die Wessis habens jedenfalls nicht geklaut ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > D.h. die Wessis habens nicht geklaut ;-) ... und die Ossis kaum genutzt, weil Wessi-Soft nicht drauf lief. ;-)
:
Bearbeitet durch User
Frank M. schrieb: > Betriebssystem war RSX-11, ein Realtime-OS. Aber auch unixoide Systeme > wie Ultrix, Unix System 7 und BSD waren für die PDP11 verfügbar. Womit > wir wieder bei C und nicht bei Pascal wären ;-) Unix wurde ursprünglich auf PDP-8 entwickelt.
A. K. schrieb: > So hat auch dein Lieblingsfeind und heutiger > Vorreiter beim geistigen Eigentum im 19. Jahrhundert von den Europäern > geklaut was sich zu klauen lohnte. Wer ist mein Lieblingsfeind?
A. K. schrieb: > In vielen Sprachen - aber eben nicht in C - kann bei Array-Zugriffen > Code eingebaut werden, der Indices auf zulässigen Wertebereich > überprüft. Das spielt bei Thema "buffer overflow" eine nicht > unerhebliche Rolle. Ich meine, dass C-Run von IAR eben ganau sowas (und anderes) tut.
Paul Baumann schrieb: > MCP war vom Mansfeld Kombinat in Eisleben entwickelt. Die Abkürzung MCP kenne ich von den Burroughs: Master Control Program. Auf den verschiedenen Rechnerlinien gab es sehr verschiedene Versionen: Die B6700 war eine Hardware-Stackmaschine; deren MCP war in Algol programmiert. Die B1700er-Linie war der erste vollständig mit Halbleitern aufgebaute kommerzielle Rechner. Deren MCP war in einer speziellen Sprache namens SDL - Software Development Language - programmiert. Der Prozessor war als Interpretationsmaschine optimiert, die einen Zwischencode per Microprogamm interpretierte. Microprogramme wurden mit einer Art Assembler namens MIL - Microcode Implementation Language oder so ähnlich - geschrieben. Die Microprogramme konnte man über die Konsole schrittweise durchtackern - mit 24 LEDs, 24 Kippschaltern zum Register laden und einige andere Taster für Halt, Step... Wirth hatte an der 1700 auch gefallen gefunden und es gab auch ein Pascal-OS dafür.
Uhu Uhuhu schrieb: > Unix wurde ursprünglich auf PDP-8 entwickelt. ... und später als SystemV auf einer 3B2 von AT&T weiterentwickelt. Die erste 3B2 mit der Seriennummer 0000000018, die über den Teich nach Europa ging, landete damals in der Firma, in der ich als junger Spunt gerade anfing. Und ich war begeistert: - Ein echter Shutdown-Schalter, der die Maschine ordnungsgemäß herunterfuhr. Einen Power-Off-Schalter gab es gar nicht. Somit war versehentliches Abschalten gar nicht möglich. (Heutzutage kann das jeder PC, damals war das eine absolute Neuheit) - Sagenhafte 4 MB RAM, auf dem sich 5-6 Entwickler parallel austoben konnten. Sogar gleichzeitiges Compilieren von mehreren Entwicklern war damit möglich - auch wenn das erste System-V damals noch gar keine Pages kannte, sondern nur Swapping. (Paging kam später, meiner Erinnerung nach in System-V R3) - Der U3B-Prozessor beherrschte elementare C-Funktionen wie strcmp(), strcpy(), memcpy(), memcmp() usw. direkt als Maschinen-Befehle. Damals dachte noch niemand an Buffer-Overflows als mögliches Angriffsszenario... ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > Sogar gleichzeitiges Compilieren von mehreren > Entwicklern war damit möglich Ein vernünftiger Rechner erlaubt sogar das Gegenteil: Das gleichzeitige Entwickeln von mehreren Kompilern. ;-) MfG Paul
Frank M. schrieb: > Sogar gleichzeitiges Compilieren von mehreren Entwicklern war damit möglich In der DDR wurden die Entwickler in Gruppen kompiliert? mfg.
Thomas Eckmann schrieb: > In der DDR wurden die Entwickler in Gruppen kompiliert? Wieso DDR? Neeee, Köln gehörte nicht zur DDR ;-)
Frank M. schrieb: > Köln gehörte nicht zur DDR ;-) Kann mich auch nicht dran erinnern, je von einer 3B2 in der DDR gehört zu haben. ;-) Die „Oberen“ dort waren ohnehin eher Vax- und VMS-lastig in ihren Bestrebungen (robotron hatte einen funktionierenden Vax-Clone).
Frank M. schrieb: > Wieso DDR? Neeee, Köln gehörte nicht zur DDR Was? Köln a.d. Oder ist doch DDR. mfg.
Ich habs in einem anderen Thread schon mal erwähnt - bis einschliesslich Mac OS 7 wurde auf dem Mac unter MPW in Pascal geschrieben, und zwar nicht nur Anwendungen, sondern auch Treiber (natürlich geht das). Die aufkommende C-Manie erforderte dann Gluecode, um die ROM und Systemroutinen auch unter C aufzurufen. Die ROMs waren allerdings grösstenteils in 68k Assembler genagelt.
Frank M. schrieb: > Die erste 3B2 mit der Seriennummer 0000000018, die über den Teich nach > Europa ging, landete damals in der Firma, in der ich als junger Spunt > gerade anfing. Und ich war begeistert: Wo wir grad beim Kopieren waren: Dessen Instruction Set Architecture war wie manch andere der 80er sehr von der VAX inspiriert - höflich ausgedrückt. Mit dem gleichen Problem: Es ist schon recht aufwändig, bei solchen ISAs auf einen Befehl pro Takt zu kommen, ganz zu schweigen von mehreren Befehlen pro Takt. Die Lebensdauer solcher Architekturen war dadurch recht begrenzt. Beim Versuch, die VAX wesentlich zu beschleunigen, ist DEC deshalb beinahe koppheister gegangen. > - Der U3B-Prozessor beherrschte elementare C-Funktionen wie strcmp(), > strcpy(), memcpy(), memcmp() usw. direkt als Maschinen-Befehle. Was nicht unbedingt ein Vorteil sein musste. Nicht selten waren solche Befehle langsamer als manuell programmierte Ersatzsequenzen. Beispielsweise weil der Microcode alle Fälle von Alignment und Overlap berücksichtigen muss, der Programmierer aber oft a prio weiss wie es sich damit verhält. Zum WE-32100 Prozessor (der von manchen AT&T 3Bs verwendet wurde) ist für den STRCPY Befehl eine Mindestlaufzeit von 83-182 Takten überliefert. Die unstrittig vorhandene Eleganz und Schönheit ist in dieser Branche kein wirklich entscheidendes Kriterium. Effizienz schlägt Schönheit. DEC wechselte zunächst zur MIPS Architektur, bevor Alpha kam. Mir ging es allerdings zunächst nicht viel anders, als ich den nicht unähnlich entwickelten NS32000 und NEC V60 Architekturen begegnete. Bis ich ARM2 begegnete. Da wurde mir allmählich klar, wieviel man mit solch eleganter Komplexität verliert.
:
Bearbeitet durch User
A. K. schrieb: > Die unstrittig vorhanden Eleganz und Schönheit ist in dieser Branche > kein wirklich entscheidendes Kriterium. Effizienz schlägt Schönheit. Die Schönheit war für ASM-Programmierer ein Kriterium - auf 8086 & Co. ASM zu programmieren, ist nicht das reine Vergnügen, wegen der vielen Asymmetrien.
Uhu Uhuhu schrieb: > Die Schönheit war für ASM-Programmierer ein Kriterium - auf 8086 & Co. > ASM zu programmieren, ist nicht das reine Vergnügen, wegen der vielen > Asymmetrien. Yep. Aber schon die Namensgebung des STRCPY Befehls stellt klar, dass die 3B2 die C Programmiersprache im Sinn hatte. Immerhin war das Ding von AT&T. Generell waren die 80er eine Ära, in der Mikroprozessoren zunehmend auf den Einsatz mit Hochsprachen optimiert wurden und Assembler-Programmierung in den Hintergrund rückte. Parallel dazu entstanden optimierende C Compiler, die weit mehr waren, als eine ungefähre 1:1 Umsetzung von Quellcode in Maschinencode. IBM hatte das schon in den 70ern gemerkt, aber niemandem verraten (801).
:
Bearbeitet durch User
Uhu Uhuhu schrieb: > Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut > war? Ihr hättet sie uns auch verkaufen können. Wolltet ihr ja nicht. Wenn mir jemand was nicht verkaufen will, bau ichs mir halt selber. Frank M. schrieb: > Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, > also nicht praxisrelevant. O.Montenbruck, T.Pfleger: ASTRONOMIE MIT DEM PERSONAL COMPUTER, 2. Aufl. 1993 Alles von Koordinatentransformation bis zu SoFi-Berechnungen und Planetenbahnen in Pascal. Nö, ist nicht praxisrelevant...
Timm Thaler schrieb: > Ihr hättet sie uns auch verkaufen können. Wolltet ihr ja nicht. Wir schon, aber wir durften nicht - das haben sich die Amis vorbehalten und haben prächtig daran verdient. Ich war kurz nach Gorbatschows Amtsantritt für einige Wochen in Moskau bei einer Bank - was ich dort im Rechenzentrum gesehen habe, das hätten wir denen im Leben nicht verkaufen dürfen: u.a. das seinerzeit neuste Modell einer HP 3000.
Timm Thaler schrieb: > Frank M. schrieb: >> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, >> also nicht praxisrelevant. > > O.Montenbruck, T.Pfleger: ASTRONOMIE MIT DEM PERSONAL COMPUTER, 2. Aufl. > 1993 > > Alles von Koordinatentransformation bis zu SoFi-Berechnungen und > Planetenbahnen in Pascal. Nö, ist nicht praxisrelevant... Ich sprach davon, dass Pascal in den 70ern nicht praxisrelevant war, weil es damals zunächst reine Lehrsprache war. Später natürlich schon. A.K. hat es auch erwähnt, z.B. den Erfolg von Turbo Pascal in den 80ern. In den 70ern jedoch wurden schon ganze Betriebssysteme in C geschrieben. Pascal spielte da noch eine untergeordnete Rolle. Jetzt verstanden? ;-)
Frank M. schrieb: > Ich sprach davon, dass Pascal in den 70ern nicht praxisrelevant war, Nein, das geht aus der Semantik Deines Satzes nicht hervor. Bitte informiere Dich über Zeitformen. Frank M. schrieb: > In den 70ern jedoch wurden schon ganze Betriebssysteme in C geschrieben. > Pascal spielte da noch eine untergeordnete Rolle. In den 70ern gab es auch schon qwerty-Tastaturen, und wir benutzen sie heute noch. Trotzdem eine Scheissidee, oder? Dvorak und Neo spielte nie eine Rolle.
Timm Thaler schrieb: > Nein, das geht aus der Semantik Deines Satzes nicht hervor. Bitte > informiere Dich über Zeitformen. Tut mir leid, dass Du mich falsch verstanden hast, als ich davon sprach, dass Pascal 1971 als reine Lehrsprache konzipiert wurde. Wo soll ich den Keks hinschicken? ;-) Kannst mir ja einen Link über Zeitformen schicken, aber bitte dann per PM. > In den 70ern gab es auch schon qwerty-Tastaturen, und wir benutzen sie > heute noch. qwerty-Tastaturen sind geil. Ich benutze sie unter Unix und Linux und zum Programmieren sogar bevorzugt. Man schont dabei Shift- und Alt-Tasten, d.h. die in der Shell und in C sehr oft vorkommenden Zeichen / { [ ] } \ sind mit nur einem Tastendruck erreichbar. Aber wir kommen vom Thema ab.
Frank M. schrieb: > Als Gründer des fli4l-Router-Projekts kann ich von dem Thema ein Lied > singen... Ich möchte dir für das Projekt Danken, es hat mir einige Jahre lang gut gedient.
:
Bearbeitet durch User
Frank M. schrieb: > Timm Thaler schrieb: >> Frank M. schrieb: >>> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, >>> also nicht praxisrelevant. >> >> O.Montenbruck, T.Pfleger: ASTRONOMIE MIT DEM PERSONAL COMPUTER, 2. Aufl. >> 1993 >> >> Alles von Koordinatentransformation bis zu SoFi-Berechnungen und >> Planetenbahnen in Pascal. Nö, ist nicht praxisrelevant... > > Ich sprach davon, dass Pascal in den 70ern nicht praxisrelevant war, > weil es damals zunächst reine Lehrsprache war. Später natürlich schon. > A.K. hat es auch erwähnt, z.B. den Erfolg von Turbo Pascal in den 80ern. > > In den 70ern jedoch wurden schon ganze Betriebssysteme in C geschrieben. > Pascal spielte da noch eine untergeordnete Rolle. Kommt drauf an wie "untergeordnet" definiert wird... UCSD-Pascal 1) bzw. das portable UCSD p-System (Ende der 70er, Anfang der 80er) waren, neben anderen, die Vorläufer heutiger VMs wie der Java-VM und (experimenteller) Betriebssysteme und relativ weit verbreitet. Von Western Digital gab's eine Hardware-Implementierung 2) und Apple setzte bei der Lisa auf Pascal. Aufgrund der Hardwarebeschränkungen der ersten Macs wurde dann z.T. von Hand in Assembler übersetzt... 3) 1) http://en.wikipedia.org/wiki/UCSD_Pascal 2) http://en.wikipedia.org/wiki/Pascal_MicroEngine 3) http://www.folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txt
Jon schrieb: > oder Bascom? oder Java? > > http://www.heise.de/newsticker/meldung/Kritische-Luecke-in-etlichen-Routern-2655271.html Gibt es denn die Java, Pascal oder Bascom Compiler für die entsprechenden Zielsysteme?
Pascal mit Sicherheit, basic,.puh k.a. vielleicht..Java vermutlich nicht
Torsten C. schrieb: > Warum dürfen Server und Router nicht zusammen in ein Gerät? Sie dürften problemlos in ein Gerät. Es müssten lediglich zwei komplett eigenständige Prozessorsysteme sein. Gehäuse und Stromversorgung können sie sich teilen.
Jens Martin schrieb: > Jon schrieb: >> oder Bascom? oder Java? >> >> > http://www.heise.de/newsticker/meldung/Kritische-Luecke-in-etlichen-Routern-2655271.html > > Gibt es denn die Java, Pascal oder Bascom Compiler für die > entsprechenden Zielsysteme? Schau mal nach welchen Libs dein Programm braucht. Unter Linux wird meistens die libc benutzt und die ist leider in C Dein Java ist dann zwar sicher, dein Problem liegt dann aber anderen Libs.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.