А разве pre версии, это не аналог release condidate-ов?

ну, логика в этом есть. зачем писать 3 буквы (pre), если можно 2 (rc)

а как классно звучит то Release Candidate 1. ;) логика в ином ;) теперь будем выспускать пре и тест версии к RC ядрам ;))))

2anonymous (*) (2001-12-16 15:00:30.0):

> А разве pre версии, это не аналог release condidate-ов?

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

Да ну этот ЛИНУКС! Новые ядра выходят каждые 2 недели, а стабильности так и не видать, в отличие от FreeBSD ;]

Предыдущему оратору с говорящим за него ником.. Кто Вас принуждает ставить новые свежеиспеченные ядра? Это замечательно что Линух живет такой активной жизнью. У меня где 2.4.7, где 2.4.10 стоит и все стабильно работает. Так что каждому свое, кому Фря, кому Линух. Все определяется задачами. Где-то Фря рулит, а где-то сосет, извините. Так что все эти флеймы - нелепая трата времени.

Удел FreeBSD это однопроцессорные системы с web сервером (в этом она реально не плоза). В остальных случаях фря либо проигрывает линуксу, либо ничем не лучше. А про не стабильность линукса говорят админы со стажем <=1.5 лет. У меня до сих пор работают сервера с ядрами 2.0.36 2.2.10 2.2.19, и не жужжат. Гораздо чаще возникают траблы с прикладным софтом чем с ядром, и это приносит на порядок больше проблем.

PS Вас никто не заставляет пользоваться линуксом.
PS2 xBSD это ~6% web сервером (в мире).
Boo

На этом сайте уже упоминалось, как FreeBSD в тестах имени Byte
серьёзно лоботомизированная FreeBSD (maxusers был меньше разумных
пределов), дала фору пресовременнейшему Линуксу на двух-процессорной
машине. Так что, обращая твою же логику против тебя, -
"Удел Linux это однопроцессорные системы" и далее по тексту.

Оригинальный автор скорее всего имел в виду подчеркнуть, что
сам процесс разработки, применяемый разработчиками FreBSD более
устойчив к появлению ляпов типа Linux 2.4.15 - там таких штук,
как 2.x.x-{pre, rc}-{aa,ac} просто нет. На это CVS имеется.

И каким местом оная методика RC даст что-нибудь?
Бага в 2.4.15 была и в последнем pre.
И ... толку?
Пока не будет некоей процедуры QA толку будет 0.
И проводить QA кроме сборщиков дистрибутивов некому,
как я понимаю.
Вывод- ядрами с kernel.org, если хотите, чтобы
вам начальство не открутило яйца, пользоваться нельзя.

2anonymous (*) (2001-12-16 20:48:59.0)
Мда, господа.

Есть кучи тестов, где winNT обыгрывает linux, linux обынрывает BSD, BSD обыгрвает Solaris и т.д.
В xBSD нет нормальной мультипроцессорности (об этом говорят ее разработчики), нет журналирумых FS, нет комерческого софта (эмуляцию линукса не предлагать).

Для desktop все еще хуже.
Так что юзайте на здоровье, но доля BSD постепенно сокращается.

> Есть кучи тестов, где winNT обыгрывает linux, linux обынрывает BSD,
> BSD обыгрвает Solaris и т.д.
Есть куча тестов, где Solaris делает всех остальных. Есть другая куча, где царит NT, и есть третья, где BSD побеждает всех на своём
пути. Всё зависит от того, кто за тесты платит. Верить этому -
дело хозяйское.

> эмуляцию линукса не предлагать.
Потому что жаба душит? Религия не велит? Это почему не предлагать,
позвольте? Работает ведь.

> В xBSD нет нормальной мультипроцессорности (об этом говорят ее
> разработчики),
Нету, нету, но вот на двух-процессорной машине FreeBSD живёт довольно
достойно в сравнении с 2.4 Linux, что пожалуй доказывает, что слухи
о какой-то особой навороченности SMP в Linux несколько преувеличены
:) Да и SMPng не за горами.

> нет журналируемых FS
А вы не делайте из журналирумых FS культа. Сразу вдруг выяснится,
что никаких реальных преимуществ над softupdates журнал не даёт.
Единственное заметное преимущество - отсутствие fsck при
перезагрузке, ну так с этим на CURRENT борются при помощи
background fsck, который в этом случае и не fsck вовсе, а просто
фоновый garbage collector для потерянных блоков. А вот сможет ли
Linux продемонстрировать наличие такой удобной фишки, как FS
snapshots, встречный тебе вопрос?

> Для desktop все еще хуже.
> Так что юзайте на здоровье, но доля BSD постепенно сокращается.
А сейчас список того, без чего на FreeBSD десктопе жить нельзя.
Доля BSD сокращается, при этом количество инсталляций растёт
неуклонно - мы уж как нибудь переживём такое сокращение :)
А уж как плохо с дестопом и коммерческим софтом под Linux, в
сравнении с Windows, MacOS (а скоро и с MacOS X) мы и обсуждать
здесь не станем.

Пользуйтесь чем угодно, только FUD распространять не надо.

> И каким местом оная методика RC даст что-нибудь?
> Бага в 2.4.15 была и в последнем pre.
Во первых между последним pre и 2.4.15 перерыв был всего-лишь 24 часа
а rc1 уже 4 суток лежит без перехода в final.

и во-вторых скорее всего [почти] никто не знал что то последний pre был перед 2.4.15
соответсвенно протестировано было в 10 раз хуже.

> но вот на двух-процессорной машине FreeBSD живёт довольно
> достойно в сравнении с 2.4 Linux,

Чудак, ты откуда такие данные взял? Из той статьи что ли? Тот товарищ
журналюга. И этим все сказано. Профи над его результатами посмеялись и забыли.
Ты свой опыт покажи или не болтай чепуху. Пишу это с дуал-бут машины freebsd-4.4/linux-2.4.16.

>> нет журналируемых FS
> А вы не делайте из журналирумых FS культа.

А мы не делаем. Мы с ними работаем ;) У меня ext3 data=journal пережила 5 выключений света
в течение 20 минут. Ни одного байтика не потеряно, рестарт мгновенный.

Official: Linux vs. FreeBSD - Offtopic

сабж.

То maxcom:
Надеюсь журналируемые vs. не-журналируемые FS оfftopic-ом не
засчитают. В противном случае - извиняюсь.

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

Что делают softupdates? Минимизация потерь данных и гарантия
постоянной консистентности образа FS на диске засчёт построения
графа зависимостей между блоками, и, как следствие, аккуратный
порядок сбрасывания "грязных" блоков на диск. Журнал - это один способ сохранить консистентность метаданных, softupdates - это то
же, но достигнутое иным способом. И, заметьте, мы с ними тоже
работаем, и, вероятно, подольше, чем вы с журналируемыми FS.

> У меня ext3 data=journal пережила 5 выключений света
> в течение 20 минут.
Проглядите архивы, и вы без труда обнаружите точно такие-же
"свидетельства", но приведённые для ext2. Чего такие свидетельства
стоят вы и сами знаете.

"mount -o data=journal"
Journals all data and metadata, so data is written twice.This
is the mode which all prior versions of ext3 used.
В других местах подобную проблему решают UPS. Как дополнительный
бонус, это позволяет избежать накладных расходов на двойную
перезапись данных. Ты не поверишь, но мой сервер переживёт
сколь угодно большое количество отключений питания в 20-ти минутный
период, и даже без рестартов :)

> То есть вы утверждаете, что ext3 защищает и данные, и метаданные?

Да, если смонтирована как data=journal.

> порядка записи блоков на диск, и с журналом имеет мало общего.

Чушь полная. RTFM.

> softupdates - это то же, но достигнутое иным способом.

softupdates не гарантирует тебе, что письмо полученное за секунду до обрыва
электичества ты сможешь прочитать после новой загрузки.
Опять RTFM: http://www.usenix.org/publications/library/proceedings/usenix2000/general/ful...

> и вы без труда обнаружите точно такие-же "свидетельства", но приведённые для ext2.

Опять мимо. Потерял второе и самое важное предложение: "Ни одного байтика не потеряно, рестарт мгновенный."
Про UPS'ы верное замечание, но есть множество жизненных ситуаций, где это неприменимо.

> и даже без рестартов :)

А этот как? Я имел в виду, что машина автоматически стартовала при каждом включении света.
А ви что подумали?

> Чушь полная. RTFM.
Отнюдь. Без data=journal ext3 не защитит тебя от потери данных,
и речь может идти только о минимизации потерь. Своих слов назад
не забираю. При чём здесь TFM?

> softupdates не гарантирует тебе, что письмо полученное за
> секунду до обрыва электичества ты сможешь прочитать после новой
> загрузки.
Изумительно справедливо. Однако любая FS не сможет тебе гарантировать
того же, без синхронного сброса каких-либо буфферов на диск, будь
это собственно данные или они же, но в журнале. Про UPS как более
практичный способ просьба перечитать предыдущее письмо. Потом
осознай, что data=journal - это свойство, чья полезность - это
дело довольно спорное при наличии УПС. А отсюда и до вывода, что
журнал - это over-hyped культ, и совсем недалеко. Без data=journal
softupdates и Ext3 предоставляют сравнимую защиту от сбоев.

> Опять мимо. Потерял второе и самое важное предложение:
> "Ни одного байтика не потеряно, рестарт мгновенный."
> Про UPS'ы верное замечание, но есть множество жизненных
> ситуаций, где это неприменимо.
Ну почему же потерял. Ты же сам повторил это своими словами - UPS
предоставляет те же удобства, без потери производительности из-за
двойной перезаписи данных. Ситуаций, где UPS принципиально не
применим, не так уж и много, как тебе кажется, и они как правило
разрешимы путём специализированного кода для данной конкретной ситуации. Или чем-то типа nvram cache в одном известном мне
embedded device для медицины :)


> А этот как? Я имел в виду, что машина автоматически стартовала
> при каждом включении света. А ви что подумали?
А ми (sic!) подумали, что при наличии UPS машина не рестартовала
вовсе. Это надо было объяснить?

> Отнюдь. Без data=journal ext3 не защитит тебя от потери данных,

Ну и глупо это повторять. Я не говорил о журналировании абстрактно. Я говорил
конкретно про ext3 в режиме data=journal.

Про UPS ты все правильно говоришь, за исключением того, что UPS не спасет
тебя в двух оставшихся случаях: сбоя в работе ядра (падение машины) и отключении
самого UPS'а ;)

Жизненных случаев невозможности использования UPS'a могу рассказать сколько угодно.
Малобюджетные машины, домашниее машины, ноутбуки, PDA, микроустройства.
Указанные категории не требуют постоянного подключения. Для них главное
быстрое восстановление после обрыва напряжения и целостность данных.

Короче, это спор бесполезный. Появится через пару лет журналирумая fs во freebsd
и ты будешь очень уверенно себя чувствовать в споре с любителями ДОС'a ;)

Утверждение один:
> Я говорил конкретно про ext3 в режиме data=journal.
Как насчёт последствий для производительности системы?

Утверждение два:
> Появится через пару лет журналирумая fs во freebsd
> и ты будешь очень уверенно себя чувствовать в споре с любителями
> ДОС'a
Поверю, когда увижу хоть одного малобюджетного юзера, согласного
пожертвовать производительностью своей системы для получения той
малой толики дополнительной защищённости сверх того, что ему уже
предоставляет ordered и metadata журнал, и, соответственно,
softupdates тоже. Вспомним, что мы говорим о той категории
граждан, которая годами использовала async mounts в ext2fs,
устанавливаемые по умолчанию большинством дистрибутивов и ни разу
не озаботилась разумностью этого. Думаю, первая строчка в бенчмарках
им как-то милее. Все остальные как-раз таки предпочтут более
эффективные решения для обеспечения защиты данных, чем data=journal.

Всё вышесказанное никоим образом не означает, что я не буду рад
появлению журналируемой FS в OS, которую я предпочитаю всем иным.
Просто я отказываюсь принимать на веру утверждение, что
журналируемые системы чудесным образом избавят меня от всех
проблем. Никак.

> Про UPS ты все правильно говоришь, за исключением того, что UPS > не спасет тебя в двух оставшихся случаях: сбоя в работе ядра >(падение машины) и отключении самого UPS'а ;) От падения ядра тебя не спасёт и журналируемая FS. Если уж оно упало, то кто знает, что оно там перед падением наворотить успело. Поздно с этим при помощи журналирования бороться :)

> Как насчёт последствий для производительности системы?

Ага... ты уже запел другие песни и другим голосом. Не поверишь, но очень
хорошая производительность. Сужу по десктопу. Порой мне кажется, что она выше,
чем с ext2. А недавно мои субъективные ощущения подтвердились данными бенчмарков,
которые делали специалисты. Очень интересное свойство было обнаружено у ext3
в режиме data=journal - просто выдающаяся интерактивность. Вот тебе и журнал!
Читай http://www-106.ibm.com/developerworks/linux/library/l-fs8.html начиная со слов
"Theoretically, data=journal mode is the slowest journaling mode of all"

Еше насчет скорости можно прочитать тут: http://www.symonds.net/~rajesh/howto/ext3/ext3-2.html
Цитата:
"Despite writing some data more than once, ext3 is often faster (higher throughput) than ext2
because ext3's journaling optimizes hard drive head motion."
Surprise, surprise...

Для серверов с UPS'ом я применяю разные стратегии: корень смонтирован как ext2,
/usr смонтирован как ext3 data=writeback, а /home и /var - ext3 data=journal.
Я тебе одно могу сказать. Даже если это несколько медленнее на определенных операциях,
это все равно быстрее, чем на ufs ;)

>Во первых между последним pre и 2.4.15 перерыв был всего-лишь 24 часа
> rc1 уже 4 суток лежит без перехода в final.

И что? Он таки будет релизом?
Не верю :)

>и во-вторых скорее всего [почти] никто не знал что то последний pre >был перед 2.4.15
>соответсвенно протестировано было в 10 раз хуже.

Кхм Я вот этот рс не поставил и не буду
И откуда у него больше тестирования? :)

> Ага... ты уже запел другие песни и другим голосом. Не поверишь,
> но очень хорошая производительность.
Нет, не поверю. Будучи воспитан материалистом, я свято убеждён,
что два больше одного. Да и личный опыт игр с Linux FS-ами не
позволяет.

> Читай
> http://www-106.ibm.com/developerworks/linux/library/l-fs8.html
> начиная со слов
> "Theoretically, data=journal mode is the slowest journaling
> mode of all"
"Сказки дядюшки Linus-а". C каких это пор интерактивная работа -
это чтение /dev/zero в один и тот же файл? Архивчик вот
распакуй с ~100k files в ~ 15k директориях, понаблюдаешь, как та же
XFS не оставит камня на камне от Ext3, а async ext2 сделает их
обоих.

> Andrew is still trying to figure out exactly why data=journal
> mode is doing so much better than everything else.
И бог ему в помощь. Cм. ниже:

>Some people have had a particular performance problem when using
> ext3's data=journal mode on busy servers -- busy NFS servers, in
> particular. Every thirty seconds, the server experiences a huge
> storm of disk-writing activity, causing the system to nearly
> grind to a halt. If you experience this problem, it's easy to fix.
> Simply type the following command as root to tweak Linux's dirty
> buffer-flushing algorithm:
> Tweaking bdflush
> echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush

Интересно, догадается ли специалист связать эти два факта?

> Даже если это несколько медленнее на определенных операциях,
> это все равно быстрее, чем на ufs ;)
Bull. К вышеописанному тесту прибавь тот факт, что UFS c dirprefs
делает на нём ext2 и продолжай гордиться своей производительностью.
В одиночку.

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

>Some people have had a particular performance problem when using
> ext3's data=journal mode on busy servers -- busy NFS servers, in
> particular. Every thirty seconds, the server experiences a huge
> storm of disk-writing activity, causing the system to nearly
> grind to a halt. If you experience this problem, it's easy to fix.
> Simply type the following command as root to tweak Linux's dirty
> buffer-flushing algorithm:
> Tweaking bdflush
> echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush

Интересно, догадался ли специалист связать эти два факта?

> Даже если это несколько медленнее на определенных операциях,
> это все равно быстрее, чем на ufs ;)
Bull.

Да не волнуйся ты так. Все у тебя будет хорошо ;)
И не сказки это, а отчет тестовой лаборатории ibm.
busy NFS servers - это busy NFS servers, и тонкую подстройку им никто не отменял...
А вообще я тебя понимаю ;(

2anonymous (*) (2001-12-16 18:29:23.0) L в моем нике - это совсем не то, о чем ты подумал.

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

А что, xfs разве не журналируемая файловая система? (Это к вопросу о том, что она камня на камне не оставит от ext3)

> А что, xfs разве не
Не обращай внимания. Тот товарищ не имеет представления о чем он говорит.
Это у него так, теоретические рассуждения, мысли вслух.

> распакуй с ~100k files в ~ 15k директориях,

Какого размера должны быть файлы в директориях? Я могу провести такой опыт.

Я вот вижу, что появление Release Candidate поимело сильный психологический эффект.
Кажется народ почувствовал и свою ответственность за выход финального ядра.
Количество багрепортов и активность patch-мэйкеров возросла на порядок.
Очень полезное начинание.

Еще бы научились свой код тестить самостоятельно.

Ага! И заимели бы себе по 1000 компьютеров разных конфигураций да?

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

Экстремальное тестирование начинаемое как можно раньше - одна из методик разработки. Вполне эффективная...

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

Это как бы на уровне радиолюбительства.
Линух же нонеча типа enterprise ready.
А никакого QA не видать.
Дистрибуторы таки да, проводят оный QA, да х. толку.
Иначе бы не имели такой грустной картины на sap.com/linux

В обчем, интересно мне, оно само помрет или останется жить
как вариант ОС для апача на загибающихся же ибиемных менйфремах? :)

Апача загнется гораздо раньше мэйнфремов.

anonymous'ы загнутся раньше ;))

Все преходяще, Ананимусу вечны! Аминь.