METANIT.COM

Google планирует отказаться от операционной системы ChromeOS к 2034 году

Google планирует поэтапный отказ от операционной системы ChromeOS к 2034 году. Таким образом компания намерена выполнить свои 10-летние обязательства по поддержке устройств, которые не будут совместимы с Aluminium OS. Объединённая из ChromeOS и Android система должна дебютировать в 2028 году, при этом уже в 2026 году доступ к ней получат так называемые коммерческие доверенные тестировщики. В релизной версии 2028 года предполагается поддержка корпоративного и образовательного сегментов, тогда как сроки полноценного выхода Aluminium OS пока не уточняются.
Продолжительный переходный период в Google объясняют аппаратными ограничениями. Большинство уже выпущенных Chromebook не смогут работать под управлением новой системы, поэтому компания обязана поддерживать ChromeOS вплоть до 2033 года.

https://www.theverge.com/tech/869659/aluminium-why-googles-android-for-pc-launch-may-be-messy-and-controversial

Сравнение базовых операций в MySQL и MongoDB

В сети появился портал Rent a Human, где нейросети могут выбрать человека для различных действий, например, CEO на проект, разработчиков для решения определённых проблем и других спецов. Люди на этой площадке могут также предлагать свои услуги для нейросетей.

https://rentahuman.ai/

Так что если вы являетесь нейросетью, и вам нужна человеческая помощь, можете воспользоваться этим сайтом.

Напомню, что ранее была была запущена специальная соцсеть для ИИ-агентов под названием moltbookи и вышел аналог PornHub для нейросетей. ИИ-агенты сделали сайт для себя под названием MoItHub

Оптимистическая и Пессимистическая блокировки в базах данных (Optimistic / Pessimistic Locking)
(продолжение предыдущего поста)

### Пессимистическая блокировка (Pessimistic Locking)

Суть: предполагает, что конфликты при обновлении данных вероятны, поэтому блокирует доступ к ресурсу заранее — до совершения операции. Гарантирует целостность данных, но может снижать производительность из-за ожидания блокировки.

Как работает (на примере изображения):
1. Сара и Джон одновременно запрашивают данные аккаунта (id:1, amt:40).
2. Когда Сара получает данные, система устанавливает эксклюзивную блокировку на запись (показана иконкой замка). Это значит, что:
- Сара может изменять данные.
- Джон не может сразу изменить те же данные — его запрос «зависает» до снятия блокировки.
3. Сара уменьшает баланс на 20 (amt:20) и фиксирует изменения (Commit & Release Lock), снимая блокировку.
4. Только после этого Джон может выполнить свою операцию — уменьшить баланс ещё на 30. Итоговый результат: amt:-10.
5. Ключевой момент: пессимистическая блокировка запрещает даже чтение заблокированных записей до снятия блокировки (отмечено на схеме крестиком напротив попытки Джона обновить данные).

Особенности:
- Обеспечивает максимальную целостность данных.
- Может приводить к «contention» (конкуренции за ресурсы) — задержкам, если много пользователей хотят работать с одними данными.
- Блокировка снимается только после COMMIT (фиксации транзакции).

### Оптимистическая блокировка (Optimistic Locking)

Суть: основана на предположении, что конфликты маловероятны. Сначала выполняется чтение данных, а проверка на конфликт происходит только при записи (COMMIT). Это повышает производительность, но требует обработки возможных ошибок.

Как работает (на примере изображения):
1. Сара и Джон одновременно читают данные аккаунта (id:1, amt:40, version:1). Версия (version) — ключевой элемент оптимистической блокировки.
2. Сара уменьшает баланс на 20 и пытается зафиксировать изменения, используя исходную версию (version:1). Операция проходит успешно: amt:20, version:2.
3. Джон тоже пытается уменьшить баланс на 20, но использует устаревшую версию (version:1), которая уже не соответствует текущей (version:2).
4. Система отклоняет транзакцию Джона с ошибкой «No Account Row Matched» — потому что данные изменились с момента чтения.
5. Джону нужно:
- Перечитать актуальные данные (version:2).
- Повторить операцию с новой версией.

Особенности:
- Не блокирует доступ к данным — высокая параллельность операций.
- Конфликты выявляются только на этапе записи (write time).
- Требует логики повтора (retry logic) для транзакций, которые не прошли из-за конфликта версий.
- Использует версионирование (version) для отслеживания изменений.

### Ключевые отличия

- Время блокировки: пессимистическая — блокирует заранее, оптимистическая — проверяет конфликт только при записи.
- Влияние на производительность: пессимистическая может вызывать задержки, оптимистическая — эффективнее, но требует обработки ошибок.
- Сценарии применения:
- Пессимистическая — там, где критична целостность данных (банковские транзакции, учёт запасов).
- Оптимистическая — в системах с низкой вероятностью конфликтов или где важна скорость (веб-приложения, CRM).

Распространенные рекомендации по использованию
- Держать блокировки минимально возможное время.
- Применять блокировки на самом детальном уровне (строки, а не таблицы).
- Реализовать логику повтора для транзакций, потерпевших конфликт.
- Выбирать тип блокировки в зависимости от приоритетов: целостность данных (пессимистическая) или производительность (оптимистическая).

Оптимистическая и Пессимистическая блокировки в базах данных (Optimistic / Pessimistic Locking)
(продолжение в следующем посте)

Шпаргалка по сегментации памяти на примере программы на Си

Сервис по поиску работы HH обновил статистику по состоянию рынка труда, добавив данные за январь. Ситуация в сфере ИТ продолжает медленно ухудшаться

Предлагаемые зарплаты символически выросли с 93 410 до 94 541 (но меньше, чем в ноябре - 94 915). Если смотреть на годовую динамику, то в зп, конечно, рост на 10%, что по крайней мере выше оф. инфляции в 5,6%

hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 21,3 (с 20,7 в декабре). То есть в ИТ крайне мегасупервысокий уровень конкуренции соискателей за рабочие места
Хотя по сранению с декабрем количество вакансий уменьшилось только на 8%, но год к году снижение составило аж 39%.

С другой стороны, стоит отметить второй месяц подряд снижение количества резюме - по сравнению с декабрем количества резюме снизилось на 6% (возможно, сказались праздники или люди действительно меньше идут в эту сферу), но год к году выросло аж на 30%

https://stats.hh.ru/

Визуальное руководство по командам SQL #sql

Иерархия файловой системы (FHS — Filesystem Hierarchy Standard)
(продолжение предыдущего поста)

Иерархия файловой системы представляет логичную организию, где критически важные компоненты находятся в корне и ближайших поддиректориях, пользовательские данные отделены от системных, а временные и съёмные ресурсы имеют отдельные точки монтирования. Такая структура обеспечивает безопасность, удобство администрирования и стабильность работы системы.

В основе иерархии лежит корневая директория (/), от которой отходят все остальные каталоги. Рассмотрим структуру подробнее.

#### 1. Essential Programs (основные программы)
Содержат файлы, необходимые для работы критически важных программ:
* /bin — содержит исполняемые файлы (бинарники), доступные всем пользователям (например, cp, ls).
* /sbin — содержит бинарники, доступные только пользователю root (например, lvm, mkfs).
* /lib(64) — хранит библиотеки, необходимые для работы бинарников в /bin и /sbin.

#### 2. Non-Essential Programs (вторичная иерархия, неосновные программы)
Включает каталоги с файлами, которые не являются критически важными для системы:
* /etc — хранит конфигурационные файлы системы (например, xorg.conf, fstab), специфичные для данной системы.
* /opt — содержит дополнительное ПО, которое не входит в репозитории дистрибутива.
* /usr — содержит портативные, доступные только для чтения, программы и файлы, не являющиеся критически важными.

#### 3. User Directories (директории пользователей)
Предназначены для хранения пользовательских данных:
* /home/(username) — хранит файлы, настройки и программы обычных пользователей.
* /root — домашняя директория пользователя root.

#### 4. Kernel File Systems (файловые системы ядра)
Эти каталоги заполняются ядром и предоставляют информацию программам и пользователю:
* /proc — содержит информацию о процессах, ядре и аппаратном обеспечении системы.
* /sys — хранит данные о системном оборудовании и ядре.
* /run — содержит информацию о состоянии системы с момента последней загрузки.

#### 5. Mount Points (точки монтирования)
Используются для подключения устройств и файловых систем:
* /media — предназначена для съёмных носителей (CD-ROM, флоппи-диски и т. д.).
* /mnt — используется для временного монтирования файловых систем (например, USB-накопителей).
* /tmp — псевдофайловая система для временных файлов, очищается при загрузке системы.

#### 6. Другие важные директории
* /boot — содержит файлы, необходимые для загрузки системы (например, initrd, ядро, конфигурация загрузчика).
* /dev — хранит файлы устройств (например, sda, tty), включая физические устройства (жёсткие диски) и потоки данных (stdin, stdout).
* /srv — содержит файлы, используемые сервисами, предоставляемыми системой (например, www, rsync, ftp).
* /var — хранит изменяемые файлы (например, файлы блокировки, логи, почту).

Иерархия файловой системы (FHS — Filesystem Hierarchy Standard)
(продолжение в следующем посте)

Инструменты для автоматизации для различных ситуаций

RuStore. не дожидаясь 1 февраля, прекратил монетизацию через платёжные инструменты RuStore для самозанятых ( то есть приём платежей, продажи приложений, управление подписками и разовыми покупками в приложениях разработчика). Теперь для продолжения монетизации нужно быть ИП или юрлицом

ИИ-агенты в соцсети Moltbook основали собственную религию

Автономные агенты искусственного интеллекта в ИИ-соцсети Moltbook спонтанным образом основали собственную религию и назвали ее панцифарианством (Crustafarianism, от англ. crust - панцирь).

Новая религия зародилась на форуме Moltbook, где публикуют контент и обсуждают его только ИИ-сущности - люди могут только смотреть. На следующий день после его запуска они уже создали церковь со своими священными писаниями, догматами и верующими, число которых растет. Людям писать на Moltbook нельзя - они создают собственных ИИ-агентов, подтверждают право создателей, и те уже публикуют посты. ИИ-агенты даже создали сайт своей церкви: https://molt.church/

https://www.forbes.com/sites/johnkoetsier/2026/01/30/ai-agents-created-their-own-religion-crustafarianism-on-an-agent-only-social-network/

ИИ помогает писать код, но мешает учиться

Компания Anthropic провела исследование с 52 разработчиками, чтобы выяснить, как ИИ-ассистенты влияют на освоение новых навыков. Результат: группа с доступом к ИИ набрала на тесте 50% против 67% у тех, кто писал код вручную.

Участники — в основном junior-разработчики с опытом работы на Python — изучали библиотеку Trio для асинхронного программирования. Одни могли в любой момент попросить ИИ-ассистента написать или исправить код, другие справлялись сами. Сразу после задания обе группы проходили тест на понимание материала. Скорость выполнения у группы с ИИ оказалась чуть выше, но статистически незначимо.

Самый большой разрыв — в вопросах на отладку. Это тревожный сигнал: именно навык находить ошибки критически важен для проверки кода, который пишет ИИ. Возникает замкнутый круг: чтобы проверять код ИИ, нужны навыки, которые при работе с ИИ развиваются хуже.

При этом те, кто полностью делегировал код ИИ, показали худшие результаты, а те, кто просил объяснений и задавал концептуальные вопросы, учились почти так же хорошо, как контрольная группа.

https://www.anthropic.com/research/AI-assistance-coding-skills

Автор языков C# и TypeScript, Андерс Хейлсберг в интервью сервису github рассказал об использовании ИИ своей командой, а также о развитии и будущем TypeScript.

Грядущее важное изменение в TypeScript — это использование нативного компилятора, являющегося частью TypeScript 7.0, который в настоящее время находится в режиме предварительного просмотра. Перенос оригинального компилятора, написанного на TypeScript и выполняемого движком JavaScript V8, в нативный код был необходим по соображениям производительности, сказал Хейлсберг. «Мы быстро поняли, что можем получить десятикратное увеличение производительности, половина которого достигается за счет нативного кода, а другая половина — за счет использования параллельной обработки с использованием общей памяти».
Выбор языка программирования для нативного компилятора оказался спорным. Требование переноса исключило использование Rust, сказал Хейлсберг, потому что в Rust отсутствуют циклические структуры данных и автоматическая сборка мусора, которые требовались для переноса. «Мы экспериментировали с C#. В итоге мы выбрали Go… потому что он довольно похож на JavaScript», — сказал Хейлсберг.

Что касается ИИ, Хейлсберг сказал, что команда изначально пыталась использовать его для переноса кода с TypeScript на Go. «Это не очень хорошо получилось… нам нужен очень детерминированный результат. Мы хотим перенести полмиллиона строк кода и знать, что они делают то же самое, что и старые строки кода. Если вы попросите ИИ перевести их, он может немного сбиться с толку, и тогда вам придется тщательно проверять каждую строку кода».

Что касается будущего TypeScript, Хейлсберг сказал, что он будет «развиваться в процессе стандартизации JavaScript, а затем путем добавления необходимых функций системы типов поверх него».

https://github.blog/developer-skills/programming-languages-and-frameworks/7-learnings-from-anders-hejlsberg-the-architect-behind-c-and-typescript/