Enquanto o sucessor do X Window Server andou por entre o Mir, o Wayland e derivados, no ano passado, foi relevado um display server, igualmente open-source, que pretendia ser originalmente um Servidor Gráfico
mais optimizado para aplicações gráficas, em ecrã cheio (full screen), e com acesso de baixo nível ao hardware gráfico, e que depois foi ampliado para suportar os elementos básicos de um interface gráfica.

Com isso nasceu o Arcan Display Server, disponível para Linux, FreeBSD e Windows (!)

https://arcan-fe.com/

https://github.com/letoram/arcan

A grande diferença entre o Mir/Wayland e até o X comparado com o Arcan, é que a sua arquitectura é muito mais similar ao servidor gráfico do sistema operativo Orbis (PS4) ou da versão do Windows 10 que opera na Xbox One, do qual, os seus elementos primitivos são os streams da GPU, e a sua renderização
 é feita exclusivamente pela GPU usando o motor gráfico (Arcan Display Engine) do Arcan.

Posteriormente, na altura que o projecto foi lançado ao público, foi criado um pequeno sistema de janelas, escrita em linguagem Lua, designado por Durban, como demonstração para além de programas, como jogos, a correr via SDL modificada para usar directamente o Arcan
Display Engine...

Actualmente, o Arcan está a ser ampliado para que o Arcan Composer (que gere, por compatibilidade, os elementos primitivos das janelas e eventos, implementados sobre o Arcan Display Engine) emule o protocolo Wayland e X Window Server,
 que actualmente está parcialmente funcional.

A ideia do autor deste projecto é que sistemas de interface gráfica como o XFCE, o Debian e companhia que usem o protocolo Wayland, funcionem sem necessidade de mudar uma única linha de código. Bibliotecas como o SDL, Vulkan e afins podem usar o Wayland, para comunicar com
o Arcan Composer, mas para acesso de baixo nível ao hardware, devem usar as versões Vulkan e SDL modificadas para operar no Arca Display Engine...

Ora isso é exactamente o que acontece no sistema Orbis da PS4. Existe uma API de alto nível mais adequado para programas com janelas e eventos, e depois uma API de baixo nível mais adequado para um jogo operar em exclusivo no monitor, comunicando quase directamente ao hardware.

Seria interessante se a Canonical tivesse sondado o programador do Arcan, pois neste caso em vez de terem criado o Mir, teriam usado o Arcan para o UNity/Xfce/etc, e depois com o aparecerimento da Steam, podiam usar a funcionalidade de baixo nível para os jogos,
implementando um Game Mode do qual o jogo teria acesso directo (na realidade via API low-level) ao hardware gráfico local, evitando os overheads do X/Wayland/Mir...

Continuação das Instruções...

Prevê-se que dentro de poucas semanas vários dos branches do projecto Darling sejam unidos, dado que certos executáveis como o ruby para Mac OS X deve ser compilado como um executável mach-O nativo.
Isto significa que o AppKit e o Mach-O library deverão substituir o main branch, o que tornaria a maioria dos utilitários do Darling, de modo a substituir os executáveis ELF nativos para os Mach-O nativos do OS X.

Mas por agora, resta explicar como se instala o suporte de 32-bit (Mas não vai funcionar num sistema Ubuntu de 32-bit, pois não é suportado!), se bem que poucos programas para a plataforma Mac OS X existam para 32-bit-

Primeiro acrescente os pacotes de compatibilidade de 32-bit...

$ sudo apt-get install libc6-dev-i386 libudev-dev:i386 lib32stdc++-4.9-dev

E o resto é fácil de prosseguir...

cd darling
mkdir -p build/i386
cd build/i386
cmake ../.. -DCMAKE_TOOLCHAIN_FILE=../../Toolchain-x86.cmake -DFRAMEWORK_COREAUDIO=ON -DFRAMEWORK_APPKIT=1
make
sudo make install

O módulo de kernel é de apenas 64-bit, portanto não é necessário recompilar.

Programas PowerPC não são suportadas, embora os devs do Darling já aceitaram a sugestão como "enhancement", e isso só exigiria criar um Toolchain com as bibliotecas para a Arquitectura PowerPC, e instalar o qemu-ppc-static para funcionar.

Guia do Utilizador (alpha...)

Para iniciar o Darling, deve primeiro activar o módulo de kernel, pelo menos uma vez por login:
$ sudo modprobe darling-mach
$ sudo chmod a+rw /dev/mach

Por fim, inicie o Darling, que carrega a versão nativa do Mac OS X do bash:
$ darling shell

Após experimentar vários comandos que já encontra no Linux, no Darling (uns funcionais, outros desactivados/inexistentes/disfuncionais...), deve ter em conta que a directoria ~/.darling é interpretada dentro do OS X virtual como a root virtual.
Ao contrário do Wine, as associações entre directorias virtuais são idênticas aos sistemas Unix, pois podemos usar links simbólicos e usar os mesmos métodos e truques.
O suporte a programas com Interface Gráfica é experimental, pois os compiladores tendem a usar o framework Carbon que não foi ainda implementado, em vez de usar o AppKit "puro", e isso falha a sua execução no Darling.

É possível instalar o XCode no Darling, mas ficará limitado aos compiladores que operam na linha de comando...
(Alternativamente, pode instalar o Clang e o osx-cross com o XCode que cria os cross-compilers nativos para Linux, caso queira criar um ambiente de teste com programas simples, para depois testá-los no Darling. A última opção é mais segura.)

Ainda assim, o Darling implementou clones de dois programas exclusivos do Mac OS X: o installer e o hdiutil, que são versões muitos simplificadas do original...

Usando o Firefox (para Linux nativo, claro!), pode visitar o Rudix ou o MacPorts, e instalar (manualmente) vários pacotes PKG, que são para os sistemas BSD, os DEB para o Ubuntu e derivados.

Assumindo que possui o bash do Darling na directoria de Transferências, para instalar um pacote, faça:
$ installer -pkg <pacote> -target /
E depois digite o comando do programa.

Se tiver programas com problemas como não encontrar biblioteca x.so ou x.dylib, basta adicionar à variável de sistema DYLD_LIBRARY_PATH ou DYLD_FALLBACK_LIBRARY_PATH, a directoria correspondente.

Usando o hdiutil pode agregar imagens DMG, do qual utiliza o FUSE, e ficam montados em /Volumes.
$ hdiutil attach <image>
$ cd /Volumes/<image>

Como podem notar, a barreira de recriar um sistema BSD em Linux é muito menor que um sistema Windows.

Após alguns anos de desenvolvimento, o rpcs3 pode ser testado com maior ou menor dificuldade, embora deva ter em atenção que:
- Não explicarei como obter os jogos.
- Exige um computador bastante potente para conseguir emular uma PS3.

Pré-requistos:
- A última versão do Ubuntu 16.10, versão 64-bits (Devido ao uso do clang e LLVM)
- Um computador com Intel Core i5 ou i7 arquitectura Haswell or Skylake. (Para ser minimamente realista)
- Entre 8 a 16 Gb de RAM
- Uma GPU NVidia série 900 ou 1000, ou AMD equivalente com suporte nativo por hardware do OpenGL 4.4 ou Vulkan (recomendadíssimo)
- Recomenda-se a instalação dos drivers das GPU com suporte ao Vulkan API
- Deve ter pelo menos entre 10 a 50 GB de espaço em disco livre para cada jogo da PS3, que quer instalar.
- Para ser legal o uso, uma drive BD-ROM que leia os discos da PS3  (recomenda-se o modelo LG BD-RE WH16NS40. ) e evite a tentação de usar cópias piratas... 

Tendo pronto a máquina pronto a funcionar, instale primeiro as dependências:

$ sudo apt-get install cmake git build-essential libopenal-dev libwxgtk3.0-dev libglew-dev zlib1g-dev libedit-dev libvulkan-dev llvm-dev

Clone o git do emulador

$ git clone https://github.com/RPCS3/rpcs3.git
$ cd rpcs3
$ git submodule update --init

// Atenção! Devido a um bug nos pacotes clang, é encessário escrever o seguinte ficheiro
++++++++++++++++++++++++++++++++++++

// This is a generated file.
 
#define RPCS3_GIT_VERSION "unknown"
 
// If you don't want this file to update/recompile, change to 1.
#define RPCS3_GIT_VERSION_NO_UPDATE 1

+++++++++++++++++++++++++++++++++++

E salvá-lo como "git-version.h", em rpcs3/rpcs3/git.version.h

Por fim, só resta compilar...

$ cmake CMakeLists.txt
$ make

Se tudo correr bem  , o executável fica guardado em...
rpcs3/bin/rpcs3

Que fica no directório raíz do disco rígido emulado da PS3 (deve ter os directórios dev_flash, dev_hdd0, dev_hdd1,... presentes.)

- Depois fica tudo por vossa conta... 

Encontrei durante as minhas pesquisas um projecto activo para um emulador de um sistema operativo de 8-bit (!) que teve sucesso na transição da década de 1970 para a de 1980: o CP/M da Digital Research

Tratou-se do primeiro sistema operativo genérico para a maioria dos computadores pessoais de 8-bit, até que o padrão IBM-PC (de 16-bit) tomou o mercado, e o sistema acabou por se extingir após 1983, embora até 1985 ainda eram lançados softwares para ele.

O Digital Research acabaria por criar uma versão de 16-bit do CP/M (designado CP/M-86) que não teve grande sucesso, mas acabaria por se tornar a base do DR-DOS que era mais ou menos compatível com o MS-DOS original.

Além disso só funcionava com o processador Intel 8080 ou 8085, mas também com o Zilog Z80 (o mesmo que o ZX Spectrum ou o TK 85), ou com o Nec V20 e V30.

O CP/M e o MS-DOS possuem características comuns, como a designação de drives por letras, o padrão 8.3 para os nomes e extensões dos ficheiros, e o sistema operativo ser constituído por três módulos: o módulo do kernel (BIOS, similar ao msdos.sys), o módulo I/O (BDOS, similar ao io.sys) e o interpretador de comandos (CPM, similar ao command.com).

O emulador pode ser obtido através deste site:
https://github.com/MockbaTheBorg/RunCPM

E deve ter pelo menos instalado o compilador gcc e o pacote base de bibliotecas (o CP/M por si só não suportava gráficos, e somente exige a biblioteca ncurses em sistemas POSIX como o Linux ou o Mac OS X)

Portanto basta clonar o git:
$ git clone https://github.com/MockbaTheBorg/RunCPM.git
$ cd RunCPM\RunCPM

E compilar:
$ makefile -f Makefile.posix

Agora crie uma pasta para o CPM (mkdir ~/cpm)
Depois crie uma pasta dentro do cpm com o nome A (mkdir A), e depois dentro da pasta A, crie uma com o nome 0 (mkdir 0).
Isto cria um drive A virtual com o selector USER 0 (uma das características bizarras deste sistema operativo era criar sub-partições (até 16) para cada uma dos 16 drivers possíveis (de A a P)

Agora copia o novo executável RunCPM para a directoria "cpm", e depois o conteúdo da pasta ./RunCPM/CCP para a mesma directoria do executável (é a implementação de terceiros da shell de comandos do CP/M 2.2).
Por fim, copie o ficheiro A.zip de ./RunCPM/DISK para a pasta ~/cpm/A/0 e depois descompacte aí (pode apagar o zipfile depois).

Para operar o programa abra a janela de Terminal, navege para a pasta ~/cpm e digite:
$ ./RunCPM

Se tudo correr bem, é iniciado um emulador Zilog Z80 e mostra a prompt de comando:
A>

Digite dir, e deve mostar algo do género:

CP/M 2.2 Emulator v2.7 by Marcelo Dantas
      Build Sep 22 2016 - 23:14:16
-----------------------------------------
CCP: CCP-DR.BIN Loaded at 0xf400

RunCPM Version 2.7 (CP/M 2.2 64K)

A>dir
A: 1STREAD  ME  : ASM      COM : BDOS     ASM : BDOS     SUB
A: BDOSEQU  LIB : CCP-DR   BIN : CCP-ZCPR BIN : CCP      ASM
A: CCP      SUB : CLEAN    SUB : DDT      COM : DISKDEF  LIB
A: DISPLAY  LIB : DUMP     ASM : ED       COM : EXIT     ASM
A: EXIT     COM : EXIT     SUB : EXIT     Z80 : LOAD     COM
A: LU       COM : MAC      COM : MBASIC   COM : MLOAD    ASM
A: MLOAD    COM : MLOAD    DOC : MOVCPM   COM : OPCODES  TXT
A: PIP      COM : RSTAT    COM : RSTAT    SUB : RSTAT    Z80
A: STAT     COM : SUBMIT   COM : SYSGEN   COM : TE       COM
A: UNARC    COM : UNCR     COM : USQ      COM : XSUB     COM
A: Z80ASM   COM : Z80ASM   PDF : ZCPR     ASM : ZCPR     SUB
A: ZCPRHDR  LIB : ZEXALL   COM : ZEXDOC   COM : ZSID     COM
A: ZTRAN    COM
A>

Em seguida invoque "exit"
A>exit

Para retornar ao bash.

E com isso pode correr os programas dignos da arqueologia informática como o MBASIC ou o SuperCalc (!). Evidentemente, que se quer aceder a disquetes de 8 polegadas no Linux, isso já é outro problema totalmente diferente.

Por hora foram implementados mais funções do d3d10core.dll no Wine 1.7.39, mas ainda o suporte a jogos que usam exclusivamente o DirectX 10 é experimental.
Para produtoras que usam o código-fonte, portar é actualmente possível, o jogo "Bioshock Infinity" que o diga!

Agora, o Wine Staging 1.7.39 para além dos patches e melhorias do costume, também acrescentou outra funcionalidade importante: Uma gestão inteligente das chamadas de sistema do WineServer, evitando o quando possível para operações triviais que acabam por ter uma quebra de performance grave. No entanto só vai funcionar com kernels superiores à versão 3.17... 

Embora os smartphones e tablets Android e/ou iOS já atiraram as calculadoras dedicadas para a extinção, ou resguardadas para usos muito restritos (a curto prazo) devidos às regras de uso em exames, isto não impediu que dois professores franceses arriscassem a projectar e lançar o protótipo de uma calculadora gráfica usando estritamente software livre. 

http://www.librecalc.com/

Na realidade não foi a primeira tentativa, mas muitas delas nem passaram de uma ideia infrutífera. O que destinge neste caso é que conseguiram criar um protótipo funcional e algum software testável 

Internamente, o LibreCalc é um mini-tablet com ecrã LCD de 3" a cores, com um teclado customizado, duas portas mini-USB, controlado por um processador com potência similar aos primeiros smartphones Android (2008 ).
A CPU escolhida foi o i-MX233 com um clock de 454 MHz com suportes a interfaces LCD, RAM e Flash ROM.
O total de RAM é de 128 Mb (2 chips de 64 cada um), e cerca de 256 Mb de Flash ROM (Os protótipos usam um SD card para o software).

Quanto ao software a escolha foi o sistema operativo Linux  , embora utilizando nos primeiros estágios a distro Debian Wheezy. O bootloader escolhido foi o U-Boot configurado de forma a dispensar o uso do initramfs.
Futuramente, poderão usar um Linux From Scratch para minimizar o espaço ocupado pelo sistema operativo na memória interna da calculadora. (O uso do Linux era mais que justificado, por já operar com o hardware sem precisar de modificar nada, excepto três patches para o LCD, teclado e chipset embutidos no kernel.)
De qualquer forma, o GNU C compiler e o Python estarão presentes na distro minimalista do LibreCalc, como se verifica nos vídeos publicados no site do projecto. 
Uma das decisões dos autores do projecto foi a dispensa do X11 Window Server na calculadora, por considerar um exagero uma máquina embebida de baixa capacidade computacional arcar com um sistema gráfico típico de um computador pessoal. Além disso o seu uso final não recomendava o uso do XFCE ou do Unity numa máquina tão fraca.
 Portanto, usaram o DirectFB por ser minimalista e simples (um simples driver de frame-buffer gráfico!) e ser suportado pela biblioteca SDL, por este dispensar o uso do X11 e ter um front-end para o DirectFB.

 Resumindo, todo o software do Librecalc que utilize gráficos utilizará o SDL, o que acabará por compensar em muitos aspectos, embora a ausência de toolkits e frameworks (dependentes do X11, Mir, Wayland, etc) seja atenuada com o facto das dimensões reduzidas do ecrã, pois todos os programas irão correr em ecrã-cheio. O Python para programas gráficos também pode usar exclusivamente o SDL, eliminando as dependências do X11.
 O software de cálculo simbólico escolhido como base foi o venerável Maxima (Escrito em LISP  ), e as poucas e reais dependências com gráficos podem ser satisfeitas com o  SDL, e é aí que os dois autores do LibreCalc estão a trabalhar neste quesito. (Pelo menos alguma coisa realmente nova, e não um patchset de algo existente).
 Por decisão própria dos professores, também criaram como teste, o seu primeiro programa verdadeiramente autónomo que funciona dentro da mini-distro Linux do LibreCalc, que é um simulador da TI-83.
 Na verdade é uma implementação vis-a-vis do funcionamento do software da calculadora TI-83 de alto nível, pois limitaram a imitar superficialmente os menus e operações da verdadeira calculadora, mas não suporta Aplicações e Programas escritos em Z80 Assembly, tão-pouco certas opções avançadas não estão presentes. A vantagem é que lê e escreve os ficheiros 83p contendo os programas escritos em TI-Basic, desde que não contenha comandos não-suportados.
 Também suporta algumas funções de ploting gráfico e o uso como calculadora científica normal.
 Este programa pode ser compilado e testado num computador, bastando ter o pacote libsdl1.2-dev (usa apenas o SDL), se bem que o layout do teclado possa dar problemas (foi já pensado no teclado LibreCalc e isto está hard-coded) como uso sério.
 Escusado será dizer que a Linha de Comandos está sempre disponível, e contêm ainda alguns comandos básicos. Provavelmente, a prazo, restringirão as versões básicas contidas na busybox, por estas serem mais que suficientes para inicializar o sistema operativo, carregar o shell em SDL e gerir os scripts de arranque, para abrir o menu de utilizador e usufruir do sistema.

 Em geral, com estas escolhas, mesmo com uma CPU igual a um Pentium II low-end  , o sistema operativo Linux arranca em apenas dois segundos, e demora mais dois para abrir o menu principal (3 a 4 segundos), o que já é bem satisfatório, comparado com os 45 segundos que uma Ti-Nspire demora a fazer um full-boot ou 3 segundos que uma Casio ClassPad demora a fazer.

Instale os drivers da NVidia e caso continue a indicar um valor incorrecto para a memória de vídeo tente abrir a opção do PlayonLinux relativa à configuração e na aba "Mostrar" em Configuração, escolha um tamanho adequado para a "Memória Gráfica".
Isto ocorre devido a uma falha na determinação da quantidade de memória gráfica.