A Vision for Redox

#1

Dear Redox Team,

I’m looking into this forum now since some months and it’s fabulous to see, how the community is growing and Redox is evolving. In my point of view, Redox is now at a point, where it needs a strong and common vision, how and in which direction it wants to develop. This community and with that Redox, has a potential to become an OS people want to use and participate to.

The time for this can’t be better chosen. The Operation System market will make again a big move in the next years. Microsoft is evolving his OS in a quit nice way, but collects in the same time so many data of it’s users, that no one can trust their OS or the Microsoft brand. Apple destroys the relationship to his old loyal customers in every way they can and loose their pc OS complete out of scope. Linux has a bad and complicated touch, even when this is now a days more a prejudice. But they often still fail to deliver a good and easy environment to their users, because they get lost in technical details which they are not hiding from the user (To explain this point a little more, Rust is the perfect example, it deliver C performance with a high-level API and with an easiness that everyone is loving. Linux isn’t able to do this step).

In this given environment, Redox has now the possibility to position itself as an alternative to the given operating systems. In my opinion the community needs now to define a vision what Redox should become in the future. This would align it’s capabilities and enables the community to develop towards it.

With this post I would try to start the dialog about a vision and hope that others see the same need than I am and join this discussion. For me Redox should have 3 main goals in his vision, which are:

  1. Easy
    • to install, use and add/change functionality
  2. Secure
    • Prevent system failures/hacks
    • Give the user easily full control which data are collected to support the redox project
  3. Powerfull
    • Get the work done, with fast performance and nice tools

(I will further update these vision with points provided by the community to have a fast overview of the actual state.)
Please comment to my post and share your idea about a vision and how it should look like.

Thanks,
Robert

#2

Hi @Roba1993,

I hope you are doing well! It’s an interesting perspective you bring up. However, I believe that instead of: [quote=“Roba1993, post:1, topic:404”]
don’t collect personal data
[/quote] perhaps give the users complete control and clarity on how their information is being collected. Thus, allowing them to opt in if they want to help out more with the project.

Best regards,

Coder206

#3

Hi @Coder206,

that’s actually a really good idea!
Data that helps to improve the OS is probably really helpful for the community. Give the user control is always good, when it’s done in a smart and simple way.

Thanks,
Robert

#4

What I think is really important (and would make Redox succeed over the other OSs - they are basically what Linux doesn’t have and what made it more something for advanced users than for general usage):

Another part of being easy: It needs to look good and simple. This is more important than many people realize. You won’t use an OS that looks like the design is a couple years old, and you won’t use it, when the UI is not intuitive and compact. Redox doesn’t need to develop a new design policy for this, using something like the Material Design by Google would even provide a better UX because the design is consistent and known to the user even on different devices and OSes.

Make everything nice and UI-Based and easy to use. If the user wants advanced stuff, they can get that, but things like the need to use the console as a normal user on a regular basis scares many people away.

Another point for security: Use build-in encryption and security methods whereever possible. Have them always activated if they don’t need any userconfiguration (they run unnoticed for normal users in the background) and the techniques that require the user to behave in a different way they would without need to be moved to the “advanced” part.

Look at what works and what doesn’t on other OSes. Something I really enjoy using Android is the permission-management. Every application needs to ask for its permissions and they can even be granted or denied at runtime - no popular desktop OS has that, the only options are “run” and “run as root/administrator” and then the application may do whatever it wants to.

(This one is in brackets, because it is not that urgent - but would be really nice.
Make Redox easily extendible. Custumization will be important to many users - and when there are already the mods X and Y present because Redox can easily be customized by modifications and they maybe are even drag + drop - that would be amazing).

This one is probably the biggest: Compatibility with programs from other OSes. One of the biggest downsides of Linux is that you can’t use most of the Windows programs user X is used to on it. It takes a lot of time to get into the new system, and many users don’t want to have that much efford when they switch. We can eliminate this problem by making it possible to run (mostly WIndows, but also Mac and Linux) foreign programs on Redox. The easiest way to do this would probably be a mini-vm for each program. This is a lot of work, but I can tell you… If Redox gets this feature, it will be over the news (and get a bigger part of the market) in no time!

#5

Did someone say encryption?

#6

1. The base footprint needs to be small. It’s a microkernel based design so it has no reason to be big and bloated like MacOS, Windows and Linux, but needs to be more like the old Mac OS 9 and AmigaOS. Things like personal assistants, calender and SMS integration like Windows and MacOS do need to be kept out of the OS. They could potentially be third party apps.

2. More arch support. Redox will use cores and threads better than Linux? Better have a POWER port ready then. Redox as a server OS would be really powerful then.

3. Consistent UI design with possability for costumization. Personally, Windows 10 is just too flat and adds pointless animations. I think we need a clean industrial design that has at least some character.

4. Better control over background apps. The possability to set a RAM limit for background tasks would be great. Windows 10 has terrible RAM handling and it’s default apps are largely to blame.

5. Linux/BSD binary compatibility. Like BSD and Linux are largely binary compatible, I think we need some compatibility in this regard. You’ll probably need some Linux drivers and a lot of windows porductivity tools anyhow. Windows binary compatibility is unimportant. Every Windows productivity app has a good or better Linux alternative, period. Perhaps Wine support.

#7

The base footprint needs to be small.

Naturally, it is a microkernel, so it will be small. The OS isn’t nearly developed enough to worry about what kind of applications to provide out of the box. That would be a very long time from now. That said, the items you listed aren’t heavy at all on a desktop. Having imag with a GUI front-end might be neat.

More arch support

If Rust supports a target then that target can easily be supported by Redox. POWER support is more a talk for upstream Rust and LLVM at this moment. Although still, most servers are being powered by AMD64 processors.

The possibility to set a RAM limit for background tasks would be great.

This is something that should never be done without careful consideration. On Linux, we have systemd which allows you to define a memory and CPU limit for services. However, the only way to handle an application exceeding that memory limit is to kill it. That can be particularly dangerous if the service was not designed to account for being randomly killed at any point in time.

Linux/BSD binary compatibility

Already being worked on via the ability to emulate syscalls from other kernels in the userspace.

#8

Realistically, Redox isn’t going to be ready to displace Linux as the desktop other-OS of choice for quite some time. Linux is perfectly suitable for the job right now until then. Redox has to start where Linux started – in the server rooms competing against Linux and BSD boxes.

First thing’s first, and that’s completing all the basics of an OS: the kernel, networking, display, input, and basic drivers. It can take many years to implement and perfect the above, so it’s not a simple task. Networking support is being perfected right now so that Redox can potentially start running some network services.

#9

using something like the Material Design by Google would even provide a better UX because the design is consistent and known to the user even on different devices and OSes.

Plenty of people are opposed to the Material Design concept though, and might not like the idea of a desktop OS looking like a touch-screen phone OS.

Make everything nice and UI-Based and easy to use.

Even Linux succeeds really well with this, but the CLI should remain the first point of access for OS functionality. That’s what makes Linux the successful OS that is. Not only do you have a strong CLI, but you make it easier to write GUI front-ends for existing CLI-functionality.

Look at what works and what doesn’t on other OSes. Something I really enjoy using Android is the permission-management. Every application needs to ask for its permissions and they can even be granted or denied at runtime - no popular desktop OS has that, the only options are “run” and “run as root/administrator” and then the application may do whatever it wants to.

Actually, Linux houses like GNOME are working pretty hard on bringing Android-like permission systems to Linux desktops right now. There is existing functionality that already does this to a degree, such as AppArmor and SELinux. However, sandboxed applications shipping in the Flatpak format will gain the ability to have dialogues for requesting user-configurable permissions per application at some point. I’m sure Ubuntu is working on similar ideas with their Snaps.

This one is probably the biggest: Compatibility with programs from other OSes. One of the biggest downsides of Linux is that you can’t use most of the Windows programs user X is used to on it.

Realistically, you’re not going to see a difference here compared to Linux when it comes to compatibility with Windows software. Redox would have to ship the entire Windows ecosystem as a subsystem, and that would generally be illegal. I don’t see this as a problem though because modern day open source software that you see on the Linux desktop is quite simple and trivial to learn.

#10

@mmstick Although it might not be very realistic, at least support for big tools like the Adobe programs would be a great plus. Linux has many upsides compared to Windows, but I think the biggest reason why people (and the developers) stay at Windows is that people are lazy, and don’t want to have to search for alternatives and/or learn something new. They’ll want to be able to use their old project data right away, but they can’t. Linux may have succeeded in the area of server OSes, but it hasn’t a really big impact on the desktop market (compared to Windows and macOS).

Maybe the Windows support could be something optional to install? For the legal part, we’d probably need to rewrite the most important parts ourselves, so that it looks for applications like a normal Windows. Microsoft may own the files and stuff so we can’t just copy them (and that is right and would be bad if it wasn’t like this), but they don’t own everything that just behaves like the thing they produced.

Material Design was just an idea. I personally like it, because it is already familiar to users because one of the largest web companies and the largest smartphone OS use it. But if Redox gets its own design, thats fine too, the default design just shouldn’t be too far away from what people know already.

Although some (relatively small) OSes might already be experimenting with such a permission system, that doesn’t change my opinion. Application permission management is great, and should be applied everywhere! :wink:

#11

Aspire to be something more than just linux-like. What are some of the lessons we’ve learned since the early 90s?

  • Encapsulation of user processes is hard. Hard enough that people would rather run a bunch of VMs than bother trying to get software to play nicely together on a single OS. Therefore: be good at encapsulation. Make it easy for processes to talk to each other, but hard for them to interfere with each other. Make it easy to “jail” a process (to borrow the BSD term.) Maybe take some pages out of Integrity OS’s playbook.
  • Encryption is hard. Hard enough that almost no one gets it right. Therefore: get it right, and build it into the kernel. Whatever protocols (local & network) Redox implements, they should be encrypted-by-default.
  • Purity is important. Do not sacrifice purity for short-term convenience. If you want to take the unix view that everything is a file, actually make everything a file. Do not allow someone to come along and say “well, it’s hard to make X a file, so lets just handle it differently for a while.” Plan9 got this right, and got a lot of subtle and powerful benefits because of it. You don’t have to make everything a file (e.g. go for an object oriented OS like MS Singularity) but whatever you go with, it should be conceptually pure.

What are some other neat ideas we’ve seen, but didn’t get a fair shake, or just haven’t caught on yet?

WinFS: What if your file system was a relational database?
TempleOS: What if your lingua franca is smarter than text files? E.g. what if your man pages could have hyperlinks and images and diagrams? What if those hyperlinks could link directly to source code? What if your terminal was just a Rust REPL?

#12

Have you thought about something like a ChromeBook but with Redox? Can be Mozilla be interested in having Firefox/Servo-books based on Redox?

#13

Yes, the encapsulation is really important. That would also allow to implement the permission system easily, and would avoid a lot of user confusion.

But…why is encryption hard? I don’t work much with it, so I’m unexperienced, but couldn’t we just rely on things that already work? It would probably be hard to have a consistent encryption everywhere, but thats more a matter of your third bullet point, purity.

#14

See here: http://loup-vaillant.fr/articles/rolling-your-own-crypto , especially the reddit comment about all the stuff he got wrong the first time.

#15

If you need a vision, maybe start small with Redox? Is it possible to provide a rust OS that is smaller than Alpine (5mb)? That could have some use cases even if it didn’t run everything… you’d certainly get a following using it with docker/containers… Is it possible to have a useable OS under 1Mb?