Yocto Project - User contributions [en]

Community Guidelines

2024-06-13T10:30:19Z

Josef Holzmayr: Add link to "Developer Interaction Tips" page

==Overview and General Guidlines==

We want to keep the Yocto Community a great place to participate, but we need your help to keep it that way. While we have specific guidelines for various tools, in general, you should:

* '''Be nice''': Be courteous and polite to fellow members of the list.
* '''Respect other people''': No regional, racial, gender or other abuse will be tolerated.
* '''Keep it clean''': Keep the language clean (no swearing)
* '''Be helpful''': Be patient with new people and be willing to jump in to answer questions.
* '''Stay calm''': The written word is always subject to interpretation, so give people the benefit of the doubt and try not to let emotions get out of control.
* '''Keep it legal''': Make sure that you have the legal right to post your content and are not violating copyright or other laws.
* '''Adhere to Terms of Service''': All community contributions are also subject to our [https://www.yoctoproject.org/about/terms-of-service Terms of Service].
* some additional tips are assembled on the [[Developer Interaction Tips]] page.

==Read Before Contributing - Search for existing answers==
'''IMPORTANT: Before you contribute, be sure that you have done a thorough search to see if your question has already been answered.''' We've already answered many questions, and you will get a better response from people if you have already done your due diligence to find obvious or partial answers.
* Search this wiki
* Search our [https://www.yoctoproject.org/tools-resources/community/mailing-lists mailing lists]
* Search the [http://www.yoctoproject.org/ Yocto Project website]

==Wiki Guidelines==

You can [http://www.yoctoproject.org/documentation learn more about our documentation] on the Yocto website, and if you are unfamiliar with MediaWiki syntax, we have a short how-to document with instructions for [[Using the Wiki]].

Creating articles in the wiki is a collaborative process. After you have written your piece others may:
* Edit
* Alter
* Adapt
* Add

So don't worry about making your article perfect the first time through. Don't hesitate to add content you think is useful and don't hesitate to make edits where you think you can help. There's always somebody to fix anything that breaks.

'''Posting Guidelines'''

Here are a few guidelines to keep in mind when using the Yocto wiki:
* '''Search first''': Before creating a new page or making significant contributions to a page, please do a quick search to make sure that you aren't duplicating existing content on the wiki or other areas on the Yocto Project website.
* '''Must be a registered user''': If you want to edit the wiki, you need to [[Special:UserLogin|create an account]] and confirm your email address (you'll get an email after registering with a confirmation link). Anyone can create an account.
* '''Contribute''': The wiki is a resource for anyone to use. Just keep the content relevant, that is anything related to Yocto as long as it meets our other guidelines should be appropriate.
* '''Make improvements''': If you find a typo or inaccurate information, just fix it.
* '''Respect links''': Please provide [http://www.mediawiki.org/wiki/Help:Redirects redirects] when you move content. Many people use the wiki and may have created bookmarks or linked to your content.

'''The Wiki is Public'''

Everything in the wiki is public.

Every edit and every new page created goes into the [[Special:RecentChanges|recent changes]] feed, which means that people will see your edits even if you haven't yet linked to a page.

Once it's out there, it's public.
* Technically, administrators can delete things, but the wiki content may be mirrored, has feeds and is in the Google cache, so deleting something doesn't make it go away.
* When you delete content from a page, the original content will still remain in the history for that page.

==Mailing List Guidelines==

[https://www.yoctoproject.org/tools-resources/community/mailing-lists More information about our mailing lists] can be found on the Yocto Project website.

'''Keep It Short'''

Remember that thousands of copies of your message will exist in mailboxes:
* Keep your messages as short as possible.
* Avoid including log output (select only the most relevant lines, or place the log on a website or in a [http://pastebin.com/ pastebin] instead)
* Don't excessively quote previous messages in the thread (trim the quoted text down to the most recent/relevant messages only).

'''Use Proper Posting Style'''

* '''No HTML or Rich Text''': Set your mailer to send only plain text messages to avoid getting caught in our spam filters.
* '''Do not top post''': Top posting is replying to a message on "top" of the quoted text of the previous correspondence. This is highly unwanted in mailing lists because it increases the size of the daily digests to be sent out & is highly confusing and incoherent. By default, most email clients top post. Please, remove the irrelevant part of the previous communication(in case of more than a single correspondence) and use bottom, interleaved posting.
* '''Using interleaved posting''': Bottom, interleaved posting is replying to the relevant parts of the previous correspondence just below the block(s) of sentences. For a comment to another block of sentences of the same quoted text, you should move below that relevant block again. Do not reply below the whole of the quoted text. Also remove any irrelevant text.
* '''Use links''': Please provide URLs to articles wherever possible. Avoid cutting and pasting whole articles especially considering the fact that all may not be interested.
* '''Don't include attached files''': Instead of including attached files, please upload your file to the [[Special:Upload|this wiki]] or another website and post a link to the file from your email message.

'''Do Not Hijack Threads'''

Post new questions or new topics as new threads (new email message). Please do not reply to a random thread with a new question or start an unrelated topic of conversation in an existing thread. This creates confusion and makes it much less likely that you will get a response.

'''Do Not Cross Post'''

Avoid posting to multiple lists simultaneously. Pick a mailing list that is most suitable for your post and just use that. CC'ing multiple lists should be avoided.

'''Subscribers Only'''

Only subscribers can post to our mailing lists. If you would like to contribute to our mailing lists, we think it is only fair that you be a subscriber. Please note that if you want to participate only occasionally, you can subscribe to a list and set your email options to digest or no mail and read the web archives when you want to catch up.

'''Additional Resources'''
* [http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquette.pdf Mailing list guidelines by Shakthi Kannan (PDF)]: Great guideline summary and examples of posting styles.
* [[Contribution_Guidelines]]

==IRC Guidelines==

[https://www.yoctoproject.org/community/mailing-lists/ More information about our IRC channels] can be found on the Yocto website.

Here are a few IRC guidelines:
* '''Don't post chunks''': Avoid posting big chunks of text - use [http://pastebin.com/ pastebin] or a similar service to shorten it to a link.
* '''Register your Nickname''': To avoid confusion and make sure you always have the same name on IRC, you should [https://libera.chat/guides/registration register your nick].
* '''Pick the right channel''': if you aren't sure, you should start in our main #yocto channel.
* '''More information''': this [http://irchelp.org/irchelp/ircprimer.html IRC primer] for new users.
* '''Web access''': If you don't normally use IRC and want to try it out, you can use the [https://web.libera.chat/?channels=#yocto Libera.chat Web IRC] chat.

==Bugzilla Guidelines==

We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in the [https://bugzilla.yoctoproject.org/ Yocto Bugzilla].

* '''Be patient with others''': Sometimes people post imperfect bug reports. In case of missing information, kindly tell reporters how to provide it, and/or suggest what they can do to improve the bug report.
* '''Stay on topic''': Don't start endless debates on topics not directly related to the scope of a specific bug report.
* '''Use proper quoting practices''': Avoid quoting complete previous comments by stripping unneeded lines, and avoid answering above the quoted text.
* '''Don't abuse your privileges''': Submitters have permission to edit their bugs. If you abuse this privilege - for example, by reopening a bug that the maintainers have closed - your privileges will be revoked.

What to do if you find a bug
* '''Search first''': Try to avoid filing duplicates by searching to see whether your issue has already been filed.
* '''Ask''': You can ask on our mailing lists or IRC channels to see if anyone has seen this issue before to gather more details or see if someone has a workaround.
* '''Submit a bug report''': Give us as many details as possible about what happened and how your issue can be reproduced. '''IMPORTANT''': please include the build/commit ID as reported by BitBake, as this will help the team determine whether your bug has been fixed already.
* '''Track our progress''': Get feedback from the development community and track resolution status.
* '''Provide a fix''': Use the tools, project wiki and git source repository in the Yocto Project to fix the problem yourself.

Learn more about [[Bugzilla_Configuration_and_Bug_Tracking|our process for reporting bugs]].

==Contribution Guidelines - Sending Patches==
[[Contribution_Guidelines|Contribution Guidelines]]

[http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded How To Sumbit A Patch To OpenEmbedded]

==Guideline Violations - 3 Strikes Method==
The point of this section is not to find opportunities to punish people, but we do need a fair way to deal with people who are making our community an unpleasant place.
* First occurrence: Public reminder that the behavior is inappropriate according to our guidelines.
* Second occurrence: Private message warning the user that any additional violations will result in removal from the community.
* Third occurrence: Depending on the violation, may include account deletion or banning.

'''Notes:'''
* Obvious spammers are banned on first occurrence. This is necessary to keep the community free of spam.
* Violations are forgiven after 6 months of good behavior.
* Minor formatting / style infractions will be dealt with through education, not the 3 strikes process.
* Extreme violations of a threatening, abusive, destructive or illegal nature will be addressed immediately and are not subject to 3 strikes.
* Contact [[User:Josef Holzmayr|Josef Holzmayr]] to report abuse or appeal violations (mistakes happen & will be corrected).

==Credits==
* [http://wiki.meego.com/Community_guidelines MeeGo Community Guidelines] were the basis for the Yocto Guidelines used under the [http://creativecommons.org/licenses/by/3.0/legalcode Creative Commons Attribution 3.0 License]
* [http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Fedora Mailing List Guidelines] used as a starting point under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported] license.

Community Guidelines

2024-06-13T10:27:32Z

Josef Holzmayr: Change CM from Nico to Josef

==Overview and General Guidlines==

We want to keep the Yocto Community a great place to participate, but we need your help to keep it that way. While we have specific guidelines for various tools, in general, you should:

* '''Be nice''': Be courteous and polite to fellow members of the list.
* '''Respect other people''': No regional, racial, gender or other abuse will be tolerated.
* '''Keep it clean''': Keep the language clean (no swearing)
* '''Be helpful''': Be patient with new people and be willing to jump in to answer questions.
* '''Stay calm''': The written word is always subject to interpretation, so give people the benefit of the doubt and try not to let emotions get out of control.
* '''Keep it legal''': Make sure that you have the legal right to post your content and are not violating copyright or other laws.
* '''Adhere to Terms of Service''': All community contributions are also subject to our [https://www.yoctoproject.org/about/terms-of-service Terms of Service].

==Read Before Contributing - Search for existing answers==
'''IMPORTANT: Before you contribute, be sure that you have done a thorough search to see if your question has already been answered.''' We've already answered many questions, and you will get a better response from people if you have already done your due diligence to find obvious or partial answers.
* Search this wiki
* Search our [https://www.yoctoproject.org/tools-resources/community/mailing-lists mailing lists]
* Search the [http://www.yoctoproject.org/ Yocto Project website]

==Wiki Guidelines==

You can [http://www.yoctoproject.org/documentation learn more about our documentation] on the Yocto website, and if you are unfamiliar with MediaWiki syntax, we have a short how-to document with instructions for [[Using the Wiki]].

Creating articles in the wiki is a collaborative process. After you have written your piece others may:
* Edit
* Alter
* Adapt
* Add

So don't worry about making your article perfect the first time through. Don't hesitate to add content you think is useful and don't hesitate to make edits where you think you can help. There's always somebody to fix anything that breaks.

'''Posting Guidelines'''

Here are a few guidelines to keep in mind when using the Yocto wiki:
* '''Search first''': Before creating a new page or making significant contributions to a page, please do a quick search to make sure that you aren't duplicating existing content on the wiki or other areas on the Yocto Project website.
* '''Must be a registered user''': If you want to edit the wiki, you need to [[Special:UserLogin|create an account]] and confirm your email address (you'll get an email after registering with a confirmation link). Anyone can create an account.
* '''Contribute''': The wiki is a resource for anyone to use. Just keep the content relevant, that is anything related to Yocto as long as it meets our other guidelines should be appropriate.
* '''Make improvements''': If you find a typo or inaccurate information, just fix it.
* '''Respect links''': Please provide [http://www.mediawiki.org/wiki/Help:Redirects redirects] when you move content. Many people use the wiki and may have created bookmarks or linked to your content.

'''The Wiki is Public'''

Everything in the wiki is public.

Every edit and every new page created goes into the [[Special:RecentChanges|recent changes]] feed, which means that people will see your edits even if you haven't yet linked to a page.

Once it's out there, it's public.
* Technically, administrators can delete things, but the wiki content may be mirrored, has feeds and is in the Google cache, so deleting something doesn't make it go away.
* When you delete content from a page, the original content will still remain in the history for that page.

==Mailing List Guidelines==

[https://www.yoctoproject.org/tools-resources/community/mailing-lists More information about our mailing lists] can be found on the Yocto Project website.

'''Keep It Short'''

Remember that thousands of copies of your message will exist in mailboxes:
* Keep your messages as short as possible.
* Avoid including log output (select only the most relevant lines, or place the log on a website or in a [http://pastebin.com/ pastebin] instead)
* Don't excessively quote previous messages in the thread (trim the quoted text down to the most recent/relevant messages only).

'''Use Proper Posting Style'''

* '''No HTML or Rich Text''': Set your mailer to send only plain text messages to avoid getting caught in our spam filters.
* '''Do not top post''': Top posting is replying to a message on "top" of the quoted text of the previous correspondence. This is highly unwanted in mailing lists because it increases the size of the daily digests to be sent out & is highly confusing and incoherent. By default, most email clients top post. Please, remove the irrelevant part of the previous communication(in case of more than a single correspondence) and use bottom, interleaved posting.
* '''Using interleaved posting''': Bottom, interleaved posting is replying to the relevant parts of the previous correspondence just below the block(s) of sentences. For a comment to another block of sentences of the same quoted text, you should move below that relevant block again. Do not reply below the whole of the quoted text. Also remove any irrelevant text.
* '''Use links''': Please provide URLs to articles wherever possible. Avoid cutting and pasting whole articles especially considering the fact that all may not be interested.
* '''Don't include attached files''': Instead of including attached files, please upload your file to the [[Special:Upload|this wiki]] or another website and post a link to the file from your email message.

'''Do Not Hijack Threads'''

Post new questions or new topics as new threads (new email message). Please do not reply to a random thread with a new question or start an unrelated topic of conversation in an existing thread. This creates confusion and makes it much less likely that you will get a response.

'''Do Not Cross Post'''

Avoid posting to multiple lists simultaneously. Pick a mailing list that is most suitable for your post and just use that. CC'ing multiple lists should be avoided.

'''Subscribers Only'''

Only subscribers can post to our mailing lists. If you would like to contribute to our mailing lists, we think it is only fair that you be a subscriber. Please note that if you want to participate only occasionally, you can subscribe to a list and set your email options to digest or no mail and read the web archives when you want to catch up.

'''Additional Resources'''
* [http://www.shakthimaan.com/downloads/glv/presentations/mailing-list-etiquette.pdf Mailing list guidelines by Shakthi Kannan (PDF)]: Great guideline summary and examples of posting styles.
* [[Contribution_Guidelines]]

==IRC Guidelines==

[https://www.yoctoproject.org/community/mailing-lists/ More information about our IRC channels] can be found on the Yocto website.

Here are a few IRC guidelines:
* '''Don't post chunks''': Avoid posting big chunks of text - use [http://pastebin.com/ pastebin] or a similar service to shorten it to a link.
* '''Register your Nickname''': To avoid confusion and make sure you always have the same name on IRC, you should [https://libera.chat/guides/registration register your nick].
* '''Pick the right channel''': if you aren't sure, you should start in our main #yocto channel.
* '''More information''': this [http://irchelp.org/irchelp/ircprimer.html IRC primer] for new users.
* '''Web access''': If you don't normally use IRC and want to try it out, you can use the [https://web.libera.chat/?channels=#yocto Libera.chat Web IRC] chat.

==Bugzilla Guidelines==

We like to have fun but we also like the communications to run smoothly. To that end here are some guidelines for participating in the [https://bugzilla.yoctoproject.org/ Yocto Bugzilla].

* '''Be patient with others''': Sometimes people post imperfect bug reports. In case of missing information, kindly tell reporters how to provide it, and/or suggest what they can do to improve the bug report.
* '''Stay on topic''': Don't start endless debates on topics not directly related to the scope of a specific bug report.
* '''Use proper quoting practices''': Avoid quoting complete previous comments by stripping unneeded lines, and avoid answering above the quoted text.
* '''Don't abuse your privileges''': Submitters have permission to edit their bugs. If you abuse this privilege - for example, by reopening a bug that the maintainers have closed - your privileges will be revoked.

What to do if you find a bug
* '''Search first''': Try to avoid filing duplicates by searching to see whether your issue has already been filed.
* '''Ask''': You can ask on our mailing lists or IRC channels to see if anyone has seen this issue before to gather more details or see if someone has a workaround.
* '''Submit a bug report''': Give us as many details as possible about what happened and how your issue can be reproduced. '''IMPORTANT''': please include the build/commit ID as reported by BitBake, as this will help the team determine whether your bug has been fixed already.
* '''Track our progress''': Get feedback from the development community and track resolution status.
* '''Provide a fix''': Use the tools, project wiki and git source repository in the Yocto Project to fix the problem yourself.

Learn more about [[Bugzilla_Configuration_and_Bug_Tracking|our process for reporting bugs]].

==Contribution Guidelines - Sending Patches==
[[Contribution_Guidelines|Contribution Guidelines]]

[http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded How To Sumbit A Patch To OpenEmbedded]

==Guideline Violations - 3 Strikes Method==
The point of this section is not to find opportunities to punish people, but we do need a fair way to deal with people who are making our community an unpleasant place.
* First occurrence: Public reminder that the behavior is inappropriate according to our guidelines.
* Second occurrence: Private message warning the user that any additional violations will result in removal from the community.
* Third occurrence: Depending on the violation, may include account deletion or banning.

'''Notes:'''
* Obvious spammers are banned on first occurrence. This is necessary to keep the community free of spam.
* Violations are forgiven after 6 months of good behavior.
* Minor formatting / style infractions will be dealt with through education, not the 3 strikes process.
* Extreme violations of a threatening, abusive, destructive or illegal nature will be addressed immediately and are not subject to 3 strikes.
* Contact [[User:Josef Holzmayr|Josef Holzmayr]] to report abuse or appeal violations (mistakes happen & will be corrected).

==Credits==
* [http://wiki.meego.com/Community_guidelines MeeGo Community Guidelines] were the basis for the Yocto Guidelines used under the [http://creativecommons.org/licenses/by/3.0/legalcode Creative Commons Attribution 3.0 License]
* [http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Fedora Mailing List Guidelines] used as a starting point under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported] license.

Developer Interaction Tips

2024-06-13T10:23:04Z

Josef Holzmayr: Created page with content suggestion by Richard Purdie

Sometimes interactions between developers can be tricky. The project aims to be inclusive and supportive of different use cases and perspectives, encouraging people to be productive and enjoy working with it and its community. We appreciate that some people find interactions more challenging due to language barriers, particular ways of thinking and the many different ways people approach problems and challenges. We've tried to document some things to keep in mind (in no particular order):

* The problem you're currently working on is going to clearly be important and the most pressing thing to you. Remember that other people have their own priorities and will be working on different things so they might not be as excited/interested in it as you are.

* Whether others engage on an issue or not isn't a good measure of how important it is, it would likely be more a factor of whether anyone has appropriate experience/knowledge and can offer any useful input. Everyone has a different background and nobody knows every different area.

* You might wonder why to you, there is such a glaring obvious hole in the project in some way. Perhaps people haven't approached things from your direction before. Perhaps they don't have your knowledge or expertise. It is very unlikely to be a purposeful omission. Anything unusual done purposefully will usually be documented as such.

* Whilst there may be a wonderful way of doing things that you can see, it is probably impractical that big changes can happen quickly and everyone can just change to that, much as everyone would wish otherwise. For a variety of reasons, changes often need slower incremental steps towards an end goal. This may feel frustrating but it is amazing over time how much change you can actually make. It does need patience.

* Criticising an existing approach or code may make people defensive even if they also don't like it. There are often reasons why things end up as they are, even if they are far from perfect. They probably did improve on something before them, the people involved probably learnt things since and would love to redo it with that hindsight or new knowledge too. Approaching things as suggesting incremental improvements is usually more productive rather.

* Maintainers have to view changes from multiple perspectives and balance the needs pf many different and often diverse users. If they suggest caution or potential problems or ask for improvements to a change, it isn't to be negative but to try and ensure any change has the best chance of getting included. Maintainers do actively want code improvements and contributions.

* Remember than when asking for something to be included, maintainers are acutely aware that once merged, you will probably move on to other things and they will be left looking after it going forward. This may mean they ask questions, it may make then reluctant to take a change if they don't want to be left maintaining it. If you think you will be around and using it and able to help in future, making that clear may help. Also try and be clear if you cannot help any more.

System Update

2022-01-28T21:53:13Z

Josef Holzmayr: /* Comparison */ link mender bullet to github, to match style of other bullets

== Introduction ==

This page compares different system update mechanisms. The purpose is to help the project with picking a suitable mechanism that the project then will support going forward. Users may find this page relevant for picking a mechanism that suits their specific needs.

A system update mechanism must ensure that a device running an older release of the operating systems runs with a more recent release when the update mechanism is done. This includes updating everything that defines the system (rootfs, kernel, bootloader, etc.), restarting running processes and potentially a reboot. An ideal mechanism:
* never ends up in an inconsistent state (atomic update),
* always keeps the device usable (fallback to previous state when there are problems, or at least supporting a recovery mode),
* requires little additional resources (disk space, RAM),
* minimizes downtime while updating,
* works in combination with security technology (integrity protection),
* is secure (does not install or execute software created by an attacker).

These are conflicting requirements. Different mechanisms will have different strengths and weaknesses. Therefore the first chapter provides a more detailed definition of the different aspects and has a table comparing the mechanisms. The following sections then describe each mechanism in more detail.

Some talks at Embedded Linux Conference presented an overview of the current mechanisms:
* How do you update your embedded Linux devices? by Daniel Sangorrin / Keijiro Yano http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf
* Comparison of Linux Software Update Technologies by Matt Porter http://events.linuxfoundation.org/sites/events/files/slides/Comparison%20of%20Linux%20Software%20Update%20Technologies_0.pdf. Video at https://youtu.be/pdHV9H9nZks?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q. Full paper done for Automotive Grade Linux (AGL) here: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-May/002061.html
* Software update for IoT: the current state of play by Chris Simmonds http://de.slideshare.net/chrissimmonds/software-update-for-iot-the-current-state-of-play
* OSS Remote Firmware Updates for IoT-like Projects by Silvano Cirujano Cuesta http://events.linuxfoundation.org/sites/events/files/slides/OSS_Remote_Firmware_Updates_for_IoT-like_Projects.pdf
* "Surviving in the Wilderness: Integrity Protection and System Update" by Patrick Ohly: [https://openiotelcna2017.sched.com/event/9J5i/surviving-in-the-wilderness-integrity-protection-and-system-update-patrick-ohly-intel-gmbh abstract and slides], [https://www.youtube.com/watch?v=N8V0W0p3YBU video recording of talk]

== Comparison ==

;Type
: ''Block-based'' update mechanisms directly modify blocks in the partition(s) that they update, without going through the filesystem. This implies that the partition has to be the same for all devices and that devices must use exactly the same partition size. ''File-based'' update mechanisms modify files and directories. Therefore devices with different partition sizes can use the same update data and it may be possible to update without a reboot.
;Disk layout
: Dependencies on boot loader, number and kind of partitions, etc. Flexible mechanisms make no or only few assumptions about the system, but typically then require additional work to integrate with a specific setup.
;Rootfs
: The partition which contains the OS. May be strictly read-only (block-based update mechanisms) or read/write (file-based). Some update mechanisms support installing and updating a subset of the full OS.
;Updates from
: describes from where the update mechanism gets the update.
;Updates what
: describes which parts of the overall system the mechanism updates.
;Code stability
: Based on how long the code has been in use, personal experience, security track record in existing deployments, etc.
;OE/Yocto integration
: Whether the mechanism is already available and who supports it.
;Resource requirements on server
: affect both build time and long-term storage capacity. Likely to depend on the complexity of the changes.
;Resource requirements on client
: Amount of temporary disk space, CPU/network load, ..., again for different scenarios.
;Failure resilience
: Summarizes how the mechanism copes with potential problems.
;Complexity
: Some mechanisms are harder to use correctly than others (usability). Also includes how difficult is to set up the mechanism because of dependencies.
;Downtime
: How long normal operation of the device needs to be interrupted for an update.
;Security
: Compatibility with other technology, protection of the update mechanism itself.

{| class="wikitable"
! rowspan="2"|Mechanism
! rowspan="2"|Type
! rowspan="2"|Disk layout
! rowspan="2"|Rootfs
! rowspan="2"|Updates from
! rowspan="2"|Updates what
! rowspan="2"|Code stability
! rowspan="2"|OE/Yocto integration
! colspan="2"|Resource requirements
! rowspan="2"|Failure resilience
! rowspan="2"|Complexity
! rowspan="2"|Downtime
! rowspan="2"|Security
|-
! on server
! on client
|-
! [https://clearlinux.org/documentation/swupdate_about_sw_update.html swupd]
| file-based
| flexible
| read/write
| HTTP(S) server, local media
| depends on setup
| relatively stable, under active development
| [http://git.yoctoproject.org/cgit/cgit.cgi/meta-swupd meta-swupd]
| moderate, suitable for frequent updates
| minimal download, needs sufficient free space in rootfs
| favors fast updates over failure resilience
| some planning required
| minimal, reboot optional
| Compatible with Linux IMA, Smack, SELinux. Signed update data, HTTPS transfer protection.
|-
! [https://github.com/sbabic/swupdate sbabic's swupdate]
| block-based / file based
| flexible
| depends on setup (read-only supported)
| local and remote (plain HTTP(S) or custom server)
| depends on setup
| Code relatively stable, 6 months release cycle
| [https://github.com/sbabic/meta-swupdate meta-swupdate]
| archives full image per build
| download and write full (compressed) image, zero-copy
| integrated rollback (requires bootloader support)
| easy to use (but requires customization!?)
| reboot required
| signed and encrypted images, HTTPS
|-
! [https://github.com/mendersoftware Mender]
| block-based / file based
| [https://docs.mender.io/Devices/Partition-layout flexible (minimum four partitions)], U-Boot or GRUB as boot loader
| supports read-write and read-only
| remote using Mender management server ([https://docs.mender.io/Architecture/Overview#modes-of-operation managed mode]) or local using CLI ([https://docs.mender.io/Architecture/Overview#modes-of-operation standalone mode])
| Complete rootfs, including kernel (built-in). Customizable with [https://docs.mender.io/artifacts/update-modules Update Modules].
| relatively stable, fully supported and tested [https://docs.mender.io/administration/upgrading upgrade path]
| [https://github.com/mendersoftware/meta-mender meta-mender]
| compressed rootfs per build
| download and write [https://docs.mender.io/architecture/mender-artifacts#streaming-and-compression compressed rootfs]
| integrated rollback
| easy when using meta-mender
| reboot required
| HTTPS enforced, [https://docs.mender.io/artifacts/signing-and-verification signed images]
|-
! [https://github.com/ostreedev/ostree OSTree]
| file-based
| flexible, but supports only limited set of bootloaders
| read/write, OS trees bind mounted read-only, /etc and /var writable
| local and remote repositories
| kernel and filesystem
| relatively stable, significant user base, under active development
| meta-ostree (WIP), [https://github.com/advancedtelematic/meta-updater meta-updater] (public)
| generating commits based on new builds, storing them in repository
| updating local repository, hard links for sharing unchanged content between deployments
| rollback to a different deployed OS tree
| some work required
| reboot required
| GPG-signed commits
|-
|-
! [https://github.com/rauc/rauc RAUC]
| block based / file-based (tar)
| flexible (block-device/MTD)
| depends on setup (read-only supported)
| depends on setup
| depends on setup (any storage device)
| relatively stable, under active development
| [https://github.com/rauc/meta-rauc meta-rauc]
| archives full (compressed) image per build
| download and write full (compressed) image
| integrated rollback (requires bootloader support)
| some customization required
| reboot required
| X509-signed update bundles
|}

== swupd ==

;Disk layout
: swupd updates files in a single partition. Other than that, it makes no assumptions about disk layout, filesystem and boot mechanism.
;Rootfs
: Files provided by the OS are read-only, everything else is read/write (/etc, /var) and preserved during updates. OS can be split up into a core OS (always installed) and optional bundles which may or may not be installed.
;Updates from
: Uses libcurl to fetch update data and thus supports all URL schemes supported by libcurl, in particular http(s) and local files.
;Updates what
: swupd itself updates files in the rootfs, other components then need to be updated (boot loader, kernel, firmware, ...) then need be updated via custom plugins.
;Code stability
: Used and maintained in Clear Linux OS. Code relatively stable, but would benefit from a rewrite (evolved from a prototype). Code changes not written for Clear Linux OS tend to get merged only slowly or not at all (examples: [https://github.com/clearlinux/swupd-server/pull/25 assumption about filesystem], [https://github.com/clearlinux/swupd-server/pull/26 error checking], [https://github.com/clearlinux/swupd-client/pull/71 path configuration]).
;OE/Yocto integration
: Layer available, not part of Yocto releases, experimental. Supports building incremental updates (= only changes since last build are stored for new build) and deltas (= optimized update pack for specific previous builds, typically major milestones).
;Resource requirements on server
: Build time and storage for each update linear with total number of files (file system analysis, zero packs) plus linear with number of modified files (compression). When using swupd purely as update mechanism (i.e. no bundles), space requirement on the server could be reduced to linear with the number of modified files by not creating the zero packs. Optionally can prepare deltas from certain previous builds, which is linear with the number of modified files since each of those builds.
;Resource requirements on client
: In the best case (delta prepared by server), a single archive with just some file diffs gets downloaded, unpacked and applied. In other cases, each new or modified file gets downloaded and unpacked. Staging new content needs free space in the rootfs partition, i.e. partition must be at least twice as large as the base OS.
;Failure resilience
: No recovery mechanism built into swupd itself. Short period of time where interrupted update may leave behind inconsistent rootfs. No updates possible when there is not enough free space left. Updating files while system services are running reduces downtime, but is also more risky if system services aren't prepared for it. Could be extended to do updates without that risk, at the expense of increased downtime.
;Complexity
: Upgrade path must be considered as part of release process (deltas, incompatible changes).
;Downtime
: Downloading and staging in parallel to normal operation. Services are kept running until after the update, at which point the device admin needs to restart services or reboot depending on what was updated (not automated at the moment in meta-swupd layer).
;Security
: Compatible with Linux IMA, Smack, SELinux. Conceptually incompatible with dm-verity. Relies on HTTPS and (optionally) [https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel%C2%AE-architecture signing] to protect integrity of update data (not integrated into meta-swupd yet).

== babic's SWUpdate ==

;Disk layout
: There is no constraint how software is stored. SWUPdate supports raw flash (NOR, NAND), UBI volumes, disk partitions or can update files (provided in a tarball) into an existing filesystem. Each artifact can be stored on a different storage device.
;Rootfs
: No constrain where software is stored. During an update, a single partition, multiple partitions or generically multiple different storages can be updated.
:
: SWUpdate is often used in one of the following setup:
:
:* '''rescue''' : The system reboots in maintenance mode and SWUpdate is started from a Ramdisk. Just one copy of the Software is stored into the system.
:* '''dual-copy''' : two copies of the software (rootfs, kernel) are stored into the system and SWUpdate installs the stand-by copy.
;Updates from
:
:* local provisioning : USB, SD, etc.
:* generic URL : HTTP(S), FTP. It uses the libcurl library and supports what libcurl provides.
:* Webserver : SWUpdate integrates a Webserver (mongoose)
:* External Backend connector (suricatta mode) to bind with an external backend server. Currently, the Hawkbit server is supported https://github.com/eclipse/hawkbit. Open to further backends.
:* Custom Protocol: SWUPdate provides a library (LGPLv2.1) in case of custom protocol.
;Updates what
:
:* bootloader (risky !)
:* kernel
:* interface to bootloader (U-Boot) Allows to change u-boot variables and allow to use plugins to make changes to other bootloaders.
;* disk partitions
;* provide interface to update FPGAs, external microcontrollers, etc.
;* custom handlers: an interface allows to add own installers written in C or in LUA.
;* system update: atomic update of network connected devices as they are just one.
;Resources on client
:
:* '''rescue''' : meta-swupdate provides recipe to generate a compressed ramdisk with small footprint. Including support for signed image, the whole rootfs is ~4MB. The minimal requirement for a complete rescue (bootloader, kernel for SWUpdate and ramdisk) is 8MB. This allows to put the rescue in a small storage like a SPI-NOR, while the software is stored on another and bigger device (NAND, eMMC).
:* '''dual-copy''' : Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. No additional space is required if the image is directly streamed to the stand-by copy.
;Failure resilience
: SWUpdate provides interface to bootloaders (U-Boot, GRUB, EFIBootGuard). Update can be marked good or bad and it starts a fallback (support from bootloader required).
; Downtime
:
:* '''rescue''' : There is need to reboot in maintenance mode and once the image is installed, needs to reboot again with the new production image.
:* '''dual-copy''' : Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.
;Security
:
:* Connection with HTTPS to the external the server.
:* Signed images : it is possible to sign the images used for the update in order to check its integrity. X.509 cryptography (CMS) or RSA keys.
:* Split in several processes: connection to the internet can run with a different userid / groupid as the installer (privilege separation). The installer runs often with high privileges because it has to write the hardware.
:* Support for encrypted artifacts
:* Signing / Encryption with openSSL or MbedTLS.

== Mender ==

;Disk layout
: No upper limit on partitions, [https://docs.mender.io/devices/partition-layout minimum four]. Dual rootfs partitions with two extra partitions, a boot and a data partition. Depends on either U-Boot or GRUB as boot loader for the automatic rollback.
;Rootfs
: Stored in one active and one passive partition, read/write while in use, but modifications to it get lost during updates when switching partitions, so persistent data should be stored in the data partition. Kernel is stored on rootfs.
;Updates from
: Mender Server over HTTPS ([https://docs.mender.io/architecture/overview#modes-of-operation managed mode])
: manual provisioning : local file system/URL, e.g. USB, SD, HTTP(S) ([https://docs.mender.io/architecture/overview#modes-of-operation standalone mode])
;Update what
: Built-in support for rootfs update, including kernel. Can be customized via [https://docs.mender.io/artifacts/update-modules Update Modules] to update files, packages or external components.
;Code stability
: Stable release. Upgrade path fully supported and tested.
;Resources on server
: Needs to store one compressed rootfs image for each update, plus small meta data section.
;Resources on client
: Needs active/passive rootfs partition, and bandwidth to download compressed rootfs image. Needs no additional space on device beyond the partitions (update is streamed), space for the Mender binary, and a tiny local database.
;Failure resilience
: Automatic rollback if the device either fails to boot, or the Mender daemon cannot connect to the Mender server afterwards.
;Complexity
: Relatively easy to [https://docs.mender.io/Artifacts/Building-Mender-Yocto-image build with Yocto]. More complex if [https://mender.io/blog/porting-mender-to-a-non-yocto-build-system not using Yocto].
;Downtime
: Update is downloaded and applied during normal operation. Afterwards one reboot is required, no other downtime.
;Security
: Secure connection to the server (TLS). [https://docs.mender.io/1.1/artifacts/signing-and-verification Artifact signing] with RSA or ECDSA.

== OSTree ==

;Disk layout
:Only limited set of bootloaders supported (those that support [http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec The Boot Loader Specification] and some exceptions). The root file system has to have the /boot directory managed by OSTree. The actual deployed OS trees have certain conventions and requirements. For example, /etc and /var need to be writable, while /usr is mounted read-only.
;Rootfs
:Files provided by OS are expected to be in /usr, which is mounted read-only. /etc and /var are writable.
;Updates from
:Local and remote repostories. OSTree works by replicating a repository to the target device and then "checking out" deployment directories from the repository. Local and HTTP methods for replicating the repository are available.
;Updates what
:OSTree (atomically) updates root file system trees and the kernel. If anything else needs to be updated, it needs to happen by running custom code on the target device.
;Code stability
:OSTree is relatively stable. It's used by many distributions and projects, such as Fedora Atomic and Flatpak. OSTree is under active development and has an open-source community around it.
;OE/Yocto integration
:Meta-ostree layer is work in progress.
;Resource requirements on server
:OSTree generates "commit objects" based on the filesystem changes between builds. These commit objects are stored in a commit chain the same way as git does. The commit objects transmitted over the network as binary diffs when the remote and local repositories are synchronized.
;Resource requirements on client
:Client has the local copy of the repository. The repository contains the objects, which map to the files on the OS trees. The deployments of the OS trees (or "checkouts" in git termininology) are made using hard links to the repository content. This means that the required space is only increased when the data changes: the static data files are shared between deployments.
:OSTree allows deleting of data. This means that the full operating system history doesn't need to be stored in the repository. A typical OSTree-based system might have two deployed OS trees: one that is being currently used and one fallback.
;Failure resilience
:OSTree controls the booting to the different deployed trees using bootloader entries. If booting a deployed OS tree fails, a different bootloader entry can be chosen for booting into a different OS tree.
;Complexity
:Some work is needed to fit the root filesystem into the conventions that OSTree likes. Some documentation of the needed steps [https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ is available here].
;Downtime
:Reboot is required after updates. Changing between deployed OS trees is done by selecting a different boot loader entry.
;Security
:The commits can be signed with GPG-based signatures. OSTree repositories store file extended attributes, which means that the security mechanisms using extended attributes should be functional with OSTree.

== RAUC ==

;Type
: RAUC supports filesystems on block devices and MTD (NAND/NOR) as well as raw images (bootloaders, FPGA bitstreams).
;Disk layout
: RAUC does not depend on a fixed disk layout but allows to flexibly [https://rauc.readthedocs.io/en/latest/reference.html#sec-ref-slot-config configure] one. It supports A+B scenarios as well as A+recovery or more complex setups.
;Rootfs
: There are no limitations on the root file system, it can be read-only or read-write. It has to contain the RAUC system configuration file, a keyring for verification and the small RAUC binary itself.
;Updates from
: RAUC is the updating core that is meant to be integrated in a custom environment. Thus it supports installing bundles from local file paths, while another application is responsible fetching the update.
: External storage (USB, SD): direct access, no copying required
: Webserver: Application downloads Bundle to local tmpfs / storage.
: Demo-applications planned.
;Updates what
:
:* everything which is updatable
:* default handler for common storage types and file systems (ext4, NAND, UBI, raw copy)
:* allows [https://rauc.readthedocs.io/en/latest/using.html#customizing-the-update custom handler] for each update target (script or application, information passed as environment variables)
;Resources on client
: At least one production rootfs and a rescue system. Temporary storage for update Bundle (compressed) if provided by a webserver.
;Failure resilience
: Interface to [https://rauc.readthedocs.io/en/latest/integration.html#interfacing-with-the-bootloader Booloader] (Barebox, U-Boot, GRUB, UEFI) allows atomic updates (correct fallback handling is up to the bootloader). Interface to mark updates good or bad after certain checks in the newly booted rootfs (must be supported by bootloader).
;Complexity
: Integration into the rootfs and generating update Bundles is relatively easy with Yocto ([https://github.com/rauc/meta-rauc meta-rauc]) or [https://www.mail-archive.com/ptxdist@pengutronix.de/msg11471.html PTXdist]. Manual integration described [https://rauc.readthedocs.io/en/latest/integration.html here].
;Downtime
: Normally, downloading and installing will be perforemd as background operation. A reboot is needed to make the new system active (might be scheduled).
;Security
: Signed images: Signing images is mandatory. X.509 cryptography (CMS) is used to sign the bundle and a full PKI with revocations is supported. An example script allows creating key/cert/keychain for test purposes.
: Verified boot: When using image updates, compatible with IMA, SELinux, dm-verity, ... (as it does require write access to the filesystems).