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!
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.
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.
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.
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.
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.
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.
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.
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..
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.
> 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.
> 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.
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. ;-)
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
