Бьюсь об заклад, что ПК в вашем офисе вряд ли потянут большие языковые модели (LLM).

Сегодня большинство пользователей взаимодействуют с LLM через браузеры, а более технически подкованные используют программный интерфейс или командную строку. Но и в том, и другом случае запросы отправляются в дата-центр, где размещается и работает модель. И такая схема работает прекрасно, до поры до времени. Аварийное отключение дата-центра может лишить вас доступа к модели на несколько часов. Кроме того, некоторые пользователи не желают отправлять личные данные какой-то неизвестной сущности.

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

Недавно моё утро началось с такого вот прекрасного e-mail от Hetzner:

Уважаемый, м-р Джей Сандерс,

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

Также просим вас прислать краткое пояснение с описанием того, как такое могло произойти, и что вы собираетесь в этом отношении предпринять. Если последующие шаги не будут успешно выполнены, ваш сервер может быть заблокирован в любой момент после 2025-12-17 12:46:15 +0100.

К письму прилагалось подтверждение того, что с моего сервера было выполнено сканирование некоего IP-диапазона в Таиланде. Отлично. Никакого вам «Здравствуйте», а лишь заявление о злоупотреблении и угроза отключить всю инфраструктуру через 4 часа.

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

Однако время шло, и сегодня я уже стал той самой будущей версией себя, которая разбирается в математике чуть лучше. Ну а поскольку мой фрактал похож на распускающийся цветок и провисел на моей стене столько лет, я буду ласково называть его «желтофиоль», хотя ниже вы увидите, что он сильно похож на некоторые другие известные фракталы. Но прежде чем переходить к изучению этого узора, будет нелишним проговорить этапы, которым мы следовали в школе при его рисовании.

Некоторым людям нравятся собеседования с написанием кода. Я к их числу не отношусь.

Недавно мне на LinkedIn попался пост такого содержания:

"Мы задаём каждому соискателю тривиальную задачу на программирование. Что-нибудь вроде: «Дан список чисел, нужно вернуть сумму чётных из них». И такая задача не предполагается как сложная или заумная, и её цель не в том, чтобы кого-то отсеять, теоретически.

Это лишь базовая проверка. Разработчик или SRE с опытом от 6 до 10 лет должен решать такие во сне, согласитесь?

Оказывается, нет.

Где-то 75% кандидатов не справляются. И не только джуниоры. Я говорю о людях с приставкой «Senior» в их квалификации. О людях, которые заявляют, что учат новичков. О тех, кто говорит, что имеет за плечами годы опыта в продакшене.

Для меня это загадка".

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

Долгие годы я воспринимал систему HDMI-CEC как домового: иногда полезная, часто непредсказуемая и всегда загадочная. У меня в гостиной собран несложный мультимедиа-центр — ТВ Samsung с поддержкой ARC (не eARC, которая заслуживает отдельного поста), Denon AVR-X1700H, спрятанный в кладовке, Apple TV, несколько подключённых к Denon игровых приставок и Raspberry Pi 4, управляющий системой Homebridge. Что касается CEC, то в Apple TV эта фича работает прекрасно, но вот приставки ведут себя так, будто едва с ней знакомы. Они будят ТВ, переключают источник, но оставляют Denon в режим ожидания, вынуждая меня переключать вывод аудио вручную.

Когда я закончил работать над проектом ecosyste-ms/package-manager-resolvers, мне стало интересно, какой алгоритм разрешения зависимостей использует сервис GitHub Actions. Когда вы записываете в файл рабочего потока uses: actions/checkout@v4, то объявляете зависимость. GitHub её разрешает, скачивает и исполняет. Так работает управление пакетами. Я же решил отправится в кодовую базу runner, чтобы увидеть весь этот процесс изнутри. И открытия, скажу я вам, оказались весьма тревожными.

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

Один особенно мудрый взрослый (где-то в 1996 году) однажды отвёл меня в сторону и сказал: «Знаешь, хорошо, что программирование приносит тебе удовольствие, потому что в будущем оно тебя не прокормит. Делать это из любви, а не ради денег — отличный подход.

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

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

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

И вот я здесь почти 30 лет спустя, и разработка, несмотря ни на что, продолжает меня кормить. Существует опенсорс, и всегда находятся библиотеки, с помощью которых я могу скроить что-то нужное. Постоянно возникают новые серии задач, для которых ещё нет готовых решений. Комбинирование деталей LEGO по-прежнему требует усердного труда. Как только я решаю эту задачу на одном уровне абстракции, мы переходим на другой… и так продолжается по кругу.

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.

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

Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.

А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.

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

Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!

Невероятно!

Но я забегаю вперёд…

Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования.

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

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

Можно подумать...

Недавно я закончил реализацию своего хобби-проекта по воссозданию ПК IBM XT из 80-х на основе оригинальных деталей с использованием современных технологий. У меня была чёткая цель: возможность играть на этом ПК в EGA-версию Monkey Island 1 со всеми примочками. То есть мне нужна была поддержка мыши, жёсткий диск с возможностью записи для сохранения игры и версия озвучки через карту Adlib, которая мне нравилась больше всего.

Эта задумка у меня возникла, когда я узнал о существовании маломощного варианта Intel 8088, который использовался в XT. Низкое энергопотребление значительно упрощает подключение процессора к ПЛИС, ввод-вывод которой обычно работает на 3,3 В. Всё это вкупе с маломощной микросхемой SRAM на 1 МБ (CY62158EV30), призванной обеспечить XT его 640 КБ памяти, уже составляло основу для всей будущей системы.

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

Интернет — невероятное изобретение. Людей от него за уши не оттащишь. Вот только есть у этого изобретения проблемы с надёжностью — пакеты теряются, каналы перегружаются, биты путаются, а данные повреждаются. Ох, какой же опасный мир! (Буду писать в духе Крамера).

Хорошо, почему же тогда наши приложения вот так просто работают? Если вы выводили своё приложение в сеть, то процесс вам знаком: socket()/bind() здесь, accept() там, возможно, connect() вон там и, вуаля — данные надёжно текут в обе стороны упорядоченным и целостным потоком.

Сайты (HTTP), сервисы e-mail (SMTP) или удалённый доступ (SSH) — всё это построено на основе TCP и просто работает.

Есть три вида писем, которые могут испортить блаженную субботу: уведомление безопасности, предупреждение об отключении электричества и, очевидно, повторное напоминание о том, что вы задолжали облачному провайдеру один цент — да, именно $0,01. Услугами DigitalOcean я пользуюсь с 2013 года, хотя для личных задач я этот сервис использую редко, просто авторизуюсь несколько раз в неделю для обеспечения поддержки моих клиентов на этой платформе.

Последние две пятницы без какого-либо уведомления в Google Cloud блокировали аккаунт моей компании SSLMate. Впервые подобное произошло в 2024 году, тоже без какого-либо предупреждения. Но сегодня я хочу не столько предупредить вас о рисках использования платформы Google Cloud, сколько поведать о вынужденных компромиссах между снижением безопасности и удобством работы, вызванных своенравной политикой Google.

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

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

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

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

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

Если вы уже давно знакомы с Backblaze (особенно, если следите за обзорами Drive Stats), то наверняка читали наши обсуждения кривой отказов. В статье «Drive Failure Over Time: The Bathtub Curve Is Leaking» мы писали о том, как проверяли истинность старого инженерного принципа, гласящего, что сбои в работе привода, представленные в виде временного графика, демонстрируют предсказуемую U-образную кривую, иначе называемую кривая «ванны».

Но тест этого не подтвердил. В результате анализа нашей коллекции приводов были зафиксированы всплески и плато, которые никак не вписывались в предсказуемый паттерн. Теперь, спустя 13 лет непрерывного сбора данных, удалось получить более ясную картину, но и более странную.

И «ванна» в этом случае не просто «потекла» (отсылка к leak в названии вышеупомянутой статьи, — прим. пер.), её форма больше напоминает бордюр при входе в душевую кабину. Складная история о том, что вначале идут сбои, а потом спокойный средний период с плавным повышением отказов, больше не вписываются в реалии жизни наших приводов. Они становятся лучше. Говоря точнее, датасет Drive Stats указывает на повышение их качественных показателей конкретно в дата-центрах.

Давайте же посмотрим, как выглядит полученная нами кривая отказов, и как она соотносится с прежними поколениями анализа.

Если коротко, то жёсткие диски становятся лучше.

(Перевод моего выступления на  P.I.W.O в июне, слегка подчищенный и приближенный к формату блога).

…звучит как-то не очень. Я сделала все эти слайды в Inkscape с ПК под управлением KDE Linux, плюс я регулярно пользуюсь Firefox. Но это всего лишь я. А что насчёт вас? Вы используете свободное ПО? Поднимите руки! [в аудитории поднимаются руки] Конечно же! Что за чепуха, «Свободное ПО не победило». Кто-то подменил мои слайды… Эй, ведущий конференции!

Ведущий: В другом каталоге.

[Перехожу в каталог с названием другой каталог и открываю файл твои слайды тупица.pdf]

Вот они мои слайды.

Всех приветствую, меня зовут Дорота, и сегодня я буду говорить о том, как …

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

Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:

«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.

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

Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.

Ещё одну схожую по духу концепцию в то же время предлагали разработчики Opera, которые хотели «встроить в ваш браузер веб-сервер».

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

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