Você acha que sistemas operacionais gerenciados são uma boa ideia? [fechadas]

15

SOs gerenciados como Microsoft Singularity e JNode

No entanto, como uma desvantagem, você está muito mais distante do hardware e, como desenvolvedor, perde a capacidade de descer para um nível mais baixo de abstração e sujar as mãos.

Quais são suas opiniões sobre isso?

    
por Chinmay Kanchi 02.09.2010 / 23:50
fonte

8 respostas

8

Acho que esse é outro caso em que "depende".

Se você estiver escrevendo aplicativos como navegadores da web, processadores de texto, etc., em que o desempenho extremamente rápido não é necessariamente um problema, essa abordagem tem seus méritos. Ao usar essa abordagem, você pode oferecer aos seus clientes uma experiência mais segura e controlada. Você não apenas está limitando os danos que podem ser causados por malware, mas também está sendo executado em um ambiente mais consistente.

É como a diferença entre jogos de console e jogos de PC. Os primeiros sabem exatamente com qual hardware eles precisam trabalhar, então podem usar esse conhecimento, enquanto os últimos precisam lidar com uma variedade maior de placas gráficas, placas de som, velocidade de disco rígido, etc.

No entanto, haverá aplicativos (como jogos!) que exigem acesso de baixo nível e ainda precisam ser executados "nativamente".

Como os idiomas gerenciados, você terá que usar a ferramenta apropriada para o trabalho.

    
por 04.09.2010 / 13:49
fonte
3
Geralmente eu acho que eles são uma boa idéia, mas já que não há muitos deles por perto ou perto de serem totalmente preparados, é muito difícil dizer como eles se apresentarão no mundo real. Eu gostaria que a MS tivesse atualizado o projeto Singularity para que pudéssemos ver onde isso estava indo, mas meu palpite é que parte dele está sendo trabalhada em alguma versão do Windows

    
por 04.09.2010 / 14:10
fonte
3

Eu acho que os benefícios de um sistema operacional totalmente gerenciado são enormes e isso pode ser realmente o futuro, mas isso vai levar muitos anos.

Um bom sistema operacional gerenciado fornecerá a você todo o ponto de entrada gerenciado que você precisa para fazer qualquer coisa de baixo nível que precisar, independentemente de ser gerenciado: capturando interrupções e executando E / S com dispositivos. C # também permite códigos inseguros (lidando com ponteiros), mas só será permitido nos "drivers de dispositivo" (que será apenas outro tipo de processo isolado de software).

Os benefícios em segurança, uniformidade, portabilidade e especialmente confiabilidade certamente excederão qualquer desvantagem de desempenho. Em seguida, um sistema totalmente gerenciado é surpreendentemente rápido, pois não é mais necessário alternar o contexto.

    
por 04.09.2010 / 13:37
fonte
2

Os SOs gerenciados provavelmente são como microkernels - você sacrifica o desempenho em nome da segurança.

Pode haver problemas semelhantes, pois exige a divisão do código em duas partes:

  • Kernel de baixo nível escrito em C / assembler
  • Kernel de nível superior escrito em linguagem gerenciada

Dependendo do custo de entrada / saída em segurança, a linguagem HL pode impor problemas semelhantes aos microkernels - possivelmente um pouco mais rápido (deixando o HL mais rápido que o switch de contexto completo, mas o IIRC por exemplo JNI é bastante caro).

O aplicativo do usuário provavelmente também precisaria de contextos separados, pois muitos aplicativos são gravados em outras plataformas (digamos C, Java ou .Net). Nos mesmos casos, as aplicações podem estar ligadas à CPU (compiladores, conversores de música, etc.) e precisam mesmo de otimização do montador para executar com velocidade suficiente. Além disso - a proteção de MMU implementada na linguagem HL provavelmente não será tão rápida quanto a de hardware, mesmo que seja muito mais bem ajustada.

A linguagem HL também não é proficiente nas operações de baixo nível. Embora o software geralmente seja projetado com práticas de codificação "boas", os drivers não são necessários. Eu não acho que eles irão proteger contra pelo menos alguns erros, já que os kernels requerem, por vezes, o gerenciamento manual de memória.

Finalmente, não acho que esse SO exigiria VM completa. Como o sistema operacional não pode ser construído com princípio, as linguagens HL de compilação, uma vez executada em qualquer lugar (mesmo com GC & co), seriam melhores candidatos.

For example, you suddenly make arbitrary pointers obsolete.

O SO é inerentemente de baixo nível. Você passa para o hardware não apenas "ponteiro arbitrário", mas provavelmente endereço físico, em vez de virtual. Alguns DMA podem manipular apenas os primeiros 16 MiB de memória. Embora esse SO possa simplificar muito, ele não se livrará dos endereços.

And if well written, you get rid of a ton of legacy crud that most modern OSes currently have.

  1. Há muito hardware legado. Muito mais do que no software. Você primeiro começa no modo real, depois habilita o gate A20 (não pergunte) para o modo protegido e depois para o modo longo.
  2. Compatibilidade API / ABI é boa. Digamos que eles tenham escrito esse sistema operacional - o que você executaria nele? Firefox - nope (C e C ++ usando WinAPI). Java - provavelmente precisava ser portado ou ter alguns problemas menores via ikvm - a menos que aconteça o uso de JNI. Eu acho que MSSQL (e com certeza Oracle, MySQL, Postgresql ...) não está escrito em linguagem gerenciada, então não seria adequado para o servidor.
  3. Até mesmo a compatibilidade de erros é "boa". AFAIK MS gasta muito tempo apenas testando e verificando se algum software não está usando API de maneira inteligente (leitura incorreta). Como o problema de usar o ponteiro depois de free quando o Windows realmente começou a liberar memória.

Acho que ganhará popularidade na mesma época que os microkernels.

    
por 23.01.2011 / 04:07
fonte
2
Pessoalmente, acho que a ideia de um sistema operacional gerenciado é um pouco como o comunismo: bom na teoria, mas impraticável de implementar.

O problema é que eu simplesmente não vejo nenhuma maneira de trazer o SO gerenciado sem reescrever completamente o sistema operacional do zero (e espero que alguém possa provar que estou errado nesta parte). Além disso, como você faz décadas de código não gerenciado em um sistema operacional gerenciado?

Os núcleos dos sistemas operacionais mais populares são testados em batalha e amadureceram ao longo de algumas décadas. Você não simplesmente reescreve-os por um capricho. Sem mencionar que a história é repleta de exemplos de projetos de processadores e arquiteturas de kernel que eram inegavelmente melhores, mas nunca conseguiram convencer ninguém de que eles valiam o custo de mudar para eles.

Por último, como uma empresa como a Microsoft ou a Apple vai vender um sistema operacional gerenciado aos clientes? O usuário médio do computador se importará se seu sistema operacional for gerenciado ou não?

O texto acima, espero que esteja errado e que os sistemas operacionais gerenciados sejam uma realidade. Mas sou cético. Se alguma vez a virmos, provavelmente não será por mais uma ou duas décadas.

    
por 23.01.2011 / 04:17
fonte
2

O código gerenciado é apenas uma extrapolação do que a proteção de memória virtual compra para você hoje, ou seja, a capacidade do computador de negar acesso a recursos.

A IBM já faz isso em seus sistemas de mainframe (eles apenas chamam de outra coisa), então é na minha opinião apenas uma questão de tempo antes que isso aconteça em sistemas disponíveis para o público em geral.

Você se importaria se um Laptop do Google (que executa o Chrome e basicamente nada mais) fosse executado em código gerenciado ou não?

    
por 23.01.2011 / 13:21
fonte
1

However, as a disadvantage, you're that much farther away from the hardware, and as a developer, you lose the ability to drop down to a lower level of abstraction and get your hands dirty.

Isso não é realmente verdade. No JNode, por exemplo, há uma classe Unsafe (e outras) que permite acessar locais de memória e assim por diante. Existem também algumas classes / métodos "mágicos" que são traduzidos em instruções privilegiadas pelo compilador JIT. O acesso a essas classes / métodos é (ou será) restrito pelo gerenciador de segurança, pelo compilador JIT e assim por diante. Mas se você estiver escrevendo códigos que são executados no nível do sistema operacional, esses recursos estão disponíveis para você.

A ressalva é (é claro) que o uso incorreto de Unsafe e classes relacionadas pode levar a falhas do sistema operacional imediatamente ou ao longo do caminho.

    
por 23.01.2011 / 04:26
fonte
0

Eu duvido de sua utilidade para computadores desktop. Mas o tempo pode me provar errado neste ponto.

Mas um potencial interessante aos meus olhos é como um sistema operacional de servidor, mais especificamente como um sistema operacional convidado em um ambiente virtualizado. Nunca funcionou bem em mim instalar uma instalação completa do servidor Windows em um ambiente de servidor virtual, sabendo quantos serviços desnecessários ele executa, incluindo a GUI completa.

Agora, instalando algo como Singularity em um servidor virtual para hospedar aplicativos ASP.NET, isso faz mais sentido. Assumindo que eles podem manter um sistema operacional leve.

    
por 23.01.2011 / 00:15
fonte