I am looking at the progress which Redox makes and it is amazing to see how fast it goes. Lastly I had an Idea about Software deployment and package management. We talked about in Reddit about the Filesystem Hierarchy and it is clear for me that the Unix way is much more practical. For Unix it is very important that you have a package manager to keep track of all the files and dependencies. I had an Idea and wanted to share with you guys and I would really appreciate to hear your opinions about it.
But first of all I want to explain why I came to this and why I think this could be a breaking through innovation in the open source OS world.
There are many amazing Operating systems out there and there are great concepts in each of them. Unix like Operating Systems are great for Servers, Windows Systems great for Developers and Businesses and OS X is great for designers and artists.
All these Operating Systems have their key advantages and disadvantages. And now Redox is upcoming as the brand new Operating System which is also UNIX based. People might think, why they should use Redox instead of Linux? That’s what I asked to myself. Redox is aiming to be a Server Operating System. I think, it is also aming as an Operating System for home users which are not that experienced. Or?
People explained me very kindly on Reddit how the Package Manager keeps the System clean and manages all the installed apps on the system. There are a lot of Components needed to install a Package like Pre and Post Scripts and as I assume a Database as well to store all the App/Package file information for removing or updating.
The Idea:
Imagine if a Program or a package is like a Plugin stored in a Single file/folder which is a kind of a Zip file/container where you can look in it and see all the related files. The key advantages of that, is that you do not need a complex package manager nor a pre or post script to install these “System extensions”. You can easily remove them by hand without forgetting any files in any other folders which is for end users much more comfortable.
As well for servers in Businesses when it comes to managing a lot of computers in a domain you can simply specify which packages can be synced with all the different computers.
This is also for security reasons that a program cannot affect any another installed application. So the installed application is limited to its directory structure inside the file container.
The app doesn’t need to be a file. It can be a folder with a file extension as well.
Example:
Firefox.app
FFMPEG.pkg
Advantages:
Simplified install/uninstall process
Security to other Applications
Less complexity for the package manager
Managing Packages for Servers or Workstations in a Domain much simpler.
For unexperienced users it is much more simpler and easier to understand.
Sticking on concepts which are decades old is in my opinion not always a good idea, even if they are revised over time.
My English is not the best but I hope you can understand it.
GoboLinux has an hybrid solution, every package is in its own folder, but then for legacy purpose/Unix compatibility, there’s symlinks to the standard places in the FHS
When I first heard about this distro (somewhere around 2005 IIRC), I found the idea really compelling, and I’m a little surprised that it didn’t take off.
It seems to tackle multiple pain points at once : legacy/compatibility, package management simplified, discoverability, easing the pain for windows’ newcomers…
I guess it wasn’t a big enough selling point, even I didn’t really give it a chance despite my interest.
Yes!
This already exists in Mac OSX so I took it as an example. Personally I think something similar like this could be something very innovative for an open source operating system and especially this is very easy to understand and manageable for unexperienced users. Android, as another example has “.apk” packages (Android Package)
so Redox could have something like “Firefox.rex” (Redox Extension).
I made this post because I think it is easier to explain to a user on how to uninstall a programm by putting a single
file into the bin rather than typing in a command into the terminal.
Probably worth not reinventing every wheel – or creating yet another one
Flatpak and Snaps have been mentioned, Debian, too. Then there is 0install and others …
Qubes might be something else to look at (for compartmentalisation).
About the “innovation” in macOS: You have the core system, the (mostly unmanaged) app packages; to solve this, you then add (at least one of) MacPorts, Fink, Homebrew, Rudix, pkgsrc/pkgin, Nix … maybe not the way to look for sane package management, especially for multi-user systems
Please take a look at habita-sh, I think it is a better solution than Flatpak and Snappy.
You have full reusability between packages while also having the isolation when needed.
You can have for example 100 different versions of the same software running in parallel without issues(if a user decided to do this).
It is a Rust static-binary that has no dependencies(compiled against Musl).
Although, I don’t know how relevant is Flatpak and Habitat for Redox since both rely on Linux-specific sandboxing(namespaces).
Hello,
instead of throwing yet-another standalone package format, let’s revise the idea again.
Since Redox is URL based I think that an APP should be simply an URL too. The HTML/CSS/JS would be sandboxed and run in ChromeOS-app way. This could be achieved with embedding of Mozilla’s Servo Engine. Of course this supposes that the target app will be offline-aware single-page website. But isn’t that becoming true? Isn’t this the future?
Packages are obsolete in my opinion. The internet provides enough applications to be run. If you still disagree please watch the recent Stanford lecture by Alan Kay “How to Invent the Future”.
I’m thinking the Redox kernel would be an excellent base for a hypervisor platform, potentially/hopefully working as a drop-in replacement for Xen in Qubes.
I think that’s a really novel approach to files management. It makes file hierarchies way more human-readable, without (at least as far as I can tell) messing anything up.
According to @jackpot51 Redox programs are statically compiled and are therefore portable. I think an implication of this is that filesystem-hierarchy-dependent package management a la GoboLinux or NixOS would be unnecessary since that form of package management was conceived, IIRC, to prevent the so-called “dependency hell” which doesn’t apply to statically compiled packages such as those in Redox. I’m not sure if there are any guarantees in the OS’ design which ensures that this assumption will still hold in the future though. I think the most useful feature of Gobolinux and NixOS package management system that Redox doesn’t have is that multiple versions of packages can’t be installed because all the packages are dumped in /bin instead of in separate folders.
I’m not well-versed in web technologies and apps, so forgive me for my ignorance, but aren’t web apps slower than native compiled packages by virtue of needing to be first interpreted by a browser engine as opposed to being directly executed by the OS? If this is the case, then I’m not sure if web apps will be considered the be-all, end-all method of delivering applications, but could probably be used as an easy way to add more apps to the OS.
I like the idea of using servo/firefox-quantum for apps. However, they are slower and use too much memory. Although, RUST should be able to handle memory better, correct?
I hope someone build an electro alternate using firefox-quantum/servo/rust.
Applications should try to ship as many dependencies of their software as possible to not have the dependency hell with other applications that X needs Y version of Library but Z Application needs it.
