Hallo, ich möchte mich gerne in Embedded Linux einarbeiten und komme aber aus der Windows-Welt. Jetzt weiss ich nicht so richtig, wie ich einsteigen soll. Wäre es hilfreich zuerst mal Linux auf nem Rechner zu installieren und damit zu spielen oder direkt ein Eva-Board kaufen, auf dem ein Embedded Linux läuft? Wie sind da eure Erfahrungen bzw wie seid ihr das Thema angegangen? Grundlagen in Embedded Systems sind da (Programmierung in C, Atmel AVR, Elektronikgrundlagen). Gruß Mattes
Moin, es läuft deutlich schmerzfreier ab wenn du dich erstmal mit Linux auf einem normalen Rechner auseinander setzt. Alternativ kannst du auch Linux in einer virtuellen Maschine unter Windows installieren und damit die ersten Schritte machen. Gruss, Tobi
Es ist zum entwickeln sowieso von Vorteil auf dem Host auch ein Linux laufen zu haben (aber kein Muss). Ah ja kannst erstmal auch VirtualBox verwenden.
Habe mir heute morgen Ubuntu eingerichtet. Hab gelesen, dass es für den Anfang angebracht wäre aber da wird wohl jeder seine eigene Meinung haben.
Hab mich jetzt etwas mit Ubuntu beschäftigt und würd jetzt gern mal eigene Applikationen einbringen. Jetzt stellt sich natürlich die Frage wie ich das mache. Ich habe mal einen Roboter programmiert, auf dem ein portiertes OSEK lief. Da konnte ich meine Applikation schreiben, neu compilieren und den Roboter bzw den Prozessor neu flashen. Diese Vorgehensweise wird wohl eher schwierig bei Ubuntu. Wie stelle ich das nun an?
Für nicht in den Repositories verfügbare Programme mit dem Programm Checkinstall. Selbstgeschriebene einfache Programme braucht man zu Testzwecken nicht wirklich zu installieren sondern kann sie einfach so ausführen.
blubb schrieb: > Selbstgeschriebene einfache Programme braucht man zu > Testzwecken nicht wirklich zu installieren sondern kann sie einfach so > ausführen. Wow ! ;-)))
Auch wenn ich Ubuntu nicht schlechter reden will als es ist: Ubuntu ist für den Einstieg in die Linux-Welt sicherlich großartig, aber, ich denke, sobald man wirklich am System "herumfrickeln" möchte gibt es bessere Distributionen, welche das Ganze einfacher gestalten und bei denen sich die vom Macher betriebene Politik nicht ganz so stark in den Weg stellt wie es z.B. bei Ubuntu der Fall ist. Nennen möchte ich: Arch Linux, Gentoo und LFS (Linux From Scratch). Ganz klar: Alle drei sind "fortgeschrittene" Distributionen, die einen Anfänger bzw. Umsteiger sicherlich überfordern. Hat man aber das nötige Know-How, dann bieten sie einfach genau das was man will: Möglichst unverfälschte Software (Stichwort: Upstream), welche möglichst zeitnah bereit gestellt wird. Vor allem der "Build Process" also das Erstellen von Packages aus den ursprünglichen Quellen ist bei Arch und Gentoo sehr viel einfacher (und mächtiger) als bei Debian Derivaten à la Ubuntu. Übrigens: Wenn du wirklich im Embedded Bereich anfangen willst eignet sich LFS ganz hervorragend dazu herauszufinden wie die einzelnen Komponenten bei einem System zusammenarbeiten. Dieses Wissen lässt sich dann auch relativ einfach auf Embedded Devices ummünzen. Idealerweise hantierst du damit aber "bloß" in einer virtuellen Machine herum, dann hast du über das Hostsystem nämlich immer die Möglichkeit dir Informationen zum aktuellen Schritt/Problem zu beschaffen ;).
Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ? Programmieren kann ich den ja auch direkt in C oder Assembler. Dinge wie Benutzerverwaltung, Zugrifsrechte oder ein Filesystem sind für normale Anwendungen ja eigentlich kaum notwendig. Bei komplexeren Systemen (zB Fritzbox) sehe ich das ein ... Was bringt das gegenüber einer "direkten" Programmierung ?
Ich habe mir am WE mal Fedora eingerichtet, auch im Bezug auf den Raspberry Pi den ich mi evtl kaufen möchte. Also mir gehts am Anfang halt nur darum auf einem Embedded Linux Board eine LED zu schalten und Taster einzulesen
Zum Einstieg in embedded Linux kann ich dir das hier empfehlen: http://cross-lfs.org Es gibt auch fertige Distributionen speziell für embedded Linux: http://www.angstrom-distribution.org Ich würde das CrossLFS empfehlen. Ohne ein komplettes Verständnis, wie ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter.
Joachim Drechsel schrieb: > Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ? Ein OS bietet mehr als die von dir genannten Feature. Insbesondere halt auch eine (hoffentlich) vernünftige Prozessverwaltung. Durch Time-Slicing und Scheduler wird scheinbare Parallelität (bei 1-CPU Systemen) oder eben sogar echte Parallelität (bei Mehrkern-Architekturen) gewährleistet. Bei Mikrocontrollern hat man halt das Problem, dass ein vernünftiges Betriebssystem komplex und groß ist. Das findet auf gewöhnlichen Mikrocontrollern halt nur bedingt Platz. Außerdem lassen sich solch komplexe System auch nicht unbedingt einfach testen. Übrigens sind Filesysteme bei Mikrocontrollern doch öfter von Nöten als gedacht. Zumindest gibt es hier mehr als nur ein Projekt, bei welchem man FAT und ähnliches nachimplementiert. Mattes schrieb: > Also mir gehts am Anfang halt nur darum auf einem Embedded Linux Board > eine LED zu schalten und Taster einzulesen Klar, damit kann man anfangen, aber letztendlich braucht es dafür kein Linux ;). Das geht auch mit einem Mikrocontroller (bzw. sogar ohne ;)).
Unlucky2012 schrieb: > Ein OS bietet mehr als die von dir genannten Feature. Insbesondere halt > auch eine (hoffentlich) vernünftige Prozessverwaltung. Durch > Time-Slicing und Scheduler wird scheinbare Parallelität (bei 1-CPU > Systemen) oder eben sogar echte Parallelität (bei > Mehrkern-Architekturen) gewährleistet. Ab welcher Hardware lohnt sich der Aufwand ? Windows, Linux etc. sind ja als EWS ausgelegt, also Mädchen für Alles. Zentraler Bestandteil eines OS ist ja Starten und Verwalten von Prozessen - auf einem ATTiny2313 macht das im Prinzip ja der Reset- Vektor. Mit einer Maschine mit viel Speicher etc. brauche ich ja noch kein Filesystem, bekomme aber einiges drauf (auch ein einfaches OS). Wo wäre da die Grenze ab der sich ein OS lohnt ? Oder gibt es da feste Kriterien ? (Sorry. Ich kenne nur den Tiny und 6502, sonst nur PC-Erfahrung. Linux kann ich installieren - das war's dann aber auch ;)
Ich definiere mal OS im embeded bereich für mich so. Eine lose sammlung von rotinen für die Mehrläufige Programmierung und deren Synchronisationsmittel. Mehrläufig: Threads, Prozesse, ... je nach dem wie man sie nennen will. In Kleinen systemen eher Threads vergleichbar, da es keine MMU gibt die die Prozesse vor gegenseitigen Speicherzugriffen schützt. Jeder Thread hat zugriff auf den ganzen speicher. Synchronisationsmittel: Maseges, Semaphoren, Queues, ... alles was man so braucht um die threads synchron zu halten und zwischen ihnen zu kommunizieren. Je nach OS können das verschiedene sachen sein. teilweise auch sehr spezielle dinge die es so nicht grossen os gibts. wozu man sowas braucht? es gibt aufgaben da braucht man sowas nicht problem wird durch eine einfache loop erschlagen, in irgendwelche irqs ausgelagert. und es gibt sachen da währe es sinvoll, bzw vorteilhaft sowas zu verwenden. z.B. auf Tasten input warten, auf dem display irgend was animieren, zusätzlich noch nen stepper drehen, auf der RS232 auf input warten, über SPI zyklisch irgend was wegschreigen, ...
Ich glaube kaum, dass dir jemand genaue und konkrete Werte liefern kann, ab wann sich ein Betriebssystem lohnt. Das kann man wohl nur allgemeiner beantworten. Und eine solche Antwort würde wohl eher lauten: Es kommt auf die Anforderungen an. Spontan und kaum durchdacht würde ich sagen, dass man über den Einsatz eines Betriebssystems erst nachdenken sollte, wenn man weiß, dass man mehrere Prozesse benötigt, welche sich nicht auf unterschiedliche Mikrocontroller aufteilen lassen, beispielsweise ein multimediales System. Und diverse Projekte hier im Forum zeigen, dass auch solche Systeme sich mit den klassischen Formen der Mikrocontroller-Programmierung in den Griff bekommen lassen. Übrigens gibt es hier im Forum schon den ein oder anderen Ansatz für Betriebssysteme auf Mikrocontrollern. Meiner Einschätzung nach handelt es sich aber mehr oder weniger um Proofs-of-Concept bzw. "Just for Fun" Projekte. Produktiv einsetzen würde ich wohl keines davon. Deinen Vergleich zwischen Betriebssystem und dem Reset-Vektor verstehe ich nicht so ganz. Der "Reset-Vektor" ist ja bloß eine Adresse, welche beim Neustart "angesprungen" wird. Da wäre wohl eher ein Vergleich mit dem MBR (Master-Boot-Record) bei einem klassischen PC richtig. Ein Betriebssystem, welches "echte" Prozessverwaltung anbietet, bietet viel mehr als nur die Möglichkeit das komplette System neu zu starten. Hier kann man - je nach Implementierung - einzelne Prozesse starten, stoppen, auslagern, einlagern, warten lassen, etc. Im Idealfall gibt es dann noch ein Threadkonzept, sodass einzelne Prozesse zum Teil auch parallelisiert werden können. Ein Betriebssystem bietet dann auch noch die Möglichkeit der Kommunikation zwischen den Prozessen an, z.B. Speicher- bzw. Nachrichtenbasiert. Wie schon gesagt: Bei den typischen Mikrocontrollern wäre ein vernünftiges Betriebssystem einfach nicht unterzukriegen. Weder vom Flash her, noch vom Arbeitsspeicher. Außerdem fehlt Hardware, welche sich bei anderen Architekturen etabliert hat, wie z.B. ein Interrupt Controller, um das Ganze brauchbar implementieren zu können. Des Weiteren ist es ein um Größenordnungen komplexeres Problem, sobald man Echtzeit-Anwendungen hat. Während man bei einem Mikrocontroller "recht" einfach sicherstellen kann, dass die Verarbeitung schnell genug passiert, ist das bei einem (komplexen) Betriebssystem nicht mehr der Fall, weil im Hintergrund haufenweise andere Prozesse laufen, die für das Wohl des Systems sorgen. I.d.R. lässt sich die Reihenfolge, in welcher diese bearbeitet werden nicht vorher bestimmen. Hier sind dann die Worst-Case Szenarien (nämlich das so ziemlich alles dazwischen funkt, was dazwischen funken kann) einfach viel schlimmer, als bei einem "einfachen" Mikrocontroller, wo man i.d.R. mit einigen an einer Hand abzählbaren Interrupts arbeitet.
Unlucky2012 schrieb: > Deinen Vergleich zwischen Betriebssystem und dem Reset-Vektor verstehe > ich nicht so ganz. Er hinkt auch ein wenig. Prinzipiell startet der Reset-Vektor aber auch einen Task. Zusammenfassend liegt die Grenze, ab der sich ein OS lohnt (zB um die Komplexität der HW/SW in den Griff zu bekommen bzw die Programmierung zu vereinfachen) bei einer Mindesthardware. Ich vermute, da gibt es dann eine finanzielle Abwägung (zusätzliche HW-Kosten für den Einsatz eines OS gegenüber den Mehrkosten für die Programmierung) bei Einsatz billigerer Hardware.
Kleine OS systeme brauchen nicht wirklich viel an resourcen. ein paar KB flash und ein paar kB ram. Nach kurzem Google, für die AVRs z.B. FemtoOS 1-4K Flash 2K ram
Es gibt ja jetzt einige Antworten aber wir sind etwas vom Thema abgekommen. Der Grund warum ich in Embedded Linux einsteigen will ist, dass es mich zu einem interessiert und ich gern später in diesem Bereich arbeiten würde. Daher ist es sicherlich nicht verkehrt, wenn man ein paar Projekte vorzeigen kann.
_\|/_ schrieb: > Ohne ein komplettes Verständnis, wie > ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter. Ja, genau, mann muss den gesamten Kernel, alle Programme und Daemons bis auf das letzte Byte genau kennen, ansonsten kommt man unter Linux nicht weiter. Sorry, aber das ist einfach nur unsinniges, elitäres Gehabe. So fern er nicht gerade einen Server ins Internet stellen will, reichen auch ein paar Grundlagen, so dass er prinzipiell klar kommt. Und bei echten Problemen ist die Community mehr als hilfsbereit.
Wooog schrieb: > Sorry, aber das ist einfach nur unsinniges, elitäres Gehabe. Naja, so abwegig finde ich das gar nicht. Klar muss man nicht "jedes Byte" kennen, aber man sollte schon wissen wie die einzelnen Systeme und Komponenten funktionieren und miteinander kommunizieren. Das Installieren bzw. Betreiben einer Distribution wie Ubuntu jedenfalls vermittelt dieses Wissen wohl nicht. Daher wurde ja oben auch auf LFS (bzw. CrossLFS) verwiesen.
und es geht hier weder um Desktop noch um server. Bei embedded sollte man schon wissen was man da tut. wie man bootet, was man an diensten braucht, in welcher reihenfolge diese zu starten sind, ... und embedded heist zumindest sehr oft auch am kernel hand anlegen zu müssen. Welche treiber brauch ich will ich muss ich haben. als modul oder im Kernel, ggf an welchem pin hängt was dran, fehlende featers nachimplementieren / anpassen, ...
Mattes schrieb: > Der Grund warum ich in Embedded Linux einsteigen will ist, dass es mich > zu einem interessiert und ich gern später in diesem Bereich arbeiten > würde. Daher ist es sicherlich nicht verkehrt, wenn man ein paar > Projekte vorzeigen kann. Du könntest auch mit dem Gnublin anfangen. Beitrag "GNUBLIN www.gnublin.org" Da wird auch aktiv hier im Forum entwickelt. Der Raspberry Pi/Beagle-Board/Panda-Board/Mini6410/STM32-Discovery/weiß-der-Geier kann auch noch später kommen. ;-) Lies dir den Thread mal durch und wann es den Raspberry Pi gibt, weiß wohl keiner. Und vor allem weiß man nicht wann man ihn bekommt.
Ja das habe ich schon alles gelesen. Wie gesagt ich arbeite gerade etwas mit Fedora um mir die Grundlagen im Umgang mit einem Linux-System zu erarbeiten.
Joachim Drechsel schrieb: > Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ? Erstmal gar keinen Vorteil... es sei denn: a) das betreffende BS bietet Dienste, die man sonst nur mühselig zu implementieren imstande ist, bzw. die mehr Mannstunden erfordern, als man selber hat. Beispiele: ein Filesystem bieten, ein GDI bieten das mit komplizierter Grafikhardware umgehen kann, komplizierte Dinge für einen erledigen wie TrueType skalieren, Jpeg dekodieren und skalieren, ein Menü mit Z-Ordnung bieten, eine Eventverwaltung bieten, Standardhardware (V24, USB usw.) verwalten und so weiter. Das sind alles Dinge, die man auch selber machen kann, aber die in Form eines sauber auf die betreffende Hardware abgestimmten BS einem sehr viel Arbeit abnehmen, so daß man sich auf sein eigentliches Problem konzentrieren kann. b) wenn man zu blöd ist, seine Firmware so zu planen und so zu schreiben, daß sie funktioniert ohne sich selber zu blockieren, dann ist so ein Scheduler mit preemptivem Multitasking offenbar hilfreich. Man kann dabei aber auch kapitale Böcke schießen und darauf sogar noch stolz sein. Lest euch mal Adam Dunkels (Contiki et. al.) tolle Erfindung der "Protothreads" durch. Ein Tollhaus. Und nochwas speziell zu Linux: _\|/_ schrieb: > Ohne ein komplettes Verständnis, wie > ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter. Deshalb ist ja auch Windows CE besser, weil eben besser durchdacht: Man braucht eben nur das API zur Kenntnis zu nehmen, also die dokumentierte Schnittstelle zur Anwendungssoftware. das "komplette Verständnis" wie das BS eigentlich funktioniert, also wie es all die Aufgaben erledigt, die dahinter stecken, braucht man nicht zu pauken. Es gibt das API, worauf man sich verlassen kann. Das ist bei Linux alles anders, da wird vom Anwendungsprogrammierer verlangt, daß er sich um die Innereien des BS Gedanken machen soll. Eigentlich ne Dreistigkeit, sowas. Ein BS sollte seinem Benutzer (wozu vor allem erst mal der Anwendungsprogrammierer zählt) Dienstleistungen und Sicherheit in Form eines verläßlichen API bieten - und ihn nicht dazu auffordern, erstmal alle Innereien verstehen zu sollen. W.S.
W.S. schrieb: > Es gibt das API, > worauf man sich verlassen kann. Das ist bei Linux alles anders, da wird > vom Anwendungsprogrammierer verlangt, daß er sich um die Innereien des > BS Gedanken machen soll. Ich lehne mich mal ein wenig aus dem Fenster: Warum sollte sich ein Anwendungsprogrammierer im Falle von Linux "Gedanken um die Innereien des BS" machen? Ich behaupte ja mal, dass dies z.B. im Falle von Android nicht der Fall ist. Und mir ist klar, dass hier noch Java (bzw. eine Abwandlung davon) mit von der Partie ist. Aber ich glaube du hast hier den Fehler gemacht und den Anwendungsprogrammierer mit demjenigen verwechselt, der das Ganze System zusammenbaut und das Betriebssystem darauf zum Laufen bringt. Der Threadersteller ist aber genau daran interessiert. Da muss man wohl auch auf Seiten von Windows CE entsprechendes Vorwissen mitbringen. Und ich behaupte jetzt einfach mal, dass es nicht unbedingt transparenter als im Falle Linux ist. Der Unterschied für den Anwendungsprogrammierer liegt höchstens darin, dass man im Falle von Linux (bzw. *nix) halt direkt mit den entsprechenden System Calls arbeitet, während man bei Windows CE über die von Microsoft bereitgestellt API auf Ressourcen, die das Betriebssystem verwaltet, zugreift. Wie diese API letztendlich implementiert ist, spielt dann keine Rolle mehr. Diese kann sich sogar problemlos von Zeit zu Zeit (bzw. von Version zu Version) ändern ohne das Verhalten von Anwendungen (fundamental) zu beeinflussen. Dem Anwendungsprogrammierer dürfte das wohl ziemlich egal sein, solange es eine vernünftige Dokumentation gibt. Hinzu kommt, dass viele Anwendungsprogrammierer sowieso weder mit der von Windows bereitgestellten API noch mit System Calls im Falle von Linux zu tun haben. Das wird bei entsprechenden Hochsprachen einfach "wegabstrahiert".
Karol Babioch schrieb: > Dem > Anwendungsprogrammierer dürfte das wohl ziemlich egal sein, Wie bitte? Du hast ne seltsame Sichtweise, die ich nicht teile. Vielleicht liegt das an deiner Auffassung davon, was ein Anwendungsprogrammierer ist. Vielleicht meinst du Leute, die im Wesentlichen nur Scripte schreiben - oder etwas mit den in diverse Anwendungen eingebauten Programmiermöglichkeiten machen, wie z.B. VBA für MS-Office-Programme oder ULP für Eagle oder LUA und so weiter. Ich rede hier von Anwendungen wie z.B. die Betriebssoftware für nen Spektrumanalyser oder ein Industriemeßgerät irgendeinen speziellen Zweck und dergleichen. Vor etwa 10 Jahren gab's mal ne Austauschaktion bei Agilent: Da konnte man sich seinen Oszillografen updaten lassen: von Win98 auf WinXP. Bloß damit du mal nen Eindruck bekommst, wo überall Windows drin ist und was die dort aufsetzende Anwendungsprogrammierung beinhaltet. Es ist hier zwar offtopic, aber ich erwähne es doch, damit du verstehst, was ich meine: Ich hatte vor vielen Jahren mir eine Applikation mit EVC für meinen Jornada geschrieben (WinCE3) und exakt dieses Programm - auf linuxisch dasselbe Binary, also exakt dieselbe EXE läuft anstandslos auf dem Colibri-Board (mit embedded Windows 7 drauf) von der letzten Messe. Auf allen Versionen zwischendurch (WinCE 4.2, 5.0, WinMobile 6.5) läuft es auch. Der Grund dafür ist, daß das API von Windows CE bzw. Mobile eben ein verläßliches API ist, egal wie sehr sich das Innere des BS inzwischen weiterentwickelt hat. Naja, sowas setzt natürlich einen gewissen Weitblick bei der Definition des API voraus - bei Microsoft vorhanden, bei der Linuxgemeinde nicht. Ich versuche es nochmal ein bissel zugespitzt und provokativ: Zeig mir doch bitte mal die Datei "linux.h", mit deren Einbindung ich dann eine - selbstverständlich grafische - Anwendung schreiben kann, die auf allen Linuxen gleichermaßen gut läuft, egal ob dieses Linux nun 10 Jahre alt ist oder brandneu oder ob grad KDE oder Gnome oder ne andere Oberfläche dabei ist. Geht nicht? Richtig, geht nicht! Natürlich hat man es als Anwendungsprogrammierer mit dem API (Application Program Interface) des BS zu tun - und zwar sehr. Selbst wenn man mit Delphi oder Visual Basic Anwendungen schreibt, kommt man nicht um das API herum - es sei denn, man schreibt nur sehr simple Dinge, die kaum über das "Hello World" hinauskommen. Das Framework nimmt einem ne Menge an Oberflächengestaltung und Ereignisbehandlung ab, aber nicht den eigentlichen Nutzinhalt. Aber zurück zum Thema der embedded (RT)OS'se: Entweder ist ein Betriebssystem sehr viel mehr als nur so ein jämmerlicher Scheduler, dann bietet es dem Schreiber der Firmware für das betreffende Gerät auch Leistungen, die den Einsatz lohnend machen - oder - es ist eben nur ein mehr oder weniger jämmerlicher Scheduler, der mehr an Aufwand erzeugt als er an Nutzen bringt. Ich denke, wir hätten's damit abgehandelt, was die RTOS'se betrifft. Tja, und zum eigentlichen Thema von Mattes: wenn es ne klare und überschaubare Sache wäre mit dem Embedded Linux, dann würde ich mich auch dafür interessieren. Klar heißt in diesem Fall: Läßt sich mit Keil für ARM's oder Softune für Fujitsu's unter Windows compilieren und kommt mit dokumentiertem API und ner Doku über das zu schreibende BSP nebst zu schreibendem Loader - eben so wie WinCE. Auf den Platformbuilder könnte man ja notfalls verzichten und alles zu Fuß tun (wie unkomfortabel!) aber sowas wie Shellskripte oder gar zwangsweise Benutzung von GNU sind außen vor. Ich hatte diese bescheuerte Diskussion schon mal mit den Jüngern von ECOS, die auch die große Klappe hatten, aber es immer noch nicht fertig gebracht haben, die Compiler von Fujitsu benutzen zu können. W.S.
Mit dem Windows-API habe ich genug zu tun. Es dürfte, sollten da mal die Quellen offengelegt werden, den Tod der Open-Source-Bewegung begründen (die Junks lachen sich tot). Was MS da zusammenstoppelt ist schlicht ein Witz. Soweit es irgendwie geht vermeide ich Windows-API-Aufrufe, den irgendwann einmal fälligen Umstieg auf Linux oder ein andereres OS verbaue ich mir möglichst nicht. Zum Thema IDE ist eigentlich nur zu bemerken, ein makefile tut es völlig. Ähnlich der Compiler, er hat den Code zu übersetzen - sonst nichts. Ich verwende C als Werkzeug um meine Ideen maschinenkompatibel zu machen, mehr macht das nicht. Das ganze Bling-Bling drumherum, wer's mag ... Richtig nervig sind allerdings falsche bis sehr lässige Dokus über APIs. Da tut sich MS auch nicht gerade hervor. Mit Linux habe ich mal gespielt, bin aber da (leider) noch nicht so weit da mitreden zu können. Es ist aber Opensource, dh ich habe zumindest die theoretische Chance mal nachzusehen was ein Aufruf überhpaut macht. Ich finde, die MS-Sources sollten zwangsweise veröffentlicht werden (schon aus Sicherheitsgründen. Weiß wer, was so in der "Cloud" passiert ?).
W.S. schrieb: > Vielleicht liegt > das an deiner Auffassung davon, was ein Anwendungsprogrammierer ist. Ich gebe zu, dass dieser Begriff sehr weit gefasst werden kann. Allerdings wirst du nicht von der Hand weisen können, dass eben auch der "typische" Android-App-Entwickler ein Anwendungsprogrammierer ist. Und der muss nun mal nicht wirklich etwas vom Betriebssystem verstehen, um eine "Standard"-App zu schreiben. Klar kann man den Anwendungsprogrammierer auch am anderen Ende ansiedeln und als jemanden definieren der Bibliotheken für Hochsprachen schreibt. Spätestens dann bedarf es Wissen um das Betriebssystem. W.S. schrieb: > Der Grund dafür ist, daß das API von Windows CE bzw. > Mobile eben ein verläßliches API ist, egal wie sehr sich das Innere des > BS inzwischen weiterentwickelt hat. Ich formuliere es mal ein wenig produktiv und als Frage: Vielleicht hat sich das Innere des BS gar nicht so viel weiter entwickelt ;). W.S. schrieb: > Naja, sowas setzt natürlich einen > gewissen Weitblick bei der Definition des API voraus - bei Microsoft > vorhanden, bei der Linuxgemeinde nicht. Das ist der Satz in deinem Beitrag mit dem ich meine größten Probleme habe. Auch bei Linux verändert man nicht aus Spaß an der Freude die API (sofern man das so nennen mag). Allerdings ist man nicht so versteift darauf, die Welt als Konstante zu definieren wie es eben Microsoft tut. Die Leute aus Redmond sind doch tatsächlich der Meinung, dass sie plattformübergreifend (Windows, Windows CE und was es noch so für Auswüchse im Laufe der Geschichte Microsofts gab) jedem eine in Stein gemeißelte API anbieten können. Das ist - zumindest meiner Erfahrung nach - einfach nicht möglich sobald ein System komplexer wird. Und ein Betriebssystem ist nun mal verdammt komplex. Klar kann man durch entsprechende Weitsicht unnötige Änderungen auf ein Minimum begrenzen, aber ab einem gewissen Punkt hindert es einfach nur noch den Fortschritt. Ich denke, wenn man sich die Entwicklung von Windows im Vergleich zu Linux ansieht (und ich rede jetzt bloß vom Kernel), dann kann Linux in puncto unterstützte Architekturen und angebotene Features über die Zeit hinweg ganz getrost als Gewinner bezeichnen. Klar geht damit ab und zu ein Bruch der API einher. Dafür gibt es im Vergleich zu Windows aber echten und schnelllebigen Fortschritt innerhalb des Kernels. Als Beispiel sei das Dateisystem genannt. Während Windows nach wie vor auf NTFS als Standarddateisystem setzt, welches laut Wikipedia bereits 1993 (!) eingeführt worden ist, hat sich bei Linux einiges getan. Erst mit Windows 8 wird es ein neues Dateisystem geben. Und man mag es kaum glauben: Damit einher geht ein Bruch in Sachen Kompatibilität. Und das sogar bei einem "stinknormalen" Dateisystem, welches sich über VFS (https://en.wikipedia.org/wiki/Virtual_file_system) wunderbar abstrahieren lässt. Und zum Thema Microsoft und Weitsicht. Microsoft hat es in seiner unendlichen Weitsicht doch tatsächlich geschafft, dass das komplette Grafiksystem im Kernel-Modus läuft, um sein damals schon langsames Betriebssystem "aufzupeppen". Die Moral von der Geschichte: Jede Menge Exploits in Form von "manipulierten" Grafikdateien. Durch die simple Darstellung eines Icons kann der komplette PC "übernommen" werden. Nicht zuletzt wurde das z.B. von Stuxnet ausgenutzt. Gerade in Bezug auf Security kann man Microsoft wohl keine besondere Weitsicht zuschreiben. Auch wenn du hier versuchst uns Konstanz als das Beste überhaupt unter zu jubbeln und ich zugeben muss, dass eine gewisse Konstanz eine gewisse Attraktivität ausstrahlt, kann eben niemand (nicht einmal Microsoft) in einem so schnelllebigen Umfeld wie der Informatik (insbesondere unter dem Aspekt der Betriebssysteme) eben jene Konstanz gewährleisten ohne sich lächerlich zu machen. Dafür bräuchte man Glaskugeln um in die Zukunft blicken zu können. Und selbst das würde nicht viel bringen. Viele der heute eingesetzten Techniken wären noch vor einigen Jahren überhaupt nicht denkbar gewesen. Unter anderem aufgrund von fehlendem Arbeitsspeicher, fehlender Rechenkapazität und vielem mehr. Wer hätte schon vor 20 Jahren darauf gesetzt, dass jeder x-beliebige Rechner etliche Gigabyte an RAM mitbringt und eine einzige Applikation mehr als 4 Gigabyte an Arbeitsspeicher in Anspruch nehmen möchte. Microsoft jedenfalls nicht, sonst hätten sie nicht 2 Gigabyte pro Prozess für das Betriebssystem reserviert, sodass dem eigentlichen Prozess nur 2 Gigabyte übrig bleiben. Erst durch einen nachträglichen Eingriff lässt sich dieses Verhältnis auf 3 zu 1 reduzieren. Inwiefern also nennst du das Weitsicht? Da gefällt mir der evolutionäre Verlauf von Linux deutlich besser. Manchmal kommt es eben zu Änderungen. Die lassen sich - davon bin ich fest überzeugt - auch gar nicht verhindern. Sonst behauptet man etwas von sich, dem man nicht gerecht werden kann. W.S. schrieb: > Zeig mir doch bitte mal die Datei "linux.h", mit deren Einbindung ich > dann eine - selbstverständlich grafische - Anwendung schreiben kann, die > auf allen Linuxen gleichermaßen gut läuft, egal ob dieses Linux nun 10 > Jahre alt ist oder brandneu oder ob grad KDE oder Gnome oder ne andere > Oberfläche dabei ist. Geht nicht? Richtig, geht nicht! Vermutlich hast du recht. Das könnte schwierig bis unmöglich werden. Auf der anderen Seite: Wieso sollte man aktuelle Systeme und "uralte" Systeme gleichermaßen unterstützen. In den zehn Jahren hat sich in Sachen Hardware eben einiges getan. Ich z.B. finde Entscheiden "Altbalast" abzuwerfen i.d.R. gut. So unterstützt das neuste GNOME bzw. KDE eben nicht mehr alle Grafikkarten. Dafür kann ich Designentscheidungen treffen, die mir sonst verwehrt blieben. Unter anderem eben 3-D Funktionen von Anfang an. Übrigens ist es im Falle Windows doch nicht anders. Jede halbwegs aktuelle Anwendung benötigt mindestens Windows XP. In vielen Fällen dann auch noch in gepatchter Form, SP 2 aufwärts. Wenn alles so utopisch wäre, wie du es uns hier aufzeigst, dann müssten doch auch sämtliche Vorgänger unterstützt werden ;). W.S. schrieb: > Natürlich hat man es als Anwendungsprogrammierer mit dem API > (Application Program Interface) des BS zu tun - und zwar sehr. Wie gesagt: Es kommt wohl auf die Sichtweise bzw. Definition eines Anwendungsprogrammierers an. Sobald man Sprachen wie Java und Skriptsprachen wie z.B. Python nutzt, wird eben vieles (bzw. alles) verborgen. Und gerade mit diesen beiden Sprachen lässt sich doch einiges anstellen. Übrigens möchte ich noch anmerken, dass Linux das mir einzig bekannte Betriebssystem ist, welches von "ganz klein" bis "ganz groß" eingesetzt wird. So hat es seinen festen Platz in der Welt der eingebetteten Systeme gefunden. Unter anderem eben in unseren Smartphones und Routern. Platz hat es gefunden auf unseren PCs. Weiter geht es über "normale" Server bis eben hin zum High-Performance Computing (HPC). Und das alles mit der selben Codebasis, im Prinzip ganz ungewollt und vor allem ohne Zwang. Das nenne ich persönlich Erfolg! Vor allem aber sagt es mir, dass Linux genau das richtige Entwicklungsmodell umsetzt. Windows hingegen hat seinen Stammplatz auf PCs. Selbst bei "normalen" (d.h. typischen) Servern wird Windows schon stark (bis komplett) von anderen dominiert (hauptsächlich eben Linux). Im HPC Bereich hat Microsoft absolut gar nichts zu bieten. Windows HPC Server ist im Besten Fall ein Witz. Ernst nehmen kann man es jedenfalls nicht. Und selbst das von dir so gelobte Windows CE teilt mit dem "großen" Windows nicht wirklich etwas - zumindest aber keine gemeinsame Codebasis. Und ich will jetzt hier Linux gar nicht besonders toll und super aussehen lassen. Aber deine Aussagen bedurften einfach einiger Gegenargumente. Was die Vielfalt von Werkzeugen in der Open-Source Welt angeht: Gerade das ist doch das Schöne. Mag sein, dass es den Einstieg erschwert, aber dafür bieten sich halt Möglichkeiten, die man mit "Schema F" nicht hinbekommt. Ich jedenfalls halte den o.g. Umstand, dass man Linux "überall" findet für keinen Zufall!
wer linkt den unter linux direkt gegen die linux.h / pardo includiert diese? vermutlich die wenigsten. ausser du willst wirklich irgend welche hw mehr oder weniger direkt ansprechen. dann sind vermutlich noch einige andere header files notwendig sowie kentnisse darüber was der treiber da eigentlich haben will. unter linux heist das zauberwort posix. und das Programme von vor 10 jahren ohne murren laufen spricht auch nicht gerade für sich. kann nur zwei (drei) sachen bedeuten. Die API hat sich in der zeit nicht weiterentwickelt, und nichts neues ist dazugekommen. Es wurden immer nur dazugepackt und versucht auf teufel komm raus an den alten ggf mitlerweile total überholten verkorksten schnittstellen am laufen zu halten. oder deine Anwendung setzt nur auf den teil der API auf der sich in der zeit nicht verändert hat. und die schnittstellen M$ kenn ich nur vom Desktop. aber dort gibt es teils kleine aber feine unterschiede zwischen den Versionen (z.B. Vista W7 bzw 32 64)
Joachim Drechsel schrieb: > Es dürfte, sollten da mal die Quellen offengelegt werden, den Tod > der Open-Source-Bewegung begründen (die Junks lachen sich tot). > Was MS da zusammenstoppelt ist schlicht ein Witz. Auch wenn ich mich mit Windows und der API viel zu wenig auskenne, gefällt mir die Vorstellung doch recht gut ;). Joachim Drechsel schrieb: > Richtig nervig sind allerdings falsche bis sehr lässige Dokus über > APIs. Da tut sich MS auch nicht gerade hervor. Wie gesagt: Ich habe kaum Erfahrung mit Windows und der dazugehörigen API. Aber ich habe kein Problem damit Microsoft einzugestehen, dass ihre Dokumentation brauchbar ist. Jedenfalls habe ich keine negativen Erfahrungen damit gemacht. Ganz im Gegenteil. Joachim Drechsel schrieb: > Ich finde, die MS-Sources sollten zwangsweise > veröffentlicht werden (schon aus Sicherheitsgründen. Weiß wer, was > so in der "Cloud" passiert ?). Das ist aber ein fundamental anderes Problem. Was in der "Cloud" passiert weißt du sowieso nicht. Ob da nun Open-Source-Software eingesetzt wird oder nicht. Aus dieser Perspektive betrachtet ist das Modewort "Cloud" sowieso höchst problematisch. Wobei ich die Grundidee für absolut richtig halte. Gerade bei Behörden und ähnlichen Institutionen sollte Open-Source-Software verpflichtend sein. Zum Glück gibt es Bestrebungen wie LiMux, welche sich hoffentlich über kurz oder lang bezahlt machen und dafür Sorge tragen, dass das ganze Thema breiter und öfter diskutiert wird. Die Vorstellung das unsere Daten über Systeme laufen, welche nicht überprüft werden können (und vor allem dürfen) halte ich in gewissem Maße für angsteinflößend.
zur Docu M$: solange es sich um Sachen handelt die jeder braucht kann ich da durchaus zustimmen. sobald es aber exotisch wird fangen die Lücken an. da dient dann nur noch ein Kommentar in einer Header file aus dem DDK als hinweis was das "ding" bedeuten könnte, bis zu nicht dokumentierten wegen aus dem netz irgend ein Problem zu lösen, bis zu kommentaren im netz das man das was sich m$ an der stelle gedacht hat leider nicht so funktioniert und man das doch am besten gleich vergessen sollte.
Es gibt seit Jahren ja einige böse Zungen, die wagen zu behaupten, dass Windows gar kein OS ist. Wie auch immer, es gibt bei Windows (inkl. CE und Konsorten) einige Dinge, die nicht ins Kernel gehören. Im Konzept eines Kernels gibt es keine "linux.h". Genau die klare Trennung von Userspace und Kernel verbietet das. Wie ja schon jemand gesagt hat: Stichwort Posix, Filesysteme und ioctls. Meinetwegen auch Erweiterungen wie /proc, sys, usw. Ist alles gut dokumentiert, und funktioniert seit Jahren um vielfaches portabler als der Microsoft-Kram. Ich muss auch nicht anfangen, irgendwelche Plattform Kits zu installieren, mit denen der Compiler dann doch nicht richtig tut, nur um eine andere ARM-Architektur zu unterstützen. Es mag geunkt werden, dass unter Linux ein gewisser Wildwuchs an grafischen Oberflächen herrscht. Dem gegenüber steht aber wiederum Android mit einer sehr klaren API. So kann sich auch jeder entscheiden, welches Toolkit für ihn das beste ist und muss sich nicht durch Windows-Geschlurf wie MFC einschränken lassen. Wenn es um Design stabiler Systeme geht, die nicht abstürzen sollen, kann ich von WinCE einfach nur abraten. Das Konzept ist aus vieler Sicht "broken by design". Vielleicht für einen PC-User nicht von Bedeutung, aber für ein medizinisches Gerät schon...
> Wenn es um Design stabiler Systeme geht, die nicht abstürzen sollen, > kann ich von WinCE einfach nur abraten. Das Konzept ist aus vieler Sicht > "broken by design". Vielleicht für einen PC-User nicht von Bedeutung, > aber für ein medizinisches Gerät schon... Da muss ich aber erst recht von Linux abraten. Mattes (Gast) - wenn es nicht sein muss, dann mache diskret weiter oder spiele etwas mit VM herum. Davon bekommst Du keine grauen Haare... Embedded Linux als Einstieg - viel Spaß.
Strubi schrieb: > Wenn es um Design stabiler Systeme geht, die nicht abstürzen sollen, > kann ich von WinCE einfach nur abraten. Nanana, mein Lieber. Mein steinalter Organizer mit WinCE 3.0 drauf läuft nun schon seit Jahren ohne Unterbrechung durch und das mit täglicher Nutzung einschließlich Ausprobieren von selbstgeschriebenen Anwendungen. Die blöde DSL-Box hingegen, wo angeblich ein Linux drin werkelt, muß ich gelegentlich mal von der Steckdose trennen, weil sie schlichtweg abgestürzt ist. Soviel zum Thema Stabilität. Ist aber hier nicht das Thema. Wir reden doch eigentlich über das Entwickeln von Anwendungen - oder nennen wir es mal lieber Firmware für Mikrocontroller. Sowas kann man selten bis nie nativ auf dem Zielsystem tun, sondern man benutzt zumeist einen PC, wo die Firmware für das Zielsystem geschrieben und übersetzt wird, um dann in das Zielsystem "gebrannt" zu werden. Gelle? Sachlich ist es dabei völig wurscht, ob man dafür nen MAC, nen Windows PC, ne HP-Unix-Station oder nen Linux-Rechner benutzt. Hauptsache, man hat den/die Compiler für den eigentlichen Code, Linker nebst Bibliotheken für das Zielsystem, Ressourcen-Zeug für alles Grafische usw. auf der betreffenden Entwicklunsplattform vorhanden. Also, auf meinem hier nicht näher bezeichneten Rechner habe ich das alles (von Fujitsu) vorhanden. Es müßte also ausreichen, das dokumentierte API des gewünschten Betriebssystemes in den Quellen der Anwendung zu benutzen. Solche Beiträge wie: _\|/_ schrieb: > Ohne ein komplettes Verständnis, wie > ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter. sind eigentlich nur ne Offenbarung des Pfusches. Wenn ich z.B. auf dem Screen ein Rechteck mit Farbe füllen will, dann brauche ich dazu den passenden (dokumentierten) API-Aufruf. Wie der im Inneren des BS funktioniert, ist Obliegenheit des Betriebssystem-Schreibers. Pfusch ist, wenn man ein BS in die freie Wildbahn entläßt, ohne eine saubere Schnittstelle nebst deren Doku vorzuhalten. Kurzum: Aus meiner Sicht ist nicht das "komplette Verständnis", sondern nur die verläßliche API-Doku das Wesentliche. Je mehr Meinungen zu diesem Thema ich hier in diesem Forum sehe, desto mehr komme ich zu dem Schluß, daß typische Linuxer die Dinge zu sehr aus der Sicht des Rechner-Sklaven sehen. Sagen wir lieber "Administrator" dazu, das klingt netter, ist aber exakt dasselbe. Oft wird sogar von "Userland" geredet, als ob dies ein ferner Kontinent sei, mit dem man nix zu tun hat. Mir ist klar, daß diese Befindlichkeiten aus der Unix-Historie kommen, wo zwischen den zahlenden Usern und den (von den Usern angeschnarrten) Admis "Legen sie mir mal Band 17 auf" eine dicke Betonwand war. Und so wie die User sich einen Dreck scherten darum, wie die Admis den Mainframe am Laufen hielten (das hat gefälligst zu funktionieren, ist ja teuer genug..) haben die Admis sich nicht um die Anwendungen der User gekümmert. Und dieser Geist steckt immer noch drin. 90% aller Linux-Beiträge in diesem Forum handeln von Innereien des BS, aber nicht von Anwendungen. Eigentlich ein trauriges Kapitel. W.S.
W.S. schrieb: > Pfusch > ist, wenn man ein BS in die freie Wildbahn entläßt, ohne eine saubere > Schnittstelle nebst deren Doku vorzuhalten. Du Scheinst wohl ein verzerrtes Bild von dem zu Haben was ein Betriebssystem ist. Linux ist ein Betriebssystemkern, mehr aber auch nicht. Coreutils, Shell, *libc, Toolkits sind gewissermaßen nur schmückendes Beiwerk. Dein Beispiel 'Rechteck Malen' hat mit dem OS an sich nichts zu tun, es ist auch nicht dessen Aufgabe, Funktionen zum Malen von Rechtecken anzubieten. Darum haben sich Grafikbibliotheken zu kümmern. Auf die Qualität der Windows-API wurde hier ja schon mehrfach eingegangen. Wenn http://de.wikipedia.org/wiki/Winapi#Programmbeispiel für dich eine gelungene API ist... (OK, ist Win32, CE wird auch nicht besser sein) Vergleiche das mal mit dem GTK+-Hallowelt. Wenn man sich die OS-Sprösslinge der letzten Jahre ansieht: Android : Linux WebOS : Linux Bada : Linux Meego : Linux iOs : OS X (BSD) Blackberry Tablet OS: QNX WP7 : Windows CE Fällt was auf? Auf der anderen Seite der Datenverbindung sieht die *NIX / nicht *NIX-Verteilung ähnlich aus. Wohl nicht ganz ohne Grund.
W.S. schrieb: > Soviel zum Thema Stabilität. Da habe ich aber ganz andere Erfahrungen gemacht. Meine beiden Windows CE Geräte (Dell Axim x51v sowie HTC Blackstone) waren beide "relativ" häufig neu zu starten. Zum Einen wurden sie unerträglich langsam, sofern man sie mal einige Tage laufen hat lassen, zum Anderen haben sie sich auch gerne mal aufgehängt. Beide Geräte hatten übrigens einen Reset-Button, welcher mit dem Stylus betätigt werden konnte. Mein aktuelles Android Smartphone jedenfalls hat einen solche nicht. Und den Akku musste ich auch noch nicht all zu oft herausziehen ;). Auch sind meine Router und Access Points (und davon sind hier einige im Betrieb) nicht tot zu kriegen. Die haben typische Laufzeiten von einigen hundert Tagen. Unterbrochen wird die Laufzeit eigentlich nur durch das Flashen von Firmware-Updates. Wie du schon sagtest: Solche Aussagen sind i.A. nicht viel wert. Da bringt jeder seine Vorurteile mit und bewertet das je nach favorisiertem System wohl auch ein wenig anders. Angefangen uns Windows als besonders stabil zu verkaufen hast aber du. Insofern wollte ich dem Ganzen mit meinen Erfahrungen entgegenwirken. Ich wäre mit Vergleichen bezüglich der Stabilität ein wenig vorsichtiger. Einfach zu behaupten System "x" ist stabiler bleibt genau das was es ist: Eine Behauptung. Dies unter objektiven Gesichtspunkten zu beweisen ist dann nämlich gar nicht so einfach. Außerdem sagt die Stabilität eines Systems nicht unbedingt etwas über die Qualität des Designs aus. Wenn überhaupt, dann sagt es etwas über die Qualität der konkreten Implementierung ab. Und ich glaube hier braucht sich Linux im Großen und Ganzen nicht zu verstecken. W.S. schrieb: > Wir reden doch eigentlich über das > Entwickeln von Anwendungen - oder nennen wir es mal lieber Firmware für > Mikrocontroller. Naja, ursprünglich ging es um das Einarbeiten in Linux im Umfeld von Embedded Devices. Das ist schon ein bisschen mehr als "nur" das Programmieren von Mikrocontrollern. W.S. schrieb: > Solche Beiträge wie: > _\|/_ schrieb: >> Ohne ein komplettes Verständnis, wie >> ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter. > > sind eigentlich nur ne Offenbarung des Pfusches. Das ist beim allerbesten Willen nicht nachzuvollziehen. Der Threadersteller will wohl - eher oder später - mit eingebetteten Systemen auf Basis von Linux umgehen können. Da muss man halt davon ausgehen, dass man auch entsprechendes Wissen um Linux hat. Das wäre im Falle von Windows nicht anders. Wenn ich ein eingebettetes System auf Basis von Windows aufbauen will, dann muss ich mich genauso mit dem Bootloader-Prozess auseinandersetzen, wissen wie ich Treiber schreibe und mit dem Betriebssystem kommuniziere. Wenn ich weiß wie die einzelnen Komponenten zusammenspielen, dann erleichtert es das Ganze natürlich enorm. Von reiner Anwendungsprogrammierung jedenfalls war hier nie die Rede. Zumindest solange nicht bis du angefangen hast irrwitzige und zum Teil falsche Aussagen zu treffen, um uns Windows CE als Wunderwerk der Technik zu präsentieren. W.S. schrieb: > Kurzum: Aus meiner Sicht ist nicht das "komplette Verständnis", sondern > nur die verläßliche API-Doku das Wesentliche. Klar ist eine gute Dokumentation hilfreich. Aber ein Verständnis davon zu haben was ganz grundsätzlich ablaufen muss, und wie dies im konkreten Fall (zum Beispiel bei Linux) funktioniert hat auch noch niemanden geschadet. Die Aussage ist wohl eher so zu verstehen, dass jemand der noch nie etwas mit Linux am Hut hatte, ganz bestimmt in Probleme laufen wird, wenn er sich an eingebettete Systeme wagt. Das ist im Falle Windows auch nicht anders - Dokumentation hin oder her. Zur Dokumentation von Microsoft hatte ich ja meinen Teil gesagt. Ich habe kein Problem damit einzugestehen, dass diese gut ist. Microsoft hat eben das nötige Kleingeld, um Leute dafür einzustellen, dass sie Dokumentationen schreiben. Andere, die wohl mehr Erfahrung mit den von Microsoft zur Verfügung gestellten Dokumentationen zu tun haben, haben diese allerdings auch kritisiert. Dazu kann ich keine kompetente Meinung abgeben. W.S. schrieb: > Oft wird sogar von > "Userland" geredet, als ob dies ein ferner Kontinent sei, mit dem man > nix zu tun hat. Also entweder du stellst gerade eindeutig unter Beweis, dass du nicht einmal weißt was es mit "Userland" auf sich hat, oder aber du machst hier einen Vergleich, den zumindest ich nicht verstehe. Userland bezeichnet i.d.R. Programme, die nicht im Kontext des Betriebssystems ablaufen (siehe https://en.wikipedia.org/wiki/User_space). Damit einher gehen unter Anderem weniger Privilegien. Das Microsoft dieses Konzept absolut falsch umgesetzt hat, habe ich ja hoffentlich oben anschaulich an einem Beispiel erklärt. Dort wird nach wie vor (!) das komplette grafische Subsystem im Kernel-Mode betrieben. Ursprünglich war dies so strukturiert worden, um einen Geschwindigkeitsvorteil zu erhalten. Das die Computer sowieso schnell genug werden würden, hat Microsoft in seiner unendlichen Weisheit wohl nicht richtig einschätzen können. Jedenfalls gehen damit Exploits einher wie ihn eben unter anderem Stuxnet ausgenutzt hat. Die simple Darstellung von manipulierten Grafikdateien reicht dann schon aus, um das System zu übernehmen. W.S. schrieb: > Und dieser Geist steckt immer noch drin. > 90% aller Linux-Beiträge in diesem Forum handeln von Innereien des BS, > aber nicht von Anwendungen. Eigentlich ein trauriges Kapitel. Das ist eine absolut nichtssagende Aussage. Wenn die Leute sich mit den Innereien des Betriebssystems auseinandersetzen, dann ist doch daran nichts auszusetzen. Wenigstens können sie das im Falle von Linux absolut uneingeschränkt tun. Bei Windows ist dies zum Einen technisch kaum machbar und zum Anderen wohl auch strafbar. Wenn überhaupt, dann ist Letzteres ein trauriges Kapitel, aber ganz sicher nicht, dass sich Leute mit Linux (und dessen Innereien) auseinander setzen. Übrigens hat man nicht unbedingt das Gefühl, dass du oben stehende Beiträge überhaupt gelesen hast. Oder aber du bist sehr schnell im Verdrängen und Vergessen. Auf die o.g. Argumente eingegangen bist du jedenfalls nicht!
W.S. schrieb: > Kurzum: Aus meiner Sicht ist nicht das "komplette Verständnis", sondern > nur die verläßliche API-Doku das Wesentliche. Die API ist unter Linux sehr viel stabiler als ihr Ruf. Lediglich im Kernel/Treiber ändert es sich mal was. Wenn du aber z.B. den Zugriff auf /dev/ttyS[0-999] ändern willst, wirst du das wohl nie in den Vanilla-Kernel bekommen. Dein Rechteck-malen erledigt sich über Toolkits, Qt, GTK usw. Klingt ziemlich nach gefährlichem Halbwissen. Win CE ist imho eine grausame Diva und wird von MS auch gerne kleingehalten damit am große Win verdient werden kann. Den Desktop hat MS, wohl auch noch recht lange, aber im Embedded-und Industrie-PC-Bereich ist Linux mehr als nur schwer am Kommen. Würde MS XP/WES 2009 weiterführen, hätte ich mir eher Sorgen um Linux und meinen Job gemacht.
Nu ja die stabilität von Linux oder Win CE auf einer HW Steht und fällt mit der qualität der Treiber. Bei Tragbaren Geräten spielt da noch das Power Management eine rolle. Viele abstürtze hänger spielen dann gerade mit dem Power Management und spezielen Ladezuständen zusammen, die verdammt schwer zu reproduziehren sind. und es gibt unterschiede in der windows CE entwicklung. der erste setzt ein fix und fertig zusammengeschnürtes Windows CE Board support Package für eine fix definierte HW ein. Er ist der reine anwendungsentwickler, der nur über die WinAPI mit dem OS kommuniziert. Will er auf eine neue HW wechslen braucht er eine HW für die auch ein Windows CE Board support Packsage existiert und ausgeliefert wird. Der 2. arbeitet bei dem HW Hersteller und baut so ein Windows CE Board support Package zusammen. Stellt die Komponenten zusammen, schreibt die Treiber, ...
Irgendwie hab ich den Eindruck, daß hier so langsam die Argumente ausgehen und durch Anfeindungen ersetzt werden. Ist nicht hilfreich, sondern stößt sowohl mich als auch eventuelle Mitleser eher ab. Meint ihr, die ihr mich so wortreich zitiert haben, daß durch verstärkte Rechthaberei und Prinzipienreiterei andere Leute animiert werden, sich mit Linux zu befassen? Ob nun die reine Torvaldsche Lehre besagt, daß ein Grafiksystem nicht in den Kernel gehört oder in irgendeine Stelle im BS, ist mir herzlich wurscht. Fakt ist, daß man das mit nem WinCE dabei hat und daß man mit nem nackten Linux bzw. einem nackten Embedded Linux genau das nicht dabei hat, was in allen Anwendungen, die mit nem menschlichen Wesen in Kontakt kommen, von größter Wichtigkeit ist: Grafik und Oberfläche. Aus Linux-Sicht gehört die grafische Obefläche also nicht ins Linux, sondern hat über sonstige Software realisiert zu werden, ja? Nun denn. Ich sehe das ganz anders: Wenn einer einen Router oder sonstwas baut, was allenfalls ferngewartet wird, dann ist das Fehlen dieser Betriebssystem-Leistungen ja OK, weil sowieso kein Display dran ist. Für alle anderen Fälle ist aber Grafik angesagt und wenn sie nicht im BS dabei ist, dann hat man 3 Probleme: OS und Grafiksystem und als drittes ne Event-Verwaltung, die zwischen beiden vermitteln muß. (Nebengedanke von mir: Linux weglassen und nur die Grafik implementieren, die ja per oben nachlesbarer Definition ohnehin nicht zum BS dazugehört) Mir kommt da sofort die Prinzipfrage hoch: Wozu braucht man in einem Gerät überhaupt ein WinCE oder Linux oder QNX? Immerhin stellen die alle ihre Hardwareanforderungen, die man erstmal löhnen muß. Im Gegenzug erwartet man Leistungen, die den Aufwand rechtfertigen. Vielleicht ist es hilfreicher, hier mal die von einem Embedded Linux erwartbaren Leistungen zusammenzutragen, um wieder auf nen sachlichen Boden zu kommen. Also, Leute, kommt auf den Anfang zurück: Mattes schrieb: > ich möchte mich gerne in Embedded Linux einarbeiten und komme aber aus > der Windows-Welt. Jetzt weiss ich nicht so richtig, wie ich einsteigen > soll. Was also bietet ein Embedded Linux an Leistungen und was nicht? Ich versuche mal als Anfang ein noch leeres Gerüst: - Scheduler ? - virtueller Speicher ? - Massenspeicher, Filesysteme ? - Ethernet ? - Event-Verwaltung ? (denkt an die Knöpfe am Gerät) - Fonts ? - Grafik ? - Drucken und Gerätekontexte ? (denkt an den Kassenbon) - Uhr, Kalender, Timer ? - USB ? - ...und was noch? und die nächste Frage: Wie steigt man ein, also wie kriegt man ein Embedded Linux zusammengebaut? - wo läßt es sich bilden außer auf nem Linux-PC? - läßt es sich mit anderen Toolchains als GNU überhaupt bilden? - wie gestaltet sich die Konfiguration? - gibt es sowas wie Board-Support-Packages für die uC, die hier in diesem Forum am beliebtesten sind? Ich denke mal, über diese Fragen zu diskutieren und hilfreiche Antworten zu schreiben, macht mehr Sinn als Flames zu verfassen. W.S.
W.S. schrieb: > - Scheduler ? T'ürlich doch > - virtueller Speicher ? dito > - Massenspeicher, Filesysteme ? dito > - Ethernet ? selbstverständlich > - Event-Verwaltung ? (denkt an die Knöpfe am Gerät) Knopf->Eingabegerät > - Fonts ? $grafikbibliothek, z.B. cairo mit pango, das rendert auch für uns Europäer seltsam anmutende Schriften > - Grafik ? $grafikbibliothek, z.B. cairo, UI dann mit GTK/QT Als Backend der Framebuffer > - Drucken und Gerätekontexte ? (denkt an den Kassenbon) Bondrucker wird wohl RS232 oder so sein, kein Problem > - Uhr, Kalender, Timer ? klar doch > - USB ? host und device > - ...und was noch? Die gewohnte Umgebung. W.S. schrieb: > nackten Embedded Linux genau das nicht > dabei hat, Dann verwende eben eine der zahlreichen Embedded-Distros. W.S. schrieb: > Aus Linux-Sicht gehört die grafische Obefläche also nicht ins Linux, Nebenbei: Windows ist das einzige (Wenn man es mal von Museumsstücken wie Mac OS Classic absieht) OS, bei dem die Grafik derart tief im Kernel steckt. Microsoft hat ja auch 'ne halbe Ewigkeit gebraucht um einen Windows Server ohne GUI rauszuhauen.
Joachim Drechsel schrieb: > Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ? Vernünftige IP und USB Stacks, Speicherschutz, lokale und remote Filesysteme, fertige Treiber und so weiter und so fort.
W.S. schrieb: > Irgendwie hab ich den Eindruck, daß hier so langsam die Argumente > ausgehen und durch Anfeindungen ersetzt werden. Du hast noch auf so gut wie keines reagiert. Insofern sind wir noch weit entfernt von dem Punkt an dem uns die Argumente ausgehen. W.S. schrieb: > Ob nun die reine Torvaldsche Lehre besagt, daß ein Grafiksystem nicht in > den Kernel gehört oder in irgendeine Stelle im BS, ist mir herzlich > wurscht. Und mit dieser Aussage hast du dich nun endgültig als jemand geoutet der von Betriebssystemen und den zu Grunde liegenden Ideen und Konzepten nicht wirklich eine Ahnung hat. "Das" Grafiksystem setzt sich - wie es in der Informatik eben üblich ist - aus vielen kleineren Systemen zusammen. Treiber für die Hardware z.B. gehören sehr wohl in den Kernel. Das Problem ist nur, dass Microsoft eben auch andere Teile in den Kernel gepackt hat, welche da nicht unbedingt hingehören. Und das ist weniger eine "Torvaldsche Lehre" als viel mehr gesunder Menschenverstand. Ein Exploit in der Form wie ihn Stuxnet verwendet hat (nämlich die simple Darstellung einer manipulierten Bilddatei) dürfte unter Linux jedenfalls nicht zur System-Übernahme führen. Und ich kritisiere hier nur den Umstand, dass hier Dinge im Kernel-Modus laufen, die es nicht unbedingt müssen. Ob mit dem Betriebssystem nun ein grafisches System mitgeliefert wird oder nicht, hat damit absolut nichts zu tun. Da kann ich deine Ausführungen sogar nachvollziehen und halte es aus Sicht von Microsoft nicht für verkehrt, wenn sie ein einheitliches System mitliefern. Nur kann man ein solches System eben genauso gut im Userland implementieren und muss es nicht mit Kernel Privilegien betreiben! Microsoft hat sich aber aus Geschwindigkeits-Gründen bewusst dafür entschieden. Ein Fehler mit fatalen Folgen. Aber auf diesen Punkt bist du nach wie vor nicht eingegangen. Vermutlich auch deshalb nicht, weil deine Definition von "Userland" falsch ist (siehe oben). W.S. schrieb: > Ich denke mal, über diese Fragen zu diskutieren und hilfreiche Antworten > zu schreiben, macht mehr Sinn als Flames zu verfassen. Ich sehe hier keine Flames. Ich sehe hier jemanden, der uns die Vielfalt der Linux-Welt schlecht reden will und uns Windows CE als Non-Plus-Ultra verkaufen will. Gleichzeitig aber stellt derjenige aber unter Beweis, dass sein Verständnis von der dahinter steckenden Technik nicht vorhanden bzw. falsch ist und auf jegliche Kommentare, welche die Funktionsweise von Windows (CE) in Frage stellen nicht eingeht. Lukas K. schrieb: > Microsoft hat ja auch 'ne halbe Ewigkeit gebraucht um einen > Windows Server ohne GUI rauszuhauen. Und diesen in typischer Microsoft Manier als etwas verkauft, dass es bisher noch nicht gegeben hat ;).
Rad neu erfinden schrieb: > Vernünftige IP und USB Stacks, Speicherschutz, lokale und remote > Filesysteme, fertige Treiber und so weiter und so fort. Prinzipiell könnte ich das auch statisch hinzulinken. "Torvaldsche Lehre": Ist auch nicht die reine Lehre ;) Halt eine Sicht der Dinge unter vielen. Sinn und Zweck eines OS ist die Verwaltung der Betriebsmittel, Klickibunti gehört nicht dazu. MS hat die Definition einen OS erweiter, nicht aus technischem, eher aus kaufmännischem Kalkül. Ein BWLer mag das verstehen und nachvollziehen können ... Mir persönlich ist das OS egal, es hat zu funktionieren und mir Dinge bereitzustellen die mir das Leben erleichtern - nicht mehr aber auch nicht weniger. Kann es das ist es ok. Kann es das nicht gehört es in den großen Rundordner. Bashing ? Egal in welcher Richtung, an Glaubensfragen werde ich mich nicht aufreiben. Es würde auch zu nichts führen.
Grafik: wie schon angesprochen der Framebuffer als schnittstelle zwischen der reinen monitor representation und dem GUI framework. Was auch immer das sein mag. von Komerziell bis open source bis zu was selbst gestrikten. Font: freeType Eingabe: über /dev/Input und den dazugehörigen Treibern. tsLib, ... Es ist immer die frage gegen was vergleicht man Linux. gegen Windows CE als bord Support Package oder gegen die selbstbau variante. Linux hat sicher viele möglichkeiten irgend etwas zu realisieren. Es gibt z.B. nicht nur ein GUI framework. sondern verschiedene. man hat zwar dann die qual der wahl. aber man kann ggf das gleiche für linux, win CE, tragbar / stationär verwenden. Bzw andere kriterien mit ansetzen, Speicherverbrauch, Lizenz, Kosten, verbrauchte rechenleistung, ... Ein Embedded Linux wird selten auf einem fix und fertig definierten board betrieben, das man von der stange kaufen kann. es gibt hier immer irgend welche anpassungen. z.B. LCD Farbtiefe, auflösung, wie sieht das Interface aus, 8bit 16bit 20bit? VSync, Paralel, seriel, ... Was für einen touch screen hab ich? resistiv oder kapazitiv? Ich habe da ich auf die sourcen zugriff habe die möglichkeit hier einzugreifen und anzupassen.
An diesem Thread kann man schön sehen: Je weniger Ahnung die Leute haben, desto größere Töne spucken sie.... Wenn man sich in embedded Linux einarbeiten will, dann von Grund auf. Ohne zu wissen wie der ganze Boot-Vorgang mit Einbindung der Hardware, Filesysteme u.s.w. geht, wird das am Ende sowieso nichts. Und da wird das Frustpotential schon ganz schön hoch. Man kann sich nicht nur an den gedeckten Tisch setzen und auf die schimpfen die für Umsonst rackern. Wer halt für embedded Linux zu blöd ist, der soll sich ce oder was anderes vorgefertigtes kaufen und damit glücklich werden. Wer's drauf hat, kann Zeit gegen Geld für Lizenzen aufwiegen und sehen was besser ist. Und viele von denen, die auf eigener Hardware ein emb. Linux mit Grafik u.s.w aufgesetzt haben, werden das nicht als Kochrezept nach außen tragen.
Was seid ihr doch für oberflächliche Leute. Bei euren Beiträgen wird mir schlecht. Ich greif mal 2 heraus: Lukas K. schrieb: >> - Event-Verwaltung ? (denkt an die Knöpfe am Gerät) > Knopf->Eingabegerät ...kopfschüttel Lukas K. schrieb: >> - Drucken und Gerätekontexte ? (denkt an den Kassenbon) > Bondrucker wird wohl RS232 oder so sein, kein Problem So? Daß Druckdaten über irgendeine verdammte Verbindung zum Drucker geschafft werden müssen, ist so was von low level und selbstverständlich, daß ich das garnicht angesprochen habe. Guckt mal auf den letzten Kassenbon und fragt euch wie das da draufkommt, was ihr dort sehen könnt. Etwa printf nach stdout? Nee. Hier geht es um Grafikdruck und nicht um ne RS232. "Bondrucker wird wohl RS232 oder so sein" - was für eine ausgemachte Blindheit! Also ich schließe mal, daß ein Embedded Linux nicht drucken kann. Allenfalls kann es das, was woanders gedruckt wurde, weiterleiten. Ganz offensichtlich habt ihr Linuxer immer noch keine Vorstellung von dem, was ich hier mal als "Grafik" bezeichnet habe: also grafisches Userinterface (Desktop auf'm Moni) und grafische Peripheriebedienung (Kassenbon aus dem Drucker). Beim Desktop sieht man bunte Kringels, aber das ist ja nicht der Kern des Geschäftes. Hinter jedem Kringel steht ein Stück Programm, ein Thread. All diese Threads müssen interagieren, dazu das Eventsystem. Und sie müssen verwaltet werden. Das ist der Job des Schedulers, also des innersten Kerns des BS. Genau deshalb ist die Verwaltung des Desktop eine zentrale Aufgabe des BS-Kernels, die all das umfaßt, was man auch für alle anderen Treads (Dienste bzw. Demons) tun muß und darüber hinaus auch noch deren visuelle Darstellung und Wiederherstellung organisieren. Und auch der hier versteht nix: "Grafik: wie schon angesprochen der Framebuffer als schnittstelle zwischen der reinen monitor representation und dem GUI framework." Der Framebuffer ist Nebensache, die Verwaltung der Elemente, sprich Threads, ist der Kern der Sache. Versucht doch endlich mal, so was einfaches zu begreifen! Fazit: Von einem Embedded Linux kann man keinen grafischen Desktop erwarten. Ist ja auch ne Aussage. Aber mir wird das hier langsam zu blöd. W.S.
W.S. schrieb: > . Etwa printf nach stdout? Nee. Hier geht es um > Grafikdruck und nicht um ne RS232. Im Handbuch des Druckers werden wohl die Escapesequenzen des Druckers beschrieben sein, dann passt das schon mit printf nach /dev/ttyS0. W.S. schrieb: > Also ich schließe mal, daß ein Embedded Linux nicht drucken kann. Gar kein Linux kann drucken. Dafür gibt es CUPS/lpr o.ä. W.S. schrieb: > Fazit: Von einem Embedded Linux kann man keinen grafischen Desktop > erwarten. Ist ja auch ne Aussage. Ich erwarte von keinem Embedded-System einen grafischen Desktop. Er stört sogar. W.S. schrieb: >> Knopf->Eingabegerät > ...kopfschüttel -v, bitte EDIT: Für einen zufällig ausgewählten Bondrucker von EPSON gibt es keine Treiber für CE, für Linux auch nicht. Nur für Desktop-Windowse.
W.S. schrieb: > Ganz offensichtlich habt ihr Linuxer immer noch keine Vorstellung von > dem, was ich hier mal als "Grafik" bezeichnet habe: also grafisches > Userinterface (Desktop auf'm Moni) und grafische Peripheriebedienung > (Kassenbon aus dem Drucker). Du scheint selber das ein oder andere Verständnisproblem zu haben. Auf meine Punkte bist du jedenfalls nach wie vor nicht eingegangen. Ich nehme mir mal das Recht heraus und behaupte, dass du damit akzeptierst, dass ich zumindest nicht Unrecht habe ;). Übrigens deuten deine Erläuterugen auf weitere Verständnisprobleme hin. W.S. schrieb: > . Hinter jedem Kringel steht ein Stück Programm, ein > Thread. All diese Threads müssen interagieren, dazu das Eventsystem. Und > sie müssen verwaltet werden. Das ist der Job des Schedulers, also des > innersten Kerns des BS. Ein Programm ist nicht mit einem Thread gleichzusetzen. Ein Thread ist eine Abstrahierung eines Abhandlungsstranges innerhalb eines Prozesses und wird unter anderem auch als "leichtgewichtiger Prozess" bezeichnet. Von Threads zu sprechen macht eigentlich nur Sinn, wenn es davon mehr als einen gibt. Und das ist absolut keine Notwendigkeit für ein Programm. W.S. schrieb: > Der Framebuffer ist Nebensache, die Verwaltung der Elemente, sprich > Threads, ist der Kern der Sache. Siehe dazu meine obige Ausführung zu Threads. Wie die "Verwaltung der Elemente" implementiert ist spielt überhaupt keine Rolle. Völlig egal, ob das nun ein Thread innerhalb eines einzigen Prozesses ist, oder aber eventuell mehrere Prozesse, welche mit einander kommunizieren. Das sind in gewisser Maßen Freiheitsgrade bei der Implementierung, die es, wenn überhaupt, in der Dokumentation zu vermerken gibt. Über die Funktionalität des Systems sagt das noch nichts aus. Um den "Kern der Sache" zu bestimmen, kommt es halt drauf an, was genau man sich anschaut. Die "Verwaltung der Elemente" in der Form, die du meinst, ist eben nicht im Kernel selbst unterzubringen, sondern im sog. Userland. Demnach würde ich es nicht als Kern der Sache bezeichnen.
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.