Система klik (http://klik.atekon.de/) представляет собой коллекцию пакетов программ, устанавливаемых в "один клик", без оглядки на проблемы с зависимостями.
Идея в том, что в пакет помещается не только программа, но и все необходимые для работы библиотеки и компоненты, что позволяет использовать данный пакет под любым Linux дистрибутивом.
Пакет устанавливается в обособленную директорию, а точнее локально монтируется, так как представляет собой сжатый образ.
Обзор klik можно прочитать в статье "One-click installation with Klik (http://www.linux.com/article.pl?sid=05/10/27/1948248)".URL: http://klik.atekon.de/
Новость: http://www.opennet.me/opennews/art.shtml?num=6423
немного покликал, и 200 гиг хард закончился.
имхо дурацкая идея...
>немного покликал, и 200 гиг хард закончился.
>имхо дурацкая идея...для нормального линуксоида - конечно непривычно и похоже на бред.
Но вот задумайся почему виндузянтикам тяжело даже думать о переходе налинух?
одна из огромнейших проблем: их пугают горы либ и зависимостей. Не то шо в винде: каждая прога принесла зависимости с собой и все. Там ПРОСТО поставить прогу. Вот если так будет и в линухе - народу больше на него перейдет.
Ну и если например для тебя место на винте не проблема (нормальная контора, где все лицензионное и ессьно никакой музыки и фильмов на винтах нет) - то там обычный 120 гиг винт просто пустует, а админ е%ецца с зависимостями. А вдь klik - весьма неплохой выход в такой ситуевине.
В нормальной конторе не должно быть зоопарка дистрибутивов (максимум две-три версии одного-двух дистрибутивов), и админы конечно же должны уметь пользоваться пакетным менеджером.
>>немного покликал, и 200 гиг хард закончился.
>>имхо дурацкая идея...
>- народу больше на него перейдет.И, пардон мой французский, нахуа?
Нафига ещё десять миллионов леммингов-кликарей?
Лучше уж вкурить идеологию и перейти "по убеждениям", а не из-за моды или "крутости".
>И, пардон мой французский, нахуа?
>Нафига ещё десять миллионов леммингов-кликарей?
>Лучше уж вкурить идеологию и перейти "по убеждениям", а не из-за моды
>или "крутости".1) Не хотите - не пользуйтесь.
2) Должно быть так - большинство прог выпускается в чём хочет (сырцы, бинарники динамические, статические и т.п.) и обязательно этот klik-пакет. Как базис. Т.е. если ты продвинутый - то и не думаешь про этот klik, а обычный юзверь, если совсем уж тошно, ставит klik, да место, но если сильно надо то уж лучше как-то прогу пользовать, чем от неё совсем оказаться.
3) Количество "умных" пользователей и "глупых" не меняется. Если всех принуждать крутить зависимости и в консоли команды давать, то обычные пользователи просто откажуться от такой системы.
4) Неужели ещё кому-то нужно объяснять, что увеличение количесва пользователей линукса идёт ему только на благо?! Драйвера забыли? Когда finereader, lingvo и т.п. появится? Не тогда ли, когда хотя бы 10% линукс займёт на десктопе?
5) Ну и, чтобы пресечь возможные гневные выкрики - от увеличения количества леммингов, сидящих на линуксе, увеличения количества "дружественных" программ с тупыми мастерами настройки, количество хакеров не уменьшиться, количество утилит, делаемых по юникс-вэй не уменьшиться. Просто добавиться куча хлама в "дружественные" дистрибутивы, которые можно не ставить и юзать слакварь, но зато с полноценными драйверами под видеокарту и SB Live 7.1. и подобное железо.
Если это будет не как основной формат, почему бы и нет, но не в коем случае не как доминирующий.
finereader - действительно не хватает, lingvo же нафиг не упёрся - есть на порядок превосходящие его аналоги
>Если это будет не как основной формат, почему бы и нет,
>но не в коем случае не как доминирующий.
>finereader - действительно не хватает, lingvo же нафиг не упёрся - есть
>на порядок превосходящие его аналоги
И какой же? Если не секрет.
Lingvo не упёрся потому что есть lingvo.yandex.ru
Мне хватает.
Больше похоже на идеологию винды - там практически каждый дистрибутив таскает все необходимые библиотеки с собой...
>Больше похоже на идеологию винды - там практически каждый дистрибутив таскает все
>необходимые библиотеки с собой...да. Тем она и выигрывает пока что.
У тебя есть, скажем, фотожоп - и все. Ты знаешь шо он встанет на любую 2k, XP,2k3. А вот если у тебя есть RPM/TAR.GZ Gimp'a - то это совсем не значит, шо ты его на любом линухе заюзаешь просто так ;))klik - просто удобство для юзерей. А это - основное условие успеха для десктоп системы.
А вы FreeBSD и порты не пробовали? проблемы с зависимостями пропадают на раз ;)
не панацея от дурного софта. из портов гном ставить просто страшно. хотя установка большинства программ упрощается невероятно. кстати, gentoo в этом плане тоже можно отметить.
А Debian ?
Слышал я историю как во фре ставили из портов phpMySQLAdmin. Для справки - это набор php скриптов для руления mysql. Так он сменил еще апач, и php. При чем php оказался с глюками. пришлось откатываться назад :)
>Слышал я историю как во фре ставили из портов phpMySQLAdmin...
Ну ставил я месяц назад. Из портов. Ну пришлось немного makefile подрихтовать для mod_php. И все. А скульный админ был тупо распакован, и конфиг для апача поправлен. :-)
Незнаю, ставил неделю назад, ничего не правил, только конфиги, проблем нет.
а про make config в порту (причем выкидывается менюшка на ncurses), или про опцию WITH_APACHE2=YES в /etc/make.conf никто не слышал? все тупо любят набирать команду make install clean, а в хандбук заглянуть влом? влом пробежаться по Makefile? влом прочитать сообщения, которые выдаются во время сборки порта?
>А вы FreeBSD и порты не пробовали? проблемы с зависимостями пропадают на
>раз ;)пробовал. И Gentoo порты пробовал. Друг друга краше.
А что делать людям которые не такие умные как вы и на 500 цел хоцца поставить какую-нить совтину просто посмотреть?? Сколько лет в таком случае уйдет на портовые сборки??
никто не заставляет компилять, ставь бинарики! http://www.freebsd.org/cgi/man.cgi?query=pkg_add&apropos=0&s...
>никто не заставляет компилять, ставь бинарики!
>http://www.freebsd.org/cgi/man.cgi?query=pkg_add&apropos=0&s...бинарники из портежей репозитория?? пасиба. Мы тут обсуждаем вещи для распространения для произвольного дистра. Не на всех линукс дистрах есть бсдшные порты %)))
Речь идет о том, чтобы Вася Пупкин, услышав про Линух и поставив его себе
нашел потом в сетке ту же кваку и без геммора поставил ее себе и поглазел на прирост FPS по сравнению с виндой. Так вот чтоб он не ип%№;%лся с зависимостями (портами (хоть в бинарном, хоть в src виде) ldd, ldconfig...) - и подойдет чудно пакет в формате klik.
супер-дурацская идея. Могу уже представить для себя что в тысччи пакетах будет все библиотеки Гноме/КДЕ и Xorg/Xfree86 и много еще.
Типа пакет firefox весит не меньше 100Мб, мд@! А в винде всего 5М :(((((
можно еще отметить, что если у пакета все зависимости лежат в одном месте, то его очень легко засунуть в chroot. И это даже само напрашивается.По-моему, такая система распространения прекрасно подойдет для крупных сложных проектов. И я лучше потрачу лишних 200метров винта, чем буду колбасится с зависимостями очередного монстроидального творения типа того же Гнома.
php во FreeBSD действительно настоятельно требует именно Apache 1.3 :-( Да и вообще механизм пакетов и портов тоже требует влядения напильником. Но идея таскать за собою всё -- это полный бред! Может с каждой X-софтиной ещё и сам X-тянется? Или только шрифты? Если эту идею довести до логического заверщения, то и ядро с загрузчиком надо в пакет включать.
А я вот всегда думаю, есть же ldd, всегда можно узнать, что нужно даже бинарнику, даже вообще исходников не имея. Можно же скрипт какой-нибудь написать, чтобы всё это отслеживать и устанавливать? Почему этого нет до сих пор? Или есть?
> php во FreeBSD действительно настоятельно требует именно Apache 1.3 :-(Гм, странно. Несколько раз ставил mod_php4 на apache2. Потому что есть -DWITH_APACHE2. Проверено - на момент год-полтора назад это было абсолютно работоспособным. Иль уже поломали?
cd /usr/ports/lang/php4 && make config опаньки! grep APACHE /usr/ports/lang/php4/Makefile опаньки! про /etc/make.conf тоже, видать, не слышали...
Если обратить внимание на такие дистрибутивы как Gentoo, UBoontu, KBoontu и в некоторых местах Debian, то можно зхаметить, что они, каждый в разной степени тяжести, предлагают поиск зависимостей и их удовлетворение, либо скачиванием из сети, либо даже поиском (!) на харде/CD. Так что я думаю всякие там клики - это малость маразматическое решение. Может для RedHad-based систем оно и подходит, но для чего-нибудь более серьезного - есть уже готовые решения...
подрихтовать надо конечно идею - а то доиграемся до того что каждая прога будет отдельно на livecd идти
:)скажем выделить что-то типа стандартных библиотек и наборов. будет 1-2 явные зависимости на другой такой же klik-пакет
Ну допустим с одной стороны в идее таскать с собой зависимости что-то есть. Когда я сам пересел на линух для меня было таким гемороем поставить прогу не из дистрибутива :(.
Полезная идея. Пользуюсь AltLinux 2.0, для которого без обновления всего дистрибутива уже ничего толком графического не поставишь. Например, хочется поставить firefox, а он цепляет за собой кучу всякого хлама, правда в klik пакета firefox нет :-(
>Полезная идея. Пользуюсь AltLinux 2.0, для которого без обновления всего дистрибутива уже
>ничего толком графического не поставишь. Например, хочется поставить firefox, а он
>цепляет за собой кучу всякого хлама, правда в klik пакета firefox
>нет :-(Вот, собссно, иллюстрация к отв. 19.
Получайте.
Наслаждайтесь.
>Вот, собссно, иллюстрация к отв. 19.Не вижу связи. Из вы из тех, что апдейтят все подряд не думая ? Зачем обновлять весь дистрибутив, когда все и так прекрасно работает и отточено под себя за много лет ?
> Вот, собссно, иллюстрация к отв. 19.
> Получайте.
> Наслаждайтесь.зачем же так ? альт 2.0 - этому продукту скоро года 4 будет. чтобы его _правильно_ довести до состояния в котором на него файерфокс нормально встанет надо такой танец с бубном что мало не покажется. вот как раз это наверно тот случай когда поставить отдельно прогу с зависимостями проще чем ставить эту же прогу правильно (в рамках дистрибутива).
Klik нужен хотя бы для того, чтоб никс мог конкурировать с виндой на рынке десктопов. Я не думаю, что среднестатистический пользователь будет долбаться с зависимостями, чтобы поставить мелкую утилитку.
Вижу много противников klik, и не понимаю их. Не равится - не ешь, в чем вопрос? А система klik наверняка найдет своего пользователя.
вот поэтому умные люди сидят на дебиане и не парятся с зависимостями:)
>вот поэтому умные люди сидят на дебиане и не парятся с зависимостями:)еще более умные люди - порты пользуют и сидят на Генту.
А с чего народ так печется про объем на диске после установки?
Если версии библиотек в пакетах совпадут, то разницы вообще нету через клик ставить или традиционным садо-мазо.
Вот объем пакета пухнет - это да, проблема. Но думаю ненамного, при условии что девелоперы не будут принимать слишком много шнапса при сборке и в каждый пакет не будет попадать целиком Гном :)
> А с чего народ так печется про объем на диске
> после установки?
> Если версии библиотек в пакетах совпадут, то
> разницы вообще нету через клик ставить или \
> традиционным садо-мазо.не-а. пакет вместе со всеми своими причиндалами ставится в отдельный каталог. то есть если у тебя 10 пакетов на гтк, то у тебя 10 гтк в разных каталогах. соответсвенно отжирается у тебя в 10 раз больше места.
с другой стороны - можешь иметь хоть 20 разных версий гтк. в общем, теряем место - выигрываем (?) удобство
А представь себе эти 20 гтк одновременно в памяти. Место на диске, в общем-то, почти ничего не стоит, но традиционные 1-2 гига памяти кончатся быстро.
8)))такие проблемы, и все из нежелания собирать из исходников....
лучший линукс тот, которого выростил сам.
>такие проблемы, и все из нежелания собирать из исходников....
>лучший линукс тот, которого выростил сам.И на котором сможете работать только вы? Это не подход.
>И на котором сможете работать только вы? Это не подходCистема имеет стандарт (LSB), которму надо следовать даже при сборке своего дистрибутива, а все стандартные дистрибутивы и так отличаются, но работа с ними практически одинакова.
Под виндами те-же проблемы. "dll hell" называется. Но поскольку разработка преимущественно закрытая так широко не обсуждается. Каждый разработчик сам решает как справляться с этой проблемой, насколько работа приложения должна зависеть от версии библиотеки и т.д. Наиболее тупые инсталляторы кидают свои dll-ки в системный каталог, чем вызывают потерю работоспособности других приложений. Те что получше, хранят библиотеки в своей директории. Еще более умные пытаются анализировать версии установленных библиотек и т.д.
Т.о. единую политику совместного использования библиотек разработать не удалось.
Ну "dll hell" слабо связан с проблемой неявных зависимостей. Как раз при Клик-пакетах, если девелоперу взбредет положить что-либо прямо в /lib, то и получим ".so hell" в полный рост :)
Другое дело, что из-за кучи зависимостей мало того, что резко усложняется управление пакетами, так еще и компилированные пакеты надо собирать под каждую версию ОС отдельно (тут я утрирую, не всегда это надо, конечно).
Налицо абсолютно лишний геморрой, как для разработчиков (попробуйте протестить сборку под 20-30 ОС-ями у которых общее только ядро - взвоете!), так и для юзера ("А вот я выкачал пакет под RedHat, а под SuSE нету, и он не ставится и какую-то фигню пишет, а нужно было еще вчера, хелп! караул!" :) )
В конце-концов - ведь мало кто возражает против LSB, а ведь это практически шаги в одном и том же направлении.
> Если версии библиотек в пакетах совпадут, то
> разницы вообще нету
Это не всегда так. Проблемы могут возникнуть(и скорее всего возникнут), если сборка программ проводилась разными компиляторами или с разной glibc.> или традиционным садо-мазо.
Ну, я бы не сказал, что это "садо-мазо". У меня установлен свой собственный LFS, несколько раз пересобиравшийся под разные gcc и glibc при помощи уже имеющихся скриптов сборки. Проблем сборки вообще нет - поменял версии этих пакетов, изменил(если надо) оптимизацию под конкретный процессор, запустил скрипт и пошел своими делами заниматься, а через некоторое время получаеш новый дистрибутив.
Чем народу YUM не понравился ?
У Oracle похожий подход ;)
Когда ставишь например 9i Enterprise, то будь готов, что он с собой поставит с пяток разных Java-машин разных версий, пару-тройку старых и не очень apache'й и еще кучу разномастной лабуды ;)
Прикол в том, что это разводится не в рамках операционки, а в рамка одного дистибутива (!!!)
Вот это я понимаю - подход, кот кому по фигу на свободное место на пользовательских винчестерах ;)
Наверняка найдет свою нишу - на десктопах
Не, смысл определенно есть. Например, если нужно поставить одну софтину, которой нужен гном или там KDE, я лучше солью лишнюю сотню метров, чем буду засорять G- или K- говном систему. А так, традиционным пакетам это конечно не замена, ни в коем разе. Кто говорит про проблемы с зависимостями - раскройте глаза, эти проблемы были актуальны лет 10 назад. Сейчас есть ports/portage, а используете бинарные пакеты - ССЗБ.
мдя...
Как я и ожидал, оно таки часть зависимостей оставляет на системе... :-(типично
------
dyug@dyug:/tmp/klik/kover/opt/kde/bin$ ./kover
./kover: error while loading shared libraries: libfam.so.0: cannot open shared object file: No such file or directory
-------
P.S. AppRun выдает то же самое... :-(Slackware 10.2
Это не жалоба это просто констатация факта...
qcad - заработал, и на том спасибо... :-)
> Slackware 10.2 qcad - заработал, и на том спасибо... :-)http://www.linuxpackages.net/pkg_details.php?id=4754
не лучше?
klik - только для debian-подобных дистрибутивов? У меня например в ASPLinux он не запускает программы.