What is the difference between Avalonia Linux DRM/embedded Linux/Android? #17088
-
|
I have always wanted to try to develop embedded projects with C#. In the past, I tried to use Windows iOT Core, but after Windows iOT Core died, I didn't know what technology to try for a long time. Although I have heard that it can be achieved through WINCE with WPF and other technologies, I have not tried it. Until later, I came into contact with Avalonia and tested that it was successfully run on the Raspberry Pi through Avalonia Linux DRM. As I kept testing and researching, I found that through the form of Avalonia Linux DRM, I can even develop an operating system similar to Andorid and iOS based on the Linux kernel. And I found that through .net and Avalonia, such a vision is not limited to large enterprises, even small and medium-sized teams can do it. As far as I know, in the past, embedded Linux mostly adopted QT and Gtk+ for development. I have not come into contact with these, and I don’t know the difference between them and Avalonia Linux DRM. I really want to know whether Avalonia Linux DRM adopts a different architecture and model from them. In addition, Avalonia uses Skia, and Android also uses Skia; Avalonia Linux DRM is based on the LInux kernel, and Android is also based on the Linux kernel. Does that mean Avalonia Linux DRM is an Android-like operating system? Why do I want to know this? On the one hand, I don't know much about it. On the other hand, in my personal opinion, Avalonia Linux DRM seems to be something completely different from the embedded systems of the past. So can you tell me some of the differences? Thank you |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
That depends on what you mean by "operating system". If you are referring to a custom shell (ie GUI) then yes you can. It's a lot of work though. If you want to make a true Linux based operating system though, you would need to make your own Linux distro. You can either follow the Linux from Scratch guide (extremely hard), or use something like Yocto (relatively easy). If you actually want a fully custom userspace (meaning you only use the kernel) you are going to have to write a lot of code to implement basically an entire Linux PC (that includes things like an init system and graphics stack). Android uses the kernel, but has a completely different user space and shell from desktop Linux. As such it's not accurate to call Avalonia DRM an operating system. It's just a GUI framework which you could use to write a shell if your operating system contains the necessary components.
QT and GTK are "native" UI toolkits. Kind of like how winforms is a native UI toolkit for Windows. The vast majority of Linux GUI programs use one or the other, or both as they are both extremely well supported and the two major desktops (KDE and gnome) are written in them. |
Beta Was this translation helpful? Give feedback.
-
Or is Avalonia Linux DRM something different? Because you didn't mention it clearly in your answer, whether Avalonia Linux DRM is something different from the past, or something similar to QT and GTK+. |
Beta Was this translation helpful? Give feedback.
-
Gnome is a full desktop environment (aka a shell). It provides a graphical interface for using a computer. EG it has a desktop with icons, a file manager, etc. Gnome itself is not similar at all to Avalonia. GTK (the UI toolkit gnome is written in) however is a lot closer to Avalonia (it provides controls, layout systems, windowing functionality, etc). The DRM specific functionality in Avalonia is not that relevant. All it does is output directly to the frame buffer device/GPU. There is no requirement to use DRM output and you can just use a standard X11/Wayland window inside Gnome/what ever shell you want. tl;dr Avalonia and GTK are both UI toolkits. In fact you can even use GTK with C#. https://www.mono-project.com/docs/gui/gtksharp/ Also if it helps, here is the wiki article for the Windows shell. |
Beta Was this translation helpful? Give feedback.
-
|
I understand what you mean. I recently had a crazy idea, using Linux as the underlying layer, using Avalonia as the GUI, and interacting with Linux through the command line (such as power on/off, mounting, etc.). As for applications, instead of using Linux applications, use Avalonia and .Net to create a new application format and run it on Avalonia. In this way, all logical controls(such as tombstone、install or uninstall application) are completed through .Net, and in theory, an alternative operating system can be created. |
Beta Was this translation helpful? Give feedback.
-
|
This is somewhat common in highly specialised embedded devices (EG cars, which might have an airconditioning "app" and a music "app"). It is however unusual for desktop apps to do this. But I have also seen and implemented something similar myself before. Generally the process is to make some sort of interface, and then implement it in another DLL. Your main app can then load the DLL that implements the interface at runtime and does what ever init it needs to do. https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support This however is far higher level than an operating system. It's at best a highly specialised shell. It can also get real painful to manage as your plugins are only guaranteed to be "valid" at compile time and there is nothing stopping you from mixing and matching assemblies after compile time (if the plugins themselves also have dependency conflicts, getting them all to behave together can be even trickier). Which often results in obscure errors like |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much. |
Beta Was this translation helpful? Give feedback.
This is somewhat common in highly specialised embedded devices (EG cars, which might have an airconditioning "app" and a music "app"). It is however unusual for desktop apps to do this. But I have also seen and implemented something similar myself before. Generally the process is to make some sort of interface, and then implement it in another DLL. Your main app can then load the DLL that implements the interface at runtime and does what ever init it needs to do.
https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support
This however is far higher level than an operating system. It's at best a highly specialised shell. It can also get real painful to manage a…