A virtualização é de longe a mais simples.
No entanto, você tem 2 casos de uso separados aqui, que terão soluções diferentes
1. Experimente novas distribuições
As distribuições são basicamente determinadas pelos aplicativos empacotados e pelo ambiente do espaço do usuário (por exemplo, SystemD
vs init
para inicialização)
Se você deseja "avaliar" o UIX de uma distribuição diferente, qualitativamente, eu recomendaria a virtualização completa em que você instala o sistema operacional na íntegra e avalia sua usabilidade. Isso é coberto adequadamente em outras respostas.
Se você simplesmente precisar do ambiente do espaço do usuário para teste, continue lendo.
2. Testes e "instâncias descartáveis" em diferentes ambientes
É mais fácil, mais barato e mais rápido usar a conteinerização, uma forma de virtualização leve que usa o kernel para criar ambientes em área restrita.
Um contêiner compartilha recursos do kernel com o Host, mas, de outra forma, possui seu próprio sistema de arquivos raiz, espaço do usuário, pilha de rede etc. Ele pode ser pensado, conceitualmente, como um chroot
esteróide. No entanto, como o kernel é compartilhado, a virtualização é "reduzida", o que significa que, para fins mais práticos, ele é executado na mesma velocidade que o sistema operacional host.
Existe um sistema de contêiner comumente usado chamado docker
. O Docker padronizou imagens para praticamente todas as distribuições de linux que você gostaria e é executado no Windows (no entanto, as imagens do Windows funcionam apenas no Windows, as imagens do Linux funcionam em ambos). Possui recursos úteis adicionais para economizar espaço e desempenho.
Existem também alternativas nativas de código aberto para Linux, como o LXC
(que está embutido no kernel!), Que podem ser usadas da mesma forma (mas com mais configuração necessária).
Exemplo simplificado de um ambiente de teste ou construção em docker
# Dockerfile
FROM ubuntu:17.10
RUN apt-get update && apt-get install -y build-essential
WORKDIR /workdir
docker build --tag my-builder .
Em seguida, na linha de comando, compile seu projeto ou testes nesse ambiente de várias maneiras
"faça login" e compile no ambiente, execute testes etc. Supondo que você esteja no diretório de origem do seu projeto
$ docker run -v "$PWD:/workdir" --rm -it my-builder /bin/bash
# echo "Now in docker container"
# make
...
# build/test/my-test
...
# exit
$ echo "Build artifacts are now on your host OS Directory :) "
Use como único
$ docker run -v "$PWD:/workdir" --rm my-builder make
Você pode até passar variáveis de ambiente
$ docker run -e "CROSS_COMPILE=arm-linux-gnueabi" -v "$PWD:/workdir" --rm my-builder make
Ou inicie uma instância persistente e copie os arquivos explicitamente
$ Start our instance in background
$ docker run --name my-builder-inst -d my-builder
$ echo "Copy files to instance"
$ docker cp /my/source/dir my-builder-inst:/workdir
$ echo "run project build"
$ docker exec my-builder-inst make
$ echo "copy build artifacts"
$ docker cp my-builder-inst:/workdir/build /my/output/dir
$ echo "destroy and delete container"
$ docker rm -f my-builder-inst
Existem literalmente centenas de outros padrões de uso, no entanto, a definição de imagem semelhante a script, imagens extensíveis e uso de linha de comando o tornam extremamente atraente para ambientes de desenvolvimento, teste e até implantação