Two different approaches to building a distribution: OpenHarmony and OpenMandriva
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Rosenkränzer, Bernhard
There are many Linux distributions out there - and almost as many different approaches to how they're built. Two distributions on nearly opposite ends of the spectrum include OpenMandriva (which uses binary packages, builds and updates each package individually, applications are part of the OS, ...) and OpenHarmony (which builds the OS from source in one go, is updated through OTA images, and treats applications as something separate, ...) A developer involved in both projects explains how the 2 projects go about building their respective OSes, why both projects made the choices they made, how the approaches differ from a developer and user perspective, and what approach works better for what particular use case.
 Hi, welcome to this custom session. I am Bill and today we are going to talk about two completely different approaches at building a Linux distribution, the ones taken by OpenHarmony and OpenMindRiva. I have attended any of my other talks, but I know I don't usually do the about me thing. I am not important, my topics are. But this time I have decided to make a bit of an exception because it does answer a few questions. Like, am I talking about one project I know well and another one I only understand basically? Or, am I trying to promote one approach by bashing another? And why am I just picking two different projects that are not exactly household names yet? Even though I of course hope both will be. So the answer to those is I have been working with OpenMindRiva since 2012. I am currently the president of the OpenMindRiva Association and I was a contributor to Mandrake back in its roots in 1998-1999. And more recently in November last year I have joined the Huawei OpenSource Technology Center, which is building OpenHarmony as a principle technologist. So I understand both projects. I am involved with decision making in both. And I think both approaches are perfectly valid. There might be reasons to go with either way. So let's take a look at what those reasons might be. Since both projects are not exactly well known yet, first of all we are going to take a quick look at what they are. Starting with OpenHarmony, its idea is to be more than an operating system. It can use multiple different corners. So it can run with Linux and with Zephyr and in the future probably a few others. We are looking at FreeRTOS, we are looking at LiteOS. There might be others in the future. The key goal is autonomous cooperative devices, multiple devices forming a distributed virtual bus that can share resources. Initial target devices are the Avenger 96 board, which is a 32-bit ARM v7, Cortex A7 and M4. And the Nitrogen 96 board, which is Cortex M4. OpenHarmony is built with Open Embedded in Yachto. So there is one command that builds the entire OS. It is a fully open project developed as an open source project, not so much an in-house product from the start. For more information there is a great talk by Stefan Schmidt, my co-worker in the Embedded Devroom at 5.30. You can look at what he is going to say or you can talk to us at the Huawei OSTC stand. Both of us should be there at some point. For this open Mantriva, that is a more traditional Linux distribution, also completely controlled by the community, continuing where Mantriva left off after the company behind it went out of business in 2012. Its route goes back to the first Mantraic Linux release in 1998. And it was originally targeting only x86 PCs, support for additional architectures, ARC64, ARMV7, H&L, RISC-5 was added later. Repositories contain 17,618 packages. And each of those packages is built and updated individually, assembled into an installable product with OMDV built ISO or OS image builder. For more information about this, you can go to the OpenMantriva website or visit the OpenMantriva stand at first. So let's take a look at how OpenHarmony is built. You download the operating system source, go into the directory, use the repo command to download a couple of git repositories that will get you bit-bake recipes, board description files, configuration files, describing how everything needs to be built, and everything will be built from sources. Then you initialize the environment, setting a couple of environment variables, adding a couple of extra bit-bake layers. That sets up the build system with everything that's needed. You set a couple more parameters and run bit-bake. And that takes care of everything else for you. The source for the actual components is downloaded, and that's already in the cache from previous build. And it's built according to what's in the bit-bake recipes and assembled into an image that works for the target machine you've specified. So you run this command and you get an image of the OS. OpenMantriva, in contrast, is built differently. Every upstream package, the library or an application is packaged in a separate RPM file. The package is then sent to ABF, the Advanced Build Farm, which sends it to builders for all supported architectures. At this time, that's x8664. ZNv1, which is a special case of x8664, count-risen processors. ARC64, ARMv7, H&L, RISC5, 64-bit, i686. And we recently got access to a PowerPC64 machine that will probably be added in the future. All the builds are done as native builds on a machine matching the architecture, or at least coming close in the case of RISC5, if you're currently using QEMU and faster machines. But that might change with the release of the new BeagleV and the Sci-Fi board. If the build succeeded on all the architectures, the packages added to the repositories, and if necessary, packages depending on it are rebuilt. When we want to build an operating system image, like the recent 4.2 release, there's a script that assembles the packages and builds it into an ISO image, or with the advent of non-x86 support. An image that works for a specific board in whatever format that target needs. None of the packages are rebuilt at that time. So why would people opt for those different possibilities? In Open Harmony, we are building everything from source and one go. We need to cross-compile. Cross-compiling is built into the OS builder by design. You certainly don't want to build an OS for Cortex M4 or Cortex M4 power device that would take forever. This approach makes it easier to build on top of different kernels, like Linux, Safari, and other options that will be added later with completely different requirements. For example, not every artist supports shared libraries. If you don't have shared libraries, you have to build everything in a completely different way. Build script from a Linux system that relies on a lot of pre-installed shared libraries will not necessarily work in that context. If you have a build script for Safari, that will not work nicely with the Linux system. This approach also makes it easier to work with boards that need custom kernels, custom bootloaders, everything. Those kernels will be put in at build time. There is no need to have pre-built packages for those kernels. There is no possibility of problems caused by ABI changes in the library, because everything is guaranteed to be built at the same time against the library version that is actually in use. Lastly, it also makes the user's license compliance tools like reuse easier, because all the sources in one place and the tool can check their license problems might be occurring. Gather statistics on how many GPL files are there, and make sure that no GPL files are linked into projects using a different open source, but not GPL compatible license and things like that. Why did we decide to use binary packages in OpenMandriever? One thing is there are lots of packages, 17,618 packages. Some of them are pretty big, like LibreOffice. They will take multiple days even on modern hardware. Given that OpenMandriever, or rather its predecessor, Mandrake started in 1998, try doing the same thing in 1998, and you will know why binary packages were really the only option. Another thing is for a larger system where not everyone is expected to update at the same time. Updating individual packages is often preferable over an OTA approach. On a larger system, not every user has the same packages installed. Only few people need, for example, KDE Plasma and GNOME at the same time. People generally pick one. That is obviously easier if they are separate packages. This approach also supports packages that cannot be cross-compiled, which sadly still exist. Another big difference is how they are updated. OpenHarmony is updated generally as an OTA image. The entire OS is updated in one go. Updates will be some variant of a file system image or a data to a previous file system image, assuming that we already know what is there before. Updates are sent to users when a new version has been completed and is tested. There are only updates that update the entire system, not just an individual part. Some details of disaster are being worked out because the first official OpenHarmony release hasn't happened yet. Some things may change slightly, but in general this is how things will go. In contrast, OpenManDriver is updated by updating individual packages. On the cooker, development tree and rolling release tree, people usually receive updated packages every day, many times several times a day. Users of the ROC, which is the stable tree, get only tested packages only once in a while. Machines are updated between releases. ROC is always a simulink to the current release. If you're installed 4.1 and told it to install ROC, you should have received an update to 4.2 a while ago. Users of the release tree stay on their release forever, even after its end of life. If you're installed 4.1 and you're opted to stay on the release tree instead of going to ROC, rolling or cooker, you will stay on 4.1 forever and you won't get 4.2. So, why would people prefer OTA updates, OpenHarmony style? They provide a guaranteed consistent system. People will always get a build that has been tested in its entirety. There's no possibility of a user getting an updated library without a corresponding application rebuilt against a library. So, no problem of an application crashing because a library has been updated and the application hasn't been rebuilt. There's no need for a lot of temporary storage for updated packages being downloaded on the running system. On systems that are extremely short on storage, like a Nitrogen96 port that has 512k storage, that is potentially a problem. Even the Nitrogen96 port is not necessarily the smallest target OpenHarmony, whatever I have. Of course, lastly, OTA updates are what people have come to expect in the consumer device space. There's nothing the user can do wrong. People expect to get updates without really noticing that their system has been updated. Why did we opt to do package updates on OpenManDreaver? One important point is dealing with the fact that not every system has the same packages installed. There's no point in sending a GTK update to a purest QT user or vice versa. There's no point in sending updated server packages to a desktop user or updating a LibreOffice to a server user or stuff like this. It gives users more control over what exactly they are updating, allows users to blacklist individual update data on quant, while still getting all the other features of a new release. And of course, it's also what people have come to expect in the Linux desktop and server. I think most people wouldn't take an OTA-style update too kindly on a traditional Linux distribution. We've seen a couple of small problems with either system, even though both have very good ideas and both work. When we started targeting non-X86 devices in OpenManDreaver, we ran into two problems. One is there's no defined standard format in which we can distribute images for non-PC devices. On a PC, we distribute an ISO file and that works for every PC, but that's not the case for other architectures. With most of the AOC64 servers these days, we can do pretty much the same. They support UEFI files and ISO files, but there's a lot of interesting devices from Raspberry Pi to RockPi to Pinebook Pro to the Pinephone to Si-5 Unleashed that simply don't. We still need some way to target those devices, which is easy in OpenHarmony. Many SOCs require a custom kernel with many patches that aren't in the upstream kernel tree yet. They touch files all over the kernel and conflict with patches that are needed for other SOCs. It's quite a challenge to build a binary package containing a kernel that can support all the needed features, for example, the current Qualcomm, mediaTek, and account all-vina.src, all at the same time. Again, for OpenHarmony, that's not a problem at all because the kernel is just put in at build time. It can just specify different sources for a different board. Many other traditional Linux distributions have decided to solve this problem. They're not supporting any devices that don't support UEFI. So, on some of the more server-centric Linux distributions, you will only find an ARC64 ISO that can be installed on modern ARC64 servers, but they won't work on a Pinebook Pro or on a Raspberry Pi, which is why you often see custom spins of those distributions for those boards. But in OpenMantreva, we care about those boards and we care about Linux on the desktop. The Pinebook Pro is a great way to get there. That's, by the way, the device I'm using to record this video. And we also care a lot about phones that are not under control of either Google or Apple. So, we want to get OpenMantreva on the Pinephone and other devices like that. So, limiting ourselves to UEFI is not the way to go. So, what could we do? Should we learn from OpenMantreva and rebuild the distribution the same way? The answer is partially. For the reason as mentioned before, we can switch to fully build this distribution from source all the time mode. That would still take weeks to get ISO done for testing. Then we fix one bug and build it again. And then the update system would clash. But the new OS image builder that is being used with count releases takes some ideas from OpenHarmony and its open embedded base. So, just like OpenHarmony, we have a per device config file that indicates which extra packages should be included for this device. And it can also specify a custom kernel repository, custom kernel config, device tree filename, custom Uboot repository and things like that. For example, this is what the device config file for Pinebook Pro looks like. It sets the architecture so all the binary packages will be built from the AX64 repositories. It pulls in the kernel firmware extra packages for the ViveHardTripZ. If a GUI is being installed, it pulls in the panfrost graphics driver. The kernel comes from a custom repository. The URL there is appended with hashtag branch. So, in order to make it possible to also pick a special branch. Then we set the kernel config, a couple of kernel extra config options, device tree filename, Uboot location, Uboot configuration. And that's it. OS image builder also allows to replace parts of the build script. So, any auto requirements like copy Uboot to one particular sector on the SD card, or create a FAT16 format, or create a CR partition number four containing a kernel, or other auto requirements that some boards have can be accommodated by that. But unlike the open harmony process, the openman driver OS image builder only builds the kernel in Uboot, so please, other components related to that board at build time, and then pulls in the binary package repositories like other openman driver builds. The script then outputs the install image for the right target device in the expected format, much like BitBake in open harmony would have done in the first place. So, take a base from this, will open harmony run into enmity limits with the other approach? Yes. As soon as we add a bigger target device, Avenger 96 and Nitrogen 96 are rather small devices that are not really expected to offer a lot of package choice or something, we will need some way to deal with packages in open harmony as well. That could be something similar to DNF or app, possibly OPKGE, which is already there in the Yachto base, or maybe something closer to the app gallery that exists on the de-googlyphied Huawei phones, assuming that its license can be adjusted to be fully open, or maybe even something entirely new that's even better that we haven't thought of yet. We'll deal with the problem when it gets there. Another takeaway is that there is clearly not one right way to build a distribution, and which approach works better often depends on the target devices. Project targeting a wide range devices will likely end up using a mixed form, like OpenMandriva's approach of having a more open harmony-like script that builds different kernels, different bootloaders, different installation images, but then pulls in the binary packages from the repository, or open harmony at some point adopting a more open-mandriva-like way to package applications for AI and devices. That's the basic idea. As you can see, both approaches are perfectly valid, both have advantages, both have disadvantages. Both projects can learn from each other, and both projects can also use an extra hand, so we would like to see you there. You can visit our GitLab repository at the location listed. Our website should be up soon, and I hope to see you there soon. If you have any questions, please feel free to ask them, either now or using the contact information that was provided in the beginning, or just find us at either the OpenHarmony stand or the OpenMandriva stand. Thanks for your attention.
 Hi, welcome to this custom session. I am Bill and today we are going to talk about two completely  different approaches at building a Linux distribution, the ones taken by OpenHarmony and OpenMindRiva.  I have attended any of my other talks, but I know I don't usually do the about me thing.  I am not important, my topics are. But this time I have decided to make a bit of an exception  because it does answer a few questions. Like, am I talking about one project I know well  and another one I only understand basically? Or, am I trying to promote one approach by bashing another?  And why am I just picking two different projects that are not exactly household names yet?  Even though I of course hope both will be. So the answer to those is I have been working with OpenMindRiva since 2012.  I am currently the president of the OpenMindRiva Association and I was a contributor to Mandrake back in its roots in 1998-1999.  And more recently in November last year I have joined the Huawei OpenSource Technology Center, which is building OpenHarmony as a principle technologist.  So I understand both projects. I am involved with decision making in both. And I think both approaches are perfectly valid.  There might be reasons to go with either way. So let's take a look at what those reasons might be.  Since both projects are not exactly well known yet, first of all we are going to take a quick look at what they are.  Starting with OpenHarmony, its idea is to be more than an operating system. It can use multiple different corners.  So it can run with Linux and with Zephyr and in the future probably a few others.  We are looking at FreeRTOS, we are looking at LiteOS. There might be others in the future.  The key goal is autonomous cooperative devices, multiple devices forming a distributed virtual bus that can share resources.  Initial target devices are the Avenger 96 board, which is a 32-bit ARM v7, Cortex A7 and M4.  And the Nitrogen 96 board, which is Cortex M4.  OpenHarmony is built with Open Embedded in Yachto. So there is one command that builds the entire OS.  It is a fully open project developed as an open source project, not so much an in-house product from the start.  For more information there is a great talk by Stefan Schmidt, my co-worker in the Embedded Devroom at 5.30.  You can look at what he is going to say or you can talk to us at the Huawei OSTC stand.  Both of us should be there at some point.  For this open Mantriva, that is a more traditional Linux distribution, also completely controlled by the community,  continuing where Mantriva left off after the company behind it went out of business in 2012.  Its route goes back to the first Mantraic Linux release in 1998.  And it was originally targeting only x86 PCs, support for additional architectures,  ARC64, ARMV7, H&L, RISC-5 was added later.  Repositories contain 17,618 packages.  And each of those packages is built and updated individually,  assembled into an installable product with OMDV built ISO or OS image builder.  For more information about this, you can go to the OpenMantriva website or visit the OpenMantriva stand at first.  So let's take a look at how OpenHarmony is built.  You download the operating system source, go into the directory,  use the repo command to download a couple of git repositories that will get you bit-bake recipes,  board description files, configuration files, describing how everything needs to be built,  and everything will be built from sources.  Then you initialize the environment, setting a couple of environment variables,  adding a couple of extra bit-bake layers.  That sets up the build system with everything that's needed.  You set a couple more parameters and run bit-bake.  And that takes care of everything else for you.  The source for the actual components is downloaded, and that's already in the cache from previous build.  And it's built according to what's in the bit-bake recipes and assembled into an image that works for the target machine you've specified.  So you run this command and you get an image of the OS.  OpenMantriva, in contrast, is built differently.  Every upstream package, the library or an application is packaged in a separate RPM file.  The package is then sent to ABF, the Advanced Build Farm, which sends it to builders for all supported architectures.  At this time, that's x8664.  ZNv1, which is a special case of x8664, count-risen processors.  ARC64, ARMv7, H&L, RISC5, 64-bit, i686.  And we recently got access to a PowerPC64 machine that will probably be added in the future.  All the builds are done as native builds on a machine matching the architecture,  or at least coming close in the case of RISC5, if you're currently using QEMU and faster machines.  But that might change with the release of the new BeagleV and the Sci-Fi board.  If the build succeeded on all the architectures, the packages added to the repositories,  and if necessary, packages depending on it are rebuilt.  When we want to build an operating system image, like the recent 4.2 release,  there's a script that assembles the packages and builds it into an ISO image,  or with the advent of non-x86 support.  An image that works for a specific board in whatever format that target needs.  None of the packages are rebuilt at that time.  So why would people opt for those different possibilities?  In Open Harmony, we are building everything from source and one go.  We need to cross-compile. Cross-compiling is built into the OS builder by design.  You certainly don't want to build an OS for Cortex M4 or Cortex M4 power device that would take forever.  This approach makes it easier to build on top of different kernels,  like Linux, Safari, and other options that will be added later with completely different requirements.  For example, not every artist supports shared libraries.  If you don't have shared libraries, you have to build everything in a completely different way.  Build script from a Linux system that relies on a lot of pre-installed shared libraries  will not necessarily work in that context.  If you have a build script for Safari, that will not work nicely with the Linux system.  This approach also makes it easier to work with boards that need custom kernels, custom bootloaders, everything.  Those kernels will be put in at build time.  There is no need to have pre-built packages for those kernels.  There is no possibility of problems caused by ABI changes in the library,  because everything is guaranteed to be built at the same time against the library version that is actually in use.  Lastly, it also makes the user's license compliance tools like reuse easier,  because all the sources in one place and the tool can check their license problems might be occurring.  Gather statistics on how many GPL files are there,  and make sure that no GPL files are linked into projects using a different open source,  but not GPL compatible license and things like that.  Why did we decide to use binary packages in OpenMandriever?  One thing is there are lots of packages, 17,618 packages.  Some of them are pretty big, like LibreOffice.  They will take multiple days even on modern hardware.  Given that OpenMandriever, or rather its predecessor, Mandrake started in 1998,  try doing the same thing in 1998, and you will know why binary packages were really the only option.  Another thing is for a larger system where not everyone is expected to update at the same time.  Updating individual packages is often preferable over an OTA approach.  On a larger system, not every user has the same packages installed.  Only few people need, for example, KDE Plasma and GNOME at the same time.  People generally pick one.  That is obviously easier if they are separate packages.  This approach also supports packages that cannot be cross-compiled, which sadly still exist.  Another big difference is how they are updated.  OpenHarmony is updated generally as an OTA image.  The entire OS is updated in one go.  Updates will be some variant of a file system image or a data to a previous file system image,  assuming that we already know what is there before.  Updates are sent to users when a new version has been completed and is tested.  There are only updates that update the entire system, not just an individual part.  Some details of disaster are being worked out because the first official OpenHarmony release hasn't happened yet.  Some things may change slightly, but in general this is how things will go.  In contrast, OpenManDriver is updated by updating individual packages.  On the cooker, development tree and rolling release tree, people usually receive updated packages every day,  many times several times a day.  Users of the ROC, which is the stable tree, get only tested packages only once in a while.  Machines are updated between releases.  ROC is always a simulink to the current release.  If you're installed 4.1 and told it to install ROC, you should have received an update to 4.2 a while ago.  Users of the release tree stay on their release forever, even after its end of life.  If you're installed 4.1 and you're opted to stay on the release tree instead of going to ROC, rolling or cooker,  you will stay on 4.1 forever and you won't get 4.2.  So, why would people prefer OTA updates, OpenHarmony style?  They provide a guaranteed consistent system.  People will always get a build that has been tested in its entirety.  There's no possibility of a user getting an updated library without a corresponding application rebuilt against a library.  So, no problem of an application crashing because a library has been updated and the application hasn't been rebuilt.  There's no need for a lot of temporary storage for updated packages being downloaded on the running system.  On systems that are extremely short on storage, like a Nitrogen96 port that has 512k storage,  that is potentially a problem.  Even the Nitrogen96 port is not necessarily the smallest target OpenHarmony, whatever I have.  Of course, lastly, OTA updates are what people have come to expect in the consumer device space.  There's nothing the user can do wrong.  People expect to get updates without really noticing that their system has been updated.  Why did we opt to do package updates on OpenManDreaver?  One important point is dealing with the fact that not every system has the same packages installed.  There's no point in sending a GTK update to a purest QT user or vice versa.  There's no point in sending updated server packages to a desktop user or updating a LibreOffice to a server user or stuff like this.  It gives users more control over what exactly they are updating, allows users to blacklist individual update data on quant,  while still getting all the other features of a new release.  And of course, it's also what people have come to expect in the Linux desktop and server.  I think most people wouldn't take an OTA-style update too kindly on a traditional Linux distribution.  We've seen a couple of small problems with either system, even though both have very good ideas and both work.  When we started targeting non-X86 devices in OpenManDreaver, we ran into two problems.  One is there's no defined standard format in which we can distribute images for non-PC devices.  On a PC, we distribute an ISO file and that works for every PC, but that's not the case for other architectures.  With most of the AOC64 servers these days, we can do pretty much the same.  They support UEFI files and ISO files, but there's a lot of interesting devices from Raspberry Pi to RockPi to Pinebook Pro to the Pinephone  to Si-5 Unleashed that simply don't. We still need some way to target those devices, which is easy in OpenHarmony.  Many SOCs require a custom kernel with many patches that aren't in the upstream kernel tree yet.  They touch files all over the kernel and conflict with patches that are needed for other SOCs.  It's quite a challenge to build a binary package containing a kernel that can support all the needed features,  for example, the current Qualcomm, mediaTek, and account all-vina.src, all at the same time.  Again, for OpenHarmony, that's not a problem at all because the kernel is just put in at build time.  It can just specify different sources for a different board.  Many other traditional Linux distributions have decided to solve this problem.  They're not supporting any devices that don't support UEFI.  So, on some of the more server-centric Linux distributions, you will only find an ARC64 ISO that can be installed on modern ARC64 servers,  but they won't work on a Pinebook Pro or on a Raspberry Pi, which is why you often see custom spins of those distributions for those boards.  But in OpenMantreva, we care about those boards and we care about Linux on the desktop.  The Pinebook Pro is a great way to get there.  That's, by the way, the device I'm using to record this video.  And we also care a lot about phones that are not under control of either Google or Apple.  So, we want to get OpenMantreva on the Pinephone and other devices like that.  So, limiting ourselves to UEFI is not the way to go.  So, what could we do? Should we learn from OpenMantreva and rebuild the distribution the same way?  The answer is partially.  For the reason as mentioned before, we can switch to fully build this distribution from source all the time mode.  That would still take weeks to get ISO done for testing.  Then we fix one bug and build it again.  And then the update system would clash.  But the new OS image builder that is being used with count releases takes some ideas from OpenHarmony and its open embedded base.  So, just like OpenHarmony, we have a per device config file that indicates which extra packages should be included for this device.  And it can also specify a custom kernel repository, custom kernel config, device tree filename, custom Uboot repository and things like that.  For example, this is what the device config file for Pinebook Pro looks like.  It sets the architecture so all the binary packages will be built from the AX64 repositories.  It pulls in the kernel firmware extra packages for the ViveHardTripZ.  If a GUI is being installed, it pulls in the panfrost graphics driver.  The kernel comes from a custom repository.  The URL there is appended with hashtag branch.  So, in order to make it possible to also pick a special branch.  Then we set the kernel config, a couple of kernel extra config options, device tree filename, Uboot location, Uboot configuration.  And that's it.  OS image builder also allows to replace parts of the build script.  So, any auto requirements like copy Uboot to one particular sector on the SD card, or create a FAT16 format,  or create a CR partition number four containing a kernel, or other auto requirements that some boards have can be accommodated by that.  But unlike the open harmony process, the openman driver OS image builder only builds the kernel in Uboot,  so please, other components related to that board at build time, and then pulls in the binary package repositories like other openman driver builds.  The script then outputs the install image for the right target device in the expected format, much like BitBake in open harmony would have done in the first place.  So, take a base from this, will open harmony run into enmity limits with the other approach? Yes.  As soon as we add a bigger target device, Avenger 96 and Nitrogen 96 are rather small devices that are not really expected to offer a lot of package choice or something,  we will need some way to deal with packages in open harmony as well. That could be something similar to DNF or app, possibly OPKGE, which is already there in the Yachto base,  or maybe something closer to the app gallery that exists on the de-googlyphied Huawei phones, assuming that its license can be adjusted to be fully open,  or maybe even something entirely new that's even better that we haven't thought of yet. We'll deal with the problem when it gets there.  Another takeaway is that there is clearly not one right way to build a distribution, and which approach works better often depends on the target devices.  Project targeting a wide range devices will likely end up using a mixed form, like OpenMandriva's approach of having a more open harmony-like script that builds different kernels,  different bootloaders, different installation images, but then pulls in the binary packages from the repository,  or open harmony at some point adopting a more open-mandriva-like way to package applications for AI and devices.  That's the basic idea. As you can see, both approaches are perfectly valid, both have advantages, both have disadvantages.  Both projects can learn from each other, and both projects can also use an extra hand, so we would like to see you there.  You can visit our GitLab repository at the location listed. Our website should be up soon, and I hope to see you there soon.  If you have any questions, please feel free to ask them, either now or using the contact information that was provided in the beginning,  or just find us at either the OpenHarmony stand or the OpenMandriva stand. Thanks for your attention.
openharmony_and_openmandriva_0_179.png openharmony_and_openmandriva_180_275.png openharmony_and_openmandriva_276_335.png openharmony_and_openmandriva_336_395.png openharmony_and_openmandriva_396_611.png openharmony_and_openmandriva_612_2663.png openharmony_and_openmandriva_2664_4811.png openharmony_and_openmandriva_4812_6131.png openharmony_and_openmandriva_6132_6311.png openharmony_and_openmandriva_6312_6791.png openharmony_and_openmandriva_6792_7823.png openharmony_and_openmandriva_7824_9551.png openharmony_and_openmandriva_9552_9995.png openharmony_and_openmandriva_9996_10043.png openharmony_and_openmandriva_10044_10247.png openharmony_and_openmandriva_10248_13571.png openharmony_and_openmandriva_13572_15431.png openharmony_and_openmandriva_15432_15503.png openharmony_and_openmandriva_15504_15551.png openharmony_and_openmandriva_15552_15923.png openharmony_and_openmandriva_15924_16727.png openharmony_and_openmandriva_16728_18143.png openharmony_and_openmandriva_18144_20135.png openharmony_and_openmandriva_20136_21515.png openharmony_and_openmandriva_21516_24047.png openharmony_and_openmandriva_24048_25715.png openharmony_and_openmandriva_25716_26927.png openharmony_and_openmandriva_26928_28199.png openharmony_and_openmandriva_28200_29627.png openharmony_and_openmandriva_29628_30863.png openharmony_and_openmandriva_30864_30911.png openharmony_and_openmandriva_30912_31667.png openharmony_and_openmandriva_31668_31859.png openharmony_and_openmandriva_31860_31907.png openharmony_and_openmandriva_31908_31967.png openharmony_and_openmandriva_31968_33275.png openharmony_and_openmandriva_33276_33412.png