[ перетаскиваю из http://www.opennet.me/openforum/vsluhforumID3/84013.html#148 и далее ]> Это совершенно не подразумевается. Особенно учитывая тот факт, что упрощённая
> документация по сборке и помощь на форумах это не подразумевает, а в
> Install большими красными буквами об этом не написано.С ровными и оформленными по гнутым правилам (%name-%version/ в тарболе с названием %name-%version.tar.*) autoconf-based проектами основная проблема не в сборке (см. http://fly.osdn.org.ua/~mike/RPM/SPECS/_minimal.spec), а в метаданных -- хотя бы однострочное и более развёрнутое описание.
С группой ещё сложней -- можно попробовать автоматически категоризировать по README, ставить одно и то же значение (что плохо) или просто требовать задания вручную.
С лицензией вроде бы как можно сделать тесты на несколько распространённых случаев, но это вопрос ответственности и автоугадав тут IMCO неуместен.
Это по опыту создания спеков для таких -- вписываются название, версия (их можно брать из AC_INIT в configure.ac), лицензия, краткое/развёрнутое описание, заполняется запись в %changelog, прогоняется buildreq с установкой в хост-систему или сборочный чрут зависимостей до удовлетворительного прохождения стадий конфигурирования и сборки; пакет собирается по полученному спеку начисто, проверяется и в первом приближении всё.
Ручную стадию с добиванием зависимостей в принципе можно автоматизировать по анализу configure.ac и требуемых pkgconfig-файлов; по крайней мере обсуждение встречал, реализации пока не видел.
Наверное, автоматизировать 80% работы по упакечиванию ~50% случаев вполне реально, добиваться 100% замещения работы для тех же случаев уже сильно сложнее, а для 100% случаев -- нереально (думаю, даже если изначально ограничиться autoconf и cmake).
> А также, что при сборке нет warning'ов. Ну и по многим другим причинам.
warning'и для рассматриваемого случая можно вылавливать и добавлением в CFLAGS -Werror.
>> А, простите. Имел в виду то, что в рамках текущей штатной
>> архитектуры и реализации CPAN собирается необходимое и достаточное
>> количество метаинформации для упакечивания модулей.
> Нет, что вы имели ввиду, когда просили объяснить, какую ручную работу можно
> выкинуть?Просил (http://www.opennet.me/openforum/vsluhforumID3/84013.html#211) объяснить на примере Makefile-GraphViz в CPAN -- какая ручная работа, проведённая для создания и публикации данного тарбола в этом репозитории с целью возможности его развёртывания при помощи perl -MCPAN, является излишней для задачи автоупакечивания.
Понятно, что написание самого модуля -- ручная работа. И его публикация -- тоже. Но побочным эффектом проведения этой работы по заданным для неё правилам оказалась возможность автоупаковки.
На самом деле пришлось запускать cpan2rpm --version 0.20 Makefile-GraphViz, предварительно поставив perl-Module-Build, perl-GraphViz, perl-Makefile-Parser по вполне ловящимся паттернам ненаходимости (эти модули есть в сизифе).
Результат вот -- погоняю с mkimage-profiles да и отправлю в Sisyphus:
http://fly.osdn.org.ua/~mike/RPM/SPECS/perl-Makefile-GraphVi...
http://fly.osdn.org.ua/~mike/RPM/SRPMS/perl-Makefile-GraphVi...
http://fly.osdn.org.ua/~mike/RPM/RPMS/noarch/perl-Makefile-G...>> Скорее нет, по крайней мере не замечал.
> Автоматические инструменты не имеют спроса?Отчасти "китайцы дешевле", отчасти -- автоматизируются частные случаи под рукой и этого вроде как достаточно (довести "свой" инструмент до пригодного другим всё-таки намного сложней бывает).
>> Не-а, скорее autoconf-based.
> А разве не большинство тарболлов не autoconf-based?Не знаю, но как минимум автоконфовых весьма много. Не во всех есть configure.ac, кстати.
> Ну вот смотрите, у вас есть программа, код. Он состоит из собственно
> кода и комментов. Без комментов вы код не поймёте.Зависит, но пусть.
> Без кода комменты работать не будут. ;) Получается так: у вас есть спецификация
> функций в виде комментов, которые вы пишете сами, и её же описание на языке
> программирования. А вот писать такие комменты, чтобы по ним код генерировался, нельзя.В какой-то мере да, комментарии могут отражать намерение и тем быть спецификацией. Но они не обязаны являться _полным_ описанием намерения и обычно являются скорее _дополнением_. Ужасно бестолково прокомментированный код (нередко под заданный процент комментариев) встречался и не радовал.
> Или, например, возьмём регекспы. Такой мощный механизм поиска. Однако часто избыточный.
[...]
> Казалось бы, язык со строкой семантикой. А дедукция невозможна.Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые и всякие corner cases. Это мощный хак, но никакой строгой семантикой там и близко не пахнет, IMHO.
>> Вообще-то нет. Например, orbitz.com не только для программистов, но без глубоких
>> макросов вряд ли работал бы так же хорошо.
> Так макросы по сути тот же самый императивный высокоуровневый код.На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю. :)
> Принципы хорошо познаются в динамике и визуализации. В моделях.
К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png
>[оверквотинг удален]
> чрут зависимостей до удовлетворительного прохождения стадий конфигурирования и сборки;
> пакет собирается по полученному спеку начисто, проверяется и в первом приближении
> всё.
> Ручную стадию с добиванием зависимостей в принципе можно автоматизировать по анализу configure.ac
> и требуемых pkgconfig-файлов; по крайней мере обсуждение встречал, реализации пока не
> видел.
> Наверное, автоматизировать 80% работы по упакечиванию ~50% случаев вполне реально, добиваться
> 100% замещения работы для тех же случаев уже сильно сложнее, а
> для 100% случаев -- нереально (думаю, даже если изначально ограничиться autoconf
> и cmake).Вопрос не в полной автоматизации, а в обучаемой экспертной системе для сборки пакетов. Которую при использовании можно было бы совершенствовать и в плане знаний, и в плане блока анализа исходников на тему автоматизированного поиска зависимостей. Скажем, мягкие зависимости автоматически не получить, это уже база знаний нужна.
И опять таки, вы говорите про сопровождающего. Которому придется читать про технику сборки. Я про пользователя. Которому посоветовали в книжках/на форумах собрать пакет. Ему совершенно неочевидно всё то, о чём говорите вы. И задачи у него другие - поменять зависимости, наложить патч, а не правильно, в соответствии с требованиями, пакет собрать. И тут сюрприз - пакет, собранный не в чистой системе, может неправильно заработать. Хотя ошибок того же ./configure, к которым он привыкнет при неполадках при сборке, в этомплане нет. То есть несовершенство системы сборки, которую приходится запускать по непонятной для пользователя причине в изменённом внешнем окружении, которое создавать нужно под каждый пакет, ему неочевидна.
> warning'и для рассматриваемого случая можно вылавливать и добавлением в CFLAGS -Werror.
Я про сборку говорю. А не компиляцию. А ворнинги компиляции - вообще чёрная магия для пользователя. Сырцы он уже править руками не будет.
> Просил (http://www.opennet.me/openforum/vsluhforumID3/84013.html#211) объяснить
> на примере Makefile-GraphViz в CPAN -- какая ручная работа, проведённая для
> создания и публикации данного тарбола в этом репозитории с целью возможности
> его развёртывания при помощи perl -MCPAN, является излишней для задачи автоупакечивания.Минуточку. Я как раз говорил о том, что для автосборки нужна ручная работа. Хорошоустроенный репозиторий - ручная работа, а не автоматизированная с анализом исходников. И, что жаль, таких универсальных репозиториев, мета, если хотите, но не CPAN/CRAN/CTAN, нет.
> Отчасти "китайцы дешевле", отчасти -- автоматизируются частные случаи под рукой и этого
> вроде как достаточно (довести "свой" инструмент до пригодного другим всё-таки намного
> сложней бывает).То есть у вас, в альте, автоматизация работает хорошо?
> Не знаю, но как минимум автоконфовых весьма много. Не во всех
> есть configure.ac, кстати.То есть ограниченные случаи - это _все_ autoconf-based?
> В какой-то мере да, комментарии могут отражать намерение и тем быть спецификацией.
> Но они не обязаны являться _полным_ описанием намерения и обычно
> являются скорее _дополнением_. Ужасно бестолково прокомментированный код (нередко под
> заданный процент комментариев) встречался и не радовал.Вопрос не в обязаны/не обязаны, а в том, что из комментариев код не следует. То есть у вас две реализации одной идеи, и обе редактируются программистом вручную, а не следуют друг из друга.
> Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые
> и всякие corner cases. Это мощный хак, но никакой строгой
> семантикой там и близко не пахнет, IMHO.Под языком я C имел ввиду. И причём тут утряхивание кода? Код регекспов есть. Семантика C есть. По идее, возможна дедукция.
> На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю.
> :)А библиотеки - не суть код высшего порядка?
> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.pngПопробуйте по подобному графу, скажем, анатомию изучить, без разреза организма и наглядного представления нутра. Да или то же железо ПК, скажем, устройство матери. И да, это всего лишь картинка, а не интерактивный динамический графический интерфейс к некой предметной области. Лучше, чем ничего. Но по типу it sucks less.
> Вопрос не в полной автоматизации, а в обучаемой экспертной системе для сборки пакетов.Это как раз уже к полной автоматизации и ближе, есть много осмысленных промежуточных этапов.
> Которую при использовании можно было бы совершенствовать и в плане знаний,
> и в плане блока анализа исходников на тему автоматизированного поиска зависимостей.Скажем так: людей, с которыми можно подобным озадачиваться -- я знаю. Поэтому если будет возможность и уместность, то просто быстрей к тому придёт, чем потихоньку.
> Скажем, мягкие зависимости автоматически не получить, это уже база знаний нужна.
Не уверен, что их вообще стоит получать. Польза местами понятна, вред -- тоже, неясен итоговый баланс.
> И опять таки, вы говорите про сопровождающего. Которому придется читать про технику
> сборки. Я про пользователя. Которому посоветовали в книжках/на форумах собрать
> пакет. Ему совершенно неочевидно всё то, о чём говорите вы. И задачи у него другие
> - поменять зависимости, наложить патч, а не правильно, в соответствии с требованиями,
> пакет собрать.Если в его задачу входит пользоваться софтиной, просто к ней прилагается понимание большего удобства эксплуатации в виде пакета -- то на большого пользователя может образоваться маленький майнтейнер. Я такое и проходил, и наблюдал -- когда человека задалбывает делать одни и те же алгоритмизируемые действия руками либо дёргать "уже майнтейнера" и он, отталкиваясь от тарбола или чаще уже собранного пакета, начинает осваивать поддержку пакетов.
По-моему, не стоит заранее считать пользователя необучаемым. :)
> И тут сюрприз - пакет, собранный не в чистой системе, может неправильно заработать.
Ну так в том же альте очень большие усилия были положены на осмысление и реализацию воспроизводимых сборок; это многим пользователям помогло заняться улучшением применяемых пакетов.
Соответственно и на обучение людей усилия были положены в сумме за прошедшие годы огромные. Это не менее важно, чем инструментальная среда.
> То есть несовершенство системы сборки, которую приходится запускать по непонятной
> для пользователя причине в изменённом внешнем окружении, которое создавать нужно
> под каждый пакет, ему неочевидна.Это вопрос полноты указанных сборочных зависимостей -- я не просто так сослался на альтовский buildreq, который предоставляет их надмножество.
> Минуточку. Я как раз говорил о том, что для автосборки нужна ручная работа.
А я и обращал Ваше внимание -- что не для всякой. Например, угрозы собрать CPAN в сизиф уже звучали. :)
> Хорошо устроенный репозиторий - ручная работа, а не автоматизированная с анализом
> исходников. И, что жаль, таких универсальных репозиториев, мета, если хотите, но
> не CPAN/CRAN/CTAN, нет.Для общего случая -- нет; и кстати, простейшее возвращение *.lsm в тарболы уже бы сделало шаг в таком направлении (по части метаинформации).
> То есть у вас, в альте, автоматизация работает хорошо?
Довольно-таки; и над ней постоянно работают в плане улучшения.
>> Не знаю, но как минимум автоконфовых весьма много. Не во всех
>> есть configure.ac, кстати.
> То есть ограниченные случаи - это _все_ autoconf-based?Нет. Не все autoconf-based получится собрать без применения головы, и некоторые другие типичные случаи тоже подходят для автоматизации сборки.
> Вопрос не в обязаны/не обязаны, а в том, что из комментариев код не следует.
Поэтому и удивился, когда Вы их назвали спецификацией -- вот и попытался сообразить, какие из виденных более-менее в ту сторону...
>> Это мощный хак, но никакой строгой семантикой там и близко не пахнет, IMHO.
> Под языком я C имел ввиду. И причём тут утряхивание кода?А -- я было понял, что про регэкспы.
>> На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю.
> А библиотеки - не суть код высшего порядка?Это тоже обобщение, но степень его интегрируемости и реюзабельности в рамках конкретнго проекта обычно отличается. А вообще макросы применяются и в библиотеках. :)
>> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png
> Попробуйте по подобному графу, скажем, анатомию изучитьПробовал, в нулевом приближении годится; а без нулевого приближения может быть опасно делать первое (т.е. углубиться в конкретный орган, но не понять его взаимосвязь со всем организмом или хотя бы с непосредственно связанными физически/биохимически/сигнально).
> И да, это всего лишь картинка, а не интерактивный динамический графический
> интерфейс к некой предметной области.(читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.
> Это как раз уже к полной автоматизации и ближе, есть много осмысленных
> промежуточных этапов.Да нет, это просто такой вид контекстно-зависимой документации, когда документация является частью программы. Я же не про замену человека ЭС. Просто семантическая разметка текста. Рутина. Система поддержки принятия решений. Ну и какой-нибудь расширяемый анализатор. Такие системы в 2000 были под DOS для медицины, к примеру. Просто устроены. А эффект заметный.
Сейчас та же документация имеет простой текстовой вид. Даже просто понять её тяжело. Как говорится, лучше один раз увидеть... А увидеть как раз нельзя, ибо просто текст.
> Не уверен, что их вообще стоит получать. Польза местами понятна, вред
> -- тоже, неясен итоговый баланс.Мягкие зависимости - они ещё позволяют ту самую гибкость при компилировании получить. Типа Use-флагов.
> Если в его задачу входит пользоваться софтиной, просто к ней прилагается понимание
> большего удобства эксплуатации в виде пакета -- то на большого пользователя
> может образоваться маленький майнтейнер. Я такое и проходил, и наблюдал
> -- когда человека задалбывает делать одни и те же алгоритмизируемые действия
> руками либо дёргать "уже майнтейнера" и он, отталкиваясь от тарбола или
> чаще уже собранного пакета, начинает осваивать поддержку пакетов.Осваивание поддержки - это осваивание существующего инструментария. Полезно, конечно, но эффект не тот, как при автоматизации. Я давно программы не собирал, может, всё сильно поменялось, но во времена 2004-2006 годов создание пакетов в плане вещей типа зависимостей, были ещё рутиной.
> По-моему, не стоит заранее считать пользователя необучаемым. :)
Обученный некоторым вещам пользователь перестаёт быть пользователем. ;)
> Ну так в том же альте очень большие усилия были положены на
> осмысление и реализацию воспроизводимых сборок; это многим пользователям помогло заняться
> улучшением применяемых пакетов.
> Соответственно и на обучение людей усилия были положены в сумме за прошедшие
> годы огромные. Это не менее важно, чем инструментальная среда.Ещё раз: пользователь с этой информацией столкнётся сильно потом. Это просто неочевидно. На это внимание обращается редко. И да, это не отменяет сложности создания чистого окружения для каждого пакета. Даже не в плане знаний, а в плане необходимости держать несколько таких окружений.
> А я и обращал Ваше внимание -- что не для всякой.
> Например, угрозы собрать CPAN в сизиф уже звучали. :)Чтобы собирать CPAN, нужно сначала было его создать. Вручную. ;)
> Довольно-таки; и над ней постоянно работают в плане улучшения.
А какие названия программ?
> Нет. Не все autoconf-based получится собрать без применения головы, и некоторые
> другие типичные случаи тоже подходят для автоматизации сборки.Тогда ещё раз: что понимается под ограниченным числом случаев? Какой признак того, что пакет автоматически зависимости получит? Скажем, какие-то типичные пакеты или количество зависимостей?
> Поэтому и удивился, когда Вы их назвали спецификацией -- вот и попытался
> сообразить, какие из виденных более-менее в ту сторону...А комментарии не спецификация? Типы входных данных, типы выходных, исключения. Мало?
>>> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png
>> Попробуйте по подобному графу, скажем, анатомию изучить
> Пробовал, в нулевом приближении годится;Вы анатомию изучали по графу названий органов и систем, а не по монтажной схеме?
>> И да, это всего лишь картинка, а не интерактивный динамический графический
>> интерфейс к некой предметной области.
> (читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.Графический интерфейс вообще сложно делать. Если, конечно, под таким интерфейсом формочки не понимать.
> Такие системы в 2000 были под DOS для медицины, к примеру.Думаю, куда раньше -- см. историю MUMPS/ISO M. Кстати, GT.M под линукс вполне доступна и развивается.
>> Не уверен, что их вообще стоит получать. Польза местами понятна, вред
>> -- тоже, неясен итоговый баланс.
> Мягкие зависимости - они ещё позволяют ту самую гибкость при компилировании получить.
> Типа Use-флагов.Как раз не при сборке, а при установке. Только они жёстче USE. И опять же это не достоинство per se, а один из концов качели "гибкость-надёжность".
> Осваивание поддержки - это осваивание существующего инструментария.
> Полезно, конечно, но эффект не тот, как при автоматизации.Ну так всё постепенно.
> Я давно программы не собирал, может, всё сильно поменялось, но во времена
> 2004-2006 годов создание пакетов в плане вещей типа зависимостей, были ещё рутиной.В альте и тогда работал buildreq, false positive'ил всякие кривые тесты на фортран в configure: http://lists.altlinux.org/pipermail/devel/2004-December/1094... :)
>> По-моему, не стоит заранее считать пользователя необучаемым. :)
> Обученный некоторым вещам пользователь перестаёт быть пользователем. ;)Не могу согласиться -- себя считаю преимущественно пользователем. (:
Необученный пользователь -- он ведь и пользоваться-то подчас толком не умеет, одна потеря времени и было бы быстрее на бумаге и калькуляторе...
> И да, это не отменяет сложности создания чистого окружения для каждого пакета.
> Даже не в плане знаний, а в плане необходимости держать несколько таких окружений.Брр, в альте автоматически делается hasher-ом (с кэшированием базовой сборочной системы, разумеется). Быстро, сравнительно дёшево, воспроизводито.
>> А я и обращал Ваше внимание -- что не для всякой.
>> Например, угрозы собрать CPAN в сизиф уже звучали. :)
> Чтобы собирать CPAN, нужно сначала было его создать. Вручную. ;)С этим спору нет, но о том и говорил -- что создавался он для _другой_ цели (которую выполняет), а в качестве _побочного_ эффекта -- возможно, совсем не предполагавшегося закладывавшими правила -- получился ещё и такой :)
>> Довольно-таки; и над ней постоянно работают в плане улучшения.
> А какие названия программ?buildreq, sisyphus_check, hasher, qa-robot, gear/girar/girar-builder, jppimport, fcimport (приблизительно по возрасту)
Обсуждения можно поискать по слову incominger.
>> Нет. Не все autoconf-based получится собрать без применения головы, и некоторые
>> другие типичные случаи тоже подходят для автоматизации сборки.
> Тогда ещё раз: что понимается под ограниченным числом случаев? Какой признак того,
> что пакет автоматически зависимости получит?Наличие в нём достаточного для этого количества метаинформации в пригодном к автоматическому извлечению виде. Это необходимое, но не достаточное условие.
>> Поэтому и удивился, когда Вы их назвали спецификацией -- вот и попытался
>> сообразить, какие из виденных более-менее в ту сторону...
> А комментарии не спецификация? Типы входных данных, типы выходных, исключения. Мало?Конечно, мало. Это описание фронта и тыла слона, но не его состава и жизнедеятельности.
>>> Попробуйте по подобному графу, скажем, анатомию изучить
>> Пробовал, в нулевом приближении годится
> Вы анатомию изучали по графу названий органов и систем, а не по монтажной схеме?По большей части вообще по тексту, а что? По фотографии было бы хуже, чем по схематическому рисунку; а и ему, возможно, предпочёл бы граф для утряски понимания взаимодействий. Из смежного -- попробуйте представить себе цикл Кребса "по монтажной схеме". :)
>> (читая между строк) Интерфейс к области делается легче, чем область к интерфейсу.
> Графический интерфейс вообще сложно делать. Если, конечно, под таким интерфейсом
> формочки не понимать.Да, конечно.
> Думаю, куда раньше -- см. историю MUMPS/ISO M.Ну я с точки зрения пользователя говорю. То есть с учётом доступности этих программ на тех же носителях.
> Кстати, GT.M под
> линукс вполне доступна и развивается.Это здорово, но для linux были бы гораздо более полезны другие системы. По автоматизированным сборке и администрированию на уровне пользователя, например.
> Как раз не при сборке, а при установке. Только они жёстче
> USE. И опять же это не достоинство per se, а
> один из концов качели "гибкость-надёжность".Не знаю кому как, а я Debian выбрал в том числе из-за них. Мусора в системе поубавилось, стабильность как раз Debian радует. Но да, самому такие пакеты собирать - уровень более высокий.
> Ну так всё постепенно.
Ну, вот мне хотелось бы видеть впереди готовую автоматизацию, даже с постепенным движением.
> В альте и тогда работал buildreq, false positive'ил всякие кривые тесты на
> фортран в configure: http://lists.altlinux.org/pipermail/devel/2004-December/1094...
> :)Я тогда в мандриве сидел, был новичком и собирал по документации аля howto.
> Не могу согласиться -- себя считаю преимущественно пользователем. (:
Ну а я не считаю. ;) Я уже не новичок, но уровень дальше не кажется мне пользовательским. А у вас уровень сильно выше.
> Необученный пользователь -- он ведь и пользоваться-то подчас толком не умеет, одна
> потеря времени и было бы быстрее на бумаге и калькуляторе...Ещё раз - смотря чему обучен. Одно дело - прикладной профессиональный софт. Другое - работа с системой или программирование на С.
> Брр, в альте автоматически делается hasher-ом (с кэшированием базовой сборочной системы,
> разумеется). Быстро, сравнительно дёшево, воспроизводито.По документации видно, что нужен пакет с зависимостями. А мы как раз говорим от тарболлах, в которых эти зависимости создать нужно. ;)
> С этим спору нет, но о том и говорил -- что создавался
> он для _другой_ цели (которую выполняет), а в качестве _побочного_ эффекта
> -- возможно, совсем не предполагавшегося закладывавшими правила -- получился ещё и
> такой :)А я говорил, что было бы здорово, если бы хорошая организация такого типа хранилица была бы не ручной работой. ;)
>>> Довольно-таки; и над ней постоянно работают в плане улучшения.
>> А какие названия программ?
> buildreq, sisyphus_check, hasher, qa-robot, gear/girar/girar-builder, jppimport, fcimport
> (приблизительно по возрасту)
> Обсуждения можно поискать по слову incominger.Спасибо.
> Наличие в нём достаточного для этого количества метаинформации в пригодном к автоматическому
> извлечению виде. Это необходимое, но не достаточное условие.Метаинформации где? В начальных файлах configure и makefile или ещё где-то?
>>> Поэтому и удивился, когда Вы их назвали спецификацией -- вот и попытался
>>> сообразить, какие из виденных более-менее в ту сторону...
>> А комментарии не спецификация? Типы входных данных, типы выходных, исключения. Мало?
> Конечно, мало. Это описание фронта и тыла слона, но не его
> состава и жизнедеятельности.А состав и жизнедеятельность, по идее, должны следовать из теории, как это в математике делается, в тех же CAS или экспертных системах. В программировании её нет, но она возможна. К примеру, существуют общие решения, на основе которых генерируются частные. Дедукция.
> По большей части вообще по тексту, а что?Но к этому тексту прилагалась картинка, правда? Без которой изучение только текста было бы много сложнее. И то, текст нужен и как замена невозможной визуализации на бумаге. Той же анимации.
> По фотографии было
> бы хуже, чем по схематическому рисунку;А я о принципиальных схемах - схематических рисунках и говорю. Фотография, конечно, слишком много деталей содержит.
> а и ему, возможно, предпочёл
> бы граф для утряски понимания взаимодействий.Для _утряски_, а не первичного ознакомления и понимания.
>Из смежного -- попробуйте
> представить себе цикл Кребса "по монтажной схеме". :)Попробуйте заменить там структурные формулы названиями веществ, и понимаемость резко замедлится. Добавьте интерактивности, и скорость освоения возрастёт.
> Это здорово, но для linux были бы гораздо более полезны другие системы.
> По автоматизированным сборке и администрированию на уровне пользователя, например.Так сами ж говорите, что это уже не совсем пользователь -- а сборщик и администратор. Мне удаётся отделываться тем, что буржуи порой обзывают wearing $that hat -- когда всё-таки надо что-то собрать или уадминить, приходится напяливать соответствующую шляпу и орудовать. А так -- юзер, просто юзер :) Вот, vimperator/pentadactyl "не осилил", посмотрев и пощупав (и сидя в vim).
> Ещё раз - смотря чему обучен.
Именно. И если обучиться собирать какие-то сильно нишевые пакеты быстрее, чем ждать других -- то может иметь смысл освоить. Сильно благодарен Владимиру Бормотову (тогда из Black Cat Linux team), помогшему верно оценить страшность конкретно этих горшков.
> По документации видно, что нужен пакет с зависимостями. А мы как раз
> говорим от тарболлах, в которых эти зависимости создать нужно. ;)А, ну в этом плане да. Я пару сообщений из треда переслал viy@altlinux, который озвучивал планы заняться именно этим вопросом (для распространённых частных случаев).
> А я говорил, что было бы здорово, если бы хорошая организация такого
> типа хранилица была бы не ручной работой. ;)Думаю, нереально. Можно добиваться двух вещей:
- большей полезности уже вложенной работы;
- меньшей работы для той же полезности.>> Наличие в нём достаточного для этого количества метаинформации в пригодном
>> к автоматическому извлечению виде. Это необходимое, но не достаточное условие.
> Метаинформации где? В начальных файлах configure и makefile или ещё где-то?В том числе, но необязательно: библиотеки могут быть полезными за счёт dlopen(), картинки тем могут быть нужными для штатного отображения UI, с какими-то конкретными версиями libdb4 могут быть известны развалы базы... вещи из README, которые автоматически не всегда вообще отразишь, потому и недостаточно такого условия.
*.lsm для метаинформации, предназначенной для человека, можно было бы попытаться либо расширить, либо дополнить в рамках отдельного файла и набора договоренностей а-ля LSB/fd.o с тем, чтобы более надёжно получать это самое автоматическое извлечение.
> А состав и жизнедеятельность, по идее, должны следовать из теории, как это
> в математике делается, в тех же CAS или экспертных системах. В
> программировании её нет, но она возможна. К примеру, существуют общие решения,
> на основе которых генерируются частные. Дедукция.Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.
>> По большей части вообще по тексту, а что?
> Но к этому тексту прилагалась картинка, правда? Без которой изучение только
> текста было бы много сложнее. И то, текст нужен и как замена
> невозможной визуализации на бумаге. Той же анимации.Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста совсем не годится: это скорее впечатление, чем понимание. [...]
> Так сами ж говорите, что это уже не совсем пользователь -- а
> сборщик и администратор.Это если вручную админить и собирать. Всё-таки, запуск checkinstall не требует квалификации и особого чтения документации.
>А так -- юзер, просто юзер :)
И работаете, наверное, не в области IT.
> Именно. И если обучиться собирать какие-то сильно нишевые пакеты быстрее, чем
> ждать других -- то может иметь смысл освоить.Часто нужны универсальные. Скажем, замена swiftweasel. Или mplayer пересобрать. Здесь широкие знания нужны.
> Думаю, нереально. Можно добиваться двух вещей:
> - большей полезности уже вложенной работы;
> - меньшей работы для той же полезности.Может, дождусь начала создания метарепозитария сырцов для создания пакетов для разных дистрибутивив. Польза была бы большая.
> В том числе, но необязательно: библиотеки могут быть полезными за счёт dlopen(),
> картинки тем могут быть нужными для штатного отображения UI, с какими-то
> конкретными версиями libdb4 могут быть известны развалы базы... вещи из README,
> которые автоматически не всегда вообще отразишь, потому и недостаточно такого условия.
> *.lsm для метаинформации, предназначенной для человека, можно было бы попытаться либо расширить,
> либо дополнить в рамках отдельного файла и набора договоренностей а-ля LSB/fd.o
> с тем, чтобы более надёжно получать это самое автоматическое извлечение.Понятно.
> Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.
Общие для создания частных.
> Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста
> совсем не годится: это скорее впечатление, чем понимание. [...]В зависимости от того, кто что понимает под пониманием. Если под пониманием понимать построение в голове визуальной модели явления, то проще её, модель, увидеть, чем про неё прочитать. Не зря говорят, что лучше один раз увидеть, чем сто раз услышать. А если понимание - построение языковой модели, то и чтения достаточно. Но тогда man китайская комната.
> Часто нужны универсальные. Скажем, замена swiftweasel. Или mplayer пересобрать.
> Здесь широкие знания нужны.Вот и не лезу...
> Может, дождусь начала создания метарепозитария сырцов для создания пакетов
> для разных дистрибутивив. Польза была бы большая.И то спасибо за обсуждение.
>> Общие более дороги, хотя нередко и более осмысленны в долгосрочном плане.
> Общие для создания частных.Ой, я своё поделие mkimage-profiles уж второй год пилю...
>> Не-не-не, текст без картинки ещё бы воспринял, а вот анимация вместо текста
>> совсем не годится: это скорее впечатление, чем понимание. [...]
> В зависимости от того, кто что понимает под пониманием.Способность применить понятое для выхода за его рамки, например.
> Но тогда man китайская комната.
Не слышал, почитал; полагаю, у Сирла ошибка в четвёртой аксиоме. Под фонарём искать грустно...
> Вот и не лезу...А я лазил. Ибо нужно было. И обжигался.
> И то спасибо за обсуждение.
Какое же это обсуждение? Так, упоминание при флейме.
> Способность применить понятое для выхода за его рамки, например.
Это определение не по устройству, а по поведению. Зная устройство, можно узнать поведение. Зная поведение, нельзя узнать устройство.
>> Но тогда man китайская комната.
> Не слышал, почитал; полагаю, у Сирла ошибка в четвёртой аксиоме.Возможно, она не всегда верна. Скажем, http://www.langust.ru/review/lang_h02.shtml#02_01 , http://www.langust.ru/review/lang_h02.shtml#02_04
Ну и НЛП есть, а вот образного уже вроде нет.
>[оверквотинг удален]
> Помилуйте, да там тридцать или сколько уже лет утряхивают базовые-расширенные-перловые
> и всякие corner cases. Это мощный хак, но никакой строгой
> семантикой там и близко не пахнет, IMHO.
>>> Вообще-то нет. Например, orbitz.com не только для программистов, но без глубоких
>>> макросов вряд ли работал бы так же хорошо.
>> Так макросы по сути тот же самый императивный высокоуровневый код.
> На орбитзах не так давно работали лисповые макросы четвёртого порядка, насколько знаю.
> :)
>> Принципы хорошо познаются в динамике и визуализации. В моделях.
> К слову о том же graphviz: http://fly.osdn.org.ua/~mike/img/m-p/targets_syslinux.png
