##Where is everyone?
Out of 192 users on the Discourse, I’ve been the only one to make a post within the last 3 days. The main site’s News section with “This Week in Redox” hasn’t been updated in 9 weeks, yet commits are being made at least once a day. For the last 62 weeks and a day that this project has been going, it seems to me like it’s already starting to burnout. If it’s not burning out, then it certainly seems to be mostly a one man show despite the 48 total contributors. By no means am I criticizing the project (yet) or anyone involved with it. I just want to know where everyone went.
##What is going on?
My main confusion lies within the unix-like branding and the disregard of POSIX compatibility. It seems to me that the two are not mutually exclusive. Further separation from being unix-like is suggested by the disregard of the Unix philosophy that “everything is a file”, and subsequently replacing that with “everything is a URL”. It appears that the branding of plan9-like would be more suitable. This is not merely a labeling issue, however, because these design choices conflict with the goals of this project, and directly manifest as some of the non-goals of this project.
For starters, “aiming towards a complete, safe Rust ecosystem” is a goal that does not explicitly align with any of the aforementioned design choices. Even with the intent to “improve the [kernel’s] security design when compared to other Unix-like kernels by using safe defaults and disallowing insecure configurations where possible”, the disregard for POSIX compatibility and abandonment of the “everything is a file” philosophy are design choices that do not directly contribute to this goal. Where, then, lies the rationale for these design choices? How do these design choices allow the users to “be able to use [Redox], without obstructions”? An obstruction seems to be the other contributors’ confusion with such design concepts, seeing as how the majority of users in the forums are familiar with, if not only used to, the design choices and/or structure of Linux. As I see it, this burden contributes to the rest of the community’s confusion and, quite possibly, their subsequent inactivity in the forums and project.
As for the non-goals, said design choices make it clear that this project does NOT in fact “stick to well-tested and proven correct designs”. This is not to say that ideas such as schemes and POSIX incompatibility are necessarily incorrect, nor that they have not been tested. However, such design choices are certainly not as well-tested as the contending ones, namely the “everything is a file” philosophy and POSIX compatibility. Furthermore, the “trade off between correctness and compatibility” directly conflicts with the project’s goal of “improv[ing] correctness and security”. Improving correctness cannot be accomplished by having it trade-off with compatibility, since improved compatibility will retrograde correctness. This is where the disregard for POSIX compatibility clearly obstructs the goals of the project, because achieving both security and compatibility is possible when POSIX compatibility exists, since that’s the whole point of POSIX in the first place.
Please take this all with a grain of salt. There are certainly a lot of unanswered questions stemming from the documentation and from the leaders and contributors as well — questions that, when answered, will clear up a lot of confusion surrounding the project and its design. Less confusion will ultimately create a stronger and more knowledgeable community that has clearly defined goals. However, as it stands now, the philosophy of “if it ain’t broke, don’t fix it”, as referred to in the goals of this project, does not persist in the current design choices and direction of Redox. Don’t get me wrong, it’s not that I’m necessarily for or against the project’s goals or the project’s design choices, but I believe that a proper explanation of the rationale behind these design choices is required, otherwise a modification of the project’s goals is in order.
