Альт Линукс начинает публикацию регулярных сборок графических окружений

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

Согласно http://packages.altlinux.org/ , 6877 пакетов в 4.0 на текущий момент. Изначально было чуть меньше.

6877

А как начнешь что-нибудь искать нужное: фигвам. Или качай с rpm.pbone.net (вручную улаживая зависимости), или собирай.

Я с 2003 года.

А что, альт так умеет?

А в чём проблема ? Я и lilo использую, а не grub.

Поскорее бы его закопали. Так ненавижу Альт Люникс, что спать не могу.

Так ненавижу Альт Люникс, что спать не могу.

Попробуйте валерианки попить. Или стать мейнтейнером ALT Linux Team, чтобы спать спокойно и умиротворённо.

яннп.жпг

Вкратце: спецдистрибутивы - тупиковый путь, специализированные репозитории/аналоги стима - верный путь но им никто не пойдет, так как мешают тараканы в головах.

Вкратце: спецдистрибутивы - тупиковый путь

Мне трудно представить, какой смысл нужно вкладывать в слово «спецдистрибутив», чтобы назвать Componentized Linux «спецдистрибутивом».

специализированные репозитории/аналоги стима - верный путь

Не знаю про Стим, но CL был именно попыткой пойти путем «специализированных репозиториев».

Хм, не троллинга ради, а интересу для. Что там такого нужного появилось?

Если на сервере 1.7, то 1.6 клиент с ним работать не будет.

P.S. съезд на git вспоминается как большое облегчение.

Я предпочитаю git там, где мне предоставляется выбор.

Мне трудно представить, какой смысл нужно вкладывать в слово «спецдистрибутив», чтобы назвать Componentized Linux «спецдистрибутивом».

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

Не знаю про Стим, но CL был именно попыткой пойти путем «специализированных репозиториев».

Это была попытка выпилить какой то мегаинструмент. Я же про то что не надо мегаинструментов по выпиливанию стопитсот репозиториев/спецдистрибутивов - надо что бы люди без всяких инструментов пилили чтото вроде реп «для цифрового артиста» а не дистрибутив «для цифрового артиста».

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

Правда, не далее как позавчера после инсталляции свежего ядра ( 3.7.6-std-def-alt1.1) и make-initrd* хозяйства, я наступил на какую-то странную проблему с lilo (на Сизифе), чего-то ей там не хватило для того, чтобы безболезненно отработать /sbin/lilo. Система после этого перестала грузиться. Немного танцев под «камлай, камлай шибче!», загрузка с grub2-шной флэшки и инсталляция grub2 проблему решили.

Наверное, проблема была в какой-то странности в конфигурации моей домашней машинки, но, так или иначе, обратно на lilo уже не хочется :)

Тут беда не столько в каком-то прикладном пакете (ну, типа того же KDE4 или OpenOffice'а). Беда в том, что этот KDE4 и OpenOffice лежат на некотором наборе библиотек «разной степени системности». И при распространённом в линуксе подходе только «дистрибутив» может гарантировать неконфликтность и достаточность этого окружения.

Альтернативами является подход, принятый в Windows («весь рантайм, начиная с msvcrt, ношу с собой») или в MacOSX - есть некоторая базовая система (в которую входит, между прочим, довольно много всего «небазового») и рассованные по бандлам библиотеки для конкретного пакета.

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

<f...ing commercial>Все в облака! Даёшь APSstandard.org!</f...ing commercial>

Если на сервере 1.7, то 1.6 клиент с ним работать не будет.

Век живи...

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

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

надо что бы люди без всяких инструментов пилили чтото вроде реп «для цифрового артиста» а не дистрибутив «для цифрового артиста».

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

Лозунг «помоги своему дистрибутиву» в головы вбит, иное - нет.

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

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

Это очень круто да. Но ниасилели.

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

Если такой репозиторий будет таскать с собой gtk нужной версии, а так же остальное нужное (так как в lsb нужного нет) - меня это нисколько не расстроит. Гентуарчеводов это конечно расстроит, но их спрашивать не будем.

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

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

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

Но ниасилели.

Увы и ах. Вроде Федора собиралась делать что-то отдаленно похожее.

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

Не выйдет. Там в конце концов потребуется поддерживать свой дистр - проще привязаться к какой-то версии убунты.

Тут беда не столько в каком-то прикладном пакете (ну, типа того же KDE4 или OpenOffice'а). Беда в том, что этот KDE4 и OpenOffice лежат на некотором наборе библиотек «разной степени системности». И при распространённом в линуксе подходе только «дистрибутив» может гарантировать неконфликтность и достаточность этого окружения.

Это «гарантировать» для любой «наперед взятой программы». Нам не нужно для любой программы - нам в каждом случае нужен вполне конкретный набор софта. И не нужно типового способа решения проблем - достаточно их решить для каждого такого репозитория-тулбокса по своему. Вплоть до полного fake chroot по необходимости.

Распространять таким образом kde/гном это искать приключений на свою задницу. А вот тот же инкскейп собирается так что бинарь неплохо встает почти везде.

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

Я по сути предлагаю подход венды (все с собой помимо win32 api) но не для конкретного приложения - а для репозитория прикладного софта. То есть для нечта, что условно будет ставится в /opt/artist и там хранить вплоть до своей личной пакетной базы. Иметь свой gtk если надо, вплоть до разных версий и свой gimp/inkscape (в примере дистрибутива цифрового артиста)

Соответственно ориентироваться такой проект должен исключительно на потребителя и монетизацию через него. И хоть виндовое ПО с зависимостями к wine туда класть, хоть какие то пакеты с артом, хоть рекламу там и др. - так как проект должен себя окупать. И не просто окупать, а оплачивать развитие foss продуктов в него входящих, в идеале, служить каналом дистрибуции на которые будут ориентироваться другие продукты по его теме, местом где будет возникать какая то специализированная интеграция для этого направления.
PS
«Дистрибутив цифрового артиста» лишь пример - я совершенно не в курсе с каких направлений такую штуку выгодней всего начинать. Может там медики какие американские жаждут такой специализированный репозиторий - но я понятия не имею что им там может понадобится :D

Не выйдет. Там в конце концов потребуется поддерживать свой дистр - проще привязаться к какой-то версии убунты.

Если этот свой дистр будет ставится по клику в мой /home/vasya | /opt/coolsoft - пусть будет свой дистр. Главное что бы он не претендовал на отдельную машину и обеспечивал описанный мной функционал «распаковал, запустил - работает» :D
Этих дистров хоть опой ешь - а пользы от них гораздо меньше чем могло бы быть.

Собственно один из вариантов это собирать все под убунту/центось и таскать эту убунту/центось как окружение с собой. Я вручную так делал при помощи .so магии - не вижу проблемы делать это не для одного пакета а для нескольких.

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

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

Мне? Ничего. Но для chroot нужен root, теряется почти вся интеграция с остальным софтом, а на распространение такой фигни можно сразу забить. С контейнером интеграция теряется еще больше - плюс настройка доступа контейнера к сети и прочий гемор. Не для сисадминов - неюзабельно.

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

Это ты меня не понимаешь. «Мне» нужна НЕХ которая будет по сути связанным набором прикладных пакетов по некой тематической/профессиональной области, «рабочее место» человека выполняющего какую то *работу*(хобби, неважно, прикладное дело). По «сложности» разработки НЕХ будет чем то вроде дистрибутива (надеюсь что все же проще чем), которая будет ставится в /opt или $HOME . Информацию о своих пакетах оно может хранить хоть у себя, хоть в системе, как удобней разработчикам.

Суть такой штуки в том что платная поддержка вещь до жути тематическая. Никто не платит за поддержку «парни у меня баг» - только в случае навязанных услуг как у оракла того же. Платят за поддержку «парни мне надо сделать с помощью вашего продукта такую-то фигню - КАК?». Соответственно 99% дистрибутивов в плане заработать с поддержки обречены на провал -> фейл линукса и FOSS на 99% рабочих десктопов.

Кстати, было бы здорово увидеть сборку с xmonad - потому, что это автоматически потребует качественной Haskell Platform.

Их в бранче нет что ли, пусть и не самых свежих?

Кстати, было бы здорово увидеть сборку с xmonad - потому, что это автоматически потребует качественной Haskell Platform.

Согласен, в TODO.

Нынешний Сизиф скоро превратится в p7, на основе которого будут выпущены стабильные дистрибутивы. Альфа-версия Centaurus вышла вчера, альфа Симпли сейчас проходит внутреннее тестирование, возможно сегодня выйдет. Нам важно довести и поддерживать Сизиф на высоком уровне актуальности и контролировать его уровень стабильности, потому сы автоматизируем сборки образов, удобные для тестирования. Это позволит не только отделить хороший бранч, но и поддерживать его, в частности обновлять свежими апстримными разработками, достигшими приемлемого качества. Не понимаю, при чем тут ресурсы. Конечно, их всегда мало, потому мы автоматизируем технологический процесс и стараемся расширить число желающих тестировать за счет упрощения установки свежих версий и избежания проблем local misconfiguration у тестеров.

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

Какая интеграция теряется? Все приложения запущены на одном X-сервере, никто не мешает bind mount хомяк в чрут или контейнер. Что еще тебе нужно?

Для протокола: запускать один «почти дистр» в другом мне кажется идиотизмом, но технических препятствий я не вижу.

Не для сисадминов - неюзабельно.

Сделай инструмент для настройки. Ах да, нужны не инструменты, а НЕХ, которая просто работает... засада, чо.

Это ты меня не понимаешь.

Объясняешь плохо.

«Мне» нужна НЕХ которая будет по сути связанным набором прикладных пакетов по некой тематической/профессиональной области

Это уровень объяснения «мне нужна кнопка „сделать збс“».

Нам важно [технический пиар поскипан]

Я понимаю, «нам важно удовлетворять клиентов, а не преследовать химеры вроде Componentized Linux». А мне важно другое.

А мне важно другое.

Преследовать химеры?

Какая интеграция теряется? Все приложения запущены на одном X-сервере, никто не мешает bind mount хомяк в чрут или контейнер. Что еще тебе нужно?

Ага-ага. Сразу видно админа-линупсоида 80го уровня. Что, и в dbus хоста пошлет мессагу из контейнера? Что и всякий kde-кпартс сможет послать-сконнектится с хостом? Вся интеграция с десктопом будет работать? Прямо таки вся? И принтеры там локальные автоматом появятся, в софте контейнера?

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

Для протокола: запускать один «почти дистр» в другом мне кажется идиотизмом, но технических препятствий я не вижу.

Под chroot - да, и с муторной настройкой и без интеграции на уровне десктопа. Как раз для запуска серверов каких нибудь.

Сделай инструмент для настройки. Ах да, нужны не инструменты, а НЕХ, которая просто работает... засада, чо.

Эти инструменты в случае chroot будут работать от рута, и каждый раз делать chroot от рута. И потенциально будут дыркой на дырке - ну и нафиг такое нужно? Если просто подойдет правильно скомпиленный репозиторий пакетов? Все что не libc прекрасно переопределяется(имхо) на уровне LD_LIBRAY_PATH

Объясняешь плохо.

Я читая тебя понимаю почему этот наш линупс в такой опе на десктопах.

«Мне» нужна НЕХ которая будет по сути связанным набором прикладных пакетов по некой тематической/профессиональной области

Это уровень объяснения «мне нужна кнопка „сделать збс“».

Только „сделать збс» уже сделали, называется например стим(или десура). И оно работает - что резко снижает пафос о том что «нифига непонятно чего ты хочешь - все есть». Вот - хочу такое, но с фильдеперсовыми пуговицами.

/facepalm Это я слишком тонко пошутил :) В новости было написано «мейнтейнер гнома в отпуске». А дистр русский.

Толще надо быть, толще :-)

Ага-ага. Сразу видно админа-линупсоида 80го уровня.

Для протокола: 1) я не админ вообще 2) это не я предлагал идею дистра в дистре.

Что, и в dbus хоста пошлет мессагу из контейнера?

Давай ты не будешь говорить загадками. Если ты пробовал и не получилось - ок. А так - я думаю, всё это настраивается, namespace'ы для этого и придуманы. Даже если DBus работает через UNIX-сокет, система из чрута может связаться с хостом.

И принтеры там локальные автоматом появятся, в софте контейнера?

Служба печати по сети работает, насколько я знаю.

Что и всякий kde-кпартс сможет послать-сконнектится с хостом?

Зависит от IPC под капотом KParts.

Эти инструменты в случае chroot будут работать от рута, и каждый раз делать chroot от рута

Рут нужен, чтобы войти в чрут. После этого его можно дропнуть.

„сделать збс» уже сделали, называется например стим(или десура). И оно работает

Не нужно петь военных песен. У Стима (точнее, игр для него) есть системные требования, которым отнюдь не весь парк инсталлированых систем удовлетворяет. И CL дал бы возможность проапгрейдить только нужные компоненты этих систем вместо полного апгрейда на другую ветку дистра.

что резко снижает пафос о том что «нифига непонятно чего ты хочешь - все есть»

Мде. Это только подогревает градус недоумения - есть и работает даже больше, чем я думал, чего тебе еще надо?

Вот - хочу такое, но с фильдеперсовыми пуговицами.

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

Для протокола: 1) я не админ вообще

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

2) это не я предлагал идею дистра в дистре.

Я тебе уже не знаю как обьяснить, уже «и унитаз приносил и задницу показывал»(С)

Давай ты не будешь говорить загадками. Если ты пробовал и не получилось - ок. А так - я думаю, всё это настраивается, namespace'ы для этого и придуманы. Даже если DBus работает через UNIX-сокет, система из чрута может связаться с хостом.
Служба печати по сети работает, насколько я знаю.
Что и всякий kde-кпартс сможет послать-сконнектится с хостом?
Зависит от IPC под капотом KParts.

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

Рут нужен, чтобы войти в чрут. После этого его можно дропнуть.

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

Не нужно петь военных песен. У Стима (точнее, игр для него) есть системные требования, которым отнюдь не весь парк инсталлированых систем удовлетворяет.
И CL дал бы возможность проапгрейдить только нужные компоненты этих систем вместо полного апгрейда на другую ветку дистра.

Это wishful thinking. Если в этих неподдерживаемых дистрах нельзя сделать свою среду которую обеспечивает стим - например там все настолько древнее что и X и libc не позволяют ничего - то там и нужные компоненты не проапгрейдить компонентами. Там всю систему апгрейдить/выкидывать.

CL это опять попытка выдумать «свой ЯП и свою ОС», эпохальное решение, когда нужен фактически тематический репозитарий. Который вследствие тех или иных технических мер способный работать в разных дистрибутивах - например потому что там пакеты собраны с зависимостями на lsb и свой репозиторий.

Мде. Это только подогревает градус недоумения - есть и работает даже больше, чем я думал, чего тебе еще надо?

Нету реализации «стима»(вместе с набором софта) в варианте FOSS для правильно выбранных профессиональных областей. Есть только для игр.

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

Это wishful thinking.

Естественно, потому что CL не существует. Но и Linux когда-то не существовало.

Но бинари работающие под рутом временно будут

Да ерунда это, чисто техническая деталь. Сделай программку входа в чрут через capability, например (есть специальная CAP_SYS_CHROOT)

например там все настолько древнее что и X и libc не позволяют ничего - то там и нужные компоненты не проапгрейдить компонентами. Там всю систему апгрейдить/выкидывать.

Технически проблема вполне решаема на уровне «сделаем из системы Слаку», так что...

CL это опять попытка выдумать «свой ЯП и свою ОС», эпохальное решение, когда нужен фактически тематический репозитарий.

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

Нету реализации «стима»(вместе с набором софта) в варианте FOSS для правильно выбранных профессиональных областей.

Ты объяснишь наконец принципиальную разницу между Стим и репозиторием LSB-пакетов?

Вы еблан, очевидно же.

(оглядываясь вокруг): и что, должно быть страшно?

Здесь вам не там. Там речь зашла о добровольности в выборе ОС и к чему такая добровольность может привести. Теоретически, разумеется, поскольку вложивший деньги в предприятие такой ситуации или не допустит, или расстанется с. ALT к примеру лучше бардака хотя бы тем, что предназначен изначально, даже не приспособлен а создавался изначально, для порядка. По тексту новости скажу просто: категорически приветствую. «Простым» пользователям, конечно и как обычно, «ненужно». Бог с ними. А как способ сделать и так уже годный инструмент ещё лучше, для тех кто понимает в хороших инструментах - однозначно да.

Welcome to Google Inc.

И сколько во всём мире корпораций Google? Спорить не стану, не знаю всех обстоятельств. Однако даже если и так, рискну предположить что это из тех исключений что лишь подтверждают правило.

Будет, конечно. Мейнтейнер Gnome сейчас в отпуске,

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

Повторюсь. Вокруг меня примерно так и происходит. Сидящие на линуксах девелоперы сами вольны выбирать себе систему; главное, чтобы этот выбор не становился помехой или каким-то отвлекающим фактором в работе. Серверные виртуалки - дебиан стэйбл, если не показано обратное. Но это, в целом, только потому, что тех.дир., начиная с какого-то момента, полюбил дебиан. До этого ему нравилась Зюзя, поэтому наш биллинг сертифицировался именно на Зюзе, и до сих пор «правильные инсталляции» делаются на Зюзе, AFAIK.

И это уже не первая такая контора в моей жизни.

Не очень важно, какого кошка цвета, главное, чтобы мышей ловила.

Ты объяснишь наконец принципиальную разницу между Стим и репозиторием LSB-пакетов?

target scope. Всё-таки, организовать установку игры в «контейнер» существенно, существенно проще, чем какого-нибудь Digikam'а или ещё какого Kdenlive'а.

Проще как по организации доступа к пользовательским данным (фактически, у игр из пользовательских данных - только сэйвгеймы, которые не предназначены для утаскивания куда-либо кроме такой же игры [той же версии]), так и по требованиям к окружению и «peer-пакетам» (для Digikam: kipi-plugins -> hugin ..., для Kdenlive - mlt).

Ты объяснишь наконец принципиальную разницу между Стим и репозиторием LSB-пакетов?

target scope.

Если я упакую в LSB-пакет игру, target scope будет одинаковая.

Всё-таки, организовать установку игры в «контейнер» существенно, существенно проще, чем какого-нибудь Digikam'а или ещё какого Kdenlive'а.

Я не являюсь ЦА Стима и у меня его нет - что представляет из себя этот контейнер? Стим гарантирует наличие в контейнере какого-то ABI? Или сам Стим предоставляет какие-то ABI/API, на которые только и может расчитывать игра? Если да, то чем он отличается от LSB?

Повторюсь.

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

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

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

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

Не верю в «только потому». Логичнее предположить что у него были достаточные основания.

Люблю этот дитр из ностальгических соображений.

Уважаю этот дистр из соображений сугубо практических.

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

Подтверждаю: впечатления актуальны и на сейчас. Есть причины. Проверено.

я сам жду уже отпочковывания p7, чтобы на него переползать. Сизифа опасаюсь, были прецеденты у меня, когда в погоне за шашечками не вовремя терял возможность ехать ;)

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

Или сам Стим предоставляет какие-то ABI/API, на которые только и может расчитывать игра?

Похоже, продоставляет. Глубоко не копал (не моя область интересов), так, потыкал пальцем. В общем, если стянуть тот же HL, например в альфу Centaurus, ругается что не может найти Steam для проверки легальности запуска или что-то вроде.

Давайте будем делать сборки для каждого wm, тех, что уже есть мало. Запишите лучше в TODO delta rpm.

Радуюсь, что мое отношение к Альту не напрасно, тоже жду p7 - с TDE, конечно :) Но хочется, чтобы причесали зависимости для тех пакетов, которые традиционно распространяются как «универсальные». Вот если Google Chrome, например, установится, - тогда будет круто ;) (поясняю: я знаю о Chromium и вообще не фанат хрома - это лишь тест на совместимость).

И вообще, прикрутить к Альту zypper от Суси! ;) К слову, я был бы такому рад.

В продолжение:
насчет zypper - хотите, считайте шуткой - но вот умеет ли с delta-rpm работать APT в принципе?

Вас что заставляют насильно качать эти сборки?

Это для тестирования - и замечательно что будет возможность а что там в свежем ... ждет или протестировать и сообщить о багах...

хочется, чтобы причесали зависимости для тех пакетов, которые традиционно распространяются как «универсальные». Вот если Google Chrome, например, установится, - тогда будет круто ;)

Да что там какой-то Chrome... Нет, хорошо конечно, однако Chrome нам зарплату не начисляет ;-) а 22-го платформа 1С для Linux ожидается, вот это будет точно ОН. Моими руками для количества Главных Бухгалтеров - обещаю, если зависимости причешут. Можно не сразу, и так уже больше десяти лет ждали и можно ещё чуть подождать. Но нужно, нужно.