Показаны сообщения с ярлыком Интервью Расмуса Лердорфа для SitePoint. Показать все сообщения
Показаны сообщения с ярлыком Интервью Расмуса Лердорфа для SitePoint. Показать все сообщения

четверг, 24 января 2019 г.

Интервью Расмуса Лердорфа для SitePoint

Интервью Расмуса Лердорфа для SitePoint

Автор: Kevin Yank (SitePoint.com)
Перевод: Дмитрий Лебедев (detail.phpclub.net)
Кевин Янк (Kevin Yank): Недавно участники форумов сообщества SitePoint собрались вместе и сформулировали подборку вопросов к создателю PHP, Расмусу Лердорфу. Я был доволен, когда прочитал его ответы и узнал, что человек, который изначально запустил в движение механизм PHP, видит безоблачным то, что происходит с движением open source. Перевод Дмитрия Лебедева (detail)
Он спешит преуменьшить свой вклад в то, чем является PHP сегодня, и приписывает основную долю успеха PHP большому сообществу разработчиков, за годы оставивших свой след в проекте. То есть Расмус сегодня — просто самый большой фанат PHP.
Но хватит с меня, давайте послушаем, что говорил Расмус.
В начале...
SP: Каким был ваш первый контакт с движением Open Source и что в нём такого, на что вы "подсели"?
RL: Тогда в начале и середине 90-х термин "Open Source" не существовал.
Существовало "бесплатное программное обеспечение", конечно же, и я игрался с Линуксом с самого первого релиза в 1991 году. До этого я использовал QNX и Xenix и начал играться с Minix пока меня не выручил Линукс.
Не думаю, что когда либо я пристращался к "движению". Когда у вас нет денег, чтобы купить Юникс, и вы можете скачать что-то, что работает, и даже найти людей, которые могут вам помочь поставить это и запустить, как можно обойти это? Культ никогда не играл роли.
SL: Что заставило вас разработать PHP? И что по вашему мнению этот язык может предложить, чего нет в других?
RL: Первая версия PHP была простым набором инструментов, которые я выложил вместе на мой сайт для пары проектов. Один инструмент делал высшего качества логи в базу данных mSQL, другой работал как обработчик форм. Я закончил на 30 разных маленьких CGI-программ написанных на C, когда устал от этого и соединил их в одну библиотеку на C. Затем я написал очень простой парсер, который бы брал теги из HTML-файлов и заменял их на вывод соответствующих функций в библиотеке.
Простой парсер медленно вырос до включения условных тегов, затем циклов, функций и так далее. Я никогда не думал, что пишу язык сценариев. Я просто добавлял немного функциональности в парсер, заменяющий макросы. Я по-прежнему писал всю свою логику для реального бизнеса на C.
Наконец, что на мой взгляд выделило PHP в те ранние дни и до сих пор — это то, что он [PHP] всегда пытается найти кратчайший путь в решении проблемы веба. Он не пытается стать языком сценариев общего назначения, и любой, кто ищет решения проблем интернета, найдёт прямое решение при помощи PHP. Многие альтернативы, которые претендуют на решение проблем интернета, просто слишком сложны. Когда вам нужно что-то установленное и работающее к пятнице, чтобы не надо было тратить все выходные листая восьмисотстраничные мануалы, PHP начинает выглядеть довольно хорошо.
SP: Если посмотреть на цифры, сейчас более 9 миллионов доменов используют PHP. Вы когда-нибудь думали, что PHP станет таким большим? Каково чувствовать, что ваш продукт — возможно, самая лучшая альтернатива решениям Майкрософта для веба?
RL: Во-первых, пусть будет ясно, что я не разрабатывал PHP, который мы знаем сегодня. Десятки, если не сотни людей разрабатывали PHP. Я был просто первым разработчиком.
PHP — в значительной степени совместный проект. Подумайте так: у вас есть проблема связанная с вебом. Вы можете либо пойти в магазин и купить дорогой продукт в целлофане, который может или не может решить большинство ваших проблем. Либо вы собираетесь вместе с некоторыми из тысяч людей, у которых есть точно такая же проблема, как и у вас, и вырабатываете решение, которое работает на всех из вас.
Вы не только получите решение, направленное именно на вашу проблему, вы также станете частью одинаково мыслящего сообщества, где идеи и опыт распространяются свободно. Это превосходит любой коммерческий продукт, который можно купить в магазине, и по мне это лучший способ разработки такого рода софта.
Поэтому когда люди спрашивают меня, каково чувствовать себя разработавшим что-то, что используют миллионы людей, это не соответствует моему взгляду на вещи. Наконец, я просто первый член сообщества, которое возникло вокруг одного подхода к решению проблем веба.
SP: Кого бы вы назвали своим героем? Какие люди из или извне IT воодушевляли вас?
RL: На самом деле, люди меня не воодушевляют в метафизическом смысле. Но я определённо ценю и уважаю превосходные решения сложных проблем.
SP: Как вы думаете, какое самое важное решение за годы разработок PHP вы приняли? Есть ли решения, которые в приняли и которые сейчас хотелось бы сделать по-другому?
RL: Сложно просить меня предугадать решения, которые были сделаны 6 или 7 лет назад, когда PHP использовался в общей сумме одним человеком. Не забывайте, что я не брался написать язык сценариев, который бы использовался на 9 миллионах доменов, я брался за решение проблем. Решение проблемы до 5 вечера, чтобы потом вы могли пойти в кино с подругой ведёт к тем перспективам, которые не идеальны 7 лет спустя, когда тысячам людей приходится работать над добавленной вами ночной писаниной.
Самое правильное решение, которое я принял за всё время было, возможно, отменить контроль. Открыть проект и дать любому, кто попросит, полный доступ к исходникам PHP. Это привело множество очень талантливых людей. Проект PHP, возможно, самый большой, если считать по количеству людей, которым вверяют доступ к CVS-репозитарию, где живёт код и документация.
Движение Open Source
SP: Движение Open Source всё ещё представляется многими, как "анархистское" и своего рода "опасностью для общества". Чувствуете ли вы, что оно когда-нибудь добьётся принятия мейнстримом? Если да, то как сообщество Open Source будет с этим поступать?
RL: Я полагаю, у этого вопроса есть две части.
Как и мейнстрим, продукт этого "движения" — определённо является мейнстримом. "Движение" построило интернет таким, каким мы его сегодня знаем. Оно построило стек TCP/IP, используемые в большинстве операционных систем (да, даже в Windows). Оно не только создало самый популярный веб-сервер в мире (имеется в виду Apache — прим. переводчика), но и системы DNS и MTA, которыми интернет и живёт. И если вы оглянетесь немного назад, вы поймете, что OpenSource сегодня это целая отрасль разработки программ. Все первые операционные системы были с открытым исходным кодом, потому что это был единственный разумный способ работать. Вы не могли продать кому-нибудь большой мейнфрейм без предоставления исходников мозга этой вещи. Только позднее была представлена концепция непредоставления исходного кода.
Но я полагаю, ваш реальный вопрос — что я думаю о попытках Майкрософта убедить мир, что большие группы людей, сотрудничающих, чтобы решать проблемы, как-то угрожают самой структуре общества, в котором мы живём. И я не думаю, что есть "много" людей, заявляющих это, поскольку это полная чепуха — я бы хотел считать мир хорошим местом, не наполненным людьми, которые распространяют такую нелепую идею. Давайте положим конец всем встречам больших групп людей, если на то пошло. Они могут быть злыми анархистами, которые разрушат мир.
В конце концов, принятие мейнстримом — не цель. Цель для большинства людей, которые работают над бесплатным софтом и opensource-проектами — сама технология. Это построение инструмента, который решает проблему. Это не идеология для большинства из нас, и поэтому принятие мейнстримом включает в себя лишь общепринятое использование технологии. На многих направлениях это было достигнуто, на многих это ещё впереди.
SP: PHP уделяется очень мало внимания со стороны мейнстрима IT-прессы. Чувствуете ли вы, что PHP нарочно игнорируется вне кругов Open Source?
RL: PHP — не очень захватывающая вещь. Это тонкий слой клея между веб-сервером и разными вещами, с которыми вам хочется, чтобы ваш сервер говорил.
По старой традиции Юникса мы полагаемся на маленькие специализированные добавочные библиотеки для подъёма всех тяжёлых действий с как можно меньшим вмешательством со стороны PHP. И ASP, и JSP, и Cold Fusion имеют большие компании с большими рекламными бюджетами за спиной и сами продукты становятся больше и сложнее с каждым релизом, чтобы покупатели чувствовали, что они стоят таких денег. Кто выложит 10 000 долларов за дискету и двухстраничный мануал?
Дискета и 2-страничное руководство могут на самом деле быть тем, что им нужно для решения их проблемы, и вполне будет стоить потратить 10 000 долларов на маленькое целевое решение как это. Маленькие целевые решения вызывают мало интереса у больших софтверных компаний. Концепция не масштабируется. Маленькие целевые решения без рекламного бюджета не интересуют рекламные газеты.
Так что нет, я не думаю, что это нарочно PHP получает мало внимания прессы. PHP так же восхитителен, как и зубная щётка. Вы используете её каждый день, она делает работу, это простой инструмент, и что? Кто захочет читать о зубных щётках?
SP: Уход от публичной лицензии* GNU** при переходе PHP от третьей к четвёртой версии вызвал суматоху среди сообщества Open Source. Чувствуете ли вы, что новая модель лицензирования сейчас принята и понята как наилучшее направление, которое PHP мог выбрать?
Общая Публичная Лицензия (General Public License, аббрев. GPL) — типовая лицензия на распространение программного обеспечения, представленная движением GNU. Широко используется для лицензирования свободно распространяемого ПО. Текст лицензии (прим. переводчика)
** GNU — проект развития свободно распространяемой Unix-подобной операционной системы. Сайт проекта. (прим. переводчика)
RL: PHP 3 на самом деле имел две лицензии. Поэтому мы на самом деле не перешли с GPL к чему-то ещё, а просто убрали часть GPL.
Я не вижу смысла в двойном лицензировании, и оно вызывает много путаницы. Постановкой PHP под лицензию, подобную той, под которой распространяется Apache, было разрешено многое из этой путаницы.
Двойное лицензирование реально не работает, если дело касается меня — люди в любом случае будут использовать менее строгую из двух лицензий. Различные запреты, которые предлагает GPL, бессмысленны, если люди могут просто выбрать пользование под менее ограничивающей лицензии типа Apache. Поэтому имело смысл просто использовать менее ограничивающую из двух лицензий.
Если вы посмотрите вокруг, нет особо значительных GPL-нутых языков сценариев. Под GPL-нутыми я имею в виду строго идущими лишь под GPL. Perl — двулицензионный с полностью неограничивающей художественной лицензией. Python имеет собственную лицензию. Ruby двулицензионный со своей лицензией. Tcl распространяется под лицензией BSD-типа. Не вижу, почему то, что PHP не распространяется под GPL, расстраивает кого-либо.
...реально GPL не нужна. Для меня не проблема, если Майкрософт забросит ASP и полностью перейдёт на PHP. Безусловно, они могут принять и расширить его, но в таком случае мы будем с ними в чисто технической гонке. Это битва, которую мы можем выиграть, и, наконец, иметь PHP везде было бы классной штукой для PHP-сообщества.
PHP сегодня
SP: К чему бы вы приписали успех PHP? Чувствуете ли вы, что PHP имеет какое-либо особое слабое место (в сравнении с другими языками)?
RL: Людям нравится PHP, потому что он решает их веб-задачи. А раз так, я не вижу какого-либо слабого места. Он делает работу, для которой был разработан.
Кое-кто может приводить довод, что определённые аспекты PHP не так развиты, как в других языках. Для примера — поддержка ООП. Но в конечном счёте оно мало нужно для решения задач веба, а скорее для эстетики и стремлении к чистоте языка.
SP: Вы по-прежнему активно вовлечены в развитие PHP?
Я всё ещё достаточно вовлечён. Я не трачу 20 часов в день, как делал это в первую пару лет, но по-прежнему устраняю ошибки, спорю с другими разработчиками по поводу деталей и порой вскакиваю и вставляю лишний новый кусочек тут и там.
SP: Какой веб-сервер лучше всех поддерживает PHP? Apache или какой-то ещё? И на какой платформе лучше всего работает PHP? Линукс/Интел, Солярис/SPARC или другая?
RL: Полагаю, всё сводится к тому, какая получает наибольшее внимание. Большинство людей используют Линукс/Интел с Apache. Это значит, что ошибки на этой платформе находятся самими разработчиками быстро, и маловероятно, что конечный пользователь столкнётся с чем-то, с чем ещё не сталкивались разработчики. Другие платформы Юникс-мейнстрима, такие как Солярис/SPARC и FreeBSD/Интел с Apache так же находятся в их числе.
SP: PHP обычно бывает спаренный с MySQL. Насколько много две команды сотрудничают в области разработок?
RL: Мы знаем ребят из MySQL очень хорошо. Первый код для базы данных в PHP был написан для предшественника MySQL, который назывался mSQL. Интерфейс к MySQL, когда он появился, был полностью совместим с интерфейсом mSQL, так что с самых первых дней существования MySQL PHP хорошо поддерживал его. Эта пара работает потому что PHP и MySQL имеют обыкновение выбирать минималистический и очень прямой подход к решению проблем.
С точки зрения сотрудничества на уровне разработки — такого в действительности немного. Но много и не требуется. PHP предоставляет тонкий слой, который просто выставляет интерфейс MySQL пользователю PHP. Мы поставляем вместе с PHP клиента MySQL, но эта библиотека полностью поддерживается командой разработчиков MySQL с небольшим участием нашей — кроме моментов когда они меняют структуру, конечно же.
SP: Полагаете ли вы, что PHP становится заменой Perl?
RL: Нет, Perl — это язык сценариев общего назначения. PHP особенно привязан к проблемам веба.
SP: Какова ваша точка зрения на Magic Quotes* и Register Globals**?
Опция, включающая автоматическое добавление обратного слеша к кавычкам в данных, приходящих из форм и HTTP-запросов. В SQL-запросах текстовые строки выделяются кавычками. Чтобы вставить строку, содержащую в себе кавычки, их нужно выделить ("эскейпить") обратными слешами ("\"). Это делается либо при помощи функции addslashes, либо автоматически при включенной опции Magic Quotes (прим. переводчика).
** Данные из POST и GET запросов (и аналогично других типов источников) доступны в массивах $HTTP_POST_VARS, $HTTP_GET_VARS. Например, значение поля name из формы будет находиться в $HTTP_POST_VARS["name"]. Опция Register Globals делает данные из этих запросов доступными по "простым" именам переменных. В данном примере — $name (прим. переводчика).
RL: Register Globals — одна из особенностей, которая привела людей в PHP. Простота создания веб-приложений, когда форма и другие переменные были автоматически доступны не может быть побеждена.
Лично я не был за выключение опции Register Globals по умолчанию. Это очень мало увеличивает общую безопасность приложения. Если люди не проверяют данные, приходящие от пользователя, тогда и без, и с включенными Registered Globals это приложение будет небезопасным.
Иметь отключенные Register Globals полезно только в одном случае — когда вы забываете инициализировать переменную до её использования, и кто-то, кто знает ваш код, использует это. Меняя уровень сообщений об ошибках, вы можете дать PHP найти эти случаи автоматически. В итоге, я думаю, всё, что сделало отключение Register Globals — это усложнило написание приложений на PHP.
И ещё это сделало нам 10-20 вопросов/сообщений об ошибках в день от пользователей, которых сбило с толку это изменение.
Magic Quotes произошли в те дни, когда PHP использовался в основном исключительно для приложений, работающих на базах данных. Эти программы принимали данные из формы и вставляли их в базу. Даже сегодня куча скриптов на PHP делают чуть больше этого.
Вам всё время нужно эскейпить кавычки перед тем, как вставлять строку в базу данных. Если вы этого не делаете, вы получаете уродскую ошибку SQL, и ваша программа не работает. После объяснения этого простого факта людям в пятидесятый раз на дню я решил, что с меня хватит, и заставил PHP эксейпить строки на лету. Таким образом, программы будут работать, а худшее, что может произойти — это кто-то увидит лишний обратный слеш ("\") на экране, когда они выводят данные напрямую вместо вставки их в базу.
Часто люди даже не замечают лишний \, поскольку это не вызвало фатальных ошибок SQL, и поэтому меня не приводят в замешательство письма с вопросами, что же происходит. Это было очень здорово.
Даже сегодня вы можете увидеть случайный сайт, где, очевидно, автор не осознавал, что данные нужно эскейпить перед вставкой в базу, и вы видите то тут, то там \. Каждый из этих сайтов — это письмо на саппорт, на которое нам не нужно было отвечать.
Информированные люди, которым не нравится эта фича, могут отключить её сами и управляться со всеми кавычками самостоятельно. А информированные, которые хотят писать компактные программы, могут просто проверить настройки, используя get_magic_quotes_gpc() и добавить вызов addslashes(), где нужно.
SP: Как вы полагаете, успешен ли баланс между коммерческим элементом и элементом открытого кода PHP?
RL: Я думаю, оно работает нормально. Различные коммерческие объекты заставляют индивидов работать над частями PHP — а это выгодно всем.
SP: Что было наиболее удивительным в инновационном использовании PHP, которое вы видели в интернете?
RL: Я продолжаю смотреть новые и причудливые вещи, последняя из которых — это ActiveScript SAPI модуль Уэза Фарлонга (Wez Furlong), который позволяет вам делать PHP-скрипт для клиентской стороны:
<html>
  ...
  <script language="ActivePHP">
    function clickit() {
      $GLOBALS["window"]->open("http://www.php.net");
    }
  </script>
  ...
  <img src="..." onclick="clickit();" />
</html>
PHPMole IDE для PHP Алана Ноулеса (Alan Knowles), написанный в PHP-GTK — также достаточно впечатляющий. Есть много других классных вещей на PHP в Сети, но эти, возможно, самые последние из того что я собирался делать.
Будущее PHP
SP: Существуют ли планы по серверным переменным с состоянием (кумулятивным переменным) в PHP? Было бы полезно поместить шаблонные объекты в разделяемую память, чтобы пользователям не приходилось бы подвергаться большим накладным расходам из-за обявления классов.
RL: Проект Альтернативного PHP Кэша (Alternative PHP Cache, APC) уже может держать шаблонные классы в разделяемой памяти, так что проблема была решена APC и другими.
Лично я полагаю, если у вас есть проблемы ресурсоёмкости, вам нужно либо немного упростить код, либо взяться за написание критических частей на C. Расширение PHP на уровне C в действительности намного легче, чем большинство людей думает.
SP: Нынешние "сессионные" переменные используют дисковое пространство (например, /tmp), что не очень хорошо для сайтов с высоким трафиком. Есть ли планы исправить это?
RL: С первого дня поддержки сессий в PHP мы обеспечили обработчик сессий для буфера в разделяемой памяти. Просто замените обработчик на mm вместо files в php.ini. Однако, для сайтов с высоким трафиком это не решение. Реальное решение — это балансировать нагрузку на сайте на нескольких уровнях.
Хранение данных сессии в памяти на одной машине не решит ничего. Для этого напишите свой собственный обработчик сохранения сессии и храните данные сессий в какого-либо рода центральной базе данных. Посмотрите руководство по функции session_set_save_handler.
SP: А что с пулингом коннектов к базам данных? Непрерывные (persistent) соединения не настолько хороши — есть ли планы применить пулинг соединений в будущем?
RL: Пул соединений должен управляться одним процессом. Поскольку большинство использует мультипроцессовый пред-разветвляющий сервер Apache, просто нет способа, которым PHP может делать пулинг соединений. Это должно осуществляться выделенным самостоятельным процессом, а это вне области самого PHP. И SQLRelay, и SRM* могут быть использованы для решения этой проблемы.
Когда общая архитектура для PHP будет однопроцессовом многопоточном веб-сервере, мы можем рассматривать помещение этой функциональности прямо в PHP, но до того дня это не имеет особого смысла. Даже Apache 2 — всё ещё будет многопроцессовым сервером, в котором каждый процесс будет способен держать в себе несколько потоков. Поэтому потенциально мы можем иметь пул соединений в каждом процессе.
SP: Есть ли планы улучшить ООП? Пользователи чувствуют, что должно быть меньше накладных расходов в шаблонных классах, и обеспечение инкапсуляции такое, что они могли бы прятать некоторые переменные. Есть ли планы по этому эффекту?
RL: Да.
SP: Sybase и MS SQL Server предоставляют поддержку многим наборам результатов, возвращённых из хранимых процедур SQL. PHP не поддерживает этого! Когда пользователи смогут ожидать этого?
RL: Когда кто-нибудь предложит код, делающий это.
SP: Сейчас запросы к базам данных буферизуются в памяти перед тем, как они будут доступны клиенту. Могут ли PHP-программисты ждать, что это поведение изменится, чтобы запросы были доступны немедленно, как только сервер базы данных присылает их?
RL: Могут, когда разные интерфейсы управления (API) базы данных будут поддерживать это. Мы уже поддерживаем это с MySQL через вызов mysql_unbuffered query().
SP: Zend Engine 2 планирует некоторые захватывающие новые фичи, такие как обработка исключений и развитая поддержка ООП. Можете ли вы дать нам грубую оценку, когда пользователи смогут ждать релиза — хотя бы в месяцах или годах?
RL: Нет. Он будет выпущен, как только будет готов.
SP: Видите ли вы будущее в PHP-GTK, с популярными настольными программами, написанными на PHP?
RL: Думаю, PHP-GTK в основном используется в случаях, где вам нужно обеспечить и веб-интерфейс, и GUI (графический пользовательский интерфейс — прим. переводчика) в одной программе. Возможность иметь один и тот же конечный код и для того, и для другого — большой выигрыш.
SP: Разработка PHP и Apache сейчас идут параллельно? Вероятно ли, что два проекта каким-либо образом сольются в один в будущем?
RL: PHP и Apache всегда были тесно связаны, поскольку оба являются кусочками головоломки, решающей проблемы веба. Поэтому есть некоторые разработчики, которые работают над обоими проектами. Но проекты определённо не сольются. В этом нет особого смысла.
SP: Думаете ли вы, что крупные корпорации будут использовать PHP в своих внутренних средах вместо J2EE и .NET в будущем?
RL: Некоторые используют, поэтому "да".
Заключение
SP: Что бы вы сказали молодым разработчикам, собирающимся начать свои собственные проекты Open Source?
RL: Я не уверен, что это возможно в этом смысле. Это что-то вроде сидеть и смотреть на свой телефон, ожидая, пытаясь заставить его зазвонить. Он всегда звонит тогда, когда вы в дУше, либо в другое неподходящее время.
Я не думаю, что вы действительно сядете и решите начать проект open source. Это "движение" — немножко миф, который люди любят возвеличивать и приписывать ему все виды нереальных черт. Никто не присоединится к вашему проекту, если всё, что у вас есть — это классная идея. У всех есть классные идеи.
Люди соберутся вокруг ваших усилий, если вы построите что-то, что достаточно полезно, что они решат, что проще взять ваш код и расширить его немного, чтобы решить их задачи. Если ваш хлам "недопечённый", люди, скорее всего, отклонят то, что вы сделали, и просто решат проблемы сами или используя что-то другое.
Поэтому чтобы начать проект open source, в первую очередь предположите, что вы действуете самостоятельно и решаете какую-либо проблему, с которая доставала вас некоторое время. Это значит многие месяцы работы, чтобы получить что-то на самом деле работающее и решающее проблему. В этот момент вы можете думать, стоит ли прекращать контроль и позволять другим присоединиться к вашим усилиям.
Ключевая фраза — "отказаться от контроля". Начало проект open source не значит, что вдруг у вас появится штат программистов, которыми вы сможете командовать. На самом деле, чтобы поднять это от земли вам нужно будет быть очень восприимчивым к предложениям от первых последователей и делать всё возможное, чтобы сделать ваш инструмент более полезным для более широкой публики. И затем вы откажетесь от всего этого и позволите людям делать что угодно с вашим кодом. Тогда вы начнёте проект open source.
SP: Какие другие инициативы open source вы запланировали? Что бы вы хотели сделать, имея бесконечное время (и 100 лишних пар рук)?
RL: Ну, я не планировал PHP. Я думаю, с точки зрения решения проблем, не с точки зрения программных проектов. На самом деле, я ненавижу программировать, но я люблю решать проблемы.* Итак, какие же проблемы я бы хотел решить, если бы я имел много времени и ресурсов?
"I actually hate programming, but I love solving problems".
Став недавно отцом, я имел большие планы построить "умную" детскую кроватку. Видео в прямом эфире, аудио и разные другие гэджеты, которые бы наблюдались и контролировались удалённо, чтобы позволить далёким друзьям и семье взаимодействовать с ребёнком. Конечно, как только ребёнок на самом деле появился, найти достаточно времени, чтобы просто сесть и почитать книгу, почти невозможно, не говоря о создании "умной" кроватки.
Другой действительно классный проект — исходная система построения дистрибутивов. Такая, где я мог бы указать, что у меня устройство с 486-м процессором, некоторым типом сетевой карты, и какие-нибудь специфики железа вместе с типом медиа и оперативной памяти, и эта штука сделала бы маленький дистрибутив Линукса предназначенный именно для моего устройства.
Затем, чтобы расширить это, иметь возможность сказать, что я хочу, чтобы оно работало как файрволл, mp3-сервер, броузерная станция. По существу добраться до точки, когда можно взять любое устройство и прицепить на него Линукс, и оно было бы работоспособным. У меня много устройств дома, которые, я знаю, можно улучшить в использовании, поставив на них более мощное ПО. И я бы хотел найти способ делать это без необходимости тратить по 6 месяцев на каждое.
Сообщество SitePoint и я хотели бы поблагодарить Расмуса за его потраченное время и детальные ответы нашим пытливым умам. Он может не контролировать силы за PHP, но он определённо блистает как член команды, которая работает вместе во всём мире, чтобы перевести PHP на следующий уровень.