> - Este projeto me fez lembrar de quando, há 20 anos, eu media o ruído de obras em prédios como se fosse um sismógrafo usando o sensor de detecção de vibração do disco rígido do PowerBook.
> - Fui eu que fiz esse software (SeisMac).
Recentemente, também houve recall adicional destes modelos. Acho que vale a pena conferir uma vez.
A1257 - Power Bank 10K
A1642 - 334 MacGo 10000mAh
A1647 - Power Bank 20,000mAh
A1652 - MagGo Power Bank 10,000mAh
A1681 - Zolo Power Bank 20K
A1689 - Zolo Power Bank 20K
Ao que parece, o único vendido oficialmente no Brasil foi o A1642.
Como a OpenAI anunciou isso primeiro há 2 dias, o impacto acabou sendo menor, e também vi comentários dizendo que foi falta de etiqueta o Alexander Wei, da OpenAI, ter falado antes sem sequer discutir com a IMO.
Como nem houve reconhecimento oficial por parte da IMO e eles já saíram anunciando, disseram também que isso acabou roubando as comemorações e o mérito dos participantes humanos, e não da IA.
Mais exatamente, no caso de implementar o servidor de back-end com Django em um serviço com front e back separados, havia também o incômodo de que, para usar só o lado do back-end, o peso característico do Django por ser tão full stack era um fardo, e me desagradava acabar ficando dependente demais do DRF, que eu usava junto para deixar o Django mais RESTful..
Especialmente a dependência vinda do fato de o próprio DRF estar fortemente amarrado ao Django ORM, além da fragmentação e da possibilidade de acesso ao banco que surgem quando, quanto mais se usa o DRF em vários lugares, mais se torna possível usar Django ORM em qualquer canto, tudo isso me trazia insegurança. Somado a isso, o serializer oferecido pelo DRF, além de fazer jus ao nome com serialização e validação de dados, também acaba tendo papéis e possibilidades que vão além disso; e, quanto mais se usa serializer, mais a separação do MVC vai perdendo o sentido, entre outras coisas.. Aí eu pensava que, se fosse assim, em vez de usar a combinação Django+DRF, seria mais estável implementar o back-end com outro framework. Por isso, na prática, em algum momento passei a escolher FastAPI primeiro.
Às vezes tenho a sensação de que, no grande conceito de dependência de trajetória, está sendo cravado um prego poderoso chamado dependência de LLM. A sensação de que estamos passando de "porque já usamos isso há tempos" para "porque o LLM gosta disso"... no fim, onde isso vai dar?
Que experimento interessante!
Li com prazer hahaha
Mesmo que o desempenho dos LLMs do Google e da OpenAI seja mais ou menos equivalente, é aqui que aparece a diferença de experiência empresarial.
> - Este projeto me fez lembrar de quando, há 20 anos, eu media o ruído de obras em prédios como se fosse um sismógrafo usando o sensor de detecção de vibração do disco rígido do PowerBook.
> - Fui eu que fiz esse software (SeisMac).
O Hacker News é impressionante mesmo...
Que comentário estranho de algum charlatão dizendo que fulano é professor.
Recentemente, também houve recall adicional destes modelos. Acho que vale a pena conferir uma vez.
A1257 - Power Bank 10K
A1642 - 334 MacGo 10000mAh
A1647 - Power Bank 20,000mAh
A1652 - MagGo Power Bank 10,000mAh
A1681 - Zolo Power Bank 20K
A1689 - Zolo Power Bank 20K
Ao que parece, o único vendido oficialmente no Brasil foi o A1642.
https://brand.naver.com/anker/shoppingstory/detail?id=5002071854
OpenAI anuncia desempenho de nível medalha de ouro na Olimpíada Internacional de Matemática (IMO) de 2025
Como a OpenAI anunciou isso primeiro há 2 dias, o impacto acabou sendo menor, e também vi comentários dizendo que foi falta de etiqueta o Alexander Wei, da OpenAI, ter falado antes sem sequer discutir com a IMO.
Como nem houve reconhecimento oficial por parte da IMO e eles já saíram anunciando, disseram também que isso acabou roubando as comemorações e o mérito dos participantes humanos, e não da IA.
Enquanto o Ocidente ganha tempo com questões de PC e privacidade + esforços inúteis...
Um tipo de escrita que é essencial neste momento.
Parece que o qwen lida bem com o coreano.
Já era previsível..
Mais exatamente, no caso de implementar o servidor de back-end com Django em um serviço com front e back separados, havia também o incômodo de que, para usar só o lado do back-end, o peso característico do Django por ser tão full stack era um fardo, e me desagradava acabar ficando dependente demais do DRF, que eu usava junto para deixar o Django mais RESTful..
Especialmente a dependência vinda do fato de o próprio DRF estar fortemente amarrado ao Django ORM, além da fragmentação e da possibilidade de acesso ao banco que surgem quando, quanto mais se usa o DRF em vários lugares, mais se torna possível usar Django ORM em qualquer canto, tudo isso me trazia insegurança. Somado a isso, o serializer oferecido pelo DRF, além de fazer jus ao nome com serialização e validação de dados, também acaba tendo papéis e possibilidades que vão além disso; e, quanto mais se usa serializer, mais a separação do MVC vai perdendo o sentido, entre outras coisas.. Aí eu pensava que, se fosse assim, em vez de usar a combinação Django+DRF, seria mais estável implementar o back-end com outro framework. Por isso, na prática, em algum momento passei a escolher FastAPI primeiro.
Sucesso viral do Soundslice
Inveja de um serviço escolhido pela IA mesmo, haha
Ele aprendeu com algo que eu já vinha usando há muito tempo..
Metáfora perfeita!!
Criei um mandal-art para facilitar a visualização de tudo de uma vez: https://a1bbs.com/view/2w5cpznk6xrh166p3tnqpq.
Alguns anos atrás, também saíram bastante notícias sobre Matrix no GeekNews, mas depois ficou tudo quieto; então era esse o problema.
Às vezes tenho a sensação de que, no grande conceito de dependência de trajetória, está sendo cravado um prego poderoso chamado dependência de LLM. A sensação de que estamos passando de "porque já usamos isso há tempos" para "porque o LLM gosta disso"... no fim, onde isso vai dar?
"Agora você já pode desligar o computador."
Boas-vindas à próxima geração de programadores