MC68020's questions

Como não posso dizer com precisão qual atualização (possivelmente nvidia-driversde 340 para 470 ou mesa 20 para 22 ou mesmo xorg-server 1.20 para 21) ou seguindo a primeira vez que executei glxgearsapós a atualização? :
Eu (embora não sistematicamente) posso ver, sobreposto no canto superior esquerdo da janela de aplicativos como vlc ou chromium , alguns relatórios muito semelhantes ao que eu obteria executando glxgears como pode ser visto abaixo em alguma captura de tela do vlc canto superior esquerdo da janela:

Isso é um inseto ? um problema de configuração incorreta? uma característica ? Tanto faz: como posso simplesmente me livrar disso?

EDIT 1: Isso seria o Indicador Visual da API de Gráficos ?
Eu ficaria surpreso, pois sua exibição não é sistemática e verifiquei se a __GL_SHOW_GRAPHICS_OSDvariável de ambiente não está definida.

BTW: Executando uma área de trabalho KDE-Plasma, sei que oferece a possibilidade de exibir informações sobre a taxa de quadros, mas não acho que essa questão esteja relacionada, pois essa opção não está definida e a exibição dessas informações é radicalmente diferente.

O servidor Akonadi é bem conhecido por ser iniciado com o primeiro aplicativo que precisa dele. (Kmail, KaddressBook, KOrganizer…)

Anteriormente executando o KDE-Plasma-5. 23 com um determinado conjunto de widgets (incluindo algum relógio digital + calendário), o servidor akonadi nunca seria iniciado até que eu voluntariamente iniciasse o kmail.

Atualizando para o KDE-Plasma-5. 24 (mesmo conjunto de widgets, mesmos serviços em execução) Percebo que o akonadi server & sons é iniciado no momento da inicialização do DE.

Por centenas de razões, eu simplesmente não quero isso:

1. Existe algum tipo de novo sintonizável que eu perdi?

2. Percebo que algum processo que nunca tinha visto está em execução: /usr/bin/kalendaracfilho de /usr/bin/plasma_sessionPoderia ser o culpado imediato? É este o aplicativo do qual o widget padrão do relógio digital agora depende?

   1. Existe uma maneira de dizer ao Kalendarac para não iniciar o servidor Akonadi? (Já tentei desabilitar todos os tipos de eventos de calendário como parte das configurações do widget sem nenhum impacto percebido na inicialização do servidor akonadi)
   2. Existe uma maneira de fazer com que este widget se comporte exatamente como costumava no KDE-Plasma-5.23 (usando fontes de informações desconhecidas do akonadi-stuff)?

Recebo 2 trabalhos de impressão que gostaria de cancelar:

Tux # lpq
photosmart_7200 is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     unknown 190     unknown                         8192 bytes
2nd     unknown 191     unknown                         8192 bytes

Criado por algum usuário localhost não root (no entanto, membro dos grupos lp e lpadmin) canalizando qualquer texto ascii para lp.)

No entanto :

Tux # lprm -
lprm: Forbidden
Tux # cancel -a
cancel: cancel-job failed: Forbidden

Não é necessário dizer que recebo resultados idênticos pela interface do navegador do cups, /var/log/cups_error.log diz:

E [21/Sep/2022:08:41:10 +0200] [Client 9] Returning HTTP Interdit for Cancel-Job (ipp://localhost/jobs/190) from localhost
E [21/Sep/2022:08:47:00 +0200] [Client 14] Returning HTTP Interdit for Cancel-Job (ipp://localhost/jobs/191) from localhost

Esses trabalhos ficam com seus arquivos d e arquivos de controle associados em /var/spool/cups :

Tux /var/spool/cups # ls -ails
…
878712 4 -rw------- 1 root lp   1032  6 juin   15:18 c00190
878713 4 -rw------- 1 root lp    940  6 juin   15:18 c00191
878714 4 -rw------- 1 root lp    832  6 juin   15:18 c00192
891424 4 -rw------- 1 root lp    954 17 sept.  22:42 c00193
891442 4 -rw------- 1 root lp    954 17 sept.  22:42 c00194
891435 4 -rw------- 1 root lp    954 17 sept.  22:42 c00195
878708 8 -rw-r----- 1 root lp   7288  6 juin   15:17 d00190-001
878711 8 -rw-r----- 1 root lp   7288  6 juin   15:18 d00191-001
885657 4 drwxrwx--T 2 root lp   4096 29 août  08:32 tmp

Executando cups-2.4.2 (trabalhos provavelmente criados executando cups-2.3.3) no linux-5.4

Então, por que esses comandos não podem realmente cancelar os trabalhos, como posso educadamente (evitando rm-los no diretório de spool) cancelar esses trabalhos.
Além disso, pode ser explicado como o proprietário desses trabalhos é relatado como " desconhecido " lpqporque as strings dos arquivos de controle mostram o nome de usuário válido?

Eu, como posso acreditar em qualquer pessoa ao redor, tenho demitido /usr/bin/startx por décadas, experimentando nada além de 100% de satisfação pelo trabalho que serve.

Se funcionar… não conserte!

O autor do script, no entanto, é explícito:

Os administradores do site são FORTEMENTE encorajados a escrever versões melhores.

Fiquei apenas curioso:

• Alguém sabe quais razões históricas levaram o autor a escrever uma declaração tão forte?
• Alguém já escreveu alguma " versão melhor ", como e para quê?

Nota : vejo vários pedidos para fechar esta pergunta pelo motivo de desencadear respostas baseadas em opinião.
Eu entendo como o qualificador "melhor" poderia sugerir julgamentos de gosto, mas eu simplesmente não consigo imaginar o autor " exortando FORTEMENTE " os administradores a cometerem mudanças estéticas.

Apenas muitas coisas estão abertas a mudanças nesse script, desde forçar argumentos cliente/servidor, honrar/ignorar usuários .*rc até mesmo bifurcar acidentalmente qualquer coisa que não seja /usr/bin/xinit.

Todas essas brincadeiras e muitas outras que nem imagino particularmente no campo da segurança, certamente dependeriam de motivos perfeitamente razoáveis ​​e se encaixariam no propósito de casos de uso especiais. É exatamente sobre isso que esta pergunta se trata.

Citando a documentação do kernel linux para parâmetros de inicialização:

pcie_bus_perf : Defina o MPS do dispositivo para o maior MPS permitido com base em seu barramento pai. Defina também MRRS (Max Read Request Size) para o maior valor suportado (não maior do que o MPS que o dispositivo ou barramento pode suportar) para melhor desempenho.

Não consigo entender por que o MRRS não deve ser maior que o MPS "para melhor desempenho".

Quero dizer, se um dispositivo pode fazer MPS=X e MRRS=4.X, as solicitações de leitura podem, em números, ser menos, portanto, o barramento está menos ocupado em comparação com uma situação de MRRS=X, mesmo que a satisfação da solicitação precise ser dividida em 4.

A divisão induziria alguma sobrecarga significativa em algum lugar?

BTW, eu conheço o conceito de "compartilhamento justo" e entendo o impacto de um grande MRRS nesse compartilhamento, mas nunca entendi o compartilhamento justo como sinônimo de melhor desempenho .