Get best of the week

Para a questão do Linux (L)

Nós procedemos do fato de você ter um sistema operacional completo, pagando imediatamente por tudo. (Bill Gates, em resposta a uma pergunta sobre concorrência com L.)


Quanto mais eu aprendo sobre Linux, menos eu odeio a B.G.


Bem, na verdade, nunca senti sentimentos tão fortes por ele, estou apenas começando a entender melhor por que a empresa que produz o Windows gasta dinheiro. E fica mais claro por que os consumidores preferem pagar Bill (claro, existem opções aqui, você entende), em vez de usar a alternativa gratuita (“isto é, gratuita”). Mas vamos começar em ordem e considerar dois episódios de interação com L.

Recentemente, L tem funcionado nos dispositivos que desenvolvo (em uma ou outra de suas formas, bem, você entende ...), no âmbito do qual o software para fins especiais é executado. E assim, no processo de interação com dispositivos externos (teclados especializados), foram descobertos artefatos interessantes do comportamento do SO, o que levou aos pensamentos declarados na epígrafe.

Episódio um - durante a correção do programa do teclado USB, foi introduzido um defeito "acidental, não intencional" que levou à falha do descritor de string do dispositivo. Para aqueles que não estão muito conectados ao USB, a explicação necessária - um descritor de string - é uma parte opcional da descrição do dispositivo, destinada exclusivamente à visualização do tipo de dispositivo e do fabricante dos utilitários do sistema. No entanto, isso não é desculpa para programadores e esses erros não devem ser cometidos, mas tudo acontece na vida. Como um host executando um sistema operacional sadio reage se um dispositivo incorreto está conectado a ele?

Pessoalmente, vejo três estratégias possíveis:

  1. , , — , , 7, ;
  2. , , — ;
  3. , , — , , USB ( ).

PNP: Observe que o padrão para a interface apenas fornece a necessidade (Figura 8.31 na página 222), enquanto aguarda a mensagem de entrada, de controlar o tempo e processar o tempo limite, como um dos possíveis erros - repita a solicitação 3 vezes e, em seguida, dê um sinal sobre a falha da transação. Ações adicionais do host são determinadas pela implementação. Bem, pelo menos, não encontrei essas informações no padrão, embora isso não seja final.

Assim, os desenvolvedores de L não se limitaram às soluções que estavam na superfície e foram mais profundas, tendo encontrado uma maneira incomumente interessante e, não teremos medo dessa palavra, de maneira idiota muito criativa:

4. repita a solicitação várias vezes, após o esgotamento de marcar o dispositivo como defeituoso e depois desligá-lo .

Até agora, nada de criminoso, se não fosse por um pequeno detalhe (“e tudo o resto são nuances”) - enquanto o host L repete a solicitação acima, monopoliza o acesso via barramento (provavelmente o tempo limite no hardware não inicia ou a interrupção não é processada) e todos (!!!) outros dispositivos USB estão ociosos. Esse processo leva cerca de uma dúzia de segundos, durante os quais todos os dispositivos estão indisponíveis - já não são ruins. E aqui está a cereja no bolo - após tentativas exaustivas de ler o descritor de cordas no teclado errado, os pacotes geralmente param de chegar a ele, após 2 minutos, entende "algo deu errado" e tenta se apresentar ao host novamente reconectando, fazendo com que o processo se repita. Os resultados são compreensíveis - trabalhar com o barramento simplesmente não é possível se você não estiver pronto para usar o modo soluço.Uma solução incomumente original, mas essa (originalidade) é sua única vantagem.

Meus conhecidos do Linux, depois de demonstrar esse fenômeno, primeiro tentaram explicá-lo no estilo de "isso não é um bug, é um recurso" (ou melhor, no início eles, como eles aceitaram, sugeriram a reconstrução do kernel com os patches mais recentes, geralmente é uma resposta universal a qualquer mensagem na comunidade L sobre um possível erro) e disseram que, sim, o comportamento está incorreto, mas, provavelmente, em algum lugar nos arquivos de configuração da montagem, há um sinalizador, redefinição ou configuração que pode desabilitar esse comportamento do sistema. Se isso for verdade, o único nome para a caixa de seleção que posso oferecer é (em russo): "Eu realmente quero_OS_be_being_being_something_failing_string_descriptor_as_hysterichka", no estilo "Até que essa cadela me diga o nome dela, não pedirei a ninguém para falar com você", desculpe pelo meu francês. Bem, mesmo que este seja o caso, existe uma bandeira assim,Por padrão, o sistema operacional não deve ser coletado no modo normal, nem pervertido? Por alguma razão, o Windows faz exatamente isso. Obviamente, você deve examinar o texto de origem do host L (provavelmente, um driver USB específico) e determinar se existe esse sinalizador e como obter um comportamento semelhante do sistema, mas pelos motivos listados abaixo, isso não foi feito, por isso nos restringimos a afirmar o fato .

O segundo recurso (muito mais parecido com um erro, porque no primeiro caso, o dispositivo estava incorreto, o que enfatizei imediatamente) foi detectado após a correção do erro do programa do dispositivo e começamos a trabalhar mais.

O fato é que, no dispositivo projetado, havia dois controladores que implementavam as funções do joystick e do teclado, enquanto um processava o lado esquerdo do teclado e o segundo processava o direito. Mas um botão no painel frontal foi conectado aos dois controladores, uma vez que continha a marcação “FIRE” e os resultados da falha de um controlador seriam muito desagradáveis. Quando você clicou nesse botão, ambos os controladores produziram um símbolo de "espaço" e tudo ficou bem até que notamos que algumas vezes (~ 10% dos casos) após o lançamento do botão A, ele continua sendo considerado pressionado e o aplicativo entra no modo de disparo contínuo. Ao mesmo tempo, pressionar e abaixar o botão novamente retornou o sistema ao modo normal.

Foi sugerido que eventos espaçados (no tempo) do teclado possam ser ignorados; nesse caso, uma mensagem sobre o lançamento de um botão.

Além disso, várias etapas foram tomadas para determinar a causa do mau funcionamento, mas sua descrição vai além do escopo e do assunto deste post e (espero) será descrita separadamente. Mas o processo de descobrir as causas de um erro tão simples (à primeira vista) exigiu esforços que qualquer desejo de entender o motivo do primeiro bug descrito no post foi perdido.
Voltando à epígrafe, devo dizer que no Windows 7 esse defeito não foi observado por pelo menos 100 cliques, o que indica a estabilidade desse sistema operacional nesse fator. Novamente, eu não vi o código fonte, mas o comportamento do programa fala por si.

É improvável que as qualificações dos desenvolvedores do Windows excedam significativamente as da comunidade de código aberto, e a questão, aparentemente, é apenas um teste, que é realizado sem ambiguidade em um volume maior (e com maior qualidade), quando as pessoas que recebem dinheiro pelo trabalho estão envolvidas nele ( além da satisfação moral).

Eu tenho que admitir que o comportamento de A, pelo menos nas situações descritas, é melhor definido pela frase "funciona", que não pode ser considerada aceitável para um sistema operacional que afirma ser confiável e generalizado, e é por isso que minha atitude em relação a B.G. Como resultado deste episódio, ele melhorou, pois ele definitivamente não é o culpado pelo que está acontecendo (embora possa haver opiniões diferentes).

More articles:


All Articles