Hi, ich gebe dir erst einmal recht und behaupte danach das Gegenteil.
Das was du sagst stimmt zwar warscheinlich, mit default Images, aber man kann sich bei Yocto frei aussuchen was man haben will. Das heißt man kann die Größe anpassen.
Was man zu Yocto verstehne muss ist, es basiert auf OpenEmbedded Core, welches buildbot verwendet um ein System zu erstellen. Buildbot ist abgeleitet von den gentoo ebuilds. Man erkennt das mittlerweile allerdings nicht mehr so gut.
Es gibt bei OpenEmbedded mehrere Layer. Es gitbt auch verschiedene Paketsysteme und libcs zur Auswahl.
Du kannst dir nun ein base-image erstellen welches nur aus dem Kernel besteht. Diesen kannst du dir konfigurieren wie du willst .Wenn du eine eigene MACHINE erstellst. Dann kannst du einen Kernel und ein Image definieren. Das minimalste Image mit dem du etwas anfangen kannst ist z.B. nur der Kernel (2MB?) und eine busy box (4MB?). Die busybox config kannst du auch frei in einem eigenen Layer überschreiben. Die libc kannst du dir auch frei aussuchen (~1MB). Also wenn dir die Busybox config von Yocto nicht gefällt, weil sie zu groß ist. Damit hast du ein bootbares Image mit ~7Mb. Je nachdem was du halt willst. Man kann mit Yocto sehr kleine Images bauen. Als Beispiel sei dafür z.B. der Bootloader vom alten Zaurus genannt (~2MB) welcher kexec verwendet um danach etwas größeres zu laden.
Es kommt also darau an was du haben willst und wie du es konfigurierst. Du kannst ziemlich sicher das selbe Image erstellen, welches bei buildroot am ende raus kommt. Die Frage ist nur ob es das schon gibt, oder wieviel arbeit du da reinsteckst. Je mehr Kontrolle du willst, z.B. systemd ja oder nein, udev oder mdev etc. Ist es vielleicht einfacher eine eigene Distribution zu erstellen, wie eine abzuändern. Ich verwene z.B. nur oe-core + openebedded + ansgroem based distribution + machine layer + product layer. Und die images die da raus kommen sind weit unter 32 MB.
Was für ein Image meinst du denn genau? Bei dem vergleich Yocto vs buildroot. Wie sieht da deine buildroot config aus und wie die von Yocto? Ich bin mir sehr sicher das selbe Image mit OpenEmbedded bauen zu können.
Bin gespannt ob ich dir da konstruktiv helfen kann. War früher mal Contributor bei OpenEmbedded (alt) und verwende es jeden Tag in der Arbeit. Von buildroot bin ich schon lange weg, da meiner Meinung nach OpenEmbedded bei weitem flexibler ist.
Bei Yocto ist wer dafür verantwortlich, dass es Sicherheitspatches gibt und wer spielt diese ein? Da Yocto so ein wenig was von LFS hat, gibt es keine zentrale Sicherheitsarchitektur, Sicherheitspatches existieren zwar und werden eingepflegt, aber ein "Hersteller" muss das auch kompilieren und verteilen.
Das ist absolut ungeeignet für IoT. Am Raspberry Pi sieht man, wie es besser geht, obwohl mir ein echtes Debian auf dem Pi noch lieber wäre.
Yocto ist nett für Systeme, die später nie wieder angefasst werden müssen, weil sie autark arbeiten. Aber für alles andere muss zwingend eine Updatestrategie her. Und da Yocto auch gerne auf Industriemaschinen eingesetzt wird, muss die Strategie über 25 und mehr Jahre gehen. Ansonsten gibt es irgendwann Blinkenlights in der Produktionshalle.
Bei Yocto ist der Hersteller für die Sicherheitspatches und das Verteilen davon verantwortlich. Jeder kann fehlende Patches einreichen. Yocto ist, wie du schon Sagst ein Baukasten um sich ein Linux zu Zimmern. Gerade deswegen ist es ja für Embedded so gut geeignet. Weil jeder Hersteller etwas anderes will. Auch eine Langzeitpflege von 25 Jahre müsste ein Hersteller tragen. Dazu braucht es dann aber auch längere Linux Kernel LTS Versionen. Was es im Moment so nicht gibt.
Ich bin mir aber auch sehr sicher, dass der Hersteller vom Raspberry Pi dir die nicht so lange zur Verfügung stellt. Des weiteren gibt es bei dem angesprochenem Debian auch keine offiziellen LTS. Erst recht keine die 25 Jahre lang dauern.
Die Risiken werden auf den Kunden abgewälzt, indem man sich selbst von jeder Haftung freistellt. In der IT geht das sonderbarerweise - ganz im Gegensatz zu den herkömmlichen Branchen.
Weiss auch nicht, warum die letzteren noch nicht auf den Trichter gekommen sind, ihr Produkt für so komplex zu erklären, dass sie keine Haftung dafür übernehmen können. Aber vermutlich passiert das nun, indem das IoT in die klassischen Branchen einsickert.
Sicherheitspatches existieren zwar und werden eingepflegt [...]
Das ist absolut ungeeignet für IoT. Am Raspberry Pi sieht man, wie es besser geht, obwohl mir ein echtes Debian auf dem Pi noch lieber wäre.
Sicherheitspatches werden bei Debian auch nicht eingepflegt. Zum Beispiel werden die SHA-1Keys erst 10 Jahre (!) nach Bekanntwerden der Schwächen langsam abgelöst. Insofern müsstest du dich in Punkto Sicherheit bei Yocto wie zu Hause fühlen.
Sicherheitspatches existieren zwar und werden eingepflegt [...]
Das ist absolut ungeeignet für IoT. Am Raspberry Pi sieht man, wie es besser geht, obwohl mir ein echtes Debian auf dem Pi noch lieber wäre.
Sicherheitspatches werden bei Debian auch nicht eingepflegt. Zum Beispiel werden die SHA-1Keys erst 10 Jahre (!) nach Bekanntwerden der Schwächen langsam abgelöst. Insofern müsstest du dich in Punkto Sicherheit bei Yocto wie zu Hause fühlen.
Sicherheitspatches existieren zwar und werden eingepflegt [...]
Das ist absolut ungeeignet für IoT. Am Raspberry Pi sieht man, wie es besser geht, obwohl mir ein echtes Debian auf dem Pi noch lieber wäre.
Sicherheitspatches werden bei Debian auch nicht eingepflegt. Zum Beispiel werden die SHA-1Keys erst 10 Jahre (!) nach Bekanntwerden der Schwächen langsam abgelöst. Insofern müsstest du dich in Punkto Sicherheit bei Yocto wie zu Hause fühlen.
Von Alexander N. am Fr, 17. November 2017 um 14:04 #
Und ich kann aus eigener Erfahrung berichten warum Yocto eben keine gute Wahl für Embedded Linux Systeme ist. Es fängt allein schon mit der Vorbelastung an. Yocto ist designed für die Hardwarehersteller, die damit sehr einfach ein Referenz BSP für ihre Geräte und damit ihrer Verpflichtung nachkommen können. Wenn es aber zu uns Entwicklern kommt ist es der letzte Rotz. Alleine nur die komplette Inkonsistenz der Rezepte und das tiefe Eingreifen in die Buildsysteme der verschiedenen Projekte (allen voran Qt, dessen configure/make komplett ad absurdum durch die Zaubervariablen von Yocto geführt wird) bringen mir jedes Mal die Galle hoch. Der zweite große Knackpunkt ist das Top-Bottom Vorgehen. Anstatt vom Minimalsystem auszugehen bekommt man einen riesigen Klotz vorgesetzt den man dann abspecken darf. Diese beiden Punkte macht Buildroot zB. deutlich deutlich besser. Buildroot erfindet auch das Rad nicht neu, sondern nutzt ganz simple Standard Makefiles.
Von Alexander N. am Fr, 17. November 2017 um 14:07 #
Ach und das Nervigste (für mich) hätte ich fast vergessen: mal einen Build ohne diese Drecks nicht standardkonforme Busybox und evtl. mit systemd - ein Ding der Unmöglichkeit. Da bleiben Leichen von Busybox im Image und systemd wird zwar als Init genutzt für den Login dann aber weiter Busybox statt LoginKit.
Von Zaubervariable am Mo, 20. November 2017 um 09:23 #
Die Yocto Zaubervariablen sind, wie Yocto ganz allgemein auch, sehr gut dokumentiert. Vorausgesetzt man verfügt über halbwegs fähige Entwickler, lässt sich damit nachvollziehbar alles bauen, vom Minimalsystem mit wenigen MB bis hin zum kompletten Desktop.
Von KalleKralle am Mi, 13. Dezember 2017 um 20:03 #
Viel Geschwafel "Yocto ist eine gute Wahl" JA UND WARUM?
Ich kenne nur Debian aufm Arm. Das ist kinderleicht zu bauen und auszustaffieren, wie ein Debian aufm PC, das kann man dank qemu auch von dort aus machen. Es fühlt sich an wie ein debian und ist auch eines. Es gibt updates die man automatisch einspielen kann, eben wie aufm PC.
Builtroot wenn man nur das allernötigste haben will, also nen MC mit nem Kernel und das Programm das ausgeführt werden soll und die Treiber die man braucht ohne Distrogedöhns. Meist will man aber doch ein bischen "Komfort" haben, da nimmt man dann halt doch wieder ein abgespecktes Debian.
Von KalleKralle am Mi, 13. Dezember 2017 um 20:17 #
Viel Geschwafel "Yocto ist eine gute Wahl" JA UND WARUM?
Ich kenne nur Debian aufm Arm. Das ist kinderleicht zu bauen und auszustaffieren, wie ein Debian aufm PC, das kann man dank qemu auch von dort aus machen. Es fühlt sich an wie ein debian und ist auch eines. Es gibt updates die man automatisch einspielen kann, eben wie aufm PC.
Builtroot wenn man nur das allernötigste haben will, also nen MC mit nem Kernel und das Programm das ausgeführt werden soll und die Treiber die man braucht ohne Distrogedöhns. Meist will man aber doch ein bischen "Komfort" haben, da nimmt man dann halt doch wieder ein abgespecktes Debian.
Yocto ist zu groß für IOT Systeme.
Das Minimal System min. 60 MB
Bei Buildroot gleicher Konfiguration ist deutlich kleiner - 10 MB.
k.T.
Hi,
ich gebe dir erst einmal recht und behaupte danach das Gegenteil.
Das was du sagst stimmt zwar warscheinlich, mit default Images, aber man kann sich bei Yocto frei aussuchen was man haben will. Das heißt man kann die Größe anpassen.
Was man zu Yocto verstehne muss ist, es basiert auf OpenEmbedded Core, welches buildbot verwendet um ein System zu erstellen. Buildbot ist abgeleitet von den gentoo ebuilds. Man erkennt das mittlerweile allerdings nicht mehr so gut.
Es gibt bei OpenEmbedded mehrere Layer. Es gitbt auch verschiedene Paketsysteme und libcs zur Auswahl.
Du kannst dir nun ein base-image erstellen welches nur aus dem Kernel besteht. Diesen kannst du dir konfigurieren wie du willst .Wenn du eine eigene MACHINE erstellst. Dann kannst du einen Kernel und ein Image definieren. Das minimalste Image mit dem du etwas anfangen kannst ist z.B. nur der Kernel (2MB?) und eine busy box (4MB?). Die busybox config kannst du auch frei in einem eigenen Layer überschreiben. Die libc kannst du dir auch frei aussuchen (~1MB). Also wenn dir die Busybox config von Yocto nicht gefällt, weil sie zu groß ist. Damit hast du ein bootbares Image mit ~7Mb. Je nachdem was du halt willst. Man kann mit Yocto sehr kleine Images bauen. Als Beispiel sei dafür z.B. der Bootloader vom alten Zaurus genannt (~2MB) welcher kexec verwendet um danach etwas größeres zu laden.
Es kommt also darau an was du haben willst und wie du es konfigurierst. Du kannst ziemlich sicher das selbe Image erstellen, welches bei buildroot am ende raus kommt. Die Frage ist nur ob es das schon gibt, oder wieviel arbeit du da reinsteckst. Je mehr Kontrolle du willst, z.B. systemd ja oder nein, udev oder mdev etc. Ist es vielleicht einfacher eine eigene Distribution zu erstellen, wie eine abzuändern. Ich verwene z.B. nur oe-core + openebedded + ansgroem based distribution + machine layer + product layer. Und die images die da raus kommen sind weit unter 32 MB.
Was für ein Image meinst du denn genau? Bei dem vergleich Yocto vs buildroot. Wie sieht da deine buildroot config aus und wie die von Yocto? Ich bin mir sehr sicher das selbe Image mit OpenEmbedded bauen zu können.
Bin gespannt ob ich dir da konstruktiv helfen kann. War früher mal Contributor bei OpenEmbedded (alt) und verwende es jeden Tag in der Arbeit. Von buildroot bin ich schon lange weg, da meiner Meinung nach OpenEmbedded bei weitem flexibler ist.
Reden wir mal über IT-Security.
Bei Yocto ist wer dafür verantwortlich, dass es Sicherheitspatches gibt und wer spielt diese ein? Da Yocto so ein wenig was von LFS hat, gibt es keine zentrale Sicherheitsarchitektur, Sicherheitspatches existieren zwar und werden eingepflegt, aber ein "Hersteller" muss das auch kompilieren und verteilen.
Das ist absolut ungeeignet für IoT. Am Raspberry Pi sieht man, wie es besser geht, obwohl mir ein echtes Debian auf dem Pi noch lieber wäre.
Yocto ist nett für Systeme, die später nie wieder angefasst werden müssen, weil sie autark arbeiten. Aber für alles andere muss zwingend eine Updatestrategie her. Und da Yocto auch gerne auf Industriemaschinen eingesetzt wird, muss die Strategie über 25 und mehr Jahre gehen. Ansonsten gibt es irgendwann Blinkenlights in der Produktionshalle.
Bei Yocto ist der Hersteller für die Sicherheitspatches und das Verteilen davon verantwortlich. Jeder kann fehlende Patches einreichen. Yocto ist, wie du schon Sagst ein Baukasten um sich ein Linux zu Zimmern. Gerade deswegen ist es ja für Embedded so gut geeignet. Weil jeder Hersteller etwas anderes will.
Auch eine Langzeitpflege von 25 Jahre müsste ein Hersteller tragen. Dazu braucht es dann aber auch längere Linux Kernel LTS Versionen. Was es im Moment so nicht gibt.
Ich bin mir aber auch sehr sicher, dass der Hersteller vom Raspberry Pi dir die nicht so lange zur Verfügung stellt. Des weiteren gibt es bei dem angesprochenem Debian auch keine offiziellen LTS. Erst recht keine die 25 Jahre lang dauern.
Die Risiken werden auf den Kunden abgewälzt, indem man sich selbst von jeder Haftung freistellt. In der IT geht das sonderbarerweise - ganz im Gegensatz zu den herkömmlichen Branchen.
Weiss auch nicht, warum die letzteren noch nicht auf den Trichter gekommen sind, ihr Produkt für so komplex zu erklären, dass sie keine Haftung dafür übernehmen können. Aber vermutlich passiert das nun, indem das IoT in die klassischen Branchen einsickert.
Sicherheitspatches werden bei Debian auch nicht eingepflegt. Zum Beispiel werden die SHA-1Keys erst 10 Jahre (!) nach Bekanntwerden der Schwächen langsam abgelöst. Insofern müsstest du dich in Punkto Sicherheit bei Yocto wie zu Hause fühlen.
Sicherheitspatches werden bei Debian auch nicht eingepflegt. Zum Beispiel werden die SHA-1Keys erst 10 Jahre (!) nach Bekanntwerden der Schwächen langsam abgelöst. Insofern müsstest du dich in Punkto Sicherheit bei Yocto wie zu Hause fühlen.
Sicherheitspatches werden bei Debian auch nicht eingepflegt. Zum Beispiel werden die SHA-1Keys erst 10 Jahre (!) nach Bekanntwerden der Schwächen langsam abgelöst. Insofern müsstest du dich in Punkto Sicherheit bei Yocto wie zu Hause fühlen.
Und ich kann aus eigener Erfahrung berichten warum Yocto eben keine gute Wahl für Embedded Linux Systeme ist. Es fängt allein schon mit der Vorbelastung an. Yocto ist designed für die Hardwarehersteller, die damit sehr einfach ein Referenz BSP für ihre Geräte und damit ihrer Verpflichtung nachkommen können. Wenn es aber zu uns Entwicklern kommt ist es der letzte Rotz. Alleine nur die komplette Inkonsistenz der Rezepte und das tiefe Eingreifen in die Buildsysteme der verschiedenen Projekte (allen voran Qt, dessen configure/make komplett ad absurdum durch die Zaubervariablen von Yocto geführt wird) bringen mir jedes Mal die Galle hoch. Der zweite große Knackpunkt ist das Top-Bottom Vorgehen. Anstatt vom Minimalsystem auszugehen bekommt man einen riesigen Klotz vorgesetzt den man dann abspecken darf. Diese beiden Punkte macht Buildroot zB. deutlich deutlich besser. Buildroot erfindet auch das Rad nicht neu, sondern nutzt ganz simple Standard Makefiles.
Ach und das Nervigste (für mich) hätte ich fast vergessen: mal einen Build ohne diese Drecks nicht standardkonforme Busybox und evtl. mit systemd - ein Ding der Unmöglichkeit. Da bleiben Leichen von Busybox im Image und systemd wird zwar als Init genutzt für den Login dann aber weiter Busybox statt LoginKit.
Die Yocto Zaubervariablen sind, wie Yocto ganz allgemein auch, sehr gut dokumentiert. Vorausgesetzt man verfügt über halbwegs fähige Entwickler, lässt sich damit nachvollziehbar alles bauen, vom Minimalsystem mit wenigen MB bis hin zum kompletten Desktop.
Viel Geschwafel "Yocto ist eine gute Wahl" JA UND WARUM?
Ich kenne nur Debian aufm Arm. Das ist kinderleicht zu bauen und auszustaffieren, wie ein Debian aufm PC, das kann man dank qemu auch von dort aus machen. Es fühlt sich an wie ein debian und ist auch eines. Es gibt updates die man automatisch einspielen kann, eben wie aufm PC.
Builtroot wenn man nur das allernötigste haben will, also nen MC mit nem Kernel und das Programm das ausgeführt werden soll und die Treiber die man braucht ohne Distrogedöhns. Meist will man aber doch ein bischen "Komfort" haben, da nimmt man dann halt doch wieder ein abgespecktes Debian.
Was ist jetzt nochmal der Vorteil von Yocto?
Viel Geschwafel "Yocto ist eine gute Wahl" JA UND WARUM?
Ich kenne nur Debian aufm Arm. Das ist kinderleicht zu bauen und auszustaffieren, wie ein Debian aufm PC, das kann man dank qemu auch von dort aus machen. Es fühlt sich an wie ein debian und ist auch eines. Es gibt updates die man automatisch einspielen kann, eben wie aufm PC.
Builtroot wenn man nur das allernötigste haben will, also nen MC mit nem Kernel und das Programm das ausgeführt werden soll und die Treiber die man braucht ohne Distrogedöhns. Meist will man aber doch ein bischen "Komfort" haben, da nimmt man dann halt doch wieder ein abgespecktes Debian.
Was ist jetzt nochmal der Vorteil von Yocto?