> Дебиан сильно отличается от альтлинукса тем, что в нем по минимуму ничего нет и много телодвижений нужно прикладывать, чтобы получить безпроблемный десктоп. Чудес не бывает. Аналогичные системы под альтом и дебианом занимают примерно одинаково места.

ну а в АЛЬТ'е минимума вообще нет. аналогичные системы не занимают одинаковое количество места. Дебиан занимает всегда меньше, конечная система == мин. инсталл + то что надо а в АЛЬТе кончная система == куча-свалка (для которой надо приложить массу усилий, чтобы выбросить лишнее) + то, что надо

оба дистра базируются на apt-get. и с ним установка свежих и просто программ - действие тривиальное. токма вот АЛЬТовский apt - кастрирован малость, да и аналога dpkg-reconfigure в rpm нет, вернее в самом rpm есть, да создатели пакетов его не юзают ради гуевых свистелок/перделок.

>Дебиан лучше для тех, кто любит вычищать дистр от ненужных переводов, документации, локалей. Для широкой гаммы железа, как старого i386, так и редких архитектур.

от это правильно. в системе не должно быть ничего лишнего

> Для сурового сервера (хотя castle все равно рулит)

а особенно на серверах ;)

> Еще хороша в дебиан система зависимостей.

я бы сказал - не система зависимостей, а система разработки. проблема АЛЬТа в том, что нет организованности. очень много споров с АЕН'ом было по этому поводу, но пока безрезультатно. в Дебиане есть строго определенный путь прохождения новых пакетов - обкатка/анстейбл/тестинг/стейбл. пользователь может выбрать какой угодно уровень новизна/стабильность. дистрибутивы по настоящему стабильны, поэтому и сервера суровые можно только на Дебиане делать.

в АЛЬТе дистрибутив формируется из нестабильного репозитария путем его временного "замораживания". стабильное состояние АЛЬТ'а тянет на уровень unstable Дебиана - максимум. причем, чтобы АЛЬТу стать как Дебиану надо немного - так же разграничить репозитарий на несколько веток и все. В АЛЬТ'е идут в этом направлении но не в сторону стабилизации, а в сторону дестабилизации ;) (Дедалус). В итоге когда юзер сталкивается с проблемами в АЛЬТе у него только один выбор: обновиься из Сизифа или этого не делать... в общем выбор хреновый. жалко что много усилий команды тратится впустую: стабильного продукта не получается

> А альтлинукс для тех, кто хочет поставить систему и работать в ней сразу + иметь свежий софт, неплохую совместимость с закрытым софтом,

ну это все у Дебиана есть, только даже лучше (писал выше)

> общаться в больших русских рассылках десктопщиков, иметь возможность сливать свои удачные наработки в мейнстрим популярной в народе команды.

общение - да это сильная сторона АЛЬТа. community@altlinux.ru итд - рассылки, на которые следует подписаться любому кто хочет по русски пообщаться про линукс. а вот насчет слива удачных разработок - жалко что из-за хреновой организации (выше) получается как всегда. ну м.б. и переменится чего со временем. АЕНа пинаем-то постоянно, да и сами кое что поделываем для АЛЬТа, хотя им почти и не пользуемся ужо...

> Каждому свое...

вот и хочется _свое_, родное, русское. поэтому и пинаем мы Вас, помогаем Вам, не загибайтесь ребятки ;)

Ура, даешь спор Дебиан vs АЛЬТ!

Слакваре - фсех парвет!!!!

попробуйте залезть на www.newsru.com и покликать по ссылкам

У меня вываливается :(((

нормально ходит по ссылкам

РХ! всем сосать!

Я ж говорю, каждому свое.
Когда я ставлю basesystem дебиан, то получаю порядк 45 метров пространства и полное отсутствие возможности разобраться в системе, потому что вообще ничего кроме бинарников да одной локали, нет.

В альте минимум, это 145 мегов, но это реально рабочая система со всеми манами, локалями, шрифтами и настройками. Я ставлю альт за двадцать минут в полную боевую готовность.

Для моего рабочего ноута с 486 процом 340 мегов диском дебиан, это хорошо и даже здорово, но для десктопа на атлоне с 10-80 Gb, простите, альт и только альт. Сразу три наши локали весь софт, который нужен.

"Свалка" или не "свалка", но любая оптимизация вылезает боком на универсальном компьютере. Даже в альте зачастую слишком много итераций для установки нужного пакета(ов). Их надо найти, да еще они разбиты на подпакеты. В дебиан просто руки опускаются.

Мне в альте ни один файл не мешается. Зато хочется, чтобы комп работал с МИНИМАЛЬНЫМИ действими и делал МАКСИМУМ возможного. С этой точки зрения альт в выигрыше. Здесь почти все работает сразу.

Насчет 4-6 уровней стабильности - тоже все небесплатно. Дебиан мощнее, но он и неповоротливей и гораздо менее ориентирован на решение проблем русского пользователя. Значит опять напильник, геморрой в простейших случаях и... старый софт.
Unstable на компактах практически не распостраняется и поэтому для большинства дебиан, это в первую очередь, старый софт.

Насчет споров с АЕН. Есть, конечно, и непонимание сути и последствий каких то проблем внутри команды, есть и заблуждения, но их не больше обычного. Глухих и упертых точно нет. :) Остальное, как у людей.

Я начинал с дебиан, продолжаю его использовать и хотел бы увидеть многие черты дебиан в альте, но не все и не любой ценой.

Серверы на альте вполне работоспособны. Особенно сейчас, когда один дебиановец привил к альту новую систему сборки ядра. :)
Хорошее ядро - половина сервера. Когда я увидел, что после долгого периода в новом ядре по умолчанию не декларативно, а по честному включена последовательная консоль - прослезился от умиления :).


О команде: Многое делается для построения девелоперского процесса. Для построения сообщества. Тот же линуксфест, свободные проекты, сизиф. Присоединяйтесь - альт всегда рад вливанию свежей крови. :)

Дебиан vs. ALT

2 AVL2: Наверно у нас разные дебианы... ;-}

1) Что такое базовая установка? Зачем она нужна? У меня есть список пакетов, который я ставлю на сервера, список который ставлю на десктопы и все. И мой личный список.

2) Зачем нужны итерации для установки пакетов? Они и так ставятся со всеми зависимостями. Причем есть развитая система поиска имени пакета.

3) Локали генерируются за несколько секунд/минут какие угодно.

4) Если программа русифицирована, то она русифицирована. Если ее русификацию не берут в upstream то это никому не нужный грязный хак.

5) У нас самый новый софт ;-} У кого нет быстрого интернета находят тех у кого есть и покупают пиво.

6) debian-russian@lists.debian.org приближается к тому моменту, когда его перестанут читать, ибо там уже слишком много сообщений.

>В альте минимум, это 145 мегов, но это реально рабочая система со >всеми манами, локалями, шрифтами и настройками. Я ставлю альт за >двадцать минут в полную боевую готовность. А кто додумался маны на русский переводить? Убил бы гада...

> общение - да это сильная сторона АЛЬТа. community@altlinux.ru итд - рассылки,
> на которые следует подписаться любому кто хочет по русски пообщаться про линукс.
А что, русские рассылки есть только у ALT Linux'а? ;)
Есть весьма неплохие конференции на русском:
debian-russian@lists.debian.org (подписаться debian-russian-request@lists.debian.org?subject=subscribe)
linux@soobcha.org (подписаться linux-on@soobcha.org)
linuxtalk@yahoogroups.com (подписаться linuxtalk-subscribe@yahoogroups.com)

>1) Что такое базовая установка? Зачем она нужна? У меня есть список
>пакетов, который я ставлю на сервера, список который ставлю на десктопы
>и все. И мой личный список.
А у меня слишком разные сервера. Гдето апач, где то с ПХП, гдето сейчас уже зоуп и т.д. Про десктоп вообще молчу. Всю жизнь мечтал составить список, но он постоянно куда то исчезает. Все течет, все изменяется.

>2) Зачем нужны итерации для установки пакетов? Они и так ставятся со >всеми зависимостями. Причем есть развитая система поиска имени пакета.
Это если схватить "за голову". А если это, к примеру, темы? или игрушки, коих штук 50 и естественно, без взаимозависимостей? А devel библиотеки? Каждый раз собираешь, уткнулся в *.h not found, поискал devel, поставил и опят заново на следующий потерянный хидер. Есть виртуальные пакеты, частично снимающие напряженность, но полностью это не решаемо. Гибкость в установке минимума дается совсем не даром.

Спасибо дебиан. apt-get & apt-cache вещи хорошие, но и недостатки их тоже нам известны :)



>Если программа русифицирована, то она русифицирована. Если ее
>русификацию не берут в upstream то это никому не нужный грязный хак.

Пуст так. Но я не сноб. Если ru.po прикладывается в альте, а не в апстриме (а это бывает на так редко, как того хотелось бы), то я предпочитаю именно эту сборку другим. А как быть с rox, который не апстрим не хочет допиливать для работы в non utf8 локалях? Допиливаем сами. И еще много чего такого, чего в дебиан непройдет, но нам то все равно нужно.


>У нас самый новый софт ;-} У кого нет быстрого интернета находят тех
>у кого есть и покупают пиво.

Я бы все таки хотел, чтобы страна не бегала за пивом и быстрым интренетом, а как то решилось это у нас б/м цивилизованно. Чтоб в каждом городишке была возможность заказать за посильную плату поезд с дисками... :)

>6) debian-russian@lists.debian.org приближается к тому моменту, когда
>его перестанут читать, ибо там уже слишком много сообщений.
Не знаю, как сейчас, а раньше там были, в основном, серверные гуру. А мне хотелось и хочется еще и нормальный десктоп.

>>а компилить то зачем?? что не так с ихними сборками? или сборками Alt Linux?

Мозилла от альтлинукса??? Убереги Боже....

>>2) Зачем нужны итерации для установки пакетов? Они и так ставятся со всеми зависимостями. Причем есть развитая система поиска имени пакета.

>Это если схватить "за голову". А если это, к примеру, темы? или игрушки, коих штук 50 и естественно, без взаимозависимостей? А devel библиотеки? Каждый раз собираешь, уткнулся в *.h not found, поискал devel, поставил и опят заново на следующий потерянный хидер. Есть виртуальные пакеты, частично снимающие напряженность, но полностью это не решаемо. Гибкость в установке минимума дается совсем не даром.

>Спасибо дебиан. apt-get & apt-cache вещи хорошие, но и недостатки их тоже нам известны :)

Авел, если в АЛЬТе с этим геморрой, и ты при сборке ищешь *.h итд то это не значит что и в Дебиане то же самое. в дебиане перед сборкой пакета надо сказать:

apt-get build-dep <имя пакета>

и он поставит все что требуется для сборки.

кроме того в Дебе есть еще apt-src, с помощью которого сильно упрощается установка (сборка) пакета с unstable на sable

так что гибкость в установке минимума не нарушена...

Re:

> А кто додумался маны на русский переводить? Убил бы гада...

Ну, насколько я понимаю, почин был дан Виктором Вислобоковым и Алексом Махоткиным. Убивать их за это? Гхм... А что не так с манами по-русски?

Видимо то что они на русском!

Re:

Э-э-э, то есть, какие к _этому_ претензии? Или мсье - ненавистник русского языка? Дык, эта, странное место и странный способ это обнаруживать :-)

>apt-get build-dep <имя пакета>
в альте тоже самое.
Вот только эти зависимости в пакетах обычно я и ставлю, потому что альтовые пакеты пересобирать смысла нет, а в тарболах зависимостей нет. :)

насчет русских манов -товарищи переводчики уж очень однобоко подошли. маны корявы и читаются плохо. такое впечатление что переводили переводчиком автоматическим слово в слово и подправляли слегка. мало быть просто переводчиком, нужно еще и предметную область понимать слегка, а там этого не чувствуется совсем...

> Ещё очень хочется увидеть примеры "многих нарушений Unix стандартов"...

А ты попробуй собрать это убожество в UNIX. Ну не нравится разработчикам Mozilla стандартный make. Им обязательно gmake подавай со всеми его нестандартными наворотами. Собственно поэтому я и назвал Mozilla GNU-сным.

>Ну не нравится разработчикам Mozilla стандартный make.

Опять этот болван вылез, неспособный собрать gmake...

Разве есть "стандартный make"?! Ах да, он в "стандартном Unix", которого тоже нет, зато на него есть копирайт :)))

GNUтый gmake славен уже только тем, что он вовсе не просто переписанный по "идеологическим" причинам make, но часть системы autoconf/automake, обеспечивающую недостижимую ни для каких других сборщиков кросплатформенность.

пля ну подскажите наконец ссылку где можно узнать чем RC2 от RC3 отличается... :(

> > Ну не нравится разработчикам Mozilla стандартный make.
>
> Опять этот болван вылез, неспособный собрать gmake...

А ты не нервничай, нервные клетки не восстанавливаются.
Ты мне лучше скажи, нахера я буду gmake собирать если он мне
(кроме как для Mozilla) не нужен? У меня и так стандартный make есть
и для сборки абсолютного большинства программ его хватает.

> Разве есть "стандартный make"?! Ах да, он в "стандартном Unix",
> которого тоже нет, зато на него есть копирайт :)))

Ну почему же, в FreeBSD есть стандартный make и не только там, и даже
не только в *BSD.

> GNUтый gmake славен уже только тем, что он вовсе не просто
> переписанный по "идеологическим" причинам make, но часть системы
> autoconf/automake, обеспечивающую недостижимую ни для каких других
> сборщиков кросплатформенность.

А я всегда думал, что отличительная черта UNIX - это портабельность.
Иначе, для чего стандарты существуют?

> пля ну подскажите наконец ссылку где можно узнать чем RC2 от RC3 отличается... :(

А тебе зачем? Если ты принимаешь участие в разработке, то и так знать должен. А если не принимаешь, то жди релиз. Нахера тебе RC*'s?

2speer:
> обеспечивающую недостижимую ни для каких других сборщиков
> кросплатформенность.
Эт ты зря так. Ant по части кроссплатформенности и фичастости уделает make и gmake вместе взятых.

> А тебе зачем? Если ты принимаешь участие в разработке, то и так знать должен. А если не принимаешь, то жди релиз. Нахера тебе RC*'s?

Интересно, что делают в целом. Качать/ставить я его не собираюсь. Вообще зачем тогда постить новости типа RC1/RC2/RC3 если непонятно в чем разница.

туева хуча софта требует именно gmake, а зачастую еще и автоконф нестарой версии. поставить gmake дело <5 мин и смысла разводить антимонии по поводу идеологической верности я не вижу. gmake это существенное развитие make и его в любом случае полезно иметь. не нравится мозилла или ее способ сборки - не юзай - всего делов то. а то использовать да хаять на каждом углу - любимое дело

>>>У меня и так стандартный make есть и для сборки абсолютного большинства программ его хватает.

Стандартного make нет. Как нет и "стандартного Unix". Кроме gmake есть другие make-подобные средства и есть вовсе ему не подобные, например в VisualStudio... Разные проекты выбирают то, что им больше подходит, иногда и своё пишут-добавляют (Qt). Удавись, если тебе это не нравится.

>>>Ну почему же, в FreeBSD есть стандартный make

И как-кем-чем он стандартизован?

>>>А я всегда думал, что отличительная черта UNIX - это портабельность.

Неправильно думал, тупо думал, обманулся на словах, не разобравшись со смыслом, историей и реальным положением дел...

1. "Портабельность" была ЦЕЛЬ, которую ХОТЕЛИ достичь отцы C и Unix. Причем портабельность они понимали сначала как ЖЕЛЕЗНУЮ кросплатформенность - то есть переносимость ядра и основных утилит с относительно небольшими их переделками и перекомпиляцией для разных архитектур. Эту цель они достигли, но не до конца - по их собственным оценкам.

2. Кросплатформенности (особенно на уровне приложений) чуть было не был положен конец коммерческими вендорами различных Юниксов, развиваших системы кто-куда и боровшихся при этом с конкурентами. Исправить положение пытались с помощью POSIX - отчасти исправили (на уровне базого API и базовых утилит), но тем самым устроили колоссальный тормоз развитию.

Стандарты - палка о двух концах, тем более что нет верховного Бога-стандартизатора, а есть различные группы-консорциумы-гос.учереждения и все они откровенно заинтересованные субъекты процесса и очень часто коммерчески заинтересованные. Так устроен мир индустриально-технологических-de_facto "стандартов". Обязательные de-yure стандарты существуют только ВНУТРИ государств (для регуляции производства-оборота продукта) и МЕЖДУ государствами - для облегчения международной торговли. Их смысл - определять ТРЕБОВАНИЯ по сертификации-соответствию. К софту это не имеет отношения почти никакого, к счастью.

3. Открытые и свободные средства разработки, созданные в рамках проекта GNU, ничуть не менее СТАНДАРТНЫ чем все остальные стандарты, как бы они не назывались - RFC, Рекомендации XXX, Соответствие требованиям YYY и т.д. Всё как полагается - есть организация, есть процесс в котором все заинтересованные могут принимать участие, есть результат, которым можно пользоваться или не пользоваться добровольно. Единственное чего нет - необходимости ПЛАТИТЬ за что либо - за участие, за доступ к материалам, за сертификацию и т.д.

4. Система GNU autoconf/automake в итоге и оказалась самым развитым и обширным средством не просто сборки C/C++ программ (и не только их, но мы ведь об *nix) обеспечивающим процесс практически для всех известных платформ. Стоит ли удивлятся или жаловаться, что такие проекты как Mozilla его использует, коли они должны быть by design переносимыми?

>>>Эт ты зря так. Ant по части кроссплатформенности и фичастости уделает make и gmake вместе взятых.

Не, не зря - часть функций процесса, в котором участвует gmake Ant не поддерживает - он слишком НОВЫЙ для этого. Ant - _правильная_ и современная система, а auto[conf|make] - реальная, и исторически обусловенная cистема и поэтому, увы, ей ещё долго предстоит быть необходимой и используемой. Хотя и тяжелой, громоздной, морально-устаревшей, если угодно... Читать сюда:

http://freshmeat.net/articles/view/889/

> > У меня и так стандартный make есть и для сборки абсолютного
> > большинства программ его хватает.
>
> Стандартного make нет. Как нет и "стандартного Unix". Кроме gmake
> есть другие make-подобные средства и есть вовсе ему не подобные,
> например в VisualStudio... Разные проекты выбирают то, что им
> больше подходит, иногда и своё пишут-добавляют (Qt). Удавись, если
> тебе это не нравится.

Есть сертифицированые UNIX системы. Загляни в http://www.opengroup.org/openbrand/register/
И причём тут Visual Studio, оно к UNIX или UNIX-like хоть как-то
относится? Скажи, а ты бы стал использовать систему, для сборки
которой требуется Kylix?

> > Ну почему же, в FreeBSD есть стандартный make
>
> И как-кем-чем он стандартизован?

Посмотри http://people.freebsd.org/~schweikh/posix-utilities.html

> > А я всегда думал, что отличительная черта UNIX - это портабельность
>
> Неправильно думал, тупо думал, обманулся на словах, не разобравшись
> со смыслом, историей и реальным положением дел...
>
> 1. "Портабельность" была ЦЕЛЬ, которую ХОТЕЛИ достичь отцы C и Unix.
> Причем портабельность они понимали сначала как ЖЕЛЕЗНУЮ
> кросплатформенность - то есть переносимость ядра и основных утилит
> с относительно небольшими их переделками и перекомпиляцией для
> разных архитектур. Эту цель они достигли, но не до конца - по их
> собственным оценкам.
>
> 2. Кросплатформенности (особенно на уровне приложений) чуть было не
> был положен конец коммерческими вендорами различных Юниксов,
> развиваших системы кто-куда и боровшихся при этом с конкурентами.
> Исправить положение пытались с помощью POSIX - отчасти исправили
> (на уровне базого API и базовых утилит), но тем самым устроили
> колоссальный тормоз развитию.

В чём же этот тормоз заключался? Кстати, сколько раз и как именно
POSIX обновлялся, знаешь? И почему его продолжают развивать?

> Стандарты - палка о двух концах, тем более что нет верховного Бога-
> стандартизатора, а есть различные группы-консорциумы-гос.
> учереждения и все они откровенно заинтересованные субъекты процесса
> и очень часто коммерчески заинтересованные. Так устроен мир
> индустриально-технологических-de_facto "стандартов". Обязательные
> de-yure стандарты существуют только ВНУТРИ государств (для
> регуляции производства-оборота продукта) и МЕЖДУ государствами -
> для облегчения международной торговли. Их смысл - определять
> ТРЕБОВАНИЯ по сертификации-соответствию. К софту это не имеет
> отношения почти никакого, к счастью.

Существуют международные и государственые институты стандартов.
Тебе, например, ISO о чём-то говорит?

> 3. Открытые и свободные средства разработки, созданные в рамках
> проекта GNU, ничуть не менее СТАНДАРТНЫ чем все остальные
> стандарты, как бы они не назывались - RFC, Рекомендации XXX,
> Соответствие требованиям YYY и т.д. Всё как полагается - есть
> организация, есть процесс в котором все заинтересованные могут
> принимать участие, есть результат, которым можно пользоваться или
> не пользоваться добровольно. Единственное чего нет - необходимости
> ПЛАТИТЬ за что либо - за участие, за доступ к материалам, за
> сертификацию и т.д.

Я не утверждал, что средства разработки GNU нестандартны. Я говорил о
том, что у них есть масса нестандартных дополнений и что некоторые
проекты построены так, что без этих дополнений обойтись не могут.
В частности, для сборки Mozilla требуется make с нестандартными
возможностями. Выходит проект Mozilla создавался исключительно для
GNU. Но ведь кроме GNU есть масса других систем. Почему их надо
превращать в GNU-подобные только ради Mozilla? Почему проект Mozilla
не желает быть портабельной?

> 4. Система GNU autoconf/automake в итоге и оказалась самым развитым
> и обширным средством не просто сборки C/C++ программ (и не только
> их, но мы ведь об *nix) обеспечивающим процесс практически для всех
> известных платформ. Стоит ли удивлятся или жаловаться, что такие
> проекты как Mozilla его использует, коли они должны быть by design
> переносимыми?

Как тут уже было замечено, autoconf/automake не являются самым самым,
да и в чём преимущество быть самым развитым, но при этом нестандартным?
Если ты хочешь развивать несовместимую систему, то возможно в этом
будет смысл, а иначе, придерживайся стандарта. Тоесть использование
gmake говорит о том, что разработчики ориентируются исключительно на
GNU системы.

>>>Загляни в http://www.opengroup.org/openbrand/register/

Возможность добровольной СЕРТИФИКАЦИИ своего _продукта_ на звание "OpenBrand" ничуть не говорит о том, что существует некий "Стандартный Юникс". Также нет нигде требования юзать всем только posix-ный make...

>>>И причём тут Visual Studio, оно к UNIX или UNIX-like хоть как-то относится?

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

>>>Скажи, а ты бы стал использовать систему, для сборки которой требуется Kylix?

Если мне нужна именно _эта_ система и меня устраивает её лицинзионная зависимость от Kylix - то, разумеется, да. Но аналогия негодная: свободный gmake - не брендовый Kylix, так как не добавляет зависимостей от своих либ и своих условий их использования-распространения.

>>>Посмотри http://people.freebsd.org/~schweikh/posix-utilities.html

И чо там можно увидеть? "FreeBSD aims to be as compliant as possible with only a minimized area of non-compliance." - ну так все к этому стремятся в границах возможного. Вот и большое число фрибсдёвых утилит, в число которых попал и ихов make, удовлетворяет POSIX 2001, а некоторое их количество - не удовлетворяет. В других системах - такая же фигня.

Ну и что? Для СВОЕГО проекта возьми любой fully-POSIX-compliant this_shit_make, а мозилловцы взяли gmake - он им чем-то больше подошел. Позикс отнюдь не является "стандартом" Юникс, а Mozailla не декларируется исключительно позиксной системой. Это никому подножки не ставит - использование gmake возможно и безусловно на всех платформах, для который годится и сама Мозилла.

>>>В чём же этот тормоз заключался? Кстати, сколько раз и как именно POSIX обновлялся, знаешь? И почему его продолжают развивать?

Позих - ублюдство, с которым приходится мирится и который приходится развивать, так как ЭТО лучше чем НИЧЕГО. Родовое ублюдство Позикса в том, что он - пример отрицательных сторон стандартизации де-факто. Из имеющегося разнообразия юнихов вылущили-лущат некоторое среднее подмножество, которое объявили "стандартом" - при этом НИКТО полностью этому стандарту не соответствовал, не соответсвует и НЕ БУДЕТ соответствовать... Зато скока процесса вокруг и около!

Я против таких стандартов. Для IT нужны не они, а СПЕЦИФИКАЦИИ, причем лучше чтобы фиксирующие не прошлое, а определяющие будущее. Такой спецификацией посикс не является.

Позикс - ублюдство и потому что отчасти является C-ориентированным и мешает перерасти этот язык в осестроении. Давно пора запустить процесс выработки новой основы для системного программизма - без неё отрасль топчется в тупике второе десятилетие, если не больше, а не тратить деньги на совершенствование бесконечно-малых...

(Imho, прогресс остановился после появления Objective C - все остальное уже тавтология. Или ТУФТОлогия...)

>>>Существуют международные и государственые институты стандартов.

Ну да, только международно-государственного "стандарта Юникс" не существует, а мы начали с того, что некто утверждал, что Мозилла нарушает юникс-стандарты...

>>>Как тут уже было замечено, autoconf/automake не являются самым самым, да и в чём преимущество быть самым развитым, но при этом нестандартным?

Преимущество в том, что он таки самый-самый, когда дело касается портирования проги на максимальное число платформ с минимизацией ручного вмешательства в сорцы. С этой точки зрения стандартнее ничего нет - никто больше не вобрал в себя такого количества сведений об отличиях десятков реальных систем друг от друга и не автоматизировал процесс сборки программ с учетом этих особенностей.

Если это не имеет значения - юзайте любой другой сборщик. Ant, например, будет (imho) отличным выбором, особенно если прибавить к нему побольше всяких прибамбасов для процессинга сишных прог - со всем остальным у него полный порядок.

> > Загляни в http://www.opengroup.org/openbrand/register/
> 
> Возможность добровольной СЕРТИФИКАЦИИ своего _продукта_ на
> звание "OpenBrand" ничуть не говорит о том, что существует
> некий "Стандартный Юникс". Также нет нигде требования юзать всем
> только posix-ный make...

Существует множество систем удовлетворяющих техническим спецификациям
на UNIX. Вот они то там и перечислены.

> > И причём тут Visual Studio, оно к UNIX или UNIX-like хоть как-то
> > относится?
>
> При том, что тулзей для сборки проектов много и каждый проект волен
> использовать ту, что ему более подходит.

Ну да, а ведь можно и под GWBASIC.EXE програмку написать. Однако мы
обсуждаем семейство UNIX, а не Windows, DOS или CP/M.

> > Скажи, а ты бы стал использовать систему, для сборки которой
> > требуется Kylix?
>
> Если мне нужна именно _эта_ система и меня устраивает её
> лицинзионная зависимость от Kylix - то, разумеется, да. Но аналогия
> негодная: свободный gmake - не брендовый Kylix, так как не
> добавляет зависимостей от своих либ и своих условий их
> использования-распространения.

Дело не в аналогии. Просто представь ситуацию, когда у тебя есть
стандартные инструменты, ты их используешь для сборки большинства
своих программ, а тут появляется проект, который пытается стать
промышленным стандартом, во всю кричит о полном моответствии W3C и
т.д. и т.п., но вот стандартными инструментами его собрать нельзя!
Ты думаешь, мне gmake достать трудно? Нет, я просто не хочу
устанавливать инструмент-однодневку (и всё что он для себя требует),
не хочу тратить на это своё время, дисковое пространство, сетевой
трафик. У меня уже есть _стандартный_ вариант того самого
инструмента, он у меня работает и прекрасно собирает всю систему
целиком, включая тучу портов.

> > Посмотри http://people.freebsd.org/~schweikh/posix-utilities.html
>
> И чо там можно увидеть? "FreeBSD aims to be as compliant as
> possible with only a minimized area of non-compliance." - ну так
> все к этому стремятся в границах возможного. Вот и большое число
> фрибсдёвых утилит, в число которых попал и ихов make, удовлетворяет
> POSIX 2001, а некоторое их количество - не удовлетворяет. В других
> системах - такая же фигня.

Не все перечисленые там утилиты необходимы при сборке. Кстати, обрати
внимание на версию POSIX.

> Ну и что? Для СВОЕГО проекта возьми любой fully-POSIX-compliant
> this_shit_make, а мозилловцы взяли gmake - он им чем-то больше
> подошел. Позикс отнюдь не является "стандартом" Юникс, а Mozailla
> не декларируется исключительно позиксной системой. Это никому
> подножки не ставит - использование gmake возможно и безусловно на
> всех платформах, для который годится и сама Мозилла.

POSIX является частью UNIX спецификации, очень важной частью.
Mozilla, с самого своего рождения, объявлялась как система
удовлетворяющая стандартам. Если её нельзя собрать используя
стандартные инструменты, то о какой стандартности Mozilla можно
говорить? Вспомни, сколько воплей было по поводу того, что IE
поддерживает определённые нестандартные расширения HTML.

> > В чём же этот тормоз заключался? Кстати, сколько раз и как именно
> > POSIX обновлялся, знаешь? И почему его продолжают развивать?
>
> Позих - ублюдство, с которым приходится мирится и который
> приходится развивать, так как ЭТО лучше чем НИЧЕГО. Родовое
> ублюдство Позикса в том, что он - пример отрицательных сторон
> стандартизации де-факто. Из имеющегося разнообразия юнихов вылущили-
> лущат некоторое среднее подмножество, которое объявили
> "стандартом" - при этом НИКТО полностью этому стандарту не
> соответствовал, не соответсвует и НЕ БУДЕТ соответствовать...
> Зато скока процесса вокруг и около!

Так ли никто? Зайди ещё раз на http://www.opengroup.org/openbrand/register/

> Я против таких стандартов. Для IT нужны не они, а СПЕЦИФИКАЦИИ,
> причем лучше чтобы фиксирующие не прошлое, а определяющие будущее.
> Такой спецификацией посикс не является.

В чём разница между спецификацией и POSIX?

> Позикс - ублюдство и потому что отчасти является C-ориентированным
> и мешает перерасти этот язык в осестроении. Давно пора запустить
> процесс выработки новой основы для системного программизма - без
> неё отрасль топчется в тупике второе десятилетие, если не больше, а
> не тратить деньги на совершенствование бесконечно-малых...

А это самое осестроение уже достаточно развилось, чтобы перерости С?
Для появления новых стандартов должен быть повод, причина, предмет
стандартизации если хочешь. А что ты предлагаешь стандартизировать
своими воображаемыми спецификациями?

> (Imho, прогресс остановился после появления Objective C - все
> остальное уже тавтология. Или ТУФТОлогия...)

Почему же прогресс не пошёл дальше, почему он не испоьлзует этот самый
Objective C, ну в том же осестроении например?

> > Существуют международные и государственые институты стандартов.
>
> Ну да, только международно-государственного "стандарта Юникс" не
> существует, а мы начали с того, что некто утверждал, что Мозилла
> нарушает юникс-стандарты...

Она нарушает UNIX спецификацию. Так красивей звучит?
И ещё, как ты думаешь IEEE Std 1003.1-2001 и ISO/IEC 9945:2002 - это
какие стандарты, немеждународные?

>>>Существует множество систем удовлетворяющих техническим спецификациям на UNIX. Вот они то там и перечислены.

Нет у этой конторки никаких технических спецификаций на юних - там есть спецификации на "OpenBrand"! Увы, но разницу тебе похоже не понять.

>>>Однако мы обсуждаем семейство UNIX, а не Windows, DOS или CP/M.

Мы обсуждаем "нарушение" проектом Mozilla "стандартов Unix" в результате использования при девелопменте "нестандартного make", при этом Mozilla компилится и работает в Виндовс тоже - поэтому и была упомянута одна из систем сборки на этой платформе. Достало пояснять тебе элементарные вещи.

>>>но вот стандартными инструментами его собрать нельзя!

Делай раз - собирай gmake своим make'ом, делай два - собирай gmake'ом то, для чего он нужен. Какие проблемы, где "нестандартность", что обсуждать на трех страницах?

Ты так и не смог привести каких-либо доказательства "стандартности" make (кроме узости собственных представлений) из твоей системы - потому что он не "стандартный", а всего лишь "входящий в комплект". В других системах в комплект входит gmake, а в третьих не входит ни то ни другое.

Вот что написано в README.gmake автором cdrecord - одной из самых кросплатформенных тулзей в мире опенсорца: "Gmake compliance is included for convenience because it may be found on many systems and most make programs are worse than gmake." Далее автор перечисляет недостатки gmake - но остальные-то вообще НЕ РАБОТАЮТ либо не доступны на всех целевых системах (ещё smake и Sun'овский make могут собрать этот проект).

Не убеждает? Тогда может попробуешь втереть Joerg Schilling'у про существование "стандартного" make? Или заранее сообразишь куда и как быстро тебя пошлет специалист, занимающейся проблемой второй десяток лет?

>>>И ещё, как ты думаешь IEEE Std 1003.1-2001 и ISO/IEC 9945:2002 - это какие стандарты, немеждународные?

Это стандарты _принятые_ международной организацией, но никакой международной обязательности в них нет и они не единственные. Более того - любой может создать СВОЮ организацию по стандартизации чего-либо - и люди к ней потянуться если сочтут ее деятельность и рекомендации ПОЛЕЗНЫМИ, а если нет - то никакая международность не поможет. Стандарты соблюдают когда их требования обязательны по закону, либо когда это _выгодно_. Во всех остальных случаях рулят хотения / удобства / целесообразности и так далее...

speer молодец. этот упертый перец аргументов правда все равно не поймет... уж сколько его собачили до этого, все свое канючит - у меня кривой софт, почему вы не подтачиваете свой крутой чтобы работал с моим кривым...

Это да. упереться рогом в gmake - надо уметь.
Я вот тоже сейчас упрусь.
С КАКОГО ПЕРЕЛЯХА ГНОМ2 ТРЕБУЕТ НЕСТАНДАРТНОГО ГТК2, А С МОИМ СТАНДАРТНЫМ XLIB СОБИРАТЬСЯ НЕ ХОЧЕТ!!!

ГНУтая гадость он после этого!!!

:))

Speer, что же такое Open Brand? А я сам подскажу:

The Open Brand is signified by the "X" Device which can be associated with and used in relation to IT systems that have been registered with The Open Group as being fully conformant to one or more specific defined sets of functionality known as Product Standards. Its use is governed by the Open Brand Trademark License Agreement (TMLA). Anyone wishing to register a product, or products, and use the "X" Device must first sign the Open Brand Trademark License Agreement and thereby "warrant and represent" that any products they register will fully conform to the identified Product Standard(s) and will continue to do so.

http://www.opengroup.org/openbrand/

И ещё, если мы обсуждаем то, что ты сам перечислил, то зачем опять приводить в пример Windows?

В чём же принципиальная разница между Open Brand в общем и UNIX в частности?

AVL2, а ты разницу между инструментом и библиотекой понимаешь?

anonymous (*) (2003-06-30 13:38:26.786965), не подмазывайся раз сам ничего умного сказать не можешь.

>>>И ещё, если мы обсуждаем то, что ты сам перечислил, то зачем опять приводить в пример Windows?

Ты до сих пор этого не понял?! Возьми Виндовс - и запусти мозиллу... Там же можешь собрать-запустить нечто Qtшное и GTKшное - это все серьезно кросплатформенные вещи (как и cdrecord) и поэтому возможностей "стандартного make" им мало - и они пользуется ДРУГИМИ средствами, с большими возможностями.

А у тебя парень проблемы не только с понималкой, но и вообще с головой, похоже. Не хотел тебе говорить, но фраза "Mozilla нарушает стандарты Unix" сразу содержит как минимум ТРИ логических противоречия, которые делают его неверным в-принципе. Так что ничего можно было-бы и не обсуждать - невменяемость пациента, в общем-то, была видна изначально. Но надежда ведь всегда остаётся...