Zukunft
-
Hi,
bei dem ganzen "Sprachenkrieg" sollte man nicht vergessen, dass das Hauptproblem in der IT heutzutage (war vllt. schon immer so) nicht ist, Code zu erstellen. Mindestens 90% der Codings ist recht einfaches Zeug, das mitnichten die Grenzen einer modernen Programmiersprache (egal welcher) ausloten...
Und: 90% der Zeit verbringt man mit Nichtprogrammieraufgaben.
Bei uns vergehen 90% der Projektzeit damit,- Mit dem Kunden zu klären, was seine Anforderungen eigentlich sind und seine konzeptionellen Schwächen auszubügeln (40%)
- Sich ein geeignetes Design auszudenken (auf Basis einer bestehenden Infrastruktur) (25%)
- geeignete Testverfahren zu definieren und durchzuführen (25%)
Das mag für "fahrende Händler ähh Programmierer" anders sein, aber in meinem beruflichen Umfeld ist das so.
Gruß,
Simon2.
P.S.: Wir haben zwar auch technische und fachliche "Architekten", die sich mehr mit reinen informatikthemen beschäftigen, aber das sind 15-20 auf 700 Programmierer.
-
Simon2 schrieb:
- Mit dem Kunden zu klären, was seine Anforderungen eigentlich sind und seine konzeptionellen Schwächen auszubügeln (40%)
- Sich ein geeignetes Design auszudenken (auf Basis einer bestehenden Infrastruktur) (25%)
- geeignete Testverfahren zu definieren und durchzuführen (25%)
Also zweiteres gehört ganz klar zur Programmierung dazu. Letzteres eigentlich auch.
-
TactX schrieb:
Simon2 schrieb:
- Mit dem Kunden zu klären, was seine Anforderungen eigentlich sind und seine konzeptionellen Schwächen auszubügeln (40%)
- Sich ein geeignetes Design auszudenken (auf Basis einer bestehenden Infrastruktur) (25%)
- geeignete Testverfahren zu definieren und durchzuführen (25%)
Also zweiteres gehört ganz klar zur Programmierung dazu. Letzteres eigentlich auch.
... wenn ich mir hier (nicht nur in diesem Thread) aber ansehe, worüber der Großteil der Diskussionen geführt wird - und was "ich-will-Programmierer-werden"-Poster fragen/denken - , habe ich den Eindruck, dass diese Themen deutlich unterrepräsentiert sind.
Gerade junge Leute, die "Programmierer" werden wollen, wissen das einfach nicht und es sollte ihnen hier IMO deutlicher gesagt werden.
Gruß,
Simon2.
-
Simon2 schrieb:
Gerade junge Leute, die "Programmierer" werden wollen, wissen das einfach nicht und es sollte ihnen hier IMO deutlicher gesagt werden.
Ist auch vollkommen richtig
-
TactX schrieb:
Optimizer schrieb:
TactX schrieb:
Ich kann mir nicht vorstellen, was richtig low-leveliges mit C# zu machen. Ist auch noch nie geschehen.
Führe doch bitte mal genau aus, was mit C# nicht möglich ist in Punkto low-level Programmierung im Vergleich mit C++.
Z.B. einen kleinen Microcontroller effizient programmieren. Oder halt genau die Teile die bei Singularity eben auch nicht schön in der warmen VM rennen.
Das hat mit VM überhaupt nichts zu tun. Vielleicht solltest du dich mal genauer über die Möglichkeiten von C# informieren. Es gibt Pointer, nicht-GC Heaps, alles was du in C++ auch hast. In C++ gibt es nix tolles lowleveliges, was es in C# nicht auch gibt. Einfach herkommen und sagen "mit C# kann man nicht effizient programmieren" ist eigentlich nicht haltbar. Wenn dir eine Laufzeitumgebung zu heavy ist, dann lass sie weg. C# ist nur ein Sprache und dass ein Betriebssystem wie Singularity nicht in einer VM läuft ist doch auch völlig klar. Der BS-Code an sich wurde natürlich zu native Code compiliert, was nichts anderes ist als was die VM ohnehin immer macht.
Und um zum Thema zurückzukommen. Die Teile von Singularity, die normalerweise in C oder C++ geschrieben worden wären, sind in C# geschrieben worden. Wo ist das Problem? Da bekommt man dann einfach zu hören "geht nicht geht nicht ist scheiße", ohne dass irgendwelche Details genannt werden. Ist doch völlig arm, findest du nicht?
-
Und das selbe gilt für Treiber. Natürlich kann man einen Treiber in C# schreiben. Und wenn ein Betriebssystem von Treibern eine bestimmte Schnittstelle erwartet, muss man sie erfüllen, dazu kann dann auch gehören, dass er als Native Code vorliegt. Alles kein Problem. C# ist nur ne Sprache. Ich muss schon sagen, mir ist eigentlich am Ende egal, wie mein Betriebssystem zustande gekommen ist und wahrscheinlich sind größte Teile von Windows Vista in C++ geschrieben. Trotzdem verwundert mich diese ohne-C-oder-C++-geht-es-nicht Ansicht stark.
-
Um es kurz zu machen gestehe ich meinen Fehler: Ich lese bei C# immer gleich C#/.NET inklusive VM, managed Code usw...
Dass das nicht korrekt ist ist mir klar. Aber eben dafür wurde C# entworfen. C# ohne VM, ohne .NET macht einfach wenig Sinn.Aber ja, mein Fehler. Mea maxima culpa.
-
heisst das ich kann mit c# programme schreiben die ohne der vm laufen?
gibts da wo dokus dazu die nicht nur akademisch interessant sind?
geht/ginge das auch mit mono?
-
Optimizer schrieb:
wenn man ein Betriebssystem schreibt benötigt man Assembler-Kenntnisse...
nicht unbedingt.
Optimizer schrieb:
Oder hast du schon mal ein Betriebssystem gesehen, dass zu 100% in einer Hochsprache geschrieben ist?
ja...
Optimizer schrieb:
Dass irgendwo C verwendet wurde, scheint mir eine Erfindung von dir zu sein.
guckst du: http://channel9.msdn.com/ShowPost.aspx?PostID=68302
(dritter kommentar)
-
ten schrieb:
Optimizer schrieb:
Oder hast du schon mal ein Betriebssystem gesehen, dass zu 100% in einer Hochsprache geschrieben ist?
ja...
Dazu gehört dann Interrupt-Behandlung, Einstellungen für den protected mode und die Sicherheitsringe, Schreiben des Dispatchers usw. das ist dir schon klar, oder? Welche Hochsprache hat Sprachmittel für solche Dinge? Ich glaube, in der untersten Schicht wirst du immer etwas Assemblercode finden, natürlich versucht man, das möglichst gering zu halten. Beispielsweise habe ich zu diesem Zweck* eine vorhandene C-Bibliothek verwendet, um mich nicht selber damit rumschlagen zu müssen. Ich würde aber darauf wetten, dass die in einer Assemblersprache geschrieben worden ist.
* EDIT: Der Zweck war nicht, ein BS zu schreiben, sondern unter DOS eigene Interrupt-Behandlungsroutinen anzumelden, was dort noch problemlos möglich war.
Optimizer schrieb:
Dass irgendwo C verwendet wurde, scheint mir eine Erfindung von dir zu sein.
guckst du: http://channel9.msdn.com/ShowPost.aspx?PostID=68302
(dritter kommentar)Ich verstehe den Satz wie folgt: Der Debugger, den Microsoft verwendet hat eine C-Schnittstelle, die erfüllt werden muss, damit sie ihr eigenes Betriebssystem debuggen können. Mir ist klar, dass sie keinen neuen Debugger entwickeln, nur um ein Forschungsprojekt voranzutreiben. Es scheint zumindest mir jetzt so, dass sie das gebraucht haben, um ihre Entwickler-Tools weiterverwenden zu können und nicht, um das Betriebssystem zu schreiben.
-
daHa schrieb:
heisst das ich kann mit c# programme schreiben die ohne der vm laufen?
gibts da wo dokus dazu die nicht nur akademisch interessant sind?
geht/ginge das auch mit mono?Es gibt NGen, ein Tool von Microsoft, dass native images erzeugt. AFAIK sind sie aber nicht grundsätzlich ohne VM lauffähig, sondern weiterhin auf das Vorhandensein der CLR angewiesen. Das ist für den Fall, dass deren Sicherheitseinstellungen geändert werden oder was zur Laufzeit hinzugelinkt wird und dient dann eher als Optimierung, damit nicht erst zur Laufzeit alles kompiliert wird.
Es gibt aber 3rd-Party Tools die völlig unabhängige Executables erzeugen. Vielleicht schreibt Microsoft auch irgendwo, was sie bei Singularity verwendet haben.
-
Optimizer schrieb:
ten schrieb:
Optimizer schrieb:
Oder hast du schon mal ein Betriebssystem gesehen, dass zu 100% in einer Hochsprache geschrieben ist?
ja...
Dazu gehört dann Interrupt-Behandlung, Einstellungen für den protected mode und die Sicherheitsringe, Schreiben des Dispatchers usw. das ist dir schon klar, oder? Welche Hochsprache hat Sprachmittel für solche Dinge? Ich glaube, in der untersten Schicht wirst du immer etwas Assemblercode finden, natürlich versucht man, das möglichst gering zu halten. Beispielsweise habe ich zu diesem Zweck* eine vorhandene C-Bibliothek verwendet, um mich nicht selber damit rumschlagen zu müssen. Ich würde aber darauf wetten, dass die in einer Assemblersprache geschrieben worden ist.
Entpsrechende Erweiterungen zum Interrupthandling beim Compiler voraussgesetzt geht da natürlich auch ganz ohne Assembler.
-
TactX schrieb:
Z.B. einen kleinen Microcontroller effizient programmieren. Oder halt genau die Teile die bei Singularity eben auch nicht schön in der warmen VM rennen.
Ich finde es witzig, dass du den Embedded Bereich anschneidest, nachdem Microsoft bereits vor einiger Zeit das .NET Micro Framework (siehe golem.de [1]) angekündigt hat, wobei ich es eher als Proof-of-Concept Projekt verstehe.
-
foobar aus dem Wald schrieb:
TactX schrieb:
Z.B. einen kleinen Microcontroller effizient programmieren. Oder halt genau die Teile die bei Singularity eben auch nicht schön in der warmen VM rennen.
Ich finde es witzig, dass du den Embedded Bereich anschneidest, nachdem Microsoft bereits vor einiger Zeit das .NET Micro Framework (siehe golem.de [1]) angekündigt hat, wobei ich es eher als Proof-of-Concept Projekt verstehe.
Ich verstehe nicht ganz was du da witzig findest. Die typischen ARMs sind imho weit davon entfernt klein zu sein, "512kb bis 1 MByte" ebenso.
Ich sehe das auch nicht unbedingt als "Proof-of-Concept". Sicher will MS schon länger in dem Markt expandieren. Aber wie gesagt, klein ist was anderes.
-
Optimizer schrieb:
ten schrieb:
Optimizer schrieb:
Oder hast du schon mal ein Betriebssystem gesehen, dass zu 100% in einer Hochsprache geschrieben ist?
ja...
Dazu gehört dann Interrupt-Behandlung, Einstellungen für den protected mode und die Sicherheitsringe, Schreiben des Dispatchers usw.
quatsch, guckst du hier: http://www.nilsenelektronikk.no/nenesos.html
-
Du hast jetzt ein "Betriebssystem" für embedded systems ohne Interrupts gefunden und das soll jetzt was beweisen? Inwiefern steht das in Zusammenhang mit Betriebssystemen, über die wir vorhin geredet haben? Wolltest du einfach nur irgendwas sagen, damit du mir ein saloppes "Quatsch" vorwerfen kannst?
Du kannst bei heute üblichen Desktop-Computern nicht auf Interrupt-Behandlung verzichten, die Interaktion mit I/O Geräten basiert darauf und präemptives Multitasking ebenfalls. Keiner will heute ein nicht-präemptives Multitasking auf seinem Desktop-Computer und I/O was vollständig auf Polling basiert frisst wertvolle CPU-Zeit. Das ist nur interessant bei embedded systems, wenn es vielleicht 1 oder 2 Kommunikations-Kanäle gibt.
Also nichts, was mit dem bis jetzt besprochenen Betriebssystemen zu tun hat (ich habe immerhin von Singularity, ein Betriebssystem für Desktop-PCs geredet). Hat dein "Beitrag" jetzt irgendeinen Sinn gehabt, wenn ja erkläre ihn.
-
Optimizer schrieb:
Hat dein "Beitrag" jetzt irgendeinen Sinn gehabt, wenn ja erkläre ihn.
vielleicht bewirkt er eine bewusstseinserweiterung bei dir, wenn du das nächste mal an betriebssysteme denkst? immerhin hat 'nesos' einen gewissen gebrauchswert im gegensatz zu 'singularity'.
btw: singularity ist doch der witz der woche. was wollen die damit beweisen? dass man einen elefanten durch die haustür kriegt wenn man nur oft genug auf ihn einprügelt? einfach nur lächerlich!
-
ten schrieb:
Optimizer schrieb:
Hat dein "Beitrag" jetzt irgendeinen Sinn gehabt, wenn ja erkläre ihn.
vielleicht bewirkt er eine bewusstseinserweiterung bei dir, wenn du das nächste mal an betriebssysteme denkst? immerhin hat 'nesos' einen gewissen gebrauchswert im gegensatz zu 'singularity'.
Btw. wären die Schwierigkeiten, ein BS nur in C# zu implementieren in deinem Beispiel noch viel geringer. Was das Bewusstsein angeht: Man kann diese Betriebssystem-Typen schlicht nicht vergleichen, da die Anforderungen völlig verschieden sind und ich wollte jetzt über die Software von embedded systems einfach nicht reden.
btw: singularity ist doch der witz der woche. was wollen die damit beweisen? dass man einen elefanten durch die haustür kriegt wenn man nur oft genug auf ihn einprügelt? einfach nur lächerlich!
Es geht hier um einen ganz anderen und möglicherweise effizienteren Ansatz, Sicherheit in Betriebssystemen zu erreichen. Sicherheit zu garantieren wird hier als Aufgabe der Software und nicht der Hardware (im speziellen der MMU) betrachtet. Dazu wird nur Code ausgeführt, der statisch oder durch von JIT-Compilierung eingebauten Prüfungen bewiesen werden kann, dass er andere Prozesse nicht verletzt. Diese Idee ist auch keineswegs neu (in einem Buch das mir vorliegt wird ein Textstück von 1995 zitiert) aber nicht realisierbar, wenn man so wie bis jetzt meistens der Fall ein C++ Programm schreibt und zu native Code übersetzt, den man dann direkt ausführen lässt.
Der Schutz von Prozessen durch die Hardware und die Kontextwechsel kosten Zeit, Zeit, Zeit. Vom Sicherheitsstandpunkt aus wäre es wesentlich geiler, µKernel zu schreiben, alle Treiber als Prozesse in einem eigenen Speicherbereich auszuführen und am besten selber nochmal unterteilen in Prozesse im Usermode und den Teil, der die Interruptbehandlung und andere potenziell böse Dinge macht. Trotzdem wird dies nicht getan. Singularity ist ein Ansatz für eine performante µKernel-Architektur, was dadurch ermöglicht wird, dass nicht die Hardware, sondern die Software den Speicherschutz garantiert und das Ausführen von nicht erlaubten Instruktionen verhindert. Und der Ansatz ist interessant.
In der Wikipedia steht auch ein kurzer Absatz dazu:
http://en.wikipedia.org/wiki/Kernel_(computer_science)#Security
-
Optimizer schrieb:
Der Schutz von Prozessen durch die Hardware und die Kontextwechsel kosten Zeit, Zeit, Zeit.
ja, aber nur weil dabei software aktiviert werden muss, die das ganze managed. die behandlung von page faults, context switches, etc. durch software frisst cpu-zeit, weil die hardware zu dumm ist.
Optimizer schrieb:
Und der Ansatz ist interessant.
nicht wirklich.
interessanter wäre ein konfigurierbares gate-array in (oder am) prozessor, in das man den scheduler und sicherheitsmechanismen wie speicherschutz beim start des betriebssystems hineinladen könnte. dann wäre es quasi bestandteil der hardware (obwohl austauschbar) und würde um zehnerpotenzen schneller sein, als alle softwarelösungen... aber auf sowas kommt ja keiner
da lassen sie lieber ein 'betriebssystem' bauen und benutzen dabei ihren lieblings-visual-basic-ersatz-und-java-nachbau, lassen die vm weg, und freuen sich: "wow, wir sind die computer scientists vor dem herrn, weil wir das hingekriegt haben, was jeder für unmöglich hielt".
eine killer application eben :p (den begriff hat m$ ja erfunden)...
:xmas2:
-
Das zur Zeit vorhandene Konzept hat bereits Jahrzehnte Zeit gehabt, sich immer weiter zu verbessern und das es nicht geil ist, sieht man doch. Der andere Ansatz ist es IMHO zumindest wert, ausprobiert zu werden, egal wie sehr dich das anscheinend frustriert.
interessanter wäre ein konfigurierbares gate-array in (oder am) prozessor, in das man den scheduler und sicherheitsmechanismen wie speicherschutz beim start des betriebssystems hineinladen könnte.
Der Speicherschutz ist bereits in Hardware gegossen (die Prüfung, die Behandlung von Speicherzugriffsfehlern sollte ja hoffentlich nicht zu häufig sein) und nen ordentlichen Scheduler halte ich für ein zu komplexes Stück Software, um es in ein Gate-Array zu laden, ganz abgesehen von der Vergleichsweise niedrigen Lebenszeit. Natürlich verfüge ich hier nicht das Expertenwissen von 50 Jahren Forschung und jeder weiß, dass in unserer Welt nicht alles so gut ist, wie es sein könnte. Trotzdem denke ich, dass man in diesem Bereich schon alles ungefähr so gut optimiert, wie es nur möglich ist. Ich glaube deshalb nicht, dass die Lösung für alle Probleme jetzt einfach ist, ein gate array hinzustellen. Alles in Hardware zu gießen wäre das schnellste, geht aber halt nicht.
Im übrigen hat ja auch der Ansatz von Singularity nicht nur Vorteile, aber den konkreten Vorteil, dass man keine aufwändigen Kontext-Switches braucht und eine schnelle Interprozesskommunikation hat muss man IMHO einfach mal anerkennen. Ich sag ja nicht mal, dass es praxistauglich ist - woher soll ich das denn wissen.