Сравнение планировщиков задач в линукс

> Моя - в том, что под реально тяжелой нагрузкой на реально многопроцессорных тачках Соляру просто не запускают :D

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

> Да я сам старик, и давно всё понял :) А распинаюсь - молодежи ради :D

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

> хм.. про микрозависания - могу подтвердить факт наличия.

А какой дистр? У меня 4 равных по частоте твоему ядра, может какие-то дистроспецифичные особенности?

> с водружённым туда оракелом.

Хорошим таким оракелом, с нагрузочкой в виде 10-15 сотен пожизненно туда подключённых и активно копошащихся рыл.

>stellar (*) (08.08.2007 17:41:22)

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

может. Suse 10.1.

:)

Гарик, как так получается - ты флеймишь тут наверное каждый день (по крайней мере, как я захожу на лор, всякий раз вижу тебя), а у тебя звёзд нет? Тебя "заговоили" что ли?

> И __тогдашний__ линукс вовсе не тормозил на таком железе, как сегодня не тормозит на сегодняшнем.

Гарик, ты слишком легко повелся на провокацию. Работаю на таком же железе как провокатор (дурик 800, 256 ОЗУ). Никаких "подтормаживаний" нет. В венде на 2 ГГц, 512 - есть, не смотря на "приоритет активного окна". :D

>Всё решаемо, нужно лишь чуток ручек приложить и без всяких патчей в ядро ;)

++

Задолбали какатели, впервые услашавшие слов "планировщик" на лор-е неделю назад.

> Гарик, как так получается - ты флеймишь тут наверное каждый день (по крайней мере, как я захожу на лор, всякий раз вижу тебя), а у тебя звёзд нет? Тебя "заговоили" что ли?

А ты вывеси опрос с предложением набавить мне апдейтом 500 скора и тут же срезать удалениями постов их обратно ;)

> Гарик, ты слишком легко повелся на провокацию. Работаю на таком же железе как провокатор (дурик 800, 256 ОЗУ). Никаких "подтормаживаний" нет. В венде на 2 ГГц, 512 - есть, не смотря на "приоритет активного окна". :D

Да и хрен с ним особо забористый, он уже и так проклят.

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

Клоун, и ты еще что-то говоришь про планировщик? =О

>медленным элементом являюсь я:)

Знаешь, заметно. Правда. :D

>Да и квалификация моя не позволяет лазить больше определенного по /etc

1. Причем тут /etc/

2. Сам признал свою некомпетентнось и продолжаешь тут гадить. Зачем?

>Но там таких тормозов не было никогда.

:D

> вывод о "тяжком наследии серверного прошлого".

)) Скорее "тяжкое наследие вантузятника" в твоей голове.

>IMHO, культура использования программно-аппаратных комплексов и ... гораздо эффективней для.

К тебе это похоже не относится.

При всем уважении.

>400 процессов, 15 минут работы, весь процессор сжирается вчистую, loadavg до ~550 доходил

Эмм.. это как? о_О

>Когда я поставил 10-ю Зюзю... то получил психотравму, последствие которой проявляются по сей день. Так не тормозила даже венда с VESA-видеодрайвером и с отключенным DMA для винтов... Если Вы на оном чуде просидели больше месяца, то "ыыыыыы", я бы умер...

++

>Нда. Ты хоть понимаешь своей дубиновой головушкой какой бред ты несешь? Речь была о динамическом изменении приоритетов СИСТЕМОЙ, ее планировщиком, а не пля о графических фронтендах к sudo renice.

Тупица, иди почитай про "динамическом изменении приоритетов СИСТЕМОЙ, ее планировщиком". Оно уже так сто лет в обед.

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

Это еще чего за бред? Хочешь побороться за орден "труженик 4.2"?

> > 400 процессов, 15 минут работы, весь процессор
> > сжирается вчистую, loadavg до ~550 доходил

> Эмм.. это как? о_О

Ну как, как, берёшь файлик:

http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c

компиляешь (+ "-lrt") и запускаешь как:

Usage : massive_intr <nproc> <runtime>
                nproc  : number of processes
                runtime   : execute time[sec]

На сколько смелости хватит. И продолжаешь работать,
типа как будто ничего не происходит.

>Ну как, как, берёшь файлик:

Вопрос немного о другом. Как может быть loadavg 550 при 400 существующих процессах? :]

Кто-нибудь может толково объяснить (или кинуть ссылку), почему проблемы _user-space_ приложения должны решаться на _уровне ядра_ (планировщик)?

Если иксы (или qt/gtk) криво написаны, то это _не_ проблема ядра и ядром не должна решаться. Почему когда процессоры были в 10 раз слабее, современные им версии kde/gnome тормозили так же, как сейчас нынешние? Почему разработчики считают, что могут запросто писать неэффективные программы, которые потом кто-нибудь (авторы ядра ОС например) исправит?

Не послать ли ядерщикам этих разработчиков <прочь>?

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

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

> Вопрос немного о другом. Как может быть loadavg 550 при 400 существующих процессах? :]

Ну а я откуда знаю? Типа я чего, эту софтинку вместо init чтоль запускал, ага?

>Типа я чего, эту софтинку вместо init чтоль запускал, ага?

>400 процессов

Я подумал, что всего столько. Тады понятно.

> И что ж они до сих пор не разродились на один, который заменит эти все три?

Причина в том, что в Linux есть правило: единожды выданное юзерам API больше не меняется без серьёзных на то оснований.

> Ну ведь очевидно, что для разного типа задач нужны разные планировщики.

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

> задачи типа: вот этим 3 процессам дать 20% cpu, вот этим 10-ти - 30%, a а остальное честно поделить между оставшимися - решается групповыми политиками или подобными механизмами ( как например в соляре )

На самом деле, одновременно с внесением в ядро CFS делается возможность шедулинговых групп. Возможно, что к следующему ядру это уже будет реализовано, пока под это там только заготовки вроде. CFS как проект обещает очень много интересного, Ingo даже пробовал "экономическую модель" придумывать, чтобы вознаграждать те процессы, которые работают по заданию других процессов (например X-Server, MySQL, PostgreSQL, you name it) работает для какого-то клиента, и неиспользованная часть временного слайса для клиента, ожидающего ответа от сервера должна премироваться серверу, а он, соответственно, быстрее отработать. Впрямую эта модель уже несколько раз была опробована и отвергнута, но через некоторую "экономическую модель" можно получить вполне адекватный результат.

> cfs использует rb-tree для хранения процессов и при большом кл-ве процессов (>= 1000), он будет работать на 20% медленнее.

Это, извините меня, очень странная формулировка. Это примерно как вместо i+=2 написать ++i;++i; и сказать, что раз вторая конструкция в ядре работает в два раза медленнее первой, то всё ядро в два раза тормознее стало. Ну будет выбор следующего процесса для исполнения сделан не за О(1), а за О(log2(n)), но это не означает, что для n=1000 разница в 10 раз, это означает, что первый алгоритм не зависит от n и всё, и ничего про тайминги. Кроме того, у Ingo в шедулере предусмотрена хитрость, чтобы выбор следующего процесса был на самом деле гораздо быстрее, чем проход по всему дереву.

> Для десктопа - отдавать бОльший приоритет задаче с активным окном.

Я на грабли этого бреда наступал в Win95 и OS/2 Warp 4.0 (у них именно такие планировщики). Когда на тот же компьютер с Pentium-100/S3 Trio 64/32Mb я поставил Slackware 3.1/Linux 2.0.30 с икссервером, я увидел как 3 Doom играют в окошках и не тормозят, когда под OS/2 даже один [активный] тормозил неприятно, если вдруг в фоне начинал T-Mail звонить. Интерактивностью своего четырёхлетнего уже десктопа я доволен по сей день.

> OS/2 даже один [активный] тормозил неприятно, если вдруг в фоне начинал T-Mail звонить.

Это мало что говорит о _планировщике_ OS/2 (кстати, хороший был планировщик). В OS/2 _любой_ процесс мог заказать себе realtime-приоритет, и кое-какие проги этим пользовались. Да и драйверы могли свой вклад внести :)

> Как в венде чтоль? Чтоб такое же тормозилово и глюкалово было? Когда можно лишь работать только с активным окном, тогда как всё остальное копошится в свопе?

Это ты по своим ощущениям рассказываешь,виндузятник. Или просто придумал этот бред? :)

> Дык ты ещё телепатический модуль не дописал. Иди работай, солнце ещё высоко.

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

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

HP суперкомпьютер с 4096 процессорами сделали. Сеьезные дяди нормальную систему Linux, кстати, туда поставили а не пионерский соплярикс, для которого это не тот уровень да и система не та. :)

> линупс даже на 16-32 ядрах на высокой многонитевой нагрузке сливать начинает даже уступающим по пиковой производительности системам на соляре и спарках

Ты Linux, надеюсь, тоже на SPARC гонял? Или сравнивал теплое с мягким?

> Да и не требуется это Солярке,

Точно. И солярка там не требуется. Ниасиливает она. Фтопку.

> железо там совсем другое и под другие цели заточено.

Под цель "освоение бюджета"?

> Пойду выпью, епть

Выпей йаду! :)

> А я бедный аспирант и не работаю, поэтому хенеси каждый день ближе к вечеру - это хорошая практика ;)

А где соплярисы одминел раньше? Уволили штоле оттуда за компелирование соплярукса на работе? Правильно - красноглазые соляроводы пользуются малым спросом у работодателей, все больше как-то нужны нормальные спецы по серьезным системам - по RedHat ENTERPRISE LUNUX, например, а не пионеры-подсолнухи. Ну что, получил за "линупс"?! :_)

<Вий-стайл он>

Поооднимииите мне веки...

Какие-то неактивные и бестолковые ананимусы пошли, ни тебе драйва, ни задора, только попытки какие-то циферки толкать. Пиписькомерки скучны и никому не интересны, нет бы рассказать, как Doom3 пустили, получив 200fps, на p3-450.

<Вий-стайл офф>

Да, кстати поглядите как работает быдлопланировщик O(1): $ ./massive_intr 100 100 004675 00003426 004676 00002936 004677 00003428 004674 00001782 004678 00000001 004679 00000001 004680 00000001 004681 00000001 004684 00000001 004685 00000001 004686 00000001 004644 00000001 004689 00000001 004690 00000001 004694 00000001 004695 00000001 004696 00000001 004645 00000001 004699 00000001 004700 00000001 004702 00000001

4 процесса сожрали все время процессора, из них два самые продуманные, а два на подхвате. Мультизадачность емае быдлопланировщика... Толи дело классный планировщик CFS от Инго, который реализует правильную многозадачность:

$ ./massive_intr 100 100 029119 00000248 029091 00000243 029112 00000248 029068 00000244 029155 00000244 029133 00000248 029160 00000244 029069 00000245 029159 00000244 029108 00000245 029067 00000244 029095 00000243 029102 00000245 029130 00000248 029120 00000248 029139 00000248 029142 00000248 029107 00000245 029144 00000248 029137 00000248 029078 00000243 029135 00000248 029146 00000248 029071 00000247 029105 00000245 029157 00000245 029084 00000243 029111 00000245 029077 00000243 029162 00000245 029123 00000248 029104 00000245 029126 00000248 029113 00000248 029128 00000248 029092 00000243 029129 00000248 029134 00000248 029121 00000248 029122 00000248 029149 00000248 029131 00000248 029154 00000245 029124 00000248 029103 00000245 029132 00000248 029158 00000245 ...

Да, кстати поглядите как работает быдлопланировщик O(1):
$ ./massive_intr 100 100
004675 00003426
004676 00002936
004677 00003428
004674 00001782
004678 00000001
004679 00000001
004680 00000001
004681 00000001
004684 00000001
004685 00000001
004686 00000001
004644 00000001
004689 00000001
004690 00000001
004694 00000001
004695 00000001
004696 00000001
004645 00000001
004699 00000001
004700 00000001
004702 00000001


4 процесса сожрали все время процессора, из них два самые продуманные, а два на подхвате. Мультизадачность емае быдлопланировщика... Толи дело классный планировщик CFS от Инго, который реализует правильную многозадачность:

$ ./massive_intr 100 100
029119 00000248
029091 00000243
029112 00000248
029068 00000244
029155 00000244
029133 00000248
029160 00000244
029069 00000245
029159 00000244
029108 00000245
029067 00000244
029095 00000243
029102 00000245
029130 00000248
029120 00000248
029139 00000248
029142 00000248
029107 00000245
029144 00000248
029137 00000248
029078 00000243
029135 00000248
029146 00000248
029071 00000247
029105 00000245
029157 00000245
029084 00000243
029111 00000245
029077 00000243
029162 00000245
029123 00000248
029104 00000245
029126 00000248
029113 00000248
029128 00000248
029092 00000243
029129 00000248
029134 00000248
029121 00000248
029122 00000248
029149 00000248
029131 00000248
029154 00000245
029124 00000248
029103 00000245
029132 00000248
029158 00000245
...

> Это мало что говорит о _планировщике_ OS/2 ...

Я полумух использовал начиная с 3.0 (1994), и с новым 4.0 (1997) сравнить имел возможность, новые "особенности" планировщика оценил. Приоритет активного окна в 4.0 -- известная фишка. Жалкое было зрелище. После чего записался в линуксоиды и сменил место работы, где требовались такие. Говорят, самый честный планировщик был в 2.11, но в 3.0 его ещё не сильно испортили, и потому я не особо заморачивался.

> Дык на килопроцессорный сервак и ядро Зюзевское специальным образом патчили, чтобы всё заработало, была ж новость на ЛОРе в стародавние времена, и феерический косяк в линупсе - создавалось столько ядерных потоков, что на пользовательские уже ничего не оставалось. Энтерпрайз система, где много чего предусмотрено и крутые шедулеры? ;)

Дык пропатчили мелочь и оно заработало без косяков на 4096 процессорах, а слоуварису даже патчи не помогут, масштабирование ни к черту и такие мощности вообще ниасиливает - не дорос еще до серьезного железа и уровня Linux.

> Да и сравнил маленький энтерпрайз и потребности отрасли в масштабах планеты...

Жжошь, красноглазый словарисовод! Вот так - даже IBM считают что слоуварис ничтожество и решили выбрать серьезную систему, Linux, вместо дырявой подсолнечной проприетарщины.

> Cколько планировщиков в BSD, Solaris, HP-UX?

Сколько в BSD файловых систем? А с журналированием? =) А IO-планировщиков? :) Linux-у не указ BSD RIP и цепляющаяся за жисть проприетарщина UNIX-зомби Solaris и HP-UX.

> Ну и пусть стоит, у них задачи специфические и Оракел там особо и не пустишь

У Оракла свой Oracle Linux(он же RHEL), поэтому новые версии оракла вообще могут перестать выпускаться под альтернативную систему солярус, будете как бсдшники в режиме эмуляции Линукса пытаться запустить Oracle на неподдерживаемой солярке. ;)

> Может всё-таки лучше один отличный планировщик чем несколько хороших? Зачем распылять силы на несколько планировщиков? Можно предвидеть аргумент "конкуренция", но ведь и так есть с кем соревноваться.

Расскажи это мегодистроклепателям. Была бы вот одна первошлака. И было бы зашибись. И флеймов кеды вс. гноме не существовало бы уже. И рпм вс. деб вс. портаге аналогично.

На самом деле новость взяли от сюда: http://linuxkernel.ru/?q=node/463

а не по какой там наводке opennet.

> Например, на машине, с которой я сейчас пишу этот пост (i865G, iP-IV 2.8GHz, 512MB), регулярно случаются "подвисания" (отсутствие видимой реакции на действия пользователя).

Очень странно. Не могли бы вы подробнее описать эти "подвисания"? Может это конфликт какой.

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

> Расскажи это мегодистроклепателям. Была бы вот одна первошлака. И было бы зашибись. И флеймов кеды вс. гноме не существовало бы уже. И рпм вс. деб вс. портаге аналогично.

Думай што говоришь! Тогда пришел бы пушной зверь лорокапец!

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

это было в ядре 2.4

В 2.6 максимальное кол-во потоков зависит от памяти на машине

> Очень странно. Не могли бы вы подробнее описать эти "подвисания"? Может это конфликт какой.

Подробней? Симптомы:

(а) приложения: Opera, KMail, OOo 2.2.0 ИнфраРесурс. Раньше в качестве mail-клиента использовался Thunderbird, тоже "подвисал". Еще раньше в качестве Web-браузера использовался Firefox, тоже "подвисал". Что странно, в основных рабочих приложениях (Konsole и vim, запущенный в Konsole) таких "подвисаний" не бывает;

(б) проявления: во время набора текста или (*гораздо* реже) при вызове контекстного меню (дополнительной кнопкой мыши) или главного меню курсор мыши останавливается на месте и не реагирует на перемещения мыши, эхо-вывод клавиатурного ввода на экран прекращается. Секунды две--три на экране не видно никаких изменений. При этом весь клавиатурный ввод и перемещения мыши по столу системой учитываются и проигрываются "моментально" в момент окончания "подвисания".

За время набора этого текста случилось два таких "подвисания".

P.S. Кстати, а что за ерунда такая с количеством процессов? В Slackware седьмой у меня весь ps aux на один экран вмещался вместе с IceWM (или что там у меня WM работало, уже не помню толком) и прочим прикладным ПО. А сейчас ps aux | grep -v ps | grep -v grep | wc -l выдает 92. Нафига столько много? ps aux | grep kde | grep -v grep | wc -l выдает 18. Это что, 18 процессов только окошки отрисовывают? Или я совсем отстал от жизни?

P.P.S. Из сетевых серверов на машине подняты только sshd и vsftpd. Никаких БД и т.п. "тяжеловесного" софта не крутится. Активно используется только: 1-й desktop Konsole (2--3 сеанса, vim), 2-й desktop Opera 9.20, 3-й desktop Skype и Gaim, 4-й desktop KMail. Иногда еще на первом десктопе запущены Kdvi, GV или Xpdf. Очень редко --- OpenOffice.org Writer или Calc.

> В Slackware седьмой у меня весь ps aux на один экран вмещался вместе с IceWM (или что там у меня WM работало, уже не помню толком) и прочим прикладным ПО. А сейчас ps aux | grep -v ps | grep -v grep | wc -l выдает 92. Нафига столько много?

Жирная слака использовала на порядки больше памяти чем 64КБ ОЗУ! Целые МАГАБАЙТЫ!!! Зачем так много?! Вот раньше были ОС и программы ... и 32 КБайта ОЗУ хватало!

> ps aux | grep kde | grep -v grep | wc -l выдает 18. Это что, 18 процессов только окошки отрисовывают?

А если немного подумать головой и посмотреть вывод ps без wc -l? Слакварщики ёмаё. Наверняка там большая часть - ядерные процессы такие как [kacpid] [kblockd/x] [kthread] [khelper] [ksoftirqd/x] [migration/x] ...

Спасибо за желание помочь!

> А если немного подумать головой и посмотреть вывод ps без wc -l?

Смотрел, конечно же, смотрел. Только что мне это дает? Кучу циферок да буковок. Понять, что именно там написано, я, конечно, могу, но вот понять зачем этот процесс нужен --- нет. По крайней мере, вывода команды ps aux для этого точно недостаточно.

> Слакварщики ёмаё.

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

Кстати говоря, я так понимаю, что "слакварщик" --- это поклонник соответствующего дистрибутива? В таком случае Ваше утверждение не соответствует действительности --- я не являюсь поклонником ни одного дистрибутива. Мне, строго говоря, не важно даже Windows или Linux стоит на рабочей машине --- vim, C++ compiler/debugger, LaTeX и Web/e-mail/Skype/ICQ есть и там и там.

> Наверняка там большая часть - ядерные процессы такие как [kacpid] [kblockd/x] [kthread] [khelper] [ksoftirqd/x] [migration/x]...

Да, именно так. А что такое ядерный процесс? И нужно ли мне это знать для того, чтобы решать мои задачи? На всякий случай --- я занимаюсь разработкой (~40% работы "на бумаге"), отладкой (~10% работы "компилятор+отладка") и распространением (~50% работы написание, редактирование и публикация научных работ) алгоритмов обработки цифрового медиа-контента. NB! Алгоритмов, а не прикладных программ, их реализующих.

> А что такое ядерный процесс?

Долго объяснять

> И нужно ли мне это знать для того, чтобы решать мои задачи?

Не нужно. И лезть в треды, которые подразумевают такое знание - тоже не нужно.

> Смотрел, конечно же, смотрел. Только что мне это дает? Кучу циферок да буковок.

Мда. Что показывает ps xauw|awk '$11~/\[.*\]/ {print $11}' ?

> Я, конечно, понимаю, что наклеивание ярлыков упрощает жизнь (ровно как и категоричность в суждениях:)),

Да просто удивительно слышать вопросы про "неужели все эти 18 процессов отрисовывают окошки" от ТЕХНАРЕЙ-СЛАКВАРЬЩИКОВ, которые в теории знают свою систему, как и гентушники, как свои пять пальцев, не говоря уже про основы. Я бы не удивился услышав такое от убнтщика или от сузевца или даже от федоровца, но услышать вопросы такого уровня от слакварщика или гентушника - нонсенсю

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

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

> Кстати говоря, я так понимаю, что "слакварщик" --- это поклонник соответствующего дистрибутива?

Это пользователь дистрибутива Slackware. Я про это:

> В Slackware седьмой у меня весь ps aux на один экран вмещался вместе

> А что такое ядерный процесс?

Это процесс который работает в режиме ядра а не в юзерспейсе.

> И нужно ли мне это знать для того, чтобы решать мои задачи?

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

> И лезть в треды, которые подразумевают такое знание - тоже не нужно.

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

Тем не менее, хочу отметить, что мой оригинальный пост (http://www.linux.org.ru/jump-message.jsp?msgid=2075225&cid=2075679) в тему был комментарием именно к новости. А именно к той ее части, что касается организации процесса разработки ПО (выбор стратегии развития экспериментальной ветки проекта и т.п.). А вот в этой области я уже имею (успешный) опыт, которым и хотел поделиться.

Как бы то ни было, признаю свою вину в том, что в пылу беседы спровоцировал значительное отклонение от темы беседы. Еще раз прошу прощеня. С оффтопиком на этом заканчиваю.

P.S. 2 anonymous от 12:32:32. Отлично понимая, что здесь не институт благородных девиц и полная свобода, незамутненная даже элементарными нормами вежливости и уважительности по отношению к собеседнику, тем не менее, должен признать, что мне несколько затруднительно общаться в таком тоне. Я просто не умею говорить на этом языке:(

> На всякий случай --- я занимаюсь разработкой (~40% работы "на бумаге"), отладкой (~10% работы "компилятор+отладка") и распространением (~50% работы написание, редактирование и публикация научных работ) алгоритмов обработки цифрового медиа-контента. NB!

Это нисколько не оправдывает незнания разработчиком основ используемой системы :)