Накопитель размером с монету и скоростью флагмана: подборка свежих IT-новостей №2
ТГК: NetIntelRU
В этой статье я расскажу о SSD размером с монету, который оставляет далеко позади обычные карты памяти, и о чумавом планшете с жидкостным охлаждением. Читайте, как Трамп спасает ИИ от бюрократии и о чем договорились Москва и Тегеран, в нашей подборке.
2 терабайта весят 1 грамм
Компания Biwin (это крупный китайский OEM-производитель памяти) наконец-то выпустила в продажу накопители формата Mini SSD (модель CL100). Главная фишка это скорость. Обычные microSD карты, даже самые дорогие, нервно курят в сторонке. Скорость чтения у этого гиганта 3700 МБ/с, а скорость записи до 3400 МБ/с. Для сравнения: даже новый стандарт microSD Express выдает около 985 МБ/с. Mini SSD быстрее почти в 4 раза.
Поскольку этот чип может часто путешествовать в кармане, Biwin его закалила: Защита IP68 не боится воды и пыли. Переживет падение с 3-х метров на твердую поверхность. Ресурсы от 512 ГБ до 2 ТБ.
Mini SSD не распаян на плате и не спрятан в недрах ноутбука под крышкой с десятью винтами. Он вставляется в лоток, как SIM-карта. Захотел расширить память? Тыкнул скрепкой, достал лоток, поменял накопитель.
Цены в Китае пока такие:
512 ГБ стоит ~85$
1 ТБ стоит ~155$
2 ТБ стоит ~311$
Biwin также выпустила кардридер RD510 с подключением по USB4 (40 Гбит/с). И знаешь, что в нем интересного? Встроенный вентилятор. Это намекает нам на то, что при таких скоростях и размерах малютка CL100 будет греться как кипятильник.
Планшет, который хочет быть игровым ПК
Компания OneXPlayer выходит на Kickstarter с новым проектом, который они скромно назвали Super X. Это, похоже, самый мощный Windows-планшет в мире. Внутри него бьется новейшее сердце от AMD, процессор Ryzen AI Max+ 395. Для тех, кто не следит за каждым чихом AMD, это флагманская 16-ядерная махина на архитектуре Zen 5 с интегрированной графикой Radeon 8060S.
Да, тут нет дискретной видеокарты, но, по заявлениям OneXPlayer, производительность этой встроенной графики находится на уровне NVIDIA GeForce RTX 4060. Если это правда, то в разрешении 2.8K можно будет играть во что угодно.
Самая безумная деталь это система охлаждения. Super X это первый в мире планшет с поддержкой внешней системы жидкостного охлаждения (СЖО). Внутренний кулер, вероятно, основанный на испарительной камере, интегрирован в тонкий алюминиевый корпус толщиной всего 12,5 мм, но он рассчитан на поддержку до 120 Вт теплового пакета.
Планшет оснащен 14-дюймовым OLED-дисплеем с высоким разрешением 2880 × 1800, поддержкой HDR и переменной частотой обновления (VRR). То есть, кроме мощности, тут еще и картинка будет сочная. Плюс, возможности для ИИ: процессор включает выделенный нейропроцессор NPU XDNA 2 с производительностью 50 TOPS, который позволяет на самом устройстве запускать огромные языковые модели, вроде DeepSeek 70B.
Стартовая цена на Kickstarter для базовой версии (Ryzen AI Max 385, 32 ГБ ОЗУ, 1 ТБ SSD) заявлена в $1900. Доплатить всего $100 и получишь топовый Ryzen AI Max+ 395. Учитывая, что речь идет о планшете с потенциально 128 ГБ сверхбыстрой оперативной памяти LPDDR5X-8000, ценник в $1900 выглядит хоть и внушительно, но для заявленной производительности почти как поход в магазин за хлебом.
Трамп vs. 50 штатов
Президент США Дональд Трамп (в очередной раз) потряс инфополе громким заявлением. Он намерен подписать указ о введении единых федеральных правил регулирования искусственного интеллекта. По его словам, это критически важно, чтобы не дать американскому лидерству в сфере ИИ утонуть в болоте бюрократии.
Политическая реальность в США такова, что помимо общенациональных законов, каждый из штатов имеет право вводить собственные локальные правила. И пока федерального закона об ИИ нет, штаты начинают принимать собственные нормы. Трамп считает, что эта разрозненность смертельно опасна для развития технологий.
Он прямо заявил. что если компаниям придется получать 50 разных разрешений для запуска одного продукта или исследования, это "разрушит ИИ на корню".
OpenAI бьет тревогу
Генеральный директор OpenAI Сэм Альтман, похоже, немного запаниковал и объявил во всей компании внутренний красный код, это сигнал максимальной тревоги. Причина проста, Google выпустила свою модель Gemini 3, которая по ряду ключевых тестов производительности обогнала ChatGPT и начала стремительно переманивать пользователей. Ситуация зеркальна той, что была в Google, когда три года назад внезапно выскочил ChatGPT и заставил их тогдашнее руководство тоже бить тревогу.
Альтман разослал сотрудникам внутреннее письмо, требуя от них сфокусироваться на улучшении ядра ChatGPT: сделать его быстрее, надежнее, умнее и дать больше возможностей для персонализации. Чтобы высвободить ресурсы, компания поставила на паузу все несущественные проекты.
Это включает в себя даже амбициозные начинания, вроде видеогенератора Sora, агентов ИИ для покупок и здоровья, а также личного помощника Pulse. Все силы, включая целые команды, теперь брошены на совершенствование самого чат-бота.
Самый ажиотажный результат этой паники – резкое ускорение выхода следующей модели. OpenAI экстренно форсирует релиз GPT-5.2, который, по слухам, должен был выйти позже в декабре, но теперь ожидается уже на этой неделе.
Сейчас им важно не потерять свои 800 миллионов еженедельных пользователей и выполнить амбициозный план по доходам, который к 2030 году должен достичь сотен миллиардов долларов.
Договорничок Москвы и Тегерана
Россия и Иран заметно углубляют свое технологическое партнерство. По итогам пятого заседания совместной рабочей группы по информационным технологиям, страны подписали солидный документ о сотрудничестве, в котором главное место отведено искусственному интеллекту.
ИИ тут только верхушка айсберга. Документ включает работу над кибербезопасностью, развитием цифровой экономики, внедрением электронного правительства, а также освоением блокчейна и финтеха.
В тексте соглашения есть явный акцент на укрепление связей с частным сектором и развитие технопарков. Такое партнерство вписывается в общую российскую стратегию. В Москве не скрывают амбиций: недавно звучали прогнозы о том, что ИИ к 2030 году должен дать экономике РФ свыше €110 млрд.
AMD наносит удар
AMD готовит очередной мощный подарок геймерам. Речь идет о процессоре Ryzen 7 9850X3D. Хотя AMD его официально еще не анонсировала, чип уже успел просочиться и на официальный сайт компании, и в бенчмарки, и даже в транспортные накладные.
Так в чем же главная интрига? Процессоры AMD с индексом X3D (использующие дополнительный кэш 3D V-Cache) давно считаются лучшими для игр. Новый 9850X3D является прямым наследником этой линейки, но с одним очень важным апгрейдом по сравнению с существующим 9800X3D. У него те же 8 ядер и 16 потоков, но рабочая частота поднята сразу на 400 МГц, с 5,2 ГГц до 5,6 ГГц. Это серьезный прирост, учитывая, что процессоры с 3D V-Cache обычно очень чувствительны к частотам.
Первый же слитый тест в бенчмарке PassMark показывает, что разница есть, хоть и небольшая. 9850X3D в многопоточном режиме обходит своего предшественника примерно на 5%. Это не оглушительный отрыв, но для игрового процессора, где важна каждая доля кадра в секунду, такой прирост только за счет частоты это отличный результат.
Интересный момент обнаружился, когда 9850X3D засветился в паре с безумно быстрой оперативной памятью DDR5-9800. Если предыдущее поколение X3D-чипов не очень любило высокочастотную память, то похоже, в новой линейке 9000-й серии AMD снимает это ограничение.
Кстати, по слухам, вместе с этим 8-ядерником AMD может показать нечто совсем дикое – Ryzen 9 9950X3D2, который якобы получит сразу два чипа 3D V-Cache.
Альтман собрался в космос
Сэм Альтман решил, что Земля для его амбиций стала тесновата. Выяснилось, что гендиректор OpenAI вел очень серьезные переговоры с ракетным стартапом из Сиэтла под названием Stoke Space. Альтман хотел выкупить контрольный пакет акций ракетной компании, чтобы начать вывозить дата-центры прямо на орбиту.
Обучение и работа ИИ потребляют электричество в чудовищных масштабах. На Земле энергия стоит денег и портит экологию, а в космосе солнце светит бесплатно и круглосуточно. Альтман в подкастах уже рассуждал о строительстве Сферы Дайсона, потому что на планете места и энергии для серверов скоро физически не останется. Stoke Space со своей полностью многоразовой ракетой Nova нужна, чтобы доставлять железки в космос.
Покупка Stoke Space стала бы для Альтмана личным вызовом Илону Маску. Владелец SpaceX уже давно намекает, что его новые спутники Starlink V3 будут работать не только как раздатчики интернета, но и как орбитальные сервера. Google и Безос тоже смотрят в эту сторону, так что намечалась знатная драка миллиардеров за то, чей суперкомпьютер будет летать выше.
Но сделку поставили на паузу. Gemini 3 так сильно наступил на пятки OpenAI, что Альтману пришлось резко свернуть космические карты и срочно спасать ChatGPT. Сейчас компании явно не до строительства ракет, тут бы лидерство в чат-ботах удержать.
Если понравилась статья - рекомендую подписаться на телеграм‑канал NetIntel. Там вы сможете найти множество полезных материалов по IT и разработке!
Мифы и реальность: есть ли основание противопоставлять Agile и Waterfall?
Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья с Хабра и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Agile — это ценности, а не методология
Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.
Waterfall: миф о жестком подходе
Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.
Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:
Техническое задание
Эскизный проект
Технический проект
Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)
Внедрение (Подготовка и передача программы)
Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:
Устранение ошибок.
Развитие и усовершенствование продукта.
Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.
Почему возникает миф о несовместимости?
Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».
Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут:
- Давайте заново начнем.
Однако в реальности:
Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками.
Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum.
Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.
Синтез вместо конфронтации: гибридные подходы
На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например:
Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.
Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.
Как же выбирать методологию? Нужно опираться на критерии, а не догмы
Выбор между Waterfall и итерационными методами зависит от четырёх факторов:
Предсказуемость требований.
Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.Стоимость изменений.
В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.Регуляторные ограничения.
В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.Культура команды и заказчика.
Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.
Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum
Спринты выжимают все соки из разработчиков из-за частых дедлайнов https://habr.com/ru/companies/ruvds/articles/844506/
Заключение: за пределами маркетинговых мифов
Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:
Какова степень неопределённости требований?
Какие ограничения накладывают регуляторы или бюджет?
Насколько команда и заказчик готовы к гибкости?
Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:
Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».
Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).
Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.
Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.
Как создаются карты для Glide BTL?
В прошлых постах мы рассказывали про подготовку к сборке уровня, а сегодня приступим к самому интересному - самой сборке вплоть до финального результата.
Итак…
- Сборка блокаута. Имея на руках референсы и набросок, можно начинать собирать первый игровой прототип уровня. Он не должен быть детализированным, но обязан быть интересным и приятным в прохождении. На этом этапе проверяются метрики и добавляются базовые механики.
- Настройка событий. Этот этап происходит одновременно со сборкой блокаута и является его неотъемлемой частью. События влияют на то, какие ощущения испытывает игрок во время прохождения, какие механики и действия ему доступны. Сюда можно отнести расстановку чек-поинтов в гоночном режиме, расставление ловушек и “абилок”, добавление интерактивности: взрывающиеся двери, сбивающие насмерть поезда, ломающиеся от удара предметы, запуск примитивных анимаций и кат-сцен.
- Тестирование. Оно проводится постоянно и с разным количеством людей. С помощью него можно проследить понятные и непонятные места на уровне, можно заметить, какие вещи кажутся людям интересными, а какие наоборот - вызывают скуку. Тестирование завершает одну итерацию и начинает новую: блокаут дорабатывается, события донастраиваются. И так пока результат не удовлетворит всю команду.
- Конечный вариант. Он подводит итоги всей проделанной ранее работы. В нём объединяются концепт, основная идея, референсы и наброски, а затем серые кубы блокаута заменяются на готовые модели. Окружение прорабатывается, настраивается освещение, проводится оптимизация.
И на этом всё. Карта готова! Хотя ещё предстоит финальное тестирование и полировка отдельных моментов, но это уже мелочи жизни :)
Про каждый из пунктов создания уровня на самом деле можно было бы расписать по целому посту. Есть очень много технических моментов, разных инструментов и прочего, здесь же мы лишь кратко описали основные моменты. Так что, если интересно, обязательно маякните в комментариях!
Наш Steam
Актуальные новости в Telegram
Как Cursor помог переписать браузерное расширение за 2 часа: опыт миграции на единый стек
Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками.
Мой стек
Frontend:
- React (без сюрпризов)
- WXT (лучший фреймворк для браузерных расширений)
- MUI (библиотека UI-компонентов под Material Design)
- Netlify (бесплатный и надёжный хостинг)
Backend:
- Supabase (как Firebase, только лучше)
- Yandex Cloud (serverless-контейнеры + S3-хранилища)
Процесс
На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей.
С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов:
Перенёс на WXT (фреймворк для Chrome Extensions)
Заменил самописные компоненты на MUI
Добавил TypeScript для типобезопасности
Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API
Что получилось
Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д.
Дополнительно добавил:
Аудиоплеер для предпросмотра файла перед отправкой
Анонимную расшифровку по прямой ссылке на аудио
Бонус
Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google.
Выводы
Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли.
Хотите больше деталей?
Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.
10.12.1972 — Рождение языка C [вехи_истории]
👨💻 В 1972 году в Bell Labs Деннис Ритчи создал язык C — фундамент всего современного IT.
У этого события нет точной даты в календаре, поэтому 10 декабря часто используют как символический день рождения, связывая его с днём рождения первой программистки в истории, Ады Лавлейс.
👨💻 Язык, задуманный для UNIX, стал «латынью» для разработчиков: на нём написаны Windows и Linux, а его синтаксис лёг в основу C++, Java и Python.






















![🗓 10.12.1972 — Рождение языка C [вехи_истории]](https://cs18.pikabu.ru/s/2025/12/10/06/gf2rctj4.jpg)
