Персонаж игры Factorio, разработанной чешской компанией Wube Software, совершил аварийную посадку на чужую планету. Его задача — построить ракету для побега. Для этого ему потребуется единолично воссоздать промышленную революцию, от разбивания камней для создания грубых каменных печей до перегонки нефти в ракетное топливо. Играя однажды, я установил насос на побережье озера, чтобы подавать воду на свой бетонный завод, и тут до меня дошло, что я много часов не пил воду в реальном мире. У меня болела голова, но я не хотел вставать из-за компьютера. Мне хотелось решить проблему щелчком мыши, как я делаю это в игре, проложив несколько метров трубопровода от кухонного крана к моей сгорбившейся фигуре (и, возможно, ещё несколько метров от моего тела до туалета).

Раньше меня увлекали многие игры, но лишь некоторые полностью подавляли мою волю, моё ощущение времени, да и все остальные зоны мозга, не занимающиеся строительством фабрики. Однако по стандартам Factorio я всё равно остаюсь обычным нубом. Два моих друга однажды устроили 24-часовую игровую сессию лишь с одним трёхчасовым перерывом на сон. Серьёзные игроки очень часто не выходят из игры в течение многих тысяч часов.

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

Продуйте пыль с разъёма

Я раскрою вам один из трюков отдела поддержки продукта. Иногда вы общаетесь по телефону или в чате с кем-то, и подозреваете, что проблема может быть лишь в том, что он забыл подключить кабель или засунул его не в тот порт. Раньше такое легко могло произойти с разъёмами PS/2, подходящими и к клавиатуре, и к мыши, а сейчас — с сетевыми кабелями, которые подходят и к upstream-, и к downstream-портам маршрутизатора.

Трюк вот в чём: не спрашивайте «Вы уверены, что подключили всё правильно?» Если вы сделаете это, то собеседник оскорбится и возмущённо бросит: «Разумеется! Я что, похож на идиота?», ничего при этом не проверив.

Вместо этого скажите: «Иногда разъём запыляется и соединение ослабевает. Можете отключить разъём, выдуть из него пыль и снова подключить его?»

В этой статье я покажу, как можно обойти шифрование BitLocker в Windows 11 (версия 24H2) и извлечь из памяти ключи шифрования тома (full volume encryption key, FVEK) при помощи моего инструмента Memory-Dump-UEFI.

Краткая справка

Если у нападающего есть физический доступ к устройству, то он потенциально может получить доступ, резко перезапустив компьютер и выполнив дамп ОЗУ из недавно выполнявшихся экземпляров Windows. Дамп памяти можно проанализировать, чтобы найти конфиденциальную информацию, например, ключи FVEK. Эта методика не работает гарантированно, потому что после отключения питания содержимое ОЗУ быстро деградирует.


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

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

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

«Привет, я слышал, ты программист! Это отлично, потому что у меня и моего друга есть одна идея для бизнеса. Со всем важным мы разобрались, и нам просто нужен программист, чтобы соединить всё это вместе».

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

«Сейчас у меня есть несколько других проектов, но я всегда с радостью готов изучить что-то новое и посмотреть, подойдёт ли это мне. Если ты хочешь, чтобы это был просто обмен денег на труд, то чтобы заинтересовать меня, нужно примерно $X в час. С другой стороны, если у тебя нет капитала для стартапа и ты хочешь оплатить работу долей в бизнесе, то я хочу примерно X% от компании (и этот вариант, разумеется, будет зависеть от того, покажется ли мне бизнес жизнеспособным и интересным для моих вложений)».

На самом деле я не ожидал, что его заинтересуют подобные условия, но думал, что он сделает контроффер или, по крайней мере, покажет, что ему больше нравится сумма/доля Y, а не X. Однако его ответ меня немного удивил.

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

Вонючее начало

В момент начала пандемии COVID-19 Дэниелу Синглтери уже осточертела его работа. Работая сантехником в коммерческих и жилых зданиях Атланты, он в свои 11-часовые смены решал самые грязные и вонючие проблемы в стране.

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

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

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

Идея о том, что язык программирования может реализовать сам себя, удивительна. Она вызывает сильное любопытство: «Как это вообще может выглядеть?» С момента своего появления в начале 60-х это мог делать Lisp.

В начале 60-х Джон Маккарти придумал серию примечательных идей, хорошо сочетающихся друг с другом и актуальных даже спустя десятки лет. Сначала он сформулировал их в статье о Lisp, а чуть позже — в руководстве по Lisp 1.5.


Джон Маккарти

Одной из таких идей стала гомоиконичность — поведение, при котором код и данные взаимозаменяемы. Обычно мы воспринимаем код как последовательность команд, оперирующих с данными. Такое понимание формирует наш взгляд на большинство современных языков программирования. Однако Lisp нарушает этот принцип, обращаясь с кодом и с данными одинаково — это называют его гомоиконичной природой. Эта уникальная характеристика, по сути, размывает границы между оператором (кодом) и операндом (данными).

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

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

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

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

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

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

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

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

Давайте изучим это на примере деградации кода.

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

Алгоритм

Алгоритм* прост. Сначала мы записываем первое число с плавающей запятой полностью; для всех последующих чисел выполняется XOR с предыдущим числом, а затем результат кодируется одним из трёх способов.

[*Конкретно эта версия сжатия чисел с плавающей запятой при помощи XOR была впервые описана в «Gorilla: A Fast, Scalable, In-Memory Time Series Database» и часто называется «Gorilla-сжатием».]

Детективное расследование по делу о почте Proton с шифрованием.

Внезапное молчание

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

Вместо них я начал получать зашифрованные PGP письма с пустым телом, которые выглядели вот так:


При изучении сообщения становилось очевидно, что это зашифрованное письмо, которое не поддерживает Fastmail. У этого сервиса есть целый пост, объясняющий такую позицию: https://www.fastmail.com/blog/why-we-dont-offer-pgp/, но до недавнего момента меня это не особо беспокоило, ведь никто не отправляет мне зашифрованные письма.

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

В начале 70-х молодые кинематографисты Джон Карпентер и Дэн О'Бэннон создали в качестве дипломного проекта историю о космическом корабле… не подозревая, что она повлияет на «Чужого» и множество других работ.

«Тёмная звезда» (Dark Star) — это снятый за 60 тысяч долларов студентами киношколы фильм, сегодня считающийся культовой классикой научной фантастики; он стал режиссёрским дебютом маэстро хоррора Джона Карпентера. Этой ленте недавно исполнилось пятьдесят лет; она равно далека от того, что снималось и до, и после неё — это не космическая одиссея и не космическая опера, а, скорее, холодная, мрачная и часто абсурдная картина о людях, оказавшихся вместе на неисправной межзвёздной консервной банке. Вероятно, самой известной её сценой оказалась экзистенциальная дискуссия между астронавтом и наделённой разумом бомбой.

Двадцать лет назад я ввязался в публичную перепалку (дружескую) с Крисом Андерсоном, работавшим тогда главным редактором Wired. Я публично выразил своё разочарование публикуемыми в Wired радужными обзорами отягощённых DRM цифровых устройств. Андерсон сказал, что я идеалист, если жду, что журнал откажется от обзоров гаджетов из-за DRM:

https://longtail.typepad.com/the_long_tail/2004/12/is_drm_evil.html

Я публично ответил, сказав ему, что он неправильно меня понял. Дело было не в идеологической чистоте, а в добросовестности обзоров. Wired призывал покупать продукт, потому что у него имелись функции x, y и z, но в любой момент в будущем производитель мог отключить любые из этих функций:

https://memex.craphound.com/2004/12/29/cory-responds-to-wired-editor-on-drm/

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

Почему ты захотела стать программистом?

Я решила стать программистом в 1965-66 годах. Прочитав статью, где на иллюстрации была показана блок-схема, я подумала: «это моё». Когда я выпустилась из старшей школы в 1967 году, не было ни одного университета, обучающего программированию, но существовал полугодовой курс в Сольне [прим. пер.: Сольна — коммуна в Швеции], который превратился в годовой курс, и на него могли выдать студенческий заём. Поэтому я подала на него заявление.

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

Однако у SJ оказалось 700 кандидатов на 50 мест, поэтому они устроили суровый процесс отбора с различными тестами. И мне удалось пройти их! Мне нужна была зарплата, чтобы оплачивать собственное жильё, так что я приняла предложение.

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

Жили-были разработчики ПО, игнорировавшие рекомендованные методики наподобие предметно-ориентированного проектирования (Domain-Driven Design); они срезали углы, чтобы выпускать продукты быстро. Они думали: «Нам платят за написание кода, а не за проектирование!»

Менеджер по продукту, в свою очередь, игнорировал то, что игнорировала команда разработки. Он даже не мог сказать, чем именно они пренебрегали. Он был убеждён, что всё, не касающееся написания кода — пустая трата времени. Он думал: «Клиенты платят нам за работающее ПО!»

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

Я думаю начать учиться писать код. Какой ноутбук мне купить? Нужно ли участвовать в буткемпе? Нужны ли моему ребёнку особые курсы или подготовка, чтобы поступить на computer science?

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

Приведу свой совет вкратце

Прежде чем думать обо всём этом: специальности, вузе, в который будет поступать ребёнок, покупке ноутбука, вам нужно понять, есть ли у вас (или у ребёнка) «искра программирования».

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

В 1994 году Nintendo подала в США заявку на крайне примечательный патент.

Патент US6115036A — «Оборудование для редактирования программ видеоигр/видеографики с функциями остановки программ и передачи данных»

Иными словами:

Nintendo Game Processor — это специализированный компьютер с клавиатурой и мышью, созданный с одной конкретной целью: для визуального создания собственных игр Super Nintendo при помощи drag and drop и записи этих игр на настоящие картриджи SNES.

Вот как мог выглядеть Game Processor:


Обратите внимание на четыре разъёма сбоку в стиле SNES / Super Famicom. Один для клавиатуры, один для мыши и два для контроллеров SNES.

Super Game Boy позволяет играть в игры Game Boy на Super Nintendo. Это впечатляет, учитывая, что эти две консоли не имеют практически ничего общего. Сегодня мы рассмотрим гибридное устройство, создающее многопроцессорную машину, в которой два CPU совершенно непохожи друг на друга. А возможно, мы заставим Super Game Boy работать действительно быстро.

Смерть, налоги и безудержно разрастающиеся браузерные движки — вот три вещи, в которых можно быть твёрдо уверенным. Актуально это было и на начало 2020 года, когда я осознал, что из-за безжалостного роста Chromium рано или поздно мы будем создавать файлы PDB (отладочных символов Windows), превосходящие предел формата PDB в 4 ГиБ.

В феврале 2020 года я зарегистрировал баг Visual Studio с просьбой увеличения этого предела, и спустя три года и три дня мы дёрнули рубильник, и теперь Chromium может создавать PDB большего размера. На тот момент PDB для Chrome занимал 95% от 4 ГиБ, а многие тестовые двоичные файлы уже преодолели этот порог, так что это было сделано вовремя.