Hi everyone!
I am new to Redox but am really exited about it.
When discussing the vision for Redox I think it can be good to clearly distinguish a few basic use cases. That list might look like this:
Desktop / workstation
This is what most of us use Windows, MacOS or Linux for.
In this use case the OS must have a GUI and support for keyboard, mouse, USB ports.
For me also localization is important, at least ability to set keyboard layout.
Server
In this area I don’t have alot of experience, but I image system monitoring capabilities are very important, like memory usage, cpu usage, maybe temperature.
Monitoring must also be possible to do remote
Most user/admin interaction will be through command line, so a good powerfull shell and scripting capabilities will be important as well
Embedded systems / SOC
This is the area where I have most interest. I would love to run Redox on my Raspberry Pi
Most user interaction will be through command line, with basic commands, like busybox.
Must have support for serial port, ethernet (SSH) and maybe USB
In case a GUI is needed, it must be possible (easy) to create a custom GUI.
A powerful build environment is a must have, where it is possible to add your own applications as well as modifying / patching the system. I am used to bitbake (Yocto) and I think that feature set is required.
Support for ARM ISA (32 and 64 bit).
Something I have not (yet) seen in the documentation is an ABI description. Maybe I have just missed it?
Game console / Media center
I don’t know if this should be its own category or if it can fit under Embedded systems. To a great extent it will have the same requirements as embedded systems but with more emphasis on GUI.
Support for graphics devices / cards (Nvidia / AMD) I would assume is important in this case.
Probably alot of the things I mention above is already in place. Very good in that case. Otherwise I’d like to see a list of TODO’s in the different areas. Maybe also already exists. Enlighten me!
Hi guys and gals. I just recently thought about that question, and after careful reading I would like to recap the ideas which were already mentioned as well as suggest some more.
Basics
Every one of us can agree upon one thing, that easy and robust installation - preferably one click away - is a must. Wether it is out of the box experience as it could be seen with live installations on Linux, or more like set-and-forget process when you install your system on a chosen destination - some sd-card or alike - for your embedded device and configure it later - think of raspberry pi .
Opt-in telemetry is something which is self-explanatory enough. Although there is still concern that the implementation of transmission of sensitive data may not be secure, therefore I would like to see implementation details available to be read along when choosing to opt-in - preferably in pdf or md format.
Secure by default. Use sane and sound solutions for everyday scenarios. There are variety of levels at which things could be done. For example when using Redox-OS as a workstation, main partition could be encrypted (“could” was chosen on purpose as I’ll later show that other solution is viable and most likely better). Other level of security would be networking where tools like WireGuard and/or Tor/I2P could be used. But this subject deserves its own discussion, so I will stop here.
Encapsulation of processes. THE NIGHTMARE. We want a better interoperability of our own system (the OS) and to be able to kill, stop and run processes as we wish. Unfortunately, current solutions aren’t the simplest possible. Some of their flaws could be attributed to systemd as it is the most prominent solution available. However, we are also aware that taking into consideration all inter-networked reliances would be a real pain in the neck for developers. Various problems arise from POSIX specifications’ overload. No modular solutions have been implemented, therefore systemd’s efficiency is not satisfactory. The problems which systemd attempts to solve require supplementary and alternative solutions, which could be provided by Redox. The correlation between the low effectiveness of current solutions and a strongly monolithical approach deserves a more thorough analysis which would exceed the needs of this article.
As Redox-OS is a micro-kernel system it’s main feature is extensibility. Drivers for all kind of things can be added and removed on the get-go. This enables us to provide different build images (*.iso) for end user. One with drivers for legacy hardware, one for hardware which is less than 10y old, one for purely servers, and one for embedded. This greatly reduces development complexity and extends its discoverability while maintaining small footprint.
Workstation
This is complex subject as it’s mostly user oriented, but I’ll try to unravel some bits and pieces that we could implement.
Multiplatformism
As @erlend_sh said, we could think of different corner cases for different platforms that could be easily implemented. For example we could build a common interface (Scheme) which could translate input values from one device to another - think of game-pad joystick translated into mouse movement.
User Interface
Creating a one is hard, but making existing Desktop Environments work on Redox-OS is harder. Take for example Gnome (as I’m most familiar with). Do you know how many obstacles does it have to make my dream come true? There are multiple dependencies that need to be addressed. Gnome functions are dependent on D-bus calls and systemd. You’ll need to implement them first in some way in order to make Gnome work on Redox-OS. So no matter how much we would wish this dream of ours to make existent DE’s work, it’s better if we develop further OrbTK. Some of us want Material Design, others don’t. I would like the inclusion of HeaderBar-like feature to OrbTK. @Meowsdauer mentioned progressive disclosure which in my opinion is a must when we want multiplatformism as a feature. And as a Gnome fanboy as I’m, I would recommend to create HIG like document for developers wanting to build applications in OrbTk. Also when it comes to UI’s an official support for theming is a must as recent Gnome developers frustrations with themes showed it’s presence.
Apps
If we want simple and elegant process management without systemd we will have to have containerized applications. Yes, applications, not programs. Think of it as android apps vs. bash scripts. We will need to have a way to build and run applications sandboxed and not interdependent on other processes. Flatpak, AppImage, and Snaps are possible candidates for implementation. Although we face the same problem as with DE’s. Flatpak and Snaps are heavy depended on systemd for sandboxing. So we are limited to reinventing the circle or settling with AppImage, as long as we won’t downstream Flatpaks/Snaps to tailor them to our needs, or implement in some way systemd.
Systemd Conundrom
There is plenty of problems with systemd. I won't be naming them, but I will point out (again) the headaches which are caused by lack of it in Redox-OS. We can not easily bring existing DE's and application delivery solutions such as Flatpaks and Snaps. Some programs really on it to fully operate. It is a monstrosity which brings it's own design principles to which we already have alternatives. But you can not deny that it's BDFL doesn't know what he is doing. One of the points worth mentioning is redesign of user directories. It's an effort to make home directories portable and encrypted. Now think about it for one second. You can have immutable OS with no users. Users could be added and removed simply by inserting/detaching a pendrive or sd-card. No app bloats the system and they are portable too. On top of that all personal data is encrypted! Your backup files could be an encrypted zip file of home directory. That is some good selling point.
Miscellaneous
Different processor architectures are out-of-scope feature as the project is limited by Rust Toolchain.
Linux/BSD binary compatibility is feasible, but cumbersome as you would need basicly have to implement some translation layer for many Unix API’s and if I’m correct it also has to be ABI compatible (if it is a library) which I don’t know if it is even doable.
Note
Sadly I could provide only 2 links as apparently new users have a limit . I’ll later update this post when limit will vanquish and/or to improve dis-ambiguity.
This is a great discussion thread, so I may be about to destroy it be asking this… Is the redox-nix project for a workable end goal to access the wider ecosystem, or a means to some other rust-only end?
it does seem redox will have to participate in the non redox ecosystem at some point, and the nix and guix builds are as the most interesting of all the options… IMO
@bijang I believe the redox-nix project is simply about building nix expressions to facilitate cross-development of redox from nix-supported hosts. Not about porting Nix itself ( As a nix developer I’d love a nix-esque management of redox ).
IMO the most interesting and seemingly achievable goal should be supporting VM hypervisors well ( i.e. virtio ). Minimal driver supported needed as compared to bare-metal server or desktop/workstation.
Then redox can showcase the novel advantages of a general purpose multi-server microkernel OS in an environment where it can be used non-experimentally.
There are some very interesting things you can probably do with the fine-grain virtualization and generic data interfacing ( redox schemes ) that redox might allow for.
Talking about things working on other OSs, there are some good examples: the portage package manager; s6 init system and based tools; isolation features from coreOS and GNU guix; razor4 filesystem, this is not from any particular OS but seems to be really well performing
A thing I think would bring attention to redox, even at the current stage would be it having the hability to run on holochain, as a sort of GNU VM, from the end user perspective. It is developed on Rust so it have a great advantage over other systems even without a big external ecossystem; at this point I think a complete system on holochain would already be a great advantage
. I’ll later update this post when limit will vanquish and/or to improve dis-ambiguity.