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

Да, только время и пропаганда, желательно еще поддержка на законодательном уровне.

Мне наиболее угрёбищным решением кажется то, что deb собирает программу из исходников, запуская систему сборки с параметрами.

Если тебе нужно просто собрать пакет из набора имеющихся файлов, ты складываешь файлы в папочку, пишешь конфиг, и запускаешь dpkg -b. С rpm все точно так же.

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

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

Даешь двойное проникновение Линукса!

А может тебе еще на грудь поссать, что бы морем пахло?

любитель золотого дождя? и часто тебе так?

Линукс держится на энтузиастах в основном, откуда тут по для специалистов

и это плохо, т.к. это то чего не хватает не только мне, но и многим другим.

Gnome 2

Единого дистрибутива

Да, надо было отдельным пунктом вынести =(

Но это не проблема линукса, дело именно в производителях по.

из чего логически можно заключить что это все таки проблемы Линукса ;)

разработчики мелких программ и проприетарщики банально сосут лапу.

Я вижу лишь пару не сильно существенных причин, чтоб им «сосать лапу»:

• Нужна определённая версия библиотеки. Решения:
  • Используй системную, и чини/поддерживай свой говнокод.
  • Бандли нужную версию с пакетом (например в /usr/local/lib/$prog_name/lib), и линкуйся к ней
• Нет инфраструктуры для компиляции deb/rpm вне системы. Решения:
  • Использовать виртуалки c целевой системой
  • СMake умеет генерировать *.deb/*.rpm/whatever после сборки
  • Найти/написать другую систему для генерации deb/rpm после сборки (я уверен, кроме CMake есть еще такие)
• Разработчик/мейнтейнер — дурак. Решения:
  • Нанять не дурака
  • Самовыпилится

Мейнтейнеры дистрибутивов уже давно запилили нормальные «Software Center» (e.g. Application Center (ubuntu), Muon (kubuntu/debian), YaST (openSUSE), Apper (KDE), Yum Extender (fedora/rhel)) их и нужно использовать.

Кстати вопрос: dpkg или rpm умеют устанавливать программы (полностью) в $HOME ?

Популярных игр
Прикладного ПО
Драйверов устройств

И да +1

может ещё в генту запилить Software Center.... от этих центров только пользователи глупеют .

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

может ещё в генту запилить Software Center....

Мне нравится вариант Muon: есть и Application Center (и гламурный Discover) и традиционный интерфейс в стиле Synaptic. И всё это пользуется единым API: QApt.

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

Доработанности кед

мне хватает и hd3000 которая игру слабую запустить не в состоянии

Это такая же фикция, как и статическая компиляция. Но я всё-таки распишу по пунктам проблемы, из-за которых становится видно, что вся пакетная система deb/rpm рассчитана только на разработку дистрибутива как единого целого и ни на что больше

• Deb, rpm и pkgbuild представляют собой входные данные для весьма оригинальных и плохо документированных интерпретаторов. Это не просто скриптовый динамический язык — это скриптовый динамический язык с непредсказуемой структурой, остутствием юнит-тестов и ужасной документацией, по сравнению с python/ruby
• В этом ужасном языке нужно явно писать зависимости пакетов — разумеется, по памяти — а для поддержки разных версий дистрибутива придётся ещё вспоминать, где и почему такой-то пакет был переименован. Условные директивы для выбора списка зависимостей по версии дистрибутива в RPM везде разные, уродливые и недокументированные, а в DEB отсутствуют вообще
• Нет никакой гарантии, что скачанный пакет будет открываться в какой-либо графической утилите. Нет никакой гарантии, что скачанный пакет можно будет установить дефолтным способом, если он тянет за собой какие-то особые зависимости (в Debian я лично помню такой факап года 3 назад).
• Продвижения для сторонних пакетов просто 0, в этом плане линукс ничем не лучше винды, где ПО распространяется на отдельных дисках или с пиратских сайтиков. Только в рекламу-то никто тут вкладываться не будет, в отличие от винды.
• Чтобы попасть в стандартные репозитории и получить какие-то возможности продвижения даже для классной опенсорсной утилиты, придётся обить семь порогов, пять раз отсосать мейнтейнеру и подождать три месяца. Заодно надо выкинуть половину функций из программы, потому что они требуют статической компиляции с библиотеками, это типа какбы небезопасно, а обеспечивать безопасность системы без запретов мейнтейнеры не умеют.

Сравнивать это с android APK или iOS IPA серьёзно просто невозможно. Потому что в них скриптовать и отлаживать нечего, всё декларативно и очень кратко.

может ещё в генту запилить Software Center.... от этих центров только пользователи глупеют .

О, здравствуйте, многоуважаемый элитарий.

Используй системную, и чини/поддерживай свой говнокод.

Какое классное отношение к сторонним разработчикам.

Бандли нужную версию с пакетом (например в /usr/local/lib/$prog_name/lib), и линкуйся к ней

Это гарантированный способ получить волчий билет от мейнтейнеров. Исключения — сверхпопулярные программы уровня firefox.

Использовать виртуалки c целевой системой

Нет никакой целевой системы, есть куча дистрибутивов и их версий. Делать одну работу десять раз в 2013 году, на тормозной и не настроенной виртуалке? Тестировать результат 10 раз или (что ещё хуже) отказаться от тестов вообще? И вы ещё спрашиваете, зачем нужен click?

СMake умеет генерировать *.deb/*.rpm/whatever после сборки

Это всего лишь жалкая попытка разорвать циклическую зависимость deb->cmake->deb. Я даже не вижу смысла объяснять неустранимую убогость автоматически сгенерированных пакетов; как минимум — это опять же волчий билет от мейнтейнеров.

Найти/написать другую систему для генерации deb/rpm после сборки (я уверен, кроме CMake есть еще такие)

Сейчас Digia разрабатывает систему сборки qbs, и её автор отказался делать генерацию DEB/RPM — потому что он опытный человек и прекрасно видит циклическую зависимость deb->qbs->deb.

Разработчик/мейнтейнер — дурак. Решения: Нанять не дурака

То есть я пишу открытый код, и я ещё должен за него платить, чтобы благодарные пользователи могли к нему прикоснутся без вырезания гланд через зад! Чудно. А почему у Google и Apple получилось сделать удобную и на порядки более быструю публикацию пакетов, но без отсоса мейнтейнерам дистрибутива?

Разработчик/мейнтейнер — дурак. Решения: Самовыпилится

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

Мейнтейнеры дистрибутивов уже давно запилили нормальные «Software Center» (e.g. Application Center (ubuntu), Muon (kubuntu/debian), YaST (openSUSE), Apper (KDE), Yum Extender (fedora/rhel)) их и нужно использовать.

Это хорошее улучшение интерфейса для пользователя. Но они никак не решили две главные проблемы: огромные трудности в создании качественных пакетов и неприспособленность всей пакетной системы для установки сторонних пакетов. Apple при переходе на intel даже сделали universal binary, которые работали одновременно и под powerpc, и под intel. Линуксоидов опыт веба 2.0 ничему не учит, и они по-прежнему считают, будто бы вывешивать на сайте 10 пакетов для 10 из 40 наиболее популярных дистрибутивов-версий - это нормально.

из чего логически можно заключить что это все таки проблемы Линукса

Тут своеобразный порочный круг. В частности из-за нехватки топового софта Линукс не может получить должного распространения. А в системе с процентом на десктопах производители ПО не видят коммерчески привлекательного рынка сбыта.

Бандли нужную версию с пакетом (например в /usr/local/lib/$prog_name/lib), и линкуйся к ней

Это гарантированный способ получить волчий билет от мейнтейнеров. Исключения — сверхпопулярные программы уровня firefox.

Насколько я знаю — в PPA более либеральная политика. Заставлять пользователей добавлять PPA не нужно. Надо лишь вывесить на сайте *.deb со скриптом, который сам добавляет PPA/репу в систему (пример: opera, chrome). Там же (на Launchpad) можно эти пакеты и собирать (для свободных программ).

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

Дурак, по определению, и написать толковой программы не может. Так что пусть идёт в макдак бургеры продавать.

Я даже не вижу смысла объяснять неустранимую убогость автоматически сгенерированных пакетов; как минимум — это опять же волчий билет от мейнтейнеров.

Пункт 1 — в PPA. Со временем скрипты сборки доработаются и всё будет хорошо.

циклическую зависимость deb->qbs->deb

что это такое? эта самая зависимость...

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

Indie разработчикам — надо лишь использовать ту самую систему для генерации пакетов, а затем вывешивать их на freedesktop.org/launchpad/sourceforge/свой сайт/etc. Крупным проприетарщикам — повесить задачу на Release team.

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

Это уже надо смотреть по силам команды. Минимальный вариант — это один *.deb, один *.rpm и один *.tar.gz/zip для наиболее актуальных версий библиотек.

А почему у Google и Apple получилось сделать удобную и на порядки более быструю публикацию пакетов, но без отсоса мейнтейнерам дистрибутива?

Сколько стоит выложить пакет на AppStore/Play Market? Какие там критерии отбора?

А вот обратная сторона click-пакетов сейчас чётко видна в Play Store: куча платных «фонариков» и «калькуляторов (месячных)» которые помимо того, что требуют доступ чуть ли не к номеру/cvv кредитной карточки пользователя так еще и глючат. Это результат той самой простоты отправки пакета в систему.

Резюмируя: умные (не глупые) найдут путь опубликовать свой продукт хоть на Solaris'е, если он будет хоть сколь-нибудь востребован. Поделия в стиле «Смотрите на мою супер-пупер-мега прогу. Она ничего не делает и стоит всего лишь $9.99» не нужны.

а будут пользоваться тем, что лучше и удобней.

Так речь шла не про удобство, а про поддержку Единственно Правильного Формата («ворд или там эксель»).

А вот обратная сторона click-пакетов сейчас чётко видна в Play Store: куча платных «фонариков» и «калькуляторов (месячных)» которые помимо того, что требуют доступ чуть ли не к номеру/cvv кредитной карточки пользователя так еще и глючат. Это результат той самой простоты отправки пакета в систему.

Глючащих программ и в линуксе полно, причём прямо в репах. Не надо притворяться, будто глюки — это свойство программ-фонариков, от которого линуксовый софт избавлен. Лучше просто сделайте ls -a ~ и опубликуйте результат.

Вот, ls -a ~ http://pastebin.com/7UNxLXp5

А какое прикладное ПО имелось в виду? Смотрю, за этот пункт проголосовало больше всего опрошенных — не удивлюсь, если это виндузятнеги...

Надо лишь вывесить на сайте *.deb со скриптом, который сам добавляет PPA/репу в систему (пример: opera, chrome). Там же (на Launchpad) можно эти пакеты и собирать (для свободных программ).

Вывесить на сайте == потерять возможности по поиску и продвижению, предоставляемые репозиториями и GooglePlay/AppStore.

Дурак, по определению, и написать толковой программы не может. Так что пусть идёт в макдак бургеры продавать.

Так уже все в макдаке, поэтому и не надо относиться к программистам, как к дуракам — таковых нет.

что это такое? эта самая зависимость...

Deb/rpm разработаны так, чтобы вызывать систему сборки с заданными параметрами и делать постобработку продуктов сборки. Для разработчиков ОС это удобно, для разработчиков софта — нет, потому что разработчик софта имеет дело с системой сборки (причём с одной для всех платформ).

Тем не менее, cmake может вывернуть всё наизнанку и делать вызовы cmake->deb. Такую хрень не получится встроить в репозитории, потому что в репозиториях всё собирается кучей в направлении deb->cmake. Так что такой кульбит с пакетами — это волчий билет в любом репозитории.

Ну и конечно, все параметры для генерации пакетов в том же cmake пишутся руками или не пишутся нигде (так что программа не может даже подписаться на открытие нужных MIME-типов в ней). А в андроиде — всё в манифесте, по-человечески.

Indie разработчикам — надо лишь использовать ту самую систему для генерации пакетов, а затем вывешивать их на freedesktop.org/launchpad/sourceforge/свой сайт/etc. Крупным проприетарщикам — повесить задачу на Release team.

Indie разработчикам нужно продвижение. Так что инди живут на AppStore и GooglePlay, и с deb/rpm никогда не придут в линукс, который заставляет их самостоятельно продвигать свой продукт, делая велосипедные сайты и распространяя пакеты через скачивание. Зачем людям идти туда, где их посылают? Очевидно, не зачем, и очевидно, что не идут к линуксу.

Это уже надо смотреть по силам команды. Минимальный вариант — это один *.deb, один *.rpm и один *.tar.gz/zip для наиболее актуальных версий библиотек.

Феноменально идиотская методика.

Вот, ls -a ~ http://pastebin.com/7UNxLXp5

А из скрытых должны быть только .local и .config. Улавливаешь?

Не надо притворяться, будто глюки — это свойство программ-фонариков, от которого линуксовый софт избавлен.

Глюки, это результат, прежде всего, некачественного кода. Потом — невнимательности QA. ... и где-то на 100-м месте это некоторые особенности работы инфраструктуры/сторонних библиотек.

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

Ну.. да. Проблема в не-следовании стандартам.

Не надо притворяться, будто глюки — это свойство программ-фонариков, от которого линуксовый софт избавлен. Лучше просто сделайте ls -a ~ и опубликуйте результат.

А в чём прикол? Я даже не поленился, сделал — ничего необычного не заметил.

Ну.. да. Проблема в не-следовании стандартам.

Проблема в том, что следование стандартам требует огромных усилий. Большинство софта на Qt такой проблемой не страдает — потому что там хранить настройки в положенном месте не просто очень легко — это даже легче, чем хранить в неположенном.

Глюки, это результат, прежде всего, некачественного кода. Потом — невнимательности QA. ... и где-то на 100-м месте это некоторые особенности работы инфраструктуры/сторонних библиотек.

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

А какое прикладное ПО имелось в виду? Смотрю, за этот пункт проголосовало больше всего опрошенных

ветку не читай @ сразу комментируй

не удивлюсь, если это виндузятнеги...

макодрочеры ;)

ветку не читай @ сразу комментируй

Это моё кредо! Сразу в бой, по-чапаевски!

Проблема в том, что следование стандартам требует огромных усилий.

Форсить стандарты тоже не вариант...

Инфраструктура тут на первом месте, без вариантов.

Хорошая инфраструктура — хорошо. Я не спорю (Я бы вообще вcех G-кодеров заставил перейти на Qt ;) ). CMake — тоже инфраструктура, хорошая инфраструктура.

С хорошей инфраструктурой работать проще — не лезь куда не надо, и всё будет хорошо.

Но я говорил о немного другом: проблем, когда в каком-то N-ом потомке Debian'a абстрактная программа не работает из-за левых патчей в библиотеке — единичны по сравнению со случаями, когда завязываются на не-штатный/экспериментальный/незадокументированный функционал и орут потом во всю глотку, когда оказывается, что в других дистрибутивах этого функционала нет. (Это чисто личные впечатления)

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

Я готов купить такую программу за до $300

разработай тз и запости на фриланс. тебе там и за $100 сделают. А за $300 - сделают вообще збс

И ведь кто-то голосует за такой непонятно что тут делающий вариант.

надеются, что им дадут. ну или просто спермотокс^Wчувство прекрасного тешат.

А из скрытых должны быть только .local и .config

удваиваю

Единственно Правильного Формата

*.епф

А из скрытых должны быть только .local и .config.

Скрытые файлы — зло.

http://habrahabr.ru/post/191850/

Мультитач запилили уже?

и типа нардов

gnubg, которые, правда, играют чрезмерно хорошо

Выбрал «прикладного ПО».

Плюсую, от себя только добавлю - ВИДЕОдрайверов, чтобы можно было комфортно использовать линь на ноутбуке :)

http://habrahabr.ru/post/191850/

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

Юмор оценил

Ке-ке-ке

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

Полмира (на самом деле уже почти весь) сидит на нём потому что вменяемых альтернатив нет. Пробовал я и SIP и Jingle вместе с Jabber, но считать их альтернативой скайпу - это мягко говоря выдавать желаемое за действительное. Так что проблема прежде всего техническая.

Засилье формата, принадлежащего одной коммерческой фирме - это проблема не линукса, это проблема реального мира.

Нет, это проблема именно Linux. Потому что у всех остальных пользователей (коих в России 99%) никаких проблем с ним нет. У них вообще никаких проблем нет и они даже не знают что с каким-то форматом могут быть проблемы.

• Прикладного ПО
• Драйверов устройств
• Возможностей файловых систем
• Улучшений ядра и окружения
• Слишком много лишнего