|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alex Semenyaka 2:461/640.640 01 Sep 2005 12:14:42
To : Valentin Nechayev
Subject : Passive FTP
--------------------------------------------------------------------------------
01 Sep 05 10:54, you wrote to Gleb Smirnoff:
VN> База использующих OpenSSH уже в сотни раз больше чем установленных
VN> OpenBSD. А, может, и в десятки тысяч - за счёт линукса во всех
VN> видах.
Мне виндузятники продемонстрировали последний Windows 2003 какой-то там сервер.
В котором в штатной, по их словам, поставке, наличествует OpenSSH. Так что
можно ожидать взрывного роста базы этого самого OpenSSHа...
GS>>>> Вот финансирование и запретит скажем Опперману работать над
GS>>>> prefetching, и прочими оптимизациями. Мол текущий IP стек и так
GS>>>> намного более производителен, чем требуется для commodity OS, не
GS>>>> надо его трогать.
AS>>> С чего бы это? Это как раз уже вопрос реализации одной из
AS>>> бизнес-моделей.
VN> С того, что любое подобное изменение - это 1) глюки,
Правильно, любое изменение - это глюки. Волков бояться - в лес не ходить. Любая
живая система меняется, это чревато глюками - и что? :)
VN> 2) изменение функциональности (наверняка в некоторых вопросах
VN> несовместимое),
Аналогично.
VN> 3) необходимость править документацию. Документацию
VN> - ко всем требованиям к *нормальной* системе документации, а не к
VN> сочетанию одного плоского мана с невнятной писулькой в
VN> /usr/share/doc - тоже Опперман писать будет?
А ты много встречал людей, которые по доброй воле садятся и пишут доки? Это как
раз та область, где для получения качественного результата требуется платить
денежку.
С другой стороны, если денежку не платить, то код будет, а документация будет
как обычно. Собственно, тоже ничего особо страшного.
Это я к тому, что гранулярность уровней внутреннего финансирования может и
должна быть высокой.
VN> А тестинг (нормальный, а не как для free OS) он профинансирует для
VN> проверки своих оптимизаций?
А тестинг должен быть организован грамотно, общим образом, вне зависимости от
наличия Оппермана. И это опять вопрос финансирования.
VN> Ставлю ящик водки на то, что в ответ на подобные запросы он пошлёт
VN> нахрен (если не дальше) и на этом всё закончится.
Это смотря как спросить, думаю. Если написать - "Андре, тут есть мысль
потратить 300 килобаксов на твой проект, но нужно, чтобы была вот такая вот
дока и вот такое тестирование - какие мысли, как организовать?" - то, думаю,
всё сложится. Второй вопрос, что я такой вопрос могу задавать только если у
меня и правда есть эти $K300.
AS>>> Многократно обсуждалось (в том числе кем-то из Взрослых Дядек :) ),
AS>>> что для подобных проектов она строится совсем по другим принципам.
AS>>> Пусть себе Опперман крутит экспериментальную ветку, это его святое
AS>>> право. А Джон Смит с Васей Пупкиным должны сделать h323-прокси для
AS>>> ipfw, потому что потребитель хочет. И им за это положена денежка.
AS>>> Потому что все понимают, что Оппермана или phk засадить делать что
AS>>> им не нравится, но за денежку - не выйдет.
VN> Да, вопрос не в деньгах. Вопрос в том, что в мире хакеров (в
VN> реймондовском смысле) "сделать" - это значит написать код. А в мире
VN> промышленных систем "сделать" - это значит сделать продукт, начиная
VN> от кода и заканчивая обложкой коробки, в которой будут лежать
VN> компакты с инсталляшкой, "getting started" и EULA. И кому тогда
VN> будут нужны те экспериментальные ветки Оппермана, phk и прочих?
А у нас одна ветка FreeBSD? :) Это как раз и есть вопрос организации продукта.
VN> Закончится тем, что они уйдут в очередной СтрекозёлBSD и будут там
VN> вести свои работы, а остальные будут у них драть что понравилось
VN> (но с соблюдением всех правил промышленной разработки).
А вот это - как организовать работу.
VN> Поэтому, деньги на поддержку систем типа FreeBSD должны, IMO,
VN> даваться не на суперпроекты типа "а вывернем-ка мы сейчас наизнанку
VN> IP стек и завяжем его узлом с VFS". А за документацию, за
VN> дружественный инсталлятор, за мелкие, но полезные улучшения,
VN> отсутствие которых просто _анноит_. Если мне вдруг свалится мешок с
VN> деньгами, те %%, которые я отправлю на поддержку фряхи, пойдут
VN> именно туда.
Согласен. Hо... как мне представляется, Core вполне согласно с твоей
постановкой вопроса. И если на фришку будут давать деньги, то лучше давать их в
Core. Можно - с выставлением приоритетов, но без диктата. Тут вариантов масса,
например: вот мешок денег, когда он кончится, вот такие-то точки хотелось бы
видеть, чтобы был следующий мешок. А как конкретно вы содержимое раскидаете и
по каким проектам - дело ваше.
VN> Я вёл в Киеве курсы по FreeBSD. Знаешь, что больше всего обижало в
VN> том, что приходилось рассказывать? Это то, что стандартные системные
VN> умолчания и дефолтные конфиги попросту неприменимы, IMO, для работы.
Знаю. Потому что год назад за подобное тут сгрызли Lleo, собственно. А пришёл
он сюда потому, что ему было неловко постоянно мне названивать и спрашивать - а
почему вот это не работает? А из-за чего вот это глючит?
VN> того. Вот поставь себя на место лектора: какое впечатление ты
VN> оставляешь своим слушателям о системе, о которой приходится
VN> рассказывать, что после установки она пригодна только для того,
VN> чтобы дорабатывать напильником? Когда рядом (и на предыдущих курсах)
VN> они видят Linux, у которого этих проблем нет?
Очень хорошо понимаю, см. выше.
GS>> Чувак, совершенно верно. Мы останемся без prefetching, но зато с
GS>> h323-proxy. Только вот никто не кинется заменять свои Cisco на
GS>> FreeBSD, ибо Cisco уже куплены и работают, да и вообще к тому момент
GS>> можно будет купить h323-proxy от D-Link или Surecom за $20
GS>> баксов. Если постоянно гнаться за фичами, которые нам диктуют
GS>> конкуренты, то никогда не догонишь. К примеру, та же Samba всегда
GS>> будет отставать от Windows. Hо если разрабатывать новые свои идеи,
GS>> то можно добиваться намного большего успеха. Пример такого успеха -
GS>> CARP.
VN> Знаешь, я всё время слышу про этот CARP и не могу понять, чем он так
VN> привлекателен. У меня знакомый - любитель опёнка - хочет разработать
VN> стандартную установку на двух тазах с CARP между ними и
VN> кластеризацией функций стандартных для сервера локалки. И упёрлись
VN> уже начиная с DHCP: репликация базы лизов - задача нетривиальная.
VN> Про другие сервисы вообще молчу: задача кластеризации POP3 может
VN> свести с ума любого админа. Так вот - что в CARP хорошего?
VN> Hадёжность на L3? И всё?
Он для развесистых конфигураций, когда firewall в одном месте, сервисы в
другом/третьем/четвёртом... Словом, ситуация ISP/CSP. Большинству конечных
пользователей оно не очень пригодится, конечно.
Alex
--- IMHO в последней инстанции
* Origin: ...можжевеловых... (2:461/640.640)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
