llenotre

Rust is not able to shield from everything. On top of that, there is a lot of unsafe code. I am 100% sure that fuzz-testing or pentests would reveal a lot of issues. This is not something I had time to work on yet.

Indeed, as I stated in the blog post, I am not very far from being able to run a text editor such as Vim or a compiler :)

Thank you very much! Even if nobody liked the project, I would not be planning to stop it. I am doing this as a hobby first!

Having even one other user than me would be terribly difficult but if it happens that would be super cool! If it does not happen, then I just have my own system and I am happy with it anyways!

So many thank to all of you for your support! This project has represented a lot of efforts for me and it means a lot!

Right now the website seems to be pretty slow/down. There is a lot of traffic, which was not expected. I also suspect there might be a DoS attack going on.

I will try to make it work better when I get home! (I am currently at work so I cannot give much attention to it right now)

Sorry for the inconvenience, but glad you appreciate the project!

Thank you very much!

The monolithic/module thing was imposed by the subjects at my school (since it started as a school project).

However, a part of me is feeling like it could make sense to do a big refactor to turn all of this into a micro kernel. However I am not willing to do this until I have a plan to make it right.

By the way, the 32 bits thing too was imposed by the school. I am now wondering if it still relevant to support it and just support 64 bits only...

I didn't know this project. I will check it out!

A lot of memory and concurrency issues have been eliminated. It is still a pain to debug, but a lot less than it was before though.

As an example, there is not a lot of chances you forget to use a mutex since the compiler would remind it to you by an error.

This is not a silver bullet though, things such as deadlocks are still present. Especially with interruptions.

To give an example, if you decide to lock a mutex, then an interruption happens, the code that locks the mutex will stop running until the interruption is over. If the interruption itself tries to lock the same mutex, then you have a deadlock, and the typing system cannot help you with this kind of problem.

The solution is to disable interruptions handling while the mutex is locked, but the compiler cannot enforce it.

Thank you for the feedback. I will fix that!