gobolinux - «другой» подход к установке приложений

1. Боян
2. Не LSB
3. Не труЪ
4. Винда уже есть

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

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

>А в чем плюсы?

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

по сути, это пакетный менеджер на уровне ФС

Анон дело говорит! меньше костылей!

>Винда уже есть

у венды есть реестр, который не даёт удалять или устанавливать пакеты простым созданием/удаления каталога

А как быть с общими библиотеками?

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

хардлинки

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

Ну да, гента ж есть.

а можно и без генты

можно бинарники распространять в простом архиве, распаковал в /programs - и пакет установлен

Пользователь может воплощать свои фантазии в ~/, остальное логично держать в соответствии со стандартами, тем более, что FHS вполне логичен и удобен.

>FHS вполне логичен и удобен

говно этот ваш FHS, нелогичное и неудобное говно

пакетный менеджер по сути - лишняя сущность

А если корневая фс их не поддерживает? Для встраиваемых систем очень актуальное ограничение.

И потом, удаление пакета с учетом зависимостей все равно не удастся свести к удалению директории. Все сведется в скриптам с поиском по хардлинкам, что в итоге выродится в те же пакетные менеджеры.

в итоге будет в системе толпиться по 10 версий одной библиотеки, т.к. производители софта будут тащить за собой бинари, вместо того чтобы тестировать работоспособность с различными версиями либ. dll hell уже проходили.

зачем при удалении что-то там искать? пока какая-нибудь библиотека используется хоть одним пакетом, он останется в системе

вот механизм установки непонятен

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

>пока какая-нибудь библиотека используется хоть одним пакетом, она останется в системе

fxd

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

>в макоси ровно такая ситуация: каждая приблуда тащит на десятки, а то и сотни мегабайт бинарей

каких бинарей?

Это идиотизм.
Хотя бы потому, что нужно либо городить костыли, складывая симлинки на все исполняемые файлы в одну директорию (что они вроде как сейчас и делают), либо вызывать все бинарники по полному пути (что люто неудобно), либо раздувать $PATH до размера в 100500 Гб (что даст лютые тормоза и необходимость менять этот $PATH после установки/удаления каждой версии какой-либо софтины).

Далее, представь, что тебе нужно перенести конфиги с одной машины на другую (ну или банально забэкапить, этот вариант даже лучше). В нормальной системе ты запихаешь в архив /etc и будешь доволен, как слон. В УГобоЛинуксе ты будешь вытаскивать конфиги по одному из каждой директории (либо опять городить костыли в виде симлинков, теперь уже на конфиги).

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

не останется, т.к. первая удалится, а вслед за ней и вторая

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

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

Давно читал про этот дистрибутив. Интересно, конечно, но мне не показалось юзабельным. Между прочим, файлы в корне скрываются специальным патчем к ядру, т.е. все ваши /etc и /usr там тоже есть.

Хотя, мне например не хватает утилиты, которая бы скрывала файл без переименовывания его с "." в начале.

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

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

В зоопарке Линукса минус конкретный - нет стандартного набора либ.

У МакОС он есть и перманентен в определенной ветке.

Хотя те же Убунту и КрасноШап вполне могут ввести такие правила установки приложений (лишь бы были приложения). А приложений не просматривается.

Вообщем, шо я хочу сказать.... На сегодня AppStore - такая же панацея, как и репы в 2003 году. Завтра придумают еще чего нового и АппСтор утратит актуальность.

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

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

В будущем нас ждет ОС на sd-карточке вставленная в какой-нибудь быстрый картридер, место под него уже есть и в настольных ПК (вместо флопа) и в ноутбуках.

Все закончится банально - вставил карточку , загрузился и скирдуешь приложения на винт, а на карточке крутится донельзя зативоизированная ОС.

>> В зоопарке Линукса минус конкретный - нет стандартного набора либ.

Анабиозники ITT. man LSB.

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

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

На сегодня AppStore - такая же панацея, как и репы в 2003 году.

AppStore - средство выманивание денег у пользователей. Это единственная цель его создания. Мы контролируем средства разработки, мы контролируем способ получения программ. Что такого «панацейного» ты нашел для простых пользователей - вопрос.

Зависни на пару минут и подумай о том, что ты написал...
Не торопись с выводами, ОК?

...
Ладно, разовью тему.

Каким боком ЛСБ к Приложению АБСver1.1, которое требует lib-sys-crap-1.5.5, а в системе по всем правилам ЛСБ установлена lib-sys-crap-1.4.3?

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

а никто и не спорит, что АппСтор лохотрон,
но таки эффективный, иначе бы некоторые не орали во всё горло о 10млрд загрузок.

что за полумеры? пускай будет каждопу приложений свой chroot и отдельное ядро. а лучше вообще каждому приложению свой компьютер. мудаки ж не слашли про _разделяемые_ библиотеки.

> Что такого «панацейного» ты нашел для простых пользователей - вопрос
Стандартный механизм обновлений. Единая платежная система. Единый подход к маркетингу. Покупка, упрощенная до одного клика. В общем, с т.зр. юзабилити - куча плюшек

Мне `chflags hidden` не хватает их Mac OS X. Там вроде как bash, т.е. все скрывается видимо ядром, а метаданные в ФС.

В план9 проблема решена кардинальным образом: там тупо нет динамических библиотек и всех связанных с ними проблем (включая такую распространенную у пуристов проблему как необходимость тащить кучу мегабайт неиспользуемого кода, только потому что устанавливаемой программе потребовалось использовать пару функций одной из библиотек). Правда я все-таки за умеренное их использование. То бишь нет смысла грузить десятки библиотек, как сейчас в линуксе, но и абсолютная статичность тоже не самый лучший вариант (например опенгл работает только из-за поддержки системами динамических библиотек) лучше выделить основные функции, которые используются 90% программ и вынести их в динамические библиотеки.

Вроде эта система используется в Mac OS.

Базовую иерархию там никуда не дели пока что.

madpower# cd /mnt/osx/
madpower# ls -l
итого 20744
drwxrwxr-x 1 root cdrw       37 Янв 29 18:03 Applications
drwxr-xr-x 1 root root       40 Июл  6  2010 bin
drwxrwxr-t 1 root cdrw        2 Сен 25  2008 cores
lrwxr-xr-x 1  501 cdrw       22 Ноя 20 21:48 Desktop -> /Users/madcore/Desktop
-rw-r--r-- 1 root cdrw     2048 Ноя 23 21:43 Desktop DB
-rw-r--r-- 1 root cdrw     6914 Ноя 23 21:42 Desktop DF
dr-xr-xr-x 1 root root        2 Сен 25  2008 dev
drwxrwxr-x 1 root cdrw       17 Дек 22 00:09 Developer
lrwxr-xr-x 1 root cdrw       11 Июл  6  2010 etc -> private/etc
dr-xr-xr-x 1 root cdrw        2 Июл  6  2010 home
drwxrwxr-x 1 root cdrw       52 Ноя 21 00:58 Library
-rw-r--r-- 1 root root 10367028 Июл 16  2009 mach_kernel
-rw-r--r-- 1 root root 10822172 Июл 16  2009 mach_kernel.ctfsys
lrwxr-xr-x 1  501 cdrw       24 Ноя 20 21:48 My Documents -> /Users/madcore/Documents
lrwxr-xr-x 1  501 cdrw       20 Ноя 20 21:48 My Music -> /Users/madcore/Music
lrwxr-xr-x 1  501 cdrw       23 Ноя 20 21:48 My Pictures -> /Users/madcore/Pictures
lrwxr-xr-x 1  501 cdrw       21 Ноя 20 21:48 My Videos -> /Users/madcore/Movies
dr-xr-xr-x 1 root cdrw        2 Июл  6  2010 net
drwxr-xr-x 1 root root        2 Сен 25  2008 Network
drwxr-xr-x 1  501 cdrw        2 Июл 13  2010 opt
drwxr-xr-x 1 root root        6 Июл  6  2010 private
drwxr-xr-x 1 root root       66 Ноя 21 15:37 sbin
drwxr-xr-x 1 root root        4 Июл  6  2010 System
lrwxr-xr-x 1 root cdrw       11 Июл  6  2010 tmp -> private/tmp
drwxr-xr-x 1 root cdrw        5 Июл  6  2010 Users
drwxr-xr-x 1 root root       14 Ноя 21 00:58 usr
lrwxr-xr-x 1 root cdrw       11 Июл  6  2010 var -> private/var
drwxrwxrwt 1 root cdrw        3 Янв 29 18:05 Volumes

Ты мою мысль не понял (-;

На сегодня AppStore - такая же панацея, как и репы в 2003 году.

AppStore это и есть репозиторий. На сегодня репозиторий - такая же панацея, как и репы в 2003 году. Видишь?

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

Почему же лохотрон? Платишь за программы - уже лох? Да ну? Я говорю, что AppStore - это репозиторий.

> Мне `chflags hidden` не хватает их Mac OS X. Там вроде как bash, т.е. все скрывается видимо ядром, а метаданные в ФС.

В смысле, скрывать хотим? Тогда man setfile

Оно разве не для OS X? Мне для linux вроде как.

Значит, у меня парсер сбоит.

`chflags hidden` так любой файл или каталог скрыть на OS X можно. Мне довольно давно lost+found каталоги глаза мозолят в ext4 (-; Хочу скрыть.

что FHS вполне логичен и удобен.

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

хотя где про AppStore linux овский почитать можно?

> dll hell уже проходили.
А dependency hell пока еще нет? Одно не лучше другого. Надо золотую середину искать.

> each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way

Они, видимо, не в курсе про rpm -qa, -ql, -qf

Вообще, мне кажется и там и там есть плюсы для разных ситуаций, так что неплохо было бы замутить смешанный вариант. Все те программы, которые сейчас входят в любой дистрибутив, пускай остаются как есть, потому что удобно как минимум держать все бинарники в одном PATH, чтобы можно было их запускать в любой момент откуда угодно, ну и общие библиотеки тоже нужно как-то разруливать. А всякую левую хрень бинарную типа игрушек и каких-нибудь фотошопов лучше держать изолированно в отдельном каталоге - в том числе для того, чтобы не размазывать разное г. по всей системе и в случае чего его можно было бы удалить одной кнопкой в файловом менеджере. Например, я все игрушки распаковываю в ~/apps/games (мог бы и в /usr/local, но вообще не люблю дальше /home вылезать). Магазину приложений в таком виде левыми пакетами тоже было бы проще рулить - каждый сидит в своем каталоге, зависимости разрешить только от общесистемных библиотек. А если бы ему по умолчаюнию было бы разрешено писать только в отдельный подкаталог в хоуме у запустившего его пользователя и больше никуда (а не в весь хоум как сейчас), было бы вообще замечательно - для примеров см андроид-маркет и например вайн.

и PATH гигабайтных размеров, с записью каждой crapsoft.bin

bender уже сказал: основные библиотеки в своих привычных директориях, crapsoft.bin и ко в собственном номере от куда они могут вылететь одним движением руки!