content/community.en.md

@@ -9,7 +9,7 @@ We follow the [Rust Code Of Conduct](https://www.rust-lang.org/policies/code-of-
 
 ## [Announcements](https://matrix.to/#/#redox-announcements:matrix.org)
 
-We do our announcements on [this](https://matrix.to/#/#redox-announcements:matrix.org) Matrix room, it's public and you don't need to login on Matrix to read it.
+We do our announcements on the [Announcements](https://matrix.to/#/#redox-announcements:matrix.org) room, it's public and you don't need to login on Matrix to read it.
 
 - #redox-announcements:matrix.org (Use this Matrix room address if you don't want to use the external Matrix link)
 
@@ -21,32 +21,36 @@ Matrix has several different clients. [Element](https://element.io/) is a common
 
 If you have problems with Element, try [Fractal](https://gitlab.gnome.org/World/fractal).
 
-- Join [this](https://matrix.to/#/#redox-join:matrix.org) room and don't forget to request an invite to the Redox Matrix space.
+- Join the [Join Requests](https://matrix.to/#/#redox-join:matrix.org) room and send a message requesting for an invite to the Redox Matrix space (the purpose of this is to avoid spam and bots).
 - #redox-join:matrix.org (Use this Matrix room address if you don't want to use the external Matrix link)
 
 (We recommend that you leave the "Join Requests" room after your entry on Redox space)
 
 If you want to have a big discussion in our rooms, you should use a Element thread, it's more organized and easy to keep track if more discussions happen on the same room.
 
-You cand find more information on [this](https://doc.redox-os.org/book/ch13-01-chat.html) page.
+You cand find more information on the [Chat](https://doc.redox-os.org/book/chat.html) page.
 
 ## [Discord](https://discord.gg/JfggvrHGDY)
 
-We have a Discord server as an alternative for Matrix.
+We have a Discord server as an alternative for Matrix, open the #join-requests channel and send a message requesting to be a member (the purpose of this is to avoid spam and bots)
 
 (The Matrix messages are sent to Discord and the Discord messages are sent to Matrix, using a bot)
 
 ## [Summer of Code](/rsoc)
 
 The **Redox Summer of Code** (RSoC) program runs annually when funding permits, and we may participate in other Summer of Code type programs.
-An overview of our Summer of Code programs and our plans for this year are [here](/rsoc).
+An overview of our Summer of Code programs and our plans for this year can be found on the [RSoC](/rsoc) page.
 Check out our [RSoC Proposal Guide](/rsoc-proposal-how-to) and [Project Suggestions](/rsoc-project-suggestions).
 
 ## [GitLab](https://gitlab.redox-os.org/redox-os/redox)
 
 A slightly more formal way of communication with fellow Redox devs, but a little less quick and convenient like the chat. Submit an issue when you run into problems compiling or testing. Issues can also be used if you would like to discuss a certain topic: be it features, code style, code inconsistencies, minor changes and fixes, etc.
 
-If you want to create an account, read this [page](https://doc.redox-os.org/book/ch12-01-signing-in-to-gitlab.html).
+If you want to create an account, read the [Signing in to GitLab](https://doc.redox-os.org/book/signing-in-to-gitlab.html) page.
+
+Once you create an issue don't forget to post the link on the Dev or Support rooms of the chat, because the GitLab email notifications have distractions (service messages or spam) and most developers don't left their GitLab pages open to receive desktop notifications from the web browser (which require a custom setting to receive issue notifications).
+
+By doing this you help us to pay attention to your issues and avoid them to be accidentally forgotten.
 
 If you have ready MRs (merge requests) you must send the links in the [MRs](https://matrix.to/#/#redox-mrs:matrix.org) room. To join this room, you will need to request an invite in the [Join Requests](https://matrix.to/#/#redox-join:matrix.org) room.
 

content/community.fr.md

@@ -29,7 +29,7 @@ Si vous rencontrez des problèmes avec Element, essayez [nheko](https://nheko-re
 
 Si vous souhaitez avoir une grande discussion dans nos salons, vous devez utiliser un fil de discussion Element, il est plus organisé et plus facile à suivre si d'autres discussions ont lieu dans le même salon.
 
-Vous pouvez trouver plus d'informations sur [cette page](https://doc.redox-os.org/book/ch13-01-chat.html).
+Vous pouvez trouver plus d'informations sur [cette page](https://doc.redox-os.org/book/chat.html).
 
 ## [Summer of Code](/rsoc)
 
@@ -41,7 +41,7 @@ Consultez notre [Guide de proposition RSoC](/rsoc-proposal-how-to) et nos [Sugge
 
 Un moyen de communication un peu plus formel avec les autres développeurs de Redox, mais un peu moins rapide et pratique que le chat. Soumettez une Issue lorsque vous rencontrez des problèmes de compilation ou de tests. Une Issue peut aussi être ouverte si vous souhaitez simplement discuter d'un sujet en particulier, qu'il s'agisse de fonctionnalités, de style de code, d'incohérences de code, de modifications et de correctifs mineurs, etc.
 
-Si vous souhaitez créer un compte, lisez cette [page](https://doc.redox-os.org/book/ch12-01-signing-in-to-gitlab.html).
+Si vous souhaitez créer un compte, lisez cette [page](https://doc.redox-os.org/book/signing-in-to-gitlab.html).
 
 Si vous avez des MRs prêts (merge requests), vous devez envoyer les liens sur le salon [MRs](https://matrix.to/#/#redox-mrs:matrix.org). Pour rejoindre ce salon, une vous aurez besoin de demander un invitation dans le salon [Join Requests](https://matrix.to/#/#redox-join:matrix.org).
 

content/community.pt.md

@@ -22,18 +22,18 @@ O Element funciona em navegadores web, Linux, MacOSX, Windows, Android e iOS.
 
 Caso tenha problemas com o Element, teste o [Fractal](https://gitlab.gnome.org/World/fractal).
 
-- Entre [nesta](https://matrix.to/#/#redox-join:matrix.org) sala e não esqueça de solicitar um convite para o espaço do Redox.
+- Entre na sala [Join Requests](https://matrix.to/#/#redox-join:matrix.org) e envie uma mensagem solicitando um convite para o espaço do Redox (o propósito disso é para evitar spam e bots).
 - #redox-join:matrix.org (Use esse endereço de sala do Matrix caso não queira utilizar o link externo do Matrix)
 
 (Nós recomendamos que você saia da sala "Join Requests" depois de entrar no espaço do Redox)
 
 Caso você tenha uma grande discussão nas nossas salas, você deve usar um thread do Element, pois é mais organizado e fácil de acompanhar caso mais discussões ocorram na mesma sala.
 
-Você pode encontrar mais informações [nesta](https://doc.redox-os.org/book/ch13-01-chat.html) página.
+Você pode encontrar mais informações na página [Chat](https://doc.redox-os.org/book/chat.html).
 
 ## [Discord](https://discord.gg/JfggvrHGDY)
 
-Nós temos um servidor no Discord como alternativa ao Matrix.
+Nós temos um servidor no Discord como alternativa ao Matrix, abra o canal #join-requests e envie uma mensagem pedindo para ser um membro (o propósito disso é para evitar spam e bots)
 
 (As mensagens do Matrix são enviadas para o Discord e as mensagens do Discord são enviadas para o Matrix, utilizando um bot)
 
@@ -41,7 +41,7 @@ Nós temos um servidor no Discord como alternativa ao Matrix.
 
 O programa **Redox Summer of Code** (RSoC) é relizado anualmente quando as doações permitem e nós podemos participar de outros programas do mesmo tipo.
 
-Um resumo dos nossos programas Summer of Code e nossos planos para esse ano estão [neste](/rsoc) link.
+Um resumo dos nossos programas Summer of Code e nossos planos para esse ano estão na página [RSoC](/rsoc).
 
 Veja nosso [guia de proposta RSoC](/rsoc-proposal-how-to) e [sugestões de projeto](/rsoc-project-suggestions).
 
@@ -51,7 +51,11 @@ Uma forma mais formal de comunicação com os desenvolvedores do Redox, porém m
 
 Envie uma Issue se você tiver problemas compilando/testando ou apenas queira discutir algum assunto, seja funções, estilo de código, inconsistências de código, pequenas mudanças ou correções.
 
-Se você quiser criar uma conta, leia essa [página](https://doc.redox-os.org/book/ch12-01-signing-in-to-gitlab.html).
+Se você quiser criar uma conta, leia a página [Signing in to GitLab](https://doc.redox-os.org/book/signing-in-to-gitlab.html).
+
+Assim que você criar uma issue não se esqueça de postar o link nas salas "Dev" ou "Support" do chat, por que as notificações de email do GitLab possuem distrações (mensagens de serviço e spam) e a maioria dos programadores não deixam suas páginas do GitLab abertas no navegador web (que requer uma configuração customizada para receber notificações de issues).
+
+Fazendo isso você nos ajuda a prestar atenção nas suas issues e evita que elas sejam esquecidas acidentalmente.
 
 Se você tiver MRs (merge requests) prontos você precisa enviar o link deles na sala [MRs](https://matrix.to/#/#redox-mrs:matrix.org), antes de entrar nesta sala você precisa solicitar um convite para o espaço Matrix na sala [Join Requests](https://matrix.to/#/#redox-join:matrix.org).
 

content/docs.en.md

@@ -10,7 +10,7 @@ We highly recommend that you start with the [Book](https://doc.redox-os.org/book
 
 ### Cargo Docs
 
-- [redox_syscall](https://docs.rs/redox_syscall/latest/syscall/) - Documentation for the Redox system calls.
+- [libredox](https://docs.rs/libredox/latest/libredox/) - Documentation of the Redox system library.
 
 - [libstd](https://doc.rust-lang.org/stable/std/) - Documentation for the Rust standard library.
 
@@ -30,4 +30,4 @@ We highly recommend that you start with the [Book](https://doc.redox-os.org/book
 
 ## Contributing to Redox
 
-- Read the [CONTRIBUTING.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md)
+- Read the [CONTRIBUTING](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md) document

content/docs.pt.md

@@ -10,7 +10,7 @@ Nós recomendamos que você comece pelo [Livro](https://doc.redox-os.org/book/),
 
 ### Cargo Docs
 
-- [redox_syscall](https://docs.rs/redox_syscall/latest/syscall/) - Documentação para as chamadas de sistema do Redox.
+- [libredox](https://docs.rs/libredox/latest/libredox/) - Documentação da biblioteca de sistema do Redox.
 
 - [libstd](https://doc.rust-lang.org/stable/std/) - Documentação para a biblioteca padrão da Rust.
 
@@ -30,4 +30,4 @@ Nós recomendamos que você comece pelo [Livro](https://doc.redox-os.org/book/),
 
 ## Contribuindo pro Redox
 
-- Leia o [CONTRIBUTING.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md)
+- Leia o documento [CONTRIBUTING](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md)

content/donate.en.md

@@ -18,7 +18,7 @@ You can donate to Redox OS the following ways:
 
 ## Merch
 
-We sell T-shirts on Teespring, you can buy them [here](https://redox-os.creator-spring.com/).
+We sell T-shirts on Teespring, you can buy them in [our Teespring website](https://redox-os.creator-spring.com/).
 
 Each sale is a donation to the Redox OS Nonprofit.
 

content/donate.pt.md

@@ -19,7 +19,7 @@ Você pode doar para o Redox OS das seguintes formas:
 
 ## Loja
 
-Nós vendemos camisetas pela Teespring, você pode comprar [aqui](https://redox-os.creator-spring.com/).
+Nós vendemos camisetas pela Teespring, você pode comprar na [nossa loja na Teespring](https://redox-os.creator-spring.com/).
 
 Cada venda é uma doação para a Organização Sem Fins Lucrativos Redox OS.
 

content/faq.en.md

@@ -6,6 +6,7 @@ This page covers questions and answers for newcomers and end-users.
 
 - [What is Redox?](#what-is-redox)
 - [What does Redox mean?](#what-does-redox-mean)
+- [What is a microkernel?](#what-is-a-microkernel)
 - [What features does Redox have?](#what-features-does-redox-have)
     - [Microkernel benefits](#microkernel-benefits)
     - [Rust benefits](#rust-benefits)
@@ -15,7 +16,6 @@ This page covers questions and answers for newcomers and end-users.
 - [What I can do with Redox?](#what-i-can-do-with-redox)
 - [What is an Unix-like OS?](#what-is-an-unix-like-os)
 - [How Redox was influenced by other systems?](#how-redox-was-influenced-by-other-systems)
-- [What is a microkernel?](#what-is-a-microkernel)
 - [What programs can Redox run?](#what-programs-can-redox-run)
 - [How to install programs on Redox?](#how-to-install-programs-on-redox)
 - [Which are the Redox variants?](#which-are-the-redox-variants)
@@ -36,9 +36,9 @@ It aims to be a complete alternative to Linux and BSD.
 
 ### Current status
 
-Redox is alpha/beta quality software, because we implement new features while fixing the bugs.
+Redox is in alpha development phase, we implement new features and fix bugs.
 
-Because of this, it's not ready for daily usage yet. Feel free to test the system until its maturity and **don't store your sensitive data without a proper backup.**
+Because of this it's not ready for daily usage yet. Feel free to test the system until its maturity and **don't store your sensitive data without a proper backup.**
 
 The 1.0 version will be released once all system APIs are considered stable.
 
@@ -48,29 +48,37 @@ The 1.0 version will be released once all system APIs are considered stable.
 
 It sounds like Minix and Linux too.
 
+## What is a microkernel?
+
+A microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system, which runs on the highest privilege of the processor.
+
+This approach to OS design brings more stability and security, with a small cost on performance.
+
+You can read more about it on the [Microkernels](https://doc.redox-os.org/book/microkernels.html) page.
+
 ## What features does Redox have?
 
 ### Microkernel benefits
 
 - **True modularity**
 
-You can modify/change many system components without a system restart, similar to but safer than some kernel modules and [livepatching](https://en.wikipedia.org/wiki/Kpatch).
+You can modify/change many system components without a system restart, similar to but safer than some modules in monolithic kernels and [livepatching](https://en.wikipedia.org/wiki/Kpatch).
 
 - **Bug isolation**
 
-Most system components run in user-space on a microkernel system. Because of this, bugs in most system components won't [crash the system/kernel](https://en.wikipedia.org/wiki/Kernel_panic).
+Most system components run in user-space on a microkernel system. Because of this some types of bugs in most system components won't [crash or damage the system or kernel](https://en.wikipedia.org/wiki/Kernel_panic).
 
 - **Restartless design**
 
 A mature microkernel changes very little (except for bug fixes), so you won't need to restart your system very often to update it.
 
-Since most of the system components are in userspace, they can be replaced on-the-fly, reducing downtime of servers a lot.
+Since most of the system components are in user-space they can be replaced on-the-fly, reducing the downtime of servers a lot.
 
 - **Easy to develop and debug**
 
-Most of the system components run in userspace, simplifying the testing and debugging.
+Most of the system components run in user-space, simplifying the testing and debugging.
 
-You can read more about the above benefits on [this](https://doc.redox-os.org/book/ch04-01-microkernels.html) page.
+You can read more about the above benefits on the [Microkernels](https://doc.redox-os.org/book/microkernels.html) page.
 
 ### Rust benefits
 
@@ -80,25 +88,27 @@ The restrictive syntax and compiler requirements to build the code reduce the pr
 
 - **Less vulnerable to data corruption**
 
-The Rust compiler helps the programmer to avoid memory errors and race conditions, which reduces the probability of data corruption bugs.
+The Rust compiler helps the programmer to avoid memory errors and race conditions, which reduces the probability of data corruption bugs due to implementation errors.
+
+- **No need for C/C++ exploit mitigations on system components**
 
-- **No need for C/C++ exploit mitigations**
+As Redox is written in Rust we don't need C/C++ exploit mitigations for the system components, reducing the system complexity and increasing the program compatibility.
 
-The microkernel design written in Rust protects against memory defects that one might see in software written in C/C++.
+The microkernel design written in Rust protects against memory defects that one might see in operating systems written in C/C++.
 
 By isolating the system components from the kernel, the [attack surface](https://en.wikipedia.org/wiki/Attack_surface) is very limited.
 
 - **Improved security and reliability without significant performance impact**
 
-As the kernel is small, it uses less memory to do its work. The limited kernel code size helps us work towards a bug-free status ([KISS](https://en.wikipedia.org/wiki/KISS_principle)).
+As the kernel is small it uses less memory to do its work. The limited kernel code size helps us work towards a bug-free status ([KISS](https://en.wikipedia.org/wiki/KISS_principle)).
 
-Rust's safe and fast language design, combined with the small kernel code size, helps ensure a reliable, performant and easy to maintain core.
+Rust's safe and fast language design, combined with the small kernel code size, helps ensure a reliable, performant and easy to maintain system core.
 
 - **Thread-safety**
 
 The C/C++ support for thread-safety is quite fragile. As such, it is very easy to write a program that looks safe to run across multiple threads, but which introduces subtle bugs or security holes. If one thread accesses a piece of state at the same time that another thread is changing it, the whole program can exhibit some truly confusing and bizarre bugs.
 
-You can see [this](https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) example of a serious class of security bugs that thread-safety fixes.
+You can see [this Wikipedia example](https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) of a serious class of security bugs that thread-safety fixes.
 
 In Rust, this kind of bug is easy to avoid: the same type system that keeps us from writing memory unsafety prevents us from writing dangerous concurrent access patterns
 
@@ -118,8 +128,8 @@ Expect high performance and data safety (copy-on-write, data integrity, volumes,
 
 You can see how Redox is compared to Linux, FreeBSD and Plan 9 on these pages:
 
-- [Redox OS Features](https://doc.redox-os.org/book/ch04-11-features.html)
-- [Comparing Redox to Other OSes](https://doc.redox-os.org/book/ch01-05-how-redox-compares.html)
+- [Redox OS Features](https://doc.redox-os.org/book/features.html)
+- [Comparing Redox to Other OSes](https://doc.redox-os.org/book/how-redox-compares.html)
 
 ## What is the purpose of Redox?
 
@@ -127,7 +137,7 @@ The main goal of Redox is to be a general-purpose OS, while maintaining security
 
 Redox aims to be an alternative to existing Unix systems (Linux/BSD), with the ability to run most Unix programs with only recompilation or minimal modifications.
 
-- [Our Goals](https://doc.redox-os.org/book/ch01-01-our-goals.html)
+- [Our Goals](https://doc.redox-os.org/book/our-goals.html)
 
 ## What I can do with Redox?
 
@@ -135,7 +145,7 @@ As a general-purpose operating system, you will be able to do almost any task on
 
 Redox is still under development, so our list of supported applications is currently limited, but growing.
 
-- [Use Cases](https://doc.redox-os.org/book/ch01-04-redox-use-cases.html)
+- [Use Cases](https://doc.redox-os.org/book/redox-use-cases.html)
 
 ## What is an Unix-like OS?
 
@@ -152,7 +162,7 @@ Any OS compatible with the [Single Unix Specification](https://en.wikipedia.org/
 This Bell Labs OS brings the concept of "Everything is a File" to the highest level, doing all the system communication from the filesystem.
 
 - [Drew DeVault explains the Plan 9](https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html)
-- [Plan 9's influence on Redox](https://doc.redox-os.org/book/ch05-00-urls-schemes-resources.html)
+- [Plan 9's influence on Redox](https://doc.redox-os.org/book/urls-schemes-resources.html)
 
 ### [Minix](https://minix3.org/)
 
@@ -160,7 +170,7 @@ The most influential Unix-like system with a microkernel. It has advanced featur
 
 Redox is largely influenced by Minix - it has a similar architecture but with a feature set written in Rust.
 
-- [How Minix influenced the Redox design](https://doc.redox-os.org/book/ch04-01-microkernels.html)
+- [How Minix influenced the Redox design](https://doc.redox-os.org/book/microkernels.html)
 
 ### [seL4](https://sel4.systems/)
 
@@ -182,14 +192,6 @@ The most advanced monolithic kernel and biggest open-source project of the world
 
 Redox tries to implement the Linux performance improvements in a microkernel design.
 
-## What is a microkernel?
-
-A microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system, which runs on the highest privilege of the processor.
-
-This approach to OS design brings more stability and security, with a small cost on performance.
-
-You can read more about it [here](https://doc.redox-os.org/book/ch04-01-microkernels.html).
-
 ## What programs can Redox run?
 
 Redox is designed to be source-compatible with most Unix, Linux and POSIX-compliant applications, only requiring compilation.
@@ -208,15 +210,15 @@ Some important software that Redox supports:
 - GCC
 - LLVM
 
-You can see all Redox components and ported programs [here](https://static.redox-os.org/pkg/x86_64-unknown-redox/).
+You can see all Redox components and ported programs on the [build server list](https://static.redox-os.org/pkg/x86_64-unknown-redox/).
 
 ## How to install programs on Redox?
 
-Redox has a package manager similar to `apt` (Debian) and `pkg` (FreeBSD), you can see how to use it on [this](https://doc.redox-os.org/book/ch02-08-pkg.html) page.
+Redox has a package manager similar to `apt` (Debian) and `pkg` (FreeBSD), you can see how to use it on the [Downloading packages with pkg](https://doc.redox-os.org/book/pkg.html) page.
 
 ## Which are the Redox variants?
 
-Redox has some variants for each task, take a look at them below:
+Redox has some variants for a group of tasks, take a look at them below:
 
 - `minimal` - The most minimal variant with a basic system without network support. Aimed for embedded devices, very old computers, testers and developers.
 
@@ -248,8 +250,9 @@ Have a look at [HARDWARE.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/m
 
 - ACPI
 - PCI
+- USB
 
-(USB soon)
+(Support for USB devices using hubs will come soon)
 
 ### Video
 
@@ -307,20 +310,18 @@ A [hypervisor](https://en.wikipedia.org/wiki/Hypervisor) is a program providing
 
 ## How do I build Redox?
 
-Currently Redox has a bootstrap script for Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE and FreeBSD with unmaintained support for other distributions.
-
-We also offer Podman as our universal compilation method. It is the recommended build process for non-Debian systems because it avoids environment problems on the build process.
+Read the following pages:
 
-- [Redox Book Guide](https://doc.redox-os.org/book/ch02-05-building-redox.html) - (Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE and FreeBSD)
-- [Redox Book Podman Guide](https://doc.redox-os.org/book/ch02-06-podman-build.html)
+- [Podman Build](https://doc.redox-os.org/book/podman-build.html)
+- [Native Build](https://doc.redox-os.org/book/building-redox.html)
 
 ## How to troubleshoot your build in case of errors
 
-Read [this](https://doc.redox-os.org/book/ch08-05-troubleshooting.html) page or join us on [Redox Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+Read the [Troubleshooting](https://doc.redox-os.org/book/troubleshooting.html) page or join us on the [Redox Chat](https://doc.redox-os.org/book/chat.html).
 
 ## How to report bugs on Redox
 
-Read [this](https://doc.redox-os.org/book/ch12-03-creating-proper-bug-reports.html) page and check the GitLab Issues to see if your problem was reported.
+Read the [Creating Proper Bug Reports](https://doc.redox-os.org/book/creating-proper-bug-reports.html) page and check the GitLab Issues to see if your problem was reported.
 
 ## How do I contribute to Redox?
 
@@ -330,4 +331,4 @@ You can contribute to Redox in many ways, you can see them on [CONTRIBUTING](htt
 
 - Have a look at the [Documentation](/docs/) page for more details of Redox internals.
 - Have a look at the [Redox Book](https://doc.redox-os.org/book/) to see if it answer your question or solve your problem.
-- If the documentation or the book does not answer your question, ask your question or say your problem on the [Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+- If the documentation or the book does not answer your question, ask your question or say your problem on the [Chat](https://doc.redox-os.org/book/chat.html).

content/faq.fr.md

@@ -108,7 +108,7 @@ Attendez-vous à des performances élevées et à la sécurité des données (co
 
 ### Comparaison avec d'autres systèmes d'exploitation
 
-Vous pouvez voir comment Redox est comparé à Linux, FreeBSD et Plan 9 sur [cette](https://doc.redox-os.org/book/ch04-11-features.html) page.
+Vous pouvez voir comment Redox est comparé à Linux, FreeBSD et Plan 9 sur [cette](https://doc.redox-os.org/book/features.html) page.
 
 ## Quelle est l'utilité de Redox?
 
@@ -116,7 +116,7 @@ L'objectif principal de Redox est d'être un système d'exploitation à usage g
 
 Redox vise à être une alternative aux systèmes Unix existants (Linux/BSD), avec la possibilité d'exécuter la plupart des programmes Unix avec seulement une recompilation ou des modifications minimales.
 
-- [Nos objectifs](https://doc.redox-os.org/book/ch01-01-our-goals.html)
+- [Nos objectifs](https://doc.redox-os.org/book/our-goals.html)
 
 ## Que peut-on faire avec Redox?
 
@@ -124,7 +124,7 @@ En tant que système d'exploitation à usage général, vous pourrez faire presq
 
 Redox est toujours en cours de développement, donc notre liste d'applications prises en charge est actuellement limitée, mais en croissance.
 
-- [Cas d'utilisation](https://doc.redox-os.org/book/ch01-04-redox-use-cases.html)
+- [Cas d'utilisation](https://doc.redox-os.org/book/redox-use-cases.html)
 
 ## Qu'est-ce qu'un système d'exploitation de type Unix?
 
@@ -141,7 +141,7 @@ Tout système d'exploitation compatible avec [la spécification unique Unix](htt
 Ce système d'exploitation Bell Labs amène le concept de "tout est un fichier" au plus haut niveau, en effectuant toutes les communications système à partir du système de fichiers.
 
 - [Explication de Drew DeVault de Plan 9](https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html)
-- [L'influence de Plan 9's sur Redox](https://doc.redox-os.org/book/ch05-00-urls-schemes-resources.html)
+- [L'influence de Plan 9's sur Redox](https://doc.redox-os.org/book/urls-schemes-resources.html)
 
 ### [Minix](https://minix3.org/)
 
@@ -149,7 +149,7 @@ Le système de type Unix le plus influent avec un micro-noyau, il possède des f
 
 Redox est largement inspiré de Minix, il a une architecture et un ensemble de fonctionnalités similaires écrits en Rust.
 
-- [Comment Minix a influence la conception de Redox](https://doc.redox-os.org/book/ch04-01-microkernels.html)
+- [Comment Minix a influence la conception de Redox](https://doc.redox-os.org/book/microkernels.html)
 
 ### [seL4](https://sel4.systems/)
 
@@ -175,7 +175,7 @@ Un micro-noyau est la quantité quasi minimale de logiciels pouvant fournir les
 
 Cette approche de la conception du système d'exploitation apporte plus de stabilité et de sécurité, avec un faible coût sur les performances.
 
-- [Explications du livre de Redox](https://doc.redox-os.org/book/ch04-01-microkernels.html)
+- [Explications du livre de Redox](https://doc.redox-os.org/book/microkernels.html)
 
 ## Quels programmes peuvent tourner sur Redox?
 
@@ -200,7 +200,7 @@ Vous pouvez voir tous les composants/programmes portés sur Redox [ici](https://
 
 Redox a un gestionnaire de paquets similaire à `apt` (Debian) et `pkg` (FreeBSD), vous pouvez voir comment l'utiliser sur cette page :
 
-- [Gestionnaire de paquets de Redox](https://doc.redox-os.org/book/ch02-08-pkg.html)
+- [Gestionnaire de paquets de Redox](https://doc.redox-os.org/book/pkg.html)
 
 ## Quelles sont les variantes de Redox?
 
@@ -300,8 +300,8 @@ Actuellement, Redox a un script d'amorçage pour Pop OS!, Ubuntu, Debian, Fedora
 
 Nous proposons également Podman comme méthode de compilation universelle. C'est le processus de construction recommandé pour les systèmes non-Debian car il évite les problèmes d'environnement sur le processus de construction.
 
-- [Guide de compilation du livre Redox](https://doc.redox-os.org/book/ch02-05-building-redox.html) - (Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE et FreeBSD)
-- [Guide Podman du livre Redox](https://doc.redox-os.org/book/ch02-06-podman-build.html)
+- [Guide de compilation du livre Redox](https://doc.redox-os.org/book/building-redox.html) - (Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE et FreeBSD)
+- [Guide Podman du livre Redox](https://doc.redox-os.org/book/podman-build.html)
 
 ### Comment lancer QEMU sans interface graphique?
 
@@ -311,13 +311,13 @@ Exécutez:
 
 ### Comment dépanner un build en cas d'erreur?
 
-Lisez [cette](https://doc.redox-os.org/book/ch08-05-troubleshooting.html) page ou rejoignez-nous sur [Redox Chat](https://doc.redox-os.org/book /ch13-01-chat.html).
+Lisez [cette](https://doc.redox-os.org/book/troubleshooting.html) page ou rejoignez-nous sur [Redox Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
 
 ### Comment rapporter des bugs de Redox?
 
 Vérifiez d'abord les problèmes de GitLab pour voir si votre problème est déjà connu.
 
-- [Guide de rapport de bogue du livre Redox](https://doc.redox-os.org/book/ch12-03-creating-proper-bug-reports.html)
+- [Guide de rapport de bogue du livre Redox](https://doc.redox-os.org/book/creating-proper-bug-reports.html)
 
 ## Comment contribuer à Redox?
 
@@ -327,5 +327,5 @@ Vous pouvez contribuer à Redox de plusieurs façons, vous pouvez les voir sur [
 
 - Jetez un oeil à la page de  [Documentation](/docs/) pour plus de détails internes de Redox.
 - Jetez un oeil au [livre Redox](https://doc.redox-os.org/book/) pour voir s'il répond à vos questions/résout votre problème.
-- Si le livre ne répond pas à votre question, posez votre question/dites votre problème dans le [Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+- Si le livre ne répond pas à votre question, posez votre question/dites votre problème dans le [Chat](https://doc.redox-os.org/book/chat.html).
 

content/faq.pl.md

@@ -116,7 +116,7 @@ Głównym celem Redox jest bycie systemem operacyjnym ogólnego przeznaczenia, p
 
 Redox ma być alternatywą dla istniejących systemów uniksowych (Linux/BSD), z możliwością uruchamiania większości programów uniksowych jedynie po rekompilacji lub minimalnych modyfikacjach.
 
-- [Nasze cele](https://doc.redox-os.org/book/ch01-01-our-goals.html)
+- [Nasze cele](https://doc.redox-os.org/book/our-goals.html)
 
 ## Co mogę zrobić z Redox?
 
@@ -124,7 +124,7 @@ Jako system operacyjny ogólnego przeznaczenia będziesz w stanie wykonać prawi
 
 Redox jest wciąż w fazie rozwoju, więc lista obsługiwanych aplikacji jest obecnie ograniczona, ale stale dodajemy nowe aplikacje i ich lista stale rośnie. 
 
-- [Przypadki użycia](https://doc.redox-os.org/book/ch01-04-redox-use-cases.html)
+- [Przypadki użycia](https://doc.redox-os.org/book/redox-use-cases.html)
 
 
 ## Co to jest system operacyjny typu Unix?
@@ -143,7 +143,7 @@ Dowolny system operacyjny zgodny ze [Single Unix Specification](https://en.wikip
 Ten system operacyjny Bell Labs przenosi koncepcję „wszystko jest plikiem” na najwyższy poziom, realizując całą komunikację systemową z systemu plików.
 
 - [Drew DeVault wyjaśnia Plan 9](https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html)
-- [Wpływ Planu 9 na Redox](https://doc.redox-os.org/book/ch05-00-urls-schemes-resources.html)
+- [Wpływ Planu 9 na Redox](https://doc.redox-os.org/book/urls-schemes-resources.html)
 
 ### [Minix](https://minix3.org/)
 
@@ -151,7 +151,7 @@ Najbardziej wpływowy system uniksowy z mikrojądrem, posiadający zaawansowane
 
 Redox jest w dużej mierze inspirowany Minixem, ma podobną architekturę i zestaw funkcji napisany w Rust.
 
-- [Jak Minix wpłynął na projekt Redox](https://doc.redox-os.org/book/ch04-01-microkernels.html)
+- [Jak Minix wpłynął na projekt Redox](https://doc.redox-os.org/book/microkernels.html)
 
 ### [seL4](https://sel4.systems/)
 
@@ -177,7 +177,7 @@ Mikrojądro to niemal minimalna ilość oprogramowania, która może zapewnić m
 
 Takie podejście do projektowania systemu operacyjnego zapewnia większą stabilność i bezpieczeństwo przy niewielkim koszcie wydajności.
 
-- [Wiecej informacji w ksiażce Redox](https://doc.redox-os.org/book/ch04-01-microkernels.html)
+- [Wiecej informacji w ksiażce Redox](https://doc.redox-os.org/book/microkernels.html)
 
 ## Jakie programy może uruchomić Redox?
 
@@ -204,7 +204,7 @@ Możesz zobaczyć wszystkie przeniesione programy/komponenty do Redox [tutaj](ht
 
 Redox ma menedżera pakietów podobnego do `apt` (Debian) i `pkg` (FreeBSD), możesz zobaczyć, jak go używać na tej stronie:
 
-- [Redox manager pakietów](https://doc.redox-os.org/book/ch02-08-pkg.html)
+- [Redox manager pakietów](https://doc.redox-os.org/book/pkg.html)
 
 ## Jakie są warianty Redox?
 
@@ -304,8 +304,8 @@ Obecnie Redox posiada skrypt startowy dla Pop OS!, Ubuntu, Debian, Fedora, Arch
 
 Oferujemy również Podman jako naszą uniwersalną metodę kompilacji. Jest to zalecany proces kompilacji dla systemów innych niż Debian, ponieważ pozwala uniknąć problemów środowiskowych w procesie kompilacji.
 
-- [Redox przewodnik](https://doc.redox-os.org/book/ch02-05-building-redox.html) - (Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE and FreeBSD)
-- [Redox Podman przewodnk](https://doc.redox-os.org/book/ch02-06-podman-build.html)
+- [Redox przewodnik](https://doc.redox-os.org/book/building-redox.html) - (Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE and FreeBSD)
+- [Redox Podman przewodnk](https://doc.redox-os.org/book/podman-build.html)
 
 ### Jak uruchomić QEMU bez GUI
 
@@ -315,13 +315,13 @@ Uruchom:
 
 ### Jak rozwiązywać problemy z kompilacją w przypadku błędów
 
-Przeczytaj [tą](https://doc.redox-os.org/book/ch08-05-troubleshooting.html) stronę lub dołącz do nas na [Redox Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+Przeczytaj [tą](https://doc.redox-os.org/book/troubleshooting.html) stronę lub dołącz do nas na [Redox Chat](https://doc.redox-os.org/book/chat.html).
 
 ### Jak zgłaszać błędy w Redox
 
 Najpierw sprawdź Problemy na GitLabie, aby sprawdzić, czy Twój problem jest już znany.
 
-- [Redox przewodnik jak zgłaszać błedy](https://doc.redox-os.org/book/ch12-03-creating-proper-bug-reports.html)
+- [Redox przewodnik jak zgłaszać błedy](https://doc.redox-os.org/book/creating-proper-bug-reports.html)
 
 ## Jak mogę przyczynić się do rozwoju projektu Redox?
 
@@ -331,5 +331,5 @@ Możesz przyczynić się na wiele sposobów do rozwoju Redox OS, wiecej informac
 
 - Spójrz na stronę [Dokumentacja](/docs/), aby uzyskać więcej szczegółów na temat elementów wewnętrznych Redox.
 - Spójrz na [Redox Book](https://doc.redox-os.org/book/) aby sprawdzić, czy odpowiada na Twoje pytania/rozwiązuje problem.
-- Jeśli książka nie zawiera odpowiedzi na Twoje pytanie, zadaj pytanie/przedstaw swój problem na stronie [Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+- Jeśli książka nie zawiera odpowiedzi na Twoje pytanie, zadaj pytanie/przedstaw swój problem na stronie [Chat](https://doc.redox-os.org/book/chat.html).
 

content/faq.pt.md

@@ -6,6 +6,7 @@ Essa página contém perguntas e respostas para iniciantes e usuários comuns.
 
 - [O que é o Redox?](#o-que-%C3%A9-o-redox)
 - [O que Redox significa?](#o-que-redox-significa)
+- [O que é um microkernel?](#o-que-%C3%A9-um-microkernel)
 - [Quais funções o Redox possui?](#quais-fun%C3%A7%C3%B5es-o-redox-possui)
     - [Benefícios do Microkernel](#benefícios-do-microkernel)
     - [Benefícios da Rust](#benefícios-da-rust)
@@ -15,7 +16,7 @@ Essa página contém perguntas e respostas para iniciantes e usuários comuns.
 - [O que posso fazer com o Redox?](#o-que-posso-fazer-com-o-redox)
 - [O que é um sistema Unix-like?](#o-que-%C3%A9-um-sistema-unix-like)
 - [Como o Redox foi influenciado por outros sistemas?](#como-o-redox-foi-influenciado-por-outros-sistemas)
-- [O que é um microkernel?](#o-que-%C3%A9-um-microkernel)
+
 - [Quais programas o Redox executa?](#quais-programas-o-redox-executa)
 - [Como instalar programas no Redox?](#como-instalar-programas-no-redox)
 - [Quais são as variantes do Redox?](#quais-são-as-variantes-do-redox)
@@ -38,11 +39,11 @@ O Redox busca ser uma alternativa completa para o Linux e BSD.
 
 ### Estado atual
 
-O Redox está em qualidade alpha/beta, pois implementamos novas funções enquanto corrigimos bugs.
+O Redox está na fase de desenvolvimento alpha, onde novas funções são implementadas e bugs são corrigidos.
 
 Portanto, ele não está pronto para uso diário, sinta-se livre para testar o sistema até sua maturidade e **não armazene arquivos sensíveis sem o devido backup.**
 
-A versão 1.0 será lançada quando todas as APIs do sistema forem consideradas estáveis.
+A versão 1.0 será lançada quando todas as APIs do sistema sejam consideradas estáveis.
 
 ## O que Redox significa?
 
@@ -50,27 +51,33 @@ A versão 1.0 será lançada quando todas as APIs do sistema forem consideradas
 
 Ele soa similar com Minix e Linux também.
 
+## O que é um microkernel?
+
+Um microkernel é um modelo para núcleo de sistema operacional com uma pequena quantidade de código executando no maior privilégio do processador, este modelo melhora a estabilidade e segurança, com um pequeno custo de desempenho.
+
+Você pode ler mais sobre isso na página [Microkernels](https://doc.redox-os.org/book/microkernels.html).
+
 ## Quais funções o Redox possui?
 
 ### Benefícios do Microkernel
 
 - **Modularidade real**
 
-Você pode modificar/trocar a maioria dos componentes do sistema sem reiniciar o sistema, similar a alguns módulos de kernel e [livepatching](https://en.wikipedia.org/wiki/Kpatch) porém mais seguro.
+Você pode modificar/trocar a maioria dos componentes do sistema sem reiniciar o sistema, similar a alguns módulos em kernels monolíticos e [livepatching](https://en.wikipedia.org/wiki/Kpatch) porém mais seguro.
 
 - **Isolamento de bugs**
 
-A maioria dos componentes do sistema executam no espaço do usuário em um sistema com microkernel, um bug em componentes do sistema fora do kernel não pode [quebrar o kernel](https://en.wikipedia.org/wiki/Kernel_panic).
+A maioria dos componentes do sistema executam no espaço do usuário em um microkernel, por causa disso certos tipos de bugs na maioria dos componentes do sistema não podem [quebrar ou danificar o sistema e kernel](https://en.wikipedia.org/wiki/Kernel_panic).
 
 - **Design de não-reinicialização**
 
-O kernel é pequeno e muda muito pouco (correção de bugs), portanto você não precisa reiniciar seu sistema com frequência para atualizar, já que a maioria dos serviços do sistema estão no espaço do usuário, eles podem ser trocados/atualizados durante a execução (reduzindo muito o tempo offline de servidores).
+Um microkernel maduro muda muito pouco (exceto por correções de bugs), portanto você não precisa reiniciar seu sistema com frequência para atualizar, pois a maioria dos serviços do sistema estão no espaço do usuário, eles podem ser reiniciados/atualizados durante a execução (reduzindo o tempo offline de servidores).
 
 - **Fácil de desenvolver e depurar**
 
 A maioria dos componentes do sistema estão no espaço do usuário, simplificando os testes e depuração.
 
-Se você quiser ler mais sobre os benefícios citados acima, leia [esta](https://doc.redox-os.org/book/ch04-01-microkernels.html) página.
+Se você quiser ler mais sobre os benefícios citados acima, leia a página [Microkernels](https://doc.redox-os.org/book/microkernels.html).
 
 ### Benefícios da Rust
 
@@ -80,25 +87,27 @@ A síntaxe restritiva e os requisitos do compilador para compilar o código redu
 
 - **Menos vulnerável a corrupção de dados**
 
-O compilador da Rust ajuda o programador a evitar erros de memória e condições de corrida, o que reduz a probabilidade dos bugs de corrupção de dados.
+O compilador da Rust ajuda o programador a evitar erros de memória e condições de corrida, o que reduz a probabilidade dos bugs de corrupção de dados devido a erros de implementação.
+
+- **Sem necessidade para mitigações de exploit das linguagens C e C++ em componentes do sistema**
 
-- **Sem necessidade para mitigações de exploit das linguagens C e C++**
+Como o Redox é escrito em Rust nós não precisamos das mitigações de exploit das linguagens C e C++ nos componentes do sistema, diminuindo a complexidade e aumentando a compatibilidade do sistema com programas.
 
-O design de um microkernel escrito em Rust protege contra as falhas de memória das linguagens C e C++, isolando o sistema do kernel a superfície de ataque é muito limitada.
+O design de um microkernel escrito em Rust protege contra as falhas de memória presentes em sistemas operacionais escritos em C e C++, ao isolar os componentes de sistema do kernel a superfície de ataque se torna muito limitada.
 
 - **Melhorias de segurança/confiabilidade sem impacto significante no desempenho**
 
-Como o kernel é pequeno, ele usa menos memória para fazer suas funções e o código limitado no kernel torna ele quase livre de bugs (objetivo do príncipio [KISS](https://en.wikipedia.org/wiki/KISS_principle)).
+Como o kernel é pequeno menos memória é utilizada para realizar suas funções, o código limitado no kernel torna ele quase livre de bugs (objetivo do príncipio [KISS](https://en.wikipedia.org/wiki/KISS_principle)).
 
-O design seguro e veloz da linguagem Rust, combinado com a pequena quantidade de código no kernel, ajudam a garantir um núcleo fácil, confiável e veloz de manter.
+O design seguro e veloz da linguagem Rust, combinado com a pequena quantidade de código no kernel, ajudam a garantir um núcleo de sistema fácil, confiável e veloz de manter.
 
 - **Segurança de Concorrência**
 
-O suporte para segurança de concorrência nas linguagens de programmação C/C++ é frágil e muito fácil de escrever um programa que parece seguro para executar em vários threads, mas introduz bugs útis e buracos de segurança.
+O suporte para segurança de concorrência nas linguagens de programmação C/C++ é frágil e muito fácil de escrever um programa que parece seguro para executar em vários threads, mas introduz bugs sútis e buracos de segurança.
 
-Se um thread acessa um pedaço do estado ao mesmo tempo que outro thread está modificando, o programa todo pode exibir bugs confusos e bizarros.
+Se um thread acessa uma parte do estado ao mesmo tempo que outro thread está modificando, o programa todo pode exibir bugs confusos e bizarros.
 
-Você pode ver [este](https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) exemplo de uma categoria séria de bugs de segurança que a segurança de concorrência corrige.
+Você pode ver [este exemplo na Wikipedia](https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use) de uma categoria séria de bugs de segurança que a segurança de concorrência corrige.
 
 Mas na Rust esse tipo de bug é fácil de evitar, o mesmo sistema de escrita que nos previne de escrever de forma insegura também nos previne de escrever padrões perigosos de acesso simultâneo.
 
@@ -118,8 +127,8 @@ Espere alto desempenho e segurança dos dados (copy-on-write, integridade de arq
 
 Você pode ver como o Redox é em comparação com o Linux, FreeBSD e Plan 9 nessas páginas:
 
-- [Funções do Redox OS](https://doc.redox-os.org/book/ch04-11-features.html)
-- [Comparando o Redox Com Outros Sistemas Operacionais](https://doc.redox-os.org/book/ch01-05-how-redox-compares.html)
+- [Funções do Redox OS](https://doc.redox-os.org/book/features.html)
+- [Comparando o Redox Com Outros Sistemas Operacionais](https://doc.redox-os.org/book/how-redox-compares.html)
 
 ## Qual o propósito do Redox?
 
@@ -127,7 +136,7 @@ O objetivo principal do Redox é ser um sistema de propósito geral com foco em
 
 O Redox pretende ser uma alternativa aos sistemas Unix (Linux/BSD) existentes também, podendo executar programas Unix com apenas compilação ou modificações mínimas.
 
-- [Nossos Objetivos](https://doc.redox-os.org/book/ch01-01-our-goals.html)
+- [Nossos Objetivos](https://doc.redox-os.org/book/our-goals.html)
 
 ## O que posso fazer com o Redox?
 
@@ -135,7 +144,7 @@ Como um sistema de propósito geral, você é capaz de realizar praticamente qua
 
 O Redox está em desenvolvimento, portanto nossa lista de aplicações suportada é limitada atualmente, mas crescente.
 
-- [Casos de Uso](https://doc.redox-os.org/book/ch01-04-redox-use-cases.html)
+- [Casos de Uso](https://doc.redox-os.org/book/redox-use-cases.html)
 
 ## O que é um sistema Unix-like?
 
@@ -143,8 +152,6 @@ Qualquer sistema compátivel com a [Especificação Única do Unix](https://en.w
 
 [Unix](https://pt.wikipedia.org/wiki/Unix) foi um sistema operacional de multitarefa muito influente e impactou as decisões de design em diversos sistemas modernos.
 
-- [Artigo da Wikipedia](https://pt.wikipedia.org/wiki/Sistema_operacional_tipo_Unix)
-
 ## Como o Redox foi influenciado por outros sistemas?
 
 ### [Plan 9](http://9p.io/plan9/index.html)
@@ -154,7 +161,7 @@ Este sistema da Bell Labs trouxe o conceito de "Tudo é um arquivo" ao seu maior
 Você apenas precisa montar o software em algum local para obter a função desejada, qualquer software pode funcionar dessa forma.
 
 - [Drew DeVault explicando o Plan 9](https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html)
-- [Como o Redox foi influenciado pelo Plan 9](https://doc.redox-os.org/book/ch05-00-urls-schemes-resources.html)
+- [Como o Redox foi influenciado pelo Plan 9](https://doc.redox-os.org/book/urls-schemes-resources.html)
 
 ### [Minix](https://minix3.org/)
 
@@ -162,7 +169,7 @@ O sistema Unix-like com microkernel mais influente, ele possuí funções avanç
 
 O Redox foi muito influenciado pelo Minix, ele tem funções e arquitetura similar escrita em Rust.
 
-- [Como o Redox foi influenciado pelo Minix](https://doc.redox-os.org/book/ch04-01-microkernels.html)
+- [Como o Redox foi influenciado pelo Minix](https://doc.redox-os.org/book/microkernels.html)
 
 ### [seL4](https://sel4.systems/)
 
@@ -184,12 +191,6 @@ O kernel monolítico mais avançado e o maior projeto de código-aberto do mundo
 
 O Redox tenta implementar as melhorias de desempenho do Linux em um design de microkernel.
 
-## O que é um microkernel?
-
-Um microkernel é um modelo para núcleo de sistema operacional com uma pequena quantidade de código executando no maior privilégio do processador, este modelo melhora a estabilidade e segurança, com um pequeno custo de desempenho.
-
-Você pode ler mais sobre [aqui](https://doc.redox-os.org/book/ch04-01-microkernels.html).
-
 ## Quais programas o Redox executa?
 
 O Redox é desenhado para ser compátivel-em-código com a maioria dos sistemas Unix, Linux e programas POSIX, necessitando apenas de compilação.
@@ -208,15 +209,15 @@ Softwares importantes que o Redox suporta:
 - GCC
 - LLVM
 
-Você pode ver todos os componentes do Redox e programas portados [aqui](https://static.redox-os.org/pkg/x86_64-unknown-redox/)
+Você pode ver todos os componentes do Redox e programas portados na [lista do servidor de compilação](https://static.redox-os.org/pkg/x86_64-unknown-redox/)
 
 ## Como instalar programs no Redox?
 
-O Redox tem um gerenciador de pacotes similar ao `apt` (Debian) e `pkg` (FreeBSD), você pode aprender a como utiliza-lo [aqui](https://doc.redox-os.org/book/ch02-08-pkg.html).
+O Redox tem um gerenciador de pacotes similar ao `apt` (Debian) e `pkg` (FreeBSD), você pode aprender a como utiliza-lo na página [Downloading packages with pkg](https://doc.redox-os.org/book/pkg.html).
 
 ## Quais são as variantes do Redox?
 
-O Redox possuí variantes para cada tarefa, leia sobre elas abaixo:
+O Redox possuí variantes para um grupo de tarefas, leia sobre elas abaixo:
 
 - `minimal` - A variante mais simples com um sistema básico sem suporte a Internet, destinada a dispositivos embarcados, computadores muito antigos e programadores.
 
@@ -248,8 +249,9 @@ Leia o [HARDWARE.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/HA
 
 - ACPI
 - PCI
+- USB
 
-(USB em breve)
+(Suporte para dispositivos USB com hubs em breve)
 
 ### Vídeo
 
@@ -307,20 +309,18 @@ Um [supervisor](https://en.wikipedia.org/wiki/Hypervisor) é um software que exe
 
 ## Como compilar o Redox?
 
-Atualmente o Redox tem um script de bootstrap para o Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE e FreeBSD com suporte não mantido para outras distribuições.
-
-Nós também oferecemos o Podman como método de compilação universal, esse é método de compilação recomendado para sistemas que não sejam baseados no Debian, pois ele evita problemas de ambiente durante a compilação.
+Leia as seguintes páginas:
 
-- [Guia no Livro do Redox](https://doc.redox-os.org/book/ch02-05-building-redox.html) - (Pop OS!, Ubuntu, Debian, Fedora, Arch Linux, openSUSE and FreeBSD)
-- [Guia do Podman no Livro do Redox](https://doc.redox-os.org/book/ch02-06-podman-build.html)
+- [Compilação Podman](https://doc.redox-os.org/book/podman-build.html)
+- [Compilação Nativa](https://doc.redox-os.org/book/building-redox.html)
 
 ## Como diagnosticar seu Redox em caso de erros
 
-Leia [essa](https://doc.redox-os.org/book/ch08-05-troubleshooting.html) página ou nos explique no [Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+Leia a página [Troubleshooting](https://doc.redox-os.org/book/troubleshooting.html) ou nos explique no [Chat](https://doc.redox-os.org/book/chat.html).
 
 ## Como reportar bugs para o Redox?
 
-Leia [essa](https://doc.redox-os.org/book/ch12-03-creating-proper-bug-reports.html) página e verifique as Issues no GitLab para ver se seu problema foi reportado por alguém.
+Leia a página [Creating Proper Bug Reports](https://doc.redox-os.org/book/creating-proper-bug-reports.html) e verifique as Issues no GitLab para ver se seu problema foi reportado por alguém.
 
 ## Como contribuir para o Redox?
 
@@ -330,4 +330,4 @@ Você pode contribuir para o Redox de diversas formas, veja elas em [CONTRIBUTIN
 
 - Leia a [Documentação](/docs/) para saber mais sobre partes internas do Redox.
 - Leia todo o [livro do Redox](https://doc.redox-os.org/book/) para ver se responde sua pergunta ou conserta seu problema.
-- Se a documentação e o livro não resolver, faça sua pergunta ou diga seu problema no [Chat](https://doc.redox-os.org/book/ch13-01-chat.html).
+- Se a documentação e o livro não resolver, faça sua pergunta ou diga seu problema no [Chat](https://doc.redox-os.org/book/chat.html).

content/home.en.md

@@ -18,20 +18,20 @@ url = "home"
 <div class="row features">
   <div class="col-md-6">
     <ul class="laundry-list" style="margin-bottom: 0px;">
-      <li>Inspired by <a href="http://9p.io/plan9/index.html">Plan 9</a>, <a href="http://www.minix3.org/">Minix</a>, <a href="https://sel4.systems/">seL4</a>, <a href="http://www.bsd.org/">BSD</a> and <a href="https://www.kernel.org/">Linux</a></li>
+      <li>Inspired by <a href="http://9p.io/plan9/index.html">Plan 9</a>, <a href="http://www.minix3.org/">Minix</a>, <a href="https://sel4.systems/">seL4</a>, <a href="https://en.wikipedia.org/wiki/Berkeley_Software_Distribution">BSD</a> and <a href="https://www.kernel.org/">Linux</a></li>
       <li>Implemented in <a href="https://www.rust-lang.org/">Rust</a></li>
-      <li><a href="https://doc.redox-os.org/book/ch04-01-microkernels.html">Microkernel</a> Design</li>
-      <li>Includes optional GUI - <a href="https://doc.redox-os.org/book/ch04-09-graphics-windowing.html#orbital">Orbital</a></li>
+      <li><a href="https://doc.redox-os.org/book/microkernels.html">Microkernel</a> Design</li>
+      <li>Includes optional GUI - <a href="https://doc.redox-os.org/book/graphics-windowing.html#orbital">Orbital</a></li>
       <li>Partial <a href="https://en.wikipedia.org/wiki/POSIX">POSIX</a> compatibility</li>
-      <li><a href="https://doc.redox-os.org/book/ch06-00-programs-libraries.html">Source compatibility</a> with Linux/BSD programs</li>
+      <li><a href="https://doc.redox-os.org/book/programs-libraries.html">Source compatibility</a> with Linux/BSD programs</li>
     </ul>
   </div>
   <div class="col-md-6">
     <ul class="laundry-list">
       <li><a href="https://en.wikipedia.org/wiki/MIT_License">MIT</a> Licensed</li>
       <li>Supports <a href="https://doc.rust-lang.org/std/">Rust Standard Library</a></li>
-      <li><a href="https://doc.redox-os.org/book/ch04-07-drivers.html">Drivers</a> run in Userspace</li>
-      <li>Includes common Unix/Linux <a href="https://doc.redox-os.org/book/ch06-04-system-tools.html">tools</a></li>
+      <li><a href="https://doc.redox-os.org/book/drivers.html">Drivers</a> run in Userspace</li>
+      <li>Includes common Unix/Linux <a href="https://doc.redox-os.org/book/system-tools.html">tools</a></li>
       <li>Custom <a href="https://en.wikipedia.org/wiki/C_standard_library">C library</a> written in Rust (<a href="https://gitlab.redox-os.org/redox-os/relibc/">relibc</a>)</li>
       <li>See <a href="/screens/">Redox in Action</a></li>
     </ul>

content/home.fr.md

@@ -23,17 +23,17 @@ url = "home"
     <ul class="laundry-list" style="margin-bottom: 0px;">
       <li>Inspiré de <a href="http://9p.io/plan9/index.html">Plan 9</a>, <a href="http://www.minix3.org/">Minix</a>, <a href="https://sel4.systems/">seL4</a>, <a href="http://www.bsd.org/">BSD</a> et <a href="https://www.kernel.org/">Linux</a></li>
       <li>Écrit en <a href="https://www.rust-lang.org/">Rust</a></li>
-      <li>Architecture en <a href="https://doc.redox-os.org/book/ch04-01-microkernels.html">Micro-Noyau</a></li>
-      <li>Interface graphique optionnelle incluse - <a href="https://doc.redox-os.org/book/ch04-09-graphics-windowing.html#orbital">Orbital</a></li>
+      <li>Architecture en <a href="https://doc.redox-os.org/book/microkernels.html">Micro-Noyau</a></li>
+      <li>Interface graphique optionnelle incluse - <a href="https://doc.redox-os.org/book/graphics-windowing.html#orbital">Orbital</a></li>
       <li>Compatible avec la <a href="https://doc.rust-lang.org/std/">bibliothèque standard de Rust</a></li>
     </ul>
   </div>
   <div class="col-md-6">
     <ul class="laundry-list">
       <li>Licence <a href="https://en.wikipedia.org/wiki/MIT_License">MIT</a></li>
-      <li>Les <a href="https://doc.redox-os.org/book/ch04-07-drivers.html">Pilotes</a> s'exécutent en mode utilisateur</li>
-      <li>Les <a href="https://doc.redox-os.org/book/ch06-04-system-tools.html">Outils</a> courants d'Unix sont disponibles</li>
-      <li><a href="https://doc.redox-os.org/book/ch06-00-programs-libraries.html">Compatibilité avec le code source</a> de programmes Linux/BSD</li>
+      <li>Les <a href="https://doc.redox-os.org/book/drivers.html">Pilotes</a> s'exécutent en mode utilisateur</li>
+      <li>Les <a href="https://doc.redox-os.org/book/system-tools.html">Outils</a> courants d'Unix sont disponibles</li>
+      <li><a href="https://doc.redox-os.org/book/programs-libraries.html">Compatibilité avec le code source</a> de programmes Linux/BSD</li>
       <li>Compatibilité partielle avec <a href="https://en.wikipedia.org/wiki/POSIX">POSIX</a></li>
       <li>Une implémentation de la <a href="https://en.wikipedia.org/wiki/C_standard_library">bibliothèque C</a> écrit en Rust (<a href="https://gitlab.redox-os.org/redox-os/relibc/">relibc</a>)</li>
       <li>Voir <a href="/fr/screens/">Redox en fonctionnement</a></li>

content/home.pt.md

@@ -18,19 +18,19 @@ url = "home"
 <div class="row features">
   <div class="col-md-6">
     <ul class="laundry-list" style="margin-bottom: 0px;">
-      <li>Inspirado pelo <a href="http://9p.io/plan9/index.html">Plan 9</a>, <a href="http://www.minix3.org/">Minix</a>, <a href="https://sel4.systems/">seL4</a>, <a href="http://www.bsd.org/">BSD</a> e <a href="https://www.kernel.org/">Linux</a></li>
+      <li>Inspirado pelo <a href="http://9p.io/plan9/index.html">Plan 9</a>, <a href="http://www.minix3.org/">Minix</a>, <a href="https://sel4.systems/">seL4</a>, <a href="https://en.wikipedia.org/wiki/Berkeley_Software_Distribution">BSD</a> e <a href="https://www.kernel.org/">Linux</a></li>
       <li>Implementado em <a href="https://www.rust-lang.org/">Rust</a></li>
-      <li>Design de <a href="https://doc.redox-os.org/book/ch04-01-microkernels.html">Microkernel</a></li>
-      <li>Inclui uma GUI opcional - <a href="https://doc.redox-os.org/book/ch04-09-graphics-windowing.html#orbital">Orbital</a></li>
+      <li>Design de <a href="https://doc.redox-os.org/book/microkernels.html">Microkernel</a></li>
+      <li>Inclui uma GUI opcional - <a href="https://doc.redox-os.org/book/graphics-windowing.html#orbital">Orbital</a></li>
       <li>Suporta a <a href="https://doc.rust-lang.org/std/">biblioteca padrão da Rust</a></li>
     </ul>
   </div>
   <div class="col-md-6">
     <ul class="laundry-list">
       <li>Licença <a href="https://en.wikipedia.org/wiki/MIT_License">MIT</a></li>
-      <li>Os <a href="https://doc.redox-os.org/book/ch04-07-drivers.html">Drivers</a> são executados no espaço do usuário</li>
-      <li>Inclui as <a href="https://doc.redox-os.org/book/ch06-04-system-tools.html">ferramentas</a> Unix/Linux mais comuns</li>
-      <li><a href="https://doc.redox-os.org/book/ch06-00-programs-libraries.html">Compatibilidade de código-fonte</a> com programas do Linux/BSD</li>
+      <li>Os <a href="https://doc.redox-os.org/book/drivers.html">Drivers</a> são executados no espaço do usuário</li>
+      <li>Inclui as <a href="https://doc.redox-os.org/book/system-tools.html">ferramentas</a> Unix/Linux mais comuns</li>
+      <li><a href="https://doc.redox-os.org/book/programs-libraries.html">Compatibilidade de código-fonte</a> com programas do Linux/BSD</li>
       <li>Compatibilidade parcial com a <a href="https://en.wikipedia.org/wiki/POSIX">POSIX</a></li>
       <li><a href="https://en.wikipedia.org/wiki/C_standard_library">Biblioteca C</a> customizada e escrita em Rust (<a href="https://gitlab.redox-os.org/redox-os/relibc/">relibc</a>)</li>
       <li>Veja <a href="/pt/screens/">Redox em Ação</a></li>

content/news/01_rsoc2024_dynamic_linker.md

++++
+title = "RSoC 2024: Progress Report - Dynamic Linker"
+author = "Andy-Python-Programmer"
+date = "2024-12-17"
++++
+
+Hello everyone! I am Anhad Singh and I am currently working on Redox’s dynamic
+linker and porting programs to be dynamically linked as a part of my RsoC
+project.
+
+*At the time of writing this post, all upstream recipes currently are statically
+compiled and patches are being gradually rolled out.*
+
+Basically, dynamic linking allows a program to use external symbols, such as
+those in shared libraries like libc, without actually including them in the
+program's executable. When the program is executed, the dynamic linker resolves
+these symbols and loads the necessary libraries into memory. 
+
+In contrast, statically linked programs resolve all symbols during compilation
+and include them directly in the final executable. While static linking ensures
+self-contained executables, dynamic linked programs are usually more space and
+memory efficient.
+
+# So, what was wrong?
+
+Initially the dynamically linked programs were faulting at the following
+instruction inside `ld64.so.1`: 
+
+`mov rax, fs:[0x10]`
+
+This was inside `Tcb::current()` which is used to retrieve the TP (Thread
+Pointer) which should be pointing to the TCB (Thread Control Block). With the
+help of GDB, I found that TP was uninitialized.
+
+This is a problem on Redox, as we need the TCB to be setup in order to do
+pretty much anything. For example, the signal handling code is in userspace and
+we have to keep track of thread-specfic signal state. This is stored in the
+TCB. However, the TCB was being set up only for the executable and not for the
+dynamic linker. Resolving this was the first step for getting the dynamic
+linker working again.
+
+Next, the dynamic linker also shares code with relibc, which is generally
+beneficial. However, many of the relibc functions rely on thread locals like
+`errno`, which is a problem as TLS (Thread Local Storage) in the dynamic linker
+is not available. These changes were able to get some of the dynamically linked
+programs to run.
+       
+Finally, after fixing and making sure that static TLS for libraries was
+correctly sized and that libraries loaded via dlopen(3) also had proper TLS
+support. These fixes, along with others (see
+<https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/570> and
+<https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/577> for all of
+them), I was able to get the dynamic linker functional again!
+
+# Where are we at now?
+The dynamic linker is now in a functional state, though certain features are
+still incomplete. For instance, lazy binding (`RTLD_LAZY`) currently behaves
+the same as `RTLD_NOW` (PR for the fix should be out soon). Additionally, stuff
+like symbol scopes (`RTLD_GLOBAL`/`RTLD_LOCAL`) are still unimplemented.
+
+My current focus is on implementing these missing features and porting existing
+applications to be dynamic linked; prioritizing programs that use libraries
+widely shared among multiple other programs.
+
+Despite these limitations, we can successfully run dynamically compiled GCC and
+execute programs compiled with it on Redox (note that patches for this are
+being gradually rolled out). Dynamically linked programs like Bash also work as
+expected.
+

content/news/02_rsoc2024_dynamic_linker.md

++++
+title = "RSoC 2024: Dynamic Linking - Part 2"
+author = "Anhad Singh"
+date = "2025-02-06"
++++
+
+I am sure you would have wondered what exactly happens when you execute a program like grep or COSMIC Terminal. How exactly does the system load and execute that program?
+How does Redox differ from Linux in how programs are loaded?
+For my Redox Summer of Code project, my task was to fix and improve the Redox's dynamic linker, add dynamic linking support to the Redox's build system and port several packages to be dynamically linked!
+
+When a command is run, the current process image gets replaced by that of the new program via the `exec()` family of functions. `exec()` functions such as `execl`, `execlp`, `execle`, `execv`, `execvp`, and `execvpe` are built on top of the `execve(2)` system call on Linux, whereas on Redox the it is handled within the libc in userspace.
+
+Let’s see this in action on Linux using `strace`, which lets us peek into the system calls being made:
+
+```bash
+$ strace -e execve /usr/bin/echo arg1 arg2
+execve("/usr/bin/echo", ["/usr/bin/echo", "arg1", "arg2"], 0x7ffccfbfef80 /* 50 vars */) = 0
+arg1 arg2
++++ exited with 0 +++
+```
+
+In this output, we can observe that the `execve` syscall is called with three arguments: the path to the program (`/usr/bin/echo`), the argument list (`["/usr/bin/echo", "arg1", "arg2"]`), and the environment variables.
+
+This function never returns because the new program takes over, and the original process no longer exists in memory. In Linux, the loading of the program happens in the kernel, while on Redox, as a microkernel OS, it is performed within the libc in userspace. Despite this, both set up the memory address space and jump to the entry point (the main function) in similar fashion.
+
+## How does the program loader work?
+To grasp how exec operates and how a program is loaded, it's important to understand the basic layout of an executable file. Both Redox and Linux use the **Executable and Linkable Format** (ELF) for executables and linkables.
+
+<center>
+    <img class="img-responsive" src="/img/rsoc-2024-dynamic-linking/elf_layout.png" width="50%" height="50%">
+    Figure 1: ELF File Layout. <a href="https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#/media/File:Elf-layout--en.svg">Source</a>
+</center>
+
+An ELF file starts with an ELF header containing essential details like the entry point, target machine, and version. Immediately following is the program header table, which lists segments that instruct the loader on how to load the executable. Before parsing these segments, the loader first creates a new memory address space for the process. One of the key segments for the loader is of the type `PT_LOAD`, which tells the loader to:
+* Allocate memory in the new memory address space for that segment based on its specified size.
+* Copy data from the executable file into memory, up to that segment's file size.
+* If that segment's memory size is larger than its file size, zero-fill it's memory that is beyond it's file size.
+
+After the ELF file has been loaded into memory, the loader switches to the newly allocated address space, dropping the old one. Execution then jumps to the program's entry point, which was specified in the ELF's header.
+
+## But wait, what happens if the program is dynamically linked?
+
+At build-time, the developer chooses whether to use static or dynamic linking.
+Statically linked programs include all the needed code from libraries (for example, `libc.a`) directly into the executable file,
+but dynamically linked programs use shared libraries (for example, `libc.so`) so that each executable does not need a copy of the library code.
+The steps described earlier applied to statically linked programs.
+
+As dynamic linked programs can make use of external symbols, such as those in shared libraries without actually including them in the program’s executable, additional work is required to resolve these symbols and load the necessary libraries into memory. 
+
+When a dynamically linked program is executed, it relies on a dynamic linker (also known as the interpreter) to resolve these symbols and load the necessary libraries into memory. The `exec()` ELF loader loads both the program and its dynamic linker. 
+
+As mentioned earlier, ELF files use segments to guide the loader on how to load the file. In addition to `PT_LOAD`, another crucial segment is `PT_INTERP`, which specifies the path of the dynamic linker. For example, on Redox you can check the dynamic linker path for GNU Bash (assuming not statically linked) with:
+
+```bash
+$ patchelf --print-interpreter /bin/bash
+/lib/ld64.so.1
+```
+
+The interpreter is loaded just like the program and after it has been loaded, the `exec()` ELF loader jumps to its entry point (as defined in https://gitlab.redox-os.org/redox-os/relibc/-/blob/7edc231f313714bd44c3967d30d56ffb44b33fb1/ld_so/src/lib.rs) rather than the program's entry point.
+
+## What happens in the dynamic linker?
+
+After jumping to the dynamic linker’s entry point, the linker resolves the main program and its dependencies in a breadth-first order, loading them in three main steps for each dynamic shared object (DSO):
+* Loading the ELF: The DSO is read and loaded into memory similar to the `exec()` loader. Note that only one copy of the DSO file is loaded, and it is shared among all processes that depend on it. On the other hand, statically linked programs embed libraries, which can result in multiple unshared instances of the DSO file; making it less memory and storage efficient.
+* Applying Relocations [^1]
+* Running init functions
+
+Once everything is resolved, the dynamic linker jumps to the program's entry point (as specified inside the ELF header), just like the `exec()` loader!
+
+Note that the interpreter remains in the memory address space *even after the program starts running*. This allows the program to instruct the dynamic linker to load additional shared libraries when needed, enabling features such as plugins/extensions and hot swapping of components.
+
+<hr>
+<center>
+    <img class="img-responsive" src="/img/rsoc-2024-dynamic-linking/flowchart.png">
+    Figure 2: Summary of the ELF loading process
+</center>
+
+## My work on the dynamic linker
+
+Interestingly, Redox already had a dynamic linker (ld.so), written in mostly Rust, but it was broken and also lacked a lot of features. In addition, dynamic linking was also missing proper toolchain and build system support. With Redox's libc supporting both Linux and Redox, the linker used to segfault before even finding the necessary dependencies to load on both platforms.
+
+Initially, it was challenging to hunt down the early segfaults. One factor was that relibc and the dynamic linker share codebases, and with the dynamic linker being a stale project, the code for it seemed incongruous from the rest of relibc. However, as the dynamic linker matured and I became more familiar with the codebase, debugging became smoother. I’ve explained the initial bug here: [RSoC 2024: Progress Report - Dynamic Linker](./01_rsoc2024_dynamic_linker.md).
+
+After the dynamic linker was in a functional state, I was able to add support for lazy binding! Essentially, this means that symbol resolution isn’t performed when the DSO loads but only when the symbol is first used. Since the relocation and symbol resolution processes are quite expensive, this change defers the cost to resolve the function to when/if it is called. Furthermore, I also added support for symbol scopes (`RTLD_LOCAL`/`RTLD_LOCAL`), paving the way for more programs to be dynamically linked as our dynamic linker matures :)
+
+Other improvements include significant performance gains (~tenfold) by optimizing how DSOs are read, parsed, and stored in memory, along with using GNU and Unix System V hash tables for faster symbol lookups. Additionally, features like `DT_RELR` and various other enhancements and features were added!
+
+You can find the source code for the dynamic linker at: https://gitlab.redox-os.org/redox-os/relibc/-/tree/master/ld_so?ref_type=heads
+
+## Making packages dynamically linked
+
+I successfully dynamically linked numerous packages for Redox, including GNU Make, LLVM, GCC, GNU Binutils, cURL, GNU Bash, COSMIC Terminal, and many more!
+
+If you want to make a dynamically linked package, check out the following section:
+
+- https://doc.redox-os.org/book/porting-applications.html#dynamically-linked-programs
+
+While porting these packages, I had to configure different build systems (e.g. GNU Autotools, CMake, Meson, ...) to recognize that Redox supports dynamic linking. One of the key build tools involved was GNU/libtool, which had to be ported to Redox. [libtool](https://www.gnu.org/software/libtool/) is a script that abstracts away platform-specific complexities of shared library creation.
+
+Previously, our C and C++ toolchains did not support dynamic linking for our targets. I also added the necessary support to enable it :)
+
+## Future work
+More packages need to be ported. The dynamic linker is now at a stage where it should be able to run any standard package - we just need to port them. However, we currently cannot upstream a package recipe unless all its dependents support dynamic linking; otherwise, it would break those packages. Compiling both static and dynamic versions isn’t a viable solution either, as it would significantly increase package size.
+
+<hr>
+Working on this project was an incredible experience - I gained insight on the dynamic linking process, navigated various build systems, and honed my debugging skills. You can check out my work by running any of the dynamically linked packages on the latest Redox image!
+
+<center>
+    <img class="img-responsive" src="/img/rsoc-2024-dynamic-linking/cosmic_files_dynamically_linked.png">
+    Figure 3: Dynamically linked Cosmic Files and Ion running on Redox!
+</center>
+
+## Resources
+If you're interested in learning more about the dynamic linking process, here are some incredible resources:
+
+1. Drepper, U 2005, ELF Handling For Thread-Local Storage, Version 0.20, Red Hat Inc, <https://www.uclibc.org/docs/tls.pdf>
+2. Drepper, U 2011, How To Write Shared Libraries, <https://www.akkadia.org/drepper/dsohowto.pdf>.
+3. Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2 1995, <https://refspecs.linuxfoundation.org/elf/elf.pdf>
+
+[^1]: https://wiki.osdev.org/ELF_Tutorial#Relocation%20Sections
+

content/news/POSIX-conformance-testing.md

++++
+title = "POSIX Conformance Testing for the Redox Signals Project"
+author = "Ron Williams"
+date = "2024-12-11"
++++
+
+The Redox team has received a grant from [NLnet](https://nlnet.nl/)
+to develop [Redox OS Unix-style Signals](https://nlnet.nl/project/RedoxOS-Signals/),
+moving the bulk of signal management to userspace,
+and making signals more consistent with the POSIX concepts
+of signaling for processes and threads.
+It also includes Process Lifecycle and Process Management aspects.
+As a part of that project,
+we are developing tests to verify that the new functionality
+is in reasonable compliance with the POSIX.1-2024 standard.
+
+This report describes the state of POSIX conformance testing,
+specifically in the context of Signals.
+This is based on my experience only, your mileage may vary.
+If you want to offer any suggestions or corrections,
+please join us on [Matrix Chat](https://matrix.to/#/#redox-join:matrix.org).
+
+## The Highlights
+
+- For Signals, POSIX.1-2024 has eliminated some interfaces and constants that were previously deprecated
+but has not added much that is new.
+See [Sortix's POSIX blog post](https://sortix.org/blog/posix-2024/) for a broader analysis.
+- The only true POSIX conformance tests are the ones provided by
+[The Open Group](https://posix.opengroup.org/docs/testsuites.html),
+but they don't have generally available tests for POSIX.1-2024 yet,
+and the new tests will likely require a fee for any long-term use.
+- [Sortix](https://sortix.org/os-test/) has tests that check for compliance
+with the 2024 standard for specific areas of functionality,
+and has recently added tests covering Signals.
+- The tests that Redox developed under our NLnet grant have similar coverage
+to the new Signals tests from Sortix,
+but due to unfortunate timing, we did not collaborate.
+- Better support for cross-compilation, separate from test execution,
+is an important requirement that is
+not very well addressed by existing conformance tests.
+
+## About NLnet and NGI Zero Core
+
+The [NLnet Foundation](https://nlnet.nl/) is a great organization to work with.
+They fund internet-related projects of various kinds,
+and they have [several funds](https://nlnet.nl/themes/) running concurrently,
+each with a different scope and set of goals.
+
+The Redox Signals project is funded under [NGI Zero Core](https://nlnet.nl/core/),
+which is no longer accepting applications,
+but [NGI Zero Commons](https://nlnet.nl/commonsfund/) is open for applications,
+and it has a broader scope and more total funds available than Zero Core.
+If your open source project has a "European dimension",
+and fits within the scope of one of their funds, consider applying.
+
+## Project Overview
+
+For the Redox Signals project, we are re-working our implementation of
+[Signals](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/signal.h.html),
+used by [`kill()`](https://pubs.opengroup.org/onlinepubs/9799919799/functions/kill.html)
+among other things, to more closely align with Unix behavior.
+We are also reducing the kernel footprint for supporting Signals,
+moving such things as stack manipulation into userspace.
+Some of the objectives for the project include:
+- Move signal handling (sigprocmask and sigaction) to userspace,
+with basic ability to catch, ignore,
+suspend, restart or terminate processes
+- Implement signal queuing (real-time-style signals), initially in the kernel,
+and implement all remaining signal-related POSIX APIs
+- Move process tracking into a userspace daemon,
+with session/group/process/thread hierarchy awareness
+- Implement support for kill, sigqueue, and waitpid syscalls with process/group/all processes targets
+in the Process Manager
+- Pass a suite of process and signal compliance tests
+
+Redox, and the work for this project in particular, is MIT-licensed.
+(Some elements such as the COSMIC Desktop applications are under other licenses.)
+
+## All About POSIX Testing
+
+### POSIX.1-2024
+
+The [POSIX](https://en.wikipedia.org/wiki/POSIX) standard, also referred to as IEEE std 1003.1,
+describes many aspects of a Unix system,
+including APIs, commands and shell behavior, and so on,
+to try to improve software portability.
+It does not describe "system calls" or other things that might determine a particular implementation.
+The POSIX standard has existed since 1988, and has evolved, with half a dozen or so versions,
+with (more recently) each new version including
+a suffix for the year the standard was approved.
+The most recent version is POSIX.1-2024.
+The standard is broken into sections,
+and systems may be compliant with one section of the standard but might not implement another section.
+
+The standard is maintained by the [Austin Group](https://www.opengroup.org/austin/),
+and is administered jointly by [The Open Group](https://www.opengroup.org/)
+and the [IEEE](https://www.ieee.org/).
+The Open Group is responsible for certification of POSIX systems.
+
+POSIX.1-2024 was released in June of this year.
+In general, as the standard evolves, some APIs, structs and constant definitions
+are first deprecated in one release of the standard,
+and then eventually removed in a subsequent release.
+POSIX.1-2024 has added new functionality in some areas,
+and made some extensions mandatory,
+but most of the changes to Signals have been deletion of obsolete and previously deprecated items.
+
+### The Open Group Tests
+
+The Open Group is the definitive source for POSIX conformance testing.
+If you want to obtain POSIX certification, you must pass the tests provided by The Open Group.
+
+The Open Group charges a fee for certification,
+and the tests are provided as part of that certification process.
+What fees apply and when is a bit confusing, but it is in the small number of thousands of dollars
+to get access to the tests, possibly with a 12 month no-fee period for open source projects.
+
+There are several older test suites that are available for download without a fee.
+These are mostly related to the POSIX.1-2003 standard,
+plus a variety of other Unix standards.
+The Open Group tests use a test framework called
+[VSXgen](http://www.opengroup.org/testing/testsuites/VSXgen.htm),
+based on the [Test Environment Toolkit](https://tetworks.opengroup.org/) (TET).
+
+For these older test suites, the pages are in some cases unmaintained,
+and links are frequently broken.
+Assembling all the necessary bits and pieces required a fair bit of googling
+and mixing and matching.
+After about two days of work,
+I had very little confidence that I had an actual usable conformance test suite.
+And as it wasn't an up to date set of tests, I decided to stop trying.
+
+However, my biggest concern, by far, was that for Redox's purposes,
+the ability to build the tests on one machine and run the tests on another
+is a critical requirement for us right now.
+VSXgen has a complex configuration and management system,
+and we are not quite up to using VSXgen on Redox,
+or compiling the many tests natively.
+
+### Linux Standard Base Tests
+
+The [Linux Standard Base](https://wiki.linuxfoundation.org/lsb/start) (LSB) 
+is an attempt to create a binary compatibility standard for Linux systems,
+while POSIX is explicitly not a binary compatibility standard.
+LSB is not POSIX - there are some significant divergences from POSIX.
+
+LSB has a set of conformance tests,
+derived from the same origin as The Open Group's POSIX tests,
+with changes to align with the LSB definition.
+The LSB Tests are not maintained, as far as I know,
+and were again not to the POSIX.1-2024 standard.
+I attempted to run the LSB tests on Pop!_OS,
+but after struggling with configuration for a day or so,
+I decided to stop.
+It's quite possible that I would have been more successful had I found
+some good documentation about configuration, but I did not.
+Since the LSB tests use the same basic VSXgen/TET framework for building and running the tests,
+my concerns about support for cross-compilation, separate from running the tests,
+apply here as well.
+
+There is some commentary about LSB, and questions about its future,
+which you can read on the
+[LSB Wikipedia Page](https://en.wikipedia.org/wiki/Linux_Standard_Base#Quality_of_compliance_test_suites).
+
+### Open POSIX Test Suite
+
+The [Open POSIX Test Suite](https://posixtest.sourceforge.net/) was an effort
+to create a set of POSIX tests that was available without fees.
+It is licensed under GPL-2.
+
+Based on the copyright notices in the files,
+it appears that Intel and Qualcomm both contributed to the effort.
+It was maintained until 2005 or 2006, and tested for conformance to the POSIX.1-2001 standard.
+It includes a decent set of tests, and test management appears to be much less complex
+than the above test suites.
+The [Emscripten team](https://github.com/emscripten-core/posixtestsuite)
+has done some work to test with this set of tests.
+
+However, as the Open POSIX Test Suite is GPL-2, and Redox wants to provide MIT-licensed tests,
+we are not able to modify their tests for inclusion directly in our work.
+
+Going forward, we will attempt to leverage their tests as a separable component.
+We will create a fork and disable those tests that are not supported in POSIX.1-2024.
+We may do some work to update to POSIX.1-2024 in areas of interest to us,
+but we are not in a position to commit to a specific amount of work on updating the tests.
+The outcome of any changes to the suite will of course be GPL-2 licensed.
+I am also not certain if we will be able to upstream the changes,
+as I do not know if the work is being maintained or if it has a designated owner.
+
+There are a variety of test types in the Open POSIX Test Suite;
+it is not limited to just poking the API.
+Quoting from their overview:
+
+> The test suite divides tests into several categories: Conformance, Functional, Stress, Performance, and Speculative.
+>- Conformance tests involve closely reading the POSIX spec and recording assertions about correct behavior. Each test case is associated with a particular assertion.
+>- Functional tests try to use the interfaces in real-world scenarios, and cover behavior that is reasonably expected, if not specifically called out, in the POSIX spec.
+>- Stress tests put the interfaces through the paces by using large numbers of system objects, or large amounts of data, or under external conditions such as low memory or high CPU utilization.
+>- Performance tests attempt to benchmark the performance of interfaces or sets of interfaces for comparison of implementations.
+>- Speculative tests arise when the POSIX spec is unclear about a certain behavior where differences in implementations can affect the application. These tests attempt to expose differences in implementations so that they can be tracked and the behaviors can be compared for consistency across revisions.
+
+### libc-test from musl
+
+[musl](https://musl.libc.org/) is a very popular "from scratch" implementation of the C standard library,
+[libc](https://en.wikipedia.org/wiki/C_standard_library).
+It uses a permissive MIT license.
+
+Quoting from their website,
+> **musl** is *lightweight, fast, simple, free,* and strives to be *correct* in the sense of standards-conformance and safety.
+
+libc, like Unix, is governed by standards.
+There is an ISO standard for libc, and a POSIX standard for libc, and they are not the same.
+musl conforms to a combination of the ISO and the POSIX standards,
+and adds some common extensions.
+
+musl has a set of tests called [libc-test](https://wiki.musl-libc.org/libc-test).
+These tests are also MIT licensed.
+The tests cover definitions, functionality, and some regression tests.
+They are primarily a test of the library,
+and have only limited testing of runtime services
+(on Linux, these would be system calls).
+They use custom macros to reduce boilerplate code,
+but it makes the tests less obvious to someone unfamiliar with the macros.
+
+libc-test has not been updated for POSIX.1-2024 yet.
+At some point, musl will need to work with POSIX.1-2024,
+and I expect that the tests will be updated.
+I hope that they can benefit from some of the work on runtime service testing described below,
+which has compatible licensing and coverage of areas not already covered by libc-test.
+
+### os-test from Sortix
+
+[Sortix](https://sortix.org/) is a from-scratch implementation of a POSIX operating system.
+The principal developer is Jonas 'Sortie' Termansen.
+As part of the effort,
+Jonas has developed a collection of POSIX.1-2024 conformance tests called
+[os-test](https://sortix.org/os-test/),
+with coverage for `io`, `malloc`, `signal` and `udp`.
+`os-test` uses the permissive ISC license,
+which is compatible with the MIT license.
+
+The tests are nice and straightforward, with no fancy configuration or macros,
+and the tests can be run from the Makefile.
+There is support for cross-compiling separately from executing the tests,
+but we found it a bit easier to write our own test execution script.
+It was simple and painless.
+
+Interestingly, Jonas has arranged for executing his POSIX test suite
+across numerous operating systems, and provides a comparison matrix
+for how each OS performs on each test.
+He even spends time interpreting the POSIX specification,
+looking for places where the spec might be imprecise or misleading,
+and writing tests to determine how each OS interprets the spec.
+
+The tests for `signal` were added on November 13 this year,
+so the Redox team had already completed
+the bulk of coding our tests when that work became available.
+I have been in touch with Jonas, and we're hoping that we can collaborate in future.
+
+### What Redox is doing
+
+Redox has its own implementation of `libc`, called `relibc`.
+Relibc is written primarily in Rust,
+and has a Linux implementation and a Redox implementation.
+For the Redox implementation, a lot of Redox's runtime services,
+including fork, exec and signal handling,
+are either fully or partly implemented within Relibc,
+"under the hood".
+So what on Linux would be a function call that leads directly to a system call,
+on Redox might have a whole (or partial) implementation behind the scenes,
+manipulating Redox-specific resources.
+
+We have developed our own test suite for Relibc,
+which is integrated into the Relibc build system.
+The Signal tests that are being developed for this project
+are part of that test suite.
+
+The Signal tests follow the patterns used in the other Relibc tests,
+and use some macros to reduce boilerplate and provide some context to errors.
+The macros are defined in our
+[test_helpers.h](https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/tests/test_helpers.h?ref_type=heads).
+The tests can be built on a development machine, normally Linux, 
+and then run on Redox in an emulator or natively.
+
+The new Signals tests are more detailed than the tests that I have seen in other suites,
+checking each possible signal in a variety of conditions.
+
+## Summary
+
+The Open Group's for-a-fee test suite has not yet been updated for POSIX.1-2024.
+It has a complex configuration and test management system.
+
+The Open POSIX Test Suite was a sincere and useful attempt to create
+freely available GPL-2 licensed tests for POSIX conformance.
+However, it does not appear to have been maintained since 2006.
+
+Sortix has up-to-date tests for POSIX.1-2024, but only in specific areas.
+Their Signals tests overlap with our work,
+but were not available in time for us to leverage them.
+
+As a result, we have developed our own tests to confirm POSIX.1-2024 conformance,
+using the same style and macros as the rest of the tests in our Relibc test suite.
+
+## Opinion
+
+I include here my own thoughts, which do not necessarily reflect the opinions
+of the Redox team, NLnet, or NGI.
+
+I am extremely disappointed that The Open Group does not provide an open source,
+free-to-use set of up to date tests.
+I think this is a major error on their part, and the fact that there was
+a concerted effort by organizations such as Intel and Qualcomm
+to develop an alternative test suite indicates that this is a serious problem.
+I appeal to The Open Group to make the POSIX.1-2024 tests free-to-use,
+open source, and open to community contributions.
+
+Many, many years ago, my first full-time job after graduating from university
+was porting Unix to new processors and systems.
+Back then, the term
+["Test Driven Development"](https://en.wikipedia.org/wiki/Test-driven_development)
+did not exist, but that's exactly how we did our work -
+build the system incrementally, focusing on one conformance test at a time,
+then clean up the code as you pass each test.
+When you can pass all the tests, you are done.
+We had a complete set of official Unix conformance tests,
+and in fact the contract for the work was written with milestones based on
+passing the tests.
+
+When you use a Test Driven approach, the set of tests you work from
+has a significant impact on your software design.
+If your tests are a good reflection of how the system will actually be used,
+the system's design should support the required functionality well.
+But if the tests do not accurately reflect the requirements,
+it's not certain if the system will do its job.
+Getting the system to correctly execute a new set of conformance tests
+at the end of the process can cause significant and expensive rework,
+and potentially create code filled with bandaid fixes specifically to pass
+"afterthought" test cases.
+
+I have no issue at all with The Open Group charging for POSIX certification.
+But having paywalled tests with a twelve month clock for open source projects
+that want to be POSIX compliant is harmful to both the open source projects
+and to the POSIX standard itself.
+
+With the growth of new processors and systems,
+like RISC-V and ARM servers for cloud-based AI,
+new wearables, hand-helds and IoT devices,
+and new OSes written in modern languages,
+the need for test-driven OS development is again reaching a peak.
+Making the tests freely available, and allowing community contributions,
+would get us a test suite that is up to date much sooner,
+and would encourage the kind of Test Driven Development that
+will help produce more correct, more POSIX conformant,
+and more maintainable operating systems.

content/news/documentation-improvements.md

@@ -26,7 +26,7 @@ I wrote the FAQ in a way that even Unix/Linux newcomers can understand, it's sim
 
 ## Book improvements
 
-(The book cover the high-level documentation and not the code APIs, read [this](https://doc.redox-os.org/book/ch11-02-writing-docs-correctly.html) page to understand)
+(The book cover the high-level documentation and not the code APIs, read [this](https://doc.redox-os.org/book/writing-docs-correctly.html) page to understand)
 
 Some parts of the book were outdated for years because the developers were busy with the code, Ron Williams improved it since the end of 2022 and I continued where he left.
 
@@ -60,29 +60,29 @@ A non-exaustive list of my improvements:
     More simple, less typos.
 
 - Several fixes on Markdown code formatting
-- [The build system was completely documented](https://doc.redox-os.org/book/ch08-06-build-system-reference.html)
-- [The package manager was documented](https://doc.redox-os.org/book/ch02-08-pkg.html)
-- [The Cookbook recipe system was completely documented](https://doc.redox-os.org/book/ch09-03-porting-applications.html)
-- [All Cookbook templates documented](https://doc.redox-os.org/book/ch09-03-porting-applications.html#templates)
-- [Most Cookbook custom template scripts documented](https://doc.redox-os.org/book/ch09-03-porting-applications.html#custom-template) - more will come.
+- [The build system was completely documented](https://doc.redox-os.org/book/build-system-reference.html)
+- [The package manager was documented](https://doc.redox-os.org/book/pkg.html)
+- [The Cookbook recipe system was completely documented](https://doc.redox-os.org/book/porting-applications.html)
+- [All Cookbook templates documented](https://doc.redox-os.org/book/porting-applications.html#templates)
+- [Most Cookbook custom template scripts documented](https://doc.redox-os.org/book/porting-applications.html#custom-template) - more will come.
 - More troubleshooting options
 - Added a way to update the toolchain
 - Software porting process was documented
 - Manual configuration of Podman was documented
-- [RedoxFS was documented](https://doc.redox-os.org/book/ch04-08-redoxfs.html)
-- [The microkernels explanation was improved a lot](https://doc.redox-os.org/book/ch04-01-microkernels.html)
-- [A high-level explanation of the kernel was created](https://doc.redox-os.org/book/ch04-02-kernel.html)
-- [A high-level explanation of the userspace was created](https://doc.redox-os.org/book/ch04-06-user-space.html)
-- [A high-level explanation of the Redox graphics/windowing system was created](https://doc.redox-os.org/book/ch04-09-graphics-windowing.html)
-- [A high-level explanation of the Redox security](https://doc.redox-os.org/book/ch04-10-security.html)
-- [More side projects were documented](https://doc.redox-os.org/book/ch01-07-side-projects.html)
-- [All crates were documented](https://doc.redox-os.org/book/ch08-06-build-system-reference.html#crates)
-- [More configuration options were documented](https://doc.redox-os.org/book/ch02-07-configuration-settings.html)
-- [Coding and building workflow documentation was improved a lot](https://doc.redox-os.org/book/ch09-02-coding-and-building.html)
-- [Bug reporting was improved a lot](https://doc.redox-os.org/book/ch12-03-creating-proper-bug-reports.html)
-- [Merge request workflow was improved](https://doc.redox-os.org/book/ch12-04-creating-proper-pull-requests.html)
-- [A branch-based workflow was documented](https://doc.redox-os.org/book/ch12-06-branch-workflow.html)
-- [The Chat page was improved](https://doc.redox-os.org/book/ch13-01-chat.html)
+- [RedoxFS was documented](https://doc.redox-os.org/book/redoxfs.html)
+- [The microkernels explanation was improved a lot](https://doc.redox-os.org/book/microkernels.html)
+- [A high-level explanation of the kernel was created](https://doc.redox-os.org/book/kernel.html)
+- [A high-level explanation of the userspace was created](https://doc.redox-os.org/book/user-space.html)
+- [A high-level explanation of the Redox graphics/windowing system was created](https://doc.redox-os.org/book/graphics-windowing.html)
+- [A high-level explanation of the Redox security](https://doc.redox-os.org/book/security.html)
+- [More side projects were documented](https://doc.redox-os.org/book/side-projects.html)
+- [All crates were documented](https://doc.redox-os.org/book/build-system-reference.html#crates)
+- [More configuration options were documented](https://doc.redox-os.org/book/configuration-settings.html)
+- [Coding and building workflow documentation was improved a lot](https://doc.redox-os.org/book/coding-and-building.html)
+- [Bug reporting was improved a lot](https://doc.redox-os.org/book/creating-proper-bug-reports.html)
+- [Merge request workflow was improved](https://doc.redox-os.org/book/creating-proper-pull-requests.html)
+- [A branch-based workflow was documented](https://doc.redox-os.org/book/branch-workflow.html)
+- [The Chat page was improved](https://doc.redox-os.org/book/chat.html)
 
 ## GitLab
 

content/news/kernel-11.md

++++
+title = "Towards userspaceification of POSIX - part I: signal handling and IO"
+author = "Jacob Lorentzon (4lDO2)"
+date = "2024-07-09T00:22:00+02:00"
++++
+
+# Introduction
+
+I'm very exited to announce that Redox has been selected as [one of the 45
+projects receiving new NGI Zero
+grants](https://nlnet.nl/news/2024/20240618-Call-announcement.html), with me as
+primary developer for [Redox's POSIX signals
+project](https://nlnet.nl/project/RedoxOS-Signals/)! The goal of this project
+it to implement proper POSIX signal handling and process management, and to do
+this in userspace to the largest reasonable extent. This grant is obviously
+highly beneficial for Redox, and will allow me to dedicate significantly more
+time to work on the Redox kernel and related components for one year.
+
+As this announcement came roughly a week after RSoC started, I spent the
+first week preparing the kernel for new IPC changes, by investing some time
+into changing the scheme packet format, improving both performance and the
+possible set of IPC messages.
+
+Since then, I've been working on replacing the current signal implementation
+with a mostly userspace-based one, initially keeping the same level of support
+without adding new features. This has almost been merged.
+
+## Improved userspace scheme protocol, and stateless IO
+
+TL;DR __As announced in the June report, an improved scheme packet format and
+two new syscalls have improved RedoxFS copy performance by 63%!__
+
+The Redox kernel implements IO syscalls, such as SYS_READ, by mapping affected
+memory ranges directly into the handler process, and by queueing `Packet`s
+containing metadata of those scheme calls. The `Packet` struct has existed, and
+had zero changes to the format, since [this commit from
+2016](https://gitlab.redox-os.org/redox-os/syscall/-/commit/0e7fec4adf35c9092b8c26c684bcb67ef5145a46). It is defined as follows:
+
+```rust
+#[repr(packed)]
+struct Packet {
+    id: u64, // unique (among in-flight reqs) tag
+    pid: usize, // caller context id
+    uid: u32, // caller effective uid
+    gid: u32, // caller effective gid
+    a: usize, // SYS_READ
+    b: usize, // fd
+    c: usize, // buf.as_mut_ptr()
+    d: usize, // buf.len()
+    // 56 bytes on 64-bit platforms
+}
+```
+
+While this struct is sufficient for implementing most syscalls, the obvious
+limitation of at most 3 arguments has resulted in accumulated technical debt
+among many different Redox components. For example, since `pread` requires at
+least 4 args, almost all schemes previously implemented boilerplate roughly of the
+form
+
+```rust
+fn seek(&mut self, fd: usize, pos: isize, whence: usize) -> Result<isize> {
+    let handle = self.handles.get_mut(&fd).ok_or(Error::new(EBADF))?;
+    let file = self
+        .filesystem
+        .files
+        .get_mut(&handle.inode)
+        .ok_or(Error::new(EBADFD))?;
+
+    let old = handle.offset;
+    handle.offset = match whence {
+        SEEK_SET => cmp::max(0, pos),
+        SEEK_CUR => cmp::max(
+            0,
+            pos + isize::try_from(handle.offset).or(Err(Error::new(EOVERFLOW)))?,
+        ),
+        SEEK_END => cmp::max(
+            0,
+            pos + isize::try_from(file.data.size()).or(Err(Error::new(EOVERFLOW)))?,
+        ),
+        _ => return Err(Error::new(EINVAL)),
+    } as usize;
+    Ok(handle.offset as isize) // why isize???
+}
+```
+
+as well as requiring all schemes to store the file cursor for all handles
+(which on GNU Hurd similarly is considered a 'questionable design choice' in
+[the
+critique](http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf)).
+This cursor unfortunately cannot be stored in userspace without complex
+coordination, since POSIX allows file descriptors to be shared by an arbitrary
+number of processes, after e.g. forks or SCM_RIGHTS transfers (even though this
+use case is most likely very rare, so it's not entirely impossible for this
+state to be moved to userspace).
+
+The new format, similar to [io_uring](https://kernel.dk/io_uring.pdf), is now
+defined as:
+
+```rust
+#[repr(C)]
+struct Sqe {
+    opcode: u8,
+    sqe_flags: SqeFlags,
+    _rsvd: u16, // TODO: priority
+    tag: u32,
+    args: [u64; 6],
+    caller: u64,
+}
+#[repr(C)]
+struct Cqe {
+    flags: u8, // bits 3:0 are CqeOpcode
+    extra_raw: [u8; 3],
+    tag: u32,
+    result: u64,
+}
+```
+
+SQEs and CQEs are the Submission/Completion Queue entries, where schemes read
+and process SQEs, and respond to the kernel by sending corresponding CQEs.
+These new types both nicely fit into 1, and 1/4th of a cache line,
+respectively, and some unnecessarily large fields have been shortened.
+`SYS_PREAD2` and `SYS_PWRITE2` have been added to the scheme API, that now
+allow passing both offsets and per-syscall flags (like `RWF_NONBLOCK`). The
+`args` member is opcode-dependent, and for `SYS_PREAD2` for example, is
+populated as follows:
+
+```rust
+// { ... }
+let inner = self.inner.upgrade().ok_or(Error::new(ENODEV))?;
+let address = inner.capture_user(buf)?;
+let result = inner.call(Opcode::Read, [file as u64, address.base() as u64, address.len() as u64, offset, u64::from(call_flags)]);
+address.release()?;
+// { ... }
+```
+
+The last `args` element currently contains the UID and GID of the caller, but
+this will eventually be replaced by a cleaner interface. The kernel currently
+emulates these new syscalls as using `lseek` and then regular `read`/`write`
+for legacy scheme, but for new schemes `lseek` can be ignored if the
+application uses more modern APIs. For instance, in `redoxfs`:
+
+```diff
+// This is the disk interface, which groups bytes into logical 4096-blocks.
+// The interface doesn't support byte-granular IO size and offset, since the underlying disk drivers don't.
+
+unsafe fn read_at(&mut self, block: u64, buffer: &mut [u8]) -> Result<usize> {
+--  try_disk!(self.file.seek(SeekFrom::Start(block * BLOCK_SIZE)));
+--  let count = try_disk!(self.file.read(buffer));
+--  Ok(count)
+++  self.file.read_at(buffer, block * BLOCK_SIZE).or_eio()
+}
+
+unsafe fn write_at(&mut self, block: u64, buffer: &[u8]) -> Result<usize> {
+--  try_disk!(self.file.seek(SeekFrom::Start(block * BLOCK_SIZE)));
+--  let count = try_disk!(self.file.write(buffer));
+--  Ok(count)
+++  self.file.write_at(buffer, block * BLOCK_SIZE).or_eio()
+}
+```
+
+Jeremy Soller previously used the file copy utility `dd` as a benchmark when tuning the most efficient block size,
+taking into account both context switch and virtual memory overhead. The
+throughput for reading a 277 MiB file using `dd` with a `4 MiB` buffer size,
+was thus increased from [170 MiB/s](/news/this-month-240229), for the previous optimizations, to 277 MiB/s with the new interface,
+roughly a 63% improvement. There is obviously a lot more nuance in how this
+would affect performance depending on parameters, but this (low-hanging)
+optimization is indeed noticeable!
+
+For comparison, running the same command on Linux, with the same virtual machine configuration,
+gives a throughput of roughly 2 GiB/s, which is obviously a significant
+difference. Both RedoxFS (which is currently fully sequential) and raw context
+switch performance will need to be improved. (Copying disks directly is done at
+2 GiB/s on Linux and 0.8 GiB/s on Redox).
+
+### TODO
+
+- There are still many schemes currently using the old packet format. They will need to be converted, allowing the kernel to remove the overhead of supporting the old format.
+- The `Event` struct can similarly be improved.
+- Both scheme SQEs and events should be accessible to handlers from a ring buffer (like io_uring), rather than the current mechanism where they are read as messages using SYS_READ. And syscall overhead, although strictly faster than context switching, is still noticeable, which is also why io_uring exists in the first place on Linux.
+
+# Signal handling
+
+The internal kernel signal implementation improved [earlier in
+March](https://gitlab.redox-os.org/redox-os/kernel/-/merge_requests/283), to
+address the earlier [quite serious
+shortcomings](https://gitlab.redox-os.org/redox-os/kernel/-/issues/117).
+However, even after the changes, signal support was still very limited, e.g. lacking support
+for sigprocmask, sigaltstack, and most of sigaction.
+
+## The problem
+
+Over the past year, I have been working to a large extent on migrating most Redox components away from using `redox_syscall`, our direct system call interface, to [`libredox`](https://gitlab.redox-os.org/redox-os/libredox), a more stable API.
+`libredox` provides the common OS interfaces normally part of POSIX, but allows us to place much more of the functionality in userspace, with a written-in-Rust implementation (even this is currently done by `relibc`, which also implements the C standard library).
+This migration is now virtually complete.
+
+Normally, monolithic kernels will expose a stable syscall ABI, sometimes guaranteed (e.g. Linux), and otherwise stable in practice (FreeBSD), with the most notable exception being OpenBSD (in the Unix world).
+This makes sense on monolithic kernels, since they are large enough to 'afford' compatibility with older interfaces, and also because much of the actual performance-critical stack is fully in kernel mode, avoiding the user/kernel transition cost.
+On a microkernel however, the kernel is meant to be as minimal as possible, and because the syscall interface on most successful microkernels differs from monolithic kernels' syscalls, that often match POSIX 1:1, this means our POSIX implementation will need to implement more POSIX logic in userspace.
+The primary example is currently the program loader, which along with `fork()` was fully moved to userspace during RSoC 2022.
+Along with possibly significant optimization opportunities, this is the rationale behind our [stable ABI policy](/news/development-priorities-2023-09/) introduced last year, where the stable ABI boundary will be present in userspace rather than at the syscall ABI.
+
+The initial architecture will be roughly the following:
+
+<hr />
+
+![Redox ABI diagram](/img/signals-project/abi.svg)
+
+A simple example of what `relibc` defers to userspace is the current working directory (changed during my [RSoC 2022](/news/drivers-and-kernel-7)).
+This requires relibc to enter a `sigprocmask` critical section in order to lock the CWD, when implementing async-signal-safe _open(3)_ (in this particular case there are workarounds, but in general such critical sections will be necessary):
+
+```rust
+// relibc/src/platform/redox/path.rs
+pub fn canonicalize(path: &str) -> Result<String> {
+    // calls sigprocmask to disable signals
+    let _siglock = SignalMask::lock();
+    let cwd = CWD.lock();
+    canonicalize_using_cwd(cwd.as_deref(), path).ok_or(Error::new(ENOENT))
+    // sigprocmask is called again when _siglock goes out of scope
+}
+```
+
+If more kernel state is moved to relibc, such as the `O_CLOEXEC` and
+`O_CLOFORK` (added in POSIX 2024) bits, or say, some type of file descriptors
+were to take shortcuts in relibc (like pipes using ring buffers), the overhead
+of two `sigprocmask` syscalls, wrapping each critical section, will make lots of
+POSIX APIs unnecessarily slow. Thus, it would be useful if signals could be
+disabled quickly in userspace, using memory shared with the kernel.
+
+## Userspace Signals
+
+The currently proposed solution is to implement `sigaction`, `sigprocmask`, and
+signal delivery (including `sigreturn`) only using shared atomic memory
+accesses. The secret sauce is to use two `AtomicU64` bitsets (even i686
+supports that, via `CMPXCHG8B`) stored in the TCB, one for standard signals and
+one for realtime signals, where the low 32 bits are the pending bits, and the
+high 32 bits are the allowset bits (logical NOT of the signal mask). This
+allows, for signals directed at threads, changing the signal mask while
+simultaneously checking what the pending bits were at the time, making
+`sigprocmask` wait-free (if `fetch_add` is).
+
+Not all technical details have been finalized yet, but there is a
+[preliminary
+RFC](https://gitlab.redox-os.org/4lDO2/rfcs/-/blob/signals/text/0000-userspace-signals.md).
+Signals targeting whole processes is not yet implemented, since [Redox's
+kernel does not yet distinguish between processes and
+threads](https://gitlab.redox-os.org/redox-os/kernel/-/issues/153). Once that
+has been fixed, work will continue to implement `siginfo_t` for both regular
+and queued signals, and to add the `sigqueue` API for realtime signals.
+
+This implementation proposal focuses primarily on optimizing the
+receive-related signal APIs, as opposed to `kill`/`pthread_kill` and
+`sigqueue`, which need exclusive access (which will probably not change), currently
+kept in the kernel. A [userspace process
+manager](https://gitlab.redox-os.org/redox-os/kernel/-/issues/152) has also
+been proposed, where the `kill` and (future) `sigqueue` syscalls can be
+converted to IPC calls to that manager. The idea is for all POSIX ambient
+authority, such as absolute paths, UID/GID/PID/...s, to be represented using
+file descriptors (capabilities). This is one piece of the work that needs to be done to
+fully support sandboxing.
+
+# Conclusion
+
+So far, the signals project has been going according to plan, and hopefully,
+POSIX support for signals will be mostly complete by the end of summer, with in-kernel improvements to process management. After
+that, work on the userspace process manager will begin, possibly including new
+kernel performance and/or functionality improvements to facilitate this.
+
+<style>
+img[alt="Redox ABI diagram"] { width: 80% }
+</style>