🚨 В открытом GitHub утекло 29 миллионов секретов за прошлый год
Пароли. API-ключи. Токены.
И почти всегда это происходит по одной причине, разработчик просто не заметил.
Есть бесплатный инструмент, который ловит такие вещи ДО релиза.
Называется Trivy.
Одна команда и он проверяет весь твой стек:
контейнеры, код, Kubernetes, cloud - всё сразу.
• Без платных тарифов
• Без продажников
• Без “enterprise only”
Просто запускаешь и получаешь отчёт.
Что он находит:
→ уязвимости во всех зависимостях и пакетах
→ пароли, API-ключи и секреты в коде
→ ошибки конфигурации в cloud и контейнерах
→ проблемы с лицензиями
→ полный список всего, что ты деплоишь
Две строки и у тебя полный security-аудит.
https://github.com/aquasecurity/trivy
🖥 Полезные Linux ресурсы 🚀 Max
@DevOPSitsec
Пароли. API-ключи. Токены.
И почти всегда это происходит по одной причине, разработчик просто не заметил.
Есть бесплатный инструмент, который ловит такие вещи ДО релиза.
Называется Trivy.
Одна команда и он проверяет весь твой стек:
контейнеры, код, Kubernetes, cloud - всё сразу.
• Без платных тарифов
• Без продажников
• Без “enterprise only”
Просто запускаешь и получаешь отчёт.
Что он находит:
→ уязвимости во всех зависимостях и пакетах
→ пароли, API-ключи и секреты в коде
→ ошибки конфигурации в cloud и контейнерах
→ проблемы с лицензиями
→ полный список всего, что ты деплоишь
brew install trivy
trivy image your-app:latest
Две строки и у тебя полный security-аудит.
https://github.com/aquasecurity/trivy
@DevOPSitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10😁10❤4🔥3🤪2👻1
🚀 9 стратегий деплоя, которые реально используют в DevOps
Современные команды выбирают стратегию релиза не «по привычке», а исходя из риска, бюджета и требований к uptime.
Вот база, которую нужно понимать:
1⃣ Recreate Deployment
Старую версию полностью останавливают, потом запускают новую
➝ Плюсы: просто, нет конфликтов
➝ Минусы: есть downtime
➝ Когда использовать: внутренние сервисы, простые системы
2⃣ Rolling Deployment
Обновление происходит постепенно, по инстансам
➝ Плюсы: без даунтайма, плавный rollout
➝ Минусы: одновременно работают разные версии
➝ Где используется: Kubernetes, Docker
3⃣ Blue-Green Deployment
Два окружения: старое (Blue) и новое (Green)
Переключение трафика происходит мгновенно
➝ Плюсы: быстрый rollback, безопасный релиз
➝ Минусы: дорого, сложнее с базой
4⃣ Canary Deployment
Сначала выкатываешь на небольшой % пользователей
➝ Плюсы: раннее обнаружение проблем
➝ Минусы: сложная маршрутизация и мониторинг
➝ Используют: Google, Netflix
5⃣ Shadow Deployment
Продакшн-трафик дублируется на новую версию
➝ Плюсы: тест на реальных данных без риска
➝ Минусы: дорого по ресурсам
6⃣ A/B Testing
Разным пользователям показываются разные версии
➝ Плюсы: решения на основе данных
➝ Минусы: сложная аналитика
➝ Цель: метрики, конверсии, поведение
7⃣ Feature Toggles (Flags)
Функция уже в проде, но скрыта за флагом
➝ Плюсы: мгновенное включение/выключение
➝ Минусы: усложняет код
8⃣ Immutable Deployment
Не обновляешь сервер - создаёшь новый
➝ Плюсы: стабильность, нет «дрейфа конфигурации»
➝ Минусы: дольше и дороже
9⃣ Serverless Deployment
Код выполняется по запросу, без серверов
➝ Плюсы: авто-скейлинг, платишь за использование
➝ Минусы: cold start, зависимость от провайдера
🧠 Вывод:
Нет «лучшей» стратегии
Есть подходящая под твою систему
- хочешь безопасность → Blue-Green / Canary
- хочешь простоту → Rolling
- хочешь контроль → Feature Flags
🔥 Сильные команды комбинируют несколько подходов сразу
🧠 Полезные Devops ресурсы 🚀 Devops в Max
@DevOPSitsec
Современные команды выбирают стратегию релиза не «по привычке», а исходя из риска, бюджета и требований к uptime.
Вот база, которую нужно понимать:
1⃣ Recreate Deployment
Старую версию полностью останавливают, потом запускают новую
➝ Плюсы: просто, нет конфликтов
➝ Минусы: есть downtime
➝ Когда использовать: внутренние сервисы, простые системы
2⃣ Rolling Deployment
Обновление происходит постепенно, по инстансам
➝ Плюсы: без даунтайма, плавный rollout
➝ Минусы: одновременно работают разные версии
➝ Где используется: Kubernetes, Docker
3⃣ Blue-Green Deployment
Два окружения: старое (Blue) и новое (Green)
Переключение трафика происходит мгновенно
➝ Плюсы: быстрый rollback, безопасный релиз
➝ Минусы: дорого, сложнее с базой
4⃣ Canary Deployment
Сначала выкатываешь на небольшой % пользователей
➝ Плюсы: раннее обнаружение проблем
➝ Минусы: сложная маршрутизация и мониторинг
➝ Используют: Google, Netflix
5⃣ Shadow Deployment
Продакшн-трафик дублируется на новую версию
➝ Плюсы: тест на реальных данных без риска
➝ Минусы: дорого по ресурсам
6⃣ A/B Testing
Разным пользователям показываются разные версии
➝ Плюсы: решения на основе данных
➝ Минусы: сложная аналитика
➝ Цель: метрики, конверсии, поведение
7⃣ Feature Toggles (Flags)
Функция уже в проде, но скрыта за флагом
➝ Плюсы: мгновенное включение/выключение
➝ Минусы: усложняет код
8⃣ Immutable Deployment
Не обновляешь сервер - создаёшь новый
➝ Плюсы: стабильность, нет «дрейфа конфигурации»
➝ Минусы: дольше и дороже
9⃣ Serverless Deployment
Код выполняется по запросу, без серверов
➝ Плюсы: авто-скейлинг, платишь за использование
➝ Минусы: cold start, зависимость от провайдера
🧠 Вывод:
Нет «лучшей» стратегии
Есть подходящая под твою систему
- хочешь безопасность → Blue-Green / Canary
- хочешь простоту → Rolling
- хочешь контроль → Feature Flags
🔥 Сильные команды комбинируют несколько подходов сразу
🧠 Полезные Devops ресурсы 🚀 Devops в Max
@DevOPSitsec
🔥6❤3👍1
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Docker за 30 секунд - поймёт даже новичок
Docker кажется сложным, пока не разложишь его на 5 элементов 👇
1. Docker Client
Это то, с чем ты работаешь каждый день:
команды build, push, pull, run
2. Docker Host + Daemon
“Мозг” Docker на машине
- хранит образы
- запускает контейнеры
- управляет всем процессом
3. Docker Registry
Хранилище образов
(например: MySQL, NGINX, Redis)
Ты либо скачиваешь оттуда, либо пушишь свои
4. Images vs Containers
- Image - это шаблон
- Container - это запущенный image
5. Как всё работает вместе
- build → создаешь image
- push → отправляешь в registry
- pull → скачиваешь image
- run → запускаешь container
💡 Вся магия Docker - это просто поток:
Если понимаешь этот flow - понимаешь Docker.
Именно это спрашивают на собеседованиях. #devops #docker #linux
https://www.youtube.com/shorts/y0dNbPCZI6E
🖥 Полезные Linux ресурсы 🚀 Max
@DevOPSitsec
Docker кажется сложным, пока не разложишь его на 5 элементов 👇
1. Docker Client
Это то, с чем ты работаешь каждый день:
команды build, push, pull, run
2. Docker Host + Daemon
“Мозг” Docker на машине
- хранит образы
- запускает контейнеры
- управляет всем процессом
3. Docker Registry
Хранилище образов
(например: MySQL, NGINX, Redis)
Ты либо скачиваешь оттуда, либо пушишь свои
4. Images vs Containers
- Image - это шаблон
- Container - это запущенный image
5. Как всё работает вместе
- build → создаешь image
- push → отправляешь в registry
- pull → скачиваешь image
- run → запускаешь container
💡 Вся магия Docker - это просто поток:
Client → Daemon → Registry → ContainerЕсли понимаешь этот flow - понимаешь Docker.
Именно это спрашивают на собеседованиях. #devops #docker #linux
https://www.youtube.com/shorts/y0dNbPCZI6E
@DevOPSitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
👎6🖕5👍3❤2
Архитектура Docker, если убрать лишнее, выглядит очень просто:
Есть образ (image) - это слепок приложения с зависимостями.
Один раз собрал - запускаешь где угодно.
Есть контейнер (container) - это уже запущенный образ.
По сути изолированный процесс с файловой системой, сетью и настройками.
Docker Engine - сердце всей системы.
Он принимает команды через CLI/API и управляет контейнерами.
Docker Daemon - фоновый процесс, который:
• создаёт контейнеры
• запускает их
• следит за состоянием
Docker Client - то, через что ты работаешь (docker CLI).
Docker Hub / Registry - место, где хранятся образы.
Оттуда ты делаешь pull, туда - push.
Как это работает в реальности:
Ты пишешь Dockerfile →
docker build → получаешь image
docker push → отправляешь в registry
На сервере:
docker pull → скачал
docker run → запустил контейнер
Зачем это:
Одинаковая среда везде (dev = prod)
быстрый деплой без «у меня работает»
изоляция сервисов
масштабирование через контейнеры
Если упростить до одной мысли:
Docker - это не про контейнеры.
Это про предсказуемый запуск кода в любой среде.
https://uproger.com/arhitektura-docker-prosto-o-glavnom-kak-eto-rabotaet-na-samom-dele/
🖥 Полезные Devops ресурсы 🚀 Max
@DevOPSitsec
Есть образ (image) - это слепок приложения с зависимостями.
Один раз собрал - запускаешь где угодно.
Есть контейнер (container) - это уже запущенный образ.
По сути изолированный процесс с файловой системой, сетью и настройками.
Docker Engine - сердце всей системы.
Он принимает команды через CLI/API и управляет контейнерами.
Docker Daemon - фоновый процесс, который:
• создаёт контейнеры
• запускает их
• следит за состоянием
Docker Client - то, через что ты работаешь (docker CLI).
Docker Hub / Registry - место, где хранятся образы.
Оттуда ты делаешь pull, туда - push.
Как это работает в реальности:
Ты пишешь Dockerfile →
docker build → получаешь image
docker push → отправляешь в registry
На сервере:
docker pull → скачал
docker run → запустил контейнер
Зачем это:
Одинаковая среда везде (dev = prod)
быстрый деплой без «у меня работает»
изоляция сервисов
масштабирование через контейнеры
Если упростить до одной мысли:
Docker - это не про контейнеры.
Это про предсказуемый запуск кода в любой среде.
https://uproger.com/arhitektura-docker-prosto-o-glavnom-kak-eto-rabotaet-na-samom-dele/
@DevOPSitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍3🔥2
Forwarded from Machinelearning
Подразделение Research анонсировало TurboQuant, алгоритм векторного квантования, объединяющий 2 других метода - QJL и PolarQuant, который решает проблему увеличения KV-кэша при работе с длинным контекстом.
TurboQuant будет представлен на ICLR 2026, PolarQuant - на AISTATS 2026.
KV-кэш хранит промежуточные представления токенов, чтобы модель не пересчитывала их на каждом шаге генерации. С ростом контекста он превращается в узкое место по памяти.
Обычное векторное квантование сжимает эти данные, но вносит накладные расходы: для каждого блока нужно хранить константы квантования в полной точности, а это плюс 1–2 бита на элемент, что частично обесценивает само сжатие.
Сначала PolarQuant: случайный поворот выравнивает геометрию векторов, после чего они переводятся из декартовых координат в полярные (радиус и угол). Распределение углов оказывается предсказуемым и сконцентрированным, поэтому нормализация и хранение дополнительных констант становятся больше не нужны.
На втором этапе подключается QJL, метод на основе преобразования Джонсона-Линденштраусса, который кодирует остаточную ошибку первого этапа всего одним знаковым битом и через встроенную оценочную функцию сочетает высокоточный запрос с низкоточными сжатыми данными, корректно вычисляя attention score.
Ни один из методов не требует обучения или дообучения и работает в режиме "без предварительного анализа набора данных".
Алгоритмы тестили на бенчмарках для длинного контекста: LongBench, Needle In A Haystack, ZeroSCROLLS, RULER и L-Eval с моделями Gemma и Mistral.
При квантовании KV-кэша до 3 бит TurboQuant показал нулевую деградацию точности на всех задачах: поиск «иголки в стоге сена», QA, генерация кода, суммаризация.
Объем KV-кэша при этом сократился в 6 раз. На H100 четырехбитный TurboQuant ускорил вычисление attention-логитов до 8 раз по сравнению с 32-битными ключами.
Область применения не ограничивается KV-кэшем. В экспериментах с высокоразмерным векторным поиском TurboQuant стабильно превзошел по recall методы PQ и RaBitQ несмотря на то, что те использовали крупные код-буки и подстройку под конкретный датасет.
@ai_machinelearning_big_data
🎯Полезные Мл-ресурсы 🚀 Max
#AI #ML #LLM #TurboQuant #Google
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯4👍3❤2
🔥 Linux Performance & Deep Debugging команды, которые должен знать каждый DevOps-инженер
Когда дашборды уже не помогают - ты идёшь в ОС.
Вот 10 команд, которые реально используют в продакшн-инцидентах:
1. strace -p <PID> -c
→ трассирует системные вызовы процесса и показывает, на чём он завис
2. perf top -p <PID>
→ live-профилирование CPU, сразу видно “горячие” функции
3. tcpdump -i eth0 -w capture.pcap port 8080
→ захват сетевого трафика для глубокого анализа
4. ab -n 10000 -c 100 http://localhost/
→ быстрый нагрузочный тест: 10k запросов, 100 одновременно
5. kubectl debug node/node1 -it --image=busybox
→ подключение к ноде через временный контейнер
6. dmesg -T | grep -i 'oom'
→ проверка OOM kill событий ядра
7. lsof -i :8080
→ какой процесс занял порт
8. iostat -xz 1 5
→ статистика диска в реальном времени
9. vmstat -w 1 5
→ память, swap и CPU в динамике
10. kubectl debug pod/app -it --copy-to=debug-pod --image=nicolaka/netshoot
→ глубокая диагностика сети внутри кластера
Когда всё горит - именно эти команды спасают.
Сохрани перед следующим прод-инцидентом ⚡
Когда дашборды уже не помогают - ты идёшь в ОС.
Вот 10 команд, которые реально используют в продакшн-инцидентах:
1. strace -p <PID> -c
→ трассирует системные вызовы процесса и показывает, на чём он завис
2. perf top -p <PID>
→ live-профилирование CPU, сразу видно “горячие” функции
3. tcpdump -i eth0 -w capture.pcap port 8080
→ захват сетевого трафика для глубокого анализа
4. ab -n 10000 -c 100 http://localhost/
→ быстрый нагрузочный тест: 10k запросов, 100 одновременно
5. kubectl debug node/node1 -it --image=busybox
→ подключение к ноде через временный контейнер
6. dmesg -T | grep -i 'oom'
→ проверка OOM kill событий ядра
7. lsof -i :8080
→ какой процесс занял порт
8. iostat -xz 1 5
→ статистика диска в реальном времени
9. vmstat -w 1 5
→ память, swap и CPU в динамике
10. kubectl debug pod/app -it --copy-to=debug-pod --image=nicolaka/netshoot
→ глубокая диагностика сети внутри кластера
Когда всё горит - именно эти команды спасают.
Сохрани перед следующим прод-инцидентом ⚡
👍11❤4👏3
🚀 Docker сборка: ускорение с 3 минут → до 20 секунд
Маленькое изменение, которое даёт огромный буст 👇
При работе с Docker была проблема:
даже небольшое изменение кода запускало полную пересборку образа.
Причина - Docker Layer Caching
Каждая инструкция в Dockerfile создаёт слой.
Если слой не изменился - Docker берёт его из кэша.
💡 Ошибка:
Копировал весь код до установки зависимостей
В итоге:
любое изменение кода → ломает кэш →
зависимости устанавливаются заново каждый раз
🔧 Фикс:
✔ Сначала копируй файлы зависимостей
✔ Устанавливай зависимости (кэшируется)
✔ Только потом копируй основной код
📉 Результат:
Сборка:
~3 минуты → ~20 секунд
Пересобираются только изменённые слои
Остальное берётся из кэша
💡 Почему это важно:
В CI/CD:
- медленные билды = медленные деплои
- лишние пересборки = лишние деньги
Маленькое изменение в Dockerfile
→ огромный эффект в реальных проектах
Маленькое изменение, которое даёт огромный буст 👇
При работе с Docker была проблема:
даже небольшое изменение кода запускало полную пересборку образа.
Причина - Docker Layer Caching
Каждая инструкция в Dockerfile создаёт слой.
Если слой не изменился - Docker берёт его из кэша.
💡 Ошибка:
Копировал весь код до установки зависимостей
В итоге:
любое изменение кода → ломает кэш →
зависимости устанавливаются заново каждый раз
🔧 Фикс:
✔ Сначала копируй файлы зависимостей
✔ Устанавливай зависимости (кэшируется)
✔ Только потом копируй основной код
📉 Результат:
Сборка:
~3 минуты → ~20 секунд
Пересобираются только изменённые слои
Остальное берётся из кэша
💡 Почему это важно:
В CI/CD:
- медленные билды = медленные деплои
- лишние пересборки = лишние деньги
Маленькое изменение в Dockerfile
→ огромный эффект в реальных проектах
👍7❤4🔥4
Как получить стабильную работу сервисов при росте нагрузки?
Получите производительность выделенного железа в облаке:
✅выделенные ядра обеспечивают стабильную производительность без задержек,
✅управление топологией процессора позволяет адаптировать ресурсы под профиль нагрузки,
✅размещение ресурсов ВМ на одной NUMA-ноде поможет сократить задержки при работе с памятью до 50%,
✅сеть 10 Гбит/с в облаке сокращает время передачи больших объемов данных,
✅лимиты ресурсов до 232 vCPU и 900 ГБ RAM позволяют переносить в облако монолитные системы и ресурсоемкие задачи.
👉 Получите грант до 30 000 бонусов на тест новых возможностей в производительном облаке Selectel: https://slc.tl/4el3q
Реклама. АО "Селектел". erid:2W5zFJEp5tV
Получите производительность выделенного железа в облаке:
✅выделенные ядра обеспечивают стабильную производительность без задержек,
✅управление топологией процессора позволяет адаптировать ресурсы под профиль нагрузки,
✅размещение ресурсов ВМ на одной NUMA-ноде поможет сократить задержки при работе с памятью до 50%,
✅сеть 10 Гбит/с в облаке сокращает время передачи больших объемов данных,
✅лимиты ресурсов до 232 vCPU и 900 ГБ RAM позволяют переносить в облако монолитные системы и ресурсоемкие задачи.
👉 Получите грант до 30 000 бонусов на тест новых возможностей в производительном облаке Selectel: https://slc.tl/4el3q
Реклама. АО "Селектел". erid:2W5zFJEp5tV
Перед вами репозиторий с полноценным визуальным и практическим гайдом по одному из самых мощных инструментов для разработчиков.
Что внутри:
• Пошаговое обучение - от базовых команд (/init, /plan) до продвинутых вещей вроде MCP, хуков и агентов
Осваивается за ~11–13 часов
• Большая библиотека кастомных команд под реальные задачи
• Готовые шаблоны памяти - как для одиночной работы, так и для команд
• Инструкции и скрипты для:
- автокод-ревью
- проверки стиля и стандартов
- генерации API-документации
• Автоматизация через циклы
Можно настроить Claude так, чтобы он работал автономно без вашего участия
• Подключение внешних инструментов
GitHub, API и другие сервисы - всё разложено по шагам
• Объяснения через схемы и диаграммы
Подойдёт даже тем, кто только начинает
• Примеры настройки узкоспециализированных субагентов
• Отдельные скрипты под обучение
Например, генерация книг и материалов для быстрого освоения любой темы
https://github.com/luongnv89/claude-howto
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤3👍3🥰1
Это слои защиты
Можно представить как кольца, которые защищают кластер
5 ключевых уровней:
• API Server Access
контроль доступа к кластеру
• Workload Security
безопасность pod и контейнеров
• Network Security
контроль сетевого взаимодействия
• Image Security
проверка и доверие к образам
• Runtime Security
мониторинг поведения в рантайме
Главая ошибка:
Многие защищают только «снаружи»
и игнорируют то, что происходит внутри кластера
Если один pod скомпрометирован
→ без ограничений он может пойти дальше по кластеру
Безопасность Kubernetes = это система слоёв
А не одна настройка
Разбор всех уровней:
https://devopscube.com/cks-exam-guide-tips/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2
🚀 Топ-12 альтернатив Docker в 2026 году
1. Podman
https://podman.io
2. containerd
https://containerd.io
3. CRI-O
https://cri-o.io
4. runc
https://github.com/opencontainers/runc
5. Buildah
https://buildah.io
6. Kaniko
https://github.com/GoogleContainerTools/kaniko
7. nerdctl
https://github.com/containerd/nerdctl
8. Rancher Desktop
https://rancherdesktop.io
9. OrbStack
https://orbstack.dev
10. LXC / LXD
https://linuxcontainers.org
11. Colima
https://github.com/abiosoft/colima
12. Lima
https://github.com/lima-vm/lima
🧠 Если кратко:
- Podman - без демона, безопаснее
- containerd / CRI-O - уровень Kubernetes
- Buildah / Kaniko - сборка образов без Docker
- OrbStack / Colima - удобная локальная замена Docker
🔥 Docker - не единственный вариант
1. Podman
https://podman.io
2. containerd
https://containerd.io
3. CRI-O
https://cri-o.io
4. runc
https://github.com/opencontainers/runc
5. Buildah
https://buildah.io
6. Kaniko
https://github.com/GoogleContainerTools/kaniko
7. nerdctl
https://github.com/containerd/nerdctl
8. Rancher Desktop
https://rancherdesktop.io
9. OrbStack
https://orbstack.dev
10. LXC / LXD
https://linuxcontainers.org
11. Colima
https://github.com/abiosoft/colima
12. Lima
https://github.com/lima-vm/lima
🧠 Если кратко:
- Podman - без демона, безопаснее
- containerd / CRI-O - уровень Kubernetes
- Buildah / Kaniko - сборка образов без Docker
- OrbStack / Colima - удобная локальная замена Docker
🔥 Docker - не единственный вариант
👍13👎7🥰1😁1
🦀 Rust - 9 лет (2006 → 2015)
🤖 Kotlin - 6 лет (2010 → 2016)
⚙️ C++ - 6 лет (1979 → 1985)
☕ Java - 5 лет (1991 → 1996)
🐹 Go - 5 лет (2007 → 2012)
🍎 Swift - 4 года (2010 → 2014)
🔧 C - 3 года (1969 → 1972)
🧬 Scala - 3 года (2001 → 2004)
📊 Julia - 3 года (2009 → 2012)
🐍 Python - 2 года (1989 → 1991)
🌐 JavaScript - 10 дней (1995)
💎 Ruby - 2 года (1993 → 1995)
🐘 PHP - 1 год (1994 → 1995)
🔷 C# - 2 года (1998 → 2000)
🎯 TypeScript - 2 года (2010 → 2012)
🎯 Dart - 2 года (2009 → 2011)
⚡ Elixir - 2 года (2011 → 2013)
🧠 Haskell - 3 года (1987 → 1990)
🧩 Objective-C - 1 год (1983 → 1984)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🌚2👎1
⚡ Claude Code теперь можно запустить ЛОКАЛЬНО - без подписки и API
Да, звучит как кликбейт. Но нет.
После утечки исходников стало ясно: весь стек можно воспроизвести у себя и гонять на локальных моделях.
Что уже работает:
• Запуск через Ollama - без облака
• Полный агентный цикл: чтение, запись, редактирование файлов
• Bash, grep, glob — всё на месте
• Работа с API и поиск в интернете - Поддержка MCP-серверов
• Память между сессиями
• не теряет контекст - Computer Vision - можно работать с изображениями - Все slash-команды: /commit, /review, /diff, /compact, /doctor - Можно стримить работу на другие устройства
По сути, ты получаешь полноценного AI-разработчика у себя на машине.
https://github.com/Gitlawb/openclaude
Да, звучит как кликбейт. Но нет.
После утечки исходников стало ясно: весь стек можно воспроизвести у себя и гонять на локальных моделях.
Что уже работает:
• Запуск через Ollama - без облака
• Полный агентный цикл: чтение, запись, редактирование файлов
• Bash, grep, glob — всё на месте
• Работа с API и поиск в интернете - Поддержка MCP-серверов
• Память между сессиями
• не теряет контекст - Computer Vision - можно работать с изображениями - Все slash-команды: /commit, /review, /diff, /compact, /doctor - Можно стримить работу на другие устройства
По сути, ты получаешь полноценного AI-разработчика у себя на машине.
https://github.com/Gitlawb/openclaude
👎11👍5😁4❤2
💻 Какой язык программирования лучше для обучения?
Многие школы используют Java, C#, C или C++, но всё больше образовательных программ переходят на Python.
У Python есть очевидный плюс — на нём легче начать. Это помогает студентам быстрее увидеть результат и сохранять мотивацию.
Но есть и минус.
Python сильно абстрагирует низкоуровневые детали, поэтому студентам сложнее понять, как работают структуры данных, память и другие фундаментальные вещи.
Лично я считаю, что программисты должны становиться polyglots — людьми, которые знают несколько языков.
Фокусироваться на одном языке — стратегическая ошибка.
Но влияет ли язык на результаты обучения?
Исследование John R. Hott (ACM ICER 2025) показывает: почти никак.
Студенты, которые выполняли задания:
- только на Python
- только на Java
- на смеси языков
показали статистически одинаковые результаты.
Не было значимых различий:
- в оценках за программирование
- в письменных заданиях
- в тестах и квизах
- в уровне сложности, который испытывали студенты
Вывод исследования простой:
👉 выбор языка программирования почти не влияет на результаты обучения.
То есть преподавателям не стоит слишком переживать о том, какой язык выбрать для курса.
Гораздо важнее другое.
Вместо бесконечных споров *Python vs Java vs C++* стоит учить студентов:
- как создавать продукты
- как запускать проекты
- как строить бизнес
- как быть независимыми от технологических трендов
Как пишет Zed Shaw в эссе
“AI Didn't Kill Programming, You Did”:
проблема не в AI и не в языках программирования — проблема в том, как люди учатся программированию.
Главная мысль:
🚀 программирование можно выучить на любом языке.
Начните с Logo.
Попробуйте Ada.
Изучите Python, Go, Rust или C.
А ещё лучше — попробуйте придумать свой язык программирования.
Именно так и начинается настоящее понимание компьютеров.
Исследование
https://engineering.virginia.edu/faculty/john-r-hott
Эссе
https://learncodethehardway.com/blog/39-ai-didnt-kill-programming-you-did/
#programming #education #python #java
Многие школы используют Java, C#, C или C++, но всё больше образовательных программ переходят на Python.
У Python есть очевидный плюс — на нём легче начать. Это помогает студентам быстрее увидеть результат и сохранять мотивацию.
Но есть и минус.
Python сильно абстрагирует низкоуровневые детали, поэтому студентам сложнее понять, как работают структуры данных, память и другие фундаментальные вещи.
Лично я считаю, что программисты должны становиться polyglots — людьми, которые знают несколько языков.
Фокусироваться на одном языке — стратегическая ошибка.
Но влияет ли язык на результаты обучения?
Исследование John R. Hott (ACM ICER 2025) показывает: почти никак.
Студенты, которые выполняли задания:
- только на Python
- только на Java
- на смеси языков
показали статистически одинаковые результаты.
Не было значимых различий:
- в оценках за программирование
- в письменных заданиях
- в тестах и квизах
- в уровне сложности, который испытывали студенты
Вывод исследования простой:
👉 выбор языка программирования почти не влияет на результаты обучения.
То есть преподавателям не стоит слишком переживать о том, какой язык выбрать для курса.
Гораздо важнее другое.
Вместо бесконечных споров *Python vs Java vs C++* стоит учить студентов:
- как создавать продукты
- как запускать проекты
- как строить бизнес
- как быть независимыми от технологических трендов
Как пишет Zed Shaw в эссе
“AI Didn't Kill Programming, You Did”:
проблема не в AI и не в языках программирования — проблема в том, как люди учатся программированию.
Главная мысль:
🚀 программирование можно выучить на любом языке.
Начните с Logo.
Попробуйте Ada.
Изучите Python, Go, Rust или C.
А ещё лучше — попробуйте придумать свой язык программирования.
Именно так и начинается настоящее понимание компьютеров.
Исследование
https://engineering.virginia.edu/faculty/john-r-hott
Эссе
https://learncodethehardway.com/blog/39-ai-didnt-kill-programming-you-did/
#programming #education #python #java
👍5🥴5❤2
Французы сломали рынок: безлимитный интернет в 135+ странах за 30€ 🚀
л Free Max доступен в 135+ странах, включая Россию, и всё это через eSIM. Трафик идёт через Францию, поэтому сайты и приложения работают как будто ты не в РФ.
Активируется без танцев с бубном:
покупаешь тариф на сайте
получаешь QR-код
сканируешь с телефона
ловишь сеть - и всё, интернет уже льётся
Даже SMS при активации адаптировали под россиян - с «Da!» и триколором.
Единственный нюанс — нужна зарубежная карта для оплаты.
И вот тут начинается самое интересное: безлимит без ограничений по трафику. Вообще.
Похоже, мобильные операторы скоро будут выглядеть совсем иначе.
л Free Max доступен в 135+ странах, включая Россию, и всё это через eSIM. Трафик идёт через Францию, поэтому сайты и приложения работают как будто ты не в РФ.
Активируется без танцев с бубном:
покупаешь тариф на сайте
получаешь QR-код
сканируешь с телефона
ловишь сеть - и всё, интернет уже льётся
Даже SMS при активации адаптировали под россиян - с «Da!» и триколором.
Единственный нюанс — нужна зарубежная карта для оплаты.
И вот тут начинается самое интересное: безлимит без ограничений по трафику. Вообще.
Похоже, мобильные операторы скоро будут выглядеть совсем иначе.
❤14👍4🤔4☃2😁1🌚1🤪1