https://nitter.cf/t.co/6jRutcDWjK Про нженерию: 🇬🇧 @bunopus_en
Lisbon, Portugal
Joined October 2014
- Tweets24.1K
- Following308
- Followers15.1K
- Likes20.1K
Pinned Tweet
Надоело годами писать в стол, завел себе soundcloud для музыкальных экспериментов, буду выкладывать потихоньку что накопилось soundcloud.com/bunopus
Как я освободил 1 ТБ на Маке, или почему не стоит перекидывать файлы с SD-карты прямиком в папку на Google Drive в проводнике.
Я копировал кое-какие штуки на MacBook 2 ТБ, и он выдал, что диск заполнен на 95%, осталось 106 ГБ. Что странно, я-то думал, что у меня еще полно места!
Запустил sudo ncdu /, без папки Google Drive (и это было ошибкой), потому что смысл считать кэшированные файлы, они потом сами удалятся, и все мои файлы потянули примерно на 840 ГБ. Но система показывала 1.7 ТБ занятого места.
Но по идее Google Drive не может занимать столько места, я использую его в режиме потоковой передачи (Stream), так что на диске лежит только кэш. Когда открываешь файл, он скачивается на лету. А через какое-то время система должна его удалять.
Я проверил, и да, Google Drive весил 1 ТБ, можете проверить, оно лежит по адресу ~/Library/CloudStorage/[email protected].
В общем, вот что произошло. У меня есть небольшой подкаст, и после каждого выпуска я доставал SD-карты из камер и перетаскивал исходники в папку внутри Google Drive. Мультикам, от 8 до 11 ГБ на файл, где-то по 60 ГБ за эпизод. Диск всё это загрузил в облако, как и положено. А потом просто... оставил локальные копии.
Ни один файл не был отмечен как «Доступен офлайн». В macOS можно проверить статус синхронизации файлов, и для каждого из них значилось: downloaded=1, keep_offline=0, uploaded=1.
Оказывается, очистка кэша Диска в потоковом режиме работает только для тех файлов, которые он скачал для вас. Файлы, которые вы создали локально, попадают в другую категорию — «это файл пользователя, не трогать», и оттуда их ничто не удаляет. С другой стороны, Apple встроила механизм вытеснения (eviction) в macOS и добавила пункт меню «Удалить загрузку» (Remove Download), но автоматически очищает место только для iCloud. В случае со сторонними провайдерами она ждет, пока решение примет провайдер. А Google ждет macOS 🙄
На странице справки Google написано, что «в новых версиях macOS система сама управляет кэшем контента», и вы не можете задать лимит размера. В документации Apple описано, как удалять загрузки вручную, и ни слова о том, что это делается автоматически. Старое правило про ограничение кэша в 20% от объема диска явно «не применяется к macOS 12.1 и новее».
Технически это можно исправить, кликнув правой кнопкой мыши по закэшированному файлу или папке и нажав «Удалить загрузку». Моя проблема заключалась в том, что у меня было около 400 файлов в куче папок и подпапок, а опция на уровне корневой папки появляется только тогда, когда всё внутри нее уже скачано. Команды для терминала или API для этого тоже нет. Спасибо LLM, я набросал небольшой AppleScript, который управляет Finder, вычистил их все и вернул свой 1 ТБ.
Урок: Или загружайте файлы через браузер, или проверяйте их статус если копируете через Файндер. Если что - статус файла можно понять по иконке облака рядом с именем. Если "облачко" есть - то файл онлайн, а не на диске.
Если вы используете Drive в потоковом режиме и места не хватает, откройте терминал и выполните эту команду внутри папки Диска:
find . -type f ! -flags +dataless -exec stat -f '%z %N' {} + | sort -rn | head
Всё, что она выведет, лежит на вашем SSD.
Мотивация через успех, особенно в детском возрасте - скользкая дорожка
Сначала делаешь внутренние тулзы, потом вас укрупняют в платформенную команду, а потом уже тебя звонят продакт менеджеры в ночи потому что продуктовым командам срочно нужен сборщик под старую версию Nodejs. Нихрена не peacefull life, не ведитесь
Evgeny Kot retweeted
Today we're releasing Air Governance.
For CTOs and tech leads: track AI usage, manage access, policies and spend org-wide.
Any LLM provider. Any dev tool. Truly vendor-agnostic.
Top-ups, guardrails, AI metrics, sessions.
Battle-tested at JetBrains. Can't imagine going back.
Есть две проходки на podlodka.io/tlcrew. Отдам первым двум комментаторам
Evgeny Kot retweeted
We connected IntelliJ IDEA’s code intelligence to Claude Code and Codex, then tested the setup with Netflix.
The first public results are out.
Typical efficiency gains: 20–30%.
Best code-navigation case: ~65%.
These results come from two real codebases. The efficiency metric averages token savings and time savings.
Correctness stayed stable or improved.
Here’s what we actually built.
The code engine behind IntelliJ IDEA ran headlessly, giving agents access to its capabilities through a CLI backed by a daemon.
LSP alone wasn’t sufficient.
Agents needed a convenient way to invoke the tools. The backend also needed to stay running and keep the project index warm between calls.
The idea is straightforward.
An IDE has already mapped the structure of your code and its dependencies — including what’s inside compiled libraries.
An agent can use that knowledge instead of spending time and tokens reconstructing it.
But the most interesting finding was which models benefited most.
The strongest models saw the biggest gains.
Especially at higher reasoning effort.
In these experiments, more capable models were also better at taking advantage of code intelligence.
My takeaway: better models and better tools aren’t competing bets.
You don’t have to choose between investing in model intelligence and giving agents better access to your codebase.
The two can reinforce each other.
Huge thanks to @pbakker and the Netflix team for working with us on this!
Вот это я знатно труханул сегодня. Сижу в самолёте, уже вырулили на полосу, начинаем разгоняться, вдруг народ сзади начинает кричать "огонь, огонь!" Смотрю в окно, а у нас из под крыла дым валит. Остановились на взлётной, приехала пожарка, все дела. В итоге откатили нас куда-то, всех высадили, но оказалось ничего страшного. Рейс заменили, но с опозданием на 3 часа. Что ж, лучше уж так 🤷
