Самые дурацкие вещи в публичных интернет-сервисах, моя версия

1. Отсутствие публичных постов Facebook, Telegram в поисковиках

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

2. Продажа-передача адреса yandex.ru яндексом прямому конкуренту

Понятно, что это политическое решение и часть происходящего много лет абсурда, но идиотизм ситуации остается. (Училка-вертухай «а голову, голову ты дома не забыл? Ха, забыл!»)

3. Потеря состояния приложением при потере интернет-соединения

Тут уже видимо главные ответственные Google и Apple, но не только, отдельные разработчики тоже этим управляют.

Как это выглядит — получил в chatgpt полезный ответ, не сделал скриншот, заходишь куда-то в путешествии, где нет интернета или он у тебя внезапно кончается — и всё, страница пропала, информации нет.

Сидишь пишешь на десктопе в телеграмме, пропал интернет — всё, тебе не видны твои переписки. Какого хуя — ответа нет, видимо опять загадочные соображения безопасности.

А какие у вас кандидаты в самые мудацкие ситуации в современном ит-мире сервисов?

Где писать об ИТ на английском за гонорар

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

Актуальность: 30 сентября 2026 года.

Издания

1. IEEE Spectrum⁠
Журнал об инженерии, вычислениях, ИИ и технологических изменениях. Здесь нужны журналистские истории с фактами, интервью и независимыми источниками.
💰 Новостные материалы — от $500; развёрнутые журналистские материалы — от $1,25 за заказанное слово.
📩 Начать со знакомства с редактором: кратко рассказать о себе, приложить примеры публикаций и предложить историю. (spectrum.ieee.org⁠)

2. Smashing Magazine⁠
Веб-разработка, UX, доступность, дизайн-системы и практические кейсы. Хорошая площадка для разбора решений на стыке интерфейсов, требований и разработки.
💰 Гонорар предусмотрен, публичной ставки нет.
📩 Отправить через форму план на 200–300 слов: тема, аудитория, польза для читателя и ваша экспертиза. (smashingmagazine.com⁠)

3. MSSQLTips⁠
Практические статьи о SQL Server, интеграции данных, Azure Data Factory, Power BI и Microsoft Fabric. Особенно интересно авторам с опытом корпоративных систем и баз данных.
💰 Оплата и бонусы за вклад; сумму нужно уточнить у редакции.
📩 В анкете нужны LinkedIn, пример текста и идеи статей. Материалы должны быть эксклюзивными; AI-генерация запрещена. (mssqltips.com⁠)

Корпоративные блоги и технический контент

4. SigNoz Technical Writer Program⁠
Backend, DevOps, мониторинг и OpenTelemetry. Ищут подробные руководства с кодом, схемами и практическими примерами.
💰 Ставка зависит от необходимой экспертизы и согласуется до начала работы.
📩 Подать тему и примеры технических публикаций через форму. Нужен опыт разработки и написания статей. (signoz.io⁠)

5. Corellium Contributor Program⁠
Безопасность мобильных приложений, пентестинг, исследование угроз и интеграция инструментов. Принимают статьи, white papers и материалы для вебинаров.
💰 Программа оплачиваемая, ставка не опубликована.
📩 Отправить тему, краткий план и пример текста. Требуется практическая экспертиза; ранее опубликованные и AI-generated материалы не принимаются. (corellium.com⁠)

6. PHPTRAVELS Content Program⁠
Travel tech: API поставщиков, платежи, процессы бронирования, масштабируемая архитектура и DevOps. Подойдут руководства и разборы реальных внедрений.
💰 $50–200 за принятый материал, в зависимости от объёма и глубины.
📩 Сначала отправить краткое описание идеи по контакту на странице программы. Профессиональный писательский опыт необязателен. (phptravels.com⁠)

7. Draft.dev⁠
Агентство технического контента для IT-компаний. Вариант для разработчиков, которым интересны регулярные заказы на статьи и руководства.
💰 Работа оплачивается, публичной ставки нет.
📩 Заявка через анкету на сайте; приглашают разработчиков с разным уровнем опыта. (draft.dev⁠)

С чего начать: подготовьте короткое предложение темы, план и 2–3 примера своих текстов. До написания полной статьи согласуйте гонорар, способ получения оплаты и права на материал.

#техническоеписательство #IT #фриланс

Профессор Стэнфорда Джон Оустерхаут продвигает Homa — новый транспортный протокол для дата-центров, который The Register описывает как потенциальную замену TCP в эпоху AI.

Посмотрим, насколько хорошо базовая модель TCP соответствует современным распределённым системам.

TCP предоставляет приложению надёжный поток байтов. Где заканчивается один логический запрос и начинается другой, транспортный уровень не знает: короткий RPC, обращение к кэшу и передача большого объекта для него сводятся к последовательности байтов, которую нужно надёжно доставить в правильном порядке. Для интернета это оказалось исключительно удачной абстракцией, но внутри современных дата-центров характер коммуникаций изменился.

Тысячи машин одновременно обмениваются RPC-вызовами, метаданными, запросами к кэшам и результатами вычислений, а параллельно через ту же сеть идут крупные массивы данных. В AI-инфраструктуре рядом с передачей весов моделей, градиентов, checkpoints и KV-cache постоянно идут короткие сообщения, от скорости доставки которых может зависеть следующий этап вычисления. Если большой массив придёт немного позже, это часто некритично, а задержка короткого сообщения способна оставить дорогостоящий GPU в ожидании.

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

В Homa используется подход SRPT, Shortest Remaining Processing Time: система стремится быстрее завершать те передачи, для которых осталось меньше данных. Поэтому короткий запрос не обязан ждать, пока через тот же участок сети пройдёт большой объём информации.

По данным Оустерхаута, в тесте сети 100 Гбит/с при загрузке 80% задержка коротких сообщений на уровне p99 составляла около 92 микросекунд для Homa против 1,2 миллисекунды для TCP — примерно в 13 раз меньше. Для длинных сообщений авторы также заявляют примерно двукратное преимущество.

С архитектурной точки зрения особенно важно изменение границы между приложением и транспортом. В TCP сеть предоставляет поток байтов, а сообщения и RPC формируются поверх него. Homa делает сообщение частью транспортной модели и тем самым даёт транспортному уровню информацию, которой у TCP нет: размер сообщения и возможность выбирать порядок обслуживания разных передач.

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

Речь при этом не идёт о немедленной замене TCP во всём интернете. Homa ориентирована прежде всего на дата-центры, может работать параллельно с TCP как модуль Linux, а Оустерхаут сейчас работает над её стандартизацией в IETF и включением реализации в основной Linux kernel.

У Homa есть и критики, которые ставят под сомнение корректность сравнений с TCP и масштаб решаемой проблемы. Да и сама идея специализированного транспорта не нова: RDMA, DPDK, NVMe over Fabrics, AWS SRD и QUIC тоже появились потому, что универсальный сетевой стек подходит не для всех классов систем.

Говорить о том, что AI «убьёт TCP», пока рано. Однако AI-инфраструктура делает стоимость задержек настолько высокой, а взаимодействие между узлами настолько интенсивным, что заставляет пересматривать решения, десятилетиями считавшиеся почти неизменной частью технологического стека. В результате транспортный протокол снова становится полноценным архитектурным выбором.

Источник: The Register, 1 октября 2026 — “Stanford prof is beating the drum for a new protocol to replace TCP”.

https://www.theregister.com/networks/2026/10/01/stanford-prof-is-beating-the-drum-for-a-new-protocol-to-replace-tcp/5300629

Главные пороки моего ChatGPT

На днях смог сравнить с Клодом, поэтому стало видно поочётливее.

1. Многословность

Я сам долгое время хотел от него развёрнутых подробных ответов, но сейчас это превратилось уже в проблему, как он разными словами по несколько раз что-то разжёвывает.
Начинаю понимать, что далеко не всегда формат рассуждений полезен, иногда это напоминает уже просто словесный понос.

2. Дрифт фокуса

По ходу дискуссии его достаточно быстро уносит в какие-то дали, приходится поправлять и возвращать, о чём мы вообще говорим.

3. Подмена понятий

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

Для борьбы с 1 и 2 сегодня нашлось интересное решение, буду тестить: https://github.com/ayghri/i-have-adhd

Также ещё проблем помельче:

4. Избыточное забегание вперёд, форсирование хода рассуждений

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

5. Документы, созданные в чате, плохо видны

Да, можно добавлять чаты к источникам проекта, но если ты сделал в чате N документов, то будет добавлен только чат, а документы прямо не видны.

6. Десктопный Апп почему-то с новыми чатами работает локально и как агент, как с десктопа делать облачные чаты пока не понял, видимо какой-то баг был при обновлениях. Похоже что починили.

7. Секции в списке чатов из десктоп-версии не видны в вебе.

Меня конечно поражает, как медленно массовые сервисы разбираются в человеческих потребностях.

Например, при заказе в магазине нужно выделить, какие продукты составляют ядро заказа.

Вот решил я взять курицу и салат, а к ним ещё чего попало набрал в 5 раз больше. А потом рраз — и тебя ставят перед фактом, что салата сегодня вечером больше нет.

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

Что, думаете Яндекс.Еда, Самокат, Wolt, Foodora понимают про ядро заказа? Хуй там.

Зачем вузы выпускают социологов и антропологов, если с потребностями работают инженеры — ежу непонятно.

почему не работает радио?

в связи со свежими новостями, как вы думаете, с какими ЕЩЁ рисками нужно считаться создателям крупнейших интернет-сервисов и дата-центров:
1. Blackout электричества более, чем на 72 часа
2. Падение астероидов
3. Ядерный удар
4. Атака инопланетян
?

Как разбить мега-продукт на цепочку ценных релизов?

я тут понял, что умею нарезать сложные цельные глыбы идей на отчуждаемые поставки—итерации с законченной ценностью

и это нифига не типовая компетенция менеджера или аналитика

многие этого делать совсем не умеют

видимо сказывается предпринимательский опыт и взгляд на мир

формализовать пока такое сложно, видимо приму как неосознанную компетенцию

Чтобы баги массовых сервисов не мучали, решил сделать отдельную группу для выражения https://t.me/uvastutbag

Можно создавать новые топики для новых сервисов

Попробовал масштабировать подход, сделал каналы еще для нескольких медиа, наверное доведу до 10

https://t.me/techcrunch_ai_digest

https://t.me/verge_ai_digest

My English is not very good

Пост-советская школа создавала чувство униженности и некомпетентности в языке через оценку степени владения языком через:
- словарный запас
- грамматику
- произношение

Спустя годы оказалось, что язык нужен для коммуникации, и для неё словарный запас, грамматика и произношение сами по себе не важны, если вас поняли.

Мне английский нравился всегда и сейчас у меня формально уровень C1-C2.

Но коллеги-венгры и курьеры-индийцы с трудом понимают мой английский не из-за скудного словарного запаса, не из-за упрощённой грамматики и не из-за моего акцента.

Они понимали меня плохо, потому что:
— я говорил (и говорю местами) слишком быстро и невнятно
— я говорил (и говорю местами) слишком сложно

«Не будет ли любезен многоуважаемый визави этим прекрасным токийским утром» для не-носителя языка звучит просто как белый шум, а для носителя — как строчка из книги.

Я тоже не сразу понимал английский акцент коллег, только через полчаса общения становилось норм.
Но к акценту мозгу подстраивается гораздо проще, чем к незнакомым словам и быстрой речи.

Поэтому с неносителями нужны простые, чёткие, короткие и точные фразы.
А с носителями, особенно американцами, сильно пригодятся фразеологизмы.

Но фокуса на этом в школе не было.

Поэтому все эти посты англофилов про тонкости произношения или грамматики (заметили, как они забили на грамматику за последние 10 лет?) мне интересны как англофилу, но вызывают сопротивление как пропаганда чувства неполноценности и фокус на неважном.