Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • redox-os/website
  • ids1024/website
  • jD91mZM2/website
  • deepaksirone/website
  • nickik/website
  • pharaone/website
  • sajattack/website
  • xTibor/website
  • orenkyl/website
  • rbnswartz/website
  • alaskacanyon/website
  • ShalokShalom/website
  • AdminXVII/website
  • oreed/website
  • linhub15/website
  • rw_van/website
  • brochard/website
  • t-nil/website
  • TeaDrinkingProgrammer/website
  • bujak.rafal/website
  • JCake/website
  • Ganipote/website
  • Streifen/website
  • piotr-calus/website
  • andypython/website
  • ssd/website
  • jensliu29/website
  • thynus/website
  • euclid/website
  • plimkilde/website
  • panaman67/website
  • MichaelMcDonnell/website
  • aaronjanse/website
  • jimt/website
  • RoboticDinosaur/website
  • Blesbok/website
  • potatogim/website
  • maheras_243/website
  • chirsz-ever/website
  • enygmator/website
  • BsmB/website
  • Darius/website
  • StaringAtEditor/redox-website
  • victor/website
44 results
Show changes
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1193 additions and 100 deletions
content/home.jp.md
View file @ 02f28248
+++
title = "ホーム"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">リリース情報をみる</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">リリース情報をみる</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.ko.md
View file @ 02f28248
+++
title = "홈"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">릴리즈 보기</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">릴리즈 보기</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.nl.md
View file @ 02f28248
+++
title = "Hoofdpagina"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Toon Releases</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Toon Releases</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Pull van GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.no.md
View file @ 02f28248
+++
title = "Hjem"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Vis utgivelser</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Vis utgivelser</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Pull fra GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.pl.md
View file @ 02f28248
+++
title = "Strona Główna"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -10,7 +10,8 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Zobacz Wydania</a>
<a class="btn btn-primary" href="/pl/quickstart/">Szybki start</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Zobacz Wydania</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Pobierz z GitLaba</a>
</div>
</div>
......@@ -39,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.pt.md
View file @ 02f28248
+++
title = "Início"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
<p class="pitch">
O <b>Redox</b> é um Sistema Operacional Tipo-Unix escrito em <a style="color: inherit;" href="https://www.rust-lang.org/"><b>Rust</b></a>,
que busca trazer as inovações desta linguagem de programação para um micro-núcleo moderno e para um conjunto completo de aplicações.
O <b>Redox</b> é um sistema operacional <a style="color: inherit;" href="https://en.wikipedia.org/wiki/Unix-like"><b>Unix-like</b></a> de propósito geral baseado em microkernel e escrito em <a style="color: inherit;" href="https://www.rust-lang.org/"><b>Rust</b></a>,
que busca trazer as inovações desta linguagem de programação para um microkernel moderno, um conjunto completo de programas e ser uma alternativa completa ao Linux e BSD.
</p>
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Ver as Releases</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Baixar do GitLab</a>
<a class="btn btn-primary" href="/pt/quickstart/">Começo Rápido</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">GitLab</a>
</div>
</div>
<div class="row features">
<div class="col-md-6">
<ul class="laundry-list" style="margin-bottom: 0px;">
<li>Implementado em Rust</li>
<li>Desenho de Micro-Núcleo</li>
<li>Inclui uma GUI opcional - Orbital</li>
<li>Suporta a biblioteca padrão da Rust</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/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 MIT</li>
<li>Os drivers são executados em espaço do usuário</li>
<li>Inclui os comandos Unix mais comuns</li>
<li>Nova biblioteca para portar programas em C</li>
<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/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>
</ul>
</div>
</div>
<div class="row features">
<div class="col-sm-12">
<div style="font-size: 16px; text-align: center;">
Redox executando Orbital
Redox executando o Orbital
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.ru.md
View file @ 02f28248
+++
title = "Главная"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Релизы</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Релизы</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Скачать на GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.sv.md
View file @ 02f28248
+++
title = "Hem"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Se utgåvor</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Se utgåvor</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Pull från GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.tr.md
View file @ 02f28248
+++
title = "Ev"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Yayınları gör</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Yayınları gör</a>
<a class="btn btn-success" href="https://gitlab.redox-os.org/redox-os/redox/">GitLab'dan Pull et</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.uk.md
View file @ 02f28248
+++
title = "Головна"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">Релізи</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">Релізи</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">Завантажити із GitLab</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/home.zh.md
View file @ 02f28248
+++
title = "主页"
url = "/home"
url = "home"
+++
<div class="row install-row">
<div class="col-md-8">
......@@ -11,7 +11,7 @@ url = "/home"
</div>
<div class="col-md-4 install-box">
<br/>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/releases">查看发布版本</a>
<a class="btn btn-primary" href="https://gitlab.redox-os.org/redox-os/redox/-/releases">查看发布版本</a>
<a class="btn btn-default" href="https://gitlab.redox-os.org/redox-os/redox/">从GitLab获取代码</a>
</div>
</div>
......@@ -40,13 +40,13 @@ url = "/home"
</div>
<a href="/img/redox-orbital/large.png">
<picture>
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.webp" type="image/webp">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.webp" type="image/webp">
<source media="(min-width: 1300px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/medium.png" class="img-responsive" alt="Redox and Orbital">
<source srcset="/img/redox-orbital/small.webp" type="image/webp">
<source media="(min-width: 640px)" srcset="/img/redox-orbital/large.png" type="image/png">
<source media="(min-width: 320px)" srcset="/img/redox-orbital/medium.png" type="image/png">
<source srcset="/img/redox-orbital/small.png" type="image/png">
<img src="/img/redox-orbital/large.png" class="img-responsive" alt="Redox and Orbital">
</picture>
</a>
</div>
......
content/news/01_rsoc2024_dynamic_linker.md 0 → 100644
View file @ 02f28248
+++
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 0 → 100644
View file @ 02f28248
+++
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 0 → 100644
View file @ 02f28248
+++
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/board-meeting-2023-06-21.md 0 → 100644
View file @ 02f28248
+++
title = "Redox OS elects its first Board of Directors"
author = "Jeremy Soller"
date = "2023-06-21"
+++
On June 21, 2023, the Redox OS nonprofit elected its first Board of Directors.
The Redox OS project is a Unix-like operating system written in Rust, and
intended for free public and commercial use. The nonprofit was formed to
support the project and its community, and will help provide transparency in
the management of funds, hopefully leading to increased donations and the
ability to hire full-time staff.
The Redox OS Board of Directors consists of:
<hr>
### Ron Williams, as President
<a href="/img/board/ron-williams.jpg"><img width=256 height=256 src="/img/board/ron-williams.jpg"/></a>
Ron has over 30 years experience in the software industry in technical, consulting and executive roles. He has consulted to Fortune 500 companies in designing and developing new products. As president and co-founder of Ensemble Systems, he grew the company to over 100 technical staff, with Ensemble twice being selected as one of the best places to work in British Columbia. After many years as a consultant and executive, he has rediscovered his love of coding by contributing to Redox OS.
<hr>
### Jeremy Soller, as Treasurer and Vice-President
<a href="/img/board/jeremy-soller.jpg"><img width=256 height=256 src="/img/board/jeremy-soller.jpg"/></a>
Jeremy created the Redox OS project in 2015, and is the Redox [BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). He has been involved with open source software development for over fifteen years, starting with hobby projects and soon moving into professional open source software development. He is currently employed as Principal Engineer at System76, where he manages a team of engineers building open source software, firmware, and hardware. His experience with low-level development has driven many successful projects at both Redox OS and System76.
<hr>
### Alberto Souza, as Secretary
<a href="/img/board/alberto-souza.jpg"><img width=256 height=256 src="/img/board/alberto-souza.jpg"/></a>
Alberto has been an open-source activist and amateur systems researcher since 2017. He has used dozens of Unix-like systems and thousands of free and open-source programs, from mainstream to underground. He has been following Redox OS development over the years, feeling confident to start contributing in 2023. Since starting, he has made vast improvements to the Redox OS management, documentation and worked on porting numerous programs.
<hr>
### Discussion
Feel free to discuss this on social media:
- [Patreon](https://www.patreon.com/posts/84927623), help us by providing funding!
- [Lemmy](https://lemmy.world/post/397986)
- [Mastodon @redox](https://fosstodon.org/@redox/110584297927846238)
- [Mastodon @soller](https://fosstodon.org/@soller/110584297023639320)
- [Matrix](https://matrix.to/#/#redox-general:matrix.org), for new members go to the [join requests room](https://matrix.to/#/#redox-join:matrix.org)
- [Reddit r/redox](https://www.reddit.com/r/Redox/comments/14fju3d/redox_os_elects_its_first_board_of_directors/)
- [Twitter @redox_os](https://twitter.com/redox_os/status/1671629242197770240)
- [Twitter @jeremy_soller](https://twitter.com/jeremy_soller/status/1671629284233060352)
content/news/bochs-qemu-2.md 0 → 100644
View file @ 02f28248
+++
title = "Bochs on Redox OS (and QEMU - Part 2)"
author = "Enygmator"
date = "2022-07-10T04:35:30.295Z"
+++
# Prologue
Hey there everyone! I'm <font color="#9a39bc">Eny</font><font color="#3e3e3e">gma</font><font color="#a58f01">tor</font> and I'm back!
_TLDR; The technical stuff starts from the **Emulators on Redox** section._
<br/>
For those of you who don't know me (or my role in Redox), I'd like to introduce myself as the **RSoC (Redox Summer of Code) 2021 student** who worked on **porting QEMU to Redox OS**.
This post brings you some updates on the progress I've made on that front (QEMU on Redox) and another juicy undertaking of mine - **It's BOCHS on Redox y'all!** 😀
I'm writing this post as an UPDATE to my previous post ([refer post - RSoC 2021: QEMU on Redox OS - Part 1](https://redox-os.org/news/rsoc-2021-qemu-1/)) that I wrote last year, as part of RSoC 2021, where I promised an update (which is long due). This post is going to be more straightforward and technical than the last one, so if you aren't fully aware of QEMU, OSes, emulators, userspace program porting, etc, you should definitely read that post. I explain _from the basic_ in simple language, before getting more technical.
You should also read it if you're interested in how I started out porting QEMU to Redox OS.
It has been one heck of a year and despite my preoccupation with my undergraduate degree (BTech - CSE, 2023), I was able to put in some amount of time after the duration of RSoC 2021, to further develop the project I was working on (QEMU, and later Bochs). I worked on the stuff mentioned in this post a while back, but am writing this post only now (procrastination). This post is not a part of either RSoC 2021 or RSoC 2022, just an update to spice things up.
BTW, I'm currently working on **Virtualization on Redox OS** as part of RSoC 2022.
Yep! Virtualization support is coming to Redox OS _soon_! The feature is called **Revirt** and the project plan and implementation details are documented in the two posts - ["Revirt - Virtualization on Redox OS"](https://redox-os.org/news/revirt-1/) AND ["RSoC 2022: Revirt-U - Part 1"](https://redox-os.org/news/rsoc-2022-revirt-u-1/).
<br/>
### Updates
If I make any updates to this post (which is sometimes helpful for people reading it in the future), I shall make note of it here and st the same time, ~~scratch out~~ older content and replace it with something like "UPDATE1: ...".
<br/>
<br/>
# Emulators on Redox
_Emulators are applications that provide **ISA-level virtualization** (one among other types of virtualization). If an emulator emulates an ISA which is the same as the ISA of the hardware the emulator is running on, it is also known as **Hardware-level Virtualization** (example: Bochs)_
_Though, do note that 'Hardware-level virtualization' is not the same as 'Hardware-assisted virtualization'. The latter is a special type of the former, where 'hardware-assisted' means ISA-support (hardwired) for virtualization at the 'hardware-level'_
<br/>
Having emulators like QEMU and Bochs successfully run on Redox OS, helps realize the support (tooling and ecosystem) required for self-hosting, and at the same time enabling support for specific use cases for Redox OS.
Self-hosting isn't a long way off on Redox, and tooling around a new software/hardware that makes it easier to work with pretty much decides how successful the software/hardware will be. (as suggested by Linus Torvalds, where he said that he loves `x86` more than `arm` because of the amazing ecosystem around x86 that has been built over the past decades).
While I was attempting to port QEMU, I thought of looking into porting Bochs too, given that its codebase looked much simpler (given that it _only_ emulates x86 and some peripherals). Here, I write about both those attempts of mine (and their results).
## QEMU
You can find all the work I did at [`enygmator/qemu` GitLab Repo - `qemu_for_redox` branch](https://gitlab.redox-os.org/enygmator/qemu/-/tree/qemu_for_redox).
QEMU has its own build system based on `MAKEFILES` and a meta-build system based on `meson` that is capable of compiling to Linux, MacOS and Windows targets. I created a new target called `redox`, which disables all features of QEMU by default and also the `tests` in `meson.build`. Then I manually enable only a subset of the features (for `qemu-system-x86_64`) to run.
Using preprocessor checks like `#if defined(__redox__)`, some of the alternative code was written.
Build, make and install scripts were configured in `recipe.sh`. It also had to be modified to recursively link the dependencies of each dependency statically (using `LD_FLAGS`).
TODO: I need to figure out a way to make that happen automatically based on `pkg-config` info.
<br/>
### Result
With a required number of features enabled (only to successfully build the emulator for `x86_64-softmmu`), QEMU is **successfully compiling for Redox OS** (including the static dependencies).
TODO: But it fails to execute - most likely because I may have written some incorrect placeholder code causing it to go into an infinite loop. Fixing this should be easier now that I have spent time understanding the kernel internals better and can use debuggers to track code execution.
I'll have an update on QEMU when `qemu-system-x86_64` runs for the first time.
<br/>
### TLDR; Working on the code
The `recipe.sh` file is [here - on the `qemu_on_redox` branch of `enygmator/cookbook` repo](https://gitlab.redox-os.org/enygmator/cookbook/-/blob/qemu_on_redox/recipes/qemu/recipe.sh).
Feature configuration is done in the `recipe.sh` file, which is used to build the QEMU package for Redox, which can later be installed on Redox. The `recipe.sh` file currently depends on the QEMU source being located at `try_redox/redox_apps/qemu-7.0.0` (where the Redox OS repo is located at `try_redox/redox`). This is used to run the VPATH build (done by commands in `recipe.sh`).
If you want complete instructions on compiling `qemu-7.0.0` on Redox OS, you'll find them in the `README.md`, [here - on the `qemu_on_redox` branch of `enygmator/cookbook` repo](https://gitlab.redox-os.org/enygmator/cookbook/-/tree/qemu_on_redox/recipes/qemu). DO contact me if you have questions, suggestions or face issues. I may be able to help. (or you can file an issue in one of repo links - [`cookbook` - GitLab Issues](https://gitlab.redox-os.org/enygmator/cookbook/-/issues) or [`qemu` - GitLab Issues](https://gitlab.redox-os.org/enygmator/qemu/-/issues))
## Bochs
[Bochs 2.7](https://bochs.sourceforge.io/) seemed like a good emulator to port, as it is so much more lighter than QEMU, due to the fact that it only emulates x86 ISA with a certain number of peripherals, and doesn't support KVM either. So, I started to work on porting it [here - on the `bochs_on_redox` branch of `enygmator/bochs` on GitLab](https://gitlab.redox-os.org/enygmator/bochs/-/tree/bochs_on_redox).
Bochs uses `Makefile` for it's build system, and similar to QEMU, it uses the VPATH build method (which ensures that all build files are worked on in a separate directory that you can manually specify, so that the source repo isn't touched in any manner at all).
My experience with porting QEMU (incompletely) came in very handy, as within 6 hours I actually was able to get Bochs to statically compile! albeit with some 'extra' features turned off. There were some `#include` changes with respect to the `SDL` and `SDL2` libraries and some 'tricky' method to force bochs to compile statically (since it's build system was not doing it correctly). You can view the changes in the repo link above.
I then configured the `make` procedure and `install` sections of the `recipe` and booted into Redox and ran bochs with a super minimal "bootloader + kernel" that I had written back in 2020 (my first "OS project" 😊) loaded onto a 'hard drive file' and configured bochs emulator using a `bochs.src` _bochs configuration file_.... and it ran! You can see "stage 2" of my kernel in the below image:
<img class="img-responsive" src="/img/screenshot/bochs_redox_demo_1.png" alt="Bochs GUI running on Redox" />
<br/>
At a later point, I'll enable and work on more features to make bochs work better. Though, the priority will always be QEMU as it is **so much more** important in terms of common/industrial usage and the functionality it offers, and a priority for emulation and Hardware-assisted Virtualization (which I'm working on as part of RSoC 2022).
<br/>
### Known Issues
1. There seems to be some problem in the framebuffer mapping when the SDL2 window resizes, causing things to look "skewed". (I fixed it in the image above by manually changing the mapping 😅)
2. Bochs also crashes when the window size in increased by a huge amount.
<br/>
### TLDR; Working on the code
The `recipe.sh` file is [here - on the `bochs_on_redox` branch of `enygmator/cookbook` on GitLab](https://gitlab.redox-os.org/enygmator/cookbook/-/blob/bochs_on_redox/recipes/bochs/recipe.sh).
Feature configuration is done in the `recipe.sh` file, which is used to build the Bochs package for Redox, which can later be installed on Redox. The `recipe.sh` file currently depends on the Bochs source being located at `try_redox/redox_apps/bochs` (where the Redox OS repo is located at `try_redox/redox`). This is used to run the VPATH build (done by commands in `recipe.sh`).
If you want complete instructions on compiling `bochs` on Redox OS, you'll find them in the `README.md`, [here - on the `bochs_on_redox` branch of `enygmator/bochs` on GitLab](https://gitlab.redox-os.org/enygmator/bochs/-/blob/bochs_on_redox/README.md). DO contact me if you have questions, suggestions or face issues. I may be able to help. (or you can file an issue in one of repo links - [`enygmator/cookbook` - GitLab Issues](https://gitlab.redox-os.org/enygmator/cookbook/-/issues) or [`enygmator/bochs` - GitLab Issues](https://gitlab.redox-os.org/enygmator/bochs/-/issues))
<br/>
<br/>
# Epilogue
While writing this post, I made some updates to the previous post. While reading that, I cringed many times looking at some glaring errors I had made in understanding a few concepts (that I now understand much better) or the method by which I did something. But I guess that's what learning and growth are about - every time you look back at your previous work, you think "I sure was an amateur back then! 😣". Some day, I'll look at this post and realize the same thing.
Contributing to Redox OS's future is a lot of fun. I learnt about the different ways in which build systems are configured/constructed (and am already using them in my projects 🙂) in addition to cross-compilation and lots of other tid-bits. I want to thank those who have guided me in the `Redox OS mattermost chat` during RSoC 2021 and later (`omac777`, `a4ldo2` and of course `jackpot51`).
I shall soon write my next post (as an RSoC 2022 student), so hang on tight people!
## Until later!
If you've reached till this point, thank you for reading. I shall be coming back sometime ~~next month~~(UPDATE1) with more exciting updates!
Until then, keep well.
Bye! 💕💕💕
<br/>
You can find me on:
- [Redox OS - GitLab](https://gitlab.redox-os.org/enygmator/)
- Redox OS - Mattermost chat - username: `enygmator`
- [GitHub](http://github.com/enygmator/)
- [LinkedIn](https://www.linkedin.com/in/ttarunaditya/)
- [Twitter](https://twitter.com/Enygmator)
- [Encrypted chat on Matrix (like _Element chat_)](https://matrix.to/#/@enygmator:matrix.org)
content/news/community-announcements-1.md 0 → 100644
View file @ 02f28248
+++
title = "Community Announcements - Matrix, Fosstodon and Lemmy"
author = "Ribbon"
date = "2023-07-15"
+++
This post will cover the important changes for community on this year.
## Matrix
It was decided that Matrix will be our permanent way for communication.
Since January the Redox project was testing Matrix as the new platform for community/development communication, Jeremy Soller migrated to Matrix because of its maturity and popularity.
A Matrix [space](https://matrix.to/#/#redox:matrix.org) for Redox was created with some rooms, more were added over time, you can see the current state below:
- [#redox-join:matrix.org](https://matrix.to/#/#redox-join:matrix.org) - a room to be invited to the Redox space.
- [#redox-general:matrix.org](https://matrix.to/#/#redox-general:matrix.org) - a room for Redox-related discussions (questions, suggestions, porting, etc).
- [#redox-dev:matrix.org](https://matrix.to/#/#redox-dev:matrix.org) - a room for development, here you can talk about anything development-related (code, proposals, achievements, styling, bugs, etc).
- [#redox-support:matrix.org](https://matrix.to/#/#redox-support:matrix.org) - a room for testing/building support (problems, errors, questions).
- [#redox-mrs:matrix.org](https://matrix.to/#/#redox-mrs:matrix.org) - a room to cover all ready merge requests without conflicts (if you have a ready MR to merge, send there).
- [#redox-board:matrix.org](https://matrix.to/#/#redox-board:matrix.org) - a room for Board of Directors meetings.
- [#redox-voip:matrix.org](https://matrix.to/#/#redox-voip:matrix.org) - a room for voice/video calls.
- [#redox-random:matrix.org](https://matrix.to/#/#redox-random:matrix.org) - a room for off-topic.
Jeremy decided to use the [Rust Code Of Conduct](https://www.rust-lang.org/policies/code-of-conduct) as rules for the rooms.
The Redox space is invite-only, every new member must join the "Join Requests" room and request an invite to the Redox space.
Only members of the Redox space can see/join the rooms.
(This system satisfy our needs properly)
The power of all moderators is limited and a room for moderators is available, we discuss moderation-related issues there.
If we have problems with the `matrix.org` instance, probably we can host one using the Synapse server (the same of `matrix.org`) because of its maturity.
Conduit is a Matrix server is written in Rust but is not ready for production use yet.
## Fosstodon
Fosstodon is an alternative for Twitter, we have more control over our content there.
- [Fosstodon](https://fosstodon.org/@redox)
We plan to migrate the userbase of Twitter to Fosstodon.
## Lemmy
Lemmy is an FOSS alternative to Reddit, we have more control over our content there.
- [Lemmy](https://lemmy.world/c/redox)
We plan to migrate the userbase of Reddit to Lemmy.
content/news/development-priorities-2023-09.md 0 → 100644
View file @ 02f28248
+++
title = "Development Priorities for 2023/24"
author = "Jeremy Soller and Ron Williams"
date = "2023-09-30"
+++
We've made great progress this summer, as all the pieces of Redox continue to come together to create a complete operating system.
To give a big-picture perspective for where Redox development is headed, here is our view of priorities as of September, 2023.
## Redox ABI
Before Redox can reach Release 1.0 status, we need to establish a stable ABI. This means that application binaries will be able to run on future versions of Redox without having to be recompiled.
Our approach is to make our C library, `relibc`, the interface for the stable ABI, and to make `relibc` a dynamic library.
This will allow us to make changes at the system call level without impacting the Redox ABI. Applications will just load the latest `relibc` at run time.
Work needs to be done on our dynamic library support, as well as to continue to extend `relibc` functionality.
We will also need to change programs that are currently using Redox system calls directly to use `relibc` instead.
## Redox Server
We want to develop a Server version of Redox.
This is a higher priority than desktop because it is presumed to be a smaller scope.
We have some work to do on optimizing drivers, especially network drivers.
The foundation is very much there and porting common server programs is an important step to take - things like Apache, Nginx, etc.
### Self-Hosting the Redox Website
We would like to host the Redox website on Redox running in a virtual machine.
The Redox Summer of Code projects have been filling in some of the gaps we have had for virtual machines.
Having drivers like the ones Andy worked on for VirtIO will enable much lower latency and higher performance virtual machines running Redox.
It gets us to the point where we might be able to run Redox on a cloud machine, like EC2 or DigitalOcean.
### Virtual Machine Support
There is a lot of work to be done on virtual machine support, device virtualization and Redox as a hypervisor.
Some of the Summer of Code work was in this area, and we are hoping to see this work continue.
## Self-Hosting the Build System
We want to self host the build system.
This has been a very long term goal that we have been working on over the entire course of Redox, and a very important one.
We have been able to port GCC, Binutils and other aspects of the build system to Redox, but the one remaining issue is that `rustc` itself doesn’t work very well on Redox.
The work we have to fix that is pretty involved, it’s at all places in the stack.
- We have to continue porting functions to `relibc`, and we have to continue porting Rust crates that that need Redox-specific changes.
- We have to continue implementing more driver and kernel support.
- Importantly, we have to implement more POSIX process and job management system calls and C library functions. This is one area that has been particularly difficult and 4lDO2 has been working really hard on it. So we hope to have some progress made within the next year.
### Developer Tools
We need to work on porting developer tools to Redox.
That involves identifying the tools we want to port and ensuring that they are running properly. We have a lot of the basic things there, like the ability to compile C programs, Python and Lua and some other scripting languages that have been partially ported.
But the big one is still `rustc`, and then after that, porting other popular languages. Elixir and Go, for example, have their own runtime and are therefore more difficult than C and C++.
We also still have a lot of work to fully support C and C++, because of missing aspects of `relibc` that need to be fleshed out, e.g. wide string support.
## Performance
We need to start giving more attention to performance and responsiveness, and making Desktop and Demo go faster is an important part of that.
A majority of how people will interact with the system is to download our ISO and try it out on real hardware.
That’s a common thing for Linux distributions and we should assume that people will be trying to do with Redox.
Right now we have some issues that are stopping us in that direction.
The support for virtual machines is far better than for real hardware.
Our device drivers try to target common hardware, but they don't always work well.
For example, the high definition audio driver may work on one machine but hang on another machine.
Preventing hangs like that across the entire set of drivers that we have is a very important part to getting people to be able to see our demo image running on real hardware at native performance.
Then there is optimization.
4lDO2 has been working on various optimizations, like on demand paging.
Jeremy likes to port a lot of games, emulators and things like that, because it’s another way to see the performance.
When you can make a game run properly at very high speeds and very low latency, then you know the rest of the stack is basically good.
It becomes an easy benchmark to compare as you make changes.
## Cosmic Desktop
The Cosmic Desktop is something being worked on at System 76, where Jeremy works.
It’s an open source Linux desktop environment that is written mostly in Rust, and that aligns it with the goals of Redox.
There are some things we need to work on to have Cosmic Desktop on Redox.
- First, we need to port some of the applications that are going into Cosmic.
For example, the text editor that Jeremy is working on for Cosmic can be ported to run on top of Orbital, which is our current window manager for Redox.
- The second stage will be to port Wayland and the Cosmic compositor.
That will allow us gain all the applications on Cosmic and the other elements of the shell by having an actual Wayland compositor.
That will also enable us to easily port GTK, Qt, and other app frameworks like Electron.
A large list of applications that run on Linux are able to be ported to any Wayland environment, and should require minimal patching to run on Redox.
\ No newline at end of file
content/news/documentation-improvements.md 0 → 100644
View file @ 02f28248
This diff is collapsed.
content/news/drivers-and-kernel-6.md 0 → 100644
View file @ 02f28248
This diff is collapsed.