Что нас ждет в Red Hat Enterprise Linux 5?

Люди, объясните, в статье рассматривается вот эта бета?

http://ftp.redhat.com/pub/redhat/linux/beta/RHEL5-Beta1/

ну про четверку я согласен - мертва с рождения.
а причем тут фанатизм?
у нас 95% серверов на SLES и Suse. корневой раздел всегда ext3. что-нить вроде /srv/www или /var/www - тоже. Остальное - по усмотрению...бывает и на рейсере.
Никто и не говорил, что рейсер всех заруливает - это вы передергивате.
я говорю о том, что эта FS сейчас довольно распространена и RH мог бы хотя бы не давать ставить си-му на нее, но вот так вот убирать сразу из ядра - это имхо, слишком.

>> Вот только fsck.jfs умеет делать segfault при проверке fs после выключения питания и нет возможности сделать resize в меньшую сторону, а так все хорошо...

> Баян, пофиксили давно. А уменьшение блочников - это да, офигеть какая нужная операция на серваке :)

Ну не знаю, где пофиксили, но jfsutils 1.1.11 у меня позавчера на этот баг натыкались. reiserfsck у меня за пять лет использования такого себе ни разу не позволял. А про resize в меньшую сторону - вы видно никогда активно LVM не использовали. Если на сервере живет десяток виртуальных машин, у которых постоянно меняются задачи и набор софта, то проблема перекидывания места c одной файловой системы на другую встает достаточно остро. Или вы разбивая оптический рейд на 16T можете заранее спрогнозировать на N лет вперед что на каких разделах будет лежать и сколько занимать?

мдя ... выкинули reiser фс ... ну и что ? ... что мешает самим ядро перекомпилить с его поддержкой? ... один фиг в стндартной поставке ядро будет неактуальное и с включёнными debug фишками ... самое время подправить конфиг и включить нужные опции ... заладили блин ...

> Ну не знаю, где пофиксили, но jfsutils 1.1.11 у меня позавчера на этот баг натыкались. reiserfsck у меня за пять лет использования такого себе ни разу не позволял.

Дык эти... UPS'ы, если сервак так часто и мощно падает, что необходимо вмешательство fsck на журналируемой системе?

> А про resize в меньшую сторону - вы видно никогда активно LVM не использовали. Если на сервере живет десяток виртуальных машин, у которых постоянно меняются задачи и набор софта, то проблема перекидывания места c одной файловой системы на другую встает достаточно остро. Или вы разбивая оптический рейд на 16T можете заранее спрогнозировать на N лет вперед что на каких разделах будет лежать и сколько занимать?

Конечно, даже больше - могу спрогнозировать, что объем корпоративных отходов жизнедеятельности Оракела будет только увеличиваться. Каюсь, с виртуалками активно не работал, и тем более с LVM на продакшене (упаси Джа!) - но ведь есть loop, на extent'ой ФС - самое милое дело, он не в состоянии помочь?

>мдя ... выкинули reiser фс ... ну и что ? ... что мешает самим ядро перекомпилить с его поддержкой? ... один фиг в стндартной поставке ядро будет неактуальное и с включёнными debug фишками ... самое время подправить конфиг и включить нужные опции ... заладили блин ...

извращенец

Откуда сведения про debug опции? Были примеры?

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

Дык, вона, товарищи сверху утверждают что все держат на reiserfs - и будут держать, при всех его ограничениях и недостатках.

> у нас 95% серверов на SLES и Suse. корневой раздел всегда ext3. что-нить вроде /srv/www или /var/www - тоже. Остальное - по усмотрению...бывает и на рейсере.

Вот это правильно, но рейзера - нужно того-сь... :) В зюзе - понятно, они им от рождения увлеклись и даже контрибьютили тучу кода по теме тех же posix acl/demand bitmap loading и т.п.

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

Годик-другой назад я сам полагал, что в условиях невысокого статического нагружения - десктопы/ws - рейзер таки заруливает на мелкоте всех, на среднем - почти всех, а единственное ограничение - большие файлы, тут он нещадно тормозил. И в целом - рейзер вовсе даже не глючил. Потом были открыты xfs/jfs и опытным путем установлено, что они практически не проигрывают рейзеру, а на некоторых задачах - так и вовсе беспощадно его уделывают (устарелый дизайн ФС, все такое).

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

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

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

>и будут держать, при всех его ограничениях и недостатках.

ДурачОк ты (и фанатик к тому же :D). ext3 имеет столько же ограничений и недостатков сколько и рейзер.

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

Именно на примере рейзер4 стали очевидно все подводные камни связанные с фс в линуксе, стало очевидно, что достоинства ext* больше связанны с недостаточно хорошим портированием других фс, что бы был хоть один аргумент в пользу ext*.

а ext4 инспирирован IBM, т.е сами по себе разработчики ext* не чесались и не чешуться, и даже дорогу другим перекрывают.

PS.Я сам проверял скорость работы рейзер4 и у меня она была существенно быстрее всех прочих систем.

PS1. У меня под рейзер3 работает много терабайт пользовательской информации(очень большого числа пользователей), никаких проблем.

>а ext4 инспирирован IBM, т.е сами по себе разработчики ext* не чесались и не чешуться, и даже дорогу другим перекрывают.

Не несите ерунды - ext4 начат в первую очередь из-за ограничений 32-битной адресации, причем процесс был вполне логичным - сторонние разработчики присылали патчи (workaround'ы для перевода 32-36, 32-48 бит и т.п.), потом Ted Tso сделал новую ветку, куда вошло большое количество потенциально опасных изменений.

а в сусе наверно оставят только NTFS-5 и FAT-32/16 ;-)
ps
забавно / на NTFS

> Насчет глючности рейзера 3 уже много раз говорилось, что проблемы связаны с глючным железом. Конечно, это недостаток проекта, его большая чувствительность к глючному железу,
> но при нормальной поддержке кернел девелоперов все могло быть решено.
Ха-ха-ха, какой такой поддержке ? Кто-то мешал делать reiserfs ? скрывали исходники ядра ? :)
Мы сделали вам глючную сложную FS - а вы теперь давайте поддерживайте, и в том что всех глюков не извели - вы сами и виноваты, плохо поддерживали.

> стало очевидно, что достоинства ext* больше связанны с недостаточно хорошим портированием других фс
Кто-то кому-то мешает их портировать ? Всегда рады любому желающему.

> что бы был хоть один аргумент в пользу ext*.
заговор! мне смешно... Оказывается Линус все эти 15 лет стремился не оптимально улучшить Линукс, а протащить какои-то не оптималные решения. Наверно поэтому Линукс сейчас стоит на 75% top500 компов планеты ?

> т.е сами по себе разработчики ext* не чесались и не чешуться и даже дорогу другим перекрывают.
Это исключительно твои ничем не подкрепленные бредовые фантазии.


> PS.Я сам проверял скорость работы рейзер4 и у меня она была существенно быстрее всех прочих систем.
Никому не нужна глючная ФС вне зависимости от ее скорости.
И я привел тесты где reiser4 сливает по полной ext4.

> PS1. У меня под рейзер3 работает много терабайт пользовательской информации(очень большого числа пользователей), никаких проблем.
Твоя судьба - твой выбор, у редхата выбор другой, тебя никто не заставляет.

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

во вторых, если бы ты читал ссылки связзанные с etx4, то и ты бы знал, что все основные патчи для этой системы пришли из ИБМ. Значит мой вывод о том, что разработчики Ext* вообще не чешуться не противоречит фактам.

О том, что нынешняя инфраструктура связанная с фс удобна только для ext* всплыло в переписке связаной с включением рейзер4 в ядро, и Мортон это признавал, поручив Рейзеру переписать один такой участок кода в ядре.

И в этом случае мои слова о заточенности кода ядра под ext* не противоречат фактам.

А о том, что есть пределы возможности влиять на кода ядра видно опять из истории рейзер4 - тот же Мортон сказал, что нужно менять весь вфс, но этот делать некому. И та же xfs на своей родной системе не имела тех дефектов, которые присутствует в порте на линукс. Совершенно очевидно, что для SGI было бы очень желательно, что бы с xfs не было связанно никаких дефектов, так как их будут сразу связывать с самой xfs, а не ее конкретной линукс реализацией. Значит, если они могли, они бы решили задачу. А считать, что не смогли решить задачу из -за того, что их разработчикам не хватило кваливификации - слишком смелое предположение.

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

>>а ext4 инспирирован IBM, т.е сами по себе разработчики ext* не чесались и не чешуться, и даже дорогу другим перекрывают.

>Не несите ерунды - ext4 начат в первую очередь из-за ограничений 32-битной адресации, причем процесс был вполне логичным - сторонние разработчики присылали патчи (workaround'ы для перевода 32-36, 32-48 бит и т.п.), потом Ted Tso сделал новую ветку, куда вошло большое количество потенциально опасных изменений.

>rtc * (*) (14.11.2006 14:11:32)

Все статьи о ext4 обязательно содержат рассказ о том, как ИБМ прислала патчи для увеличения разрядности и прочее, и что все основные патчи принадлежат ИБМ, и именно потому, решив что производимые изменения довольно серьезны, их нужно выделить в отдельное дерево разработки, и потом повысить версию

>Все статьи о ext4 обязательно содержат рассказ о том, как ИБМ прислала патчи для увеличения разрядности и прочее, и что все основные патчи принадлежат ИБМ, и именно потому, решив что производимые изменения довольно серьезны, их нужно выделить в отдельное дерево разработки, и потом повысить версию

Те, кому это надо, те и сделали - Mingming Cao из ibm прислал патчи, Andrew Morton и Theodore Tso форкнули дерево. Идет обычная работа, а не перекрытие дорог и палки в колесах.

>argin * (*) (14.11.2006 15:40:00)

>И в этом случае мои слова о заточенности кода ядра под ext* не противоречат фактам.

Да не заточено ничего, просто изначально была только одна ФС. Даже когда команда Рейзера присылала патчи касательно batching write, никто не считал, что VFS заточен под ext2/ext3.

>А о том, что есть пределы возможности влиять на кода ядра видно опять из истории рейзер4 - тот же Мортон сказал, что нужно менять весь вфс, но этот делать некому.

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

>И та же xfs на своей родной системе не имела тех дефектов, которые присутствует в порте на линукс. Совершенно очевидно, что для SGI было бы очень желательно, что бы с xfs не было связанно никаких дефектов, так как их будут сразу связывать с самой xfs, а не ее конкретной линукс реализацией. Значит, если они могли, они бы решили задачу. А считать, что не смогли решить задачу из -за того, что их разработчикам не хватило кваливификации - слишком смелое предположение.

Да-да, читали про прерывание отключения питания в SGI системах? Так в PC этого нет и не будет, поэтому нужны дополнительные подпорки файловым системам, которые уж очень трепетно относятся к порче данных, надо полагать, что при порте на Linux инженеры SGI не смогли достаточно прямо решить эту проблему.

>>Все статьи о ext4 обязательно содержат рассказ о том, как ИБМ прислала патчи для увеличения разрядности и прочее, и что все основные патчи принадлежат ИБМ, и именно потому, решив что производимые изменения довольно серьезны, их нужно выделить в отдельное дерево разработки, и потом повысить версию

>Те, кому это надо, те и сделали - Mingming Cao из ibm прислал патчи, Andrew Morton и Theodore Tso форкнули дерево. Идет обычная работа, а не перекрытие дорог и палки в колесах.

Правильно, о том и речь, что инициаторами выступили разработчики из ИБМ, а при нормальном ходе событий и нормальном планировании, инициировать эту работы должны были сами разработчики ядра, ведь необходимость повышать разрядность ext* возникла не вдруг

>>И в этом случае мои слова о заточенности кода ядра под ext* не противоречат фактам.

>Да не заточено ничего, просто изначально была только одна ФС. Даже когда команда Рейзера присылала патчи касательно batching write, никто не считал, что VFS заточен под ext2/ext3.

Нет уж, Мортон прямо говорил, что надо переписывать весь вфс ради рейзер4 и делать это некому. И так же я читал слова о том, что код ядра удобен именно для ext*, и другие вынуждены этот код в ядре дублировать для себя, делая его удобным именно себе. Это дублирование кода было и есть одной из претензий к рейзер4.

Естественно я согласен, что главное здесь сложившаяся историческая ситуация, когда ext* была единственной фс.

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

В случае с xfs все таки нет оснований считать, что разработчики SGI ни осилили.

>Правильно, о том и речь, что инициаторами выступили разработчики из ИБМ, а при нормальном ходе событий и нормальном планировании, инициировать эту работы должны были сами разработчики ядра, ведь необходимость повышать разрядность ext* возникла не вдруг

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

>argin * (*) (14.11.2006 16:43:37)

>Нет уж, Мортон прямо говорил, что надо переписывать весь вфс ради рейзер4 и делать это некому. И так же я читал слова о том, что код ядра удобен именно для ext*, и другие вынуждены этот код в ядре дублировать для себя, делая его удобным именно себе. Это дублирование кода было и есть одной из претензий к рейзер4.

Плохо читали - ищите тему на kerneltrap.org касательно batching write. Никто и никогда не собирался переписывать VFS. Тем более для Reiser4. Макчимум - это изменение размера блоков (сделать их увеличенными для записи больших файлов) и возможно добавление плагинов на уровне vfs.

>Естественно я согласен, что главное здесь сложившаяся историческая ситуация, когда ext* была единственной фс.

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

Reiser4 - это хак на хаке из-за того, что Ганс решил, что все нужно делать в собственной ФС, а не расширять VFS. Понятно, что никто не хочет это включать в дерево, особенно в свете истории с reiserfs (aka reiser 3). Похожая ситуация и с fuse, когда ее функциональность была заметно урезана для включения.

>В случае с xfs все таки нет оснований считать, что разработчики SGI ни осилили.

Там весьма сложный код, так что _никто_ кроме официальных разработчиков XFS в него не смотрит (да и скорее всего мало знает), так что винить здесь больше некого.

>argin * (*) (14.11.2006 16:51:30)

>Плохо читали - ищите тему на kerneltrap.org касательно batching write. Никто и никогда не собирался переписывать VFS. Тем более для Reiser4. Макчимум - это изменение размера блоков (сделать их увеличенными для записи больших файлов) и возможно добавление плагинов на уровне vfs.

Эта часть переписки даже приводилась и цитировалась на лоре.

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

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

А FAT конечно пипец какая надежная серверная фс. или в RHEL5 ее тоже не будет?

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

Наивно... Кстати, вы наверное в курсе, что Торвальдс начал один разработку Linux, но тем не менее сейчас очень многие вносят свой вклад.

>argin * (*) (14.11.2006 17:22:38)

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

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

это был вопрос ко мне ?

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

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

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

Программа пишется с определенным набором возможностей, как только кому-то нужна расширенная функциональность, он ее реализует (понятно, что это работает только в мире Open Source), при этом реализовать новые возможности может кто угодно, и вовсе не обязательно это должен быть маинтейнер, более того, он никому не должен и не обязан что-то делать по чьиму-либо запросу.

>argin * (*) (14.11.2006 17:51:26)

> во вторых, если бы ты читал ссылки связзанные с etx4, то и ты бы знал,

Я лично знаю разработчика экстентов для ext4. И сделал он их just for fun, к IBM никакого отношения не имеет. IBM дорабатывало его патчи.
Так что утверждение
>что все основные патчи для этой системы пришли из ИБМ.
ложно.


> Правильно, о том и речь, что инициаторами выступили разработчики из ИБМ,
> а при нормальном ходе событий и нормальном планировании, инициировать эту работы должны были сами разработчики ядра
Это ошибка. Linux это не обычный проект с планом работ, где все разработчики построились в ряд и делают все по команде.
Линукс - это эволюция, есть ряд файловых систем, те которые людям нужны - выживут , те что нет вымрут. Эволюционная модель в купе с грамотным руководством Линуса позволяет в долгосрочной перспективе достигать лучших результатов, чем в проектах с планированием.

тебе сюда: http://www.kroah.com/log/linux/ols_2006_keynote.html
cо слова evolution.


>PS. Я специально копировал дерево мелких файлов, и делал резет при копировании, никаких проблем, никакой порчи информации. На моей
>домашней машине,

Редхату надо чтобы файловая система была стабильна не только на домашних машинах с 1 CPU, а на на куче всевозможных серверных конфигураций с SMP 32 процессорами десятками винчетеров (часть из которых навернется в обозримом будущем) и т п.
Редхат не строит свой бизнес вокруг десктопов.

Почему-то я не сомневаюсь, что RH собирает и анализирует статистику по обращениям в техподдержку, и исключение RaiserFS вполне может быть вызвано серьезными инцидентами с ней. Допустим заплатили люди за RHEL, использовали RaiserFS, и потеряли данные. А техподдержке руками разводить? Извиняться?

Короче. Из гуру кто-нибудь объяснит мне стоит ли пробовать на десктопе Red Hat Enterprise Linux 5 Client? Или поставить Red Hat Enterprise Linux 5 Server и дорабатывать напильником?

И еще растолкуйте мне непонятливому. Я свободно могу скачать и использовать эти самые Red Hat Enterprise Linux 5 Client и Red Hat Enterprise Linux 5 Server?

>И еще растолкуйте мне непонятливому. Я свободно могу скачать и использовать эти самые Red Hat Enterprise Linux 5 Client и Red Hat Enterprise Linux 5 Server?

Только srpm. Бинарные сборки redhat'овских srpm называются centos, scientific linux и др. Или можно попытаться сделать это самому.

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

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

>Программа пишется с определенным набором возможностей, как только кому-то нужна расширенная функциональность, он ее реализует (понятно, что это работает только в мире Open Source), при этом реализовать новые возможности может кто угодно, и вовсе не обязательно это должен быть маинтейнер, более того, он никому не должен и не обязан что-то делать по чьиму-либо запросу.

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

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

>Но гораздо больше похоже на то, что вы просто пытаетесь создать в моих словах противоречие там, где его нет.

Вы уже противоречите сами себе. Снова.

>>Программа пишется с определенным набором возможностей, как только кому-то нужна расширенная функциональность, он ее реализует (понятно, что это работает только в мире Open Source), при этом реализовать новые возможности может кто угодно, и вовсе не обязательно это должен быть маинтейнер, более того, он никому не должен и не обязан что-то делать по чьиму-либо запросу.

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

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

>argin * (*) (14.11.2006 21:39:06)

>> во вторых, если бы ты читал ссылки связзанные с etx4, то и ты бы знал,

>Я лично знаю разработчика экстентов для ext4. И сделал он их just for fun, к IBM никакого отношения не имеет. IBM дорабатывало его патчи. Так что утверждение >>что все основные патчи для этой системы пришли из ИБМ. >ложно.

У нас серьезная проблема, я читал много статей по этой теме, и в них речь идет о том, что патчи это инициативя ИБМ, там речь не идет о том, это кто то предложитл патчи, которые ИБМ доработала и опять предложила.

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

Поэтому продолжение нашего спора бессмысленно, у меня недостаточно много свободного времени для поиска опровержения.

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

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

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

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

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

Вот его Theodore Tso и Andrew Morton и сделали - ext4 extents и 48-bit address space написали люди из IBM, а маинтейнеры в это время занимались другими полезными задачами, и никто никому не мешал и т.п.

>argin * (*) (14.11.2006 21:59:27)

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

>Вот его Theodore Tso и Andrew Morton и сделали - ext4 extents и 48-bit address space написали люди из IBM, а маинтейнеры в это время занимались другими полезными задачами, и никто никому не мешал и т.п

Плохо не то, что написали какой то кусок кода люди из ИБМ, а то, что именно ИБМ-щики явились инициаторами развития ext*.

Поверь, я не страдаю фетишизмом ФС. Они лишь инструмент решения вопросов, но в этой истории наглядно проявилось то, что ext* и его развитие никак не планируется, пущено на самотек.

Это будет не /, а \

;)