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

Причем отслеживать такое нужно... правильно, вручную

В генте не работает SElinux?

http://fxr.watson.org/fxr/source/bsd/?v=xnu-2050.18.24

вот, ссылка на исходники BSD части XNU, там можно посмотреть BSD шные копирайты в файлах, например в NFS. Код конечно уже модифицирован относительно оригинального BSD.

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

Единственное, что технически не дает (ИМХО) click стать общим форматом для крупной и мелкой рыбы - это отсуствие зависимостей между пакетами.

Ты закатываешь в один пакет свое проприетарное приложение именно потому что оно состоит не из «независимых компонент»

Я думаю, что мне лучше знать.

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

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

Загугли

Читал и полностью согласен.

Выход один - самому стать апстримом. Я один не потяну - фэйл очевиден.

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

Не понял...

а теперь загрузи свой арм и покажи dpkg -l | grep kernel-image

дальше продолжать?

Да. Значит Raspberry Pi работает вообще без пакета с ядром или может всё таки там есть пакет с патченным ядром?

Ну не нужны они, зависимости между click пакетами.

Тебе лично - не нужны, мне - нужны.

Взять тот же хром

Ты пакаджер Хрома?

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

Может, ты пакаджер офиса или сапра? А то MS распространяет офис в виде нескольких пакетов.

вообще без пакета с ядром

да, и не только оно, все ARM/MIPS железки, которые попадали в мои руки

а теперь загрузи свой арм и покажи dpkg -l | grep kernel-image

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

Тебе лично - не нужны, мне - нужны.

Мы возвращаемся в самое начало, опять про юзкейсы. Так зачем нужны?

А то MS распространяет офис в виде нескольких пакетов.

Да ладно! Я тут вижу офис только в одном пакете: office_bus_enu_14.0.0_100825.3_ship_volume_build.dmg

спасибо.
но я думал, ты про hfs говорил.

Мы возвращаемся в самое начало, опять про юзкейсы. Так зачем нужны?

Я уже описал.

А то MS распространяет офис в виде нескольких пакетов.

Да ладно!

Что, больше не распространяет? Раньше я точно мог поставить Ворд и не ставить Эксель.

Я тут вижу офис только в одном пакете: office_bus_enu_14.0.0_100825.3_ship_volume_build.dmg

ГейОС не пример.

это не пакет, а образ файловой системы

Вроде как хорошо сделали. Главное, что не тронули deb-пакеты. А так - глядишь, и больше полезных, но мелких поделок появится.

Всё больше похоже на мастдайку. В какой ещё ОС устанавливают ПО при помощи мыши? Есть в этом что-то неправильное...

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

Ну и? гнулинукс более универсальная система чем андроид. Это по сути конструктор для сборки и тестирования систем. Все это гугл делает внутри себя - в результате соотвествующий инструментарий для распределенной разработки такой системы ненужен.

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

Давайте не про теорию а про практику. В практике деб-репозиторий для распостранения isv софта (то есть то для чего click) это нечто перелинкованное зависимостями внутри и извне. Зависимости и правила сборки.

Но если чо, click это и есть deb. click от deb отличается ограничениями наложенными на контент.

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

[шеллскрипт]
Ну именно это сlick и делает как я понимаю, только не в первом приближении.

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

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

спасибо.
но я думал, ты про hfs говорил.

HFS самодельная, но реализована поверх BSDшной VFS.

Если мне не изменяет память, до 10.6 поддерживалась BSDшная UFS.

Вот почему у 99.9999% пакетов нет в зависимостях ядра linux?

А что эти 99% пакетов зовут ядерные функции? А не какой нить libstdc++ или libc?

Я уже описал.

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

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

Раньше я точно мог поставить Ворд и не ставить Эксель.

А это разве не бинарный инсталлятор? Ну, там галочки ставишь, а потом жмёшь install :) Знаешь, а это ведь не куча разных пакетов и даже зависимостями там не пахнет... В любом случае, для таких вендузятников и в линуксе остались всякие инсталляторы.

ГейОС не пример.

Зато венда пример, ага.

Вот почему у 99.9999% пакетов нет в зависимостях ядра linux?

А что эти 99% пакетов зовут ядерные функции? А не какой нить libstdc++ или libc?

это не пакет, а образ файловой системы

Так-так-так... А как тогда в такой системе поставить приложение, зависимостей же нет :) Ой, наверное под такую систему надо будет переделывать пакет... А может быть даже использовать click, божемоймывсеумрём!!!

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

Что, не хватает тебя больше, чем на пару постов во вменяемом тоне?

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

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

А что эти 99% пакетов зовут ядерные функции? А не какой нить libstdc++ или libc?

У многих приложений даже libc в зависимостях не прописан. Разработчики как бы верят, что уже всё установлено :) Наивные такие, правда?

«Операционные системы» Appl^Wгруши

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

aptitude install package

Не благодари.

Неpower юзер должен использовать то, что ему дает power-майнтейнер.

В реальном мире не бывает так, чтобы все юзеры были не-power, а все майнтейнеры — power. Я уж не говорю о том, что это весьма субъективные вещи, например даже очень хорошо знакомый с чем-то другим мейнтейнер не сможет собрать толком программу на Qt, если не знает возможностей Qt — обязательно же что-то пропустит, и пропускают.

Что, не хватает тебя больше, чем на пару постов во вменяемом тоне?

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

Обоснуй свой ответ.

Для меня программный комплекс - это библиотеки, ресурсы и куча бинарников. В данном примере будем считать, что разработчик наркоман и не хочет пользоваться системными библиотеками, а без libastral.so его приложение вообще работать не будет. Другими словами, у нас уже есть общие компоненты, которые хотят использовать разные бинарники. Допустим, что это совсем разные бинарники - например, какой-нибудь сервер, клиент и конфигуратор и все будут выполняться на разных системах - на сервере, у менеджера и у программиста. Тогда будет 4 click пакета program_comon.click, program_server.click, program_client.click и program_config.click. Если же приложения невозможно использовать на разных системах или приложения отличаются только бинарниками, которые весят крайне мало и основной размер занимают общие ресурсы, то легче сделать один click пакет. Если же общих ресурсов крайне мало, а бинарники отличаются очень сильно или у всех свои ресурсы, то легче сделать 3 click пакета, засунув в каждый из них свои библиотеки. Если же в такой программной комплекс, который засунули в один click пакет, нужно подключить дополнительный компонент, который, например, продаётся отдельно, то этот компонент можно отдельно упаковать в click пакет (в качестве примера можно взять какой-нибудь рендер для пакета моделирования - получается всего 2 пакета).

Так делают все адекватные разработчики. Теперь я внимательно слушаю, почему пользователь лора считает себя умнее гугла, эппла и марка вместе взятых :)

aptitude install package

Ты знал =)

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

Это да. Каждый, кто даст себе труд прочитать их, решит для себя.

4 click пакета program_comon.click, program_server.click, program_client.click и program_config.click

Замечательно. Итак, зависит ли program_server.click от program_common.click? Если да, как именно это указывается? Если нет, то почему?

Теперь я внимательно слушаю, почему пользователь лора считает себя умнее гугла, эппла и марка вместе взятых :)

Найди этого пользователя и спроси его.

В генте не работает SElinux?

SELinux научился отслеживать bundled libs? o_O

Все это гугл делает внутри себя

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

В практике деб-репозиторий для распостранения isv софта (то есть то для чего click) это нечто перелинкованное зависимостями внутри и извне. Зависимости и правила сборки.

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

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

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

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

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

deb по сути не предназначен для распространения вне репозитория

смотрим на skype

А кому он нужен полуброшенный?

Пока нет адекватных замен - мне. KWin до сих пор не дотягивает до кастомизабельности compiz. Weston теоретически может его переплюнуть, но compiz работает уже здесь и сейчас. Я говорю о старой ветке, конечно, 0.9.* - это фэйл по многим статьям. Хотя некоторые баги там и починены, общее состоянии ужасно.

Значит Raspberry Pi работает вообще без пакета с ядром или может всё таки там есть пакет с патченным ядром?

В Raspbian скорее всего кастомный пакет с ядром. Но ставить зависимость от пакета ядра Linux некорректно(если только это не Linux-only вещь). Пример - тот же Debian/kFreeBSD.

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

Единственное, что технически не дает (ИМХО) click стать общим форматом для крупной и мелкой рыбы - это отсуствие зависимостей между пакетами.

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

Ты закатываешь в один пакет свое проприетарное приложение именно потому что оно состоит не из «независимых компонент»

Я думаю, что мне лучше знать.

Если ты уперся рогом в землю и игнорируешь реальность - то нет, тебе хуже знать.

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

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

Я тебя понял. Я говорил про то что никакой реальной независимости между отдельными пакетами в любом репозитории нету, в том числе и в репозитории вендорском. Пакет в репозитории не является независимой единицей, в отличие от репозитория целиком.
И в случае энд-юзера выставлять свой софт в качестве кучи пакетов - это делать «кишки наружу». Эндюзеру эти кишки ненужны. Для него вся твоя куча пакетов - одна логистическая единица, а то что ни там обновляются по отдельности ему плевать. Для него удобнее не разбираться в том что и как у тебя там обновляется, а нажать на кнопку «поставить апдейт номер 100500»

А вот если мы говорим об админе сложного софта, который ведет некую сложную инсталляцию, то таки да, ему с зависимостями удобно. Но это совсем другая задача. Почему бы тогда ему просто не использовать уже готовый apt-get (yum) и вендорский репозиторий? То есть ты зачем то пытаешься прикрутить к специально упрощенной системе сложность, которую от нее откручивали специально?

Хе-хе, а чем это репозиторий click пакетов принципиально отличается от репозитория deb пакетов? :)

В песочнице выполняется.
Lordwind наверное по вирусам соскучился и поэтому ему это не нравится.

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

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

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

Итак, зависит ли program_server.click от program_common.click

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

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

Найди этого пользователя и спроси его.

Ха-хахаха-ха! Прекрати, человек-анекдот

Если ты уперся рогом в землю и игнорируешь реальность - то нет, тебе хуже знать.

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

А вот если мы говорим об админе сложного софта, который ведет некую сложную инсталляцию, то таки да, ему с зависимостями удобно. Но это совсем другая задача. Почему бы тогда ему просто не использовать уже готовый apt-get (yum) и вендорский репозиторий?

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

То есть ты зачем то пытаешься прикрутить к специально упрощенной системе сложность, которую от нее откручивали специально?

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

А не выбирать какую версию по сегодня захотела его левая пятка.

Для игрушек и многих прикладных свистоперделок это далеко не так.

Неpower юзер должен использовать то, что ему дает power-майнтейнер.

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

Именно на таких неpower юзеров вся технология репозиториев и рассчитана.

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

А вот локальная установка нужнадля игр и практически только для них

Для любых прикладных свистоперделок. Игры естественно included. Вот например, хочу поставить свистоперделку «будильник». И что, ждать пока эту ненужную шутку кто-то засунет в репозхиторий? Или самому этим заниматся? Это бред. Пусть эту свистоперделку суют в apk/click и я ее поставлю в один клик.

Итак, зависит ли program_server.click от program_common.click

Если сначала установить program_common.click,

Если тебе что-то непонятно в моих вопросах, не стесняйся переспросить.

Найди этого пользователя и спроси его.

Ха-хахаха-ха!

Если ты считаешь меня умнее гугла и прочих, это твоя личная проблема.

SELinux научился отслеживать bundled libs? o_O

Мне знакомый пользователь федоры только что сказал, что да. Мне уточнить у него что-нибудь?

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

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

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

Они же не удаляют классический подход. В конце-концов останутся и другие дистрибутивы. В чем проблема?

общее состоянии ужасно

Ладно, не важно. Просто жаль, что сообщество не может допилить его до адекватного состояния. А Canonical не фиксит его, потому что все силы бросили на unity8/mir и это их право.

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

Я чуть ранее намекнул, но боюсь, что ещё не все осознали шутку юмора. Любое приложение (разработчик) сможет рассчитывать, что ядро есть, поэтому его нет в зависимостях. Так и пакеты click могут быть уверены в наличии ядра linux, Qt, python, gstreamer и notify-osd.

Lordwind наверное по вирусам соскучился и поэтому ему это не нравится.

А кто мешает поднять левый репозиторий с заражёнными пакетами?

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

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

На этом всё? Я рад, что больше нечего возразить.

это твоя личная проблема.

У меня нет проблем, я несу свет понимания даже человекам-анекдотам :)

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

И много ты занимался разработкой софта для которых apk/dmg являются основными? Ты смотришь на все со своей колокольни желчного разработчика аппаратно-программного комплекса где проблем такого характера просто не возникает.

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

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

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

Нужны не «пакеты без зависимостей» а законченное, простое, минимальное решение.

Более того, подозреваю что можно вызывать apt-get и апдейтать свою инсталляцию внутри сендбокса вручную со своего собственного долбанного репа :D Для тех кто без сложностей не может :D