Dev/Embedded/NotOEYocto - Revision history

Drizzt at 11:43, 5 December 2024

2024-12-05T11:43:00Z

← Older revision		Revision as of 13:43, 5 December 2024
Line 48:		Line 48:
	The problem is that I'm not the only one experiencing these problems.		The problem is that I'm not the only one experiencing these problems.

	But what's bad is that rather than going back to common "old" working solutions and writing tutorials or sharing knowledge, people ~~know~~ bundle their whole mess in containers (VMs, docker, ...) in order to "make it easier to reproduce and share".		But what's bad is that rather than going back to common "old" working solutions and writing tutorials or sharing knowledge, people now bundle their whole mess in containers (VMs, docker, ...) in order to "make it easier to reproduce and share".

	That's not sharing, that's obfuscating.		That's not sharing, that's obfuscating.

	Sad.		Sad.

Drizzt: /* Conclusion */

2021-06-22T15:31:29Z

Conclusion

← Older revision		Revision as of 17:31, 22 June 2021
Line 48:		Line 48:
	The problem is that I'm not the only one experiencing these problems.		The problem is that I'm not the only one experiencing these problems.

	But what's bad is that rather than going back to common "old" working solutions and writing tutorials or sharing knowledge, people know bundle their whole mess in containers in order to "make it easier to reproduce and share".		But what's bad is that rather than going back to common "old" working solutions and writing tutorials or sharing knowledge, people know bundle their whole mess in containers (VMs, docker, ...) in order to "make it easier to reproduce and share".

	That's not sharing, that's obfuscating.		That's not sharing, that's obfuscating.

	Sad.		Sad.

Drizzt: /* (Bad) Experiences */

2021-06-22T15:30:18Z

(Bad) Experiences

← Older revision		Revision as of 17:30, 22 June 2021
Line 43:		Line 43:
	Of course, I also have a few (lot ?) of bad experiences with these tools.		Of course, I also have a few (lot ?) of bad experiences with these tools.

	Even if I managed to use them once or twice (OpenWRT on a WRT54GL ... and that's the only one !) I have had many problems with these tools. They range from impossibility to reproduce the same result on different computers, to impossibility to make changes as it broke the whole build process.		Even if I managed to use them once or twice (OpenWRT on a WRT54GL ... and that's the only one which worked fine !) I have had many problems with these tools. They range from impossibility to reproduce the same result on different computers, to impossibility to make changes as it broke the whole build process.

	== Conclusion ==		== Conclusion ==

Drizzt: /* Inconsistency */

2019-10-17T03:19:03Z

Inconsistency

← Older revision		Revision as of 05:19, 17 October 2019
Line 9:		Line 9:
	Or "Don't do it ... but we're doing it anyway".		Or "Don't do it ... but we're doing it anyway".

	Most of these solutions states that it's not possible (which is false) or not a good idea (false too) to use common distributions on embedded systems~~, but~~ as it's impossible for users to continuously update their systems by rebuilding everything each time or continuously track all their tools and packages for security or stability issues, they finally ... reproduce exactly the same kinds of mechanisms, creating new distributions ....		Most of these solutions states that it's not possible (which is false) or not a good idea (false too) to use common distributions on embedded systems.<br />
			But as it's impossible for users to continuously update their systems by rebuilding everything each time or continuously track all their tools and packages for security or stability issues, they finally ... reproduce exactly the same kinds of mechanisms, creating new distributions ....

	== Impossible to maintain ==		== Impossible to maintain ==

Drizzt: /* Inconsistency */

2019-10-15T16:10:23Z

Inconsistency

← Older revision		Revision as of 18:10, 15 October 2019
Line 9:		Line 9:
	Or "Don't do it ... but we're doing it anyway".		Or "Don't do it ... but we're doing it anyway".

	Most of these solutions states that it's not possible (which is false) or not a good idea (false too) to use common distributions on embedded systems, but as it's impossible for users to continuously update their systems by rebuilding everything each time of continuously track all their tools and packages for security or stability issues, they finally ... reproduce exactly the same kinds of mechanisms, creating new distributions ....		Most of these solutions states that it's not possible (which is false) or not a good idea (false too) to use common distributions on embedded systems, but as it's impossible for users to continuously update their systems by rebuilding everything each time or continuously track all their tools and packages for security or stability issues, they finally ... reproduce exactly the same kinds of mechanisms, creating new distributions ....

	== Impossible to maintain ==		== Impossible to maintain ==

Drizzt at 16:07, 15 October 2019

2019-10-15T16:07:01Z

← Older revision		Revision as of 18:07, 15 October 2019
Line 1:		Line 1:
			{{DISPLAYTITLE:Do not use Yocto or OpenEmbeded}}
	== In short ==		== In short ==
	I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.<br />		I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.<br />

Drizzt: Created page with "== In short == I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.
They are most of the time a problem, not a solution, and hide al..."

2019-10-15T16:06:02Z

Created page with "== In short == I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.<br /> They are most of the time a problem, not a solution, and hide al..."

New page

== In short ==
I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.<br />
They are most of the time a problem, not a solution, and hide all the interesting parts behind complex build systems and tend to promote the wrong approach to embedded systems (from my point of view at least).

I'll try to explain why here.

== Inconsistency ==
Or "Don't do it ... but we're doing it anyway".

Most of these solutions states that it's not possible (which is false) or not a good idea (false too) to use common distributions on embedded systems, but as it's impossible for users to continuously update their systems by rebuilding everything each time of continuously track all their tools and packages for security or stability issues, they finally ... reproduce exactly the same kinds of mechanisms, creating new distributions ....

== Impossible to maintain ==
As I partly exposed in the previous point, when you use one of the common image builder solutions, you have to take care of tracking security patches, fixes, or any kind of upgrades.

You must endorse the role of the software packagers from the distribution and make sure each version of each library is supported by each software, and so on.

In common distributions, this job is made by the package maintainers, and most of the time shared among many distributions.

When using common distributions, security issues are reported by the whole community, and fixed quite quickly.

When using a custom system, built by you, used only by you, you're the only one performing tests, no one helps you. You're out of the community, on your own.

== Hiding information and knowledge ==
The sets of scripts used to build the system tends to become a mess of hundreds of chunks, overriding one another for the sake of modularity, and making it very complicated to identify the source of failure when the process fails.

The end user doesn't know how things are done, it becomes some kind of magic, and knowledge is kept hidden, which is the opposite of the open-source philosophy.

This goes up to a point where even "professionnals" do not know what they are doing, and provide a Yocto Board Support Package (BSP) only because they have to (because all the others are doing it), but include links to unbundled binaries within their packages or worse, provide multiple compilers which are in fact only links to a single one, making the results unusable.

== Huge amount of disk space used ==
Each BSP tends to download sources for everything, including the cross-compilation toolchain when it's not badly bundled as binaries, and build everything from sources, which results in huge directories of tens of GigaBytes (or hundreds of them) while the whole project should fit in barely more than a few hundred Megabytes.

== Not using distribution provided tools ==
Many of theses solutions either rebuild most of the tools or bundle binaries (and associated libraries) for them, while these tools are available in most common distributions.

The problem is that those tools are out of the distribution packaging process, and will not receive fixes or improvements.

If the tools from common distributions lack some specific functionality or have bugs, then the right way to do it is to help fix or improve existing, bundled tools, not get out of the distribution path and start doing things on the sideways.

== (Bad) Experiences ==
Of course, I also have a few (lot ?) of bad experiences with these tools.

Even if I managed to use them once or twice (OpenWRT on a WRT54GL ... and that's the only one !) I have had many problems with these tools. They range from impossibility to reproduce the same result on different computers, to impossibility to make changes as it broke the whole build process.

== Conclusion ==
The problem is that I'm not the only one experiencing these problems.

But what's bad is that rather than going back to common "old" working solutions and writing tutorials or sharing knowledge, people know bundle their whole mess in containers in order to "make it easier to reproduce and share".

That's not sharing, that's obfuscating.

Sad.

Dev/Embedded/NotOEYocto - Revision history

Drizzt at 11:43, 5 December 2024

Drizzt: /* Conclusion */

Drizzt: /* (Bad) Experiences */

Drizzt: /* Inconsistency */

Drizzt: /* Inconsistency */

Drizzt at 16:07, 15 October 2019

Drizzt: Created page with "== In short == I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors. They are most of the time a problem, not a solution, and hide al..."

Drizzt: Created page with "== In short == I do not like common embedded "solutions" like OpenEmbeded, Yocto, or their predecessors.
They are most of the time a problem, not a solution, and hide al..."