|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Sergey Skvortsov 2:5020/400 08 Apr 2005 22:49:01
To : Valentin Nechayev
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
Valentin Nechayev wrote:
>
> SS> А главное - несколько странно противопоставлять *BSD между собой - пусть
> SS> уж, как привычно, BSD vs. SysV, ok?
> Hе так.
>
> Q16: что хуже фря или соляра?
> A16: линух популярнее.
Собственно аллюзия была на классику:
"...As far as the differences between BSD and Systems V, that's
simple. System V sucks and BSD doesn't." Curt Welch
> Так в том и дело. И без мьютексов нельзя обойтись, и без сообщений. Вопрос
> только в том, какая схема будет лежать в основе и _как_ она будет лежать.
> И если мьютексная (неважно, с квадратно-гнездовой сериализацией, как в Linux,
> или скользящей, как во FreeBSD5) понятна большому числу народа, то как
> строить без безумного геморроя схемы на сообщениях - знает значительно
> меньше грамотных людей. И тех в основном утянули писать драйвера под NT.
Собственно претензий и поводов для яростных нападок - равно как и
идеалистичных восторгов - к DFBSD быть ну просто не должно. Мне гораздо
интереснее, почему никто не смотрит на NetBSD 2.0, которая существенно
более зрелая и стабильная (и чьи pkgsrc DFBSD в итоге и будет пользовать).
А количество разработчиков... Это по большому счёту тема project
management'а проектов. То эмпирическое правило, что нормальные thread'ы
может сделать только большая коммерческая компания и почти невероятна
для opensource: Solaris/Microsoft vs. FreeBSD/Linux, - так вот это
правило есть следствие несколько более общего - что при росте сложности
проекта сильно вырастает потребность в правильном management'е (надеюсь,
никто не видит в этом слове неприятных коннотатов). И у opensource
project есть потолок в экстенсивном росте.
Любой разработчик opensource тратит на development часть своего времени,
вне (или в ущерб ;) основной работе. Редко всё это совмещается. Как итог
- невозможность адекватного планирования "на сколь-нибудь смешной срок"
даже просто releas'ов (пример - FreeBSD 5), и, уж честно, довольно
сырого результата в итоге.
Другая проблема - проблема роста сложности. Типичный пример - ports tree
в FreeBSD. В таких случаях требуется продуманная стратегия развития.
Package management есть нетривиальная задача, и объединение в pkgsrc
двух ОС будет лишь плюсом (свой новый и уникальный packaging DFBSD не
потянул бы). А гордая и неприступная OpenBSD плетётся где-то сзади.
Проблем второго плана тоже хватает.
Во-первых - дублирование работ. Периодически случается так, что два
developer'а делают одно и тоже. В итоге "остается лишь один" - редко
когда изначально некоординированные подходы можно совместить. Итог -
снижение интереса у "проигравшего" - ему повезёт, если его труд есть
просто выложенная в opensource коммерческая разработка. Иначе -
коллизии. (Или вот скажем вопрос про ABI...)
Во-вторых - отсутствие нормального уровня research'а. Dillon проходится
насчёт того, что все консервативны и все их идеи давно устарели, люди
зашорены и ничего революционного не предлагают. А, скажем, адепты ранее
упомянутых register-based VM (не к ночи будет сказано) - скромно
говорят, что registeres лучше чем stacks, поскольку за последние 30
исследования в теории компиляторов были в основном для register-based
VM. А это простой и весомый довод (если, конечно, не врут). И, при всём
уважении к инновациям, мне система фундаментальных исследований (равно
как и использование их результатов) более мила.
Так что, возвращаясь к DFBSD - быстрый старт и хорошие результаты - не
есть какая-то уникальная особенность именно этого проекта. Уникальным он
станет, если с возрастом бегло описанные выше проблемы он сможет
предотвращать и превентивно решать.
--
Sergey Skvortsov
mailto: skv@protey.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
