LINUX.ORG.RU

Интервью с Con Kolivas


1

0

Анестезиолог Con Kolivas, который также известен как создатель Rotating Staircase Deadline Scheduler (RSDL), заявил что уходит. Что он больше не будет присылать патчи к ядру linux.

И так же заявил, что Linux не займет место на десктопах, и что Microsoft уничтожила инновации для PC. Ну и постарался объяснить почему.

>>> Интервью



Проверено: Shaman007 ()

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

> Винда стартует секунд за 20 на компе, который в два раза хуже моего, а у меня грузится gentoo около минуты.

а ты убери в boot.ini ключик /fastboot и увидешь сколько винда грузится реально, т.к. сейчас винда продолжает грузиться еще 2-3 минуты после появления рабочего стола

ЗЫ у меня из-за этого в w2k был глюк с usb-клавиатурой -- после появления окна для логина я вынужден был ждать пару минут пока загрузятся дрова для usb т.к. не мог ввести пароль.

ЗЗЫ сейчас проблема решена -- на машине нет винды :D

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

> многочисленные тесты мускула на линакс

ошибку уже нашли, и она была не в ядре, а в libc

а вообще у меня заметны тормоза в линуксе только в 1 случае -- когда копирую фильмы на флешку, причем это продолжается уже довольно давно -- еще где-то с 2.6.10

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

>вот как раз эти тесты - не доказательство. видите ли, mysql далеко не единственная СУБД, и далеко не всем он нужен.

не совсем так. в мускуле нет ничего необычного - того, что небыло бы присуще любому многопоточному приложению активно использующее I/O и все подсистемы VM. мускул - это как раз очень показательно. даже если бы это был например какой нибудь Informix со своим планировщиком потоков и I/O, с locked shared memory сегментами и raw I/O chunck (tablespace)-ами, это все равно было бы показательно, хотя и не в такой степени.

aydef
()
Ответ на: комментарий от vadiml

>ошибку уже нашли, и она была не в ядре, а в libc.

не совсем так. это была не совсем ошибка и не только в libc. ( в ядро была добавлена новая фича, а во free из glibc добавлен ее вызов - штука по смыслу аналогичная MADV_DONTNEED в madvise )

однако даже с патченным ядром и glibc в тестах Джефа линакс проигрывает фряхе. Сейчас с этим разбирается Nick Piggin. К сожалению он один. Похоже мало кого это интересует кроме него и может еще Рика (судя по обсуждению в рассылке )

aydef
()
Ответ на: комментарий от wieker

> а посмотреть исходники из своего дистрибутива слабо?

Именно это я и сделал, и хочу, чтобы сделал ты, чтобы ткнуть тебя в ответ на твой собственный вопрос, почему не включают патчи -ck.

> у меня Debian > неслабо пропатчен и отличается от ванилы.

Ты от ответа-то не уходи. Что там за патчи? Ответ на этот вопрос даст ответ на твой изначальный вопрос.

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

>True. Вон, тот же Ingo уже года три поддерживает свою ветку -rt. И execshield. И не гундит, что это в mainstream не входит. На самом деле всё очень хорошо получилось. Я просек фишку Линуса. Дело в том, что Коливас несколько... нестабилен на психику. И это была, на мой взгляд, такая микро-проверка. Кон её провалил, и при первом же несогласии Линуса с его мнением, Кон просто взял, и свалил из проекта. Нужны ли такие мейнтейнеры в ядре linux, да ещё отвечающие за планировщик? Однозначно - нет. Ушел, и поделом!

- Избавься от него, - говорит мне Тайлер. - Слишком молод. Я спрашиваю Тайлера, сколько это лет - слишком молод? - Не имеет значения, - отвечает Тайлер. - Если кандидат молод, мы говорим ему, что он слишком молод. Если он толстый, мы говорим ему, что он слишком толст. Если стар - что слишком стар. Если тощий - слишком тощ. Если белый - слишком бел. Если черный - слишком черен. Именно так проверяли кандидатов в буддийских монастырях на протяжении квадриллионов и биллионов лет, объясняет Тайлер. Кандидата посылают прочь, но если решимость его настолько сильна, что он прождет у дверей без еды под открытым небом три дня, тогда и только тогда он может войти и приступить к тренировке. (с) Бойцовский клуб

iKlim
()

Да, я тоже считаю, что он тупо не выдержал. Это амбиции. Держал бы свою ветку и не парился, а там смотришь, если бы всё было реально клёво, то и в основное ядро бы включили со временем.... А то - такие разглагольствования начал...В общем не выдержал он OpenSouce developement rules и не смог смириться:-)))

dx
()

Забавные посетители на ЛОРе: сами ни строчки кода не написали, многие ядра 2.4 в глаза не видели, а хаять все горазды.

Между тем, в 2.4 без патчей Кона слушать музыку или смотреть видео и при этом просто компилировать с -j2 и что-то куда-то копировать просто невозможно - сплошные лаги и выпадения кадров.

Увы, ядро 2.4 почти умерло, но исправленные патчи Кона ещё можно скачать здесь:

http://www.plumlocosoft.com/kernel/

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

написали, не бойся, а без патчей данного товарища прекрасно все работало - около 2-х лет сидел под 2.4.2х ничего подобного не замечал - может просто надо все делать вовремя, а не убивать жесткий диск столь жестоким образом?

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

Если гонять в 2.4 по одной задаче, то, да, всё отлично работает.

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

Угу все прекрасно работало, мышиный курсор дергался при дисковых операциях, при той же компиляции.

the_moon
()
Ответ на: комментарий от dmesg

>Очень даже понятно. Они боятся ровно того же, чего боится Линус. Что Коливас в один прекрасный момент, когда ему что-то не понравится, кинет их всех разом. Как он сделал это сейчас со своими пользователями ветки -ck

Смешно. А они сами безрукие, что ли? Он ведь в основном их код правит.

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

>А Кон до сих пор вольный сеятель.

Врач.

А Алан Кокс - биолог.

Только первому нравится больше работать по своей оригинальной специальности, а второму - по освоенной.

jackill ★★★★★
()

А что войдет?

Vista? Виндузятники плюются!

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

>были у меня ХТ, 486, PI - ничего шустрого в них никогда не замечал :) первое чуство комфорта почуствовал на AMD Duron 1100 + Debian Woody + KDE 2

Первое чувство комфорта я почувствовал на P-100 16Mb.

А уж когда селерон трехсотый купил и до пятисот догнал (333->515) на 32-х метрах, да еще туда риву воткнул, вот это была адская машина, рвущая все живое и мертвое.

А сейчас AMD 64 3200+, гиг памяти. Радости особой - разве что от игр, в которые я, опять же, не играю.

А, флеш перестал тормозить, если несколько окон открыть (тоже бесполезно, ибо поставил 64-битный линукс и флеш для меня закончился).

Разницы между версиями для 64 и 32 бита не вижу вообще.

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

>я пишу и собираю проекты в eclipse, слушаю музыку, листаю инет и почту, все это работает вместе с compiz fusion, почему у меня все работает так же как в винде ( не считая того что винда умудряется иногда свопиться и приходится идти пить чай ) и нааааамного быстрее чем в маке? а для более быстрой загрузки попробуйте suspend to disk

Могу тебе сказать, что для P-III 933, который у меня был до предыдущего компа, я мог сказать то же самое (кроме compiz fusion). Но этого недостаточно.

Хочется, например, чтобы при копировании большого объема данных у меня фильмы не заикались или музыка (dma включен, sata-ii).

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

>Между тем, в 2.4 без патчей Кона слушать музыку или смотреть видео и при этом просто компилировать с -j2 и что-то куда-то копировать просто невозможно - сплошные лаги и выпадения кадров.

У меня обратное мнение. Более того, в 2.4 я не видел ни разу, чтобы мышь начала дергаться из-за нагрузки на винт.

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

>>У мну CFS. прокрутка некоторых веб-страниц иногда тормозить стала, когда gcc собирает.

>Я вчера тоже пробовал 2.6.22.1 и CFS. На больших дисковых нагрузках музыка заикается :( Да и отзывчивости особой как-то не заметил.

Неужто так плохо? Может машинка слабая?

А вот на AthlonXP 2500+ с FreeBSD 6.2-STABLE, когда собирается какой-либо порт в терминальном окне, музыка не заикается.

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

>Уже задрали люди, заявляющие, что раз не принимают ИХ работу, то быть Линуксу в жопе. Таких уже десяток-другой нашелся, а Линукс все еще нормально себя чувствует.

Ещё десяток-другой найдётся и линукскапец обеспечен. :)

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

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

iZEN ★★★★★
()
Ответ на: комментарий от anonymous-III

> То что нужно простым смертным юзерам (его патчи заточенные под десктоп) никак не согласуется с политикой партии (мнением ведущих кернел девелоперов, для которых главное чтобы линукс хорошо бегал на 1000 процессорах)

И в чём-то они правы. Они смотрят вперёд и видят на серверах и десктопах 1000-ядерные процессоры. И пишут ядро таким образом, чтобы в будущем оно работало не как 95 винда на Core2Duo.

Хотя, с другой стороны, Кона жалко.

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

> А, флеш перестал тормозить, если несколько окон открыть (тоже бесполезно, ибо поставил 64-битный линукс и флеш для меня закончился).

Для меня флэш не закончился:

Mozilla/5.0 (X11; U; Linux x86_64; ru; rv:1.8.1.4) Gecko/20070603 Firefox/2.0.0.4

+

net-www/netscape-flash-9.0.48.0-r1

+

net-www/nspluginwrapper-0.9.91.4

и флэш работает на ура

MaratIK
()
Ответ на: комментарий от pv4

> И в чём-то они правы. Они смотрят вперёд и видят на серверах и десктопах 1000-ядерные процессоры. И пишут ядро таким образом, чтобы в будущем оно работало не как 95 винда на Core2Duo.

Э-э-э, нет.

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

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

Вот об этом Кон и говорит.

Посмотри на Инго. Куча патчей O(1) (на самом деле O(много)). Это хорошо для большого количества процессов/запросов - да, но совсем не факт, что это хорошо при типичных для пользователя десятке процессов.

С написанием хорошо параллелящегося кода, способного работать на 1000 процессоров, это всё перпендикулярно.

execve
()

Доктор прописал эвтаназию, печально это всё =(

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

>и флэш работает на ура

Вот с этой же хренотой не пашет. Все поставил, прописал - не жреццо.

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

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

Это, собственно, и есть пресловутый баланс "cathedral vs bazaar".

В своё время несоблюдение этого баланса оттолкнуло Кита Паккарда от проекта XFree86.

Сейчас похожие тенденции наблюдаются в разработке ядра. Очень жаль, что Кон ушёл (независимо от того, насколько он "психически устойчив"). И очень надеюсь, что ветку -ck кто-нибудь возьмётся поддеживать.

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

> Проблемы в его RSDL были? Были.

С текущим CFS'ом тоже проблем хватает. Например на arm'ах с шансом примерно 80% на этапе загрузки вылетит красивые 2-3 странцы текста, сводящиеся к одному слову: oops. В остальных 20% он так честно распределяет ресурсы, что загрузка до логина шла около 12 часов вместо обычных полутора минут. При этом у RSDL ничего такого не наблюдалось. Вот так вот тестируют шедулеры нынче...

Civil
()
Ответ на: комментарий от aydef

> не совсем так. в мускуле нет ничего необычного - того, что небыло бы присуще любому многопоточному приложению активно использующее I/O и все подсистемы VM. мускул - это как раз очень показательно.

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

yeti
()

основная проблема у Кона с разработчиками была в том, что среди linux kernel developers очень сильно развит not-invented-here синдром. Прямо-таки гигантская опухоль... Идеи того же Кона неоднократно реализовывал Инго, забывая при этом отдать кредит автору. Только недавно он стал упоминать, что изначальная идея принадлежит тому-то... CFS и RSDL в основе суть одно и тоже, И проблемы похожие. Но Инго не мог позволить, чтобы авторство планировщика ядра перешло от него к Кону :)

А уж история со swap-prefetch совсем получилась глупая.

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

>зачем в ядре зоопарк разводить

Во-первых, там уже зоопарк. Во-вторых, ядро претендует на универсальность в различных вычислительных категориях.

Пара маркетинговых утверждений:

1. Чтобы превзойти конкурента, сделай все то же, что он, но лучше.
2. Предложи дополнительно новый, удобный функционал.

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

jackill ★★★★★
()

>Academic approaches to solutions tend not to be useful in the real world. On the flip side, pure hackery also tend to be long term disasters even if initially they're a quick fix. Finding the right balance between hackery and not ignoring the many years of academic research is what is needed.

>APC: Did you get that balance right?

>Heck no. But that's what I strived for.

Золотые слова! Очевидно, с таким человеком как Линус такой подход ужится не может.

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

Почему бы Кону не войти в лагерь GNU и не поспособствовать с его знаниями и идеями ускорению разработки GNU/Hurd? ... :)

Если Linux тормозится с внедрением новых идей и программингом just for fun, то есть и иные места приложения усилий.

Что касается производительности, то проблема освобождения от накопившихся ошибок и тормозов перезапуском все же пока есть.

Iaxx
()

OpenSolaris и OpenBSD

Товарищу анестезиологу -- респект.

Кстати, пользуясь случаем, можно почитать и первый комментарий к статье:

> You might want to look at the opensolaris community. You'll find most of your schedular issues have been addressed in Solaris -many as far back as 2.7 - and the community a lot less ego driven.

> And then, of course, there's openBSD - big ego issues, but interesting for desktop use.

> Paul Murphy (6 days ago)

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