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

50% на крючке корпорации бобра, сливают им инфу о контактах и перемещениях

За вами персонально уже выехали.

Что - паверюзерности недостаточно чтобы галку убрать «синхронизировать»?

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

Это другая проблема, не песочницы. Да, наверное, сделать приличный click-пакет будет не проще, чем сегодняшний «общесистемный» deb. Значит, будут делать говенные пакеты, но юзеры типа firestarter всё равно будут рады.

Из свежего могу припомнить что только в убунте при работе zRam количество занятого места в свопе

И поэтому такой глючный zram делают по дефолту в lubuntu? Ага, наверное там все мазохисты.

P.S. zram в бубунте абсолютно такой же, как и в debian.

С собой разговариваешь?

Ты задрал с детсадовскими замашками :)

Я тебе привел пример, когда САПР нужны зависимости. Потребности игр мне безразличны.

назови мне хоть один юзкейс

Я тебе привел пример

Т.е. ты не осознаешь, чего от тебя хотят? Чукча что-ли?

Ты задрал с детсадовскими замашками :)

Я отвечаю тебе в твоем же стиле. Не нравится - переходи на нормальный тон.

Т.е. ты не осознаешь, чего от тебя хотят? Чукча что-ли?

Ты не понимаешь, что тебе говорят? Русский не родной?

Я отвечаю тебе в твоем же стиле.

Если бы отвечал в моём стиле, то хватило бы 2х комментариев, а так ты уже с час тут тупишь.

Ты не понимаешь, что тебе говорят?

Да, я не понимаю, какого хрена мне приводят в пример приложение, когда я прошу объяснить юзкейсы... Поэтому я начинаю считать оппонента идиотом и общаюсь с ним соответсвенно. Последняя попытка, для самых одарённых - почему разработчики приведённого в пример приложения разбили его на кучу мелких пакетов и зачем им так делать при пакетировании в click? Если ты не сможешь ответить на этот простой вопрос, то не будет смысла продолжать разговор вообще. Зенитарчиком больше, зенитарчиком меньше...

что, правда?

у меня детектор сарказма сбоит. Это сарказм был или нужен пруф?

deb пакет 1c сейчас тащит в зависимостях

ну, может оно не в зависимостях deb пакета, а в файле «install.doc» - но, IMXO, требования к ПО на машине, которая станет сервером 1C, довольно обширны и конкретны,
maya, когда ставил напосмотреть пиратскую версию, тоже, помнится, требовала что-то неожиданное - gcc кажется, какие-то либы как на родном RHELе и MAC адрес отсутствующей у меня сетевой карты (давно это было) -а ведь я даже не дошёл до установки сторонних серверов рендеринга.

прошу прощения, двусмысленно получилось :)
про фс заинтересовало, можно подробнее?

Если бы отвечал в моём стиле, то хватило бы 2х комментариев

Кому хватило бы?

Почему разработчики приведённого в пример приложения разбили его на кучу мелких пакетов и зачем им так делать при пакетировании в click?

Что именно ты не понял в:

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

Если ты не сможешь ответить на этот простой вопрос

Если ты не сможешь понять этот простой ответ...

Мрачно. Одно дело не ставить их, другое дело считать что «все нужное есть». А если нет? Могли бы не ставить зависимости но оставить чтобы хотябы проверить а заработает ли оно на целевой системе. Уж не говоря о версионности.

Об этом заботятся те, кто делает диск с системой. Версионность решается линковкой с библиотеками из SDK, как в OSX/iOS, да и в tizen тоже.

ну, может оно не в зависимостях deb пакета, а в файле «install.doc»

Вот и с click так будет и никаких проблем. Сервер - один пакет click, толстый клиент - другой пакет click и все счастливы.

Шел 2013 год. Новости про убунту собирали больше 10 страниц комментариев. И как еще не надоело...

Шел 2013 год. Новости про убунту собирали больше 10 страниц комментариев. И как еще не надоело...

Самое забавное то что вечером кто нибудь запилит новость на главную про это и там будет в три раза больше страниц.

Скучные люди эти, линуксоиды.

Когда я могу взять с сайта автора программу самой свежей версии, поставить её в отдельную папку, поиграться, и снести одну эту папку одним F8 в mc - это таки удобство. Это, я бы даже сказал, УДОБСТВО. Что бы об этом не думали красноглазые аскеты.

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

Либо я не распарсил, либо кто-то дурак. Уточните свой комментарий.

а) click заточен под юзкейс аналогичный андроидному apk.
б) репозиторий деб пакетов это куча зависимостей внутри, плюс завязка на зависимости извне. Плюс чаще всего завязка на более крупные репозитории. click же завязан «на одну строчку» - версию платформы (убунту). Как собственно и apk. Репозиторий click это просто *несвязанный* между собой куча пакетов.
в) так как click завязан на свой юзкейс пакеты в click собраны специальным образом и расчитаны на работу в упомянутом сендбоксе(для deb это не так)

PS
Я не считаю что это плохо, в отличие от вашего оппонента. Но разница между тем и этим огромна.

...нацеленный в первую очередь на несуществующие мобильные платформы под управлением Ubuntu Touch.

дело не в безболезненном сваливании, а в том, что сейчас линуксовый софт в первую очередь делают под убунту (и правильно делают)

Что не позволяет этот ваш «только для убунту» линупс использовать не у красноглазых школьников (и не в гугле с их штатом убунту-суппорта).

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

зероинсталл это совершенно другой механизм. click это аналог apk.

Кому хватило бы?

Адекватным людям.

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

Ну вот, в «общих пакетах» будут всякие Qt и прочие библиотеки. А зачем разбивать одно приложение на кучу мелких? Почему какой-нибудь gstreamer или тот же Qt есть смысл разбивать на мелкие пакеты, а всякие 1c, firefox, chromium, libreoffice, vmware, bricscad лучше распространять в одиночных click пакетах?

Я даже уточню кое-что насчёт зависимостей... Вот почему у 99.9999% пакетов нет в зависимостях ядра linux?

Почему какой-нибудь gstreamer или тот же Qt есть смысл разбивать на мелкие пакеты, а всякие 1c, firefox, chromium, libreoffice, vmware, bricscad лучше распространять в одиночных click пакетах?

Да, почему? И почему я должен закатать в один пакет мое проприетарное приложение, которое состоит из двух (или более) независимых компонент, обновляемых независимо, взаимодействующих через четко определенный интерфейс?

> Мне не нравится, что зависимостей между click-пакетами нет вообще.

Кошмар! Зачем тогда они вообще это сделали?! Я-то думал что это такой же 1 click install, как в Opeensuse, а они...

Проблемы меньшинств - это проблемы меньшинств

Не тупи, детёныш

бгг. Из этого «детёныша» уже пару десятков лет песок сыплется :)

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

Нет, это задача апстрима. Мэйнтэйнер лишь адаптирует и подгоняет под дистрибутив, «встраивает» пакет в экосистему.

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

Если разработчик четко дал понять - WONTFIX/LATER, доставать его бессмысленно.

Часто на лаунчпаде бываете? :)

Нет. О причинах см. выше

click это аналог apk.

Дай Б-г чтобы он оказался лучше, дай Б-г

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

> Я напоминаю, что steam runtime портирован на другие дистрибутивы.

Посмотри и ужаснись. Ты же не думаешь что любая 4-мегабайтная программа будет таскать с собой это?

Не нравится, потому что влажные фантазии оказались важнее логики?

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

Я даже уточню кое-что насчёт зависимостей... Вот почему у 99.9999% пакетов нет в зависимостях ядра linux?

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

click заточен под юзкейс аналогичный андроидному apk.

Именно.

click же завязан «на одну строчку»

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

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

Именно. Самое главное, что в эти click пакеты можно всунуть весь прикладной софт, а в стандартных репозиториях держать только системный софт. Так же плюсом является то, что магазин приложений от убунту можно будет легко поставить в любом дистрибутиве, если удовлетворить зависимости - разработчикам прикладного и проприетарного софта не нужно будет думать насчёт совместимости с другими дистрибутивами, им нужно будет думать только насчёт совместимости с магазином приложений ubuntu, а насчёт совместимости с другими дистрибутивами уже будут думать разработчики ubuntu. Следовательно, этот магазин можно будет поставить из стандартных репозиториев других дистрибутивов либо его можно будет поставить как стим - скачав rpm/deb/tgz со всеми зависимостями внутри.

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

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

Осталось только найти четкую границу между этими двумя категориями, ага.

как в os x, видимо.

бгг. Из этого «детёныша» уже пару десятков лет песок сыплется :)

Зелененькие даже тусовку не знают :(

И почему я должен закатать в один пакет мое проприетарное приложение

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

которое состоит из двух (или более) независимых компонент, обновляемых независимо

Очевидно же, что должно быть 2 click пакета, раз они такие независимые.

Из этого «детёныша» уже пару десятков лет песок сыплется

Из меня тоже давно сыплется, но это не мешает нам обоим флудить :)

Нет, это задача апстрима

Следовательно, нужно «добиваться» исправления этого в апстриме.

Если разработчик четко дал понять - WONTFIX/LATER

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

а) click заточен под юзкейс аналогичный андроидному apk.

суть в том, что в андроиде помимо apk нет пакетного менеджера (что, кстати, плохо, ИМХО)

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

deb может быть как с зависимостями внутри, так и без них извне (не считая, разве что, libc)

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

в первом приближении:

SB=$HOME/sandbox/package
mkdir -p $SB
ar x package.deb
tar xzf data.tar.gz -C $SB
for f in $SB/usr/share/applications/*.desktop; do
    sed "s/Exec=\(.*\)/Exec=LD_PRELOAD_LIBRARY=$SB\/lib \1/g" > ~/.local/share/applications/package.desktop
done

ввиду наличия дыр в старых версиях либ, положенных в такой пакет

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

потому что в случае какого-нибудь arm-а ядра в виде пакета может и не быть

Просто это не пишут, потому что разумеется само собой.

Именно. Поэтому разработчики приложений будут подразумевать наличие определённых зависимостей - Qt будет стоять везде, а если разработчику потребуется libastral.so, то он либо запихнёт эту библиотеку в click пакет, либо как-нибудь сообщит об этом потенциальному пользователю.

Осталось только найти четкую границу между этими двумя категориями

Этим будут заниматься разработчики приложений и разработчики дистрибутива.

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

Ага, а данные пользователя(относящиеся только к конкретной программе, при правильно настроенной песочнице) все равно утекут/буду удалены/whatever...

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

>> Наряду с этим, кстати, бывают и другие забавные мнения, типа убунта глючит

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

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

Следовательно, нужно «добиваться» исправления этого в апстриме.

Загугли «перечень проблем в OpenSource-сообществе»(непомню как по-английски точно), среди них есть uncooperative upstream. Выход один - самому стать апстримом. Я один не потяну - фэйл очевиден.

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

Результат к сожалению - один. А пока я держу 0.8.* в дереве и обвешиваю его патчами совместимости. Дай Б-г здоровья тем, кто пилит 0.8.* в старом git-репозитарии.

должно быть 2 click пакета, раз они такие независимые.

Ну, началось шлангование.

Просто это не пишут, потому что разумеется само собой.

Именно. Поэтому разработчики приложений будут подразумевать наличие определённых зависимостей - Qt будет стоять везде

Я не говорю о зависимостях на систему (хотя они тоже нужны любой нетривиальной программе), я говорю о _зависимостях между click-пакетами_, что непонятно?

потому что в случае какого-нибудь arm-а ядра в виде пакета может и не быть

Не понял... http://packages.debian.org/wheezy/kernel-image-3.2.0-4-versatile-di

Для Raspberry Pi к примеру ванильное ядро не годится, дальше продолжать?

Да, почему?

А вот я не понимаю почему такой срач идет из-за двух абсолютно друг друга дополняющих систем, заточенных под абсолютно разные юзкейсы. click это система даже не для всех ISV. Серьезным ISV как раз удобнее держать несколько своих репозиториев - под rhel & debian. А вот мелким ISV как раз удобнее чтото вроде click(который негр конечно испортит своей тягой к вендоорлокингу и прочей муете)

И почему я должен закатать в один пакет мое проприетарное приложение, которое состоит из двух (или более) независимых компонент, обновляемых независимо, взаимодействующих через четко определенный интерфейс?

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

Я не говорю о зависимостях на систему (хотя они тоже нужны любой нетривиальной программе), я говорю о _зависимостях между click-пакетами_, что непонятно?

Ну не нужны они, зависимости между click пакетами. Есть приложение, его можно разбить на кучу мелких пакетов. Взять тот же хром - его можно было бы разбить на туеву хучу пакетов: отдельно flash плагин, отдельно морду, отдельно движок, отдельно pdf модуль, отдельно кодеки, но разработчики сделали один пакет, так как это удобнее всем. И всякие сапры с офисами будет легче распространять одним пакетом, взять тот же qtdevelop. А можно извращаться и делать кучу пакетов по несколько килобайт - в одном мануал, в другом иконки, в третьем бинарник, в четвёртом данные и т.д.