>>>>Кстати, BSD на одном POSIX не остановились, не надо;)
>>>Я и не имел в виду этого.
>>Тогда к флейму "BSD vs. Linux" это не имеет отношения:).
>
>А к обсуждению с применением логики -- имеет. :)
>
>По поводу стандартов, реализаций и остановок -- а с SUSv3 в FreeBSD
>сейчас как обстоит? Боюсь, тут мне быстро не ответить - за FreeBSD я не настолько активно слежу. Надо копаться в архивах standards@... В OpenBSD недавно провели ревизию и обновили API (точнее, CRT), точнее надо будет поглядеть в свободное время.
>>Идеология Linux (не декларируемая, а фактически получающаяся) - "стандарты, это,
>>конечно, хорошо, но мы знаем, как лучше". Иногда это оправдывает себя. Иногда -
>>нет.
>
>Да, как и в MS. Главное отличие -- установка открытых стандартов
>де-факто vs закрытых с.д-ф.
Угу. Это, конечно, облегчает, при необходимости, написание аналогичной реализации (т.к. GPL-ную инкорпорировать нельзя). Но всё равно приходится подстраиваться под довольно динамичную систему, в отличие от стандартов, которые определяются обычно всерьёз и надолго.
>>>Э, не -- autocrap вовсе не из/для Linux родился, не надо.
>>Не из и не для. Но волею судьбы это получился самый распространнёный
>>(хотя, к счастью, не единственный, достаточно вспомнить тот же CMake)
>
>Недавно фиксил детские ошибки в scons и тихо удивлялся...
>http://fly.osdn.org.ua/~mike/tmp/scons-0.97-alt-as-needed.patch
Текстовая консоль (в широком смысле этого слова, т.е. линксовый фреймбуфер тоже) - это вообще больное место всех никсов.:( Есть портабельные, есть функциональные, есть надёжные - выберите не более двух:). Впрочем, это больше с чужих слов, так как с нестандартными архитектурами сталкиваюсь очень редко, а ковыряться в исходниках всех этих консолей ещё не приходилось...
>>вспомогательный софт, помогающий портировать приложения между разными ОС,
>>в том числе между Linux и BSD.
>
>Но вот как раз его тащить в такое обсуждение смысла и не
>нашёл. Работает -- и ладно.
С появлением всё большего количества нюансов, которые обладают разными побочными эффектами и имеют порой различные взаимозависимости, autotools всё сложнее заставлять работать так, как надо. Собственно, различны системы портов (packages в NetBSD) делают то, что изначлаьно должны были делать эти autotools. А это значит, что не слишком хорошо они работают...
>>>И насчёт губительности -- не могу согласиться, превращение в окаменелость с
>>>надменным видом куда уж губительней.
>>Если честно, мне сложно назвать BSD окаменелостью.
>
>Если бы относил высказывание именно к BSD, написал бы "...навроде *BSD".
>Здесь скорее подразумевал "классические UNIX", которые проморгали своё вымирание.
Кто-то всегда вымирает. Ce la vi :)
>>Но зато непроработанных до конца моментов меньше.
>
>Ну таких фразок с неясными определениями "проработанности" и "до конца" и я
>могу настрогать бегом. :)
Можно и на примерах. Одна пересборка ядра Linux уже давно стала присказкой:). В OpenBSD и FreeBSD у меня пока ни разу не было проблем. Редко когда у меня получалась некомпилируемая конфигурация, да и то было достаточно отцэвээситься через пару часов.
Про sysinstall во FreeBSD промолчу (дерьмо редкостное на самом деле, только недавно ним неуставные отнношеия из-за попытки сделать раздел, выходящий за границу 2 ТБайт), но если система поставилась - значит, она поставилась и работает. С *BSD у меня ни разу не было, чтобы, скажем, Иксы отказывались стартовать в дефолтной конфигурации, даже в -CURRENT. И я всегда контролирую с самого начала, что у меня и откуда грузится, в то время как большинство дистров сразу стартует кучу непонятной фигни, в которой ещё пойди разберись, что за что отвечает и что с чем взаимосвязано... Больше того, я сейчас постоянно живу на OpenBSD-CURRENT, пользуясь shapshot'ами, и ещё ни разу не попадал в ситуацию, когда система перестала бы после очередного обновления работать или какие-то программы начинали глючить. В то время как от знакомых линуксоидов (людей ничуть не глупее меня) не раз слышал жалобы про кривые обновления - и это в стабильных ветках!
Зато Linux, как правило, оказывается быстрее, это да. Иногда даже заметно быстрее. Это позволяет экономить деньги на оборудовании. И ещё свежие железки обычно раньше всего начинают работать под Linux. И родная Java под Linux работает относительно неплохо, в отличие от BSD, где приходится накладывать кучу патчей, адаптирующих исходники к реалиям отличных от Linux систем (а без Java порой никуда, к сожалению)...
>Если о функциональности речь -- то вопрос в том, что и когда
>уже готово для работы. По крайней мере с моей колокольни.
И ещё в том, что считать "готовым для работы". Одно дело "пипл хавает", другое - "чтобы не падало".
>>надеюсь, не надо пояснять, почему никакая система тестов не заменит полноценный
>>анализ качества кода?
>
>Дык. Только вот анализ требует человеко*времени*квалификации, см. выше по обсуждению насчёт
>бизонов и цепочек.
Никто не спорит, что требует. А ещё он требует желания это делать - можно нанять сколько угодно аналитков, которые будут просто гонять... мяч по футбольному полю, ага. В таких случаях "идейные" люди выдают лучший результат...
>>Ещё несколько лет назад я общался с RH, Mandrake, ALT и ещё
>>чем-то, а сравнительно недавно - Kubuntu и вариацией OpenSUSE. Ото всех
>>дистрибутивов осталось впечатление "недоделанности".
>
>Я помню два линуксовых дистрибутива, от которых его не оставалось -- Black
>Cat 6.02 и альтовский Linux-Mandrake RE Spring 2001. Всё было
>просто на местах и работало.
Black Cat - хмм... Слышал, но руки так и не дошли посмотреть...
>>Когда же я попробовал свою первую в жизни BSD-систему (в то время я ещё мог себе
>>позволить выбирать софт, а не использовать то, что есть), там было скорее ощущение
>>нехватки функционала. Весь вопрос в том, что легче исправить:)
>
>Как-то видел фото -- запорожец, которому всунули битурбо от ауди. Правда,
>ещё подвеску перебрали. Так и тут -- иной функционал сверху-то
>можно относительно дёшево присобачить, да чтоб с места стронулся, надо ещё
>инфраструктуру перепахивать.
Зачастую инфраструктуру как раз приходится перепахивать для того, чтобы 95% надёжности превратить в 100% (без оглядки на форс-мажор, ессесно). Просто потому, что при закладке этой инфраструктуры был использован не академический ("предусмотреть всё возможное") а инженерный ("работает здесь и там, вот и хорошо") подход. ;)
Присобачить что-то новое в *BSD обычно легче как минимум за счёт лучшего качества документации.;) По моему скромному опыту, за man'ами в Linux никто особо не следит... Гуглить - это конечно, хороший совет, но только если систему уже удалось заставить работать и выходить в инет.;)
>Смотря какая нехватка ощущалась...
Ну как это какая - сайты на Flash глючили, и Unreal Tournament не запускался :))) (с тех пор Flash стал нормально работать, спасибо Gnash, а про игры просто забыл думать). Пожалуй, главное отставание *BSD сейчас - это нативная работа с потоками (слишком всё сложно, особенно в связи с существованием тех же стандартов, зачастую не проговаривающих какие-то важные моменты в этом взаимодействии), FreeBSD с LinuxThreads идёт особняком; отсутствие портов для некоторых распространённых в мире приложений (тот же злосчастный Oracle как пример); отсутствие лёгких в использовании локализованных инсталяторов (не знаю, правда, как сейчас у PC-BSD с этим). Я что-то упустил? :)
>>Просто очень хорошо понимаю, что BSDL - манна небесная
>>для небольших компаний, у которых нет денег судиться с теми, кто
>>наедет за нарушения GPL, а также не могут себе позволить открывать
>>исходники доработанной ими системы
>
>Ну и кому эти лузеры сдались?
Из вот таких вот "лузеров" родилась, например, компания, в которой я сейчас работаю, один из крупнейших хостеров Рунета. На FreeBSD, кстати:). Или вы отрицаете малому бизнесу в ИТ-сфере в праве на существование?
>PS: спасибо :)
Ээээ... Не за что :)))
