Оберон-клуб «ВЄДАsoft»

Некоторые воспоминания о Никлаусе Вирте
4 января 2024 г.

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

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

На самом деле, если бы не Никлаус, сомнительно, что я вообще занялся бы информатикой. Моя первая степень была по математике. Я заинтересовался информатикой, потому что меня увлекали компиляторы и языки программирования. Первым языком, который я глубоко полюбил, был Паскаль. Это было просто, понятно и легко понять как с точки зрения дизайна, так и с точки зрения реализации. Вместе с Питером Солличем, сокурсником, я затем наткнулся на листинги исходного кода компилятора Pascal в P-Code. Удивительно, что полный компилятор Паскаля мог быть написан примерно в 5000 строк простого для понимания кода. Это положило начало нашему проекту по написанию собственного компилятора Паскаля для нового микрокомпьютера Osborne 1. Это было примерно за год до выхода Turbo Pascal.

Примерно в середине проекта Питер обнаружил ещё пару тонких исследовательских отчётов в жёлтых переплётах от Никлауса Вирта из ETH. Один описывал язык Модула-2, другой — набор инструкций для компьютера Лилит, реализующий этот язык. Мы сразу были очарованы как языком, так и набором инструкций, которые были одновременно простыми и очень компактными. В то время экономия памяти имела первостепенное значение, поскольку на нашем компьютере было всего 54 килобайта полезной памяти. Поэтому мы переключили скомпилированный исходный язык на Модулу-2, а промежуточный код на вариант кода Лилит. Этот компилятор в конечном итоге стал Turbo Modula-2 для 8-битных компьютеров. Мы продали его компании Borland, но компания не распространяла его под своим именем.

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

Работа в группе Вирта была совершенно особенной. Я понял насколько другим стало это рабочее место только после того, как ушёл. Видите ли, всё, с чем мы работали, было «самодельным», но в то же время выходило далеко за рамки стандартов того времени. Все началось с компьютера: экрана, который мог отображать полную страницу формата А4 на растровом дисплее, и мыши для взаимодействия с ней. Это как минимум за 5 лет до того, как появился коммерческий компьютер с такими характеристиками. Продолжение было со шрифтами. Поскольку не было растровых дисплеев, не было и шрифтов для таких дисплеев. Итак, один член группы был профессиональным дизайнером шрифтов, а другой — дизайнером инструментов для проектирования шрифтов! Продолжалось это с операционной системой и инструментами программирования. У нас был простой, но мощный текстовый редактор, который можно было настроить как очень производительную среду разработки. У нас также был простой и красивый отладчик, который показывал дамп потока с полным исследованием памяти в наборе мозаичных окон. Забыл упомянуть, оконную систему конечно тоже разработали, всё было.

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

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

Я считаю последовательность языков, над которыми работал Никлаус, своего рода кульминацией языков фон Неймана. После своего дипломного проекта EULER он работал над ALGOL-W, предполагаемым преемником Алгола 60, который был поддержан другими ведущими светилами информатики, такими как Тони Хоар или Эдсгер Дейкстра, но в конечном итоге не был принят в качестве официальной следующей версии Алгола. Следующим был Паскаль, добившийся огромных успехов в преподавании и на ПК. После Паскаля появилась Modula, а затем Modula-2 — язык, который мне лично нравился больше всего. Он добавил к Паскалю концепции модульности, которые позволили команде разработчиков работать над общей базой кода, а также концепции параллелизма, которые были чище и мощнее, чем то, что появилось 15 лет спустя с Java. Последним из языков Вирта был Оберон, который добавил минималистическую конструкцию для поддержки расширяемых программ, относящихся к области объектной ориентации, и в остальном отказался от многих функций Модулы-2. Следовательно, его было даже проще реализовать, чем Модулу-2, и поэтому можно было разработать полную операционную систему с графическим интерфейсом пользователя и компилятором на небольшой кодовой базе и описать её в одной книге.

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

Несколько конкретных вещей, которые я помню:

• Никлаус не любил комитеты, вероятно, из-за своего опыта работы в комитете по Алголу 68. Меня пригласили стать частью комитета по стандартизации ISO для Модулы-2. Вирт сказал мне, что я могу пойти, если захочу, но дал понять, что, по его мнению, это не стоит усилий. Он не собирался присутствовать сам. Я присутствовал на нескольких заседаниях комитета, а затем бросил это.

• Никлаус видел свою роль, в основном, как пионера и исследователя, а не как лидера языкового сообщества. Незадолго до моего приезда в Цюрих у Модулы-2 случился небольшой момент славы: ей был посвящен целый номер ведущего тогда журнала PC Magazine Byte. При большей поддержке Modula-2 мог бы стать широко распространённым системным языком, и он определенно этого заслужил. Было также предложение о языке-преемнике под названием Modula-3, разработанном Лукой Карделли, Грегом Нельсоном и другими в DEC SRC. Это также был очень чистый и элегантный языковой дизайн, более амбициозный и мощный, чем Modula-2. Если бы Никлаус присоединился к этим усилиям, кто знает, возможно, он стал бы популярным преемником и конкурентом C++. Но он уже работал над своей следующей вещью — Обероном.

Никлаус объединил теоретические и практические результаты глубже, чем любой другой человек, которого я знаю. Он был одним из отцов структурного программирования и пионером в совершенствовании программ, что прекрасно описано в его книге «Структуры данных + алгоритмы = программы». Тем не менее, он сделал всё это, чтобы получить лучшие практические абстракции, которые помогли ему разработать чистые операционные системы, компиляторы и другие инструменты, и всё это в нескольких килобайтах памяти. В отличие от других системных языков, таких как Си, языки Вирта никогда не шли на компромисс в отношении наличия жестких абстракций. Я считаю, что это его непреходящее наследие: как теория и абстракция помогают в повседневном программировании, но только если всё сделано правильно, с безжалостным упором на простоту.

Никлаус Вирт 1934-2023 гг.

Мы теряем наших героев одного за другим. К тому времени, когда вам исполнится 70 лет, как и мне, вы начнете терять их гораздо чаще. Мы потеряли Дона Ланкастера ещё в июле. Книги Дона научили меня тому, как работает цифровая логика, ещё во второй половине 70-х. Его письмо было настолько хорошо, что я подражал ему, когда в 1980-х годах начал писать компьютерные статьи, а затем и книги.

Никлаус Вирт умер в Швейцарии в возрасте 89 лет. Он был ещё одним героем, который научил меня писать компьютерные программы, которые можно было прочитать. Паскаль не был первым языком программирования, который я когда-либо изучал; эта честь (а может и бесчестие) достается APL и чуть позже ФОРТУ. В 1978 году я написал форматтер текста на APL для мэйнфреймов. Это было 600 строк волнистой тарабарщины. К тому времени, как я добрался до низа, я уже забыл, как работает верх. ФОРТ, ну, чем меньше сказано, тем лучше. Я думаю об этом как о языке программирования магистра Йоды. Если вы когда-нибудь имели дело с ФОРТОМ, вы точно поймёте, что я имею в виду.

Мой друг Майк Бентли познакомил меня с Паскалем в 1980 или 1981 году. Вскоре после этого я купил компилятор для своей машины CP/M. Pascal/MT+ был потрясающим, настолько потрясающим, что я решил написать о нём книгу. Я написал примерно половину книги, когда из-за горизонта появился Turbo Pascal. К тому времени, как я закончил книгу по Pascal/MT+, Turbo Pascal захватил вселенную Pascal, и я переписал Pascal из Square One для Turbo Pascal. (Издатель переименовал книгу в Complete Turbo Pascal по причинам, которые я никогда не понимал.)

Я выучил Паскаль методом проб. Я научился писать на хорошем языке Паскаль, прочитав замечательную книгу Вирта «Алгоритмы + Структуры данных = Программы» 1976 года. Моё недовольство APL оставило во мне неизгладимое убеждение, что программное обеспечение должно быть доступно для чтения людям, которые его не писали — и не после сотен часов мучительной работы. Я выучил Си, который называют «языком ассемблера высокого уровня», что является противоречием. Моё мнение: поднимайтесь настолько высоко, насколько можете, или настолько низко, насколько можете. Для меня это означало Pascal (или BASIC, или COBOL) на верхнем уровне и настоящий ассемблер на нижнем уровне. Исходный код Си излишне неясен, и под этим я имею в виду только то, что он мог бы быть намного более читабельным, если бы его создатели решили не гордиться его неясностью. На самом деле существует конкурс на написание самых нечитаемых программ на языке Си, который, я думаю, многое расскажет вам о Си и его сторонниках. Было время, когда Си мог делать то, чего не мог Паскаль. Те дни давно, давно прошли, и я больше не буду здесь спорить.

Я выучил язык программирования Modula-2 Вирта, когда в 1980-х годах стали доступны его продукты. Я читал о Modula-3 (1988) и Oberon (1987), но никогда не писал на них код. Насколько я могу судить, они расширили возможности Паскаля, не повредив его понятности. Сам Паскаль уже давно вышел из-под контроля Вирта, и сегодня у нас есть чрезвычайно мощные реализации Паскаля, такие как Delphi и Lazarus/FreePascal. Но без Вирта такие люди, как я, все равно писали бы на BASIC или COBOL.

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

Всего доброго, сэр. Мы никогда не забудем тебя.

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

Жизнь профессора Никлауса Вирта невозможно описать в нескольких словах: он родился в Швейцарии в 1934 году, учился в ETH Цюриха, а затем получил докторскую степень по информатике в Беркли. Именно там он познакомился с компьютерными языками и компиляторами. Он получил премию Тьюринга ACM (Нобелевскую премию в области информатики) в 1984 году. Он изобрёл множество языков, в том числе знаменитый язык Паскаль, а также Модула-2.

Но сводить карьеру Никлауса Вирта только к компьютерным языкам было бы неправильно. Он изобретал компьютерные системы, включая ОС с человеко-машинным интерфейсом, среды разработки с языками и компиляторами.

Он проработал два года в исследовательском центре Xerox PARC в Пало-Альто, вдохновившись цитатой Алана Кея, который там работал: «Люди, серьёзно занимающиеся разработкой программного обеспечения, должны создавать своё собственное оборудование». Таким образом, в 1980 году, за четыре года до появления Mac, Никлаус Вирт начал разрабатывать Lilith, одну из первых рабочих станций с мышью и графическим дисплеем высокого разрешения, но так и не достигшую коммерческого успеха американских решений.

В 1992 году в «Руководстве по системе Оберон» он объяснил, что, несмотря на закон Мура, который гласит, что мощность полупроводников удваивается каждые два года, программное обеспечение становится больше и менее оптимизированным с той же скоростью. Это было названо законом Вирта: несмотря на многочисленные достижения, аппаратное обеспечение ускоряется медленнее, чем замедляется программное обеспечение. Система «Оберон», состоявшая из операционной системы, языка и компьютера, имела целью противоречить закону Вирта. В 2013 году (ему на тот момент было 79 лет!) вышла новая версия Оберона, где Вирт зашёл так далеко, что спроектировал собственный микропроцессор на основе ПЛИС (FPGA).

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

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

Спасибо за Ваш вклад, профессор Вирт, пусть цифровые сообщества воздадут Вам должное, следуя Вашим принципам!

Тристан Нито, Окто

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

Этот пост посвящён памяти Никлауса Вирта, пионера компьютерных технологий, который скончался 1 января 2024 года. В 1995 году он написал влиятельную статью под названием «Призыв к экономичному программному обеспечению», опубликованную в Computer, журнале для членов IEEE Computer Society, которую я прочитал в начале своей карьеры предпринимателя и разработчика программного обеспечения. Далее я попытаюсь обосновать то же самое почти 30 лет спустя, с учётом сегодняшних компьютерных ужасов. Версия этого поста изначально была опубликована в моем личном блоге Berthub.eu.

Несколько лет назад я выступил в местном университете с докладом о кибербезопасности под названием «Кибер и информационная безопасность: мы все сошли с ума?». Это всё ещё стоит прочитать сегодня, поскольку мы все вместе сошли с ума.

То, как мы создаём и поставляем программное обеспечение в наши дни, большей частью просто смешно. Это приводит к тому, что приложения используют миллионы строк кода, чтобы открыть дверь гаража, а другие простые программы импортируют 1600 внешних библиотек кода (зависимостей) неизвестного происхождения. Безопасность программного обеспечения ужасна, и это зависит как от качества кода, так и от его объёма. Многие из нас, программистов, знают, что текущая ситуация несостоятельна. К сожалению, многие программисты (и их руководство) никогда не сталкивались с чем-то другим. А у остальных из нас редко бывает время сделать свою работу лучше.

>>
Это касается не только вас; мы не просто страдаем от ностальгии: программное обеспечение сегодня действительно очень странное.

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

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

Ужасное состояние безопасности программного обеспечения

Не вдаваясь в подробности: «Старик (48 лет) кричит на облако», позвольте мне ещё раз констатировать некоторые очевидные вещи. Состояние безопасности программного обеспечения является ужасным. Если мы посмотрим только на прошлый год, если вы использовали стандартное программное обеспечение, такое как Ivanti, MOVEit, Outlook, Confluence, Barracuda Email Security Gateway, Citrix NetScaler ADC и NetScaler Gateway, скорее всего, вас взломали. Даже компании с почти бесконечными ресурсами (такие как Apple и Google) допускали тривиальные «худшие» ошибки безопасности, которые подвергли опасности их клиентов. Тем не менее, мы продолжаем полагаться на все эти продукты.

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

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

Предполагается, что облако каким-то образом способно сделать небезопасное программное обеспечение заслуживающим доверия. Однако в прошлом году мы узнали, что платформа электронной почты Microsoft была тщательно взломана, включая секретную правительственную электронную почту. ( Дважды! ) Есть и вполне обоснованные опасения по поводу безопасности облака Azure. Между тем, любимец отрасли Okta, предоставляющий облачное программное обеспечение, позволяющее пользователям входить в различные приложения, перешёл в полную собственность. Это было их второе нарушение за два года. Кроме того, наблюдалось подозрительное количество случаев взлома пользователей Okta.

Очевидно, нам нужно лучшее программное обеспечение.

Европейский Союз принял три законодательных акта с этой целью: NIS2 для важных услуг; Закон о киберустойчивости практически для всего коммерческого программного обеспечения и электронных устройств; и обновлённую Директиву об ответственности за качество продукции, которая также распространяется на программное обеспечение. Законодательство всегда сложное, и ещё неизвестно, правильно ли они его поняли. Но то, что безопасность программного обеспечения в наши дни настолько ужасна, что требует принятия закона, кажется очевидным.

Почему безопасность программного обеспечения так плоха

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

Безопасность программного обеспечения зависит от двух факторов — плотности проблем безопасности в исходном коде и огромного количества кода, доступного хакерам. Как любили подчеркивать в 1980-х годах представители оборонного сообщества США, количество имеет своё собственное качество. Обратное справедливо и для программного обеспечения: чем больше у вас его, тем большему риску вы подвергаетесь.

Например, пользователи Apple iPhone неоднократно подвергались взлому на протяжении многих лет из-за огромной поверхности атаки, открытой iMessage. Можно отправить незапрошенное iMessage пользователю Apple. Телефон немедленно обработает это сообщение и сможет просмотреть его. Проблема в том, что Apple мудро решила, что такие нежелательные сообщения должны поддерживать широкий спектр форматов изображений, случайно включая PDF-файлы со странными встроенными сжатыми шрифтами, использующими древний формат, который фактически включал язык программирования. Таким образом, кто-то может отправить на ваш iPhone незапрошенное сообщение, которое поможет выявить слабые места в остальной части телефона.

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

>>
Устранение всех ошибок в вашем коде не избавит вас от решения реализовать функцию автоматического выполнения кода, встроенного в документы.

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

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

Можем ли мы написать лучший код?

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

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

Состояние поставки программного обеспечения

Другая проблема заключается в том, что мы часто не знаем, какой код на самом деле отправляем. Программное обеспечение стало огромным. В 1995 году Никлаус Вирт посетовал, что размер программного обеспечения вырос до мегабайт. В своей статье «Призыв к экономичному программному обеспечению» он описал свою операционную систему Oberon, размер которой составлял всего 200 килобайт, включая редактор и компилятор. Сейчас существуют проекты, размер файлов конфигурации которых превышает 200 КБ.

Типичное приложение сегодня построено на Electron JS, платформе, включающей в себя как Chromium («Chrome»), так и Node.JS, которая обеспечивает доступ к десяткам тысяч программных пакетов для JavaScript. По моим оценкам, простое использование Electron JS требует не менее 50 миллионов строк кода, если вы включаете зависимости. Возможно, больше. Тем временем приложение, вероятно, содержит сотни или тысячи вспомогательных пакетов. Многие используемые пакеты также по умолчанию будут передавать информацию о ваших пользователях рекламодателям и другим брокерам данных. Зависимости влекут за собой дополнительные зависимости, и что именно включается в сборку, может меняться ежедневно, и никто точно не знает.

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

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

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

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

Раньше это была шутка, но в наши дни мы часто поставляем программное обеспечение в виде контейнеров, поставляя не только само программное обеспечение, но также включая файлы операционной системы, чтобы гарантировать, что программное обеспечение работает в хорошо известной среде. Зачастую это влечёт за собой доставку полного образа компьютерного диска. Это снова значительно увеличивает объём развёртываемого кода. Обратите внимание, что с контейнерами типа Docker можно делать хорошие вещи (см. ниже), но на Docker Hub много образов размером более 350 МБ.

>>
В мире выпускается слишком много кода, и мы даже не знаем, что поставляем, и недостаточно внимательно (или вообще не) присматриваемся к тому, что, как мы знаем, поставляем.

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

Теперь, даже если все включенные зависимости являются золотыми, уверены ли мы, что их обновления безопасности попадут в ваше приложение для открывания гаражных ворот? Интересно, сколько приложений Electron до сих пор поставляются с ошибкой обработки изображений, из-за которой Google и Apple в прошлом году пытались выпустить обновления? Мы даже не знаем.

Но что ещё хуже, это известный факт, что все эти зависимости не являются золотыми. Экосистема Node.js имеет комичную историю, когда репозитории пакетов были захвачены, взломаны или воскрешены под тем же именем кем-то другим, кто-то с гнусными планами по обеспечению вашей безопасности. PyPI (аналог Node.js на Python) страдает от аналогичных проблем. Зависимости всегда требуют тщательного изучения, но никто не может разумно ожидать, что они будут часто проверять тысячи из них. Но мы предпочитаем об этом не думать. (Обратите внимание, что вам также не следует переусердствовать и без необходимости переопределять всё самостоятельно, чтобы предотвратить зависимости. Существуют очень хорошие модули, которые, вероятно, более безопасны, чем те, которые вы можете ввести самостоятельно.)

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

Вы можете писать экономичный код уже сегодня

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

Трифекта – это результат. Это настоящее автономное программное обеспечение, которое позволяет вам использовать браузер для перетаскивания изображений для удобного обмена ими. Меня годами мучило то, что мне приходилось использовать imgur для этой цели. Imgur не только устанавливает множество файлов cookie и трекеров в мой браузер, я также навязываю эти трекеры людям, которые просматривают изображения, которыми я делюсь. Если вы хотите самостоятельно разместить такой веб-сервис, вы также не хотите, чтобы вас взломали. Большинство решений для обмена изображениями, которые, как я обнаружил, вы можете запустить самостоятельно, основаны на огромных платформах, которым я не слишком доверяю по причинам, изложенным выше.

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

В итоге вы получите в общей сложности 3 мегабайта кода.

Напротив, ещё одно решение для обмена изображениями поставляется в виде образа Docker размером 288 МБ, хотя, по общему признанию, оно выглядит лучше и имеет некоторые дополнительные функции. Но их размер не составляет 285 МБ. Ещё одно сравнение — это решение для обмена изображениями на базе Node, которое насчитывает 1600 зависимостей, что, по-видимому, составляет более 4 миллионов строк JavaScript.

>>
В мире поставляется слишком много кода, большая часть которого написана третьими лицами, иногда непреднамеренно, большая часть не проверяется. Из-за этого существует огромная поверхность атаки, полная посредственного кода.

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

Ответ на Trifecta

Это было довольно интересно. До сих пор наиболее распространённой реакцией на Trifecta было то, что для её развёртывания мне следует использовать целый пакет веб-сервисов Amazon. Это чрезвычайно странный ответ на проект с чётко сформулированной целью предоставления автономного программного обеспечения, не зависящего от внешних сервисов. Я не уверен, что здесь происходит.

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

Я хочу закончить этот пост некоторыми наблюдениями из статьи Никлауса Вирта 1995 года:

«Для некоторых сложность равна силе. (…) Люди всё чаще ошибочно интерпретируют сложность как изысканность, что сбивает с толку: непостижимое должно вызывать подозрение, а не восхищение».

Я также заметил, что некоторые люди предпочитают сложные системы. Как давно заметил Тони Хоар: «Существует два метода проектирования программного обеспечения. Один из них — сделать программу настолько простой, чтобы в ней явно не было ошибок. Другой — сделать это настолько сложным, чтобы не было очевидных ошибок». Если вы не умеете делать первый вариант, второй способ, возможно, станет выглядеть ужасно привлекательным.

Вернёмся к Вирту:

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

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

«Чума, вызванная взрывом программного обеспечения, не является «законом природы». Этого можно избежать, и задача инженера-программиста — сократить его».

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

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

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