> Gentoo - это глобальная система от которой можно брать все что надо, а слака - сам себе в ящике царь, че хочу - то творю.

"глобальность" - это unlimite Internet ? ...не всегда "плюс".

про "царя" верно. Это же Операционная Система.

А творить я предпочитаю то, что хочу. Иные последствия воспринимаю как bug`и.

:-)

Belen У меня в иксах русский не отображается..хотя по русский пишет... я хз че ей не нравится... до этого проблем не было... у меня Slackware 9.1..

2anonymous (*) (2003-09-30 09:44:34.392894)

http://www.slackware.ru/show_forum.ghtml?Forum_id=65&root_id=620&dept...

2Belen> если Alt + F2 нажать :-))

А что происходит если Alt F2 нажать?

Вытяжка с http://www.slackware.ru/show_forum.ghtml?Forum_id=65&root_id=620&dept...

...
Ищщо разъ о гномах и их наречиях.
Gnome пользует fontconfig(библиотека такой). Этот ничего не знает о штатных иксовых фонтах кроме Type1 и ttf. Чтобы он был доволен, нужно подложить в стандартное место нужные шрифты (взять маздайные, к примеру), произвести шаманские пляски с mkfont[dir,scale] (Type1), ttmkfdir(ttf), fc-cache -f (в верхней директории шрифтов). Проследить наличие нужных fonts.dir/scale. Прописать директории новых шрифтов в /etc/X11/XF86Config (или где у тебя...). Гнома грузить после этого. Штандартенсвитчер для кбд реагирует здраво на два шифта. Остальные кнопки, похоже, не дозволены.
...
То, что про прикручивание TTF верно до пункта с созданием fonts.dir и fonts.scale включительно.
После этого надо прописать новый каталог со шрифтами в /etc/fonts/local.conf и запустить fc-cache
После этого шрифты к гному подцепятся.
...
Дык, если стандартное место (что прописано в конфигах fontconfig), то и писать ничего дополнительно не нужно.
...

2Troll Вообще-то по умолчанию в KDE при этом сочетании клавиш вызывается окно для быстрого запуска программы... так вот в нем в slack91 нижний край наезжает на кнопки... хотя работе это не мешает

Подбросим дровишек во флейм. Глянул я на этот сварет. Идея интересная - реализация менеджера пакетов на шелл-скрипте. Предположим (я до конца не стал смотреть на функциональность), что сварет получает функциональность, схожую с apt или urpmi. При прочих равных условиях, не кажется, ли вам, что идеологически правильно именно решение на базе UNIX shell+tar.gz, нежели apt+rpm/deb, и что такое решение может быть взято на вооружение другими дистростроителями?

Вопрос скорости работы скрипта ясен сам собой, хотя смотря как написать (кто пробовал уже? как там этот скрипт ворочается? Он же жирный... больше 500 кБ!)

А как, кстати, сварет хранит зависимости? Тоже в Беркли ДБ или в текстовом файле каком? (ну правда лень скрипты смотреть) :)

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

реализация менеджера пакетов на шелл-скрипте

2 Zubok:

file /usr/bin/debconf
/usr/bin/debconf: perl script text executable

Когда пакетов стало больше 10000, кинулись его писать на C...
Может, в следующем (не sarge) stable можно будет сделать заветное

apt-get remove perl*

> При прочих равных условиях, не кажется, ли вам, что идеологически
> правильно именно решение на базе UNIX shell+tar.gz, нежели
> apt+rpm/deb,

Нет, это не UNIX-way. Должна быть утилита, которая _очень хорошо_
( в том числе -- достаточно быстро ) умеет выполнять
операции установки/удаления/обновления софта.


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

Да это уже пройденный этап. dpkg, помнится, тоже когда-то
perl'-овым скриптом был; а поскольку Slackware -- это дистр
с замедленным [умственным] развитием, то сейчас там та же
ситуация, что в нормальных дистрах -- лет 8 назад.


P.S.
По поводу идеологически правильного package manager'-а:
http://u-os.org/upm.html

P.P.S.
Slackware must die!

2 Dselect:

>Когда пакетов стало больше 10000, кинулись его писать на C...

Мне кажется, что возникновение apt на Си - это не уход от скрипта, а просто его начали писать уже на Си, когда кто-то решил сделать новый фичастый менеджер пакетов. В таких случаях говорят "исторически так сложилось".

>Нет, это не UNIX-way. Должна быть утилита, которая _очень хорошо_ ( в том числе -- достаточно быстро ) умеет выполнять операции установки/удаления/обновления софта.

Спорное утверждение. Если мы используем определение Unix-way: "каждая программа должна делать одну вещь и делать ее хорошо", то swaret - это очень даже Unix-way. Для инсталляции, переименования, удаления, обновления пакетов используются программы из раздела /bin (cp, rm и пр.). Они делают одну вещь и делают ее хорошо. Стандартный /bin/sh выполняет хорошо shell-скрипт. Надо добавить в архив tar.gz скрипты pre-install и post-install, ну и скрипты, работающие при удалении пакета. Короче, операции самой инсталляции из tar.gz и удаления пакетов - вещи быстрые, на чем бы вы ее не написали. Тут есть возражения?

А вот главная проблема - это зависимости пакетов. База зависимостей - это "лес" (множество графов "дерево") без циклов. Возникает проблема эффективного хранения и поиска. Насколько я понял, в сварет используются таки текстовые файлы, потому что в зависимостях я не увидел ничего экзотического, кроме стандартных вещей, которые требует POSIX. Вот хранение и поиск в зависимостях - это основная проблема, где все зависит от того, насколько эффективно вы придумали хранить эти зависимости. Думаю, что задача как-нибудь решаема (уж не знаю, как ее решали на perl в Debian). Вот попробует кто-нибудь сварет и скажет нам - медленно или нет (на сайте сварета, кстати, есть скриншоты со всевозможным поиском). База пакетов действительно может быть большой... Вот в rpm придумали использовать Berkeley DB. Ну вот если без маленькой БД все-же не обойтись, то это тоже, в принципе, подходит под Unix-way. Что же, будем, значит, в шелл-скрипте использовать этот механизм. Почему бы и нет? (хотя BDB - это какое-то извращение. Ставить движок ради какой-то там утилиты...). В любом случае, прежде, чем говорить "вот именно тут вся проблема скрипта" послушаем слакварщиков, как они находят скорость работы :)

>По поводу идеологически правильного package manager'-а: http://u-os.org/upm.html

Будем посомтреть, что это за товарищ Сухов.

>Slackware must die!

Я хоть и не слакварщик, но резко ты :)

P.S. Скрипт swaret такой огромный оказывается еще потому, что все отступы (а они здоровые) сделаны пробелами, а не табуляцией. На производительность это не скажется, но все-таки процент этих пустот велик слишком тут. В hex рябит от ascii-кода 0x20 :)

2 Dselect:

Да, этот uPM - весьма интересная вещь. Все про него пока не прочел - не было времени, но в целом/общем идеологию понял. спасибо за сцылу! ;)

2anonymous (*) (2003-09-30 19:28:47.588097)

правда глаза колет?

Slackware must die!

2 Zubok:

> А вот главная проблема - это зависимости пакетов.

Дык это единственное (но сущенственное! ) отличие package manager'-а от tar xjf blah-blah :)

> Если мы используем определение Unix-way: "каждая программа должна делать одну вещь и делать ее хорошо", то swaret - это очень даже Unix-way.

Главное, что делает package manager -- анализирует зависимости. Поэтому (если следовать UNIX-way) должна быть програмулина, которая это умеет делать. Где она?

> Для инсталляции, переименования, удаления, обновления пакетов используются программы из раздела /bin (cp, rm и пр.).

Вы еще скажите, что для установки пакетов используется open(2), а посему swaret -- это UNIX-way :)

> (хотя BDB - это какое-то извращение. Ставить движок ради какой-то там утилиты...).

Когда пакетов десятки тысяч, это вполне оправдано. Plain text a la /var/lib/dpkg/available -- это хорошо, но поиск по нему...

чего ещё нет в слаке:
1)postfix
2)postgresql
3)xinetd

этого наверно тоже нет по соображениям безопасности.
то есть вместо глючных и дырявых postfix и xinetd используются супербезопасные проги - sendmail и inetd.

кто-нибудь видел слаку версий 5.x и 6.x ? их нет, а всё почему? да потому что они решили что если не фичами, так номером версии шапку догонят

2Dselect
>Slackware -- файлопомойка, хуже которой только Windows 3.11

Ты чего такое курил сегодня ? ;)

кто какчал отсюда? http://ostnet.ru/slaka/slackware-9.1-install-d1.iso

проверил на md5sum 40% пакетов битые. тот кто выкладывал и те кто скачивал проверьте у себя, дайте ответ, это только у меня так ?!

Вывод: это не тот дистрибутив.

Не стал качать, по причине отсутствия доверия к источнику.

P.S. Спасибо за информацию.

Единственное, в чём Слака отстаёт от Шапки -- это в номере версии. =)
А в остальном -- Слак рулит. :P

>Слака отстаёт от Шапки -- это в номере версии. =)

Шапка щас последняя - 9, Slackware - 9.1

Гы. Точно. %)))

Насчет биты - все ок, но я качал один из первых.

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

СЛАКА САСЕТ!!!!!

Slackware - рулит!!!

ПАм - в жопу. Юзеров с сервера под слакой - на хуй. Пущай логиняться в свои редхатовые боксы, там и ПАм для них настрой. Гы-гы, где это ты ваще видел "юзера" под линем? Под линем только крутые сисадмины, им пам не упирался.

slack ware - "слабое изделие" в переводе с английского. название противоречит самому дистрибутиву.

> slack ware - "слабое изделие" в переводе с английского. название противоречит самому дистрибутиву.

Честно говоря, без разницы, как оно там переводится. Хорошо, что есть.