Lassi's questions

Ao expandir o /etc/passwd campo GECOS para obter o nome completo do usuário, devemos expandir apenas o primeiro e comercial ( &caractere) ou todos os e comerciais?

Em um campo GECOS com ,subcampos delimitados por vírgula ( ), o e comercial deve ser expandido apenas no primeiro subcampo (ou seja, o nome completo do usuário) ou em todos os subcampos?

Se o nome de usuário do Unix contiver letras maiúsculas, devemos preservá-las na &expansão ou devemos apenas capitalizar a primeira letra do nome de usuário e minúsculas o resto?

Existe uma maneira razoavelmente fácil de executar o NeWS (Network-extensible Window System, um sistema de janelas baseado em PostScript feito por pesquisadores da Sun na década de 1980) em computadores atuais?

Em sua página da web sobre o truque do tubo automático , Dan Bernstein explica uma condição de corrida select()e sinaliza, oferece uma solução alternativa e conclui que

Claro, a Coisa Certa seria ter fork()retornado um descritor de arquivo, não um ID de processo.

O que ele quer dizer com isso - é algo sobre poder select()nos processos filho manipular suas mudanças de estado em vez de ter que usar um manipulador de sinal para ser notificado dessas mudanças de estado?

Existe uma maneira de instalar apenas atualizações de segurança para o Alpine Linux e seus apkpacotes, ignorando atualizações que não corrigem falhas de segurança?

Eu escrevi algum software Linux/BSD de código aberto com uma interface de linha de comando e gostaria de saber se posso facilmente executá-lo no Solaris também. Quais seriam as opções fáceis (ou seja, tão fáceis quanto Linux/BSD) para instalar uma máquina virtual amd64 com Solaris ou um de seus derivados para pessoas que não sabem quase nada sobre Solaris?

Deve ter (fora da caixa ou facilmente instalável):

• conectividade com a internet
• cliente e servidor ssh
• bash ou zsh
• git
• alcatrão
• faço
• algum editor de texto melhor que o vi (vim ou um clone do emacs está bem)
• qualquer compilador e vinculador C é popular entre os programadores do Solaris (muitas pessoas usam o GCC hoje em dia?)
• Cabeçalhos C para libc, interface syscall do kernel e o que mais for normalmente necessário
• um gerenciador de pacotes fácil seria bom, mas se ele for fornecido com as coisas acima, tudo bem também

Existe uma maneira fácil de fazer com que as whoisconsultas do terminal tenham coloração de sintaxe na saída para que seja mais fácil de ler?

Algo básico como colorir NOT FOUNDem vermelho e nomes de campos e datas em cores diferentes já seria útil. Não importa se a coloração não for 100% precisa.

Por que ainda existem artefatos visuais quando os emuladores de terminal desenham aplicativos baseados em texto? Isso em computadores recentes que renderizam jogos 3D e janelas GUI, incluindo fontes vetoriais com suavização de serrilhado sem artefatos.

Vejo regularmente os seguintes artefatos que revelam etapas intermediárias do processo de atualização de tela:

• Movimento do cursor do terminal (o cursor pisca ou salta pela tela durante a atualização)
• Rasgando (parte da tela mostra coisas antigas enquanto outra parte mostra coisas novas)
• Rolagem (a rolagem é perceptível, em vez da nova posição de rolagem ser mostrada imediatamente)

Os artefatos são vistos apenas por intervalos de menos de um segundo, e não durante a maioria das atualizações de tela, mas tendo crescido em GUIs sem cintilação, eu ainda gostaria de saber como evitá-los. Todos os artefatos acima (exceto rolagem) podem ser vistos, por exemplo, no vídeo ASCIInema a seguir, uma vez que ele começa a desenhar as telas mais complexas: MapSCII - o mundo inteiro em seu console!

Também não estou falando especificamente sobre atualizações lentas. Seria bom se as atualizações fossem sempre instantâneas, mas isso nem sempre é possível devido a atrasos na rede e no processamento. O que quero dizer aqui é que telas parcialmente desenhadas geralmente são visíveis por um breve momento. Na maioria das GUIs modernas, apenas telas totalmente finalizadas são mostradas ao usuário, e artefatos de desenho parcial são muito raros.

É minha impressão que o pipeline de emulação de terminal é algo assim:

1. O usuário pressiona uma tecla no teclado
2. Kernel passa o pressionamento de tecla do driver do teclado para o sistema de janelas
3. O sistema de janelas passa o pressionamento de tecla para o emulador de terminal
4. O emulador de terminal passa o pressionamento de tecla para o dispositivo de kernel pseudoterminal (pty)
5. Pty interpreta o pressionamento de tecla e passa o resultado para o aplicativo baseado em texto
6. O aplicativo executa o comando em resposta ao pressionamento de tecla
7. O aplicativo renderiza uma nova tela (grade de células de caracteres) para o buffer interno
8. Chamadas de aplicativos cursesou outra biblioteca para converter a grade de células de caracteres em códigos de escape ANSI que renderizarão uma tela equivalente no terminal
9. A biblioteca grava esses códigos de escape ANSI no dispositivo pty
10. Pty processa os dados escritos de alguma forma
11. O emulador de terminal lê dados processados ​​de pty em alguns pedaços
12. O emulador de terminal chama o sistema de janelas para renderizar o resultado dos códigos de escape ANSI na janela do terminal

Qual das etapas acima pode retardar o processo o suficiente para que o emulador de terminal nos mostre etapas intermediárias de renderização em vez de mostrar apenas o resultado final?

• Parece que a velocidade dos terminais de hardware (conexões de porta serial) é ditada por sua taxa de transmissão, que pode ser alterada tcsetattr(), mas li em várias fontes que a configuração da taxa de transmissão não tem efeito nos dispositivos pseudoterminais (pty) usados ​​​​pelo terminal emuladores. Isso significa que os kernels Unix não limitam deliberadamente as comunicações pty?

• Os aplicativos ou bibliotecas de renderização (curses, etc.) enviam texto e códigos ANSI em várias gravações em vez de tentar se contentar com apenas uma write()?

• Os kernels Unix têm limites de tamanho em seus buffers de E/S internos, o que afeta coisas como a quantidade máxima de dados que podem ser enviados por um canal sem bloqueio. Isso afeta a renderização de telas de terminal com muitos detalhes (uma tela cheia de texto, muitas cores etc.)? Imagino que o texto combinado e os códigos de escape ANSI poderiam somar tantos dados que não cabem no buffer do driver pty, o que dividiria uma atualização de tela em várias operações de gravação pelo aplicativo e várias leituras pelo emulador de terminal. Se o emulador de terminal estivesse ansioso para exibir os resultados de cada leitura antes de processar a próxima, isso faria com que a exibição piscasse até que a leitura final em um lote fosse processada.

• Os emuladores de terminal ou drivers pty têm tempos limite deliberados para processamento em lote, de modo que seu comportamento imite mais de perto os terminais de hardware, pareça mais natural ou aborde alguma outra preocupação que foi considerada mais importante do que a velocidade de exibição?

Recentemente tem havido algum esforço para fazer novos emuladores de terminal que renderizem mais rápido (por exemplo, pré-renderizando fontes em texturas OpenGL na memória de vídeo). Mas esses esforços só parecem acelerar a renderização de uma grade de células de caracteres em um bitmap de tela uma vez que a grade foi calculada.

Parece haver algo mais acontecendo que torna essas coisas fundamentalmente lentas, mesmo em um computador muito rápido. Pense nisso: se o emulador de terminal processa todos os códigos ANSI para obter uma grade de células de caracteres antes de renderizar qualquer coisa em um bitmap de tela, então não importa quão lentas sejam as rotinas de renderização de grade de caracteres para bitmap - deve haver sem cintilação (pelo menos não o tipo de cintilação que claramente parece corresponder ao movimento do cursor em um terminal de hardware, que é o que vemos com frequência). Mesmo que o emulador de terminal levasse um segundo inteiro para desenhar qualquer grade de células de caracteres na tela, simplesmente teríamos um segundo de inatividade, não um segundo de cintilação.

Um problema semelhante é que o Unix cleare os resetcomandos são incrivelmente lentos para o que fazem (da perspectiva de um usuário de GUI, eles não fazem nada mais complexo do que redesenhar um bitmap). Talvez por motivos relacionados.

Existe alguma maneira de fazer o comando simples

sudo pkg_add some-package

trabalhar em uma instalação comum do NetBSD sem recompilar nada do código-fonte? Todos os outros sistemas Unix que experimentei fornecem um comando equivalente pronto para uso com pouco esforço.

O melhor que consegui pensar foi adicionar

export PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/$(uname)/$(uname -m)/$(uname -r)/All/"

mas sudo não /root/.shrclê .shrc.

A FAQ do pkgsrc, "Usando 'sudo' com o pkgsrc" diz que você pode adaptar o "recurso su(1) just-in-time do pkgsrc" para usar o sudo, mas requer a edição de um makefile e a recompilação de algo. Isso parece um requisito exorbitante para uma tarefa tão básica. Mesmo sem esta modificação, pkg_addnão me pede suquando tento instalar pacotes como um usuário normal - apenas dizpkg_add: Can't create pkgdb entry: /var/db/pkg/<...>: Permission denied

O OpenBSD tem um arquivo /etc/installurl para esse fim, mas não consegui encontrar um equivalente para o NetBSD.