его можно сделать в Линуксах чисто уже имеющимися средствами, даже ничего не изобретая

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

То получиться классический DLL Hell, наиболее простое решение - как раз держать библиотеки рядом с приложением, а не в системе

Убунта превращается в винду!
Закопать!
Зависимости - это хорошо!
Все убунтоиды должны умереть!

Эй, кто там смеет пытаться упороться сильнее Поттеринга?

Так что никакого «Qt в стандарте» не будет, не напрягайся.

http://www.linuxbase.org/navigator/browse/lib_single.php?cmd=list-by-name&amp...

Начиная с версии 3.2. И как это у них получилось?

Qt простите какой версии «попадёт в базовую систему»? И как насчет того, чтобы разработчики Qt приняли обязательство

И второй вопрос — а зачем? Если в базовую систему попадёт libxyz версии abcd, то все пакеты для данной базовой системы будут собраны для этой версии. Точка, абзац, зачем нам новые версии?

это же унылый виндовс-вей =(

Я не очень хорошо знаю, что там у макоси, но если там такая фигня с отсутствием зависимостей, то это же кошмар, нет? Если убрать систему завистмостей, то это в каждый пакет придётся пихать нужные либы, а с учётом установки каждой проги в отдельный каталог получим кашу в духе винды. Нахрена оно надо? Даже для мобильной платформы не особо оправдано, не говоря уже о десктопе. Сейчас конечно тоже не идеал, но зачем совсем ахинею то пороть?

да что ж вы тугие такие

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

убунтовцы хотят вынести наиболее употребительные зависимости (либы, иконки там всякие и т.д.) в базовую систему, чтобы софтописатели были уверены, что такие-то либо в системе точно есть и их не придётся вытягивать из каких-то репозиториев

а в комплекте с пакетом будут идти какие-то специфические довески, которые используются чисто этим пакетом

third-party software on the Ubuntu Phone/Tablet

то есть, это не для десктопа, я так понимаю? Зачем тогда весь этот холивар?

всё развитие смартфонов в гаджеты для всего намекает что скоро десктопа, как такового, не останется

Ну на LSB и FHS все же забили болт (Спасибо Red Hat). Даешь зоопарк, бинарные конфиги и антивирусы! Без них ведь vendor-lockin и выкачку бабла за воздух никааак не осуществить.

И через 10 лет у вас спросят чем Linux отличается от других и вы ответите: обоями.

Стыдно.

Ну, например, тем, что разрешение зависимостей - это математически неразрешимая задача. Поэтому проще их не иметь, или иметь самый минимум, вроде самых популярных фреймворков, как сделано, например, в Windows.

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

Я думаю что в лучшем случае будет та же гента со сброкой в облаке.

Иначе каждый калькулятор или аудиоплеер будет тянуть за собой все зависимости. Места на диске жто отожрет минимум в 3 раза больше. Я не уверен на счет памяти - процедуры из shared библиотек копируются прииспользовании или нет? Если нет - убунтовские нововведения отожрут всю оперативу(или как минимум увеличат её потребление и никакие гигабайты вас не спасут.) Из того что я вижу в wiki: Library code may be shared in memory by multiple processes as well as on disk

В случае с нововведением кроме диска пострадает еще и потребление оперативки.

GLIBC?

gentoo, portage, slots

правда, в случае с gimp (который в официальном дереве) такого нет, но можно ебилды переписать, и ставить в систему хоть 10 версий gimp.

с python такое работает, к примеру, и с множеством других пакетов

Только не работает с главной системной библиотекой. По крайней мере, пару лет назад не работало. А так захочешь поставить свежий софт, а он новую версию GLIBC требует, а с ней старый софт не работает... И получается, что захотел какую-то мелочь на 100кб обновить, а приходится обновлять всю систему, т.к. в генте параллельно 2 системных библиотеки (ака glibc) держать было нельзя.

Нет, конечно же, таскать все либы с приложением тоже не вариант, только dll-hell всё-таки существует, и отрицать его очевидное существование глупо. В той же винде, кстати, несмотря на распространённый подход «1 приложение = 1 каталог», и поныне здравствуют и используются разделяемые библиотеки.

убунтовцы хотят вынести наиболее употребительные зависимости (либы, иконки там всякие и т.д.) в базовую систему, чтобы софтописатели были уверены, что такие-то либо в системе точно есть и их не придётся вытягивать из каких-то репозиториев

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

А что будет с обновлениями безопасности для такого вот софта? Как по мне, то пакетный менагер меня устраивает почти на 100%

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

Вот тогда в и скажете зависимости это хорошо или плохо.

И как насчет того, чтобы разработчики Qt приняли обязательство не ломатьбинарную совместимость как минимум в рамках всей 4-й, всей 5-й и всей 6-й версий?

Они не ломают вообще-то. Изменение name mangling было очень давно и в дальнейших изменениях не требуется.

Так что никакого «Qt в стандарте» не будет, не напрягайся.

Вы отрицаете очевидное.

Ты не понял. Они теперь будут включены в _КАЖДЫЙ_ пакет и занимать будут 100500*кол-во_пакетов.

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

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

Отличная новость.

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

Надеюсь будут три варианта установки программ: 1. Одним пакетом со всеми зависимостями внутри. 2. apt-get install, вытягивающий программу со всеми зависимостями из репов, на лету формирующий пакет и ставящий его по алгоритму пункта один. 3. apt-get install, ставящий программу «как обычно»

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

а ты сидишь и ждёшь ебилдов.

Напиши свой, читай подправь ebuild от старой версии и положи в локальный оверлей.

Зачем пользоваться source-based дистрибутивом, если не можешь написать необходимый файл для установки из исходников нужной тебе программы ?

убунтовцы хотят вынести наиболее употребительные зависимости (либы, иконки там всякие и т.д.) в базовую систему, чтобы софтописатели были уверены, что такие-то либо в системе точно есть и их не придётся вытягивать из каких-то репозиториев

Как ты себе это представляешь в мире никсов, где живут по несколько десятков конкурирующих версий различных технологий и программ? Если всё включить в базовую систему - придётся бунту распространять на двух blu-ray или полутора дюжинах dvd.

С нетерпением жду нового пакетного менеджера

так у этой идеи нет пакетного менеджера, как и у macos. А deb будет таким же, как .pkg.

скоро так и терминал уберём а потом и рута, будем как в винде сидеть в песочнице с дырами .

В винде есть и терминал, и рут. Песочница есть в Linux, даже несколько, на выбор.

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

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

в генте 2.7.0 и live, старше на сайте нет, откуда брать недостающие патчи?

Это будет не система, а монстр.

Не взлетит.

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

т.е. каждое приложение будет весить огого?

А что будет с обновлениями безопасности для такого вот софта? Как по мне, то пакетный менагер меня устраивает почти на 100

Сколько патчей для устранения проблем с безопасностью в QtCreator накатили разработчики всех линуксовых дистрибутивов? Да я сам отвечу: ноль. Аналогично с игровым движком OpenMW. Полагаю, что и в игрушке 0ad ситуация не отличается.

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

В таком случае не проще ли взять с собой ноут с убогой?

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

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

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

У Linux и Unix есть принцип KISS, Keep It Simple, Stupid .

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

В общем Ubuntu быстрее закопается.

Как там плагин QbsProjectManager, есть в списке? Включён в 2.7.0, но исходники qbs идут ка git submodule. В убунтовском пакете нет.

Ха, смешно.

One-application OS

Может, сабж разрулит проблему с безопасностью? Т.е., некая довольно простая система-гипервизор пускает контейнеры с виртуальной машиной, внутри которой есть только одна программа. В самой ВМ нет ни рута, ни пользователя в обычном понимании - нет необходимости. Да, придётся интегрировать программы с сабжем, также не очень понятно, какую часть поддержки железа переложить на гипервизор, но зато всё будет изолировано друг от друга, и никакие дыры _внутри_ этой вм не будут страшны.

Идея гипотетическая, помидоры просьба не кидать.

Вот только как раз таки программа в пакете all-in-one больше соответствует принципу KISS, чем когда она раскидана по всей файловой системе а для её управления (установка, обновление, удаление) нужно использовать сложные программы, которые с легкой подачи пользователя могут выдать тоскливую портянку ошибок.

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

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

То, что задумали эти ребята, нельзя назвать идеальным. Но это трезвая (или не очень? :)) попытка решить проблему, которая объективно существует. Даже если ничего не получится, сообщество получит опыт, который пригодится после. Да, KISS принцип хорош, но сейчас у Linux есть не меньше недостатков, чем у винды. Более того - я вижу всего один единственный плюс - открытость.

нашел старый диск на 20 ГБ, ему уже лет 10 - работает зараза и очень хорошо работает.

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

ну если единственный плюс - открытость... поздравляю! вы прозорливый пользователь.

хороший вопрос. Т.к. qt-creator у меня не стоит и ставить не хочется, то попробую погадать по кофейной гуще^W^W ебилду.

Тут поддерживаются плагины: autotoolsprojectmanager, cmakeprojectmanager. С судя по ебилду из подмодулей ничего не загружается (это про 2.7.0). Так что вполне возможно и нету, полезный проект, сабмитить баг?

В 9999 (live версия) нужно смотреть как работает git-eclass насколько я помню, он сабмодули загружает.

Ну и если я правильно понимаю, то получается, что в одной и той же версии qt-creator может быть разный qbsprojectmanager в зависимости от того, когда собирали?

нет.

пака убунта, превед ищо адна венда

ну если единственный плюс - открытость... поздравляю! вы прозорливый пользователь.

Ну ладно, еще бесплатность :) Просто исторически сложилось, что я работаю на разных системах, и с того времени, когда вышла семерка, с винды я не плююсь. Мне не нужно быть Ъ - я просто «работаю свою работу».

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

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

В случае же если у вас будет большой «толстый» пакет, в который включены необходимые библиотеки вам нужно будет переустанавливать этот пакет целиком, а не обновлять лишь библиотеку и так с каждым «толстым» пакетом.

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

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

Вы опять смотрите на вещи глазами пользователя, на которые этот пользователь вообще не должен смотреть и знать, тем более пользователь Ubuntu.

Идея установки пакетов без зависимостей неплохая. На одной из разновидностей BSD прошла ведь. НО нельзя давать возможность установки пакета от обычного пользовательского аккаунта. Это называется здравствуйте вирусы под Ubuntu?

не переживай, копируют 100% мOSX.
Как я понял там pkg от Фряхи и «вот это».

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

И вам надо повторить, что в реальном софте библиотеки не будут дублироваться либо уже дублируются, потому что софт кроссплатформенный и пишется также под Windows/Mac?