Hallo, es ist ja Niemandem in der Embedded Welt entgangen, dass es sehr starke Bemühungen in die Richtung geht, Embedded Entwicklung zur Domäne von java Programmierern zu machen, insbesonders standardisierte Betriebssysme wie Android darunterzulegen, und auf allen Ebenen auf Standards zu setzen (z.B. Web Services bei Kommunikation). Die Vorteile liegen für Projektverantwortliche auf der Hand: - Abkehr von Druidenwissen, Embedded Entwicklung durch günstigere und leichter zu bekommende SW-Entwickler - Fertigen Unterbau einkaufen (oder umsonst herunterladen) und nur noch das Baukastensystem Java oben draufsetzen - Standardisierte Middleware, im "günstigsten Fall" durch Open Source schwarmgetestet - Plattformübergreifende Codebasen, bei Standards von OS copy-and-paste möglich Das ist die Theorie. In der Praxis (die in der Regel eher von den Entwicklern wahrgenommen wird) sieht die Sache schon etwas Anders aus: - Z.T. um mehrere Potenzen höhere Hardwareanforderungen gegenüber RTOS basierten Lösungen, erfordert wesentlich billigere Stückpreise bei Hardware - Sicherheitsprobleme, da Android #1 Ziel der Hacker ist - Unterbau ist "Black Box," d.h. Debuggen auf Systemebene schwer bis unmöglich - Dauerstabilität in der Regel nicht garantierbar - Anpassung an Custom Boards erfordert in der Regel wieder Spezialisten - fehlende Echtzeit - Schwarmtesting ist ein nicht bewiesener Mythos (Heartbleed etc) - Horrende Bootzeiten - abgespecktes Android nötig (um z.B. ungewünschte Autoupdates zu unterdrücken) - etc pp. Ich bin mir darüber im Klaren, dass diese Debatte enorm emotional geführt werden kann und sowohl auf Pro als auf Con Seite noch sehr viel mehr Argumente ins Feld geführt werden können. Darum geht es aber hier nicht, denn egal wie man dazu steht: Die Zeit wird zeigen, ob das Modell realisierbar ist oder nicht. Funktioniert es, wird die Zukunft hier liegen; funktioniert es nicht, wird in der Blase, die z.Zt. wächst, so manche Firma den Bach runtergehen, die darauf setzt, und die Embedded Welt wird weiter ihr eigenes Randdasein mit ihren eigenen Paradigmen bleiben (Ökosysteme etc). Deshalb hier die Bitte um Erfahrungswerte: Wo sind (vor Allem im Industrial Embedded Bereich; bei Consumer stellt sich die Frage ja eigentlich nicht mehr wirklich) Projekte mit Java/Android am Laufen und mglw. schon im Feld eingeführt, und was sind die Erfahrungen? Schönen Dank!
:
Verschoben durch Moderator
druidordroid schrieb: > - Abkehr von Druidenwissen, Embedded Entwicklung durch günstigere und > leichter zu bekommende SW-Entwickler Das ist ein Mythos. Embedded bleibt embedded egal welche Sprache du nimmst. Die Einschränkungen und besonderen Anforderungen bleiben. wenn du die nicht kennst wirst du es in jeder Sprache auf jedem OS vergeigen. > - Fertigen Unterbau einkaufen (oder umsonst herunterladen) und nur noch > das Baukastensystem Java oben draufsetzen Die gibt es auch für standard Kernel oder man nutzt z.b. VxWorks > - Standardisierte Middleware, im "günstigsten Fall" durch Open Source > schwarmgetestet bei einem default kernel dabei. im Zweifel sogar per Paketmanager downloadbar. > - Plattformübergreifende Codebasen, bei Standards von OS copy-and-paste > möglich Das ist bei allen großen projekten heute schon der Fall... > - Z.T. um mehrere Potenzen höhere Hardwareanforderungen gegenüber RTOS > basierten Lösungen, erfordert wesentlich billigere Stückpreise bei >Hardware Richtig. > - Sicherheitsprobleme, da Android #1 Ziel der Hacker ist Sicherheitsprobleme entstehen durch schlechtes design und bewusste Entscheidungen GEGEN Sicherheit zugunsten der Kosten. > - Unterbau ist "Black Box," d.h. Debuggen auf Systemebene schwer bis > unmöglich > - Dauerstabilität in der Regel nicht garantierbar Richtig, hier ist ein LTS kernel die bessere Wahl. > - Anpassung an Custom Boards erfordert in der Regel wieder Spezialisten Richtig. Es wird gerne übersehen, dass Android nicht einfach magisch irgendwo startet. > - fehlende Echtzeit Richtig. Wird man mit Android auch aktuell nicht hinbekommen. > - Schwarmtesting ist ein nicht bewiesener Mythos (Heartbleed etc) > - Horrende Bootzeiten > - abgespecktes Android nötig (um z.B. ungewünschte Autoupdates zu > unterdrücken) das hält sich in Grenzen, wenn man einen kleinen Kernel nimmt. - Aber dann hat man auch die Vorteile oben nicht mehr :) > Deshalb hier die Bitte um Erfahrungswerte: Wo sind (vor Allem im > Industrial Embedded Bereich; bei Consumer stellt sich die Frage ja > eigentlich nicht mehr wirklich) Projekte mit Java/Android am Laufen und > mglw. schon im Feld eingeführt, und was sind die Erfahrungen? Im Bereich Consumer (Klicki-Bunti) mit Bildschirm und Touch ist Android recht praktisch. Allerdings darf man den Anpassungsaufwand nicht unterschätzen. Gerade das Managment tut das leider oft nach dem Motto "Auf so vielen Smartphones geht es ja! Sie müssen es nur einfach installieren!" Für Visualisierung und unkritische Interfaces geht Android auch. Hier ist es aber oft mehr Hype als wirtschaftlich. Zwei mir bekannte Projekte in dem Bereich sind gnadenlos über das Budget geschossen und am Ende wären "echte" embedded Lösungen deutlich günstiger in der Entwicklung auf billiger Hardware gewesen. Hier wird es aber wahrscheinlich mit mehr Erfahrungen deutlich besser, dass einzuschätzen. Gerade für Industrie wird es noch dauern, bis entsprechend Leistungsfähige Plattformen auf dem Markt sind. Diese RaspBerry-Pi zwischengröße ist hier aktuell vollständig von kleinen custom-kerneln besetzt. Ein kleiner Kernel mit einer einfachen Oberfläche lässt sich in ca. 50MB unterbringen und flüssig mit HD ausgabe auf einem 500MHz kern betrieben. versuch dass mal mit einem Android. (Siehe z.B. Damm Small Linux) - Durch entsprechende Toolchains (die ja meist so wie so vorhanden sind) ist der auch aktuell meist schneller gebaut als jedes Android. Für alles was Echtzeit braucht geht es schlicht einfach nicht. Für alles mit sehr beschränkten Resourcen (z.B. durch hohe Stückzahl) macht es auch keinen Sinn.
In der unantastbaren RTOS-Abteilung werden die ersten Halbgötter nervös...
Intel hat grad den Appollolake mit 12 Jahren Verfügbarkeit gelauncht. Möchte man wirklich später ein 12 Jahre altes Android mit verkaufen?
Michael X. schrieb: > Intel hat grad den Appollolake mit 12 Jahren Verfügbarkeit gelauncht. > Möchte man wirklich später ein 12 Jahre altes Android mit verkaufen? Man will die Aussicht haben, ein bestehendes Produkt ein Jahrzehnt verkaufen zu können, ohne es alle 2 Jahre umkrempeln zu müssen. Neue Versionen von Programmen, Betriebssystemen oder Hardware beinhalten immer das Risiko, dass bestehende Lösungen nicht mehr so funktionieren wie vorher. Geht es jedoch nur um Bug- und Security-Fixes, ist das Risiko wesentlich geringer. Die Linux Enterprise-Distris von Suse und Redhat gibt es deshalb mit 10 Jahren Fix-Support, plus ein paar Jahre mehr für tiefe Geldbeutel. In diesen Distris enthaltene Pakete erhalten Fixes, ggf. als Backports, aber im Rahmen normaler Updates keine völlig neuen Versionen. Das heisst nicht, dass es die nächste Version der Distri-Version erst nach 10 Jahren gibt, aber es bedeutet Stabilität für bestehende Lösungen. In diesem Sinn darf man das auch bei der Hardware und bei Android sehen. Ein Anbieter von Embedded-Lösungen benötigt eine Stabilität der Plattform. Alle 2 Jahre alles auf den Kopf stellen zu müssen ist in Embedded meist keine sinnvolle Option. Es geht da ja nicht um Handys.
:
Bearbeitet durch User
NB: Was hat das mit A&B zu tun?
Android wird ja durchaus nachgefragt. Da gibts schon Interesse. Immerhin dürfte das UI vielen bekannt vorkommen.
druidordroid schrieb im Beitrag #4913060: > Verstehst Du die Bedeutung des Wortes "Bitte"? Was hat "Bitte" mit > "verbieten" zu tun? Es gibt noch nicht mal einen Zusammenhang mit > "verbitten." Ich kann hier offensichtlich nichts "verbieten," ich habe > nur gebeten. > Wenn du provozierst ändert das ja nichts daran auch wenn du es höflich wie nach alter chinesischer Sitte gemacht hast. Ohrfeige bleibt Ohrfeige, auch wenn man die anbietet oder drum bettelt. > Wenn das die Mods auch so sehen, dürfen sie den thread gerne löschen > oder verschieben (NB: Ich habe kein Anderes passendes Unterforum > gefunden, deswegen ist der thread hier gelandet). Die machen das nach ihren Gusto und das braucht hier nicht diskutiert werden. Ich wollte dich auch nur darauf aufmerksam machen. Auf Mittel, dass zu verbieten, hätte ich sowieso keinen Zugriff, aber manchmal sind die Mods. auch dankbar, wenn andere User so ein wenig mit aufpassen, denn die können ja nicht immer moderieren. >> Wem meine Meinung nicht passt, braucht sie weder lesen, noch sonst >> ein Wort drüber verlieren. Ansonsten kann die Diskussion hitzig werden. >> Also, lasst euch nicht veräppeln. > > Aha, bist Du das Tier aus der Muppet Show, dessen Kettenreichweite > besser nicht unterschritten werden sollte? Ist es der Sinn und Zweck > dieses Forums, Dich nicht zu ärgern, damit die Form gewahrt bleibt? Bislang hatte noch keiner Anlass die Kette kurz zu halten. Meine Löschquote ist erstaunlich gering. Also muss ich wohl was richtig machen. Übrigens ist das "Tier" einer meiner Lieblings-Muppets. Du stehst wohl lieber auf Fossy-Bär, oder? > Offensichtlich hast Du irgendwelche Probleme mit normalem > mitmenschlichen Umgang und elementarsten Umgangsformen (von den o.g. > Problemen, Sprache richtig verstehen zu können, mal ganz abgesehen). Den > Vorwurf des Forumsmissbrauches gebe ich deswegen gerne an Dich zurück. Meine Umgangsformen sind schon okay und wenn man sich argumentativ durchsetzen will, muss man schon mal etwas ernster werden, sonst würde Weichgespültes ja einfach nutzlos verpuffen. Funktioniert doch. > Danke übrigens für die bislang sehr konstruktiven und hilfreichen > Antworten. Ich würde mich über weitere Erste-Hand-Berichte freuen. Reichen dir die anderen nicht? Sind doch sehr kompetent. Ein Vergleich, sofern ich das richtig verstanden habe, vereinfacht ausgedrückt, zwischen Embedded und dem quelloffenen Android kann es eigentlich nicht geben, weil Android nur auf einer bekannten Hardware weiter entwickelbar ist. Embedded kann aber mit völlig frei und neuer Hardware nebs Software entwickelt werden, so das man nicht veraltete Resourcen nutzen muss, was dann aber die Kompatibilität verschlechtert. Das muss man dann in Kauf nehmen weil die Entwicklung nicht still stehen bleibt. Bei Embedded kann das schnell eine Sackgasse werden. Das Thema hatten wir hier schon mal. druidordroid schrieb: > schwarmgetestet Interessantes Kunstwort, kennt google gar nicht. Wenn man Qualitätsprobleme bei Apps hat, dann sollte man die von einem zertifizierten Prüfer checken lassen. Wenn man beim Arzt unzufrieden mit der Diagnose ist, kann man ja auch eine zweite Meinung einholen. Einziger Unterschied, der Arzt kostet auf Krankenschein nix extra. Bei Software sieht das schon anders aus, aber das Prinzip ist das selbe.
:
Wiederhergestellt durch Admin
Michael X. schrieb: > Appollolake Das sind doch aber x86 Prozessoren? Da bringt mir android auch nicht so viel drauf.
>x86 Prozessoren
gibt sogar Android tablets mit x86
und nachdem es hier um JAVA geht, wäre das vollkommen egal, du würdest
es nicht merken..
waflija schrieb: > Das sind doch aber x86 Prozessoren? Da bringt mir android auch nicht so > viel drauf. Weshalb? Besonders Asus hatte in den letzten Jahren etliche x86-Handys und -Tablets im Angebot, die mit Android liefen. Intel hat den Handy/Tablet-Markt zwar mittlerweile wieder aufgegeben, aber von recht wenigen Apps mit Binärcodeteilen abgesehen ist die Anwendungsbene Java, mit in Zwischencode ausgelieferten Apps. Relevant ist der verwendete Prozessor also nur für jenen Compiler, der diesen Zwischencode bei Installation (ab V5) oder Ausführung (davor) in Maschinencode übersetzt.
:
Bearbeitet durch User
druidordroid schrieb: > Deshalb hier die Bitte um Erfahrungswerte: Wo sind (vor Allem im > Industrial Embedded Bereich; bei Consumer stellt sich die Frage ja > eigentlich nicht mehr wirklich) Projekte mit Java/Android am Laufen und > mglw. schon im Feld eingeführt, und was sind die Erfahrungen? Android enthält wie Java einen Garbage Collector, der das System teils sekundenlang anhält. Das ist für embedded ein klares no-go. Ebenso ist es unter Android nicht vorgesehen, Routinen über Interrupts auslösen und ausführen zu lassen. Die Schnittstellen-Behandlung ist allgemin schlecht, man müsste für jeden I/O Pin den HAL erweitern. Damit ist Android ausschliesslich als Bedienoberfläche in zeitunkritischen Anwendungen tauglich. Selbst klassisches Windows wäre besser für embedded geeignet (Ein Win31 kostet auch bloss 128kB). Ja, man kann Java auch mit anderen garbage collectoren bauen und man könnte auch Java routinen über interrupts anbinden, aber das ist nicht vorgesehen in Android, dessen Hauptaufgabe ein dermassenes Verdongeln ist daß man auf keinen Fall Werbung und unbegrenzte Datenübermittlung an den App-Autor blocken kann. Als Steuerungs-App für die Hausautomation ist Android natürlich nett.
:
Bearbeitet durch User
Michael B. schrieb: > Damit ist Android ausschliesslich als Bedienoberfläche in zeitunktischen > Anwendungen tauglich. Wobei die damit arbeitenden Mobilgeräte stets separate Prozessoren für die Funkerei mitführen (baseband). Und die arbeiten nicht unter Android. Die Trennung von Lowlevel-Steuerung und Kommunikation/Interaktion halte ich in Steuerungs-Geräten mit viel User+Netzwerk-Aktivität ohnehin für recht sinnvoll. Nicht zuletzt aufgrund des zunehmenden Update-Drucks im Kommunikationsbereich, und aufgrund von Sicherheitsfragen. > Android enthält wie Java einen Garbage Collector, der das System teils > sekundenlang anhält. Wurde mit Android 5 erheblich verbessert. Aber natürlich geht Garbage Collection schon prinzipiell nicht sonderlich konform mit Echtzeitanforderungen. Allerdings betrifft die GC nicht das Basisbetriebssystem, also den Kernel, sondern die eigentliche Android-Ebene.
:
Bearbeitet durch User
Android ist dann sinnvoll, wenn man Internet, GUI, 3D, Multimedia, Apps, Datensammelei und Werbung machen will. Moderne Fernsehgeräte (z.B. LG) laufen z.B. unter Android. In dem Augenblick, wo das Teil etwas wichtiges machen muss (d.h. irgendwas mit Anforderungen an Zuverlässigkeit, Echtzeit oder Langfristigkeit), ist Android eine äußerst schlechte Wahl. Für das Hauptthema hier im Forum (Deeply Embedded) ist Android nicht geeignet. Die Hauptvorteile "sicher gegenüber Angriffen durch Open-Source-Schwarmintelligenz" und "schnelle Entwicklung durch relativ sinnloses Zusammenklicken von Bibliotheken" widersprechen sich in meinen Augen so sehr, dass man darüber nicht weiter diskutieren braucht.
:
Bearbeitet durch User
druidordroid schrieb: > Ich bin mir darüber im Klaren, dass diese Debatte enorm emotional > geführt werden kann Und warum packst du dann eine gute Portion Unterstellungen, unbelegte Behauptungen und Beleidigungen in dein Eröffnungsposting? Insgesamt klingt das was du schreibst sowieso so, als ob du eine Studie mit teilweise vorbestimmten Ausgang schreiben musst und wir die Idioten spielen sollen, die dir für den Rest die Stichworte geben sollen. Ich würde fast schon auf eine gewisse österreichische Hochschule tippen, die mal wieder peinlich auffällt.
Sobald das Produkt etwas Wichtiges in Richtung Verfügbarkeit und fkt. Sicherheit leisten muss hat sich die Frage Android/Java erledigt. Das ist keine Meinung, sondern ein Zustand ;-)
Mir ist nach meiner Erinnerung in den letzten 20 Jahren EDV kein einziges, wirklich brauchbares Java-Programm untergekommen oder eins, das nicht irgendeine katastrophale Macke gehabt hätte (oder gleich mehrere davon). Allerdings bin ich davon überzeugt, daß das gar nicht mal an der Sprache liegt, sondern einfach an der Tatsache, daß jeder Halbwissende meint, mit einer einfachen Sprache könne man einfach programmieren. Das führt leider dazu, daß reichlich bunt angestrichener Mist unterwegs ist. Oder kürzer: man wollte eine Sprache, mit der jeder Idiot programmieren kann. Und genau das ist passiert.
Markus F. schrieb: > Mir ist nach meiner Erinnerung in den letzten 20 Jahren EDV kein > einziges, wirklich brauchbares Java-Programm untergekommen oder eins, > das nicht irgendeine katastrophale Macke gehabt hätte (oder gleich > mehrere davon). Das Backend der BMW Homepage ist in Java programmiert. Kannst ja selber bewerten ob das gut/schlecht ist. Tobi schrieb: > Sobald das Produkt etwas Wichtiges in Richtung Verfügbarkeit Verfügbarkeit ist nicht das Problem. Solange das Problem einfach/schnell genug skaliert (Google App Engine) ist Java/die Sprache als solches nicht das Problem. Es kommt mehr auf die Problemstellung drauf an. Meine Erfahrung (über einen Kollegen die Infos bekommen), ein Mittelständischer "Hidden Champion": Raspberry Pi Lösung zum auslesen und konsolidieren von Messwerten. Nach dem Protoypen eingestellt geworden, auch wenn ich glaube, dass das Konzept an sich scheisse ist. Raspberry Pi etc. können durchaus für viele Dinge sinnvoll eingesetzt werden, aber, wie schon ein paar mal gesagt worden ist, jeder Depp glaubt er würde das hinkriegen weil es ein paar Tutorials gibt.
ui schrieb: > Das Backend der BMW Homepage ist in Java programmiert. Kannst ja selber > bewerten ob das gut/schlecht ist. Als reiner Nutzer kann ich die Qualität eines Backends nicht beurteilen (es sei denn, es ist so grottenschlecht, daß es zickt). Allerdings würde ich darauf wetten, daß es ein Vielfaches an Ressourcen verbraucht als eigentlich notwendig.
Android ist sicher gut zum Visualisieren von Prozessdaten. Man schreibt sich ein serielles Interface, und connectet zb per Bluetooth. Der effektive Prozesscontroller ist etwas einfacheres, Stabiles, das den Prozess steuert und sonst nur kommuniziert. Solange da ein AVR genuegt, genuegt er. Wir sind auch grad an so einem Projekt. Das Kommunikationsinterface muss nur zustandslos sein, dann kann man beliebig connecten und disconnecten, der Prozess laeuft weiter. Ah, ja Erfahrungen. Nee Android als Prozess Controller, geht nicht. Ich muss mein Tablet vielleicht einmal im Monat neu booten. Sowas geht nicht fuer einen Prozesscontroller. Meine Prozesscontroller muessen jahrelang ohne neu booten durchlaufen. Stell dir vor ein Seilbahn Controller muss waehrend der Fahrt neu gebootet werden., dann will er ein Update machen, und das geht nicht..
:
Bearbeitet durch User
Hannes J. schrieb: > druidordroid schrieb: >> Ich bin mir darüber im Klaren, dass diese Debatte enorm emotional >> geführt werden kann > > Und warum packst du dann eine gute Portion Unterstellungen, unbelegte > Behauptungen und Beleidigungen in dein Eröffnungsposting? > Hä? Wo ist irgendwas von dem, was Du da schreibst, im Eingangsposting? Nach Bestem Wissen und Gewissen habe ich Niemanden da beleidigt, bitte lies das noch mal genauer durch. SOLLTE eine Beleidigung oder Unterstellung dort drin sein, bitte ich um Entschuldigung, davon war nichts beabsichtigt! > Insgesamt klingt das was du schreibst sowieso so, als ob du eine Studie > mit teilweise vorbestimmten Ausgang schreiben musst und wir die Idioten > spielen sollen, die dir für den Rest die Stichworte geben sollen. > Ach so? Wie würde denn die Interpretation zu dem hier im Original geposteten passen? druidordroid schrieb: > Darum geht es aber hier > nicht, denn egal wie man dazu steht: Die Zeit wird zeigen, ob das Modell > realisierbar ist oder nicht. Funktioniert es, wird die Zukunft hier > liegen... Hintergrund ist, dass mein AG sehr intensiv mit Android als Plattform für eine Industrial Anwendung OHNE GUI liebäugelt. Selbstverständlich habe ich als Entwickler mit RTOS Hintergrund (wie alle in der Entwicklungsabteilung) starke Vorurteile (keines von den Argumenten GEGEN Android in diesem Thread hat nicht einer in unserem Flur auch schon eingeworfen), aber die Position der GeschFü ist aus deren Sicht auch nicht von der Hand zu weisen. Und da immer noch der alte Grundsatz gilt "was nicht bewiesen funktioniert oder bewisen NICHT funktioniert, darf man ruhig mal in Betracht ziehen," hatte ich eben gehofft, NICHT alle meine Vorurteile untermauert zu kriegen, sondern belastbare Fakten. Also entweder "das ist bei uns hoffnungslos aus Gründen abc, def und xyz in die Hose gegangen" oder "wir haben vor 2 Jahren ein Produkt damit eingeführt, und bislang bewährt sich das im Feld gut." Deswegen auch meine Bitte um ERFAHRUNGEN, nicht Meinungen (obwohl der Querschnitt der Meinungen auch schon interessant ist, danke dafür). > Ich würde fast schon auf eine gewisse österreichische Hochschule tippen, > die mal wieder peinlich auffällt. Nope, so gar nicht.
Android ist toll. Octave, python zum visualisieren oder optimieten der Prozesse, bzw sum loggen, ein Fernsehdongle MIT rs232 Verbindung zum controller. Java, fehlanzeige.
Sapperlot W. schrieb: > Ah, ja Erfahrungen. Nee Android als Prozess Controller, geht nicht. Ich > muss mein Tablet vielleicht einmal im Monat neu booten. Sowas geht nicht > fuer einen Prozesscontroller. Meine Prozesscontroller muessen jahrelang > ohne neu booten durchlaufen. Andererseits geht es auch nicht, dass ein Gerät mit Anzeige/Bedienung per Webserver (IoT like) im Internet monatelang ohne Updates durchläuft. Klar, heute macht man das so, aber es pfeifen die Spatzen von den Dächern, dass das nicht so bleiben kann. > Stell dir vor ein Seilbahn Controller muss waehrend der Fahrt neu > gebootet werden., dann will er ein Update machen, und das geht nicht.. Wer den direkt mit den Sensoren/Aktuatoren versehenen Steuerteil eines Seilbahn-Controllers auch direkt mit Interaktion per Netz und Webserver etc versieht, der hat es verdient, dass ihm die Seilbahn auf den Kopf fällt. Wenn man andererseits den nicht mit Android arbeitenden Steuerteil autark arbeiten lässt und nur den mit Android arbeitenden Teil für Anzeige/Bedienung ab und zu updaten muss, dann geht das schon. Übrigens gibt es in Android ohne Google-Apps keine Zwangsupdates. Ersetze Android durch Linux oder Windows und es ändert sich nicht viel an solcher Bewertung. Keines dieser Systeme eignet sich für kritische Prozessteuerungen für deine Seilbahn. Umgekehrt sind individuell handprogrammierte Webserver/Webapps oder anderer Kram vergleichbarer Komplexität und Netzwerkebene als Nischenlösung teuer und nicht notwendigerweise sicherer.
:
Bearbeitet durch User
> Allerdings würde ich darauf wetten, daß es ein Vielfaches an > Ressourcen verbraucht als eigentlich notwendig. Aber die Ressourcen sind nicht zwangsläufig verschwendet, man bekommt auch was dafür. Zum Beispiel exzellente Möglichkeiten für Remote-Debugging. Ein schwerer Merzedes verbraucht auch mehr Sprit und Material, als Notwendig. Trotzdem werden diese Autos gekauft - und das sicher nicht weil alle Käufer Ahnungslos sind.
Markus F. schrieb: > Mir ist nach meiner Erinnerung in den letzten 20 Jahren EDV kein > einziges, wirklich brauchbares Java-Programm untergekommen oder eins, > das nicht irgendeine katastrophale Macke gehabt hätte (oder gleich > mehrere davon). Du wirst X Java-Programme genutzt haben, ohne das du es wusstest. Java ist in Web-Backends sehr beliebt. https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites > Oder kürzer: man wollte eine Sprache, mit der jeder Idiot programmieren > kann. Und genau das ist passiert. Das ist zum Teil richtig. Der andere Aspekt ist, dass man in der Sprache selber ein paar Dinge und im Java-Ecosystem eine ganze Menge Dinge vermurkst hat.
(ernst gemeinte Frage) wo ist der Haupt-Unterschied zwischen einer RaspPi mit linux mit java aber ohne GUI und einem Android mit Java aber OHNE GUI ?!
> Android mit Java aber OHNE GUI
Gibt es das überhaupt?
Wie dem auch sei, den Unterschied hast du selbst hingeschrieben:
1) RaspPi mit linux
2) Android
Bei 1 hast du eine Hardware Plattform benannt, bei 2 hast du keine
Plattform genannt. Es wäre auch ein Android auf Raspi denkbar. Oder ein
Raspi ohne Linux.
Der wesentliche Unterschied ist das Betriebsystem.
Linux ist der Name des Kernels, der sowohl von Android als auch von
zahlreichen anderen Betriebsystemen, zum Beispiel Debian, Suse, redHat,
Ubuntu, usw benutzt wird.
Hinzu kommt, dass Java und die Android Variante von Java nicht identisch
sind. Deswegen läuft ja seit Jahren der Rechtsstreit zwischen Oracle und
Google. Kurz gesagt ist die Programmiersprache von Android eine leicht
abgespekcte Variante des normalen Javas.
Dazu kommt, dass bei Android die ganze GUI ein Teil der Java
Laufzeitumgebung ist, während sie bei den gängigen Linux Distributionen
ein separates optionales Programmpaket ist.
Du hattest um Erfahrungen gebeten. Zum Spaß wollte ich einen fahrenden Roboter (NiboBee) wie ein ferngesteuertes Auto mit dem Smartphone steuern, und zwar über Bluetooth. Ich hatte dazu eine App geschrieben, die entsprechende Buttons (vor, zurück, links,rechts) bereit stellt. Die Datenübertragung war aber ein bisschen hakelig, weswegen ich das Fahrzeug nicht gut steuern konnte. Betriebsystem, Garbage kollektor und Bluetooth sind offensichtlich keine gute Kombination für Anwendungen dieser Art. Eigentlich wollte ich im nächsten Schritt den Tilt Sensor verwenden, aber mir war die Lust vergangen, weil es schon mit den Buttons schlecht funktionierte.
>Andererseits geht es auch nicht, dass ein Gerät mit Anzeige/Bedienung
per Webserver (IoT like) im Internet monatelang ohne Updates durchläuft.
Klar, heute macht man das so, aber es pfeifen die Spatzen von den
Dächern, dass das nicht so bleiben kann.
Natuerlich geht das. Der Webserver muss ja auch nur genau die
Funktionalitaet zur Verfuegung stellen, die benoetigt wird. Das bedeutet
ein paar HTTP-Get Anfragen, ein paar JSON Antworten. Natuerlich keine
Schreibrechte. Wenn man Schreibrechte geben wollte, wirds kompliziert,
mit Verschluesselung und dergleichen.
Ich werd fuer besagte Prozesskontrolle, mit Schreibrechten, bei
Bluetooth bleiben, und Vorhandensein vor Ort voraussetzen und
durchsetzen. Dies kann man zB duch Anzeige eines Codes auf dem Display
des richtigen Prozesscontrollers, der dann im dem mit Bluetooth
angebundenen Android quittiert werden muss. Und das Bluetooth des
Android ist dann mit dem Prozesscontroller gepairt.
:
Bearbeitet durch User
Sapperlot W. schrieb: > Natuerlich geht das. Der Webserver muss ja auch nur genau die > Funktionalitaet zur Verfuegung stellen, die benoetigt wird. Das bedeutet > ein paar HTTP-Get Anfragen, ein paar JSON Antworten. Warten wirs ab, wie lange ihr das durchhaltet. Also einfache Oberflächen ohne den ganzen Schnickschnack, der sich auf der Messe rein optisch so wundervoll zeigen lässt. Auge isst mit. ;-)
:
Bearbeitet durch User
Jack schrieb: > Du wirst X Java-Programme genutzt haben, ohne das du es wusstest. Java > ist in Web-Backends sehr beliebt. Das ist mir durchaus bekannt. Und meine Aussage von oben stützt sich - zumindest zum Teil - auf die Erfahrungen, die ich "von innen" damit gemacht habe. Die Qualität eines Web-Backends kann man vernünftig nur von da aus einschätzen - nach außen "versteckt" der Load-Balancer (zum Glück) das Meiste von dem, was innen schief läuft. Wenn man genau hinguckt, werden da Server per Schedule regelmäßig neu gestartet, weil sie aus irgendwelchen Gründen, die keiner findet, im CPU-Röst-Modus hängenbleiben oder man muß sie noch nicht mal neu starten, weil sie das - ohne ersichtlichen Grund - schon von ganz alleine tun.
Google ist doch selbst dabei ihr Android Things dmait zu bewerben, dass es eine geringe Einstiegsschwelle gibt und jeder schnell auf vorgegebener Hardware mit Android und deren API entwickeln kann. Lasst doch einfach mal einen Studenten ein Testprojekt mit sowas machen. Das ist bestimmt interessant. Für die schon viel genannten Visualisierungsaufgaben oder Aufgaben ohne Echtezitanforderungen ist das bestimmt ganz praktisch wenn man mit wenig Kosten einen Mehrwert mit anbieten kann. Link: https://developer.android.com/things/index.html
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.