Há anos que uso mysqld_safe(assim) para --skip-grant-tablespoder redefinir com segurança minha rootsenha do MySQL:
sudo mysqld_safe --skip-grant-tables &
Mas recentemente, ao tentar instalar o MySQL 8.0.36 no Red Hat 8, recebo:
mysqld_safe: command not found
Que diabos? Se o mysqld_safecomando não for encontrado, como devo definir/alterar a rootsenha?
Tenho meu macOS Sonoma (14.3) configurado para atualizar aplicativos automaticamente em segundo plano.
Isso é ótimo! Mas existe alguma maneira de ver quais aplicativos foram atualizados no macOS e quando?
Às vezes seria bom saber o que está instalado e quando, se houver necessidade de depurar problemas com uma atualização.
Até recentemente atualizar para o macOS 13 (Ventura), eu poderia executar este comando Bash para converter uma imagem JPEG em uma string Base64 em um script que uso ocasionalmente:
IMAGE_BASE64=$(base64 -b0 /path/to/image.jpg);
O IMAGE_BASE64valor resultante pode ser usado como variável $IMAGE_BASE64em meu script.
Mas recentemente tentei usar este script novamente no macOS 13 (Ventura) e este base64comando estava falhando com o seguinte erro:
base64: invalid argument -b0
Usage: base64 [-hDd] [-b num] [-i in_file] [-o out_file]
-h, --help display this message
-Dd, --decode decodes input
-b, --break break encoded string into num character lines
-i, --input input file (default: "-" for stdin)
-o, --output output file (default: "-" for stdout)
Mudar o comando a ser usado -iparece resolver o problema:
IMAGE_BASE64=$(base64 -i /path/to/image.jpg);
Mas qual é a diferença entre os dois comandos?
O que estava -b0fazendo antes do macOS 13 (Ventura) que -iestá sendo feito agora no macOS 13 (Ventura)?
Estou executando o FFmpeg versão 4.3.1 — conforme instalado via Homebrew — no macOS Catalina (10.15.7). E esta manhã eu estava executando um comando FFmpeg padrão para usar as legendas de mesclagem MP4 e SRT:
ffmpeg -y -i input.mp4 -i input.srt -c:v copy -c:a copy -c:s mov_text -metadata:s:s:0 language=eng output.mp4
Quando de repente falhou com estas linhas na tela:
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Stream #1:0 -> #0:2 (subrip (srt) -> mov_text (native))
Press [q] to stop, [?] for help
Segmentation fault: 11
Isso é estranho para mim, já que usei exatamente o mesmo comando alguns dias atrás - e até mesmo no passado - sem problemas.
A verificação do próprio arquivo de saída mostra apenas o seguinte como conteúdo; parece ter morrido imediatamente ao criar cabeçalhos para o arquivo de saída:
ftypisomisomiso2avc1mp4freemdat
A verificação de alguns dos meus arquivos MP4 utilizáveis mostra que ftypisomisomiso2avc1mp4freemdattambém faz parte do conteúdo inicial desses arquivos. Mas os arquivos MP4 que funcionam claramente têm cabeçalhos e conteúdo binário além disso.
Por que diabos isso está acontecendo de repente em um comando de cópia / mesclagem de conteúdo tão simples? Este comando não faz nada além de mesclar um vídeo MP4 com legendas sem transcodificação de conteúdo e deve levar menos de um segundo ou mais para fazer seu trabalho.
A única coisa a notar é uma execução regular brew updatee brew upgradecom pouco ou nenhum problema. Mas estou assumindo que uma atualização recente do FFmpeg causou esse problema. Aqui está a saída da versão completa na minha máquina macOS para referência:
ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
built with Apple clang version 12.0.0 (clang-1200.0.32.21)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.1_2 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-videotoolbox --disable-libjack --disable-indev=jack
libavutil 56. 51.100 / 56. 51.100
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
Use -h to get full help or, even better, run 'man ffmpeg'
O que pode ser feito para corrigir isso? Simplesmente esperar que uma nova versão/patch do FFmpeg seja lançada para resolver o problema? Existe talvez um parâmetro que possa ser adicionado a esse comando para garantir que o comando funcione conforme o esperado?
Estou trabalhando com o Ubuntu e preciso encontrar em todos os arquivos do sistema com menos de 7 dias, começa com Le são .txt, em seguida, gerar um arquivo de saída com base nisso.
Isto é o que eu tenho até agora:
nohup find / -type f -ctime -7 -name \*.txt \*L | tee /tmp/log``-`hostname`-`date -I`.log
Mas de alguma forma a saída é
find: paths must precede expression: `*L'
Eu tentei várias maneiras de colocar o Lno script. O que pode ser feito para que isso funcione?
Esta é uma repostagem de uma pergunta excluída de outro usuário . Eu estava postando uma resposta quando de repente eles excluíram a pergunta, por isso estou repostando aqui para poder compartilhar minha solução com outras pessoas.
Versão curta : as imagens HEIC precisam ter dimensões pares. Nas versões anteriores do ImageMagick instalado pelo Homebrew, libheif 1.7.0 usava um truque para arredondar as dimensões da imagem para valores pares para permitir que imagens com dimensões ímpares fossem convertidas.
Agora, o libheif 1.8.0 abandonou esse truque e gera imagens em casos em que o macOS aparentemente não pode abrir, apesar de serem arquivos HEIC válidos.
Enquanto a Apple resolve o que precisa ser feito para corrigir isso, o que pode ser feito nesse ínterim para permitir a conversão limpa de tais imagens de uma forma que permita que o macOS as abra?
Versão mais longa : Tenho usado o ImageMagick para converter pilhas de imagens JPEG de alta resolução para o formato HEIC - para economizar espaço no arquivo e tempos de transferência de dados, mantendo a qualidade - ligado e desligado desde julho de 2020. Estou usando o macOS Catalina 10.5.6 (19G2021) e o ImageMagick foi instalado e atualizado via Homebrew.
No mês passado, algo estranho aconteceu durante a conversão de um pequeno diretório cheio de imagens: imagens aparentemente arbitrárias seriam convertidas em HEIC, mas não consegui abri-las no aplicativo “Preview” ou mesmo no Pixelmator no macOS. Nenhum ícone de visualização foi gerado também. Para tornar as coisas mais estranhas, se eu pegasse aquela imagem HEIC e a convertesse de volta em JPEG, a conversão funcionaria. Portanto, o HEIC era válido de alguma forma, mas não de uma forma que a API nativa do macOS pudesse manipular.
De acordo com este comentário sobre um relatório de problema no repositório ImageMagick , descobriu-se que libheif - a biblioteca que lida com coisas HEIC no ImageMagick - foi recentemente atualizada para 1.8.0 e essa nova versão lida com a conversão de imagens com dimensões ímpares de maneira diferente das versões de libheif 1.7.0 e anteriores. No caso de imagens com dimensões ímpares, ele cria imagens HEIC que usam uma claptransformação de corte (abertura limpa) e o macOS aparentemente não tem ideia de como lidar com isso. E verificando minha pilha de imagens que não podem ser abertas, todas elas têm pelo menos uma dimensão (largura ou altura) em um valor de número ímpar.
Portanto, embora isso seja claramente um problema com o macOS e como ele lida nativamente com arquivos HEIC, o que posso fazer agora para voltar à conversão em massa de imagens que podem ser visualizadas no macOS? O downgrade para libheif 1.7.0 parece confuso e um pouco regressivo.
Se você quiser testar isso por si mesmo, tente este comando usando esta imagem de teste na Wikimedia que tem 3111 de largura por 3333 de altura; apenas renomeie a imagem test.jpegpara isso:
convert test.jpg test.heic
Ou tente fazer o mesmo usando o utilitário libheif heif-encassim:
heif-enc test.jpg -o test.heic
Em ambos os casos, o aplicativo macOS “Preview” – e outros aplicativos – não pode abrir o test.heicarquivo gerado. Mas claramente pode ser convertido de volta para um JPEG como este na linha de comando usando o ImageMagick:
convert test.heic test.jpg
Aprendi a transcodificar vídeo MKV para MP4 com codificação de vídeo HEVC (x265) para tornar os arquivos menores de uma forma que torne tudo compatível com iOS. Mas, embora o processo seja ótimo - e a compactação seja ótima com tamanho de arquivo baixo - quando tento mesclar legendas em um vídeo específico, o vídeo MP4 resultante recebo uma pilha de erros do FFmpeg como este:
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3152805999 / timestamp: 3154741000 is out of range for mov/mp4 format
Estou usando o macOS Mojave (10.15.2) com o FFmpeg 4.2.1 instalado via Homebrew, mas o problema persiste mesmo se eu baixar a compilação noturna (ffmpeg-4.2.1-macos64-static, 20191215-9fe0790) e usar esse binário em vez disso da versão instalada do Homebrew.
O problema é que tenho este vídeo que converti com sucesso em um MP4 com vídeo x264 e áudio AAC no passado e consegui mesclar legendas SRT também no arquivo resultante sem problemas. Mas quando eu crio um MP4 usando vídeo HEVC (x265) hoje da mesma fonte exata, a mesclagem de legendas SRT falha com os erros “pts não tem valor” e “está fora do intervalo para o formato mov/mp4”.
Este é o comando que uso para criar o vídeo MP4 HEVC (x265) a partir de uma fonte MKV:
ffmpeg -i input.mkv \
-map_metadata -1 \
-vf scale=-1:720 \
-c:v libx265 -crf 20 -c:a aac -b:a 128k \
-threads 4 \
-tag:v hvc1 -sn \
-map 0:0 -map 0:1 output_hevc.mp4 \
;
E este é o comando usado com sucesso no passado para mesclar legendas SRT em um MP4 existente sem recodificar:
ffmpeg -i output_hevc.mp4 \
-i input.srt \
-c:v copy -c:a copy \
-c:s mov_text -metadata:s:s:0 language=eng \
output_final.mp4 \
;
Acho que o problema pode ser que em cerca de 50% do vídeo não há legendas; apenas nos segundos 50% do vídeo são necessárias legendas.
O vídeo em questão tem cerca de 2 horas de duração. E nos primeiros 50 minutos, não há necessidade de legendas em inglês. Mas cerca de 50 minutos depois, é quando as legendas começam.
Então as legendas no SRT começam assim:
1
00:52:33,123 --> 00:52:50,123
It was a dark and stormy night…
Mas quando executo o comando FFmpeg acima, a saída é algo como isto; vezes um pouco falsificado para o propósito do exemplo:
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
Stream #1:0 -> #0:2 (subrip (srt) -> mov_text (native))
Press [q] to stop, [?] for help
frame=25560 fps=0.0 q=-1.0 size= 304640kB time=00:52:00.00 bitrate= 791.7kbits/frame=50730 fps=50726 q=-1.0 size= 681984kB time=time=00:52:00.00 bitrate=1772.4kbit[mp4 @ 0x7facb9002000] Application provided duration: 3152137000 / timestamp: 3152137000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3152805999 / timestamp: 3154741000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3153246998 / timestamp: 3156809000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3154051997 / timestamp: 3159013000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3155556996 / timestamp: 3163817000 is out of range for mov/mp4 format
E toneladas de mensagens semelhantes até, et voila! A mesclagem termina, nenhuma legenda é visível e pronto.
Isso está me deixando louco! Quero dizer, se eu usar o mesmo comando, mas especificar um tempo de busca que comece por volta do ponto em que as legendas entram, eu realmente vejo as legendas em 50% do vídeo que precisa delas:
ffmpeg -I output_hevc.mp4 \
-i input.srt \
-c:v copy -c:a copy \
-c:s mov_text -metadata:s:s:0 language=eng \
-ss 3120 \
output_final.mp4 \
;
Mas eu preciso de mais de 50% do vídeo, é claro. Caramba, acabei de tentar este comando; Posso obter as legendas para mesclar com o MP4 se eu definir a busca para qualquer valor igual ou superior a 1005 segundos:
ffmpeg -i output_hevc.mp4 \
-i input.srt \
-c:v copy -c:a copy \
-c:s mov_text -metadata:s:s:0 language=eng \
-ss 1005 \
output_final.mp4 \
;
Mas o que há de tão mágico em 16,75 minutos (1005 segundos) no contexto disso?
FWIW, se eu executar um comando semelhante para criar um MKV do vídeo, tudo bem!
ffmpeg -i output_hevc.mp4 \
-i input.srt \
-c:v copy -c:a copy -c:s copy \
output.mkv \
;
De alguma forma, essa fusão mov_textfaz com que o processo falhe, ao que parece.
E se eu adicionar uma legenda falsa no início do arquivo assim:
0
00:00:00,000 --> 00:16:75,000
Foo!
1
00:52:33,123 --> 00:52:50,123
It was a dark and stormy night…
Tudo funciona como desejado! Exceto por ter a palavra “Foo!” aparecendo em 50% do vídeo. Obviamente não é o ideal.
Existe alguma maneira de contornar isso? Isso é um bug do FFmpeg ou talvez um problema com o vídeo HEVC (x265) com legendas sendo mescladas?
De acordo com alguns relatórios, após a atualização do Chrome no macOS, o sistema torna-se efetivamente “brickado” e não inicializável.
Por que isso aconteceu e o que pode ser feito para colocar a máquina em funcionamento novamente?
Ouvi recentemente que os navegadores Chrome, Firefox, Edge e Brave estarão testando (e implementando?) o uso de DNS sobre HTTPS (DoH) para resolução de DNS em seus navegadores, em vez do DNS tradicional ou mesmo DNS sobre TLS.
O que é DNS sobre HTTPS (DoH) e o que devo saber sobre isso?
Não estou pedindo conselhos sobre compras, mas simplesmente pedindo que, depois de passar mais tempo procurando por esse tipo de coisa do que eu esperava, parece que o principal tipo de hub USB tipo C traduz / converte uma conexão USB tipo C em vários USB Um porto feminino.
Isso faz sentido, dada a popularidade geral e prevalência de cabos e dispositivos USB A existentes atualmente. Mas parece-me que deveria haver pelo menos alguns hubs USB Type-C básicos para vários hubs USB Type-C por aí. Mas não consigo encontrar nenhum.
E por hub USB quero dizer apenas um hub: não me refiro a um desses dongles que é uma verdadeira faca do “Exército Suíço” com muitas conexões - como DVI, portas USB, Ethernet e talvez até uma porta de cartão SD - mas um multiplicador de porta básico.
FWIW, estou perguntando isso porque tenho um MacBook Air (2018) e, para todos os efeitos, não preciso de conexões USB tipo A para muitos dos meus usos diários. Mas ter pelo menos mais 1 a 2 portas USB tipo C seria útil em alguns casos.
Então, há algum tipo de limitação de host/convidado para a especificação do USB Type-C que impede isso ou é simplesmente um tipo de oferta e demanda?