4 октября 2025 года было сказано приступить к проектированию распределённого чана.

Эта нить посвящена проблемам, обсуждению их и публикации новостей по данному проекту.

Распредчан - это кодовое название механизма синхронизации данных между держателями нод нашего чана.

Нода - ресурс, предоставляющий интерфейсы для server2server и server2client взаимодействий, где s2s - связь между нодами, а s2c - связь между нодой и интерфейсом, например между pissykaka и pissychan-front.

Какие проблемы мы хотим решить?

• Независимое хранение постов без централизации оного в руках полутора анонов.

• Распределённое хранение файлов.

• Возможность каждой ноды принимать посты и файлы от s2c-коннектов для последующей синхронизации их с другими нодами, в том числе теми, что были оффлайн некоторое время.

Мы открыты к предложениям, обсуждению и критике данного проекта.

Интересно, как быстро поведёт центральный осевой цилиндр?

Глава OpenAI Сэм Альтман написал в X: "Я испытываю огромную благодарность к людям, которые писали невероятно сложный софт символ за символом. Уже сложно вспомнить, сколько усилий это требовало. Спасибо, что довели нас до этой точки". Пост собрал 4,9 млн просмотров и почти 4 000 ответов — подавляющее большинство гневных. На фоне 45 000 увольнений в IT с начала 2026 года слова прозвучали как прощальная речь от человека, чьи модели обучены на коде тех самых разработчиков.

Контекст делает твит особенно токсичным. За последние недели Amazon сократил 16 000 человек, Block Джека Дорси — почти 40% штата (4 000 сотрудников), Atlassian — 10% (1 600 человек). Meta* (признана экстремистской и запрещена в РФ), по данным CNBC, готовит сокращение до 20% персонала. Общий мотив — руководители заявляют, что ИИ сделал этих сотрудников ненужными. По подсчетам RationalFX, более 9 200 из 45 000 увольнений напрямую связаны с автоматизацией и внедрением ИИ-инструментов.

Реакция в X была единодушной. "Приятно знать, что наша награда — потеря работы", — ответил один из пользователей. TechCrunch подчеркнул главный парадокс: OpenAI обучила модели на массивах кода, написанного вручную теми самыми программистами, которым Альтман теперь выражает благодарность, — а ИИ компании используется как обоснование для их увольнения.

https://habr.com/ru/news/1012044/

Ранее сообщалось, что опытные айтишники с 20-летним стажем вынуждены теперь работать в доставке из-за ИИ.

https://www.cnews.ru/news/top/2025-05-20_opytnejshego_programmista

Любопытно, что самые сложные для поиска люди - это программисты. Казалось бы, миллионам людей нужны программисты. Миллионы людей хотят, чтобы им написали код.

Но при этом программисты - это какая-то невероятная аномалия. Это алкаши, обманщики, лентяи, дебилы, криворукие уебки, воры, гости из юго-восточной Азии и просто неквалифицированные чуваки.

Казалось бы - вот она, ниша! Вот бизнес-возможность! Пиши код и настраивай CI/CD, получай бабло и зарабатывай авторитет! Но нет. Что не так с профессией программиста? Почему их нет нормальных?

https://www.opennet.ru/opennews/art.shtml?num=64932

Организация Wikimedia Foundation была вынуждена временно отключить возможность редактирования и запретить выполнение персональных скриптов на Meta-Wiki, Wikipedia и сопутствующих Wiki-сайтах, из-за инцидента с безопасностью, который создал угрозу компрометации учётных записей администраторов проекта и привёл к массовой вредоносной модификации страниц и скриптов.

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

Вредоносный скрипт был загружен ещё в 2024 году участником Ololoshka562. Какого-либо вклада в статьи у учётной записи не было, за исключением попытки написания статьи под любопытным наименованием «Упячкоид».

Mysql 8.0.32

После вставки в таблицу с колонкой id AUTO_INCREMENT PRIMARY KEY строки и извлечения last_insert_id строку невозможно получить следующим запросом по данному id. Строка при этом в таблице присутствует, а last_insert_id указывает на верный идентификатор.

Почему так может быть?

• После вставки строки она есть в таблице под айди 2207. То есть она точно есть в таблице после выполнения моего кода с запросами к СУБД, всегда доступна по айди 2207.

• Если запустить код, который: сохраняет строку в таблицу БД с айди 2207, извлекает внутри данной транзакции last_insert_id == 2207, завершает транзакцию и коммитит изменения, затем в другой свежей транзакции пытается извлечь строку из таблицы по айди == 2207; если запустить такой код в режиме отладки - то идентификатор сходится, но данные всё равно не возвращаются.

• Грешным делом я пробовал добавить sleep(1) после каждой вставки строки и перед попыткой извлечения - думал, может упираюсь в I/O или что-то вроде. Нет, дело не в этом.

• У меня нет репликации или чего-то такого: дело точно не в рассинхроне мастера с репликой для чтения. В моём случае СУБД одна.

(Мне всё равно никто не ответит, но когда найду причину - напишу, в чём я был неправ)

узнал про flux architect

ахахаха

оказывается в мире фронтенда тоже появилась своя святая троица из паттернов

так-то давно пора

жду когда ещё vue и react и angular разрабы соберутся, чтобы издать свои PSR и сделать всю дымящуюся кучу кода совместимой друг с другом

кааеф!!

Дисскас.