Почему ГНУсофт такой кривой ?

когда я говорил про кривость, я имел ввиду состояние юзабильности без поика патчей, а не про сравнительную кривость с другим софтом. Т.е. про релизную политику, а не про качество.

>Почему ГНУсофт такой кривой ?

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

А вы использете GNU за деньги?

ВАМ НИКТО НИЧЕГО НЕ ДОЛЖЕН!

> ВАМ НИКТО НИЧЕГО НЕ ДОЛЖЕН!

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

сильно сомневаюсь.

>ВАМ НИКТО НИЧЕГО НЕ ДОЛЖЕН!

а при чем здесь "деньги" или "должен" ? никакое волонтёрство не исправит эту ситуацию кроме полного форка всех базовых проектов(что не реально). Речь идет об историческом разбиении проектов по ролям. GNU.ORG выпускает релиз раз в год, потом все его патчат.(и не логотипы вставляют, а реально правят баги). Разные дистрибы часто по разному.

Нафиг ваши тормозные костыли для многобайтных кодировок, многим важна скорость работы

многобайтовые костыли не нужны, ибо http://lorquotes.ru/view-quote.php?id=3408

А почему zort такой кривой?

Это не GNU софт кривой, а кривые "современные требования", созданные маркетинговой политикой RedHat (и потом успешно собезьяненные разработчиками GTK и GNOME).

Не было бы RedHat, так и сидели бы либо на 8-битных кодировках, либо на честном UCS-4 (с честным переписыванием всего заново), а не на UTF-8, который "работает" только у американцев.

да чё вы к кодировкам то привязались... во многих патчемых прогах в (B)LFS поддержка присутствует, но не работает. Так что большей частью это исправление багов а не добавление фичи.

http://packages.debian.org/changelogs/pool/main/g/glibc/glibc_2.7-6/changelog (10 серьёзных исправлений с 2.7 релиза в октябре насчитать можно, а минорной версии не вышло)

Лурье, ты ли это ?

>Лурье

кто это ?

> свежие релизные версии часто полностью сломаны, и до правки дистростроителями - не юзабильны.

Релизная версия -- это то, что в твоем дистрибутиве. То, что выкладывается в виде исходников на странице автора, это, как правило, полуфабрикат. Там же, на странице автора, как правило, присутствует ссылка на репозиторий VCS, где можно взять свежачок, список патчей, присланных со стороны и т.п. Дистростроитель дорабатывает этот полуфабрикат до уровня готового продукта и делится с разработчиками своими наработками. Нормальный дистростроитель очень плотно взаимодействует с авторами.

Выпускать или не выпускать минорные промежуточные версии -- это сугубо дело авторов. Поддержка старых версий требует времени. В текущей ситуации, обязанности по поддержке возлагаются, в основном, на дистростроителей, т.к. они это все равно будут делать даже если минорные версии будут выходить (а ты как думал? В Debian stable, например, практически не кладут новых версий -- патчат старые).

Если ты сам себе дистростроитель, то обязанности по допиливанию возлагаются на тебя.

У меня проблем нет. Что я делаю не так? Может не выискиваю дотошно всякие "кривости"?

Взгляну На АНТИЛОПУ-ГНУ И потихонечку вздохну: Зачем, зачем Везли в Европу Такую Антиантилопу?!!

>> Лурье

> кто это ?

почитайте тему про домен ))) там был "коллега" который хотел толкнуть домен сообществу )

Не толкнуть, а дать попользоваться с условием, что там будет его реклама :) Ну а толкнуть - уже потом :) И за кругленькую сумму :)

> ЗЫ в плане минорных версий ядро, VIM и bash, приятно выделяются из серой массы, постоянными выпусками стабильных патчсетов/минорных версий.

Проблемы, по-моему, начинаются тогда, когда авторы двух программ не могут согласиться, кто из них прав. Например тот же Vim и Man:

Я в личной переписке заявил автору Vim, что ни одна из реализаций "man" под Linux (т.е. оригинальный man и man-db) не смотрит в каталоги (типа $(MANDIR)/fr.ISO8859-1 и $(MANDIR)/fr.UTF-8), куда "make install" ставит страницы руководства, и предложил добавить аргумент к скрипту configure, который будет решать, ставить "для Debian" или "для RedHat" (в терминологии LFS - см. http://www.linuxfromscratch.org/lfs/view/6.3/chapter06/man-db.html). После некоторой переписки было выяснено, что man в FreeBSD (в то время 5.1) действительно смотрит в эти каталоги, но в некоторых случаях (в том числе ru_RU.UTF-8) портит не-ASCII символы.

В результате Bram пишет:

> This point still stands. Perhaps some tools need to be adjusted to work

> properly, that's not my problem. I'm not going to adjust Vim for broken

> tools that CAN be fixed. Especially if it's such a mess as you describe.

> Any solution would only be temporary. In this situation it's

> better to aim for the final solution.

На что я ответил:

> I see your point. My point is: don't trigger the existing Linux bugs

> then. No feature is better than broken feature. In other words,

> could you please remove the installation of translated manual pages

> by "make install", at least on Linux, but let them stay in the source tree?

Ответ Bram:

> I think that is a bad solution. "make install" should install the

> manual pages. When the encoding is wrong this will trigger someone to

> solve the problem (hopefully).

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

> It is also a lot simpler to refuse to work with the current

> semi-broken "groff zoo" situation (and thus require current distros to

> patch Vim) than to provide a simple configure switch. I have nothing

> against the "Linux distros, you all are broken, please fix yourself or

> patch Vim" statement, as long as it (or some more diplomatic variant

> of it) is in the official documentation (i.e., the src/INSTALL file).

А патч в результате все еще нужен и про него в src/INSTALL ничего не сказано, и во FreeBSD не-ASCII символы все еще портятся.

>это то, что в твоем дистрибутиве.

нихрена ;). это дистрибутивная версия.

>То, что выкладывается в виде исходников на странице автора, это, как правило, полуфабрикат.

ну да. Что то не помню что бы на лоре была новость типа "Вышел полуфабрикат программы-2.8, Ура !!!" ;) (хотя к KDE4 это в какой то степени относится...)

неправильно это. Лучше бы бета версии выпускали, чем выпускать релизы бета качества и вынуждать дистрибутивы доводить софт до ума...

заставляет меня зависеть от дистрибутивов и их специфических идеологий. Можно сказать что часть работы РeдХета тоже отсюда исходит.

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

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

У тебя очень вендовое представление о релизах. Избавляйся.

> А патч в результате все еще нужен и про него в src/INSTALL ничего не сказано, и во FreeBSD не-ASCII символы все еще портятся.

И? Автор Vim тебе правильно сказал. ЕГО скрипты работают так, как оно ДОЛЖНО работать. Если какие-то другие программы НЕ работают так, как должны, напиши об ошибке авторам этих других программ, а не проси автора Vim сломать его скрипты для совместимости со сломанными программами.

Мягкотелость в плане потакания ошибкам других приводит иногда к плачевным результатам. Наиболее распространенный пример -- потакание браузеров ошибкам неграмотных веб-мастеров, в результате теперь вообще хрен поймешь, что же такое HTML, ибо стандарт вроде есть, но его никто не соблюдает на 100%, где, кто и насколько не соблюдают -- у каждого свои, да еще и пытаются фиг знает каким образом показать то, что вообще никаким спецификациям не соответствует.

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

Не понял. Нсли автор Vim пользуется возможностью других программ (*roff), которая еще не реализована - как это может быть багом в *roff?

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

>А патч в результате все еще нужен и про него в src/INSTALL ничего не сказано, и во FreeBSD не-ASCII символы все еще портятся.

да, отвратно.

> не помню что бы на лоре была новость типа "Вышел полуфабрикат программы-2.8

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

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

Чем лучше? Сейчас идет нормальное разделение труда -- разработчики пишут, дистростроители адаптируют под дистрибутив и шлют фидбэки. Все заняты, дело движется споро. Если свалить _всю_ работу на core team, новых (не минорных) версий можно будет ждать до морковкиного заговения, а дистростроители выродятся в примитивных запускателей dpkg-buildpackage (или чего там у кого).

> заставляет меня зависеть от дистрибутивов и их специфических идеологий.

Если ты полагаешься на любой чей-то труд, то ты от него зависишь. Используя GNOME, даже собирая его из исходников, ты зависишь от приверженности разработчиков HIG'у, от лени разработчиков GTK и много еще от чего. То, как этот GNOME разложит по папочкам дистростроитель зависит гораздо меньше. Я, например, завишу от разработчиков FVWM. Захотели они в один прекрасный момент отключить поддержку глобального системного меню, и отключили -- пришлось, знаешь ли, в свой конфиг прописывать строчку Read bla-bla-bla.

> только в результате получается, что для полного обVCSивания минимальной системы нужно содержать зоопарк из 5-6 разных VCS. это отвратно.

Мне, например, приходится держать несколько архиваторов/компрессоров. И ничего, нормально. Не понимаю, чем тебе так не нравится держать в системе клиентов для нескольких VCS. Apache для SVN ведь никто не заставляет поднимать.

> к тому же многие исправления отвергаются хозяевами VCS по тем или иным причинам...

Ну, насколько я помню, все VCS умеют сохранять локальные изменения при обновлении. Держи свой личный форк (mainstream+свои патчи). А выпуску минорных fix-версий ни жарко, ни холодно от того, примут разработчики твой патч или нет.

> автор Vim пользуется возможностью других программ (*roff), которая еще не реализована

Насколько я понимаю, автор Vim пользуется возможностью, которая заявлена, как реализованная. Если она не работает, то это баг, о котором надо сообщить разработчикам.

Автор Vim пользуется тем, что man умеет обрабатывать страницы руководства в кодировках, отличных от ISO-8859-1. Официально такая возможность не заявлена, а -Tlatin1 и патчи от Fedora - это хак.

Бред, тогда уж однобайтовые кодировки, а то по вашему koi8-r тоже не заявлено

> по вашему koi8-r тоже не заявлено

Вы в этом абсолютно правы (если не учитывать groff CVS). Попробуйте вывести страницу руководства в KOI8-R на принтер. С ISO-8859-1 это работает, достаточно передать groff параметры -mandoc -Tps.

И попробуйте еще в FreeBSD в чешской локали (которая использует ISO-8859-2) вывести страницу руководства от Vim. Man во FreeBSD передаст groff'у ключик -Tascii.

У меня все выводится( локаль koi8, дистр - слака ) никаких RH костылей - нет

У меня тоже Windows 3.11 на 266MHZ летает. Засунь ее назад на свалку истории.

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

Т.е. вы предлагаете чтобы новые версии програм тормозили больше чем старые, т.к. прогресс идет и вычислительные мощности дешевеют, и правда зачем им постаивать? даешь все приложения на C# и java

>примитивных запускателей dpkg-buildpackage (или чего там у кого).

ничего плохого не вижу в их вырождении... к тому же linux, bash и VIM - минорные версии/патчи выпускают, и не похоже что бы это им сильно мешало. ИМХО нынешняя ситуация больше относится к сложившейся традиции чем к необходимости.

вместе с дистрибутивом ты "покупаешь" не только стабильность и отлаженность, но и лишние для некоторых сущности... к примеру package management (что, если я хочу свой собственный) стандарты на именные конвенции, на /etc, на иерархию каталогов.

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

кастомизаторы как бы в жопе оказываются. только не говорите что так и должно быть.

>Если ты полагаешься на любой чей-то труд, то ты от него зависишь.

и я бы предпочёл продолжить от него зависеть, но напрямую... без всяких man in the middle.

>И ничего, нормально.

компрессоры это не VCS. некоторые VCS страшно space inefficient. засорять диск очень не хочется.

>все VCS умеют сохранять локальные изменения при обновлении.

что, и CVS умеет локальные бранчи ? я думал нормально это реализовано только в git и hg.

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

> У меня все выводится( локаль koi8, дистр - слака )

Действительно, если в man.conf прописано, что NROFF надо вызывать с -Tlatin1, то для вывода на экран почти все работает (но это тем не менее хак). С этим хаком вместо "пуль" в ненумерованных списках отображается псевдографика, и вывод на принтер идет кракозябрами.

Вот ведь непонятливый, объясняют же что работа со строками utf-8 содержащими кириллистическими символы много медленней чем с однобайтными кодировками, зачем сознательно соглашаться на тормоза

//качпа sending

> много медленней

WHAT? Зато сколько проблем можно сразу выкинуть.

> ничего плохого не вижу в их вырождении...

А я вижу, но сейчас объяснять не стану -- долго.

> к тому же linux, bash и VIM

Скачай source-пакеты ядра и bash из Debain и удивись количеству патчей. При всех их минорных релизах. Про vim не знаю, лень смотреть.

> ИМХО нынешняя ситуация больше относится к сложившейся традиции чем к необходимости.

Необходимость заключается в том, что дистрибутив -- это несколько больше чем варезник для "альтернативной ОС" (т.е. набор откомпилированных программ, записанных на диск). Потребности разные, потребителей много и эти потребители отнюдь не заинтересованы в глубоком ковырянии исходников какой-либо программульки. А core team не заинтересована работать колцентром для домохозяек. Именно тут возникает _необходимость_ в посреднике. Который может пойти на копромисс (наложить патч самостоятельно), чтобы все остались максимально довольны: у разработчиков процесс разработки идет по графику, а у домохозяек в кратчайшие сроки исправлены глюки, которые им мешают.

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

У меня есть определенные требования к ПО. И я хочу их удовлетворить с минимальными трудозатратами. Трудозатраты на зарабатывание дополнительных нескольких тугриков на железо, которое позволяет мне не замечать лишние сущности, несоизмеримо меньше, чем на прыжки с бубном там, где не нужно.

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

> package management

Это скользкая тема. Я ярый сторонник PM в системах общего назначения.

> стандарты на именные конвенции, на /etc, на иерархию каталогов.

А мне не фиолетово ли, как они называются? Я ведь не яблочник какой, чтобы по загадочным причинам намеренно делать "не так как у всех", если это не приносит явной выгоды.

> было бы неплохо , если бы релизный софт был готов к кастомизации этих сущностей сразу

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

> кастомизаторы как бы в жопе оказываются.

Кастомизатор должен обладать навыками разработчика, а при разработке еще и не такая жопа случается, так что это все цветочки.

> продолжить от него зависеть, но напрямую... без всяких man in the middle.

Граф зависимостей настолько хитро переплетен, что всегда найдется очень много чего, от чего ты зависишь не напрямую.

> некоторые VCS страшно space inefficient. засорять диск очень не хочется.

Не понял. Если я делаю cvs checkout bla-bla-bla, то что там space inefficient окромя исходников? Или есть какие-то VCS, которые что-то еще делают? Я не говорю про локальный VCS-сервер, он не нужен.

> что, и CVS умеет локальные бранчи ?

А я говорил о бранчах? Если у тебя есть изменения (твои личные патчи) в working tree, то cvs update накатит патчи от разработчика, сохранив твои изменения. Конфликты, естественно, вручную надо разруливать.

>буду я использовать этот софт за деньги - что-то изменится?

Да, суппорт.

Фигня в том, что собственнический софт ничуть не менее кривой :(

>удивись количеству патчей.

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

>то cvs update накатит патчи от разработчика,

эти изменения ещё надо протестировать на работоспособность в "непатченной-тобой-версии" прежде чем конфликты резолвить. Без локальных бранчей откат назад будет очень неудобен. Не говоря о том для своих изменений тоже неплохо было бы версионность иметь. СVS-way для таких задач плохо подходит.

Как говорил Линус "Пользователи СVS - тупые и уродливые" ;)

>Я ярый сторонник PM в системах общего назначения.

я не говорил про отмену. я говорил про замену на свой.

>тугриков на железо, которое позволяет мне не замечать лишние сущности

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

это не путь самурая. ;)

да и потом может у нас задачи разные, и линукс для тебя это только пускалка бровзера и почты ?

>потребители отнюдь не заинтересованы в глубоком ковырянии исходников какой-либо программульки

долой домохозяек из пользователей ;)

для тех кто не заинтересован, пусть будут дистрибутивы. это не значит что заинтересованным нужно палки в колёса вставлять (пусть и не намеренно)

>некоторые важные возможности

инфраструктура важнее фичей. может нынешняя система как раз тормозит добавление этих фичей....

>Кастомизатор должен обладать навыками разработчика,

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

>Граф зависимостей настолько хитро переплетен, что всегда найдется очень много чего, от чего ты зависишь не напрямую.

да ладно, не надо этих обобщений. У англоязычных даже термин есть для этого праведного процесса ;) http://en.wikipedia.org/wiki/Disintermediation

Убей себя пожалуйста - окажи услугу сообществу

ананимус, я вас чем то обидел ?

Просто раздражают такие советчики пытающиеся пропихнуть виндовые методы разработки

анонимус вы дурак ? у ядра виндовые методы разработки ?

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

>Ядро это один из самых наикривейщих компонентов

как раз наоборот, относительно своего размера это один из самых НЕ кривых компонентов. плюс они не стесняются компенсировать кривость мин. версиями.

>накладывают на него десятки тысяч патчей,

не правда. своих патчей они накладывают мало

http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.22-...

> не правда. своих патчей они накладывают мало >http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.22-...

Я говорил про нормальных дистростроителей, дебиан к таковым не относится. Лучше посмотри сколько патчей в RHEL и SuSE

>Я бы не стал ставить ядро как пример некривого гнутого софта. Ядро это один из самых наикривейщих компонентов, нормальные дистристроители накладывают на него десятки тысяч патчей, чтобы оно нормально работало.

Хочешь сказать что Патрик со Слакварей и Арчь плохие дистростроители? Что плохого в .config, ручках и в ванильном ядре?