Установка программ одним кликом появилась в Ubuntu 13.10

Очевидно подпись и песочница помешают им расспространяться

Песочница - это да. Но кто мешает сейчас поднять левый «подписанный» репозиторий с деб пакетами, как это сейчас делает medibuntu? Или просто распространять пакет, который подключит нужный подписанный репозиторий, как сейчас это делает хром или стим?

суть в том, что готовые сборки андроидов собирает не только гугл

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

ну-ну, посмотри на chrome-овский репозиторий, много там зависимостей и правил сборок?

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

они впадают в паадучую от одного слова маркетинг(которые они к этому переименованию пытаются присобачить)

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

Вам кажется... или вы просто пропустили часть треда.

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

Во первых деб используется не только для убунтудебьяна. Полно и других форков. Во вторых «чаще всего» годится только для кулхацкеров и прочих инженегров. В третьих что там куда встанет никого не волнует в данном случае - имеется принципиальная разница. Деб как и rpm предполагает стандарт только на сам формат пакета. То что обычно на deb только форки дебьяна - скорее случайность и результат меньшей2 популярности. А клик это в том числе стандарт на API, типа LSB.

смотрим на skype

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

Не дайте умереть с голоду

:)

Я ее не игнорирую. Я знаю ее изнутри и снаружи.

И много ты занимался разработкой софта для которых apk/dmg являются основными?

Вообще не занимался. И говорю о deb/apt.

Ты смотришь на все со своей колокольни желчного разработчика аппаратно-программного комплекса где проблем такого характера просто не возникает.

Проблем какого характера? Я вижу, что система была бы способна на многое, если бы ее не кастрировали исскуственно; и вижу применение этим способностям. Причем тут моя желчная склонность к программно-аппаратным комплексам?

Если раньше у нас был огорожденные внутренности сендбокса, то теперь эти внутренности сендбокса взаимодействует с абсолютно не расчитанным на секурити тонной кода в apt-get'е.

Даже не понимаю, о чем ты. apt-get просто разрешает зависимости (для протокола: зависимости внутри песочницы), никакого взаимодействия нет.

Можно краткое содержание, о чём вы тут уже 14 страниц трёте? :)

не стесняйся переспросить.

На этом всё?

Нет, я жду ответа.

У меня нет проблем,

Ты просто не хочешь их замечать.

я несу свет

Да ты просто Прометей и Люцифер в одном лице.

Где скачать хотя бы два таких пакета click? И чем их ставить, как ПО называется?

Или просто распространять пакет, который подключит нужный подписанный репозиторий, как сейчас это делает хром или стим?

В click пакет его не сможет подключить, нечем.

Хм... Может он там сознание терял...

Нет, я жду ответа.

Если сначала установить program_common.click, то ничего не произойдёт - на винте просто будет папка с ресурсами. Если сначала установить program_server.click, то будет ошибка и грамотный программист добавит уведомление «отсутствует program_common.click». Более того, сейчас ситуация хуже - так как зависимости «учитываются», то ту же 1с нужно устанавливать в определённом порядке - купленное приложение, состоящее из нескольких пакетов есть только на диске и отсутствуют в репозитории, а это значит, что при установке пакета с неудовлетворёнными зависимостями просто будет вылазить ошибка.

Следовательно, в идеале лучше сделать один click пакет (как делают те же microsoft или adobe со своими приложениями под мак), либо подымать свой репозиторий, как это сделали разработчики dr.web for linux.

Хм... Может он там сознание терял...

/me .oO( похоже, поциент в бессознательном состоянии )

В click пакет его не сможет подключить

А это не click пакет должен подключать, а приложение, установленное из первого click пакета, должно видеть приложение, установленное из второго click пакета.

Если же песочница не будет позволять читать чужие бинарники, тогда вопрос с зависимостями решён - все компоненты в одном click пакете.

похоже, поциент в бессознательном состоянии

Проветрился, дорогой? :) Или мне в третий раз процитировать?

мне в третий раз процитировать?

Да и во второй раз не надо было.

Неверно.

Верно.

Пакет click ожидает наличия определённых пакетов.

Это и есть одна строчка - например LSB 4.0 . если вы говорите что вы требуется «LSB 4.0», это в одной строчке и есть тот самый список пакетов.

Именно. Самое главное, что в эти click пакеты можно всунуть весь прикладной софт

Весь не всунешь, а вот прикладные свистоперделки и прочие игры, таки да.

магазин приложений от убунту можно будет легко поставить в любом дистрибутиве, если удовлетворить зависимости -

Только в том случае если эту «платформу убунта» портируют на другие дистрибутивы. А тут есть огромные сомнения - скорее всего будет очередной срач и де-факто вендорлок.

Так вот, я не распарсил следующее - вы втиснулись в разговор, когда один недалёкий выразил мнение, что теперь убунта превращается в венду/mac os, и я у него поинтересовался о наличии принципиальной разницы между репозиторием click пакетов и репозиторием deb пакетов.

Ну так сами подумайте - я вам назвал целый список того почему click «репозиторий», а точнее магазин(как и apk) это совершенно другое явление чем репозиторий deb.

А убунта скорее пытается превратится в андроид, а не в винду/мак.

Но кто мешает сейчас поднять левый «подписанный» репозиторий с деб пакетами

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

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

Верно.

Да не верно же :)

Это и есть одна строчка - например LSB 4.0

Только это будет не LSB. Там как бы Ubuntu SDK.

Весь не всунешь, а вот прикладные свистоперделки и прочие игры, таки да.

Весь прикладной софт - начиная от файлменеджеров и заканчивая эклипсом. Через пару лет сами увидите.

скорее всего будет очередной срач и де-факто вендорлок

Значит будет как со стимом - кто-то засунет себе в репы, а пользователи федоры будут качать rpm с сайта ubuntu-click.com

А убунта скорее пытается превратится в андроид, а не в винду/мак.

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

Раньше было sudo apt-get install -y chromium, а теперь будет просто click-get install chromium, вот и вся разница для потребителя.

Не факт что их можно будет ставить из сторонних репозиториев

Сейчас же можно. Тем более, зачем бороться с местными зеркалами?

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

Этот же человек сейчас качает с китайского сайта mega_free_porn_9999.deb, который потребует пароль рута.

В чем конкретно проблема?
В отсутствии библиотек разных версий в системе?
В отсутствии зависимостей кликпакетов?
В необходимости прав рута для дебпакетов?
Чем тебе приглянулись кликпакеты, и чем не устраивают?

В чем конкретно проблема?

«В отсутствии зависимостей кликпакетов».

Чем тебе приглянулись кликпакеты, и чем не устраивают?

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

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

Сейчас же можно.

.click?
Я что-то пропустил!

Я что-то пропустил!

Будьте внимательней - я про обычный deb репозиторий говорил.

расширение файлов .click

надеюсь, Canonical этот момент уже запатентовали?

Так никто не отменяет это для деб

речь идёт о клик пакетах.

Политика доложна быть совершенно другой особенно на телефонах.

Политика доложна быть совершенно другой особенно на телефонах.

Песочница и невозможность исполнять скрипты во время установки пакета. Что ещё нужно?

Божежтымой, 14 страниц срача.

А убунту нужно закопать.

Можно краткое содержание, о чём вы тут уже 14 страниц трёте? :)

Каноникал изобрела пакетный менеджер без поддержки зависимостей. Зачем в линуксе придумали пакетные менеджеры, а в виндовсе - термин «DLL Hell» они уже не помнят.
Причём если сама Каноникал планирует использовать эту штуку для установки игр на телефоны, то местные горячие головы предлагают с её помощью развёртывать 1С на серверах.


ЗЫ
rpm/deb пакет идёт вместе с набором правил для SELinux и файрвола (чем не песочница?), и он вполне может иметь 0 зависимостей. Теоретически.

Контроль за поставщиками приложений.

Т.е. я ожидаю, что Каноникал будет контролировать источники .click приложений.

Каноникал изобрела пакетный менеджер без поддержки зависимостей.

Откуда дровишки?

.click это deb с определенными ограничениями.

Зачем в линуксе придумали пакетные менеджеры, а в виндовсе - термин «DLL Hell» они уже не помнят.

Просветите, пожалуйста, как организовать «DLL Hell» статически слинкованным приложением которое не если и несет динамические библиотеки, то только в споей песочнице?

Или вы из каких-то других соображений все эти глупости написали?

Кто марку показал чакру и научил ставить проги из бандлов?! Признавайтесь!

Click package не замена DEB пакетам, а создан как дополнительный формат.

Принципиально новый и с нескучным процессом установки?

Софт из Click package будет работать в специальной песочнице, чтобы снизить потенциальный риск вредоносного воздействия.

Вангую что скоро убунта со своим миром и однокликочным инсталлингом сама станет одной большой песочницей.

для установки можно использовать dpkg, хотя это не поощряется и не рекомендуется.

а за юзание этой_\«фичи\»_ марк будет высылать в качестве поощрения печеньку? Весело у вас там...

Да не верно же :)

Верно :)

Это и есть одна строчка - например LSB 4.0

Только это будет не LSB. Там как бы Ubuntu SDK.

И это будет по прежнему одна строчка, только не LSB_4.0 а UbuntuSDK_1.0

Весь прикладной софт - начиная от файлменеджеров и заканчивая эклипсом. Через пару лет сами увидите.

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

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

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

Значит будет как со стимом - кто-то засунет себе в репы, а пользователи федоры будут качать rpm с сайта ubuntu-click.com

Ну это может закончится тем что UbuntuSDK_1.0 для остальных дистрибутивов просто не будет. Вот я про что. Стим в отличие от убунты это уже написанный клиент. А вот для UbuntuSDK такого уже написанного «клиента» нету.

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

Ну ставить андроидные пакеты с CLI нельзя не потому что этому мешают какие то там чудовищные ограничения - просто нет соответствующих тулзов(или даже есть но я не в курсе)

просто click-get install chromium, вот и вся разница для потребителя.

Это как бы для гика а не для потребителя. А потребитель просто должен кликать на .click файл в броузере.

Спасибо.

Проблема в том что не всем удобно эклипс и всякий другой софт иметь в таком виде.

Сам эклипс на сайте лежит в виде архива eclipse-SDK-4.3-linux-gtk.tar.gz на 190 MB. Если всё взлетит, то через пару лет там будут лежать click пакеты.

возможность ставить .click на других дистрибутивах, и дистрибутивах устаревших в том числе.

Именно. Только им будет плевать на сильно устаревшие дистрибутивы.

UbuntuSDK_1.0 для остальных дистрибутивов просто не будет

Будет в первую очередь для убунты. А «потом» уже появится время портировать на другие дистрибутивы. На этом можно неплохо заработать, поэтому нет причин сомневаться в мотивации Марка.

Ну ставить андроидные пакеты с CLI нельзя

adb install example.apk

Но тут смысл в другом - сделать репозиторий click пакетов не сложно, а написать какой-нибудь click-get можно и на питоне. Хоть и быдлокод получится, но своё дело сделает.

Это как бы для гика а не для потребителя. А потребитель просто должен кликать на иконку приложения в маркете.

fxd

Просветите, пожалуйста, как организовать «DLL Hell»

ясно, что не имеется ввиду конкретно «*.dll» - если, скажем, видеоредактор меняет формат рабочих файлов и видеопроигрыватель, который раньше умел их показывать начинает глючить - это тоже «DLL Hell». Или если gedit требует для плугина второй питон, а в системе - третий.

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

Ну, за исключением игр - да и то не всегда.

У многих приложений даже libc в зависимостях не прописан.

например?

например?

Да почти любой. В качестве примера первый попавшийся - http://packages.ubuntu.com/raring/graphics/acidrip

Намного легче посчитать, у каких пакетов наоборот.

Да почти любой.

Я в сусе этот почти любой найти не могу.

В качестве примера первый попавшийся - http://packages.ubuntu.com/raring/graphics/acidrip

Он написан на перле - от перла и зависит - libc он прямо не зовет. Нету там никакого «верят» - все там правильно с зависимостями.

Я в сусе этот почти любой найти не могу.

Ну, с «любым» это я погорячился...

ясно, что не имеется ввиду конкретно «*.dll» - если, скажем, видеоредактор меняет формат рабочих файлов и видеопроигрыватель, который раньше умел их показывать начинает глючить - это тоже «DLL Hell». Или если gedit требует для плугина второй питон, а в системе - третий.

Ну как такое возможно для случая .click файлов?

смешной тред получился, усилиями квазара и чемпиёна.
жаль, никто не вспомнил инцидент с местной мусульманкой, которая словила троя через deb пакет.

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

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

click пакеты устанавливаются с помощью dpkg. То есть это банально скриптообвязка вокруг dpkg собранных «криво» - считай без зависимостей. Потому не взлетит оно на других дистрах - на сегодняшний момент сильно костыльно-поделочное решение.

Ну ставить андроидные пакеты с CLI нельзя не потому что этому мешают какие то там чудовищные ограничения - просто нет соответствующих тулзов(или даже есть но я не в курсе)

можно - при чем из ремотной консоли с помощью adb.

Вообще мне не совсем понятно на кой хрен собственно городить отдельные пакеджи. Хоть deb хоть rpm «уже сегодня» позволяет собрать все в виде мегапакета если надо. Аналог какого нить rpmbuild который будет заточен на то чтобы валить софт в opt и по той де spec брать все че там required вытаскивать и пихать все в кучу с возможностью маскировки системных пакетов - опять же не проблема, и не надо для этого городить отдельную пакетную систему. Для инсталяции в один клик в том же сусе YMP файлы (https://en.opensuse.org/openSUSE:One_Click_Install_ISV) являются метаописанием для существующих пакетов.

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

Вообще мне не совсем понятно на кой хрен собственно городить отдельные пакеджи. Хоть deb хоть rpm «уже сегодня» позволяет собрать все в виде мегапакета если надо.

аналог .App из OS X «уже сегодня» есть?

a) нафиг он нужен
b) к клику это не имеет никакого отношения.

b) к клику это не имеет никакого отношения.

пакеты со всеми зависимостями, исполняющиеся от юзера.

Божежтымой, 14 страниц срача.

А убунту нужно закопать.

А в стим на чём играться?

Каноникал изобрела пакетный менеджер без поддержки зависимостей.

Это они, поспешили.