Алексей Кузнецов, внёсший огромный вклад в развитие ядра Linux, ответил на вопросы читателей opennet.ru.

Последние 10 лет Алексей отстранился от публичных дел, но в конце 90-х и начале 2000-х годов входил в категорию наиболее значительных разработчиков ядра Linux и занимал c 2000 по 2003 год пост мэйнтейнера сетевой подсистемы Linux. В частности, Алексей довёл до полноценного вида сетевой стек Linux, переработал его для использования на многоядерных системах, доработал поддержку IPv6 и обеспечил средства для управления трафиком. После переработки IP-стека Алексей принялся за переделку поддержки протокола TCP. Результатом стал новый TCP-стек, представленный в ядре Linux 2.2 и до сих пор используемый повсеместно. Из подготовленных Алексеем инструментов наиболее известны наборы утилит iputils (ping, tracepath, tftpd, rarpd) и утилиты управления трафиком iproute2 (ip, tc, ss). С 2003 года Алексей занимается развитием продуктов виртуализации компании Parallels.

Разработка ядра

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

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

Слышали слова: freebsd, netbsd. Про linux слышали только одно - это не работает. Не забывайте про историческое время - начало девяностых (молодежь про это уже ничего не знает), мы были беднее церковных крыс и благодарить судьбу можно было даже за то, что для посылки однострочного е-mail через модем - через uucp шлюз - через Курчатовский Институт не требовалось гербовой печати с подписью главного бухгалтера.

Был отправлен человек с ящиком дискет в CERN: вези все программы и OS, что найдешь, потом разберемся. Человек был физик с очень небольшим вычислительным уклоном и привез он такую гору мусора, что я в ней месяц разбирался. Так вот - исторический момент - freebsd был привезен полностью на огромном количестве дискет, но без сорсов. И не взлетел. Ну вот совсем никак. А вот linuх был всего на двух дискетах – boot & root. И почти взлетел!

Я увидел надпись Login: и даже успел сказать ему root и увидеть #. А вот дальше на все был один ответ: Segmentation Violation и что-то про uselib. Но мы не привыкли отступать. Здесь случился акт божественного провидения: undelete на одной из пустых дискет (парень почистил часть особо бесполезных дискет с тем, чтобы туда записать какие-то мануалы, но не успел) обнаружился файл "?inux.tgz".

Распаковка показала, что это похоже на сорс ядра linux. Методом пристального взгляда проблема была вычислена: boot оказался немножко новее root, и функция uselib работала не совсем так, как этого ожидал root. Далее я взял лопату и стал рыть от забора и до успеха. Помню смутно: пришлось отыскать клон gcc для msdos (DJGPP), подправить кернел и ухитриться скомпилировать его под msdos. Получить работающий linux. Но без библиотек и возможности что-либо скомпилировать кроме кернела.

Далее собственную libc в степени, достаточной для работы make, gcc, ld etc. пришлось НАПИСАТЬ самому. А все остальное: gcc, as, ld - используя DJGPP и его сорс. Нетрудно понять, что после всего этого я из физика-теоретика превратился в linux-хакера. И назад в науку дорогу уже не нашел.

Как получилось, что вы стали мэйнтейнером? Какой путь пришлось для этого пройти?

В то время я был просто очарован Интернетом: возможности протокола, открывающиеся перспективы просто сносили крышу. Будучи человеком увлекающимся, я практически забросил свою основную область деятельности (теоретическая физика) и полностью переключился на изучение того, что было к тому времени сделано и изобретено, на размышления, что и как это нужно сделать. Где-то к 1996 у меня был the grand plan. И linux дал возможность для воплощения этого плана.

Во-первых, но не это самое важное, поддержка сети в linux была практически в состоянии tabula rasa. А главное - люди, которые каким-то чудом собрались вокруг проекта. Открытые для инноваций, гибкие, талантливые - Алан Кокс, затем Педро Маркес, Дэвид Миллер. До 1996 года (Linux 2.0) я просто работал. Чинил баги, делал какие-то нужные и не очень вещи. Заработал какой-то авторитет.

Где-то к 1996 году стало ясно, что сеть находится в тупиковом состоянии. Алан Кокс, бывший в то время майнтейнером сетевой части linux, сделал гениальный ход: он устранился и дал дорогу молодым: Педро Маркесу, который сделал к тому времени начальную поддержку IPv6 и начал переписывать TCP. А я (будучи "молодым" не по возрасту, а по духу :-)) взял на себя более низкоуровневую часть. К несчастью, Педро проработал недолго - закончил университет и пропал где-то в катакомбах Cisco, но начало новой эпохи положил именно он. Вот с тех пор я и стал отвечать за всю низкоуровневую часть сетевого кода: с одной стороны границы было TCP, c другой - внутренности сетевых драйверов. До 1999 года TCP я глубоко не занимался.

Как происходило взаимодействие с другими разработчиками ядра?

Через обмен e-mail. Патч публиковался в linux-kernel (затем - netdev). Если он не вызывал возражений, maintainer его прикладывал к своему дереву, затем пересылал Торвальдсу. Если были возражения - патч переделывался. А бывало и так, что патч отвергался целиком и кто-то совершенно другой делал то же самое совершенно по-другому.

Затем Дэвид Миллер организовал CVS для сетевой части и для своего собственного проекта (ultrasparc port). После этого взаимодействие стало более цивилизованным, но суть поменялась незначительно.

Чем было вызвано решение сменить область деятельности и покинуть арену разработки ядра?

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

Чем вы занимаетесь сейчас?

После TCP-стека я охладел и увлекся новым проектом в недрах Parallels. Я переделывал миграцию контейнеров Parallels Virtuozzo Containers. Занимался портированием контейнеров на Itanium. Это был изначально мертвый (малый интерес рынка), но технически невероятно интересный для меня проект. Потом был перенос контейнеров в линейный формат, совместимый с виртуальными машинами Parallels Server. Это трудно описать, просто потому что замысел и состоял в том, что никакого внешнего эффекта быть не должно, только контейнеры должны работать лучше. Некоторое время даже занимался Parallels Desktop для Mac, отдыхал от Linux.

Сейчас я занимаюсь Parallels Cloud Server, если точнее, то входящим в его состав Parallels Cloud Storage. Parallels Cloud Server представляет собой гибрид платформы для виртуализации (гипервизоры + контейнеры) с распределенным облачным хранилищем (именно Storage вызывает особый интерес у рынка) . «Гибридизация» снижает время простоя из-за отказов оборудования, упрощает поддержку и администрирование серверов, а также позволяет создавать эффективные и высокодоступные виртуальные серверы с очень хорошими показателями аптайма.

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

Лично я с ним никогда не встречался. Более того, избегал прямого общения с ним даже по е-mail. Я всегда имел промежуточное звено: сначала Алан Кокс, затем Дэвид Миллер. Линус считал меня "arrogant" (по словарю: заносчивый, высокомерный, надменный, самонадеянный, преувеличивающий свои возможности). Возможно, он употреблял в отношении меня и более крепкие эпитеты, но те, кто мне это передавал, могли просто щадить мое самолюбие. И он был прав: я считал и считаю его самовлюбленным малообразованным пингвином. И с большой склонностью к халтурным решениям, уж извините. Посмотрите на страшные куски кода, логика которых дожила до настоящего времени (inode.c, buffer.c), уродливый неработающий scheduler, который прожил десять лет.

Но не поймите меня неправильно. Я уважаю Линуса безмерно: во-первых, это харизматичный лидер, который умеет делать невозможное - управлять толпой анархистов самого разного интеллектуального уровня, многие из которых считают его идиотом; и не превратиться при этом в африканского царька. А главное, это человек, который видит на годы вперед. И это было ясно уже к 2000му году, когда linux, несмотря на все сделанные глупости, отвратительную архитектуру и ужасное качество кода, стал уверенно обходить и freebsd, и коммерческие unixы. Поэтому я всегда внимательно его слушал, а глупости, которые он говорил, особенно внимательно. Такой вот парадокс.

Возьмите классическую управленческую проблему. Когда назрела необходимость переключиться на какую-то VCS, Линус отверг CVS по понятным причинам, а svn, mercurial etc. - под совершенно надуманными предлогами. Вместо этого был взят bitkeeper, система с уродливейшей архитектурой, да еще и закрытой. И не бесплатной! Да еще и невероятно неэффективной. Кстати, это была еще одна из причин моего ухода: на компьютерах, которые были мне доступны, один однострочный коммит занимал почти час, а многие операции были вообще невозможно выполнить за конечное время. К тому же на гигабайт памяти у меня и денег просто не было.

Глупость? Непотизм? Не знаю. Но посмотрите на конечный результат: все уже и забыли про этот злосчастный bitkeeper, а есть git, который, безусловно, является лучшей распределенной VCS всех времен и народов. Вот это и называется гениальностью. Человек увидел бриллиант в куче навоза. Навоз со временем рассосался - бриллиант остался. А я бриллианта там не видел, вот так.

Насколько активное участие в разработке СПО помогло в завоевании жизненной позиции (опыт, связи, известность)?

Опыт. Опыт и еще раз опыт. Я могу и не боюсь менять архитектуру. Я не боюсь выбрасывать старый работающий код. Связи и известность я давно потерял.

Ядро

В документации к ядру Linux с иронией отмечается неуместный выбор названия "tasklet" (The name 'tasklet' is misleading: they have nothing to do with 'tasks', and probably more to do with some bad vodka Alexey Kuznetsov had at the time.). Это вы придумали тасклеты? Если так, то для решения какой задачи они были созданы и каков был мотив выбора названия? И кто блеснул остроумием в документации про тасклеты?

Да, я. Надо знать ситуацию. К тому времени ядро поддерживало SMP только на уровне IRQ. И мы не имели внутриядерных threadов. Медленная часть работы, которую нельзя было выполнить с заблокированными IRQ, выполнялась в глобально сериализованном контексте - bottom-half (ВH). Сначала было разрешено параллельное выполнение BH на разных процессорах, назвал я это softirq. Но стало ясно, что для выполнения какой-то определенной задачи необходимо создать объект, работающий в одном потоке (подобно linux task), но в контексте softirq. Отсюда и название - "маленькая задачка". Кто блеснул остроумием, я уже не помню. Заметьте, что коммент сделан одним из друзей, он не обиден. Я имел славу изобретателя стойких афоризмов и выживающих десятки лет "плохих" названий. Возможно, благодаря весьма несовершенному английскому мне удавалось рождать какие-то особо сочные конструкции.

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

Энтузиаст не может написать правильное руководство. Точка. Руководство всегда пишет автор соответствующей компоненты. Более того, это итеративный процесс. Например, когда я писал руководство к iproute2, мне пришлось переписать значительную часть iproute2 и даже ядра. Просто потому, что идея, которая казалась замечательной, когда существовала только в виде кода, не переносилась на бумагу. tc-cref планировалось. Но я настолько был напуган усилиями, затраченными на ip-cref, что просто не смог начать эту работу. А затем началась работа над SMP, оптимизация (по сути - переписывание TCP) и это вообще растворилось в прошлом. Я думаю, ребята, работавшие над HTB и более поздними алгоритмами должны быть честнее, чем я, и все-таки оставить что-то разумное, записанное на бумаге.

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

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

Это был мой план. План Педро Маркеса, план Дэвида Миллера. И теоретические знания, полученные из статей и писем отцов-основателей. Я, например, очень любил размышлять над письмами Van Jacobson'а; все частности - бред, все рекомендации неправильны даже арифметически. Implementation в BSD - не просто халтурна, это бы полбеды, но она просто окончательно хоронит изначальную идею. Но идеи - великая ценность.

Если бы вы сейчас стали разрабатывать сетевой стек, сильно бы он отличался от того что вы сделали в прошлом, иными словами, считаете ли вы архитектуру сетевого стека Linux, достаточно продуманной для дальнейшего развития?

Сложный вопрос. Эта архитектура прожила 10-15 лет практически без изменений, так что она была совсем неплоха. C другой стороны, все было бы по тому же grande plan, но технически и логически по-другому. Не было бы destination cache. Была бы лучшая интеграция с netfilter. Мой grande plan в основных чертах совпадал с тем, что сейчас называется SDN. Делайте выводы.

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

Начать c написания драйвера, использующего хорошо разработанную подсистему, например, usb, сетевой драйвер, блочный или scsi драйвер. Файловая система - это уже сложнее. Главное - стремиться к совершенству. Если Вы видите, что другие уровни не дают Вам что-то сделать максимально эффективным или простым способом, думайте, как можно поменять не только Ваш код, но и другие уровни. Наверняка другие драйвера имеют подобные проблемы, и Вам удастся убедить людей что-то там поменять. Через некоторое время Вы поймете, что Вы понимаете, как работает SCSI, VFS или другая подсистема. И далее вперед!

Разное

Какие недостатки в Linux вы сейчас видите, что по вашему недостает современному Linux, чтобы набрать популярность?

Насчет популярности я не могу ничего сказать. Вы вспомните первые упоминания про iPad. Это казалось просто смехотворным. А изменило мир. Linux растет как верблюжья колючка, а тоже не бедствует и меняет мир по-своему.

Технически: подсистема виртуальной памяти всегда была и осталась большой кучей мусора. Старые ковбои стреляли отлично (Rick Van Riel, Andrea Arcangeli) и сделали ее работающей, но, похоже, он опять распадается. Нужен новый мозг. buffer.c, inode.c - просто гиря на ногах, оставшаяся с первых дней linux. Современные ребята знают, как ее сбросить, но что-то уже лет пять тормозят.

Обращались ли к вам с просьбами вставить бекдор в разрабатываемые вами продукты?

Никогда.

Есть ли то, что по вашим наблюдениям не хватает в развитии технологий? Вы бы что-то поменяли?

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

Вы будете смеяться, но у меня есть какие-то смутные надежды на Китай. И даже на Россию, чем черт не шутит.

Нужна ли России национальная ОС?

Нет.

Предпочтения

Каким ПО для разработки вы пользовались раньше и пользуетесь сейчас? Что использовали для отладки и профилирования?

Всегда gcc. oprofile для профилирования (perf не получается, то ли я кривой, то ли он). Для отладки - ничего. Как-то так получается, что я всегда пишу такой код, который или сразу работает или очевидно, почему не работает, и отладка никогда не требуется. Последнее время использовал systemtap. Поражен мощью подхода и невероятной сказочной кривизной имплементации.

Какими дистрибутивами Linux и операционными системами пользовались в своей работе? Как часто меняли дистрибутивы?

Fedorа (redhat, пока ее не было). Меняю очень редко. Принцип такой - выходит RHEL5 - я ставлю Fedora 13, RHEL6 - Fedora 16. Вот, услышал, что RHEL7 отпочковался от Fedora 18 (a заодно и диск на ноутбуке сдох), и поставил Fedora 19. Теперь беру таймаут до RHEL8.

Вы до сих пор используете консольный почтовый клиент. Чем объясняется непринятие новых веяний? Часто ли вы решаетесь перейти на что-то принципиально новое, оставив в прошлом старое и привычное?

Привычка. А главное - отсутствие необходимости.

Скажите, пожалуйста, Вы получаете текстовые письма, даже без attachments, которые прямо запрещены в netdev. Где так же запрещена порча писем убиранием и добавлением дополнительных пробелов и табуляторов. Зачем Вам может понадобиться что-то кроме mutt?

В последнее время я часто пользуюсь gmail. И уже успел сточить зубы от ненависти - несколько раз поменять интерфейс за такое короткое время. Зачем?

У человека выделяют первую и вторую сигнальные системы, "образную" и "вербальную". Некоторые апологеты unix-way утверждают, что именно консоль, требующая развитой второй сигнальной системы как способности сформулировать задачу в виде последовательности команд ведущих к результату, и является причиной успеха ОС Unix (в определенной среде); а нынешняя "борьба графических десктопов" - это игра на чужом поле по чужим правилам за чуждые умы. Как Вы считаете, стоит ли Linux бороться за умы людей, привыкших использовать первую сигнальную систему при работе с компьютерами и подстраиваться под них? Стоит ли программистам проходить через "console-only" этап?

Программисты и любые школьники должны проходить через "console-only" этап. "Первая сигнальная система" - это политкорректный эвфемизм. Это откуда-то из области борьбы за права животных. Для развлечения животной части человека у нас есть ipad, телевизор, kinect etc. Но слово "компьютер" - это слово для human sapience.

Вы владеете 10 пальцевым вводом? Вы пользуетесь стандартной раскладкой qwerty или что то вроде dvorak для программистов? Какую клавиатуру вы предпочитаете?

К своему стыду - нет. Более того, я даже не могу работать в темноте, нужно постоянно синхронизировать положение пальцев визуально. Использую только thinkpad c верхним thinklight. На вопрос про клавиатуру ответ уже не требуется.

Какое десктоп-окружение предпочитайте? Что вы думаете о большинстве современных десктоп-окружений?

Не люблю и не понимаю. Моя система - это fwvm с 7 десктопами, где на 7м десктопе - обычная простая мультиоконная система, где все запускается из терминалов. Пара кнопок есть: для сhrome и для нового терминала. А на всех остальных десктопах full-screen rxvt c огромными шрифтами и раскладкой клавиатуры, совпадающей с linux-консолью. Так что, по сути, это текстовые консоли 119х33.

Как вы относитесь к планшетам и новым гаджетам? Какими электронными устройствами вы пользуетесь?

Смартфон, планшет, электронная книга, ноутбук. Все вышеперечисленное - гениальные изобретения уровня телевидения, радио или личного автомобиля. На ноутбуке я работаю, на iPad c retina я читаю книги. Смартфон - это уже фактически новый человеческий орган. Честно говоря, еще год назад у меня не было смартфона, и я говорил: "по телефону я разговариваю". Теперь я знаю, как я был неправ: gps, камера, сканер, Интернет практически везде, etс. - это другое качество жизни.

Насколько перспективными вы считаете такие разработки как очки google glass и устройства, вживленные в организм, такие как deus ex? Каким вы видите будущее?

Google glass опробую при первой возможности. Про deus ex слышу впервые, но уверен, что подобные устройства имеют грандиозные перспективы при условии, что будет доказана их безопасность с медицинской точки зрения и не возникнет массовой фобии.

Используете ли вы облачные сервисы и web-службы или предпочитайте классические локальные приложения?

Dropbox, Evernote, Roboform. Gmail. Использую только те, что имеют встроенный или предоставляют возможность локального backupа. Держу у себя локальную копию Gmail. И всем советую. Независимо от того, насколько солидна контора - она может закрыться в любой момент без предупреждения. Если у Amazon будут проблемы, клиенты узнают про это последними.

Как вы отдыхаете? Кино, книги, сериалы, бар-кафе, туризм, природа? Какая обстановка на ваш взгляд помогает комфортно программировать?

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

Вы пользуетесь чем то вроде GTD или системами планирования времени, такими как Pomodoro? Как удавалось работать за десятерых и поддерживать сверхвысокий темп разработки, вызывающий удивление у других разработчиков ядра Linux? Работали по 16 часов в день или умели грамотно отсеивать мелочи, на которые не стоит тратить времени?

Просто работал 24/7. Надо понимать, что в то время какой-то другой части жизни у меня не было. Во-первых, есть заблуждение про 16 часов. 8 - это не про сон случайно? Тогда неверно. Я спал 12-14 часов в сутки, а остальное время наводил порядок в том, что уже родилось. Все архитектурные решения формируются в подсознании именно во время сна. В какой-то момент вы просто понимаете, что теперь вы знаете, что и как нужно делать. Тогда вы садитесь и записываете это. Это не совет. Я же не профессиональный программист. Если решение не созреет - я ничего не сделаю. Просто не смогу. Профессионал себе этого позволить не может.

Технические вопросы

Как вы думаете - не пора ли пересмотреть архитектуру ядра и переходить от монолита в сторону микроядра?

Нет. Я просто не понимаю, что такое microkernel. И уверен, что никто не понимает, иначе бы это кто-то сделал. А до сих пор процесс был только обратный: f.e. ядро macos - это mach+freebsd c варварски выломанным microkernel.

Почему в Linux нет поддержки MPLS? Очень, очень хотелось бы получить из коробки полноценный маршрутизатор с MPLS, VRF-ами, MPBGP.

Честно, не знаю. При мне были только слова. А почему до сих пор ничего толкового не родилось - не знаю. Просто не было человека. В linux Вы же не можете никому ничего приказать.

Какие из направлений, в которых сейчас развивается виртуализация, вам кажутся наиболее перспективными и почему?

Вопрос не понял. Имеется в виду containers vs. virtual machines? Или Xen vs. kvm? Или kvm vs. psbm?

Xen - мертворожденный проект. Про это знают все, включая его автора. Существуют еще какие-то люди, которые уже совершили ошибку и вложили что-то в Xеn и теперь пытаются это отбить. Могу только сказать - нельзя на это ловиться. Если нужен именно такой тип виртуализации, смотрите в сторону ESX. Скупой заплатит дважды. Parallels Cloud Server и KVM. Parallels пока просто лучше. KVM - лучше архитектурно и, скорее всего, их ядра в конце концов сойдутся. Но я уверен, что PCS навсегда останется лучше RehHatных решений. Containers vs. virtual machines... просто не имеет смысла сравнивать. Это разные и по смыслу, и назначению подходы. Будут жить оба.

На каком ядре будет ближайшее OpenVZ-ядро? Будет ли поддержка и сборка пакетов для других дистрибутивов, например Ubuntu 14.04 LTS?

Это вопросы скорее к Киру Колышкину ([email protected] или [email protected] ). Я не в курсе.

Как много осталось наработок в ядре компании Parallels, которые комьюнити пока отказывается принимать? Когда можно ждать полную интеграцию OpenVZ-ядер в апстрим?

Про "отказ принимать". Нет, такого никогда не было. Программисты, которые работают над Parallels Containers/OpenVZ ядрами, они же - одни из главных разработчиков апстрим. Есть разница – нам нужно сделать вещь к следующему релизу. Точка. Тушкой, чучелом: но мы ее сделаем: архитектурно криво, cо стальными швеллерами в тех местах несущих стен, где и дыр-то быть не должно. Все это будет работать и простоит сто лет. Но не может же автор этого кошмара заслать это в mainstream. Он же сам это и обязан будет забраковать. Точно такая же ситуация, например, в Redhat.

Главная вещь, оставшаяся в VZ оut of mainstream, - миграция. При этом миграция в Parallels Containers намного мощнее миграции в OpenVZ. Делал ее я, под заказ, очень быстро. Работает уже 10 лет и даже насморка не было. Никакой речи о приеме в mainstream здесь просто нет. Есть новый проект CRIU. Пока он сырой, но ясно, что рано или поздно он спустится с горы и все сделает как надо.

Не чувствуете ли вы растущую сложность в сетевой подсистеме? Каковы дальнейшие, по вашему мнению, пути развития сетевой подсистемы Linux? Почему, на ваш взгляд, удобная система etcnet не нашла своего применения за пределами дистрибутива AltLinux?

Я так понимаю, Вы имеете в виду user space часть. Про etcnеt я ничего не знаю.

В старые добрые времена у меня даже /etc/sysconfig/network-scripts вызывала какие-то неприятные движения в желудке. NetworkManager - зло. Это то самое чистое зло, то самое, про которое нам батюшки в храмах упоминают, предварительно перекрестившись (или не упоминают, я не знаю, я атеист). Если мы его не запинаем, настанет день, когда бороться будет поздно. hal запинали? Вот и NetworkManagerу туда же дорога.

Многие, использующие Linux в роли маршрутизаторов, критикуют его за отсутствие реализации CARP на уровне ядра, аналогичной FreeBSD, OpenBSD. Что можете сказать по этому поводу?

Надо сделать. Честно говоря, я не знаю, что там сделано в FreeBSD, OpenBSD. Не очень понятно, чем UCARP так плох. Еще раз, деталей я не знаю, но выглядит это по меньшей мере подозрительно. Всякая система, которая разрешает одновременное использование одного адреса на нескольких хостах, требует очень тщательной проработки. До сих пор ничего кроме халтурных решений класса "для сельской местности сойдет" я не видел.

Почему развитие сетевой подсистемы ядра Linux остановилось? С начала двухтысячных ничего нового, в документации и примерах tc описывается поведение серверов и скорости десятимегабитных сетей Неужели всё уже сделано и не хочется что то переделать, улучшить? Чего с вашей точки зрения не хватает в сетевой подсистеме сейчас?

А почему последний коммит от меня был в 2003 году или где-то так? Да. Именно так, все сделано.

Я хочу надеяться, что 10-15 лет назад был заложен такой потенциал, который позволил прокатиться по инерции до нынешних времен. Когда это кончится? Я вижу два облака на горизонте - скорости > 10Gbit, которые опять опасно приблизились к производительности памяти и SDN.

Будет ли продолжено развитие iproute2? В данный момент ощущение, что оно уже долгие годы заброшено и не развивается вовсе.

Оно развивается синхронно с кернелом. Новые опции появляются в кернеле, появляются и в ip.

Будет ли когда-либо в продуктах Parallels (например, в Parallels Cloud Server хороший шейпер? Почему не принимается набор патчей для OpenVZ с реализацией учета трафика и шейпер? Или придется на tc городить огород в стиле этого :)

Опять не ко мне вопрос. Спросите Кира Колышкина. Например, я со времени своего появления в Parallels молил о переключении на HTB. А несколько месяцев назад узнал - СBQ и ныне там. Был зол.

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

Что вы думаете об интерфейсе сетевого стека plan9 (и о plan9, вообще)? Почему не появилось желание сделать что-нибудь подобное в linux? Не считаете ли вы, что для увеличения производительности и упрощения кода в ядре лучше было бы вынести по-максимуму сетевую подсистему из ядра в пространство пользователя, как это сделано в plan9?

Нет, не считаю. Это такой же миф, как microkernel, exokernel etc. Хотя с plan9 я знаком слабо. Скорее, я рассуждаю об exokernelах и предложениях типа netchannel.

Почему в Linux нельзя узнать, сколько можно записать в буфер сокета?

Да, есть такая проблема. В свое время я на нее убил немало времени, но так и не решил.

Даже более простая проблема не решена. Есть такая опция SO_SNDLOWAT. Но не в Linux. Если SO_SNDLOWAT=1000, то посылка <=1000 байт либо не должна блокироваться, либо должен вернуться EAGAIN. Сходство видите? Это как если бы мы спросили размер буфера и нам ответили 1000.

Проблема в том, что архитектура linux использует пресегментированные очереди. Это означает, что при определенных параметрах запись 1000 байт может потребовать аллокации огромного количества памяти. Например, IPsec можно в теории сконфигурировать так, что он будет выедать один байт, забивать его случайными числами до 256, затем еще добавлять хидеры, alignment, struct sk_buff опять же. Так и то 4 мегабайт можно дорастить.

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

Почему нет kqueue? (epoll не даёт почти никакой информации о событии). Не хватает чтобы сразу прилетал размер полученных данных/размер данных которые можно записать, еоф, код ошибки для данного дескриптора+операции, чтобы можно было получать сразу и udata (размерности size_t) и дескриптор fd на котором случился эвент, не хватает возможности вливания сразу массива за один вызов.

Вот уж о чем не задумывался, о том не задумывался. Насчет размера получаемых данных - явная недоработка. Остальное - просто не понимаю - epoll массив событий с fd и возвращает. И даже EOF там есть (POLLRDHUP). Или Вы имеете в виду, чтоб в каждом был (fd, size) для последующего гипотетического recvfmmsg()? Да, интересно. Но должен сказать, для BSD, где kqueue и придумана, это выглядит как явный overdesign.

Появится ли в Linux что-то похожее на Netgraph из FreeBSD?

Так вроде он есть. Хватит автору характера пропихнуть это в mainstream - будет у всех.

Как вы оцениваете перспективы таких вещей как netmap(freebsd) и intel dpdk? Стоит ли интегрировать их в ядро, или же развивать PACKET_MMAP? Хотелось бы также узнать ваше мнение по поводу проекта nftables.

Стоит. PACKET_MMAP - был просто мой эксперимент. Он оказался удивительно эффективен, но у меня не было цели сделать _продукт_. Мне нужно было доказать, что можно делать что-то полезное без трюков с page tables. Я, честно говоря, был удивлен, что последующие проекты, наследующие ту же самую логику, не получили разумного продолжения.

Была такая вещь еще - PF_RING, тоже засохла. nftable был флагманский проект и активно поддерживался одним их maintainerов ядра: Патриком Макхарди. Затем он либо потерял интерес, либо время. Но nftables еще развивается, по крайней мере, поддерживается и синхронизируется с mainstream, так что шансы есть.

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

Не знаю. Сама идея мне по душе. Но реализация через netfilter не вызывает никакого энтузиазма. Я бы попробовал решать ее по-другому, например, в духе, light net namespace.

Почему в ядре linux нет netflow? Сторонний модуль для ядра требует определенных версий, патчей и добавляет проблем со сборкой; реализация в userspace не дает желаемую производительность.

Ответ один: нет человека.

Не пора ли оставить TCP только для "длинных" дистанций, а внутри датацентров перейти на "плоский" InfiniBand?

Подобные предложения я слышу периодически даже от очень квалифицированных людей. Давайте сначала посмотрим с другой стороны: Вы знаете, например, что для длинных дистанций TCP не годится категорически, и как раз там его лучше бы на что-то заменить. Есть, например, TIXEL. Есть и другие решения.

А на коротких дистанциях в сетях без потерь у TCP просто нет ни конкурентов, ни особенных проблем. С удешевлением 10Gbit ethernet появится дорогой 100Gbit. И так далее.