Jesus! E eu reclamando quando tem update de uns 20 pacotes no Leap depois de uma semana kkkkkkkkkkkkkkkk
2 curtidas
A única coisa chata, é que o download parece limitado a 4,5 MiB/s, e em geral menos ainda.
Já fiz uma experiência com espelho no Brasil, e triplicou a velocidade, mas depois de algum tempo deu problema e voltei para os repositórios-padrão, que têm redirecionamento. Falta pesquisar mais sobre isso.
Outras distros, facilmente baixam atualizações na faixa de 15 a 33 MiB/s (200+ Mbps), a partir de espelhos no Brasil.
Mas enfim, aproveito esse tempo de download no TW para fazer outras coisas.
2 curtidas
Bom lembrar que o TW é rolling, mas tem pacotes bem granulares/divididos assim como o Debian, então o número de atualizações é bastante exagerado.
Já o Manjaro e o Arch tem pacotes mais “gordos”/consolidados. Eu tenho o mesmo hábito do @frc_kde e raramente passo de 150 pacotes a cada atualização semanal, apesar de certamente baixar a mesma quantidade.
2 curtidas
O correto seria compararmos MB ou MiB de download ─ mas também o espaço adicional ocupado após o upgrade.
No último Domingo, 28 de Fevereiro:
TW 199 packages 713.8 MiB additional 2.7 MiB will be used.
Arch 40 packages 263.06 MiB Net Upgrade Size: 22.25 MiB
Onde “Net size” = “tamanho líquido” (tal como “peso bruto” e “peso líquido”, nas latas de produtos importados).
Eu estou usando o TW como minha distro principal e única kkkkkk Não faço dual boot porque prefiro concentrar minhas atividades numa única distro e caso outra me interesse, começar do zero em um momento oportuno.
Se eu estiver no meio de uma disciplina durante meus estudos ou estiver fazendo um trabalho que durará um período de tempo eu prefiro esperar que tenha uma pausa [férias] ou um encerramento para migrar.
Minha dúvida quanto a atualizar sempre é para o caso de ser mais “recomendável” mesmo esperar uns dias, pra evitar algum possível problema de compatibilidade ou algo do tipo, ou se não tem nada a ver isso.
Tenho exatamente as mesmas preocupações que você ─ (1) Poder me concentrar naquilo que preciso ou quero fazer; (2) Deixar instalação de distros, ou manutenção, para um momento oportuno, em que não me atrapalhe. ─ E é exatamente o que tenho conseguido com dualboot.
Talvez você esteja encarando “dualboot” como algo com a mesma exigência de tempo que ocorre quando se depende de uma “distro única” ─ só que em dobro. ─ Eu encaro dualboot exatamente ao contrário. É algo que não me exige tempo de manutenção. Se acontece qualquer problema, bastam 2 minutos para abrir outra distro e continuar minha atividade anterior.
Nas folgas e intervalos, posso voltar à distro anterior e solucionar aquele problema.
Enquanto isso, vou aprendendo alguma coisa. É um investimento, para não depender de 1 única empresa (usei Kubuntu por 10 anos, e depender da Canonical me incomodava cada vez mais). Para não ser pego de surpresa quando uma comunidade sofre um revés (apertem os cintos, o líder sumiu com as chaves). Ou no caso de uma comunidade dar uma guinada (Sabayon + Funtoo → Moccacino).
Há algum tempo, o Foliate parou de abrir no meu Tumbleweed. Depois, o GoogleEarth também parou de abrir. Agora, TW é uma das 3 distros que me deixaram sem sincronização do Google. ─ Se TW fosse minha “distro única”, essas 3 coisas já me teriam obrigado a parar outras, para solucionar, com maior ou menor urgência.
Em vez disso, passei a usar o Debian testing e o MX Linux KDE.
Pra mim, até parece ironia, pois durante quase 10 anos o Debian (stable!) foi a mais “problemática”, para mim ─ mas não desisti. Mantive em dualboot, tentando nas horas vagas, até que um dia, consegui amansar o bicho.
Youtube-DL está meio capenga no KDE Neon e no Mint 20, imagino que por se tratar de uma versão menos atual. Poderia usar Flatpak, ou instalar via “py” (acho… anotei, para experimentar algum dia). Não há urgência. E de qualquer modo, só faço experiências “localizadas” ─ e não mexo no que está dando certo.
2 curtidas
Honestamente você faz bem… Empilhar complexidades e riscos não é uma boa ideia em sistemas de produção. Usar uma distro rolling e bleeding edge já é uma bela de uma aventura.
Acredito que seria uma preocupação desnecessária considerando que o sistema faz uso de snapshots BTRFS. Outra questão é que pelo planejamento do repositório não ser de longo prazo, você pode acabar tendo mais problemas se deixar as coisas atrasarem muito, na faixa de meses.
3 curtidas
Não tem muito a ver. A maioria das distros tem sistemas de CI nos servidores de pacotes, de modo que, quando um pacote é atualizado, todos os que dependem dele são recompilados para assegurar compatibilidade. Soma-se isso com o fato de que o openSUSE Tumbleweed faz uns testes a mais que outras rolling release não costumam fazer (openQA).
A recomendação para rolling-releases (ao menos o Arch contra-indica) é evitar upgrades parciais (ou seja, escolher o que você quer que esteja na versão mais nova disponível e deixar de lado outros programas/bibliotecas).
(Fora que, salvo se você tiver informação “privilegiada”, você nunca vai saber o momento de “calmaria” para atualizar).
No caso, baixar o youtube-dl “congelado” do GitHub do projeto?
2 curtidas
Olhando por esse ponto, faz muito sentido, nunca pensei por esse lado. Em todo caso, nesse momento, seria inviável por ter pouco espaço de armazenamento, mas é algo que vou considerar quando tiver mais.
Aproveitando, eu realmente adotei o BTRFS pra usufruir dessa funcionalidade, porém ainda não descobrir como usar. Eu vou naquele “YasT instantâneos do sistema (snapper” e ele me diz:
“Não existe nenhuma configuração para o snapper. Você deve criar uma ou mais configurações para utilizar o yast2-snapper. A ferramenta de linha de comando do snapper pode ser utilizada para criar as configurações.”
Eu achei que isso era automático.
Isso é mais do que suficiente pra mim kkkk assim fico mais tranquilo. Muito obrigado!
1 curtida
É normal o TW atualizar tanto assim, as vezes ele baixa 200 MB a cada 2 dias… as vezes baixa 600 MB num dia e 2 GB no outro 
, mas estes casos de 1 GB ou 2 GB são casos raros, ocorrendo em média 1 vez a cada 2 meses, enfim… é normal, por ser Rolling Release somado “por ser openSUSE”, por conta das dependências.
openSUSE é uma distribuição que baixa o software que você pediu + todas dependências + todas recomendações, ou seja, é uma distribuição gorda, com o objetivo de não haver problemas com dependências ausentes, logo, atualizações serão maiores que qualquer outra distribuição.
Em relação ao tempo que você pode atrasar uma atualização… talvez os colegas já responderam aí… mas eu costumo atualizar no mesmo dia que elas surgem, e quando eu esqueço, atualizo no dia seguinte, ou com 2 dias de atraso, e até hoje não tive problemas.
Sou usuário NVIDIA, e tive um problema recentemente:
No dia 24/02, recebi um update enorme, incluindo o “kernel-default”, e assim que reiniciei… tela preta (o que chamamos de TTY).
Meu Plasma não subiu, então reiniciei, e na tela do GRUB fui em “Advanced options” e iniciei pelo kernel anterior à atualização, e o Plasma subiu.
O meu problema foi o driver proprietário NVIDIA presente no repositório comunitário, meu kernel-default atualizou mas o driver não, então tive que aguardar este driver atualizar, para poder usar o kernel mais recente, então eu fiz o seguinte… Para não ficar me preocupando em ir no GRUB toda vez para iniciar o kernel antigo, eu removi o kernel default:
sudo zypper remove kernel-default
Porém, todo dia que chegava um update novo, o bendito kernel-default queria ser instalado novamente, então eu adicionei uma trava nele, para não atualizar mais, com o seguinte comando:
sudo zypper addlock kernel-default
Assim, eu poderia ir atualizando o sistema normalmente, sem me preocupar com o kernel.
No dia 01/03, percebi que meu driver NVIDIA iria atualizar, então eu decidi fazer duas coisas… remover a trava do kernel-default e instalar as atualizações, com os seguintes comandos:
sudo zypper removelock kernel-default
sudo zypper ref && zypper lu && sudo zypper dup
Este último comando faz um refresh na lista de repositórios, lista os updates e pergunta se deseja atualizar, a saída é bem legal (para ver a saída, clique para expandir), você pode usá-la em seu Tumbleweed na próxima vez.
Enfim… Por conta da minha NVIDIA, fiquei 5 dias usando o kernel antigo, aguardando atualizarem o driver proprietário, não foi um problema crítico, visto que a solução alternativa foi apenas usar uma versão de kernel anterior, mas levei um susto no começo, e tem gente que pode acabar achando que “o sistema quebrou” e formatar só por isso (e se formatasse daria no mesmo).
4 curtidas
Se encontrar um modo simples de ativar os Snapshots pelo YaST2, me avise. ─ Tentei pesquisar, ler, e fazer tudo por comandos, e não me arrependo, pois acabei aprendendo alguma coisa. ─ Mas foi um longo processo (certo, não fiquei obcecado para fazer tudo com urgência), preservando a instalação original do openSUSE.
Por algum motivo, meu TW instalado em Janeiro 2020 (novo PC) também não ativou a geração automática de snapshots. ─ O que registrei na época:
2020-01-12 23:16 — YaST2 disse que não havia arquivo de configuração:
Querying snapper snapshots failed:
org.freedesktop.DBus.Error.Failed; caused by 3 sender=:1.88 -> dest=:1.87 serial=6 reply_serial=9 path=; interface=; member= error_name=error.unknown_config
O Snapper estava desabilitado nas configurações do YaST2 ─ mas acho que não mexi nisso, naquele momento:
# cat /etc/sysconfig/yast2
(...)
# Enable use of snapper for YaST.
USE_SNAPPER="no"
(Acho que não mexi, porque ainda não estava entendendo nada).
O comando Snapper não encontrava nenhum Snapshot, nem nenhum arquivo de configuração:
# snapper list
The config 'root' does not exist. Likely snapper is not configured.
See 'man snapper' for further instructions.
# snapper list-configs
Config | Subvolume
2020-01-13 00:12 ------ Criar configuração snapper para root:
# snapper create-config /
# snapper list-configs
Config | Subvolume
-------+----------
root | /
# snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------+------+---------+-------------+---------
0 | single | | | root | | current |
Para testar, instalei um pacote ─ e o Snapper criou um par de Snapshots (antes e depois):
# zypper install speedtest-cli
(...)
# snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------------------------------+------+---------+--------------+-------------
0 | single | | | root | | current |
1 | pre | | Mon 13 Jan 2020 00:19:58 -03 | root | number | zypp(zypper) | important=no
2 | post | 1 | Mon 13 Jan 2020 00:19:59 -03 | root | number | | important=no
Não gostei, pois achei que deveria existir um “1 | single” ali no meio.
Deletei os 2 snapshots com o parâmetro --sync para sincronizar o sistema de arquivos após a remoção.
# snapper delete --sync 1 2
# snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------+------+---------+-------------+---------
0 | single | | | root | | current |
Para criar o Snapshot “single” inicial ─ dando um nome útil:
# snapper create --description "Snapshot 1 de 2020-01-13"
# snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------------------------------+------+---------+--------------------------+---------
0 | single | | | root | | current |
1 | single | | Mon 13 Jan 2020 00:27:20 -03 | root | | Snapshot 1 de 2020-01-13 |
(Acho que faltou alguma coisa, pois no antigo PC o primeiro Snapshot sempre era assinalado por um asterisco, indicando que não poderia ser deletado, até ser substituído por outro Snapshot “inicial”).
Para ver as configurações do Snapper para o Root:
# cat /etc/snapper/configs/root
Resolvi reduzir a quantidade de snapshots “comuns” (não-importantes):
2020-01-13 00:51:13
# cat /etc/snapper/configs/root | grep "NUMBER_LIMIT"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"
# snapper -c root set-config "NUMBER_LIMIT=10"
# cat /etc/snapper/configs/root | grep "NUMBER_LIMIT"
NUMBER_LIMIT="10"
NUMBER_LIMIT_IMPORTANT="10"
Notei que o menu do Grub ainda não oferecia nenhuma opção de carregar Snapshots.
Por motivos que não lembro mais, acabei instalando mais um pacote e sua dependência. ─ Não tenho nenhuma anotação de que isso tenha partido de algum tutorial ou documentação:
# zypper install libqrcodegencpp1 libsnapper5
Em seguida, documentei os pacotes instalados naquele momento:
$ date
Tue 14 Jan 01:11:09 -03 2020
$ rpm -qa | grep grub
ruby2.6-rubygem-cfa_grub2-2.0.0-1.1.x86_64
grub2-branding-openSUSE-84.87.20191004-3.5.noarch
grub2-systemd-sleep-plugin-2.04-3.2.noarch
grub2-2.04-3.2.x86_64
grub2-x86_64-efi-2.04-3.2.noarch
grub2-snapper-plugin-2.04-3.2.noarch
grub2-i386-pc-2.04-3.2.noarch
$ rpm -qa | grep snapper
yast2-snapper-4.2.0-1.1.x86_64
libsnapper5-0.8.8-1.1.x86_64
snapper-zypp-plugin-0.8.8-1.1.x86_64
grub2-snapper-plugin-2.04-3.2.noarch
snapper-0.8.8-1.1.x86_64
A certa altura, habilitei SAVEDEFAULT no arquivo /etc/default/grub e, depois de atualizar o Grub, ele passou a oferecer um menu de Snapshots no final.
# date && grub2-mkconfig -o /boot/grub2/grub.cfg && date
Tue 14 Jan 01:55:07 -03 2020
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-5.4.7-1-default
Found initrd image: /boot/initrd-5.4.7-1-default
Found Fedora 31 (KDE Plasma) on /dev/sda5
Found KDE neon User Edition 5.17 (18.04) on /dev/sda6
Found PCLinuxOS on /dev/sda7
done
Tue 14 Jan 01:55:16 -03 2020
O acesso ao submenu de Snapshots fica no final do Grub, abaixo de todas as outras distros.
O submenu é enjoado. Tudo é openSUSE, tudo é Tumbleweed, tudo é 5.4.7-1… O que interessa, é difícil de ler e interpretar ─ data grudada com a hora… em UTC!
Além dos manuais # man snapper (e outros), devo ter recorrido a estas páginas:
- Tutorial Snapper
- Snapper FAQ
- Configurações do Snapper
- System Recovery and Snapshot Management with Snapper
- Snapper - Arch Wiki
- Snapper - Gentoo
Um mês depois, entrei num Snapshot (pelo Grub), para “voltar atrás” da instalação de um pacote, e o Rollback não funcionou.
# snapper rollback
Creating read-only snapshot of default subvolume.IO Error (.snapshots is not a btrfs subvolume).
Aliás, eu estando “dentro” daquele Snapshot, o comando snapper ls não mostrava nenhum Snapshot!
Faltava incluir o subvolume BtrFS /.snapshots no fstab!
Depois de bater cabeça e pesquisar bastante, cheguei a este comando, que fez aparecerem de novo os Snapshots:
# mount -o subvol=@/.snapshots /dev/sda2 /.snapshots
Eu ainda estava dentro do Snapshot nº 233 ─ assinalado por um sinal “-” (menos).
# snapper ls
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
-----+--------+-------+------------------------------+------+----------+--------------+--------------
0 | single | | | root | | current |
1 | single | | Sun 19 Jan 2020 18:00:11 -03 | root | timeline | timeline |
7 | pre | | Thu 23 Jan 2020 09:54:03 -03 | root | number | zypp(zypper) | important=yes
...
231 | single | | Thu 13 Feb 2020 17:00:01 -03 | root | timeline | timeline |
232 | single | | Thu 13 Feb 2020 18:00:01 -03 | root | timeline | timeline |
233- | pre | | Thu 13 Feb 2020 18:00:48 -03 | root | number | zypp(zypper) | important=no
234 | post | 233 | Thu 13 Feb 2020 18:00:58 -03 | root | number | | important=no
Depois disso, finalmente funcionou o “volta atrás”:
# snapper rollback
Creating read-only snapshot of default subvolume. (Snapshot 243.)
Creating read-write snapshot of current subvolume. (Snapshot 244.)
Setting default subvolume to snapshot 244.
Tentei adicionar o subvolume BtrFS no /etc/fstab, mas não foi possível dentro de um read-only snapshot:
UUID=e93c93ad-8397-4e94-bb26-26c769b1ee1d /.snapshots btrfs subvol=@/.snapshots 0 0
Reiniciei, no Grub escolhi a opção principal do openSUSE, e assim entrei no novo subvolume-padrão ─ mas, de novo, o Snapper não listou nenhum Snapshot. ─ Ok, montar o subvolume:
# mount -o subvol=@/.snapshots /dev/sda2 /.snapshots
E lá estava o novo “Snapshot inicial” ─ nº 244, cópia do nº 233 ─ devido aos vários “single” criados ao longo daquelas horas de tentativas.
# snapper ls
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
-----+--------+-------+------------------------------+------+----------+-----------------------+--------------
0 | single | | | root | | current |
1 | single | | Sun 19 Jan 2020 18:00:11 -03 | root | timeline | timeline |
7 | pre | | Thu 23 Jan 2020 09:54:03 -03 | root | number | zypp(zypper) | important=yes
21 | pre | | Thu 23 Jan 2020 22:45:27 -03 | root | number | zypp(zypper) | important=yes
...
231 | single | | Thu 13 Feb 2020 17:00:01 -03 | root | timeline | timeline |
232 | single | | Thu 13 Feb 2020 18:00:01 -03 | root | timeline | timeline |
233 | pre | | Thu 13 Feb 2020 18:00:48 -03 | root | number | zypp(zypper) | important=no
234 | post | 233 | Thu 13 Feb 2020 18:00:58 -03 | root | number | | important=no
235 | single | | Thu 13 Feb 2020 19:00:01 -03 | root | timeline | timeline |
236 | single | | Thu 13 Feb 2020 20:00:01 -03 | root | timeline | timeline |
237 | single | | Thu 13 Feb 2020 21:00:01 -03 | root | timeline | timeline |
238 | single | | Thu 13 Feb 2020 22:00:01 -03 | root | timeline | timeline |
239 | single | | Thu 13 Feb 2020 23:00:01 -03 | root | timeline | timeline |
240 | single | | Fri 14 Feb 2020 00:00:01 -03 | root | timeline | timeline |
241 | single | | Fri 14 Feb 2020 01:00:01 -03 | root | timeline | timeline |
242 | single | | Fri 14 Feb 2020 13:00:22 -03 | root | timeline | timeline |
243 | single | | Fri 14 Feb 2020 13:03:02 -03 | root | number | rollback backup | important=yes
244* | single | | Fri 14 Feb 2020 13:03:03 -03 | root | | writable copy of #233 |
Então, deletei todos os Snapshots que não interessavam mais:
# snapper delete --sync 1 7 21 25 30 78 105 169 198 202 207 208 209 224 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242
# snapper ls
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
-----+--------+-------+------------------------------+------+----------+-----------------------+--------------
0 | single | | | root | | current |
243 | single | | Fri 14 Feb 2020 13:03:02 -03 | root | number | rollback backup | important=yes
244* | single | | Fri 14 Feb 2020 13:03:03 -03 | root | | writable copy of #233 |
A ocupação da partição de sistema caiu de 26,7 GiB para 14,7 GiB.
Esse é um recurso que uso para limpar a partição: (1) Instalo um pacote, digamos KPat; (2) Entro no Snapshot “pré”; (3) Faço rollback; e (4) Deleto todos os Snapshots mais antigos.
Finalmente, incluí no fstab:
UUID=e93c93ad-8397-4e94-bb26-26c769b1ee1d /.snapshots btrfs subvol=@/.snapshots 0 0
Em seguida, montar tudo:
# mount -a
Esse exagero de Snapshots “single” ─ de hora em hora! ─ não existia no antigo PC, onde eu tinha instalado o Leap e depois fiz upgrade para TW, e usei por 3 anos.
Naquela instalação, o Snapper veio funcionando desde o início, não tive trabalho algum ─ e também não aprendi nada, além de deletar Snapshots.
Esse exagero de “single” é inútil para mim, mas uma vez tentei desabilitar, acabou desabilitando também os pre / post do zypper, então desfiz a mudança.
Em 7 Março 2020, parece que ainda não estavam sendo eliminados automaticamente:
systemctl status snapper-cleanup
● snapper-cleanup.service - Daily Cleanup of Snapper Snapshots
Loaded: loaded (/usr/lib/systemd/system/snapper-cleanup.service; static; vendor preset: disabled)
Active: inactive (dead) since Sat 2020-03-07 12:36:23 -03; 35min ago
TriggeredBy: ● snapper-cleanup.timer
Docs: man:snapper(8)
man:snapper-configs(5)
Main PID: 3799 (code=exited, status=0/SUCCESS)
2020-03-07 13:14:58 --- pediu senha (claro).
$ systemctl start snapper-cleanup
systemctl status snapper-cleanup
● snapper-cleanup.service - Daily Cleanup of Snapper Snapshots
Loaded: loaded (/usr/lib/systemd/system/snapper-cleanup.service; static; vendor preset: disabled)
Active: inactive (dead) since Sat 2020-03-07 13:14:25 -03; 1min 19s ago
TriggeredBy: ● snapper-cleanup.timer
Docs: man:snapper(8)
man:snapper-configs(5)
Process: 16597 ExecStart=/usr/lib/snapper/systemd-helper --cleanup (code=exited, status=0/SUCCESS)
Main PID: 16597 (code=exited, status=0/SUCCESS)
No início de Maio 2020 o openSUSE começou a carregar sem montar todos os subvolumes ─ senão sempre, pelo menos muitas vezes:
# mc
Failed to run:
Cannot create /root/.config/mc directory
# date && snapper ls
Sat 2 May 15:29:51 -03 2020
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
---+--------+-------+------+------+---------+-------------+---------
0 | single | | | root | | current |
# history
1 2020-05-02_15-29-10 mc
2 2020-05-02_15-29-51 date && snapper ls
3 2020-05-02_15-31-10 history
# ls -n /root
total 0
De Maio até Novembro 2020, tive de testar a montagem e, se necessário, executar # mount --all. ─ Depois, parece que consertou espontaneamente.
Na virada do ano, tornei a instalar um pacote inútil, entrar no Snapshot anterior a ele, e fazer outro Rollback.
# snapper delete --sync 244 2123 2124 2125 2126 2127 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145
# date; snapper ls
Wed 6 Jan 20:37:56 -03 2021
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
------+--------+-------+------------------------------+------+----------+------------------------+---------
0 | single | | | root | | current |
2146* | single | | Thu 31 Dec 2020 20:31:37 -03 | root | | writable copy of #2139 |
2147 | single | | Thu 31 Dec 2020 21:00:05 -03 | root | timeline | timeline |
Dessa vez, a ocupação da partição raiz caiu de 28,0 para 20,7 GiB.
3 curtidas
Uso OpenSUSE Tumbleweed há quase um ano e nunca tive problemas do sistema dar tela preta ou qualquer coisa parecida.
Porém, já tive um problema com o Wine que simplesmente não funcionava, muito tempo de pois de alguma atualização voltou a funcionar, já tive um problema com o lutris também, que estava faltando uma dependência e o último problema que já atrapalhou muito mais do que os outros dois foi com o “subtitle composer” que simplesmente fechava por algum motivo, é isso me atrapalhava num nível muito grande porque tinha vezes que eu tinha que refazer legendas por completo, lembro que eles corrigiram esse erro alguns dias de pois.
Pelo menos eu acho bem poucos erros para uma distro rolling releases.
1 curtida
Me enganei, não é “py”, é pip.
sudo -H pip install --upgrade youtube-dl
Ainda não li o suficiente, nem testei, por isso não tenho muita certeza sobre isso.
- Da página do YTDL
- Instalando o pip
- Documentação do pip
Salve, galera! Alguém aí usa o WPS Office (em especial se for no TW)? Estou tentando instalar a tradução PT-BR e até agora não consegui. Já joguei o dicionário na pasta /dicts, porém não aparece no programa. Meio arriscado usar um software de escrita sem dicionário, tem coisa que a gente deixa passar.
Gosto do WPS porque ele é bem compatível com arquivos doc e docx e me salvou há um tempo atrás num perrengue universitário haha então por enquanto ele tem moral comigo.
Observação: esse post bem que poderia virar um “Discussão sobre openSUSE” já que estamos em 2021 kkkkkkkk
Pessoal, não sei porque mas o Google Chrome está bloqueando o download da ISO do openSUSE Tumbleweed, tem que forçar o download clicando com o botão direito e “Salvar como…”, depois ainda tem que pedir para manter o arquivo, muito estranho.
Comigo também aconteceu isso hoje, bem estranho realmente, e tive que baixar em aba anônima, dessa forma foi.
Fiz o teste aqui no Chrome, também não consegui baixar pelo Site Oficial, eu clico no botão para baixar e nada acontece.
Cliquei com o botão direito do mouse > Abrir link em janela anônima, e funcionou o download.
Acho que está ligado a isso:
Os mirrors brasileiros do openSUSE (pelo menos o da UFPR) usam HTTP e não HTTPS, e o Chrome não inicia mais downloads HTTP automaticamente, especialmente quando eles são iniciados por uma página HTTPS (caso do get.opensuse.org).
Os tais “motivos de segurança” contra downloads assim são os mesmos da pressão dos navegadores contra HTTP em geral (facilidade de fraudar a identidade de um site, facilidade de outros membros da rede bisbilhotarem, etc.).
Essas preocupações são menos relevantes nesse caso, só verificar a autenticidade da ISO com SHA e/ou GPG e tranquilo (isso inclusive garante que o mirror/espelho não foi invadido, coisa que o HTTPS não te protegeria contra).
2 curtidas
Será que alguém consegue avisá-los? Basta usarem o Let’s Encrypt que resolve o problema, esse pequeno detalhe pode atrapalhar/desanimar alguém que esteja interessado em usar o sistema.
1 curtida
Ver se @Daigo tem algum contato na UFPR que pode ver isso, o mirror deles do Arch Linux também é HTTP…
2 curtidas