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:
Easy
to install, use and add/change functionality
Secure
Prevent system failures/hacks
Give the user easily full control which data are collected to support the redox project
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.
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.
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.
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!
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.
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.
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.
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.
@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!
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?
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.
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?
My vision for Redox as a desktop OS (though I agree that’s probably not the best place to start for Redox if it wants to have straight forward business applications early on):
A format-agnostic operating system. In short, the same as what Ubuntu Edge wanted to become, except I think the tablet (and possibly others) should be replaced before taking on laptops.
I own a smartphone, a tablet and a Nintendo Switch. I only have a very basic smartphone right now but I’m sure the latest generation of smartphones is pretty much on par with or even more powerful than the Switch. I have never had a genuine need for more than one of those devices at any given time.
So ignoring the necessity of a hardware story to go along with this for now, I’m thinking about how the interface for such an operating system to work. Switching between states like:
Smartphone
Tablet
Handheld console (tablet with gamepad attachments)
Remotely controlled console
…would undoubtedly require a clever interface that can be progressively enhanced/minimised, without feeling like you’re dealing with a completely separate interface when switching between formats. A good format-agnostic experience heavily relies on a purpose-built operating system GUI that’s format-aware.
Well I mean once we have wayland we can port mir and unity 8. Mir still maintain upstream and is now a wayland client and unity 8 has a small but dedicated community around it still.
One thing that could really make Redox shine, I think, is if the system image was immutable.
In today’s world of computing, updates are crucial, and getting them right is crucial. Chromium OS has a great idea: OS updates just involve swapping out the system image, so it’s just a matter of rebooting the machine. Two system images are held at all times, and when upgrading, the bootloader switches the active image from the old to the new.
Could work really well with the idea mentioned here of containerized applications where they can be configured to communicate, but they aren’t allowed to interfere with one another, and really not allowed to mess with the system image or its configuration.
That being said, I understand the importance of the free-as-in-freedom philosophy, which implies the ability to have complete control over the software running on one’s system.
With that in mind, I suggest that the user be fully allowed to modify and build their own system image, but the currently-running system image should be immutable by default. The user would either modify their secondary, inactive system image and then reboot into it, or perhaps be allowed to set the running image to be mutable to allow fast testing of changes. This would obviously break the feature where updates are pulled from a server and applied painlessly, but I think that’s an OK trade-off for a user who wants complete control and customization.
To summarize, my contribution to the vision would be:
updates to the OS and applications are fast and simple, because they’re immutable.
installing new software is safe and easy to reverse, because it won’t interfere with the system image or other applications
I would like to contest this. In 2019, every modern OS has a design language that’s at least a couple of years old. The actual age of the design doesn’t matter. What matters is making the design good – it should rely on well-known and well-tested design principles. If you expect the design to have to last a while, make it a timeless design – one that doesn’t lean heavily on popular modern idioms. I would say an example of a popular modern idiom that’s not timeless is extreme flat design. Humans live in a 3D world and take a lot of cues from dimensionality. Completely eliminating the third dimension has a negative impact on usability. See: https://www.nngroup.com/articles/flat-ui-less-attention-cause-uncertainty/
I do think the design needs to be serious. Early GNOME and KDE designs were very cartoony, bubbly, and colorful. Contrast that with what OS X and Windows were doing, and it made Linux distros seem like a joke. If the design takes itself seriously, then users will take it seriously. And I think they are learning that over at GNOME and KDE.
I think this begs the question: who is this operating system for? If it’s an iOS competitor, then I agree with what you’re saying. Since it’s not trying to be iOS, maybe we should consider what it is trying to be. I think that adopting the “universal operating system” concept that was mentioned earlier would be a great and awesome aspiration. If that’s what we run with, then you have to consider that there will be both types of users who need to use this OS: the sysadmin who only cares about the terminal as well as the novice desktop user who wants a great, free OS to get stuff done.
As mentioned earlier, the best way to strike that balance is to give everything a CLI and to create GUIs for things that make sense. Where a GUI is present, it should, again, use tried-and-true design principles like progressive disclosure to ensure that it’s good for both novice and advanced users.
Consistency is huge. The more consistent it is, the lower the learning curve, because users will be able to predict how things will behave based on prior experience.
People like to customize, and the UI should support that at least at a simple level with color themes.
A point about consistency - In addition to being consistent across the system, the GUI should be consistent over time as well. The system should stick to consistent idioms and appearances for long stretches of time, and then should be overhauled all at once when the time is right. Remember, an OS should be stable environment. It’s an ecosystem. Changing idioms and appearances all the time will cause app builders to have to re-write their GUIs all the time, and projects without active contributors will go without updates, and in turn the user experience will be disjointed, difficult, and plain distasteful.
Material Design by Google and Fluent Design by Microsoft are some of the best design systems out there, in my humble opinioin. (although MS has done a horrible job implementing Fluent, so don’t judge it based on what Windows 10 looks like right now).
Is Material free as in freedom? That would affect things.
Should Redox ever support touch? On phone-sized screens? Probably not in the foreseeable future, I’m guessing. If that ever happened, a design overhaul would probably be fine. Moving forward with that assumption, I think it’s probably best to start with a design that has less consideration for mobile than Material does. Material is supposed to work well across all screens, but it absolutely has decisions built-in that come from the requirement to work well on mobile. It’s born out of a mobile-first philosophy where the mobile problem should be solved first, because it’s the most constrained. Then everything else can follow.
I propose creating a design system and language that borrow from common idioms but are adapted to the Redox mission.
Reflecting on my comments here, I would propose the following additions or changes to the vision:
Stable. Both from an operating and user-interaction standpoint.
The GUI shell is:
timeless
based on tried-and-true design principles
takes itself seriously
is a pleasure to use. Means that it generally gives people a pleasant feeling when using. Requires collecting feedback.
consistent with itself and consistent over time. Design changes are well thought out and come infrequently to support the goal of stability.
