GoboLinux - альтернативный подход

Ещё один .. "идеолог ..." http://community.livejournal.com/ru_linux/861354.html?view=9381034

>Есть такая идея: берём и прикручиваем к менеджеру пакетов интерфейс в виде ФС, например, через FUSE. Монтируем куда-нибудь в /var/lib/packages и наслаждаемся: ls /var/lib/packages/kde* или rm -rf /var/lib/packages/firefox. :)

А что, интересное решение.

а per-process namespace в Linux ещё нет :(

s/Program/Program Files
s/Settings/Document and Settings

s/GoboLinux/Винда

>> Личноя думаю что правильнее будет двигаться в направлении раширения фунций файловой системы, т.е. для данного случая "срастить" пактный менеджер и ФС

вам указать вектор направления или сами догадаетесь???

GoboLinux - извращение!
Надеюсь загнецца также быстро, как и RODlinux :-/

> Причём зависимости-то лажовые - одним (к примеру) нужен libpng-1.1.1, а другим - libpng-1.1.3

Вам сразу сказали, что Fedora Core - не серьёзный дистрибутив, а песочница для разработчиков. Если вы считали иначе - то сами себе злобный Буратино. :)

> При деинсталляции не нужно как муд@к бегать по /usr, /usr/local, /bin, etc, а достаточно удалить папку с устаревшей программой.

Именно мудаки и бегают по каталогам. Умные люди используют менеджеры пакетов. :)

>GoboLinux - извращение! Надеюсь загнецца также быстро, как и RODlinux :-/

+1

>> >Есть такая идея: берём и прикручиваем к менеджеру пакетов интерфейс в виде ФС, например, через FUSE. Монтируем куда-нибудь в /var/lib/packages и наслаждаемся: ls /var/lib/packages/kde* или rm -rf /var/lib/packages/firefox. :) А что, интересное решение

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

>>>Есть такая идея: берём и прикручиваем к менеджеру пакетов интерфейс в виде ФС, например, через FUSE. Монтируем куда-нибудь в /var/lib/packages и наслаждаемся: ls /var/lib/packages/kde* или rm -rf /var/lib/packages/firefox. :) А что, интересное решение

>>тогда уж бинарики и шаред обжекты можно хранить в запакованном файле образе (пакете)... но таки опять изобретаем костыли...

Эээ товарисчи а в slackware давно есть /var/log/packages :)

>> Эээ товарисчи а в slackware давно есть /var/log/packages :)

да не, я про велосипед аля жабные пакеджи (.jar) где "все" в одном флаконе и только динамика отдельно в песочнице

> дистрибутив не видел, на сайт не ходил, но судя па каментам, кг/ам

В кои-то веки этот подход оказался ВЕРНЫМ! :-)

> при отсутствии нужной программы в репозитории любой дистр становится source-based...

Ну так резко я бы не стал высказываться. Ebuild, например, пишется за пару минут, да и checkinstall ещё никто не отменял.

"Разруха она не..." (C)

Идея не нова, как уже писали выше все это похоже на организацию FS из NeXTStep, но только похоже. Как многие тут говорили, что все похоже на MacOSX - похоже, т.к. ноги растут из NeXTStep. http://en.wikipedia.org/wiki/NeXTStep. Если кто-то хочет сказать, что это революция, то я отвечу просто - "Этой революции в обед 100 лет, и она была как минимум в 1988 или 1989 году." Данный подход - в чем-то хорош, но как быть с консолью? В той же MacOSX - все что является *nix наследием лежит в своих дирах, даже /etc не тронут. А все, что относится к свистелкам и пределкам, лежит в новой структуре каталогов. Скажу чесно, меня немного начинает бесить запуск некторых вещей из консоли. Надо набирать пути к апликухам, в них искать исполняемый файл и запускать его, в GNUstep c этим попроще - openapp, чего в MacOS - нет. Возникает вопрос зачем использовать консоль? Отвечу: по работе необходимо установка и отладка драйверов, потом есть некоторые GUI приложения, которые являются обертками, а проги используются консольные и данные от них передаются врапперу. Иногда мне надо получить данные напрямую, зачем и вызывается консольное приложение.

ЗЫ Если человек хочет альтернативу вантузу, то он должен изучить эту альтернативу, а не загибать пальцы и кричать - "Хочу как в вантузе!". Для тех, кто хочет как в вантузе - KDE + CP, как было уже сказано.

/Programs/GNU Ls/ls /Programs/GNU Rm/rm /Programs/GNU Tar/tar /Programs/Bzip2/bzip2

???

Совсем о...ели ?

Интересная новость. Интересный дистрибутивчик. Симпотичный дизайн у них :)

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

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

>а не копаться в системных папках

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

>В общем респект и уважуха

масло масляное. чему удивляться - вантуз разрушает моск

>А то порасбросали все непойми куда.

открой для себя команды-запросы к пакетному менеджеру

>А в винде?? ИМХО супер удобная схема размещения как юзерских профилей, так и системных файлов.

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

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

>Кстати авторы дистрибутива идут путем наименьшего сопротивления - большинство программ ставится без каких либо патчей - достаточно указать правильный --prefix для automake. Очень по моему логичный ход - вместо того чтобы иметь 101 разных KDE для разных дистрибутивов, гораздо удобнее иметь только один с самого сайта KDE. И сизифов труд ментейнеров пакетов можно было направить в более полезное русло.

prefix для automake + кучу путей для pkgconfig. Как вариант кучу symlinks, которые надо удалять, что далеко нетривиально. Когда-то, когда был маленьким и глупым, пользовал свой дистр, собранный по такому принципу. Геморой ещё тот... Сейчас мспользую Gentoo, если чего надо нестандартное, гораздо проще сделать ebuild.

101 разных KDE для разных дистрибутивов - этим занимаются не разработчики KDE, а разработчики дистрибутивов. Если GoboLinux считают, что их подход верный, пусть сами и "ментейнят" :)

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

Попробуй сначала сам :). Да, ещё один момент. Иногда предпочтительно хранить бинарники на RO разделе и монтировать RW только при обновлении. SELINUX и прочую новою моду я не очень люблю, да и вносит она ненужную задержку - у меня на серверах не тысячи разных сервисов лежит, чтоб не разнести их по пользователям. А так быстрая защита от подмены, врядли какой exploit сможет перемонтировать FS. А вот как здесь разнести то, что лежит в /usr/bin, /usr/share, /var/lib, etc.

> И опять же - классический юникс это конечно круто, но при возможностях современного железа можно сделать еще лучше и удобнее. Ничто не должно стоять на месте и ИМХО данный дистрибутив основан на очень интересной и вполне логичной концепции.

Да... эту логику мне не понять...

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

нифига неудобно. вместо rpm -i/emerge/... которое работает и на удаленной машине за много км от тебя, фигня для быдлогуманитариев

>>А теперь представь себе, как разрастется PATH. PATH=/Programs/то:/Programs/сё:/Programs/и_ещё:/Programs/и_так_на_каждую_програм му

>Еще один мегамоскЪ или просто неопытный тролль. В PATH скорее всего дира с симлинками.

А теперь представь, стоит пакет в /Programs/someapp, бинарники в bin, данные в data, библиотека в lib. Что будет, если библиотека, которую открыли по symlink из /Libraries/someapp.dll.so полезет за своим файлом в ../data ? И вообще, почему русскоязычные пользователи не кричат: "Хочу библиотеки в /Библиотеки, а не /Libraries!!! И вообще, что это за чёрточка перед именем каталога!!!" :-D

>> В PATH скорее всего дира с симлинками.

>Наверняка так, а как же иначе.

>И что в результате? Чтобы удалить пакет, надо удалить каталог пакета, а еще вычистить линки в /usr/bin, /usr/man. Где объявленная легкость управления пакетами путем манипуляций с каталогами?

+1. Люди, сначала попробуйте сами или хотя бы представьте, потом делайте!

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

Я тут поговорил с Юниксом, он мне сказал, что это всё ложь и правокация, и что он ни в чем таком не нуждается. "Так как то что"... чему вас только в школе учат?

>есть задачи, для которых дос самое то [skip] >И замыкаться на юниксах и винде не стоит.

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

> Для тех, кто хочет как в вантузе - KDE + CP, как было уже сказано.

KDE - правильный Unix-way, он к вантузу никаким боком. Кстати, куда в GoboLinux засунули утилиту dcop? А meinproc? А kcmshell? :)

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

угу, а дай им логарифмическую линейку так будут искать куда там батарейки вставляюцо

> А в винде?? ИМХО супер удобная схема размещения как юзерских профилей, так и системных файлов.

Одни только пробелы в названиях системных каталогов внушают порой негуманные мысли о применении средневековых пыточных средств к тем, кто эту схему придумал. А уж про, мягко говоря, непростоту разноса %windir%, Program Files и Documents and Settings по отдельным разделам (какой <censored> придумал C:, D:, и т. д.?) вообще молчу

Все комменты "ниасилил", а по поводу новости... ну на лицо виндузятнеговский подход!

Говорите от пакетов отказаться? А как тогда зависимости выполняются? Ведь не статически же линковать все вподряд.

По поводу удобства: если кто-то говорит, что непонятна структура каталогов текущая, мол искать все тяжело... то спрашивается, а на кой черт придумали PATH=.... кстати говоря. При этом "революционном" подходе в несчастную PATH нужно записать будет столько... что все удобство копирования сводится на нет.

Согласитель удобнее набрать в консоли superprog, чем c:\Program Files\SuperProg\superprog.exe :D D: :D

ИМХО весь этот "революционный" поход либо затея только что пересевшего на Линукс виндузятнега, либо для привлечения оных...

> А уж про, мягко говоря, непростоту разноса %windir%, Program Files и Documents and Settings по отдельным разделам (какой <censored> придумал C:, D:, и т. д.?) вообще молчу

Ну это-то просто. Оно в реестре хранится. Собственно, как линуксоид обязан разбираться в /etc, так форточник обязан в реестре. :)

>Стандарты соблюдены симлинками :) Вот если бы /usr/bin и пр. каталогов не было бы вовсе, вот это было бы несоблюдение. Не нравится запускать текстовый редактор как /Programs/Vim/vim -- не надо, запускай как /usr/bin/vim, там для тебя симлинк лежит.

Так даже и /Programs/Vim/vim или /usr/bin/vim не нужно запускать. Просто vim. Насколько я понял, это будет работать также без проблем, так как они (переопределили?) пути в $PATH

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

+1 Смотрю вот на дистр, вроде интересно..

/dev/ и /etc/ писакть ИМХО быстрее, чем Programs/ и т.д. (+к шифту тянуцо)

Посвящается гуру-анонимусам.

И ведь верно, с той минуты Стал ходить дурак надутый.

То и дело он, дурак, Говорит другим: - Не так!

Он не плачет и не пляшет, А на все рукою машет.

Постороннему никак Не узнать, что он дурак.

Дети буквы пишут в школе, Да и спросят: - Хорошо ли?

Поглядит в тетрадь дурак, Да и вымолвит: - Не так.

Шьют портнихи на машинке, Шьют сапожники ботинки.

Смотрит издали дурак И бормочет: - Все не так!

И не так селедок ловят, И не так борщи готовят,

И не так мосты мостят, И не так детей растят!

Видят люди, слышат люди, Как дурак дела их судит,

И подумывают так: "Что за умница дурак!"

С.Я. Маршак

> Единственное - имена у них с большой буквы и длиннее стандартных - набирать сложнее.

ИМХО всё заточено под zsh - без него там никуда.

Кстати... возьмем gentoo:
KDE там в /usr/kde/3.5, Qt в /usr/qt/3, ранлевелы в /etc/runlevels...

>Говорите от пакетов отказаться? А как тогда зависимости выполняются? Ведь не статически же линковать все вподряд.

О! По твоему в слаквари все статически слинковано, ибо зависимостей нет? А мужыки-то не знают!

> При этом "революционном" подходе в несчастную PATH нужно записать будет столько...

директорий с симлинками :)

>Вообще как я понял, на сайт дистрибутива никто не потрудился заглянуть.

Да нет, я там по всем разделам прошелся. Дизай отличный :) И идея необычная.

>большинство программ ставится без каких либо патчей - достаточно указать правильный --prefix для automake. Очень по моему логичный ход - вместо того чтобы иметь 101 разных KDE для разных дистрибутивов, гораздо удобнее иметь только один с самого сайта KDE. И сизифов труд ментейнеров пакетов можно было направить в более полезное русло.

У них есть какие-то рецепты (аналог spec-ов?) и пакеты (аналог rpm-пакетов?), так что мэйнтейнеры GoboLinux мало чем отличаются от мэйнтейнеров других дистрибутивов -- только --prefix разные ставят )

>Ничто не должно стоять на месте и ИМХО данный дистрибутив основан на очень интересной и вполне логичной концепции.

Согласен.

>Этот дистрибутив - говно.

OMG! И такое позволяет себе говорить модератор. Вот скажи я что-то подобное, так ты бы удалил, а сам?! Позор. :(

> Надеюсь загнецца также быстро, как и RODlinux

Эт вряд ли. Он старше Gentoo :)

>Кстати, защищающие этот дистр поголовно тролли, а Linux видели на уровне "при мне включали", а как компьютер работает - не понимают.

Чушь собачья. Вот кто троллит, так это ты.

>Может закрыть этот топик? Спорить тут вроде не о чем.

Лучше иди занимайся своими делами.

Пробовал 012. Запутался со сборкой драйверов. Gentoo намного проще в установке. Или хотя бы лучше документирован.

Что-то я не пойму, чего все так на Gobolinux наезжают. Да, идея странная. Да, спорная. Но ведь у кого-то нормально работает. Сами подумайте, если Gobolinux загнётся, все эти люди так просто не исчезнут. Они пойдут внедрять те же идеи в другие дистрибутивы :)

Так что пожелаем им успехов в их нелёгком труде и долгой жизни. В соседней палате.

>он в макоси сделали все так же, как и ребята...и что??

Когда мы в последний раз видели МакОСь? Наверное в какой-нить бете 2000-го года... А правда жизни такова: в макоси есть Applications в SuSE есть /opt и найди 5 отличий... Так что афтару низачОт за незнание МакОСи...

> Есть такая идея: берём и прикручиваем к менеджеру пакетов интерфейс в виде ФС, например, через FUSE. Монтируем куда-нибудь в /var/lib/packages и наслаждаемся: ls /var/lib/packages/kde* или rm -rf /var/lib/packages/firefox. :)

На Федоре работает: в mc - <Alt>-<C> #rpms <Enter> .

> при отсутствии нужной программы в репозитории любой дистр становится source-based...

Открой для себя checkinstall .

> Считаю, что это абсолютно правильная мера. Все эти "менеджеры зазипованных программ" - херня полнейшая, создают больше неудобств, чем решают проблем. Буквально намедни в стоящий FC5 попытался всунуть пакет от FC6. Казалось бы, надо только встать рядом (или проапгрейдить существующий пакет), но нет, у них, мля, "зависимости"! (к слову, это был пакет OpenSSL) Причём зависимости-то лажовые - одним (к примеру) нужен libpng-1.1.1, а другим - libpng-1.1.3; Спрашивается, эти библиотеки НАСТОЛЬКО отличаются, что надо выпендриваться??!! В жизни не поверю!

А ты посмотри, потом будешь говорить, что не поверишь :) Но реально, болишинство таких зависимостей решаются пересборкой пакета - на уровне исходных текстов обычно не такое сильное. Версии меняются в основном когда набор аргументов изменился, функция стала deprecated или исчезла совсем. Если просто расширился функционал или внутренности, версия не меняется.

> И структура выбрана, считаю, совершенно верная - в одном месте программки (с либами), в другом - конфиги, то и другое быстро находится. При деинсталляции не нужно как муд@к бегать по /usr, /usr/local, /bin, etc, а достаточно удалить папку с устаревшей программой.

И бегай, "как муд@к", удаляй symlinks :-D

> Эх, на дворе 21 век - Линукс начал становиться лучше! :)

А вот с этим согласен на 75% - нужно изложить в следующей редакции: "Линукс постоянно становится лучше" ;-)

>> Буквально намедни в стоящий FC5 попытался всунуть пакет от FC6.

>Как там Саныч говорил? А, точно! "А можно еще хер себе дверью специально прищемить и потом всем рассказывать про неправильные двери."

+1. Не знаю, кто такой Саныч, но эту фразу я запомню и буду выдавать за свою :)

> Личноя думаю что правильнее будет двигаться в направлении раширения фунций файловой системы, т.е. для данного случая "срастить" пактный менеджер и ФС. И ФС сама уже предлагала услуги ПМ по удалению/установке программы, тогда для пользователейвсе станет еще прозрачнее, а раскидывать все по отдельным неправильно, причины тут описывали выше, я с ними на 100% согласен!

Не совсем так. Это не задачи ФС. Расширение не должно быть быть безграничным, иначе будет Big Bang :) Есть замечательнейшие вещи, в частности упоминаемая здесь FUSE, тако можно спокойно возложить на неё.

> Есть такая идея: берём и прикручиваем к менеджеру пакетов интерфейс в виде ФС, например, через FUSE. Монтируем куда-нибудь в /var/lib/packages и наслаждаемся: ls /var/lib/packages/kde* или rm -rf /var/lib/packages/firefox. :)

> А что, интересное решение.

+1. А вообще я бы много на неё возложил... Очень много есть програм, которые думают, что пользуются только ею.

> Этот дистрибутив - говно.

+1

Гениально :)

>>> Есть такая идея: берём и прикручиваем к менеджеру пакетов интерфейс в виде ФС, например, через FUSE. Монтируем куда-нибудь в /var/lib/packages и наслаждаемся: ls /var/lib/packages/kde* или rm -rf /var/lib/packages/firefox. :) А что, интересное решение

>> тогда уж бинарики и шаред обжекты можно хранить в запакованном файле образе (пакете)... но таки опять изобретаем костыли...

> Эээ товарисчи а в slackware давно есть /var/log/packages :)

Посмотри на название каталога и сразу станет ясно, что там не пакеты лежат :)