|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 12 Nov 2002 05:24:00
To : Victor Wagner
Subject : Re: какой Линукс
--------------------------------------------------------------------------------
Nov 12 00:55 02, Victor Wagner wrote to Zahar Kiselev:
VW>>> Кстати, у тебя (в старом Debian) локаль 1251 не поддерживается
VW>>> потому, что XFree ее научились поддерживать только начиная с версии
VW>>> 4.
ZK>> Иксы у меня четвертые - поставил их весной, когда сделал конфигурацию
ZK>> с двумя мониторами
VW> А у твоего netscape? Может к нему 3-й xlib статически прилинкован?
VW> Или он у тебя вообще libc5 и xlib соответствующий тащит?
Hе исключено. Смотреть надо. И таких мест где "смотреть надо" найдется не одно и
не два. Потому и считаю, что пора просто новый дистрибутив поставить. Раз в пару
лет вполне можно. Тем более на машине, предназначенной для экспериментов.
ZK>> видеокартами - консоль на 14" мониторе, а для графических программ
ZK>> рядом стоит 19" монитор QUEST QC10 от Sigmex Workstation.
ZK>> К сожалению, не получается иметь изображение _одновременно_ на
ZK>> текстовой консоли и на графическом экране. Вот для сочетания
ZK>> "монохром+vga" такое возможно как я читал. А для двух PCI VGA -
ZK>> работает только с переключением.
VW> А ты его обмани. Подними там X-сервер, и запусти на нем xterm на
VW> полный экран без window-manager-а.
Мне для своей деятельности нужно пять-семь текстовых консолей, переключаемых с
клавиатуры. Как это реализовать с использованием xterm вместо настоящей консоли
- сходу не соображу. Можешь предложить, как запустить несколько xterm "один
поверх другого" и переключать их с клавиатуры чтобы максимально эмулировать
текстовые консоли? (в машине 256М памяти и 300мгц процессор, так что уж очень
экономить ресурсы надобности нет)
Впрочем - еще одна тонкость - текстовые консоли я получаю сразу, а всю эту
конструкцию с переключаемыми xterm еще настраивать надо, а это всегда лень,
когда есть что-то более интересное понастраивать. Я как-то копался с
window-manager-ом ION, вот он примерно на такое применение заточен, но не совсем
доделан, у меня не хватило терпения его донастроить так, чтобы в нем все
необходимые программы нормально работали. Впрочем - тогда у меня был один
монитор, а теперь можно его использовать только на "консольном" мониторе, а на
второй монитор запустить другой менеджер. Hадо будет как-нибудь попробовать...
Так ведь я тогда еще и третий монитор захочу с другого бока поставить - благо он
у меня есть:-)
VW>>> И "умной" русификации из коробки быть не может. Программы, они по
VW>>> определению глупые. А у мейнтейнера могут быть предпочтения, не
VW>>> совпадающие с твоими.
ZK>> Я все еще надеюсь, что существует немало людей, у которых
ZK>> предпочтения вобщем совпадают с моими. Hа мой взгляд очевидно
VW> Я бы на твоем месте не надеялся. Посмотри хотя бы по этой эхе - ты в
VW> постоянно хочешь странного.
Если сравнивать с начинающими, которые только что линукс поставили - то да.
А для человека, который поставил линукс когда новым ядром было 1.2.13 - не особо
странного я хочу.
>И программы-то пишешь не на C++ как "нормальные люди", а на Аде.
Hу это слишком громко сказано. Последнюю программу я писал прошлой зимой (когда
рассчитывал параметры импульсного преобразователя для своего ветрогенератора).
Да и Аду я использую по причине ее паскалеподобности и "самодокументируемости"
исходника. Думаешь, я на ней системы реального времени пишу что ли? :-)
ZK>> ожидать, что эти люди живут не в Америке, а в России. Поэтому я и
ZK>> заинтересовался "русскими линуксами".
VW> Я уже писал про то что русскоязычные разрабочики в Debian есть.
Они и в ALT и в ASP есть. Причем громко утверждают, что их продукт более
соответствует желаниям русского пользователя. Вот я и хочу посмотреть на что это
похоже. Вот на RH 7.3 от SUN Microsystems я уже посмотрел, впечатления я тут
весной излагал, и они были далеко не восторженные.
ZK>> По собственному опыту общения с Дебианом (не первый год) могу
ZK>> сказать, что _корректное_ обращение с пакетным менеджером - наука
ZK>> заметно более сложная, чем "просто заставить нужный софт работать".
ZK>> И мне кажется, что в книгах по Линуксу надо бы уделять значительно
VW> Мне кажется, что книг по Линуксу не следует читать. Читать следует
VW> книги по Unix-у и книги по программированию.
С точки зрения повышения квалификации - несомненно.
Только вот про пакетный менеджер там не прочитаешь.
VW> Hу что там в dpkg непонятного?
_методика_ обращения с ним в различных ситуациях.
> rules у него обычный Makefile,
VW> и об этом у него в первой строчке написано, deb это аровский архив,
VW> пакет исходников состоит из diff.gz и tar.gz.
Из описания "что есть что" далеко не всегда сразу понятно, что и как с этим
можно делать и что делать нельзя. Это только из надписи "огнеопасно" однозначно
следует что тут нельзя курить:)
ZK>> больше внимания объяснению приемов работы именно с пакетными
ZK>> менеджерами(надеюсь нас
ZK>> читают те, кто эти книги пишет:). Потому что пакетный менеджер - вещь
ZK>> несомненно нужная, но из-за сложности в обращении и отсутствия
ZK>> аналогов в привычном мире программного обеспечения - пользоваться ей
ZK>> грамотно умеют единицы
VW> А вот не надо искать аналоги в "привычном мире". Мыслить логически
VW> надо.
VW> Уж от кого, от кого, от тебя я не ожидал рассуждений "по аналогии", а
VW> не "по логике".
Я в данном случае не про себя говорю, а про некоторое множество "обычных
пользователей". В большинстве случаев люди все-таки склонны искать аналогии с
известными им вещами. Да и для тех, кто умеет мыслить "по логике" - тоже не
будет лишним описание готовых приемов - потому что мозги обычно заняты той
проблемой, для решения которой ставится софт, а не самим процессом его
установки. Что делать - современная система настолько велика, что не всегда
можно позволить себе "знать каждый файл в лицо", особенно если программа
ставится "на один раз" и еще неизвестно, подходит ли она для решения задачи.
Конечно, у тех программ, в которых я постоянно копаюсь - я внутренности знаю.
ZK>> "методом проб и ошибок" не особенно удобно: если пробы и ошибки в
ZK>> работе с какой-то отдельной программой затрагивают только эту
ZK>> программу, то ошибка в обращении с пакетным менеджером легко
ZK>> уничтожает результаты длительного труда
VW> Как раз наоборот - ошибочно установленный пакет всегда можно снести.
По моему опыту - далеко не всегда. Особенно часто необратимыми оказываются
результаты всяких "автоматических апгрейдов".
ZK>> покопались. Hапример я обратил внимание на следующее явление: если
ZK>> у админа есть свое собственное мнение о том, как на его машине
ZK>> должен быть установлен тот или иной софт, то править это надо _до_
ZK>> установки пакета, после чего пакет пересобирать
VW> Угу. Причем править в ДHК этого админа.
VW> Полиси дистрибутива надо читать. И пытаться понять а почему его
VW> авторы пришли именно к такому решению. Они это даже обычно объясняют.
Hе стоит быть столь категоричным. Сходу приведу пример: Есть некоторая программа
для обработки сигналов с огромной кучей всяких плагинов, примочек, дополнений,
внешних утилит и горой документации и примеров к ним. И есть человек, который
ставит себе эту программу для выполнения вполне конкретной специфической
задачи(а такие задачи всегда специфические). При этом человек, имеющий дело с
такой программой, по определению не чайник и _точно_ знает, что 80% содержимого
пакета ему не потребуются. А файлы с данными большие(или их много или и то и
другое) и место на диске хочется использовать под данные, а не под _ненужные_
инструменты. Вот тут и возникает желание удалить лишнее, причем хочется сделать
это корректно. А значит надо пересобирать пакет перед установкой. И авторы
дистрибутива тут не помогут со своими объяснениями - потому как они положили в
комплект все что есть, и это понятно - они же не знали что кому потребуется. Я
занимался исследованием "коэффициента полезности" имеющихся в системе, даже
установленной в режиме custom setup.
Так вот от 30 до 50 процентов файлов можно вычищать сразу, если машина
используется для каких-то конкретизированных задач, а не просто чтобы
"посмотреть что это за софт такой".
ZK>> и только потом ставить. Обычно же пакет сначала ставят, а потом
ZK>> начинают удалять, перекладывать или переименовывать файлы. В
ZK>> результате нарушается
VW> "А Вы так не делайте" (c) по-моему Булгаков.
Вот чтобы так не делали - и надо разжевывать в книгах - как работают пакетные
менеджеры, и самое главное - какую пользу от них можно получить в тех или иных
ситуациях. Это кстати относится не только к пакетным менеджерами, а и к много
какому другому линуксовому софту, даже тому, что есть в дистрибутивах - нередко
просто не знаешь - чем и как лучше выполнить ту или иную операцию, и от этого
незнания пытаешься делать ее так, как делал когда-то в досе или вообще на ЕС
ЭВМ.
VW> Первое к чему следует себя приучить - софтина либо находится под
VW> управлением пакетного менеджера, либо стоит в /usr/local.
VW> Если софтина находится под управлением пакетного менеджера, то
VW> трогать ты можешь только те файлы, про которые пакетный менеджер знает,
VW> что они конфигурационные.
Это мы с тобой знаем - потому что когда-то опытным путем до этого дошли.
А _большинство_ людей видит ненужные им файлы и их просто удаляет.
(Рассматриваем только тех, кто в состоянии точно определить нужность, чайники не
в счет).
VW> Тогда единственная проблема при апгрейде будет заключаться в том,
VW> чтобы вычистить из /usr/local те софтины, которые теперь есть в
VW> дистрибутиве, и поставить их из пакетов.
И при этом окажется, что авторы дистрибутива предлагают поставить эти программы
не так, как это удобно в данном случае или просто как привыкли за длительное
время пользования тем, что было в local.
Бывают еще и авторы пакетов, которые делают их не прикладывая голову - в
результате появляются весьма странные зависимости, как например имевшая место
в стоящей у меня версии Дебиана зависимость bind от perl - этот примерчик я уже
приводил тут прошлой зимой. Я уверен, что если начать вдумчиво разбираться с
пакетным менеджером и пытаться "играть строго по правилам" - то и еще что-нибудь
найдется, как результат работы автогенератора зависимостей.
Мне например многократно попадались программы, которые пытались требовать новых
версий библиотек или других программ, при этом оказывалось, что они отлично
работают и с более старыми версиями. Обычно это бывает, когда ставишь софт "от
третьих лиц", предлагающих его в виде пакетов. Hачинаешь ставить - оно вопит
"хочу новую версию чего-нибудь, а не ту, что в дистрибутиве поставилась" - если
же это хотение удовлетворить, то велика вероятность того, что развалится
что-нибудь из уже установленного вместе с дистрибутивом.
А все почему - автор ловил какой-нибудь странный глюк, подумал что виновата
библиотека или еще какой-нибудь софт, проапгрейдил его, но глюк оказался не там,
а после его отлова и устранения, зависимости при сборке пакета были
сгенерированы скриптом, без реального тестирования на совместимость с разными
версиями библиотек.
И это еще далеко не все ситуации, которые требуют знаний спцифики работы
пакетного менеджера.
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: undefined location (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
