Parece que não é exatamente uma tradução literal, sem interpretações, como normalmente se espera de um tradutor.

Testei com o texto de apresentação do Claude Cowork. Como abaixo, surgiram emoji e marcadores de lista.


(Original)
How is using Cowork different from a regular conversation? In Cowork, you give Claude access to a folder of your choosing on your computer. Claude can then read, edit, or create files in that folder. It can, for example, re-organize your downloads by sorting and renaming each file, create a new spreadsheet with a list of expenses from a pile of screenshots, or produce a first draft of a report from your scattered notes.

(Traduzido com ChatGPT)

🧠 Diferença entre o Cowork e uma conversa comum

No Cowork, você concede ao Claude permissão para acessar uma pasta específica no seu computador, escolhida por você. O Claude pode ler, editar e até criar novos arquivos nessa pasta.
Por exemplo, o Claude pode

  • organizar e renomear os arquivos da pasta de downloads,
  • extrair gastos de vários screenshots para criar uma nova planilha, ou
  • redigir um rascunho inicial de relatório com base em anotações dispersas.
 

No texto de impressões sobre o Claude Cowork escrito por Simon Willison também havia preocupação com ataques de prompt injection, mas foi rápido.

 
terger24 2026-01-15 | comentário pai | em: O RSA foi derrubado. (threads.com)

Acho que seria melhor filtrar para impedir completamente o envio de certos domínios.

 
winmain 2026-01-15 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Isso depende da capacidade do compilador.

Se montar o mesmo código em assembly, dá para ver o resultado.

 
jjw9512151 2026-01-15 | comentário pai | em: Rust é mais rápido que C? (steveklabnik.com)

Parece que o pessoal do ffmpeg acha que Rust não é mais rápido que C mesmo kkk https://www.memorysafety.org/blog/rav1d-perf-bounty/

 

Continuo usando o Gemini; logo após o lançamento ele era realmente muito bom, mas com o passar do tempo a inteligência dele está piorando.
Uma das principais causas é a "referência a conversas anteriores", e acho que, se até inteligência personalizada for adicionada, isso vai piorar ainda mais.

 

Na verdade, já é difícil conseguir uma melhora de 2 a 3 vezes refazendo o código inteiro, então obter até 400 vezes de ganho de desempenho simplesmente mudando algumas linhas é realmente impressionante.

 

Impressionante.

Se ficou 2x mais rápido, pode ter sido algo inteligente; se ficou 100x mais rápido, foi só parar de fazer algo idiota.

Acho que não é totalmente falso, mas, quando envolve o kernel, imagino que perceber que estava lento já deve ter sido muito difícil.

 

Sei lá. Parece mais algo como a reação negativa de usuários heavy.

 

Foi muito útil 👍👍

 

Que tal separar um dispositivo dedicado só para jogos? Eu quase não jogo, então não faço isso, mas pelo que vejo, quem joga costuma fazer bastante isso.

 

Ah, eu me formei em fevereiro deste ano em um curso da área de computação e ainda estou sem emprego. Uso Linux desde 2015, antes mesmo de começar a estudar desenvolvimento!

 

Parece que a questão de conseguir construir e fornecer a infraestrutura que a Apple queria também deve ter influenciado bastante a escolha.

 

Bom, no fim das contas, embora isso não tenha sido mencionado diretamente nesta matéria, acabou sendo praticamente uma admissão de que fracassou a estratégia da Apple de construir internamente, dentro do ecossistema da própria Apple, o ambiente de IA no nível que ela queria... (depois do Apple Car também). Fico pensando como teria sido se tivessem sido uns 2 anos mais rápidos.

 

Obrigado pelos materiais detalhados e pelo resumo. No começo, achei que fosse algo semelhante às Capabilities do Linux, mas então é uma abordagem que inclui até análise dinâmica.

 

Pedi para o Gemini explicar. Eu também não sou da área de segurança, então não sei ao certo.

[Relatório aprofundado: a tecnologia de segurança de próxima geração em que PyPI e OpenSSF estão de olho, "Capability Analysis"]

À medida que os ataques à cadeia de suprimentos que ameaçam o ecossistema de código aberto ficam mais sofisticados, o PyPI (Python Package Index) e a OpenSSF (Open Source Security Foundation) estão acelerando a adoção de "Capability Analysis" (análise de capacidades/funcionalidades), indo além das abordagens tradicionais de correspondência de padrões.

O ponto central dessa tecnologia é enxergar não “o que o pacote finge ser”, mas “o que ele realmente é capaz de fazer”.

  1. O que é Capability Analysis (análise de funcionalidades)?

Se a varredura antivírus tradicional funciona comparando uma “lista de procurados” (assinaturas conhecidas de malware), a Capability Analysis verifica a “capacidade de comportamento” do pacote.

Por mais que ele se disfarce como um utilitário legítimo, para assumir o controle do sistema ou roubar informações ele inevitavelmente precisa usar certos recursos do sistema operacional (rede, arquivos, processos). Essa técnica de análise rastreia se, ao executar o código, o pacote exerce as seguintes "permissões sensíveis" (Capabilities):

  • Rede (Network): o script de instalação transmite dados secretamente para um IP externo (exfiltration) ou tenta se comunicar com ele?
  • Sistema de arquivos (FileSystem): tenta acessar ou modificar arquivos sensíveis como chaves SSH, credenciais da AWS, /etc/passwd etc.?
  • Execução de processos (Execution): executa comandos de shell ou cria subprocessos gerando código dinamicamente (eval, exec)?
  1. Uso real e principais ferramentas de segurança estimadas

Atualmente, projetos da OpenSSF e grupos de pesquisa em segurança estão desenvolvendo e aplicando as seguintes ferramentas em seus pipelines para realizar esse tipo de análise.

A. OpenSSF Package Analysis (projeto oficial)
- Visão geral: projeto liderado pela OpenSSF que realmente instala e executa pacotes publicados no PyPI ou no NPM em um ambiente isolado de sandbox.
- Como funciona: intercepta em nível de kernel as system calls geradas durante a execução do pacote, coletando dados comportamentais como “este pacote tentou se conectar a 192.168.x.x durante a instalação”.
- Stack tecnológica: usa gVisor (sandbox), Strace (rastreamento de system calls) etc.

B. Packj
- Visão geral: ferramenta desenvolvida com base em pesquisas acadêmicas (Georgia Tech etc.), especializada em etiquetar "risky capabilities" (capacidades de risco) de pacotes.
- Como funciona: combina análise estática e dinâmica. Encontra chamadas de APIs sensíveis no código-fonte e analisa os metadados do pacote para determinar, por exemplo, se é um “pacote abandonado” ou um caso de “typosquatting” (falsificação por nome semelhante).
- Característica: detecta combinações anormais de permissões como “este pacote é uma biblioteca de áudio, mas tem funções de comunicação em rede e acesso à agenda de contatos”.

C. GuardDog
- Visão geral: ferramenta de CLI publicada pela Datadog que usa o Semgrep (motor de análise estática) para encontrar padrões maliciosos.
- Como funciona: identifica padrões de código (heurísticas) que implementam “funcionalidades maliciosas”, como código ofuscado oculto no pacote, scripts de mineração ou downloaders de executáveis.

D. Falco & Sysdig
- Visão geral: ferramentas de segurança de runtime para ambientes cloud native.
- Papel: são usadas como motores para detectar em tempo real comportamentos anômalos quando o pacote é executado dentro de um contêiner (ex.: acesso inesperado ao shell, leitura de arquivos sensíveis).

  1. Materiais e links de referência relacionados

Para um entendimento mais profundo dessa tecnologia, você pode consultar os projetos originais e blogs abaixo.

 

Acho que eles provavelmente baixam o pacote, executam o código e fazem coisas como desempacotamento, análise estática e análise dinâmica para ver o que o código faz. Como malware costuma se espalhar desse jeito.

 

Às vezes eu também penso a mesma coisa. Não tem fim.

"Às vezes penso se escolher desenvolvimento de software não foi uma decisão errada
Mesmo depois de virar sênior, ainda exigem estudo e projetos paralelos
Não sei quando vou poder ter hobbies ou vida social"