LINUX.ORG.RU
ФорумTalks

Интервью с создателем сетевого стека Linux

 


1

5

http://www.opennet.ru/opennews/art.shtml?num=38016

Некоторые кусочки текста особенно доставляют:

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

Не хватает центральных авторитарных органов, которые могли бы запрещать и отсекать отмершие технологии и разрешать новые

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

Смартфон - это уже фактически новый человеческий орган

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

Xen - мертворожденный проект. Про это знают все, включая его автора. Существуют еще какие-то люди, которые уже совершили ошибку и вложили что-то в Xеn и теперь пытаются это отбить. Могу только сказать - нельзя на это ловиться.

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

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



Последнее исправление: makyrros (всего исправлений: 3)

Ответ на: комментарий от tazhate

Почему? И что, на ваш взгляд, лучше?
Квм.

Как то скромно вы забыли о вопросе «почему?».

andreyu ★★★★★
()
Ответ на: комментарий от tazhate

dom0 в случае квм - это твое обычно ядро, в случае с esx - хостовая нода. domU - гость. В чем проблема-то? cli настолько же убогое, как и у квм, и на голову выше вмварных поделий.

leave ★★★★★
()

По тексту видно, что Линус совершенно прав.

quiet_readonly ★★★★
()
Ответ на: комментарий от true_admin

Пока из очевидных моментов это работа на плохих wifi-линках.

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

andrew667 ★★★★★
()
Ответ на: комментарий от tailgunner

Xen пускает софт прямо над гипервизором, который таки bare-metal. С очень маленьким оверхедом в комплекте с хорошей изоляцией.

У kvm виртуалки немногим отличаются от обычных процессов хост-системы.

Motif ★★
()
Ответ на: комментарий от Motif

Xen пускает софт прямо над гипервизором, который таки bare-metal.

Это прекрасно. Но вот то, на что я отвечал:

Motif> виртуалки только с целевым софтом, вообще без операционки или с минимумом обвязки

Ты хочешь сказать, что эта фраза значила _не_ «виртуалки, внутри которых только целевой софт»?

У kvm виртуалки немногим отличаются от обычных процессов хост-системы.

И это плохо... почему именно? И чем отличаются виртуалки KVM с проброшенными в них устройствами от виртуалок bare-metal Xen?

tailgunner ★★★★★
()
Ответ на: комментарий от andrew667

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

Я имел в виду при плохой связи и большом кол-ве клиентов у беспроводной точки доступа..

true_admin ★★★★★
()
Ответ на: комментарий от Motif

Xen пускает софт прямо над гипервизором, который таки bare-metal. С очень маленьким оверхедом

картинка по теме http://dtrace.org/blogs/brendan/files/2013/01/virtualization_xen_kvm-600.png

Только этот теоретический «маленький overhead» по железным ресурсам в реальной жизни часто оказывается никому не нужен. А нужнее всего простота поддержки, надежность и единообразное управление хостом, и возможность на хосте запускать ещё какие-нибудь «свои» сервисы — всё это как раз и дает kvm.

alpha ★★★★★
()
Ответ на: комментарий от tailgunner

Ты хочешь сказать, что эта фраза значила _не_ «виртуалки, внутри которых только целевой софт»?

Именно это она и значила. Кстати, да, затупил - пруф о поддержке подобного в kvm.

И чем отличаются виртуалки KVM с проброшенными в них устройствами от виртуалок bare-metal Xen?

Overhead. Иногда важно. Если виртуалок ОЧЕНЬ много или нужны ОЧЕНЬ низкие задержки.

Motif ★★
()
Ответ на: комментарий от alpha

А вот и анонимные теоретики подтянулись. Школу не проспи.

Motif ★★
()
Ответ на: комментарий от Motif

Ты хочешь сказать, что эта фраза значила _не_ «виртуалки, внутри которых только целевой софт»?

Именно это она и значила. Кстати, да, затупил - пруф о поддержке подобного в kvm.

Ты издеваешься? KVM запустит то, что ты ей подсунешь. Подсунешь ОС - запустит ОС, подсунешь «целевой софт» - запустит его, это суть виртуальной машины. Нужны примеры - недавно была новость про OSv.

И чем отличаются виртуалки KVM с проброшенными в них устройствами от виртуалок bare-metal Xen?

Overhead.

А если без умных слов? Накладных расходов на работу с проброшенными устройствами считай что и нет.

Если виртуалок ОЧЕНЬ много

Если виртуалок ОЧЕНЬ много (и таким образом проброс устройств невозможен), то в этом вашем bare metal гипервизоре всё равно необходимы драйверы устройств, виртуализирующие железо. Не вижу, как накладные расходы могут быть намного меньше, чем при использовании KVM с паравиртуальными драйверами.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)

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

anonymous_incognito ★★★★★
()

Во, +100500 как говорится

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

Золотые слова!

anonymous_incognito ★★★★★
()
Ответ на: комментарий от Motif

И где у kvm bare-metal и паравиртуализация? Так, еще один Virtualbox. Разве что освященный дланью RedHat.

Facepalm.

tazhate ★★★★★
()
Ответ на: комментарий от true_admin

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

andrew667 ★★★★★
()
Ответ на: комментарий от sin_a

думается мне, что и «инженерам от бога» тоже хочется успеха (публичного), признания (не только среди профи), женщин и прочего.

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

dk-
()
Ответ на: комментарий от stevejobs

что-то мне подсказывает, что этот чувак не то что не «всемирно известен», а вообще никак неизвестен, даже бывшим одноклассникам и коллегам по Параллельсу. Для интересу, напишу бывшему паралелльсовцу и спрошу, знает ли он какого-нибудь Алексея Кузнецова.

Алексей Кузнецов - это автор iproute2. Так что даже ты его знаешь.

ansky ★★★★★
()
Ответ на: комментарий от true_admin

Пока из очевидных моментов это работа на плохих wifi-линках.

На «плохих линках» у всех протоколов с гарантией доставки проблемы. По построению.

Ну и то что настройки tcp глобальны для всех соединений.

А это проблема реализации, а не протокола.

no-dashi ★★★★★
()
Ответ на: комментарий от tazhate

А можно подробнее?

Я вот тоже, когда интервью увидел, сразу же обратил внимание на этот комент и стало интересно. Просто сам его недавно воткнул и наоборот доволен.

Кстати, там проскочили вопросы про новые релизы openvz, но конкретного ответа не было. Кто-нибудь в курсе, есть продвижения на этом фронте?

shell-script ★★★★★
()
Ответ на: комментарий от shimon

Кто-нибудь, повесьте переводчика

где твой полный перевод?

Rastafarra ★★★★
()
Ответ на: комментарий от dk-

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

Хотя бывает и самооправдание, да.

sin_a ★★★★★
()
Ответ на: комментарий от true_admin

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

qulinxao ★★☆
()
Ответ на: комментарий от no-dashi

На «плохих линках» у всех протоколов с гарантией доставки проблемы.

Речь о том что можно сделать лучше чем то что есть сейчас.

это проблема реализации, а не протокола.

Протокол вообще ничего не умеет, протокол это формальное описание структуры пакетов и формальная диаграмма состояний. Главное в TCP алгоритмы контроля перегрузки и потери пакетов.

true_admin ★★★★★
()
Ответ на: комментарий от andrew667

В скоростных проводных каналах это уже не так ощутимо

Там, кстати, тоже могут быть свои проблемы. Посмотри tcp incast problem.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Главное в TCP алгоритмы контроля перегрузки и потери пакетов.

То, что эти параметры являются system-wide а не socket-wide, это как раз проблема реализации.

no-dashi ★★★★★
()
Ответ на: комментарий от ansky

iproute2 знаю, а Алексея Кузнецова - нет. Улавливаешь разницу? Того же Леннарта хотя бы на ЛОРе знают. В первую очередь самого Леннарта, и только потом уже его поделия, ага?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Не понимаю. Упоминания о Леннарте читал здесь, на ЛОРе, а что он сделал не знаю и юмора о нем не понимаю. Имя Алексея Кузнецова узнал еще 15 лет назад, ковыряясь в ядреных сорцах и читая «man ip».

ansky ★★★★★
()
Ответ на: комментарий от true_admin

Затраты на установление соединения (ACK, SYN,...).

andrew667 ★★★★★
()

Далее собственную libc в степени, достаточной для работы make, gcc, ld etc. пришлось НАПИСАТЬ самому

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

mio ★★
()
Ответ на: комментарий от mio

В очередной раз убеждаюсь

У меня были те же комплексы. А потом понял что нормальных прогеров единицы, а остальные пишут ещё хуже. Так что смелее в бой :).

true_admin ★★★★★
()
Ответ на: комментарий от ansky

Имя Алексея Кузнецова узнал еще 15 лет назад, ковыряясь в ядреных сорцах и читая «man ip».

ковыряясь в ядреных сорцах

понятно, широко известен среди 3,5 людей, которые ковыряются в ядерных сырцах. Боюсь, ненужный депутат Федоров, котоырй за жизнь не сделал и тысячной доли достижений Кузнецова, и то более популярен

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

stevejobs ★★★★☆
()
Ответ на: комментарий от true_admin

Там, кстати, тоже могут быть свои проблемы. Посмотри tcp incast problem.

Посмотрел. Пока сталкиваться с таким не приходилось, но думаю проблема преувеличена. Реально коммутаторы должны быть совсем отстойные. А вот на беспроводной сетке реально какой-нибудь хост таким образом и завалить. Провожу аналогию с dns amplification attack. Меня пару раз так реально достали.

andrew667 ★★★★★
()
Ответ на: комментарий от andrew667

Реально коммутаторы должны быть совсем отстойные.

Там проблема не в коммутаторах, а в том что несколько хостов одновременно начинают передачу данных. Коммутатор практически ничего сделать не может.

Правда, я обо всех этих проблемах знаю только от коллег, сам я не сетевик.

true_admin ★★★★★
()
Ответ на: комментарий от stevejobs

Каждому свое. Зачем навязывать понятия о счастье? Как минимум это не умно.

nihil ★★★★★
()
Ответ на: комментарий от true_admin

Там проблема не в коммутаторах, а в том что несколько хостов одновременно начинают передачу данных.

Я к тому, что для средненького коммутатора - это пустяки, а не нагрузка.

andrew667 ★★★★★
()

Для развлечения животной части человека у нас есть ipad, телевизор, kinect etc. Но слово «компьютер» - это слово для human sapience.

Эдик деанонимизировался.

cipher ★★★★★
()

Хорошее интервью, спасибо. Напомнило молодые годы.

Deleted
()

спасибо - интересное интервью

sambo ★★
()
Ответ на: комментарий от andrew667

для средненького коммутатора - это пустяки, а не нагрузка.

Дело не в нагрузке на коммутатор, а в перегруженности линков. Представь себе ситуацию когда у тебя в стойке 20 серверов с гигабитными каналами и 4ГБ аплинк свитча. Если все 20 серваков на полную катушку будут генерить трафик то они завалят 4ГБ линк.

Что произойдёт с tcp? Я не знаю, не проверял :). Но умные люди мне говорят что система может войти в резонанс: пакеты теряются, скорость падает, потом tcp снова резко разгоняется и опять всё по-новой. Решений несколько. Например, не слать одновременно кучу запросов на сервера в одной стойке. Или слать запросы с разным временем исполнения.

true_admin ★★★★★
()
Ответ на: комментарий от stevejobs

iproute2 знаю, а Алексея Кузнецова - нет. Улавливаешь разницу? Того же Леннарта хотя бы на ЛОРе знают. В первую очередь самого Леннарта, и только потом уже его поделия, ага?

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

На Опеннете интервью с тобой, конечно, не опубликуют, а вот в Толксах, пожалуй, обсудят.

aidan ★★★★
()
Ответ на: комментарий от tailgunner

Ты издеваешься? KVM запустит то, что ты ей подсунешь. Подсунешь ОС - запустит ОС, подсунешь «целевой софт» - запустит его, это суть виртуальной машины

kvm то запустит, но еще нужна система подготовки того, что будет запускаться.

https://github.com/GaloisInc/HaLVM

Вот что я имею ввиду. Есть также для OCaml и Erlang. Аналоги?

А если без умных слов? Накладных расходов на работу с проброшенными устройствами считай что и нет.

Легковесные VM могут запускаться динамически, ПОСЛЕ получения запроса клиента, и уничтожаться по его выполнению. Для систем с непредсказуемыми нагрузками.

о в этом вашем bare metal гипервизоре всё равно необходимы драйверы устройств, виртуализирующие железо

Полная паравиртуализация xen это совсем другое, чем паравиртуальные драйвера kvm. Модификация операционки для работы в паравиртуальном домене заключается в переносе из 0 кольца в 1 и обращении к API гипервизора вместо железа. Все драйвера РОДНЫЕ, никакое железо не виртуализуется. А легковесные домены вообще не содержат драйверов железа и работают только с API гипервизора, что и дает низкие накладные расходы.

Motif ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.