|
2.19, odmin (ok), 07:48, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Есть хоть какие-то шансы, что во фре появится быстрая FS Без этого пусть хоть в... большой текст свёрнут, показать | |
|
3.20, odmin (ok), 07:58, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Кстати, используется 32-битный режим почему-то. Просто тупо молча. Наверное чтобы не говорить лишний раз, что у FreeBSD с её одной единственной веткой портов на ВСЕ семейства с 64-битами всё очень грустно.
Короче, напрягают меня такие "честные сравнения" со стороны Кенни. Тем более, что у Ника Пиггина даже в предложенных Кеннавеем условиях линукс получается быстрее... С чего бы вдруг....
| |
|
4.23, Аноним (23), 08:47, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Что за бред про 32-битный режим? Все на 64бит, никаких проблем.
Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете объяснить зачем? Broken на amd64 вообще-то всего 32 порта.
Про тормозной и сырой ZFS - тоже посмеялся. 2 месяца в продакшне (пока на HA кластере, разумеется) - ни одной проблемы. Такой стабильной ФС я, пожалуй, еще не видел. Со скоростью тоже все ok - с большими файлами и raidz - 90% от теоретического максимума (пропускная способность дисков). На мелких файлах особо не мерял, но по крайней мере операции с деревом портов раз в 5 быстрее UFS.
fsck мне никогда не был нужен. Хотя с ним потенциальная проблема есть, согласен. Только не поверю что ему нужна ядерная память.
В общем, все как всегда. Руки.
| |
|
5.24, odmin (ok), 09:16, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Что всё Почему тестирование Кенни провёл в заскорузлых 32 битах Откуда дрова... большой текст свёрнут, показать | |
|
6.28, Кирилл (??), 11:53, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Да, все баги, которые постоянно вылазят у подписчиков freebsd-stable@ твоих прямых рук
>испугались и спрятались...
Возможно это касается ветки Карент, но в Стабл никаких проблем в пределах означеной функциональности в обычной эксплуатации не замечал.
| |
6.31, portsman (?), 12:14, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>Что "всё"? Почему тестирование Кенни провёл в заскорузлых 32 битах?
>
>>Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете >>объяснить зачем? Broken на amd64 вообще-то всего 32 порта.
>
>Откуда дрова? Ни в жисть не поверю, после всего прочитанного в разных
>листах, что из 18 тысяч портов только 32 штуки в 64битах
>не работают. ФАНТАСТИКА! Во фре намного больше просто BROKEN портов, не
>говоря о специфике. Ещё скажите, что на других архитектурах тоже все
>18 тыщ портов отлично работают... :)
Зачем верить ну есть же сухая стистика:
http://portsmon.freebsd.org/portserrcounts.py?buildenv=amd64
http://pointyhat.freebsd.org/errorlogs/packagestats.html
| |
6.61, Аноним (23), 18:13, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Это не в курсе, у него спросите У меня ни на десктопе, ни на ноуте, ни на серве... большой текст свёрнут, показать | |
|
|
|
3.27, Кирилл (??), 11:44, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Если у вас есть разделы по Терабайту, то строго рекомендуется использовать журнализированную ФС. И кто вам сказал, что она "сырая"? Надо было хотя бы ознакомиться с возможностями и ограничениями различных ф/с перед тем, как терабайтный разделы пилить, а не рассуждать тут о том, что вот система какая плохая, я о неё нихрена не знаю, делаю абы чего, а она ещё работать отказывается, как я себе напридумывал.
П.С: Господа пионеры, бросай привычку вякнуть абы чего, лишь бы голос подать.
| |
|
4.34, odmin (ok), 12:56, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Если у вас разделы по терабайту, то строго рекомендуется использовать нормальную ОС. Я правильно понял? :-D
Потому как UFS2 якобы и больше поддерживает, но КАК? И в документации, кстати, ни слова про то, что оно будет fsck-аться 3 часа и что сам fsck будет валиться и жрать память как свинья помои. GJOURNAL только вышло из статуса беты, zfs ещё не вышло. Тот кто СЕЙЧАС использует FreeBSD по всем признакам пионер. А вовсе не те, кто ругает бзду...
| |
|
|
6.40, Кирилл (??), 14:31, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>зачет :)
Нет, _Nick_, не зачёт. Пионер лепит херню. Так что слюни пускать не советую.
| |
|
7.46, _Nick_ (??), 15:18, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Нет, _Nick_, не зачёт. Пионер лепит херню. Так что слюни пускать не
>советую.
ну, слюна уже пущена :))
PS с сеня сам переползаю с JFS на ext4. Во де красота.
И online resize (как в JFS), но и offline shrinking (чего ТАК не хватало
в JFS), вагон рулей тюнинга, обратная совместимость с ext3 (пока на включишь
новые фичи).
| |
|
|
9.57, _Nick_ (ok), 16:46, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | никаких опечаток Хоть какой shrinking Потому как в JFS Линуховом его нету ваще... текст свёрнут, показать | |
|
|
|
|
5.36, Аноним (-), 13:21, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
> будет fsck-аться 3 часа
сократи кол-во inode'ов
newfs(8)
-i bytes
Specify the density of inodes in the file system. The default is
to create an inode for every (4 * frag-size) bytes of data space.
If fewer inodes are desired, a larger number should be used; to
create more inodes a smaller number should be given. One inode
is required for each distinct file, so this value effectively
specifies the average file size on the file system.
| |
5.42, BayaN (ok), 14:32, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Тот кто СЕЙЧАС использует FreeBSD по всем признакам пионер. А вовсе не те, кто ругает бзду...
Так, а зачем тогда ты её используешь? Используй Linux, лично меня в нём всё устраивает.
| |
|
6.45, Кирилл (??), 14:46, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Так, а зачем тогда ты её используешь? Используй Linux, лично меня в
>нём всё устраивает.
А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке? Я без иронии, просто не в курсе многих решений. И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?
| |
|
7.48, _Nick_ (??), 15:25, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке?
>Я без иронии, просто не в курсе многих решений.
журнал.
если какой коммит не закончится полностью (что большая редкость, как ты понимаешь),
то fsck пойдет полную проверку делать. Иначе (считай 99% сбоев) - просто откатит журнал.
Секунды.
>И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?
Да вот так же и обрабатывает :)
Есть пара толстых стораджей с 4Тб рейдами.
Ну, пара лет уже как, но ни разу полный чек не потребовалсо.
Обычная ext3.
| |
|
|
9.56, _Nick_ (ok), 16:42, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | ls -l my_file -rw-r--r-- 1 root root 1048577048576 Mar 11 05 40 my_file конеч... текст свёрнут, показать | |
|
|
7.52, BayaN (ok), 15:39, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Ну для начала в большинстве Linux овых ФС есть журналирование Во-вторых часть д... большой текст свёрнут, показать | |
|
8.54, Аноним (-), 15:59, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | COW в ZFS не копирует неизмененные блоки, а только меняет метаданные на измененн... большой текст свёрнут, показать | |
|
9.58, BayaN (ok), 17:41, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Ну ещё бы она копировала то, что уже и так на диске Чтение не составляет пробле... текст свёрнут, показать | |
|
|
7.67, Michael Shigorin (ok), 20:22, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке?
Журнал, как обычно.
>И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?
Нормально себе отрабатывает. И многотерабайтные с непомнюсколькофайлов -- тоже. Причём очень давно: в 2003 вовсю стораджи со специализированным дистрибутивом на базе ALT Linux с XFS и управлением томами разбирали :)
| |
|
|
5.43, Кирилл (??), 14:34, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Я правильно понял? :-D
Не знаю. Видно, что с пониманием у тебя по жизни не лады.
| |
|
|
3.37, Аноним (-), 13:36, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Есть хоть какие-то шансы, что во фре появится быстрая FS? Без этого
>пусть хоть в 2 раза быстрее аллокатор будет, в реальной жизни
>FreeBSD будет в аутсайдерах.
реальная жизнь это не только PC-серверы, а еще и embedded хотя бы. Не везде нужна такая FS как zfs.
>ZFS ещё совсем сырое и по дизайну мегатормозное.
сравни версию во фре и в солярке. Но тормозит скорее всего у тебя интерфейс между стулом и компьютером.
> UFS2+SU?
нет, просто ufs2 на gmirror или gstripe. softupdates - это вообще отдельная "веселая" песня.
> при количестве inode-ов в 40млн
а зачем тебе столько inode'ов? язык чесать?
| |
|
4.39, Юзеръ (ok), 14:17, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Во-во На этот случай нужна простая и легкая FS и желательно быстрая UFS тут топо... большой текст свёрнут, показать | |
|
5.41, Аноним (-), 14:32, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит
>по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое
>... не пахнет" :\
Что ты будешь делать, если накроется журнал? Молиться на btrfs (ака vapourware от orcale'а)?
для больших объемов есть FS с checksum'ами типа ZFS, HAMMER, NILFS, GPFS и тп. А вот JFS и XFS в пролете.
Журналирование можно сделать и в VM, т.е. заюзать GJournal, и не использовать fsck. Но полагаться на журнал - это, конечно, плевать на все, кроме ребутов/зависаний. Если начнет глючить контроллер или драйвер, то как тебя твой журнал спасет?
| |
|
6.44, Аноним (-), 14:36, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Журналирование можно сделать и в VM, т.е. заюзать GJournal, и не использовать fsck.
sorry,
Gjournaled file system has to be fscked, but only to handle orphaned
files. Such fsck on multiterabyte provider takes seconds, not hours.
| |
6.47, _Nick_ (??), 15:21, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Если начнет глючить контроллер или драйвер, то как тебя
>твой журнал спасет?
када глючит железо - надо его менять, а не выбирать ФС "понадежнее".
Винт может глюкнуть так, что больше не определится даже в биосе.
Так что, нужно на журналирование забивать из-за этого?
| |
|
7.49, Аноним (-), 15:30, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>када глючит железо - надо его менять, а не выбирать ФС "понадежнее".
железо не вечно и backup никто не отменял, однако добавить к этому еще и надежную фс как ZFS не помешает
>Винт может глюкнуть так, что больше не определится даже в биосе.
>Так что, нужно на журналирование забивать из-за этого?
это наоборот, повезло, т.к. ты узнаешь, что данные испорчены и может заюзать backup. А что ты будешь делать с silent error? Как от этого тя спасет журнал? checksum'ы помогут восстановить копиую из резерва или пометить файл как содержащий ошибку.
| |
|
8.51, Аноним (-), 15:33, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | речь о комплексной политике обеспечения надежности Полагаться на один журнал, н... текст свёрнут, показать | |
|
9.59, odmin (ok), 17:47, 11/03/2008 [^] [^^] [^^^] [ответить] | +/– | Бред А ОЗУ заглючит или винт начнет вылетать, никакое ZFS не спасёт Тогда смыс... текст свёрнут, показать | |
|
|
11.79, odmin (ok), 05:59, 12/03/2008 [^] [^^] [^^^] [ответить] | +/– | И как поможет IO checksum ОЗУ или винт начали мусор гнать, zfs увидело ошибку,... текст свёрнут, показать | |
|
|
11.78, odmin (ok), 05:52, 12/03/2008 [^] [^^] [^^^] [ответить] | +/– | Я больше доверяю инфе с freebsd-stable , чем анонимным аналитикам с опеннета В ... текст свёрнут, показать | |
|
|
|
|
7.85, Кирилл (??), 10:13, 12/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> када глючит железо - надо его менять, а не выбирать ФС "понадежнее".
Знать бы когда оно решит глючить. ZFS в этом плане очень удобное решение.
| |
|
6.69, Michael Shigorin (ok), 20:39, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Если начнет глючить контроллер или драйвер, то как тебя твой журнал спасет?
Так, для справки: замечено, что при битой (разогнанной, перегретой...) памяти у людей xfs отваливало систему в ro с внятной руганью в лог.
Про развал журнала пока только слышал, но "не фонтан". Самому сталкиваться не доводилось.
Кажется, там рейд с батарейкой суппорт радостно дёргал по питанию (то ли на агаве, то ли на мастерхосте).
| |
|
5.73, nuclight (ok), 22:11, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>> при количестве inode-ов в 40млн
>>а зачем тебе столько inode'ов? язык чесать?
>
>А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит
>по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое
>... не пахнет" :\
А причем тут емкость HDD, а? покажите мне df -i хоть с одной промышленной системы, где есть разделы с более чем миллионом файлов.
| |
|
6.75, Michael Shigorin (ok), 23:14, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>покажите мне df -i хоть с одной промышленной системы,
>где есть разделы с более чем миллионом файлов.
До кластера отсюда не дотянуться :), а из того, что поближе --
/dev/mdN xfs 890M 986K 889M 1% ~ftp
/dev/mdK xfs 110M 324K 109M 1% ~ftp/pub/Linux/ALT
| |
|
7.82, nuclight (ok), 09:06, 12/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>покажите мне df -i хоть с одной промышленной системы,
>>где есть разделы с более чем миллионом файлов.
>
>До кластера отсюда не дотянуться :), а из того, что поближе --
>
>
>/dev/mdN xfs 890M 986K 889M 1% ~ftp
>/dev/mdK xfs 110M 324K 109M 1% ~ftp/pub/Linux/ALT
Ну и? Оба раздела не превышают даже ОДНОГО миллиона. Тогда как в исходном посте говорилось про 40.
| |
|
6.76, fedya (??), 02:20, 12/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
> А причем тут емкость HDD, а? покажите мне df -i хоть с одной
> промышленной системы, где есть разделы с более чем миллионом файлов.
[root@lxwdc1 ~]# df -ih
Filesystem Inodes IUsed IFree IUse% Mounted on
[...]
/dev/mapper/VolGroup01-LogVol00
2.5G 129M 2.4G 6% /mnt/aoe1
| |
|
7.84, nuclight (ok), 09:13, 12/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
> [root@lxwdc1 ~]# df -ih
> Filesystem
> Inodes IUsed IFree IUse% Mounted on
>
> [...]
> /dev/mapper/VolGroup01-LogVol00
>
>
> 2.5G 129M 2.4G 6% /mnt/aoe1
Хм. А что у вас там лежит, на такое количество файлов? И какая вложенность каталогов?
| |
|
8.92, fedya (??), 22:08, 12/03/2008 [^] [^^] [^^^] [ответить] | +/– | Это e-discovery NAS http en wikipedia org wiki Data_processing_architecture_... текст свёрнут, показать | |
|
|
|
|
|
3.60, fedya (??), 17:59, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
> Вчера вычитал в рассылке freebsd-stable@
Дайте, пожалуйста, ссылку...
> Для проверки террабайтной UFS2 fsck надо гиг ОЗУ, причём в kernelspace, соответственно,
> надо /boot/loader.conf править и перегружаться.
Это странно, fsck работает в userspace и использует своп если ей надо. fsck *может* потребоватся гиг виртуальной памяти на терабайт диска, но это не обязательно, зависит от параметров файловой системы. См. http://groups.google.com/group/lucky.freebsd.fs/browse_thread/thread/d69ac01f
Для сравнения, полная проверка 15T xfs c дефолтными настройками на CentOS 4.5 у меня заняла 26 часов и 18 гиг памяти. XFS, кстати, не поддерживает бэкграунд чекинг.
| |
|
4.77, Wulf (ok), 02:29, 12/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Вчера вычитал в рассылке freebsd-stable@
>Дайте, пожалуйста, ссылку...
Вероятне всего, имеется ввиду следующий тред:
http://groups.google.com/group/lucky.freebsd.stable/browse_thread/thread/c348
Кстати, "матерый бздун Oliver Fromme" там и повторил, что при дефолтных newfs-ных параметрах для fsck на 1ТБ UFS2 надо 1G памяти, только в userspace. Естественно, совет добавить памяти им был дан для ускорения fsck, дабы последний не лез в swap. Я могу предположить, что проблема озвученная в треде была вызвана банальным неподмонтированым swap-ом в single user mode.
Не про какую необходимость правки /boot/loader.conf и перезагрузку там и не упоминалось. Только топикстартер зачем-то прописал бесполезные параметры kern.maxdsiz и kern.dfldsiz, которые обычно осью определяются правильно. Но это его собственные тараканы. Могу напомнить что кол-во памяти для ядерного malloc, т.е. фактически kernelspace выставляется через vm.kmem_size и vm.kmem_size_max, но на fsck не особо влияют.
Как резюме, можно посоветовать гражданину Одмину учить английский вместо олбанского, может тогда хоть смысл текста начнет понимать.
| |
|
3.66, nuclight (ok), 19:50, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
Не, а кто чуваку виноват, что он отформатировал такой большой раздел с дефолтными параметрами. У людей вон есть UFS2 на 6 терабайт нормально отформатированная есть, и ничего, fsck работает. Что предложили вытащить - а что еще советовать чуваку, если он уже в ситуацию попал? Убиться об стену? Неконструктивно.
>ZFS ещё совсем сырое и по дизайну мегатормозное. GJOURNAL ещё сырое.
Ага, все умрем. Не все так печально. ZFS считается экспериментальной, и кстати довольно быстрой. И для экспериментальной FS у нее весьма высокая надежность. Плюс - класс задач - терабайты не везде нужны пока. У меня вот 300-гиговый раздел на UFS2+SU проверяется за считанные секунды.
| |
|
|
1.3, sauron (??), 20:10, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
О том что аллокатор памяти в libc фиговат для потоковых приложений известно давно.
| |
|
2.72, Michael Shigorin (ok), 20:50, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>О том что аллокатор памяти в libc фиговат для потоковых приложений известно давно.
Да он и вообще до недавних пор (e.g. в glibc-2.5) был не сильно-то адекватен текущему положению дел в linux-2.6 :(
| |
|
1.4, BayaN (ok), 20:21, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>FreeBSD 7.0 does not support the MFS file system; the nearest alternative is the tmpfs filesystem which was used for this test.
Понравилось сравнение тёплого с мягким, ближе просто некуда. Добавил бы тогда NetBSD с tmpfs для интереса.
| |
|
2.16, Аноним (-), 23:10, 10/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>FreeBSD 7.0 does not support the MFS file system; the nearest alternative is the tmpfs filesystem which was used for this test.
>
>Понравилось сравнение тёплого с мягким, ближе просто некуда. Добавил бы тогда NetBSD
>с tmpfs для интереса.
Согласен. И вообще, это когда MFS исключили из 7-ки? tmpfs же все еще экспериментальная (как и zfs)...
| |
|
1.6, terminus (ok), 20:32, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Диллон только обещает. Весь kerneltrap.org исписал, писатель... Посмотрим что он там со своим Hammer сделает.
| |
1.7, _Nick_ (ok), 21:25, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
нечесный тест.
Берет Бздю в карренте - брал бы и 2.6.25-rc4/5 ядро.
А так - очередной бойан
| |
|
|
|
4.14, _Nick_ (ok), 22:01, 10/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
да ты хоть по ссылке сходи.
Первый де график - FBSD-8.0 и Fedora с 2.6.24
бойан
| |
|
5.15, PereresusNeVlezaetBuggy (ok), 22:08, 10/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>да ты хоть по ссылке сходи.
>Первый де график - FBSD-8.0 и Fedora с 2.6.24
>
>бойан
Ыыы, просто само тестирование меня самой своей идеей не впечатлило, изучать не стал. :( Впрочем, если я не ошибаюсь, там действительно аллокаторы одинаковые...
| |
|
|
3.13, Аноним (-), 21:50, 10/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Это на Опеннет ее очередная опечатка:
>
>"The following graph compares FreeBSD 7.0 and Linux 2.6.24+glibc 2.7"
Не опечатка, тестировали именно FreeBSD 8, читайте дальше пояснение к графикам:
"This graph shows FreeBSD 8.0 but FreeBSD 7.0 does not perform substantially differently"
| |
|
|
1.8, Аноним (23), 21:29, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Нравится тенденция тестирования DragonflyBSD вместе с другими системами. По всем тестам она сливает просто катастрофично. Надеюсь, Диллон одумается и закроет проект, а полезные наработки типа hammer и vkernel перенесет на FreeBSD CURRENT. Ибо DF чуть менее, чем полностью бесполезная трата времени разработчивов. PS. Еще умиляют местные защитники DFBSD, которые сами ее не используют :)
| |
|
2.11, PereresusNeVlezaetBuggy (ok), 21:41, 10/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Нравится тенденция тестирования DragonflyBSD вместе с другими системами. По всем тестам она
>сливает просто катастрофично. Надеюсь, Диллон одумается и закроет проект, а полезные
>наработки типа hammer и vkernel перенесет на FreeBSD CURRENT. Ибо DF
>чуть менее, чем полностью бесполезная трата времени разработчивов. PS. Еще умиляют
>местные защитники DFBSD, которые сами ее не используют :)
Блин, ну вам-то лично чем эта ОС мешает?! Я её тоже не использовал напрямую, но при этом я пользуюсь мелкими и не очень наработками, которые приходят именно из этой ОС. И то, что они приходят именно из DragonFly BSD говорит о том, что именно организация разработки этой ОС лучше всего подходит для появления данных конструкций (драйверов, например).
И не надо говорить, что разработчики DragonFly BSD лучше бы пригодились в других проектах. Во-первых, если бы им лучше работалось в других проектах, то они работали бы в других проектах, а там, где им лучше работается, там и результаты лучше (поскольку ОС открытая, то польза, опять же, всем - см. выше). А во-вторых, вы предпочитаете конкуренцию или моно-/олигополию?
Если честно, я снимаю шляпу перед разработчиками DFBSD, что они взялись за этот проект, когда рынок, казалось, уже давно был поделен.
Ну а насчёт того, что 4.x устарело - надоело, чесслово. Если для вас важнее то, что появилось только в 5.x/6.x/7.x - то пользуйтесь, пожалуйста, никто вам не мешает! Но, пардон, обсирать-то других зачем?! Глупо выглядит, а вовсе не понтово.
| |
|
|
2.25, terminus (ok), 10:52, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>После тестов SMP нет доверия к этому товарищу.
Nick Piggin гонял недавно на ванильном 2.6.25-rc4, а Kriss тогда еще гонял на 2.6.23. При чем тут доверие, просто те тесты MySQL устарели...
А вообще прикольно наблюдать за этими товарищами. Ждем ответ от Nick Piggin =)
| |
|
3.38, Аноним (-), 13:42, 11/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
> А вообще прикольно наблюдать за этими товарищами. Ждем ответ от Nick Piggin =)
А бенчмарки без политики не бывают. ;)
| |
|
|
1.87, fsck (??), 10:34, 12/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
да уж линух
помниться знакомым занимающимся железом притянули винт который толи начал сыпаться толи еще что то
но линухоид с ним ничего сделать несмог
я при этом присутсвовал(когда принесли и обясняли проблему)
хардовики протестили и сказали проблемы с винтом нет
эт где то на уровне операционки
ну линуха под рукой небыло
запустил bsd 4
прочекал ее bsd шным fsck
она там все пофиксила
винт вернули линухоиду......
он аж плакал - поскольку там был биллинг и вся статистика за несколько лет по клиентам
вот
а вы кричите линух линух....
| |
|
2.89, Анонимускун (?), 18:27, 12/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
кто ж знал, что ты такой идиот и будешь использовать fsck_ufs или fsck_ffs вместо fsck.ext2 или fsck.ext3 (из комплекта sysutils/e2fsprogs)
ССЗБ!
| |
|
1.91, Аноним (91), 21:35, 12/03/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
если бы небыл идиотом то понял бы что так и было
или мне каждому идиоту разжопывать и в рот пихать?
| |
|