Yocto can be incredibly simple, this is my favorite example: <a href="https://github.com/bootlin/simplest-yocto-setup/">https://github.com/bootlin/simplest-yocto-setup/</a><p>Only the kernel and bootloader usually need to be specialized for most modern arm boards: the userland can be generic. Most of the problems people have with yocto are due to layers from hardware vendors which contain a lot of unnecessary cruft.
Last time I tried Yocto, some people here on HN suggested that I try Buildroot instead.<p>I don’t see so many mentions of Buildroot in this thread yet.<p>If you are interested in Yocto it might be worth having a look at Buildroot as well. I liked it a lot when I tried it.<p>My thread from years ago, where people told me about Buildroot:<p><a href="https://news.ycombinator.com/item?id=18083506">https://news.ycombinator.com/item?id=18083506</a><p>The website of Buildroot:<p><a href="https://buildroot.org/" rel="nofollow">https://buildroot.org/</a>
Q: How do you guys centrally update field devices?<p>I am working on professionalizing our IOT setup that currently consists of a few dozen raspberries which run docker containers. They are individually updated by sshing into them and running apt update manually. Docker containers are deployed with a commercial solution.
I want to have a centralized way to update the OSes, but it does not really make sense for our small team to introduce yocto knowledge, because that would make us fall behind development schedule even more. Also, the hardware needs are just too boring to justify rolling our own os.
I have not yet found a hardware independent Linux distro that can be reliably updated in an IOT context.<p>I am now looking if we can buy ourselves out of this problem.
Ubuntu Core goes in the right direction, but we don't want to make us dependent on the snap store.
Advantech has a solution for central device management with Ota updates, maybe we are going that route.<p>How do you guys update field devices centrally? Thanks!
Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on Yocto and this thing <i>suuuuucks</i>, I threw a docker image there and called it a day".<p>Which is a pity, because when used correctly it's really powerful!<p>From the article, I can't help but mention that one third of the "key terminology" is about codenames. What do people have with codenames? I can count and easily know that 5 comes after 4. But I don't know how to compare Scarthgap and Dunfell (hell, I can't even remember them).
Love Yocto! It has a learning curve but it took about a week from nothing to an embedded image including Swift and Flutter apps, U-Boot, etc. A curve worth climbing.
I am actually scared of switching jobs in case my next job doesn't involve yocto.<p>How would I make use of the countless hours I have already invested in this piece of software? Countless keywords and the dark magic of the ever changing syntax.<p>But when it works it works..
>you can’t run “apt update”<p>if you want to get a little weird, you can tell yocto to compile everything into deb packages and host them yourself with something like aptly
I read just the title and wondered if this was a yocto post.<p>I have (accident) become the yocto SME at my $dayjob. Probably the biggest positive has been free SBOM generation, and cooking things like kSLOC counts into recipes.<p>The learning curve stinks, the build suite is very powerful.
As someone in the Software Supply Chain business. Yocto SBOMs are considered low quality because they include things that do and do not exist in the final compiled artifact. When you compare what exists inside, physically from a binary perspective, what is included in the manifest, and what is generated in the build root, you will find they will never align unless you get creative and map artifacts together. Today they are accepted as meeting the compliance checkbox, but once the industry matures, they will need to adjust their approach.
This toolchain is about half my dayjob.<p>Bitbake is a meta-compiler, and the tool suite is very powerful. Just realize to this means you need to be an expert error-message debugger, and able to jump into (usually c/c++) code to address issues and flow patches upstream.<p>It really is gratifying when you finally kick out a working image.
Ah BitBake and OpenEmbedded. That’s what Palm used for WebOS. It was simultaneously amazing and a nightmare. In 2024 you should not be using it. There are better alternatives.
> One limitation of the current disk image for Rock Pi is that you don’t have a functional TTY.<p>I believe on systemd-based systems these are service-units you need to enable, and with yocto, possibly install?<p><pre><code> systemctl enable -now getty@tty0 (etc)
</code></pre>
Or something like that. I’ve experienced similar issues while working on a x86 based NAS and also on the RPi when enabling serial-consoles.
What I would really like is something like Docker to build images for my raspberry pis. Just a single file, shell commands, that's it. I feel that Yocto is already too complicated if you want a reproducable setup for you raspberry pi at home.
I think long term yocto and build root are going to be replaced by container tooling. Theres not that big of a difference between compiling an OS image and building a container image.
The one thing I still don't like about Yocto is the setup process. You need to check out multiple layer repositories, make sure you check out the right commit from each repository (need reproducibility!), put everything in the correct directory structure, and then set up `bblayers.conf` and `local.conf`.<p>I've got a script that does all this, but it's still a pain.<p>I've been thinking about putting everything in a monorepo, and adding poky, the third-party layers, and my proprietary layers as submodules. Then, when the build server needs to check out the code or a new developer needs to be onboarded, they just `git clone` and `git submodule update`. When it's time to update to the latest version of Yocto, update your layer submodules to the new branch. If you need to go back in time and build an older version of your firmware image, just roll back to the appropriate tag from your monorepo.<p>Anyone else have another solution to this issue?<p>Oh yeah, and the build times. It's crazy disk I/O bound. But if you're using something like Jenkins on an AWS instance with 96GB of RAM, set up your build job to use `/tmp` as your work directory and you can do a whole-OS CI build in minutes.