|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 12 Nov 2002 11:29:15
To : Zahar Kiselev
Subject : Re: какой Линукс
--------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
VW>> А ты его обмани. Подними там X-сервер, и запусти на нем xterm на
VW>> полный экран без window-manager-а.
ZK> Мне для своей деятельности нужно пять-семь текстовых консолей,
ZK> переключаемых с клавиатуры. Как это реализовать с использованием xterm
ZK> вместо настоящей консоли - сходу не соображу.
заменяем слово "консоль", на "workplace" любго window manager'а.
Hа каждом workplace - xterm открытый во весь экран (или не во весь, не
суть важно).
У меня, настроено по Alt-F[1-8] выбор одного из уже восьми WorkPlace.
ZK>>> ожидать, что эти люди живут не в Америке, а в России. Поэтому я и
ZK>>> заинтересовался "русскими линуксами".
VW>> Я уже писал про то что русскоязычные разрабочики в Debian есть.
ZK> Они и в ALT и в ASP есть. Причем громко утверждают, что их продукт
ZK> более соответствует желаниям русского пользователя. Вот я и хочу
ZK> посмотреть на что это похоже.
посмотри, раз хочется. Всегда нужно делать все что хочется ;-)
ZK> Вот на RH 7.3 от SUN Microsystems я уже посмотрел, впечатления я тут
ZK> весной излагал, и они были далеко не восторженные.
а восторженых скорее всего и не будет ;-)
VW>> Полиси дистрибутива надо читать. И пытаться понять а почему его
VW>> авторы пришли именно к такому решению. Они это даже обычно объясняют.
ZK> Hе стоит быть столь категоричным. Сходу приведу пример: Есть некоторая
ZK> программа для обработки сигналов с огромной кучей всяких плагинов,
ZK> примочек, дополнений, внешних утилит и горой документации и примеров к
ZK> ним. И есть человек, который ставит себе эту программу для выполнения
ZK> вполне конкретной специфической задачи(а такие задачи всегда
ZK> специфические). При этом человек, имеющий дело с такой программой, по
ZK> определению не чайник и _точно_ знает, что 80% содержимого пакета ему
ZK> не потребуются. А файлы с данными большие(или их много или и то и
ZK> другое) и место на диске хочется использовать под данные, а не под
ZK> _ненужные_ инструменты.
этот человек с такими желаниями один одинешенек на земле?
ZK> Вот тут и возникает желание удалить лишнее, причем хочется сделать это
ZK> корректно. А значит надо пересобирать пакет перед установкой. И авторы
ZK> дистрибутива тут не помогут со своими объяснениями - потому как они
ZK> положили в комплект все что есть, и это понятно - они же не знали что
ZK> кому потребуется.
не факт. Если этот человек таки не один с такими вот требованиями, или
его требования ЛОГИЧHЫ, то авторы дистрибутива могут порезать пакет на
множество пакетов. Порезать так, что 80% "ненужного содержимого пакета"
будет лежать отдельно.
Если же запросы этого члеовека уникальны, то ему могут просто подсказать
как ему их самому удовлетворить.
ZK> Я занимался исследованием "коэффициента полезности" имеющихся в
ZK> системе, даже установленной в режиме custom setup. Так вот от 30 до
ZK> 50 процентов файлов можно вычищать сразу, если машина используется для
ZK> каких-то конкретизированных задач, а не просто чтобы "посмотреть что
ZK> это за софт такой".
ну так, в чем проблема-то? Берется пакетный менеджер своего дистрибутива,
и методично удаляются пакеты, которые не нужны.
зависимости? Ага! значит такиэти пакеты нужны. Потенциально нужны!
И вполне реальна ситуация, когда какой-то другой софтине может понадобится
пакет, который ты посчитал ненужным.
Если нет - значит кривособраный пакет, и авторы дистрибутива с радостью
примут багрепорт.
VW>> "А Вы так не делайте" (c) по-моему Булгаков.
ZK> Вот чтобы так не делали - и надо разжевывать в книгах - как работают
ZK> пакетные менеджеры, и самое главное - какую пользу от них можно
ZK> получить в тех или иных ситуациях.
польза очень просотая - можно не помнить какой файл откуда, что он тут
делает, и зачем. И можно не волноваться, что при обновлении софта
останутся какие-то обломки.
VW>> Первое к чему следует себя приучить - софтина либо находится под
VW>> управлением пакетного менеджера, либо стоит в /usr/local.
VW>> Если софтина находится под управлением пакетного менеджера, то
VW>> трогать ты можешь только те файлы, про которые пакетный менеджер знает,
VW>> что они конфигурационные.
ZK> Это мы с тобой знаем - потому что когда-то опытным путем до этого
ZK> дошли. А _большинство_ людей видит ненужные им файлы и их просто
ZK> удаляет.
сами себе злобные буратины.
Если фал на диске _тебе_ не нужен, подумай, может он кому-о нужен?
Чтоб узнаьт "кому и зачем" - есьт пакетный менеджер.
ZK> (Рассматриваем только тех, кто в состоянии точно определить нужность,
ZK> чайники не в счет).
Компьютер, в общем случае, это довольно сложный комплекс. Даже те, кто в
состоянии определить, не всегда могут это сделать адекватно.
Вот чтоб им помочь, и есть пакетный менеджер.
VW>> Тогда единственная проблема при апгрейде будет заключаться в том,
VW>> чтобы вычистить из /usr/local те софтины, которые теперь есть в
VW>> дистрибутиве, и поставить их из пакетов.
ZK> И при этом окажется, что авторы дистрибутива предлагают поставить эти
ZK> программы не так, как это удобно в данном случае или просто как
ZK> привыкли за длительное время пользования тем, что было в local.
зачем? Дистрибутив обычно ставится в /usr
со всеми вытекающими.
ZK> Бывают еще и авторы пакетов, которые делают их не прикладывая голову -
ZK> в результате появляются весьма странные зависимости, как например
ZK> имевшая место в стоящей у меня версии Дебиана зависимость bind от perl
ZK> - этот примерчик я уже приводил тут прошлой зимой.
еще той зимой тебе популярно обхяснили - КРИВО СОБРАHЫЙ ПАКЕТ.
ZK> Я уверен, что если начать вдумчиво разбираться с пакетным менеджером и
ZK> пытаться "играть строго по правилам" - то и еще что-нибудь найдется,
ZK> как результат работы автогенератора зависимостей.
найдешь чего - пиши багрепорты. И читай на них ответы.
ZK> Мне например многократно попадались программы, которые пытались
ZK> требовать новых версий библиотек или других программ, при этом
ZK> оказывалось, что они отлично работают и с более старыми
ZK> версиями.
если собраный пакет хочет новой библиотеки, я обычно беру пакет с
исходниками, и пробую пересобрать его со своей версией библиотеки.
ZK> Обычно это бывает, когда ставишь софт "от третьих лиц", предлагающих
ZK> его в виде пакетов.
если я ставлю пакеты "третьих лиц", я в 90% сразу беру пакет с
исходниками, и пересобираю на своей машине.
Есть всего несколько "третих лиц", в качесве сборке пакетов которых я
уверен.
ZK> Hачинаешь ставить - оно вопит "хочу новую версию чего-нибудь, а не ту,
ZK> что в дистрибутиве поставилась" - если же это хотение удовлетворить,
ZK> то велика вероятность того, что развалится что-нибудь из уже
ZK> установленного вместе с дистрибутивом.
то все от лени. В моем случае, достаточно сказать
rpm --rebuild <package.src.rpm>
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
