A HP deixou de vender novas licenças do HP Anyware a 7 de maio de 2026. O que a sua equipa está a substituir não é bem um protocolo. É uma arquitetura em que nada tinha de ser instalado em nenhum equipamento do utilizador.
O Kasm Workspaces devolve exatamente essa propriedade. Entrega ambientes de trabalho e aplicações Linux em contentores e também consegue intermediar ambientes Windows já existentes, tudo num navegador moderno e sem software cliente no equipamento. Consegue ainda passar uma GPU NVIDIA às sessões em contentor Linux, e instalei-o num VPS com GPU numa tarde.
Não é uma escolha automática para gradação de cor crítica ou verificação CAD, porque o Kasm não documenta um modo 4:4:4 selecionável comparável ao do HP Anyware. Os limites relevantes, a linha de decisão e a configuração da GPU estão abaixo.
A versão curta
O Kasm Workspaces é um substituto genuíno do HP Anyware para equipas cujo requisito inegociável é não ter software cliente: entrega ambientes Linux em contentores e consegue intermediar ambientes Windows para um navegador, enquanto as suas sessões em contentor Linux suportam aceleração por GPU NVIDIA. O Kasm não documenta um modo 4:4:4 selecionável comparável ao do HP Anyware, por isso as equipas que trabalham com cor devem validar a carga de trabalho real e comparar a via sem perdas do Amazon DCV antes de migrar.
- As datas com que deve planear: a venda de novas licenças HP Anyware terminou a 7 de maio de 2026. As renovações de um ano continuam disponíveis até 31 de outubro de 2027, enquanto a manutenção e o suporte dos contratos plurianuais existentes podem prosseguir até 31 de outubro de 2029.
- O que o Kasm devolve é um acesso nativo pelo navegador sem nada instalado no equipamento, exatamente a propriedade que os zero clients do HP Anyware ofereciam.
- A aceleração por GPU funciona, com condições: hardware NVIDIA compatível com CUDA, o NVIDIA Container Toolkit e uma GPU por contentor para cargas gráficas.
- O compromisso do streaming: a via padrão do Kasm usa JPEG/WebP nativos do navegador, enquanto o seu modo sem perdas opcional foi pensado para redes locais de elevada largura de banda.
- O limite de licenciamento: a Community Edition está limitada a cinco sessões simultâneas e exclui o uso comercial, por isso as equipas empresariais devem orçamentar Starter ou Enterprise desde o primeiro dia.
- A divisão: os fluxos de trabalho Linux e de contentores pensados para o navegador encaixam no Kasm, as equipas que trabalham com cor devem comparar o Amazon DCV, e as equipas muito centradas em Windows devem testar a via de espaços de trabalho de servidor do Kasm antes de avançar.
O Que Este Guia Não Cobre
Alguns temas adjacentes ficam deliberadamente fora do âmbito para que isto continue a ser um guia de instalação e avaliação:
- O funcionamento interno do protocolo PCoIP, tratado na comparação dos protocolos PCoIP e RDP da Cloudzy.
- O detalhe do licenciamento empresarial do NICE DCV para além da distinção entre AWS e fora da AWS.
- O VMware Horizon e o Citrix VDI, que servem outra escala de implementação e outro comprador.
- A criação de espaços de trabalho Windows em contentor, que merece um guia próprio.
O que termina com o HP Anyware e o que fica para trás
7 de maio de 2026 foi o último dia em que a HP vendeu uma nova licença Anyware. O aviso de fim de vida da HP para o Anyware indica que as renovações de um ano continuam disponíveis até 31 de outubro de 2027, que o suporte a essas renovações termina a 31 de outubro de 2028, e que a manutenção e o suporte dos contratos plurianuais existentes podem prosseguir até 31 de outubro de 2029. Aos Trusted Zero Clients e ao Desktop Access aplicam-se datas distintas, por isso verifique o seu contrato e a sua linha de produto em vez de tratar 2029 como data de suporte universal.
A HP apresenta a decisão sem rodeios:
«Após uma reflexão cuidadosa sobre as nossas prioridades de investimento no portefólio, tomámos a difícil decisão de descontinuar certas áreas das nossas soluções de ambiente de trabalho remoto.» - Anúncio de fim de vida do HP Anyware
A HP indica ainda que o HP Z Remote Graphics Software (RGS) continuará disponível para determinados casos de uso em estações de trabalho.
A arquitetura de cliente zero continua a ser a referência útil: os utilizadores chegam a uma estação de trabalho remota sem manter um cliente de software completo em cada equipamento. Para um olhar mais atento à camada de transporte, o guia da Cloudzy sobre como o PCoIP transmite um ambiente de trabalho remoto explica o modelo baseado em píxeis.
Como o Kasm entrega um ambiente de trabalho através do navegador

Para um espaço de trabalho em contentor, o Kasm arranca um contentor Linux isolado a partir de uma imagem registada e transmite o seu ambiente de trabalho ou aplicação para o navegador.
É esse modelo de contentores que faz o padrão de ambiente de trabalho remoto no navegador sobre VPS com GPU funcionar de forma limpa, e é a parte que mais me interessa enquanto pessoa que tem de o manter a funcionar. Nos espaços de trabalho em contentor, cada sessão é descartável, reproduzível e definida por uma imagem. Corrige a imagem e todos os ambientes em contentor que a sua equipa abrir amanhã usarão a imagem atualizada. É este o argumento da manutenção e, numa implementação de cinquenta lugares, é a razão inteira para escolher esta arquitetura. A visão geral de ambientes de trabalho remotos do Kasm descreve o acesso pelo navegador sem agente, extensão ou software no equipamento e explica que é possível transmitir ambientes Windows tradicionais a par de ambientes Linux.
A aceleração por GPU é acrescentada no runtime de contentores, não no protocolo de visualização. O guia atual de aceleração por GPU do Kasm exige uma placa NVIDIA compatível com CUDA, controladores NVIDIA atuais e o NVIDIA Container Toolkit em cada anfitrião de agente. Para aceleração gráfica, o Kasm atribui uma GPU a um contentor; várias GPU por contentor ficam reservadas a cargas não gráficas.
Na rede, a via padrão do Kasm usa JPEG/WebP nativos do navegador, enquanto o seu modo sem perdas opcional usa QOI. Ambos importam, porque é no codificador que o Kasm e o HP Anyware se separam.
A plataforma pode ser alojada por si ou adquirida como serviço alojado. Tudo o que se segue assume que é você a executá-la.
Onde o Kasm fica aquém do HP Anyware
Vale a pena conhecer quatro limites antes de aprovisionar seja o que for. Nenhum é secreto, todos estão documentados, e um deles põe fim à avaliação para certas equipas, ao passo que os restantes apenas deslocam uma linha para um orçamento, um calendário ou um requisito de hardware.
O Kasm não documenta um modo 4:4:4
O PCoIP Ultra pode usar YUV 4:4:4 para todo o detalhe de croma, mas a disponibilidade depende do anfitrião, do cliente, da GPU e do modo de otimização escolhido. O guia de planeamento de sessões PCoIP Ultra da HP assinala que as políticas PCoIP podem configurar o NVENC em YUV 4:4:4 ou YUV 4:2:0 consoante a configuração. A via padrão nativa do navegador do Kasm usa JPEG/WebP, enquanto o seu modo QOI sem perdas opcional se destina a redes locais de elevada largura de banda. O Kasm não documenta um modo 4:4:4 selecionável diretamente comparável ao do HP Anyware.
O guia atual de codificação sem perdas do Kasm diz que 1920x1080 a 60 fps com movimento moderado consumirá provavelmente uma ligação gigabit inteira e que muitos CPU x86_64 de quatro núcleos posteriores a 2014 aguentam cerca de 1000 Mbps de descodificação. Isso torna o modo prático sobretudo numa LAN; não substitui testar a fidelidade de croma numa ligação doméstica.
Exige testes com a carga real: gradação de cor crítica, provas de impressão e verificação CAD, onde o píxel é o entregável. Se a fidelidade de croma verificável for contratual, trate a ausência de um modo 4:4:4 documentado como bloqueio até que os testes provem o contrário.
A partilha de GPU multi-inquilino exige MIG
As orientações atuais do Kasm sobre GPU tornam explícito o aviso de segurança:
«A segurança da aceleração por GPU em contentores multi-inquilino não está bem estabelecida.» - Documentação de GPU do Kasm Workspaces
A mesma página pede que a funcionalidade seja usada com cautela e com plena compreensão das implicações de segurança, e aponta o NVIDIA MIG, suportado a partir do Kasm Workspaces 1.19.0, como a única forma segura de partilhar uma GPU entre vários utilizadores. O Kasm também pode sobrecarregar uma placa forçando o número de GPU que um agente reporta, o que deixa vários contentores partilhá-la, mas isso é uma alteração de escalonamento e não uma fronteira de isolamento.
Desqualifica: implementações com GPU partilhada em que os inquilinos não confiam uns nos outros e hardware compatível com MIG não está em cima da mesa, ou em que um regulador lhe pedirá que justifique a fronteira de isolamento.
A Community Edition para nas cinco sessões simultâneas
A matriz de edições atual do Kasm apresenta a Community Edition como gratuita, limitada a cinco sessões simultâneas e sem direitos de uso comercial. A Starter surge a 10 $ por utilizador nomeado ou 20 $ por sessão simultânea, enquanto o preço da Enterprise é sob consulta. Verifique os valores atuais na matriz antes de construir um orçamento em cima deles.
O limite de sessões não é a única fronteira. Uma equipa empresarial de cinco pessoas continua a precisar de um escalão comercial, mesmo que nunca ultrapasse cinco sessões simultâneas. O Kasm posiciona a Starter para implementações auto-alojadas abaixo de 25 utilizadores ou sessões e a Enterprise acima desse limiar.
Para as empresas, isto coloca uma licença paga no orçamento logo no primeiro dia.
O Windows usa um espaço de trabalho de servidor, não um contentor
O Kasm consegue entregar ambientes de trabalho e aplicações Windows através de servidores estáticos, servidores com escalamento automático, RDS ou Azure Virtual Desktop. A visão geral do suporte a Windows do Kasm trata-os como espaços de trabalho de servidor, não como contentores Windows descartáveis. Se a sua estação de trabalho remota existe porque três pessoas precisam de uma aplicação de engenharia que só há em Windows, faça o protótipo exatamente dessa via antes de mexer no trabalho com contentores GPU Linux mais abaixo. É o ramo com maior probabilidade de mudar a arquitetura, por isso teste-o enquanto desistir ainda é barato.
Implicação: as equipas muito centradas em Windows devem começar por prototipar a via de espaços de trabalho de servidor.
A minha leitura destes quatro pontos: o teto de concorrência e a via Windows são questões de licenciamento e de calendário que se conseguem planear. A partilha de GPU multi-inquilino passou a ter uma resposta documentada no MIG, tornando-se uma questão de hardware e de versão. A fidelidade de cor é o limite verdadeiramente arquitetural e não se moverá sem outro modelo de entrega ou sem provas dos seus próprios testes.
Kasm, NICE DCV e HP Anyware lado a lado
A AWS mudou o nome de NICE DCV para Amazon DCV. A visão geral de funcionalidades e preços do Amazon DCV documenta o seu cliente HTML5, a compressão de qualidade sem perdas, a partilha de GPU em Linux e a regra de que o uso em EC2 não tem custo adicional de servidor DCV, ao passo que outras implementações exigem licença. Eis como os três se posicionam nos eixos que decidem uma migração.
| Eixo | Espaços de Trabalho Kasm | NICE DCV | HP Anyware |
|---|---|---|---|
| Exige instalar cliente | Nenhuma no equipamento | Cliente nativo ou cliente HTML5 no navegador | Cliente zero / cliente fino |
| Acesso nativo pelo navegador | Sim, qualquer navegador moderno | Sim, cliente HTML5 | Através de hardware de cliente zero |
| Aceleração por GPU | NVIDIA através do runtime de contentores, uma GPU por contentor gráfico, MIG para partilhar uma placa | Sim, incluindo partilha de GPU em servidores Linux | Sim |
| Fidelidade de cor | JPEG/WebP padrão, modo sem perdas opcional, nenhum modo 4:4:4 documentado | Compressão de qualidade sem perdas quando a rede e o CPU o permitem | O PCoIP Ultra suporta YUV 4:4:4 em configurações compatíveis |
| Modelo de licenciamento | Community: 5 sessões simultâneas, uso não comercial, escalões empresariais pagos | Sem custo na AWS EC2, licença obrigatória noutros locais | Vendas novas terminadas, renovações limitadas |
| Alojado por si fora da nuvem | Sim, totalmente | Sim, com uma licença adquirida | Sim |
| Disponibilidade atual | Disponível | Disponível | Sem vendas novas, datas de suporte variáveis por contrato até 2029 |
| Entrega de Windows | Espaço de trabalho de servidor estático ou com escalamento automático, RDS ou AVD | Instalação nativa no servidor | Agente PCoIP nativo |
A tabela não abrange o peso operacional, e é essa diferença que decide muitas migrações. O Kasm pede que pense em imagens de contentor e num registo de espaços de trabalho. Isso é confortável se já usa Docker e estranho se não. O Amazon DCV pede que pense em instalações de servidor e, fora da EC2, num servidor de licenças. Se a sua decisão depende também de agrupar ambientes ou manter uma máquina por utilizador, a distinção entre VDI agrupado e VM autónomas é a próxima questão de arquitetura.
Qual encaixa na sua equipa
Percorra a decisão por esta ordem, porque o primeiro ramo elimina mais gente.
3D com cor crítica, verificação CAD ou gradação VFX. Compare primeiro o Amazon DCV e orçamente a licença flutuante fora da EC2. A AWS indica que na EC2 não há custo adicional de servidor DCV e que outras implementações exigem licença. Continua a ser a despesa certa quando a precisão de croma testada é o produto.
Zero instalação de cliente como requisito inegociável, com cargas de trabalho do tipo ambientes de desenvolvimento, aplicações de escritório e produtividade, ou ferramentas criativas servidas pelo navegador. Vá de Kasm. É o caso em que recupera a simplicidade no equipamento que o HP Anyware lhe dava, com aceleração por GPU à mistura. Valide a nitidez do texto, o movimento e a latência de entrada com utilizadores reais antes de alargar o piloto.
Uma licença HP Anyware Pro já existente e vontade de seguir a via da própria HP. Veja o HP RGS, que a HP diz que oferecerá como alternativa a certos clientes do HP Anyware. Verifique o suporte atual de plataformas cliente na documentação do HP RGS face ao seu parque real antes de avançar, sobretudo se a sua frota for mista.
Ficar como está durante a janela de renovação. É uma escolha legítima, não uma tática de adiamento. As datas de renovação e suporte acima dão-lhe uma janela de compra delimitada e uma cauda de suporte mais longa. Se a sua equipa está a meio de um projeto, comprar estabilidade enquanto faz o protótipo em condições é defensável. Planeie o protótipo pela data de suporte efetiva do seu contrato, não pela data mais alargada do aviso da HP.
Os serviços geridos como o Splashtop e o Parsec são a quinta opção e ficam aqui excluídos de propósito: cada um exige software cliente ou um intermediário na nuvem, exatamente a propriedade de que esta migração tenta escapar.
Instalar o Kasm com aceleração por GPU num VPS
Use uma de duas vias. A imagem Kasm Workspaces de um clique da Cloudzy apresenta atualmente o Kasm 1.17 sobre Ubuntu Server 24.04 LTS; se a escolher, salte a secção «Instalar o Kasm Workspaces» mais abaixo. Num VPS com GPU da Cloudzy acabado de criar, use a sua imagem Ubuntu/CUDA e siga a via de instalação manual do Kasm 1.19 apresentada a seguir. Em qualquer dos casos, verifique a versão do Kasm instalada e a pilha NVIDIA antes de ativar sessões com GPU.
Pré-requisitos
A GPU, as versões de software do anfitrião e o armazenamento disponível são as principais restrições. O resto é um anfitrião Linux suportado e comum, com espaço para os serviços do Kasm e para cada sessão.
- Uma GPU NVIDIA compatível com CUDA no anfitrião que vai desempenhar o papel de agente do Kasm.
- Ubuntu 24.04 LTS, que é o alvo documentado principal do Kasm para a via de GPU.
- Acesso root ou sudo.
- A página de requisitos de sistema do Kasm 1.19 especifica 2 núcleos de CPU, 4 GB de RAM e 75 GB de armazenamento SSD para a plataforma, mais os recursos atribuídos a cada sessão; a alocação predefinida de um espaço de trabalho é de 2.768 MB e 2 núcleos.
- Um navegador moderno. É esse o requisito inteiro do lado do cliente.
Instalar o Kasm Workspaces
O Kasm publica um pacote de instalação versionado e a respetiva soma de verificação. O guia de instalação em servidor único do Kasm 1.19 usa esta sequência padrão de instalação online:
cd /tmp
curl --fail-early -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0-latest.tar.gz -fO https://kasm-static-content.s3.amazonaws.com/kasm_release_1.19.0-latest.tar.gz.sha256sum
sha256sum --check kasm_release_1.19.0-latest.tar.gz.sha256sum
tar -xf kasm_release_1.19.0-latest.tar.gz
sudo bash kasm_release/install.sh
O instalador mostra no fim as credenciais de administrador e de utilizador. Guarde-as e depois abra a aplicação web na porta 443.
Instalar o controlador NVIDIA e confirmar a placa
Execute o nvidia-smi antes de instalar seja o que for. As imagens de VPS com GPU da Cloudzy já incluem controladores NVIDIA e CUDA. Se o comando indicar a placa, mantenha o controlador existente e salte o bloco de instalação a seguir. O Kasm avisa que misturar métodos de instalação de controladores pode impedir o anfitrião de arrancar, por isso use este bloco apenas num anfitrião Ubuntu 24.04 limpo e sem um controlador NVIDIA funcional.
nvidia-smi
sudo apt update
sudo apt install -y software-properties-common ubuntu-drivers-common
sudo add-apt-repository ppa:graphics-drivers/ppa -y
sudo apt update
sudo ubuntu-drivers install
sudo reboot
nvidia-smi
Para as imagens de espaços de trabalho de IA do Kasm, o seu guia de GPU indica 560.28.03 como mínimo. Esse número segue o formato de versão de controlador da NVIDIA, por isso compare-o com o campo Driver Version do nvidia-smi e não com o campo CUDA Version separado.
Dica profissional: confirme o nvidia-smi no anfitrião antes de mexer em qualquer definição de GPU do Kasm. O alinhamento entre controlador e container toolkit é o pré-requisito dos espaços de trabalho com GPU, e confirmar a placa primeiro ao nível do anfitrião elimina toda uma classe de ambiguidades mais à frente.
Instalar o NVIDIA Container Toolkit
O NVIDIA Container Toolkit é distinto do CUDA. O bloco condicional a seguir só o instala quando o nvidia-ctk está ausente e depois configura e reinicia o Docker:
if ! command -v nvidia-ctk >/dev/null 2>&1; then
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update && sudo apt install -y nvidia-container-toolkit
fi
sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker
Confirme que o runtime chega mesmo à GPU a partir de dentro de um contentor:
sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi
Deverá ver a mesma informação de GPU e de controlador a partir de dentro do contentor. Se este comando falhar, pare: nenhuma definição de espaço de trabalho do Kasm vai corrigir um runtime de contentores que não vê a placa.
Ativar a GPU num espaço de trabalho e verificá-la

Na consola de administração, escolha uma imagem de ambiente de trabalho que suporte a pilha gráfica necessária, defina GPU Count como 1 e confirme que o agente reporta a GPU. Para aceleração gráfica, o Kasm atribui uma GPU ao contentor; várias GPU por contentor destinam-se a cargas não gráficas.
Um contador de GPU só prova a atribuição do dispositivo. Numa imagem de ambiente de trabalho compatível que inclua o VirtualGL e o glxinfo, verifique tanto o acesso a partir do contentor como o renderizador OpenGL:
nvidia-smi
vglrun -d "${KASM_EGL_CARD}" glxinfo -B | grep -i "OpenGL renderer"
O primeiro comando confirma que o contentor vê a placa. O segundo deve indicar a GPU NVIDIA como renderizador OpenGL.
Se o renderizador indicar um rasterizador por software como o llvmpipe, se a KASM_EGL_CARD não estiver definida, ou se a sessão abrir com ecrã preto, volte a verificar a compatibilidade da imagem, o controlador do anfitrião, o runtime de contentores, a deteção de GPU pelo agente e o número de GPU do espaço de trabalho. Um resultado bem-sucedido do nvidia-smi não prova por si só que o VirtualGL está a renderizar na GPU.
Dica profissional: percorra as verificações por camadas: nvidia-smi no anfitrião, nvidia-smi dentro de um contentor Docker simples com --gpus all, a deteção de GPU pelo agente no Kasm e depois vglrun glxinfo dentro do espaço de trabalho. A primeira camada que falha é a que há para corrigir.
É o passthrough de GPU que decide onde isto corre. Um VPS comum, só com CPU, não expõe qualquer placa CUDA física, por isso comece por uma instância com GPU. Os planos de VPS com GPU da Cloudzy usam passthrough dedicado e imagens Ubuntu prontas para CUDA; o inventário e os escalões de VRAM podem mudar, por isso dimensione a partir da página de planos em direto em vez de fixar pressupostos de 24 GB ou 48 GB. A imagem Kasm de um clique e o plano com GPU são vias de implementação distintas, por isso confirme a imagem escolhida, a versão do Kasm, o controlador e o toolkit antes de lançar sessões.
Assim que as verificações de GPU por camadas passam, a parte difícil fica para trás. A partir daí, o trabalho é manter imagens de espaços de trabalho e um registo, em vez de aplicar patches a uma frota de ambientes individuais. É uma troca que aceitaria em qualquer equipa que tenha liderado.
Conclusão: o Kasm substitui o fluxo de trabalho pensado para o navegador
O Kasm encaixa melhor quando o requisito é acesso apenas por navegador a ambientes ou aplicações Linux descartáveis, com aceleração por GPU opcional. Não é um substituto direto de todas as instalações do HP Anyware: o Windows usa uma via de espaço de trabalho de servidor, o uso comercial exige um escalão pago, a partilha de GPU multi-inquilino exige hardware compatível com MIG, e as equipas que trabalham com cor devem validar a fidelidade ou comparar o Amazon DCV.
Construa o piloto a partir da carga de trabalho mais difícil. Teste a aplicação que só existe em Windows, a janela sensível à cor ou a fronteira de segurança da GPU partilhada antes de migrar os utilizadores mais fáceis. Se isso passar, a entrega pelo navegador do Kasm e a manutenção baseada em imagens podem eliminar boa parte da carga nos equipamentos que tornava os zero clients atrativos.
Perguntas frequentes
Para que serve o Kasm Workspaces?
O Kasm Workspaces é uma plataforma de espaços de trabalho entregues pelo navegador. Executa ambientes e aplicações Linux em contentores e consegue intermediar servidores Windows, Linux e macOS já existentes através de espaços de trabalho de servidor. As sessões em contentor podem ser descartadas e recriadas a partir de uma imagem, ao passo que os espaços de trabalho de servidor mantêm o ciclo de vida do anfitrião subjacente.
O Kasm Workspaces suporta aceleração por GPU?
Sim. O Kasm suporta aceleração por GPU da NVIDIA através do NVIDIA Container Toolkit. Para aceleração gráfica, é atribuída uma GPU a um contentor; as cargas de computação não gráficas podem usar várias. O anfitrião precisa de um controlador NVIDIA compatível, do runtime de contentores, da deteção de GPU pelo agente e de um espaço de trabalho configurado com um número de GPU.
O Kasm Workspaces é gratuito?
A Community Edition é gratuita para uso individual, sem fins lucrativos e não comercial, e está limitada a cinco sessões simultâneas. As equipas comerciais devem usar a Starter ou a Enterprise; o Kasm indica atualmente a Starter a 10 $ por utilizador nomeado ou 20 $ por sessão simultânea, para implementações auto-alojadas com menos de 25 utilizadores ou sessões.
O Kasm Workspaces consegue executar Windows?
Sim. O Kasm consegue transmitir ambientes e aplicações Windows através de espaços de trabalho de servidor estáticos ou com escalamento automático, RDS e Azure Virtual Desktop. É uma arquitetura diferente dos contentores Linux descartáveis do Kasm, por isso as equipas cujo requisito central é software que só existe em Windows devem prototipar exatamente essa via antes de avançar.
Para uma estação de trabalho remota, é melhor o Kasm ou o NICE DCV?
Depende de qual é o requisito inegociável: acesso apenas por navegador ou fidelidade de imagem validada. O Amazon DCV é a primeira comparação mais forte para trabalho em que a cor é crítica, porque documenta compressão de qualidade sem perdas quando as condições de rede e de processador o permitem. O Kasm encaixa melhor quando a prioridade é o acesso pelo navegador sem software no equipamento e os espaços de trabalho Linux definidos por imagens.

Discussão
Comentários
Inicie sessão para participar na discussão.