https://www.reddit.com/r/kdeneon/comments/16jizz7/is_tuxedo_os_based_on_neon/ neon mesmo
1 curtida
Eu tinha lido que era base Ubuntu-LTS; o que dá no mesmo kkk…
a base é uma só, o neon só diferencia o repo do kde kkk
1 curtida
Se não me engano o Fedora KDE vem com o Akonadi instalado. O Akonadi consome recursos sem dó.
1 curtida
Nem lembrava mais.
Foi uma das primeiras coisas que fiz:
2020-01-12 20:28:59 --- remover PIM !
# dnf remove korganizer kmail akregator ktnef kaddressbook konversation kf5-akonadi-server mariadb-common
No match for argument: ktnef
Dependencies resolved.
=============================================================================================================
Package Architecture Version Repository Size
=============================================================================================================
Removing:
akregator x86_64 19.04.3-2.fc31 @anaconda 3.9 M
kaddressbook x86_64 19.04.3-2.fc31 @anaconda 758 k
kf5-akonadi-server x86_64 19.04.3-4.fc31 @updates 9.8 M
kmail x86_64 19.04.3-2.fc31 @anaconda 14 M
konversation x86_64 1.7.5-6.fc31 @anaconda 14 M
korganizer x86_64 19.04.3-2.fc31 @anaconda 7.2 M
mariadb-common x86_64 3:10.3.20-3.fc31 @updates 179 k
Removing dependent packages:
kf5-akonadi-server-mysql x86_64 19.04.3-4.fc31 @updates 3.4 k
kgpg x86_64 19.04.3-2.fc31 @anaconda 7.8 M
kontact x86_64 19.04.3-2.fc31 @anaconda 1.6 M
mariadb-embedded x86_64 3:10.3.20-3.fc31 @updates 23 M
Removing unused dependencies:
akonadi-import-wizard x86_64 19.04.3-2.fc31 @anaconda 2.5 M
akregator-libs x86_64 19.04.3-2.fc31 @anaconda 2.4 M
boost-system x86_64 1.69.0-9.fc31 @anaconda 16 k
boost-thread x86_64 1.69.0-9.fc31 @anaconda 270 k
grantlee-editor x86_64 19.04.3-2.fc31 @anaconda 1.2 M
grantlee-editor-libs x86_64 19.04.3-2.fc31 @anaconda 149 k
kaddressbook-libs x86_64 19.04.3-2.fc31 @anaconda 685 k
kdepim-addons x86_64 19.04.3-2.fc31 @anaconda 9.7 M
kdepim-apps-libs x86_64 19.04.3-2.fc31 @anaconda 937 k
kdepim-runtime x86_64 1:19.04.3-2.fc31 @anaconda 18 M
kdepim-runtime-libs x86_64 1:19.04.3-2.fc31 @anaconda 2.2 M
kf5-akonadi-calendar x86_64 19.04.3-2.fc31 @anaconda 2.3 M
kf5-akonadi-contacts x86_64 19.04.3-2.fc31 @anaconda 2.8 M
kf5-akonadi-mime x86_64 19.04.3-2.fc31 @anaconda 968 k
kf5-akonadi-notes x86_64 19.04.3-2.fc31 @anaconda 157 k
kf5-akonadi-search x86_64 19.04.3-2.fc31 @anaconda 1.4 M
kf5-calendarsupport x86_64 19.04.3-2.fc31 @anaconda 3.2 M
kf5-eventviews x86_64 19.04.3-2.fc31 @anaconda 3.3 M
kf5-grantleetheme x86_64 19.04.3-2.fc31 @anaconda 242 k
kf5-incidenceeditor x86_64 19.04.3-2.fc31 @anaconda 3.0 M
kf5-kalarmcal x86_64 19.04.3-2.fc31 @anaconda 966 k
kf5-kcalendarcore x86_64 19.04.3-2.fc31 @anaconda 1.0 M
kf5-kcalendarutils x86_64 19.04.3-2.fc31 @anaconda 1.8 M
kf5-kcontacts x86_64 19.04.3-2.fc31 @anaconda 1.8 M
kf5-kdav x86_64 19.04.3-2.fc31 @anaconda 472 k
kf5-kidentitymanagement x86_64 19.04.3-2.fc31 @anaconda 422 k
kf5-kimap x86_64 19.04.3-2.fc31 @anaconda 1.1 M
kf5-kitinerary x86_64 19.04.3-2.fc31 @anaconda 1.4 M
kf5-kldap x86_64 19.04.3-2.fc31 @anaconda 721 k
kf5-kmailtransport x86_64 19.04.3-2.fc31 @anaconda 1.1 M
kf5-kmailtransport-akonadi x86_64 19.04.3-2.fc31 @anaconda 153 k
kf5-kmbox x86_64 19.04.3-2.fc31 @anaconda 94 k
kf5-kmime x86_64 19.04.3-1.fc31 @anaconda 596 k
kf5-kontactinterface x86_64 19.04.3-2.fc31 @anaconda 194 k
kf5-kpimtextedit x86_64 19.04.3-2.fc31 @anaconda 1.2 M
kf5-kpkpass x86_64 19.04.3-2.fc31 @anaconda 133 k
kf5-ksmtp x86_64 19.04.3-2.fc31 @anaconda 203 k
kf5-ktnef x86_64 19.04.3-2.fc31 @anaconda 596 k
kf5-libgravatar x86_64 19.04.3-2.fc31 @anaconda 200 k
kf5-libkdepim x86_64 19.04.3-2.fc31 @anaconda 1.3 M
kf5-libkdepim-akonadi x86_64 19.04.3-2.fc31 @anaconda 790 k
kf5-libkleo x86_64 19.04.3-2.fc31 @anaconda 2.3 M
kf5-libksieve x86_64 19.04.3-2.fc31 @anaconda 4.1 M
kf5-mailcommon x86_64 19.04.3-2.fc31 @anaconda 3.9 M
kf5-mailimporter x86_64 19.04.3-2.fc31 @anaconda 1.3 M
kf5-mailimporter-akonadi x86_64 19.04.3-2.fc31 @anaconda 98 k
kf5-messagelib x86_64 19.04.3-2.fc31 @anaconda 16 M
kf5-pimcommon x86_64 19.04.3-2.fc31 @anaconda 1.5 M
kf5-pimcommon-akonadi x86_64 19.04.3-2.fc31 @anaconda 426 k
kmail-account-wizard x86_64 19.04.3-2.fc31 @anaconda 2.9 M
kmail-libs x86_64 19.04.3-2.fc31 @anaconda 4.3 M
kontact-libs x86_64 19.04.3-2.fc31 @anaconda 365 k
korganizer-libs x86_64 19.04.3-2.fc31 @anaconda 3.3 M
libical x86_64 3.0.6-2.fc31 @updates 1.7 M
libkgapi x86_64 19.04.3-2.fc31 @anaconda 2.6 M
libkolabxml x86_64 1.1.6-11.fc31 @anaconda 3.8 M
mariadb x86_64 3:10.3.20-3.fc31 @updates 40 M
mariadb-backup x86_64 3:10.3.20-3.fc31 @updates 29 M
mariadb-cracklib-password-check x86_64 3:10.3.20-3.fc31 @updates 22 k
mariadb-errmsg x86_64 3:10.3.20-3.fc31 @updates 2.3 M
mariadb-gssapi-server x86_64 3:10.3.20-3.fc31 @updates 30 k
mariadb-server x86_64 3:10.3.20-3.fc31 @updates 99 M
mariadb-server-utils x86_64 3:10.3.20-3.fc31 @updates 7.5 M
mysql-selinux noarch 1.0.0-8.fc30 @anaconda 49 k
perl-DBD-MySQL x86_64 4.050-4.fc31 @anaconda 364 k
perl-DBI x86_64 1.642-5.fc31 @anaconda 1.8 M
perl-Math-BigInt noarch 1:1.9998.16-439.fc31 @anaconda 689 k
perl-Math-Complex noarch 1.59-449.fc31 @updates 86 k
pim-data-exporter x86_64 19.04.3-2.fc31 @anaconda 1.1 M
pim-data-exporter-libs x86_64 19.04.3-2.fc31 @anaconda 601 k
pim-sieve-editor x86_64 19.04.3-2.fc31 @anaconda 1.5 M
qt5-qtbase-mysql x86_64 5.13.2-1.fc31 @updates 86 k
qt5-qtnetworkauth x86_64 5.13.2-1.fc31 @updates 346 k
qt5-qtxmlpatterns x86_64 5.13.2-1.fc31 @updates 4.1 M
xerces-c x86_64 3.2.2-3.fc31 @anaconda 4.5 M
Transaction Summary
=============================================================================================================
Remove 86 Packages
Freed space: 394 M
Is this ok [y/N]: y
Depois disso, o uso inicial de Memória RAM caiu de 915 MiB para 693 MiB – segundo o Conky, que na época ainda usava o “cálculo antigo”.
Não foi uma redução tão espetacular (-24%). Depois reduziu para 607 MiB, não lembro como (-34%).
Uns 4 anos antes, em 2016, eliminar o PIM do Kubuntu tinha reduzido de uns 800 MiB para 400 MiB (-50%) – mas era num PC com apenas 4 GB RAM. – Num PC com mais RAM, qualquer distro usa mais RAM… e além disso, todas as distros hoje usam mais RAM do que 7 anos atrás.
3 curtidas
Seu Neofetch no Fedora também demorava a carregar as informações? Me recordo de ter ido em tutoriais de como transtornar isso, mas não resolveu na época… parece que é coisa do BTRFS.
Salve, @Tosca16
Nunca notei nada assim.
O que eu uso, normalmente, é no Conky – por exemplo:
neofetch ${alignr 100}${exec neofetch --stdout | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
${execi 600 neofetch --de_version on --stdout | grep "Packages:"}
${execi 600 neofetch --de_version on --stdout | grep "DE:"}
${execi 600 neofetch --de_version on --stdout | grep "CPU\|GPU"}
E também em um bash script – que salva essas informações em TXT em vez de exibir na tela.
1 curtida
Porém…
… há muito tempo percebo longas demoras para abrir aplicativos pela primeira vez, logo no início da sessão do openSUSE – única distro que uso com BtrFS.
Após o boot, começam vários serviços de manutenção BtrFS + Snapper, e isso às vezes demora um bom tempo. – Nesse período, Dolphin, Kate, Konsole, Gwenview, Chrome etc. demoram para abrir.
1 curtida
Wine 9.0-rc3 nativo no Wayland. A partir do Wine 9 (no momento ainda em… | by Fast OS | Jan, 2024 | Medium taí resultado dos meus testes iniciais com wine wayland, mesmo nesta fase já parece bem promissor e com bom desempenho
Vindo aqui após ver o vídeo do Diolinux Labs sobre o Wayland.
Estou usando o Hyprland há umas duas semanas com VGA Nvidia. E por incrível que pareça, sem nenhum bug. O sistema tá muito fluído, os jogos estão rodando de boa.
Por hora, estou bem satisfeito com a troca de DE.
2 curtidas
Mais um poster pra fomentar a polêmica e discórdia de quem é a culpa do Wayland ser ruim ou não kk.
1 curtida
Me parece que o autor do texto tratou (de forma errada) o protocolo (que é o que é de fato) Wayland como um Gerenciador de Janelas. Sinto que faltou algum estudo mais aprofundado do autor dobre o tema (Wayland) apesar de algumas críticas serem validas.
3 curtidas
Fiquei abismado com isso aqui:
em muitos casos, portar um aplicativo para Linux não é tão difícil. O que as empresas (e os projetos FLOSS também!) enfrentam e calcularão os méritos cuidadosamente com antecedência é se vale a pena o custo de suporte, bem como o controle de qualidade/testes contínuos. Sua equipe terá que fazer todo esse trabalho e, afinal, eles poderão gastar esse tempo em outras tarefas.
Portanto, se eles aprenderem que “portar para Linux” não significa apenas testes e suporte adicionais, mas também significa escolher entre o servidor de exibição legado X11 que permite portabilidade 1:1 do Windows ou os “novos” compositores Wayland que não suportam o mesmos recursos de que precisam, eles rapidamente considerarão que não vale a pena o esforço. Eu vi isso acontecer.
É claro que muitos aplicativos usam um kit de ferramentas multiplataforma como o Qt, o que simplifica bastante a portabilidade. Mas isso apenas move o problema uma camada para baixo, já que agora o kit de ferramentas precisa abstrair o Windows, o macOS e o Wayland. E o Wayland não contém recursos para fazer certas coisas ou as faz de maneira muito diferente do Windows, por exemplo, então os kits de ferramentas não têm como realmente implementar a funcionalidade existente de uma forma que funcione em todas as plataformas. Portanto, na documentação do Qt você encontrará frequentemente textos como “funciona em qualquer lugar, exceto em compositores Wayland ou dispositivos móveis” 4 .
Muitos pedaços faltantes ou comportamentos alterados são apenas cortes de papel , mas se somam. E se os utilizadores tiverem uma experiência pior, isso traduzir-se-á em mais trabalho de suporte, ou em pessoas que não queiram utilizar o software na respetiva plataforma.
O que está a faltar?
Posicionamento da janela
Aplicações SDI com múltiplas janelas são muito populares no mundo científico. Para aquisição de dados (por exemplo com microscópios) muitas vezes temos um monitor com elementos de controle e outro maior com a imagem gravada. Existem também outras configurações onde múltiplas modalidades de sinal são adquiridas, e o experimentador alinha as janelas exatamente da maneira que deseja e espera que o layout seja armazenado e carregado ao reabrir a aplicação. Mesmo na imagem do Adlershof Technology Park acima você pode ver esse estilo de design de UI, em megaescala. Ser capaz de destacar elementos como janelas de um aplicativo de janela única para movê-los livremente é outro paradigma usado com frequência e imensamente útil com esses aplicativos complexos.É importante observar que este não é um design legado, mas em muitos casos uma escolha intencional – esses tipos de aplicativos funcionam incrivelmente bem em telas maiores ou em muitas telas e são muito flexíveis (você pode ter qualquer configuração de janela desejada e alternar entre eles usando as (geralmente) ótimas habilidades de gerenciamento de janelas da sua área de trabalho).
É claro que esses aplicativos funcionarão muito mal em tablets e formatos pequenos, mas não é para esse propósito que foram projetados e ninguém os usaria dessa forma.
Presumi com certeza que esses recursos seriam implementados em algum momento, mas quando ficou claro que isso não aconteceria, criei o protocolo ext-placement que teve uma boa discussão, mas acabou sendo rejeitado no xdgnamespace. Em seguida, tentei outra solução baseada no feedback, que acabou não funcionando para a maioria dos aplicativos, e agora propus o xdg-placement (v2) em uma tentativa de talvez ainda concluir algum protocolo com o qual possamos concordar, explorando mais opções antes de pressionar o protocolo existente para inclusão no extnamespace do protocolo Wayland. Enquanto isso, não podemos portar nenhum aplicativo que precise desse recurso e, ao mesmo tempo, estamos mudando desktops e distribuições para o Wayland por padrão.
Restauração da posição da janela
Da mesma forma, um protocolo para salvar e restaurar posições de janelas já foi proposto em 2018, há 6 anos, mas ainda não foi acordado e pode nem mesmo ajudar aplicativos multijanelas em sua forma atual. A ausência deste protocolo significa que os aplicativos não podem restaurar as posições anteriores das janelas e o usuário precisa movê-las para o local anterior repetidamente.Enquanto isso, os kits de ferramentas não podem adotar esses protocolos e os aplicativos não podem usá-los e não podem ser portados para o Wayland sem a introdução de cortes de papel.
[e segue por aí…]
Várias “novidades” que me afetaram, no Wayland, estão associadas com esse tipo de coisa. – Eu imaginava que talvez fossem dificuldades transitórias, que se resolveriam mais à frente – mas isso aí parece indicar que pode demorar muito tempo, ou talvez nunca aconteça.
2 curtidas
Isso é uma questão real mesmo. Não é raro a proposição de protocolos no Wayland virar meio que uma odisseia. Muitas empresas vão simplesmente esperar até estas questões serem resolvidas, por ser muito trabalho para pouco retorno. Neste caso o desenvolvedor até tentou propor um protocolo e não rolou, consigo imaginar a frustração.
Esse artigo (na verdade as respostas) mostram que a “comunidade” Linux perdeu o foco, não é mais uma “comunidade” é mais um “Cada um por si, juta tudo e torce pra dar certo (spoiler nunca dá, quem já fez faculdade sabe)”, o cara escreve um baita artigo mostrando que várias classes de usuários e desenvolvedores é um problema sério, pra obter uma resposta:
Pessoalmente, não vejo isso como um obstáculo. É mais um aborrecimento por enquanto.
E claro não podia faltar o clássico desvio de discussão que mata qualquer discussão:
Simplesmente reclamar que Wayland deveria copiar o X11 não adianta nada. Se copiasse o X11, acabaria na mesma posição e os desenvolvedores acabariam por abandoná-lo da mesma forma. Acho que é bom que a funcionalidade esteja finalmente sendo inserida no software em que deveria estar.
Ignorando completamente os problemas que as pessoas tem, usado a falácia “se funciona pra mim funciona pra todos” ou “o problema Z é em Y não em X” (sendo que Y só tem que lidar com Z porque X não lidou) e no final… nada muda
1 curtida
Concordo, em muitos aspectos.
Muito do que vem sendo feito, conduz a isso: – A dissolução da “solidariedade” entre usuários, desenvolvedores, mantenedores.
Sei que é complicado “manter a filosofia original” e pipipi popopó. – Isso pode servir para acalmar consciências – mas muitas das soluções que vêm sendo adotadas e aplaudidas consistem, sim (a meu ver), em entregar o ouro para tudo que há de mais “anti-GNU-Linux”.
Teoricamente, para essa minha (ou nossa?) crítica ser “válida”, eu deveria “oferecer uma solução” (alternativa). – Bom… só em “teoria”. – Ninguém faz “o GNU-Linux” sozinho. Então, é capcioso, cobrar que quem critica, ofereça uma “solução total”.
2 curtidas
Nos fóruns que vi não tem muita reclamação quanto a migração, parece que até mesmo nos hardwares Nvidia o Plasma 6 com Wayland tem funcionado bem…
Verdade…
Parece que o pessoal só reclama, se atrapalhar os games – ou o uso de 3 monitores com tamanhos e tecnologias diferentes, rá rá rá!
Como troquei o custo de um carro + o custo de uma academia – pelo uso das pernas – comecei a perceber que as pessoas reclamam (e as autoridades consertam) imediatamente, de qualquer buraco no asfalto, e (quase nunca) de buracos nas calçadas, montes de brita e areia nas calçadas, carros estacionados nas calçadas, caminhões fazendo entregas em cima das calçadas, desníveis bruscos nas calçadas etc.
1 curtida
Eu to com medo de atualizar aqui pelo OBS, que até semana passada não tava funcionando nem a pau (testei do testing do arch) e pelo fato de que a resolução da minha placa é quebrado, minha tela é 4K, porém, uso em 1440p, e pelo wayland, não tava dando pra ajustar nada, nem o DPI podia aumentar. Então… A reclamação minha é essa hahaha Ahh tem uns outros detalhes de produtividade que não entra nessa questão, mas enfim… Só resta espera o Arch lançar oficialmente o KDE e quem sabe, ver o que da…
2 curtidas