Hallo,
hat sich denn schon mal jemand mit OpenEmbedded beschäftigt? Ich sehe, daß es patches gibt, die von dort übernomen werden und in Freetz einlaufen.
Der Grund warum ich überhaupt darüber nachdenke, ob es nicht vorteilhaft wäre, Freetz auf OpenEmbedded als Grundlage zu gestalten, sind die über 1000 Pakete, die es bereits an OpenEmbedded angepasst gibt. Sofern ich OE richtig verstanden habe, werden plattformspezifische Unterschiede durch patches gelöst, die über das BitBaker Framework injiziert werden.
Es scheint:
*) OpenEmbedded wurde ursprünglich für ARM CPUs geschaffen.
*) OpenEmbedded ist bereits als Paket für die meisten LinuxDistros vorhanden. Das hieße, daß man sich das mit dem Package-Manager seiner Wahl installiert (also deren cross-compiler toolchain und ihr meta-framework)
*) OpenEmbedded läuft auch unter OS X native.
*) OpenEmbedded läuft jedoch *nicht* unter Windows/Cygwin. Der Port-Versuch führt zu einem 404. Ansonsten hätte man auch auf die Wartung einer Freetz-VM verzichten können.
*) Es gibt über 1000 Pakete, die für Embedded Devices interessant sind. Das wäre der Part, an dem Freetz enorm profitieren würde.
Ich habe mich nur oberflächlich damit beschäftigt (drüber gelesen). Auch möchte ich nicht, daß dies hier als Kritik am jetzigen build-system verstanden wird, denn ich finde es schon ganz schön beeindruckend, was die Entwickler von Freetz geleistet haben. Und es läuft ja auch anscheinend ganz gut ("never change a running team")
Der Gedanke ist halt, daß an OE viel mehr Leute mitarbeiten, Firmen, z.B. und man somit von der geteilten Arbeit profitiert (und sich auch sicherlich ne Menge neue Probleme einhandelt, lol).
Über 1000 Pakete...! Brums. Brums.
hat sich denn schon mal jemand mit OpenEmbedded beschäftigt? Ich sehe, daß es patches gibt, die von dort übernomen werden und in Freetz einlaufen.
Der Grund warum ich überhaupt darüber nachdenke, ob es nicht vorteilhaft wäre, Freetz auf OpenEmbedded als Grundlage zu gestalten, sind die über 1000 Pakete, die es bereits an OpenEmbedded angepasst gibt. Sofern ich OE richtig verstanden habe, werden plattformspezifische Unterschiede durch patches gelöst, die über das BitBaker Framework injiziert werden.
Es scheint:
*) OpenEmbedded wurde ursprünglich für ARM CPUs geschaffen.
*) OpenEmbedded ist bereits als Paket für die meisten LinuxDistros vorhanden. Das hieße, daß man sich das mit dem Package-Manager seiner Wahl installiert (also deren cross-compiler toolchain und ihr meta-framework)
*) OpenEmbedded läuft auch unter OS X native.
*) OpenEmbedded läuft jedoch *nicht* unter Windows/Cygwin. Der Port-Versuch führt zu einem 404. Ansonsten hätte man auch auf die Wartung einer Freetz-VM verzichten können.
*) Es gibt über 1000 Pakete, die für Embedded Devices interessant sind. Das wäre der Part, an dem Freetz enorm profitieren würde.
Ich habe mich nur oberflächlich damit beschäftigt (drüber gelesen). Auch möchte ich nicht, daß dies hier als Kritik am jetzigen build-system verstanden wird, denn ich finde es schon ganz schön beeindruckend, was die Entwickler von Freetz geleistet haben. Und es läuft ja auch anscheinend ganz gut ("never change a running team")
Der Gedanke ist halt, daß an OE viel mehr Leute mitarbeiten, Firmen, z.B. und man somit von der geteilten Arbeit profitiert (und sich auch sicherlich ne Menge neue Probleme einhandelt, lol).
Über 1000 Pakete...! Brums. Brums.
