O configure -a não funciona; configure -a em recursão infinita

invernosantigos
(usa Linux Mint)

Enviado em 28/01/2022 - 03:37h

Vim para relatar um problema terrível e grotesco, desesperador e sem solução, e a solução estúpida e altamente desrecomendável que o resolveu. O assunto está aqui para debate da comunidade, e não tanto para servir de referência para solução de problemas semelhantes, até mesmo porque era a pior solução de todos os tempos, que sabe-se lá porque zicas do destino, funcionou. Mas devia era ter destruído todo o sistema de vez. O tipo de estória que voce conta para os amigos para dizer que "isso existe, e pode acontecer".

O precedente não era dos melhores... Eu estava encarando o desafio de instalar o Cinelerra no Linux Mint 20 Ullyana. Quem conhece, sabe bem que o Cinelerra pode ser o melhor editor de vídeo, mas padece de uma distribuição amadora e um desenvolvimento irresponsável : Bugs de instalação à rodo, versões distribuídas sem configure ou makefile. Appimages que não funcionam porque não são reconhecidas como executáveis, por mais que voce mude as permissões no terminal ou na gui. Exigências de dependências, obsoletas ou experimentais e que continuam experimentais para sempre -- do tipo "a versão final vai sair no fim do mês, então vamos usar", mas essa versão final não sai nunca, porque os bugs dela parecem um impávido colosso, como o hino nacional... Não são terminadas nunca, e no fim ficam obsoletas antes mesmo de ser lançadas, substituídas por novas tecnologias que ao contrário delas, funcionam. Fora que se isso for pouco, o Cinelerra exige também pacotes git, vários deles, todos na mesma linha experimental. Imagine a irresponsabilidade de exigir gits, que além de experiementais, são frequentemente descontinuados sem aviso, além de instruções de instalações doentiamente mal-redigidas. As exigencias do cinelerra são absurdas : Instalar várias dezenas de dependências só para os gits, e inclui umas cacas já obsoletas e problemáticas como Vdpau ( aquele que só dá pau... ), Vaapi, e o inacreditável SHUTTLE USB support, que serve apenas para as placas de captura da marca SHUTTLE, e por isso não deveria ser dependência obrigatória. Da mesma forma, vdpau e vaapi só interessam à Nvidia... Devem ser patrocinadores do cinelerra... Fora a SHUTTLE ser odiada pela comunidade pelo descaso e estupidez com que trata o pessoal do Linux. Bom, batalhei muito e superei os obstáculos Vdpau support e Vaapi support e fui encarar o nojento usb support da shuttle, que exigia um git que pedia uma paulada de dependências para ser compilado, configurado e "makeado". Entre elas, o inocente Apache2, que tem um bug nojento à anos e ninguém resolve.

Bom, foi esse bug que me pegou. O apt-get travou porque o dpkg entrou em recursão e esgotou o cache do apt -- Nenhuma recursão infinita é de fato infinita, porque o cache disponível não é. Então quando o espaço disponível para o cache acaba, a aplicação apenas trava e a recursão acaba. E o cache do dpkg é generoso, mas limitado. Ficou apenas o aviso repetido por centenas de linhas de terminal : "Deep recursion on subroutine "main::rmdir_if_empty" at /usr/bin/deb-systemd-help, erro na linha 424". Ficou travado nesse erro sem conseguir sair dela, e sem finalizar a subrotina. Eram literalmente centenas de repetições dessa mesma linha. Sendo recursão, poderia ter sido milhares, mas como pontuei, o cache disponível não é infinito -- o dpkg no máximo instala até cerca de 30 dependências de uma vez, e poderia instalar mais, até 50, mas não consegue mais organizar a ordem de instalação -- Nenhuma solução destravaria o dpkg depois dessa. Era preciso fechar o terminal e matar o processo. Mas rodar --configure -a era inútil, porque ele apenas repetia a recursão e não saía disso. Eu fiz., matei o processo e tentei de novo. Inútil, o mesmo de novo. Outros comandos não eram aceitos, porque a Nerdalha Desenvolvedora que criou o Dpkg programaram a coisa para resolver tudo apenas com --configure -a. E quando o problema é o próprio configure -a ? Examinei a subrotina que travava a configuração do apache, no lugar e na linha indicada ( /usr/bin/deb-systemd-help , linha 424 ) e era assustador por ser um arquivo do systemd. Era além do meu conhecimento, que não é muito -- me considero "Iniciante Chique", o cara que continua iniciante, mas já tem idade suficiente pra já ter aprendido alguma coisa. Rodar configure -a era inútil, porque ele voltava à recursão, e a máquina se recusava a qualquer outra opção que não fosse executar "sudo dpkg --configure -a", à não ser apt clean, que foi necessário para limpar o cache do dpkg ou a máquina parava. Pensei que o único modo de se livrar disso seria eliminar o apache do dpkg, mas não encontrei onde ficam os arquivos temporários de instalação, o cache do dpkg. A nerdalha não pensou nisso como solução... Depois de meia hora ficou claro que eu teria que reinstalar o sistema -- e o meu sistema é todinho customizado à mão -- ou recorrer ao Timeshift, notório quebrador de Grub -- Isso porque o timeshift faz backup de todo o sistema, mas não inclui o grub nem o initramfs, porque esses não estão na Partição de Sistema, mas na Partição de Boot, que é separada; no diretório "boot" da partição de sistema só tem um link simbólico para o conteúdo da partição de boot, mas o timeshift não copia conteúdo via link simbólico. Então, se o seu grub quebra e voce tenta recuperar pelo timeshift, voce perde tudo e a máquina não inicia mais, e voce tem que reinstalar mesmo. Quando se configura o timeshift, é preciso incluir manualmente a partição de boot ( na opção "Incluir diretório/arquivos" ). Foi então pensando que eu teria que reinstalar tudo que me veio a idéia ruim que deu certo :

A recursão se devia a um problema dos scripts do apache com uma subrotina do /usr/bin/deb-systemd-help, certo ? E o nome "deb-systemd-help" sugere que ele não é um arquivo essencial do systemd, mas apenas um gerador de avisos em tela -- o famoso Verbose. Então mandei o /usr/bin/deb-systemd-help para a lixeira para deixá-lo indisponível para o sistema e fiz o dpkg configure -a. Desta vez ele rodou até o fim, sem nenhuma recursão, embora chiasse que não consequia encontrar o /usr/bin/deb-systemd-help. Mas completou o configure -a. Depois, restaurei o arquivo, da lixeira para o seu devido lugar.

Se eu fosse estúpido, ficaria todo orgulhoso de mim mesmo por meu brilhantismo. Mas não deu. Era estúpido mesmo. Funcionou, mas foi o equivalente à pular do alto de um prédio para não se suicidar. Mas achei que valia um relatório, porque já vi deslumbrados que acham que o apt é o Merlim, que faz mágica, e que é infalível. Quem tem prática sabe que o apt às vezes kg td, porque ele depende totalmente que as informações dos repositórios estejam corretas, e nem sempre estão. Quem pegou o lendário bug do build-essential no trusty Tahr, que quebrava a máquina toda vez que se tentava instalá-lo, por causa de um libstdc bugado e uma dependência circular; ou o lendário bug do Python em 2016, mais ou menos, em que os pacotes Python ficaram desencontrados durante meses, com um monte de versões diferentes dos mesmos pacotes que não funcionava estavelmente em conjunto em nenhuma versão. Resolver o problema como eu resolvi, pondo o sistema em alto risco, não é motivo para achar que acertou alguma coisa ou que teve a idéia certa. Não é uma questão de ser criativo ou de pensar fora da caixa. E quem ri por último, NÃO ri melhor; geralmente, é porque não entendeu a piada mesmo. É mais para pensar : estou no Linux desde os tempos do Lucid Linx ( que não é tanto tempo assim ), e nunca me conformei com a falta de salvaguardas do apt-get... Não deveria haver algum script semiautomático para lidar com aquela falhas comuns, como o problema das travas /var/lib/dpkg/lock-frontend, /var/lib/dpkg/lock, e /var/cache/apt/archives/lock ? Ao invés disso a Nerdalha Desenvolvedora e os Fanáticos da "Segurança" ficam criando dificuldades, como tirar a opção -B ( --force-breaks ) do dpkg para evitar "mau-uso" por parte de principiantes, proibir a instalação disso e daquilo, e outras alterações cosméticas que não resolvem os reais problemas do Linux, e apenas refletem os vícios pensamento dos nerds, como fazer as coisas de um determinado jeito apenas porque no achômetro deles é "o certo", mesmo quando é o jeito mais complicado, mas não resolve os reais problemas do Linux, como a instabilidade das permissões do Ubuntu, ou a falta de compatibilidade entre as permissões do FAT 32 e as do ext 4. Ou o lendário problema dos drivers em Linux, que funcionam mal pra caramba, desde sempre. Aliás, o segredo comercial do Windows, mantido à 7 chaves pela Microsoft desde os tempos de Darth Gates, não são os acordões feitos por debaixo dos panos com fabricantes de drivers ou de impressoras. Isso até existe, mas o grande segredo comercial do "Ruindows" é mesmo o seu refinado sistema de gerenciamento de drivers.

removido
(usa Nenhuma)

Enviado em 28/01/2022 - 09:32h

Bom, quanto ao cinelerra, como não sou da área de audiovisual, entendo pouquíssimo de editores de vídeo e áudio.

Pelo que eu entendo do pessoal que utiliza Linux e trabalha com isso, o cinelerra, por mais que ainda seja atualizado, já "morreu" - no sentido de desuso - faz muito tempo, justamente pelos inúmeros bugs e inúmeras dependências que ele exige.
Para linux, o mais completo me parece ser o DaVince Resolve, logo em seguida temos o LightWorks, e para edições mais simples, o Kdenlive. Existem outros, mas estes são os que eu mais vejo o pessoal usar.

Quanto a quebra de gerenciador de pacotes, as distribuições dependem de um gerenciador para manipular a instalação e desinstalação de programas, pois as bibliotecas no Linux são compiladas dinamicamente, de forma que uma biblioteca possa ser utilizada por mais de um programa. Diferentemente do Windows, que cada programa é disponibilizado com todas as dependências juntas, deixando o sistema mais inchado.

Quanto aos problemas do gerenciador de pacotes, se o desenvolvedor, ou melhor, o "empacotador" do programa seguir corretamente as instruções de como empacotar um programa para .deb ou .rpm, dificilmente (para não dizer impossível) esse pacote quebrará o sistema. O Cinelerra foi construído de forma totalmente incorreta e como você mesmo disse, utilizando dependências obsoletas e outras experimentais.

Não é de hoje que o Cinelerra é empacotado dessa forma. Desde os meus primeiros dias de usuário linux, quando tentei instalá-lo, por mera curiosidade, tive inúmeros problemas, isso lá por meados de 2009.
Felizmente, existem alternativas melhores, como dito no início da minha postagem.

Em resumo, os gerenciadores de pacotes exigem certos cuidados para não quebrar o sistema. Eu utilizo Linux a muitos anos, e raramente tive problemas com pacotes, a não ser pacotes mal construídos ou meta-pacotes.

E complementando, hoje em dia, temos mais opções além dos gerenciadores de pacotes, como AppImage, Snap, e Flatpak, que rodam em uma "caixa", deixando o sistema livre de problemas com dependências.

O Ubuntu, além de se basear no ramo unstable do Debian, que como o nome diz, "instável", tem a particularidade em favorecer os ditos meta-pacotes, os quais podem conter dependências conflitantes ou mesmo inexistentes. Por isso, é de total responsabilidade do empacotador olhar com mais cuidado as dependências antes de disponibilizar o pacotes, e isso não é de forma alguma um tipo de "falha" do Linux.

Sobre os drivers, não há nada que se possa fazer se os fabricantes não liberam versões para Linux. A comunidade se esforça para criar alternativas para substituí-los, para que o suporte seja ampliado para mais dispositivos. De qualquer forma, faz muito tempo que eu não tenho problemas com drivers em minhas instalações.

E sobre as permissões, confesso que não entendi as tais "instabilidade das permissões do Ubuntu". As permissões no Linux são funcionais em sistemas de arquivos feitos para Linux, nesse sentido, não funciona em sistemas de arquivos feitos para outros sistemais operacionais, como o Windows (NTFS/FAT), que tem o seu próprio sistema de permissionamento.

invernosantigos
(usa Linux Mint)

Enviado em 29/01/2022 - 01:30h

Agradeço desde já os comentários, Run4n. Batalhamos à anos para promover um sistema estável e isento de bugs, e é sempre desapontador ver a falta de empenho de alguns desenvolvedores. À cerca de 1 ano, dei uma bronca no pessoal do Libreoffice em algum fórum da vida por aí, apenas porque fiquei passado com a penúltima versão do Libreoffice 6, que tinha o pack de dependências mais porco que já vi : Misturava sources com pacotes deb, e a source não era nem compilável -- sem automake, configure ou makefile, e claro, não permitiria nem morto instalação automática tal como era oferecido, e nem mesmo podia ser compilado à mão. De resto, exigia uma depe que não existia e não era oferecida. Um quebrador de sistema ! é o que era ! Espalhei um alerta para que ninguém instalasse a estrovenga, então a Libre org tirou do ar depois de 2 semanas. Como se já não soubessem de início o trabalho porco que tinham feito... E o que me deixa indignado, é que o "Libreoff" chegou até aqui graças só á comunidade Linux, já que a parceirinha querida, Microsoft, fez de tudo para destruir o Libre, ainda no berço. Me queixei inclusive que era um péssimo uso das doações que a Libre Org reecebia. Deve ter doído.

E peço desculpas por ser obscuro em alguns pontos, por falta de espaço e não poder prolongar discussão sobre um monte de assuntos que realmente não tem muito à ver uns com os outros, fora a bronca GERAL que mereciam e levaram. Os bugs de permissão ao que me referi, por exemplo, são bem típicos principalmente das versões atuais do Mint e do Ubuntu, do Trusty Tahr para cá. Simples : Mude as permissões de uma pasta, e assinale recurssão para todos os arquivos contidos na pasta. Necas ! Só a pasta em si muda as permissões, os arquivos nele voce terá que mudar a permissão manualmente um-à-um ! Mudar pelo terminal resolvia, mas agora não resolve mais, pelo menos não no Mint. Resumindo : Dá muito trabalho ! Fora que um dos motivos que me fez debandar do Ubuntu, foi a instabilidade das permissões. Por 10 ou 15 vezes, em algum dia qualquer eu quis ligar o PC, e não consegui acesso à pasta home, porque as permissões tinham sido adulteradas sem motivo ou por isso mesmo. Tudo ficava como Root, reiniciar não resolvia, e eu ficava de 2 à 3 horas redefinindo permissões, diretório por diretório -- inclusive os ocultos, fora o .xautority e o .drmc, que ficavam inacessíveis para o usuário. Eu poderia simplesmente ter ignorado e entrado direto como administrador, mas aprendi à não ignorar problemas e não deixá-los para o dia seguinte. Sou meio neurótico por causa disso, porque não tenho muito tempo disponível todos os dias; então no dia que tenho, deixo o Linux no ponto, pronto para uso imediato ou para cair fora dele de imediato.

Mas como pontuei, as permissões são apenas um dos problemas do Linux. O problema dos drivers não está na falta de fornecimento de driver do fabricante, mas sim que o Linux administra mal os drivers, mesmo os muito bem-feitos. Vamos comparar : Eu disse que o verdadeiro segredo comercial do Ruinwindows era o seu "refinado sistema de gerenciamento de drivers". O que isso quer dizer exatamente ? Não era uma frase de efeito e muito menos um elogio; eu estou no Linux porque desde os anos 90 tenho uma relação de ódio com o Ruinwindows, e parece que o ódio é mútuo... Agora, veja : segundo um amigo meu, hacker que dedicou a vida á quebrar o código-fonte do Windows, o tanto que desse, e o surpreendente no Ruinwindows é como ele implementa os drivers. O Linux só joga eles direto no compilador, como se fosse uma subrotina qualquer. E é exatamente o que não funciona. O Ruinwindows usa aqueles nefastos arquivos autorun ( Auto-Run, "auto-início" ) para implementar a chamada de sistema para aquele driver. Parece um lixo, esses autorun, um mero risco de segurança, mas na verdade são espertos : São cheios de meta-dados para a orientação das Bibliotecas de Chamada da API de drivers. Eles chamam uma biblioteca que vai configurar as Convenções de Chamada para aquele driver. Nada de driver rodando à seco, a execução dele é pré-configurada por uma chamada "personalizada" definida através dos metadados do autorun. Ou seja : O velho golpe do driver pré-configurado. O Linux só usa esse truque com os processadores. É o ponto forte do Debian, com seus pacotes pré-compilados para AMD 64, i386, arm, sparc... Mas no Windows, tudo é assim, e cada driver tem uma biblioteca pré-compilada para aquele hardware esperando ele. Ele já inicia otimizado no carregamento, e o fracasso do Linux em simplificar a instalação e execução dos drivers mostra que pular etapas não é a melhor solução. E por isso o Ruinwindows leva bem mais tempo para instalar um driver, mas quando termina, roda bonito ! Claro, foi pré-compilado pelo próprio sistema seguindo as instruções da tal biblioteca... Esconder isso é a razão do empenho da Microsoft em não abrir nem parcialmente o código-fonte para auditoria pública. É tão secreto que eles nem mesmo patentearam ! Eles até liberaram o código-fonte de versões antigas -- arcaicas -- como o XP, milenium, 95 e cacas e tal... Mas a API de drivers não está lá no código-fonte liberado para exame. Qualquer hackeada básica no windows mostra de cara que a API de Drivers é separada da API de sistema. E, segundo o meu amigo, é bem parecida com uma API ODBC -- Open Database Connectivity ( ODBC ) -- uma API de banco de dados de alta perfomance. Não por acaso, foi a Microsoft que desenvolveu essa tecnologia, junto de uma outra empresa chamada Simba Technologies. Oficialmente, a tecnologia foi desenvolvida para Big Data, mas a API de Drivers do Ruinwindows parece ser algo como um protótipo dela.

Pelo que entendi do que ele me disse, uma biblioteca dinâmica tipo ODBC, permite que as ligações sejam configuradas por um arquivo ou biblioteca externa de diretivas, e o auto-run é para chamar esses arquivos de diretivas. Simples assim, mas muito engenhoso. Mas espero que tenha sacado que, por isso, fazer engenharia reversa num driver feito para windowns -- como é o caso do Noveau -- não dá certo, porque o segredo não está no driver, mas na implementação dele dentro da API ( bibliotecas + driver = implementação ) o que depende, essencialmente, das ligações -- o modo como uma biblioteca chama a outra.

Mas, outro aspecto do mesmo problema que eu quero apontar também, é que o Linux não precisava usar drivers próprios -- ele poderia muito bem usar os drivers do Windows mesmo, mas decidiu-se reinventar a roda. Bastaria que a API de drivers fosse separada, e fosse compatível com a API de drivers do windows. ( ou pelo menos que fosse híbrida/mista ). E nem seria preciso engenharia reversa para isso, já que a API de drivers do Windows é pública, para os desenvolvedores de aplicações, e só a implementação dela é que é segredo comercial. De resto é bom lembrar que a execução de drivers no Linux é mais estável, porque o Linux usa Pseudo-sistemas de arquivos ( Procs, Sys ). Mas no windows o driver "evolui" e dá para tirar o máximo rendimento dele, ao invés da execução rígida do Linux.

Bom, vou terminar por aqui, porque se eu ficar enumerando tópicos e detalhando, vai levar páginas de assunto. Tomei esses dois exemplos -- permissões e drivers -- porque eram os mais significativos.

clodoaldops
(usa Linux Mint)

Enviado em 29/01/2022 - 08:35h

-como uso meu desktop/laptop apenas para tarefas básicas como ouvir musicas, assistir filmes, navegar internet, editar textos/planilhas/apresentações não tenho enfrentado nenhum problema sério e /ou insolúvel no ubuntu, linuxmint, fedora, debian
-mas não uso desktop/laptop para editar imagens/videos/audios

invernosantigos
(usa Linux Mint)

Enviado em 29/01/2022 - 12:18h

Bom, Clodoaldops, primeiro, parabéns pelo sempre bom serviço prestado aqui. Vc, e o Alfbneto são meus heróis aqui, e eu considero ambos meio que "infalíveis". Mas, indo direto ao assunto. Nem todo mundo usa o Linux só pra trabalho, ou apenas para coisas básicas. No caso do meu, ele faz de tudo, desde baixar e editar imagens, músicas e servir de central multimídia ( fica ligado a noite inteira, servindo de Jukebox ). E tenho o hábito de baixar músicas ( 700 aqui ) e ajustar o volume de algumas no Audacity, se não estiver bom. Não engulo cru. Mas o ruim mesmo, é meu Mint 20 ser todo configurado à mão para extrair usabilidade máxima, já que padeço de déficit de atenção grave, à ponto de ser aposentado precocemente por incapacidade -- então comecei por causa do déficit de atenção, configurando tamanho e tipo de fontes, e por fim peguei embalo e acabei configurando até o Preload à mão. Ou seja, eu mexo até nas áreas de alto risco, pq a máquina ficou meio pesada com tanta coisa instalada, e tive que aumentar o rendimento de algumas coisinhas aqui, de modo que bugs que vc nunca nem ouviu falar, pq geralmente passam despercebidos, se destacam num sistema tão pesado... Por exemplo, o Mint tem uns problemas bizarros de lentidão no Initramfs, que às vezes levava 15 minutos para terminar -- o que eu acho um vacilo de alto risco de segurança -- É natural que ele fique mais lento conforme o sistema vá ficando mais pesado, mas "15 minutos", é lisérgico. É um bug conhecido. Alguns tutoriais por aí, como o do respeitável Elias Praciano, já deram dicas de trocar a compressão, eu tentei em 3 ocasiões e ou não mudou nada, ou piorou mesmo. Por fim, fiz o que o Praciano não fez e consultei o monitor de sistema e o proc, e descobri que o problema do Initramfs era simplesmente um bug de falta de prioridade de processo -- tava rodando com prioridade de Usuário ( acontece em cerca de metade das inicializações, numa instalação nativa sem modificações do Mint 20 ), e eu mudei para prioridade máxima de root, para o sistema ficar exposto o mínimo de tempo. Mas não o fiz mexendo no Kernell ou no Init ou no systemd. Apenas coloquei um comando "sudo nice" ( sudo nice -n -20 initramfs ) nos aplicativos de início automático para ele reconfigurar as prioridades sem ter que mexer em arquivos de configurações fundamentais no núcleo profundo do sistema. Há coisas que é melhor nunca mexer, como o Sudoers -- Mico Total. Não tem transparência, não tem facilidade, é ambiguo e não tem bons tutoriais. Mais perigoso que compiz tendo apenas 2 Gb de memória.

Há outros bugs que vc certamente nunca ouviu falar, digo, nem ouviu... No Ubuntu e seus derivados, tem um peculiar e raro bug de instalação que só ocorre se vc fizer várias reinstalações simples. Uma reinstalação limpa resolveria, mas "Instalção Limpa" mantra sagrado de alguns, não é uma opção viável se vc tem 800 Gb de documentos e mídias na máquina -- A minha Valentine aqui é uma Biblioteca Multimídia bem parrudinha. Minha vida tá toda aqui. O bug : Após várias instalações e reinstalações seguidas, é comum uma instalação nova bugar todas as permissões de diretório da partição Home, ignorando usuário e administrador e pondo todos os diretórios como Root, ou pior, permissões 1000 ou até mesmo 10000, quase Sigid. Por que, não sei. Talvez muitas reinstalações e trocas de sistema detonem a compatibilidade do xautority, ou algo assim. Ocorre mais quando vc muda de uma versão para outra, mesmo que da mesma distro. Mas encontrei uma solução simples para evitar esse erro : Durante a instalação, ou reinstalação, antes de clicar no instalador do sistema, abrir terminal, entrar como Sudo Su, e aplicar Umask 0000. E só aí começar a instalação. Por isso o meu palpite é que a reinstalação de uma versão para outra diferente pode sofrer uma leitura errada das permissões anteriores dos diretórios do usuário, e o sistema literalmente SOMA as permissões da nova instalação com a antiga -- e o erro é cumulativo, principalmente quando a instalação buga e vc tem que refazê-la porque a máquina não inicia. A série "T" do Mint ( Tina, Tara, Taturana ) era mestra em bug de instalação e acabei aprendendo isso do jeito mais díficil. Mas pelo menos, ali eu tinha a opção de deletar o Xautority, e refazer as permissões diretório por diretório. Acabei ficando bom em Mint por causa dessas micadas.

A parte realmente ruim de customizar tanto o OS, não é a lentidão para iniciar ( 4 minutos, uma eternidade num Mint ) ou o sistema pesado, mas que vc fica muito bom no que faz, mas só naquela distro, sem um conhecimento mais amplo de Linux. Confesso que tenho uma certa inveja de um cara "multi-distro" como vc, que vai do Ubuntu até o Fedora e volta, sem nem suar... O único conselho bom que meu pai me deu na vida, foi dizer que um cara que é muito bom numa coisa geralmente só é bom nisso... E é bem o meu caso. Mas não deixo de ter uma certa satisfação com o trabalho bem-feito quando amigos meus me visitam e vêem o Chrome rodando com 40 abas abertas, mais duas janelas do Nemo abertas, mais Clementine aberto e VLC rodando ( um dos dois players parados, pelo menos ). Ah, e o Cairo-Docs também, para manter as minhas aplicações de mais uso sempre à mão. Tudo isso num i5 com apenas 12 Gb DDR funcionais e uma placa-mãe chulé ( Positivo ). Sem aquecimento ou lentidão. Tá certo que isso não é exatamente um sistema fraco, e a maioria dos problemas do Ubuntu e seus derivados é só falta de configurar Swappness, mas o fato é que mesmo nessas condições de muito exigência, o sistema roda redondo e sem pausas por turnos de até 8 horas... Mas, sinceramente não recomendo. Máquina leve com customização mínima é melhor. Mas também não vejo mérito em se conter por preguiça ou por medo de ousar.

clodoaldops
(usa Linux Mint)

Enviado em 29/01/2022 - 13:48h

-resolvi o problema de inicialização lenta do linuxmint fazendo duas coisas
1- troquei cinnamom pelo mate/xfce
2- troquei o hdd por um ssd
-agora o linuxmint abre com menos de 30 segundos num laptop/2011 (ci3/4ram/240ssd)

invernosantigos
(usa Linux Mint)

Enviado em 30/01/2022 - 03:42h

As escolhas de um homem prático, que prefere eficiência ! Como se diz na moda : "Menos é mais !", o antológico grito de guerra oficial do minimalismo. Sem dúvida, mate/xfce são as melhores opções para simplicidade eficiente. Eu recomendaria. Mas o "Cinnamongo" não é problemático; a inicialização dele é lenta -- às vezes -- porque ele automatiza muita coisa, tantas que a gente tem que desabilitar algumas na inicialização automática, como o geoclue ( quem precisa ter sua localização rastreada logo ao entrar ? É algum programa de proteção às testemunhas ? ). Desabilitando os serviços desnecessários, e incluindo zram e zswap, fica rapidinho, geralmente só 2 minutinhos numa instalação limpa. O problema aqui é o Shell lotado com uma centena de aplicações que vão do Krename até o Catfish, fora tudo que está no meio e eu não desinstalo para evitar problemas, tipo o Libre 7.2 e o 7.0. O 7.2 eu uso, é a minha atual versão de trabalho. Não desinstalo o 7.0, porque em situações anteriores, desinstalei versões anteriores de um libre-base ( 7.0 é base do 7.2, por exemplo ), e a versão de uso quebrou ou ficou sem funcionalidades como o assistente de impressão. O libre tem vários pacotes que não são atualizados à cada ramo de uma versão, e aparecem só na lista de dependências da versão-base ( ramo principal ); mal gerenciamento da lista de dependências, só isso. Talvez, tenha finalmente mudado, mas eu não quero arriscar a estabilidade da minha instalação só para abrir 200 MB de espaço à mais que eu não preciso. Eu sou do tempo em várias aplicações do Linux usavam dependências do Libre, o que era estúpido, porque vc reinstalava o Libre e quebrava o sistema. Acontecia muito, justamente no Trusty Tahr e nos derivados dele, como o Elementary OS Júpiter, Mint Rebecca, Rafaella, Ritalina... Entre outras coisas que apesar de desnecessárias eu não desinstalo, está o Midnight Commander, que é dependência de alguma aplicação que ainda não descobri qual é, mas que em compensação, é bem útil quando o Nemo Buga e eu não estou num bom momento para reiniciar a máquina. E de qualquer forma, acho a proposta do Cinnamon, brilhante, e vou contar porque :

O Linux Mint surgiu como uma distro voltada para desenvolvedores. Era um laboratório para cientistas loucos -- por programação ( desculpe pelo trocadilho ) e nele a interface Cinnamon surgiu com a proposta mais original já vista entre todas as interfaces gráficas : Ele vê todo o sistema como uma grande network, e tudo dentro do sistema é visto como um objeto dessa network, seja um arquivo ou uma aplicação ou mesmo uma interface de configuração. Então usa o CUPS para identificar cada objeto dentro dessa network como um objeto de interface gráfica. Botões e GUIs são tratados como um mero periférico de controle, como mouse ou teclado. Outros são tratados como periféricos de entrada -- um arquivo não é muito diferente de um pendrive -- Uma vez que esse objeto é montado dentro da rede e tem seu caminho definido, ele é traduzido como objeto de interface gráfica que pode ser posicionado e à seguir, é renderizado com GTK e Qt. É na renderização de fato que o Cinnamon fica pesado, não porque ele seja pesado em si, ou porque o GTK e Qt sejam pesados, embora sejam; mas apenas porque toda renderização é pesada, em qualquer sistema ou interface gráfica. A mágica não é a leveza, a mágica é renderizar objetos de forma estável. Mas para isso precisam ser definidos como objetos de forma estável. Xfce e Gnome são estáveis porque definem objetos de interface estáveis, mas precisaram percorrer muito chão para chegar nisso. Já o Unity e o Mir apanharam muito, e ainda apanham. O MATE é um fork leve do Cinnammon, então não conta, mas é basicamente o Cinnamon sem as partes pesadas.

Pessoalmente, acho que poderiam ter feito uma engine de renderização mais leve, se tivessem tomado como base, como primeira camada, o Enlightment, que é o renderizador de interface gráfica do Bodhi Linux, outra proposta alternativa, mas que se destaca por sua incrível leveza e simplicidade flexível. A proposta do Enlightment é usar o mínimo de dependências e nenhum GTK ou Qt, mas isso só foi possível nas versões rc1 e rc2 -- atualmente está no RC4, ou seja, continua ainda como experimental ( rc ). À partir do rc3 passou à usar algum GTK para evitar saias-justas com dependências. A equipe do Enlightment não tem tanto pessoal qualificado ou verba quanto a do Cinnamon, de modo que criar dependências dedicadas para pular problemas com as dependências disponíveis no mercado, não está bem nas possibilidades dos desenvolvedores. Mas voltando ao assunto, quando digo que o renderizador de interface gráfica do Cinnamon poderia ter ficado mais leve e mais ágil usando o Enlightment, eu preciso fazer a consideração sincera que a equipe do Cinnamon até experimentou o Enlightment, mas... não é que não deu certo, mas que o desenvolvimento do Enlightment não evoluiu de forma ágil, e ficou parado no rc2 por 10 anos, e ainda agora, continua experimental ( rc4 ), e a equipe do Cinnamon foi sábia em preferir não se prender à um projeto de desenvolvimento incerto, que vai ficar pronto em algum incerto amanhã que não chega nunca.

Depois de toda a crítica que eu fiz, o fato é que o Cinnamon é ótimo embora longe ainda de ser perfeito. Eu e meu já citado amigo hacker -- somos ambos veteranos do movimento gótico, e trabalhamos juntos na mesma firma de auditoria; ele era o hacker da firma -- costumamos brincar dizendo que não custa sonhar com o Ubuntu Definitivo mas por enquanto, não dá. Já demos até nome pra ele : Ubuntu DD ( Dangerous Dragon ). Vai ser o Ubuntu 30 ? O 50 ? vai ser no meu tempo de vida ? Vou ter que contratar uma daquelas firmas que congela o meu cadáver ? Por enquanto não dá -- muita dependência bugada e muito subsistema mal-contruído. Na linha hors-concours do Mico Total, que tal o Pulseaudio e o Alsa do Mint ? Eles não se falam. Sozinho, o Pulseaudio já é uma bagunça; juntou o Alsa, não parecem nem saber qual é a tarefa de cada um. Na dúvida, deixam de funcionar ambos e o som fica sem saída. Voce abre as configurações de audio, e descobre que os canais sumiram. Canais somem ! É uma bagunça total, quase uma sauna gay... E pra piorar, o Alsa foi simplesmente montado encima, como se fosse um puxadinho de um barraco de alvenaria numa favela qualquer do Rio, com direito à tiroteio e tudo mais de sempre. E a solução poderia ser bem simples : O que o Pulseaudio/Alsa precisa pra ficar consistente, é apenas de um arquivo de confile -- aqueles arquivos .cfg, que servem para configurar outros arquivos de configuração, como o Grub.cfg, que é o responsável pela estabilidade do Grub, a coisa mais estável e bem-feita que existe em todo o Linux. Uma obra-prima, mas seu exemplo de sucesso não é seguido.

A bagunça em algumas dependências -- gtk, qt e python ( gtk e qt sossegaram, mas python virou uma zona ) poderia ser mitigada quebrando alguns vícios de desenvolvimento que uma certa nerdalha precisa largar : Experimentalidade, procrastinação em entregar versões definitivas para ficar mudando o projeto que já está sem rumo ou meta ou nunca teve mesmo ( github, essa foi pra vcs ). E a pior e mais danosa de todas : Micromodularidade, que é aquela mania que alguns tem ( alô, Qt... ) de ficar quebrando dependências em dezenas de pequeninas dependências ( o Libboost-all-dev precisa mesmo de 150 dependências ? Porque vc precisa de um jeito ou de outro instalar TODAS. Os pacotes de plugin do Cairo-Docs precisam mesmo ser individualizados ? um meta-pacote que reúnas todos não é mais pratico e não garante melhor consistência para os arquivos de config ? ). Resumindo o problema : há quem ache que "mais modularidade é melhor"; sério, eu li isso à uns anos de um cara que comentou isso numa queixa sobre um pacote gtk bugado, quando o problema do pacote era justamente a divisão do projeto original em várias dependências desencontradas. Esse cara que achava que mais modularidade é melhor não pensava bem, pois se pensar ainda que só um pouco, percebe-se rápido que ficar dividindo dependências em pacotinhos mínimos é burrice pura e simples porque multiplica as chamadas de sistema e trocas de contexto. resumindo, deixa toda a execução muito mais lenta. Micromodularizar era uma boa idéia no tempo em que um disco de meros 20 Gigabertos custava uma fortuna. São Torvalds criou o Linux com foco em administração de dependências -- liberdade para instalar apenas o que vc precisa justamente por causa disso. Quem poderia imaginar que 30 anos depois, um lindo Seagate Barracuda de 1 Teranossaurus Rex custaria baratinho ? ( "Baratinho", é claro, desde que o Bolsocaro e a Dilmaluca não detonem a economia, o câmbio e o seu salário, se vc ainda estiver recebendo algum... ).

Basicamente o que eu estou dizendo é que ainda temos muito o que melhorar -- como se todo mundo ainda não tivesse notado isso ainda -- e não vamos chegar lá com um monte de negligentes e irresponsáveis fazendo as coisas de qualquer jeito e o resto só assistindo ( O negacionismo já chegou no Linux ). E nem são coisas tão difíceis assim. Não é preciso reinventar a roda ou lançar uma nova coisa fodástica tipo SuperlightDM Overdrive com dobra espacial trifásica; é só voltarmos consistentemente ao que acreditávamos lá no comecinho : Criar programas que façam uma só tarefa, mas a façam bem feito.

clodoaldops
(usa Linux Mint)

Enviado em 30/01/2022 - 08:53h

Filosofias à parte ...
O MATE não É um fork leve do Cinnammon
O Cinnamon é um fork do Gnome Shell


O MATE Desktop Environment é a continuação do GNOME 2. Ele fornece um ambiente de trabalho intuitivo e atraente usando metáforas tradicionais para Gnu/Linux e outros sistemas operacionais Unix-like.
https://mate-desktop.org/pt/

invernosantigos
(usa Linux Mint)

Enviado em 31/01/2022 - 05:17h

Obrigado pela correção, Clodoaldops, é bom para evitar a difusão de desinformação involuntária. Acho que não peguei bons artigos sobre o MATE, ou entendi tudo errado -- ou um pouco de ambas. Mas já que virou assunto, qual é mesmo o diferencial, a origem e a filosofia de desenvolvimento do MATE ? A origem ficou clara pelo o que vc já disse, mas o diferencial e a filosofia de desenvolvimento dele não ficaram lá muito claras. Tudo isso conta, ainda que não pareça... Comecei no Mint graças á filosofia inicial deles de oferecer uma suíte completa de aplicativos, e codecs pré-instalados.

Naquela época, eu tive problemas com minha conexão com a internet. Basicamente, minha casa é fundos. E eu tinha desavenças com o proprietário da casa da frente que era um Pitboy encrenqueiro doido para causar por qualquer motivo; então quebrar 15 metros de parede de corredor debaixo da janela dele para passar um cabo era fora de questão, por isso eu usava um serviço 3G que era bem limitado. Um pacote de 2 Gb naquela época --hj em dia uma atualização só já levaria embora metade disso, num dia bom... Relembrando, soa como piada, pacote de internet de 2Gb/mês... E a versão do Ubuntu naquela época, o Xenial Xerus, foi de longe o pior Ubuntu de todos os tempos. Bugs à rodo, dependências descontinuadas. Falhas fatais de depe em subsistemas críticos -- teve problema de dependência no dpkg, no gcc, no gtk, no python, no Rythymbox... resumindo, se funcionasse uma semana inteira sem quebrar nada, era incomum. Meus 2 gigabertos não rendiam, e eu reinstalava muito. Eu ainda era newbee, então a solução pra mim era sempre reinstalar, ainda que eu tivesse aprendido muita coisa, digamos avançada, no antecessor Vivid Vervet : bug de .drmc, de permissão, aprendi à fazer partição manual na instalação, consertar fstab, pilotar testdisk. Aprendi a instalar dependência á unha, graças ao lendário bug do Build-essential. Minha filosofia de vida sempre foi nunca ter medo ou preguiça de ter que fazer algo do jeito mais difícil. Meu citado amigo hacker apontou que eu era azarado o suficiente para de cara, pegar vários bugs de nível avançado, um atrás do outro, ao invés da misericórdia de só pegar bug de newbee, tipo, ficar um mês sem atualizar nada por não saber usar apt-get. Ocorreu que uma hora, tive problemas com a operadora de 3G q eu usava e fiquei sem internet 10 anos ! Para instalar, eu anotava as dependências que o sistema pedia, pegava elas numa LanHouse qualquer da vida -- naquela época, eram baratas -- trazia pra casa num pendrive, jogava numa pasta, e corria "dpkg -i *" Numa época em que uma aplicação pesada como o Rythymbox tinha no máximo 30, 35 depes, era viável esse estilo de vida. Hoje, seriam 50... Quando eu soube que o Mint trazia tudo pronto pra mim, abracei. Com a suíte nativa do Mint, aprendi sobre Libreofice, conheci o Gimp, o VLC, o Ogg Vorbis; ainda que eu não gostasse da interface, eu gostava do Unity e até onde sei, fui um dos poucos caras que se deu bem com ele e gostou... Comecei com o Mint Rafaella e depois com o Rebecca -- Rebecca era tão estável que fiquei com ela por 6 anos, até acabar o suporte. Dava pra fazer manutenção só á cada 6 meses. Tive que trocar o HD 2 vezes antes de trocar de versão. Quem pode contar essa estória hj em dia ?

Então, só tenho experiencia com Mint, Ubuntu e Elementary OS. Eu gostava muito do estilão clean e minimalista do Elementary Luna, e aprendi á customizar sistema com ele; mas o Pantheon Shell era muito frágil e desisti dele. O Pantheon do Luna tinha a mais incrível dependência circular que já vi na vida : Uma cadeia de dependências circular de 20 pacotes, todos do núcleo do Pantheon -- tão frágeis que era tudo protegido por chattr. Por acidente, descobri meio sem querer, que eu podia instalar o cinnamon nele -- mas perdia os efeitos de transparência do Pantheon, que meio que eram uma marca do Elementary. E descobri que eu podia instalar o Pantheon, o Unity e o Cinnamon nele, e alternar entre eles alternando o perfil de usuário, ou até mesmo criar perfis que combinavam elementos de ambos. Naquele tempo ( 2005 +/- ~ ) isso era possível. Hoje em dia, ficaria instável. De lá pra cá, só tive tempo para conhecer o Budgie, e gostei da proposta, mas ainda precisa muito melhorar, tá mais pra pobrinho do que para minimalista. Mas acho que o excesso de distros e a falta de intercambialidade entre as interfaces delas é prejudicial ao desenvolvimento, e eu gostaria de ver menos propostas porém mais consistentes

Dá para aprender bastante sem ter que ficar fazendo excursão por cada distro que é lançada, mas o custo é um certo empobrecimento e rigidez intelectual. Expandir horizontes era preciso. Experimentei algumas outras coisas quando aprendi à usar Máquina Virtual, ou melhor dizendo, aprendi quando as VMs se tornaram acessíveis ao usuário leigo -- antes, eram autênticos purgatórios via terminal