Хочется сказать многое... а написать - ещё больше... но...
23Oz.
Dear Nathan Baxter!
Thank you for your great original artwork.
Regards,
sda00
а сейчас я встану, открою дверь на улицу и тихонько покурю...
P.S. вот так простые ламеры становятся "отцами":
http://www0.get-e.org/Main/News/_articles/431.html
суббота, 24 ноября 2007 г.
вторник, 13 ноября 2007 г.
Взгляд ушастого ламера на проект "Информационная независимость России"...
"...виды, намеренья и цели государя, немногим известные, и образ его действий при сем, нередко скрывающий первые. Политика - тухлое яйцо..."
(Суворов)
"Политика - это искусство возможного"
(Отто фон Бисмарк)
поскольку по предмету "Политпроституция" в моей "зачётке" стоит твёрдый "Неуд.", или говоря проще - "единица" по любой из возможных систем оценок (5-ти бальной, 10-ти и т.д.), то особого смысла "марать бумагу" вроде как и нет. но, ежели рассматривать сей опус как некое развлекательное чтиво (а-ля pulp fiction), то "пуркуа бы и не па"?
коли вдруг сие "творение" вызовет абсолютно нехарактерный для моего блога наплыв "камментов" - заранее предупреждаю: любые высказывания личностного характера, наносящие ущерб чести и достоинству упомянутых в этом трэде юридических и физических лиц, будут удалены. меня же можете костерить насколько хватит фантазии, ибо всегда приятно оценивать человека по его высказываниям.
для начала - краткий экскурс в историю.
с момента падения династии Романовых и замены института монархии на институт "вся власть - советам" многострадальная "одна шестая часть" мирового сухопутного пространства стала напоминать герметичный аквариум со стенками из "кривого" стекла, искажающего восприятие в обе стороны, окружённый водами мирового океана. поскольку ограниченность ресурсов и деятельности существ в условиях безграничности потребностей есть суть аксиома экономической науки, то в упомянутом "аквариуме" царствовало плановое распределение имеющихся ресурсов (иначе именуемое как "Планирование", поскольку "прости, дорогая, но так получилось"), без малейшей оглядки на насущные потребности индивидуумов (к слову сказать сам термин "индивидуум" был до недавнего времени ругательным). несмотря на то, что ограниченные природные и человеческие ресурсы "аквариума" с лихвой могли обеспечить более-менее сносное существование и воспроизводство популяции, "Планом" сей факт учтён не был, что приводило к неизбежным контактам с окружающим "океаном" (для э-э-э... "поддержания тонуса"). к слову сказать и сами "океаняне" были и остаются в этих контактах зело заинтересованы, ибо более чем уверены (и не без оснований кстати), что могут распоряжаться ресурсами аквариума гораздо эффективнее (читай - дорваться к сырьевой базе, что уже есть свершившийся факт). принимая во внимание этот махонький "конфликт интересов" абсолютно логично выглядит, что "План" аквариума не предусматривал гармоничного и всестороннего развития общества, что и привело к значительному дисбалансу в некоторых отраслях и сферах по сравнению с сообществом "океанян". одна из таких "сфер", где "аквариум" значительно отстал - это IT (information technology). вот и попытаемся о ней поговорить, используя нормативную лексику.
место, которое наша страна занимает сегодня в мировой индустрии IT, можно назвать "призовым" с сильной "натяжкой" (во всех смыслах, оттенках и позах этого слова). дабы не "растекаться мыслию по древу" настоятельно рекомендую ознакомиться со следующим изумительным по красоте изложения и сути произведением г-на Картунова, дающим представление о заслугах некоторых весьма уважаемых лиц перед Отечеством:
Кое-что об Эльбрусе-2000
из прочих "активов" заслуживает упоминания "свечной заводик" в славном городе Зеленограде, и пожалуй ещё возможность выпуска микропроцессорного комплекта Л1839 (аналога VAX-11/750):
"ЭЛИНС-36"
итого: "тишь, гладь, да Божья Благодать". а ежели следовать логике поговорки "нас е*** - а мы крепчаем!", то состояние наше по "крепости" думаю уже давно превышает любые мыслимые и немыслимые параметры всех известных (и неизвестных впрочем тоже) науке жидкостей, материалов и т.п.. пожалуй стоит откровенно признать, что подобное состояние вполне закономерно. почему? да потому, что "как-то так сложилось", что людям, способным думать и творить, создавать что-то новое и идти вперёд нет места в структурах нашего Отечества (опять же, "место" скорее всего таки есть, только вот оценка их труда по сравнению с "альтернативными" "местами" не выдерживает никакого сравнения). а людей, способных данные качества воспитать и развить у детей... да вы и сами всё знаете... "знак червонца проступает вместо лика на доске"(БГ). а с таким подходом альтруисты и фанатики своего дела долго здесь не задерживаются. "климат здесь не тот" (Розенбаум).
лирическое отступление: ни в коей мере не стоит считать, что только у нас всё плохо, а "за морем" всё хорошо. "хорошо там - где нас нет!" внимательно изучим следующую статью:
"DEC_Alpha"
как мне кажется на её основе стоит сделать несколько очевидных выводов:
1) наиболее ценным ресурсом в любых аспектах деятельности являются именно люди, а не материалы (сырьё);
2) наиболее передовую и перспективную разработку прикрыла более успешная/ые коммерческие компания/ии (опять же - люди, менеджмент, стратегическое планирование, позиционирование на рынке, расширение своего бизнеса и т.п.);
3) благодаря опять таки людям (команде разработчиков "Альфы") наработки не пропали даром, а используются сегодня, как в AMD, так и в Intel (такое ощущение, что порвали "Альфу", как Тузик тряпку, и куски этой "тряпки" ноне жёстко конкурируют меж собой за доли рынка).
поучительная история, не правда ли?
и на фоне этого благолепия вдруг (практически все незапланированные события случаются "вдруг"... вопрос лишь в том, является ли рассматриваемое нами событие незапланированным...) нежданно и негаданно "что-то случилось само собой в кармане полковничьих брюк"("Наутилус") и вуа-ля! "здравствуйте! я - ваша тётя!". встречаем:
"Виктор Имантович Алкснис"
"Пудинг - это Алиса! Алиса - это Пудинг! Унесите Пудинг!" (Л. Кэррол) и унеслось... настоятельно советую всем внимательно изучить "блог" этого человека и составить своё собственное мнение о его делах и поступках, ежели есть к тому малейшее желание. нас же в первую очередь интересует следующий Документ:
проект "Информационная независимость России"
постараюсь выделить некоторые моменты без отрыва от контекста (пожалуйста, укажите на возможные допущенные ошибки, "пробелы". спасибо):
1) фраза насчёт "последних пятнадцати лет" звучит как-то чересчур оптимистично в свете того, что на тайваньском заводе TSMC по модели отечественной разработки для комплекса "Эльбрус-3М1" был выпущен процессор R500 с тактовой частотой в 300Mhz, в то время как в 1992-ом году 64-разрядная версия процессора "Альфы" EV4S была способна работать на частоте 200 МГц. мы что, таки 15 лет назад имели сопоставимые продукты и инфраструктуру для их выпуска??? "а мужики-то не знают..." (рекламная пауза). или сравнение с "передовиками капиталистического труда" не входит в наши планы?
2) "Удручающее состояние...создаёт угрозу...препятствует проведению преобразований..." стоп, стоп, стоп... "я вам не скажу за всю Одессу..."(Утёсов), но:
>:/sda@black::
[21:34:32] : ~ > uname -a
Linux black 2.6.23-ARCH #1 PREEMPT Sun Oct 28 20:11:25 MSK 2007 i686 AMD Athlon(tm) 64 Processor 3700+ AuthenticAMD GNU/Linux
таки да! всё "железо" без исключения - "вражеское, забугорное". вы можете не верить, да только мне это ну ни капельки не создаёт никаких "угроз" и "препятствий". а вот операционная система (ОС) и все прикладные программы (кои целиком и полностью уже много лет удовлетворяют все мои потребности) - Open Source (с открытыми исходными кодами) - и я в праве модифицировать их так, как считаю нужным (чем иногда и занимаюсь по мере необходимости). при этом не нарушаю ни один из пунктов законодательства своей страны, связанный с незаконным использованием ПО (программного обеспечения). а основные причины, по которым произошёл отказ от использования проприетарного ПО - именно низкое качество, дикая дороговизна и банальное отсутствие оного для полного удовлетворения всех моих потребностей (наряду с прочими). да, сейчас довольно много качественного Open Source софта портировано на платформу MS Windows, токмо аналогов связки iptables+iproute(2) до сих пор и близко нет. возможно, что и не будет. если же говорить о довольно субъективном критерии "качества" и объективном критерии "функционал" - то лишь линейка продуктов компании Adobe превосходит Open Source аналоги. поскольку грубо говоря "Gimp"-а + "Evince" + утилит формирования pdf файлов мне хватает с избытком, то и надобности в продуктах от Adobe пока нет. есть правда ещё пунктик об OCR (Optical Character Recognition) - тут я полный профан, бо на сегодня схема: "картинка" со сканера -> оптимизация "картинки" -> pdf как-то прекрасно работает и без OCR.
внимание вопрос: "а что же мешает другим гражданам поступать аналогично?" на самом деле только тот предмет, который мешает плохому танцору. главное - это всегда иметь возможность осознанного выбора. если человек осознанно выбирает платформу Apple или Microsoft - это его выбор, достойный уважения. значит ему проще, удобнее, легче именно работать с этой платформой. значит он согласен платить за это свою цену. я же свою цену - цену сидения за "манами" и прочей документацией вплоть до исходных кодов - заплатил и продолжаю платить в том же духе. и честное слово, я уважаю всех, кто осознанно сделал свой выбор и также заплатил по счёту, буде то чек за лицензию на продукты Microsoft или же чек за Apple. но постойте! позор мне! опять "убежал вперёд паровоза"! "кондуктор! нажми на тормоза!"
3) "Реализация данного национального проекта должна обеспечить создание российских программных средств общего назначения, а так же производство в Российской Федерации конкурентоспособных образцов компьютерной техники и комплектующих к ней".
вопрос нумеро уно: "именно создание с нуля или адаптация уже существующего"? (это очень и очень разные суммы денег, доложу я вам).
меня так всё устраивает как оно есть ноне в исходниках. и документация на английском радует. а была бы нужная документация на китайском - так засел бы за словари или знакомого китайца попросил бы помочь. нет знакомого китайца? и интернета нет? тогда с тихой грустью и лютой пролетарской ненавистью "рыл" бы исходники... в мире Open Source не бывает безвыходных ситуаций.
вопрос нумеро дуо: "производство в Российской Федерации конкурентоспособных образцов компьютерной техники и комплектующих к ней... на какой основе? база где? что мы тут собрались производить? и самое главное - для кого?"
про ограниченное количество ресурсов не забыли? "Ну а здесь, знаешь ли, приходится бежать со всех ног, только чтобы остаться на том же месте! Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!"(Л.Кэррол) мы безнадёжно отстали в "производстве конкурентоспособных образцов компьютерной техники и комплектующих к ней". и вопрос не в деньгах. предположим на мгновение, что денег у нас - как атомов во вселенной. люди. основного ресурса у нас нет. не лучше ли вместо этой более чем сомнительной инициативы сконцентрироваться на том, что мы до сих пор умеем делать и делаем лучше других? и развивать именно эти направления, потихоньку "вытягивая" смежные отрасли из трясины? или кроме сырьевой базы в качестве "ресурсов" уже ничего не осталось?
"нет повести печальнее на свете, чем повесть о....." эх... "Испокон веков на Руси всего две проблемы... Первая - это дороги. Вторая же успешно решается при помощи асфальтоукладчика..."
4) "на первом этапе его реализации...должно быть предусмотрено создание российских программных средств общего назначения... для использования органами государственной власти, органами местного самоуправления, государственными и муниципальными унитарными предприятиями, государственными и муниципальными образовательными учреждениями."
ура! чётко очерчена "целевая аудитория". то есть можно набравшись смелости констатировать свершившийся факт: Государство призадумалось и пытается выработать для себя какие-то "правила поведения", хотя более уместно уже говорить о "правилах выживания в экстремальных условиях" и на первое место выносить именно "муниципальные образовательные учреждения". в этом контексте представляют определённый интерес проверки коммерческих структур на предмет "лицензионного ПО". "Врачу - исцелися сам!" хотя... признаю. осознанное использование коммерческой структурой нелицензионного ПО автоматически означает готовность принять на себя все риски и отвечать за последствия данного шага. но вот подобная проверка упомянутой "целевой аудитории" имеет гораздо больший смысл. особенно если была выделена и ПЕРЕЧИСЛЕНА определённая целевая сумма из бюджета в конкретно проверяемое учреждение. впрочем, я опять забегаю вперёд паровоза. хочу лишь настоятельно рекомендовать к прочтению следующую "страничку":
Дело Поносова
горжусь своим Президентом, способным внятно изложить точку зрения:
"Хватать и не пущать — это простое дело, а разобраться по существу это всегда сложнее. Если необходимо внести изменения в законодательство, которое, как я вижу, является не очень совершенным, значит, подумаем над этим.
Но вот так хватать человека, который купил там какой-то компьютер, и грозить ему тюрьмой это чушь собачья"
(В.Путин)
5) "В настоящее время сложилось доминирующее положение...является разработкой корпорации Майкрософт. При этом необходимо учитывать, что большинство ПО этой корпорации основано на недоступном пользователю исходном тексте (далее - исходный код) и в связи с этим создаются значительные трудности в обеспечении информационной безопасности"
наконец-то! "аз есмь истина!" "дети прыгали до потолка - папа в козыря попал!"(поговорка в Преферансе) и вот тут позвольте вернуться к сути пункта №4 и спросить: "так что же мешает изменить это положение дел?" ведь по большому счёту уважительных причин-то нет! было бы желание! в мире Open Source НЕТ разницы, кем создано ПО. исходники доступны и модификация исходников как правило не запрещена. кем бы ни было создано Open Source ПО - конечный пользователь всегда обладает тотальным контролем над ним (исходники-то под рукой). и не надо даже заикаться о наличии специализированного софта и отсутствии Open Source аналогов! отказ от использования продукции Майкрософт высвободит такие средства бюджета, на которые не только аналоги гипотетическому спец. софту можно будет создать с нуля, но и детишкам в детские дома и интернаты подкупить новых игрушек, одежду, отремонтировать что не так.
и опять несколько нюансов... основное здесь - что слово Linux напрямую фигурирует только в привязке к КНР, а мы все знаем, чем там дело закончилось:
Конец проекта Red Flag
но даже если события развернутся аналогичным образом - то всё равно высвободятся колоссальные средства бюджета. на детские дома должно хватить. коды же самой ОС Windows в теории должны быть (уже) открыты госструктурам РФ. вопрос только в цене лицензии на их возможную модификацию. то есть вопрос этот ещё и не вопрос вовсе. что же до создания Open Source приложений под Windows - так их и ноне ужо портировано вагон с телегой, да и в Microsoft работают далеко не идиоты - уже зарегистрировали 2 своих Open Source лицензии. им-то подавно не надо самим себе доказывать всю ущербность собственного ПО по сравнению с Open Source аналогами. я конечно же утрирую. Microsoft безусловно создала некоторые очень функциональные программные продукты (тот же Active Directory), но посмотрите сами на долю решений от MS, работающих в top 500! и пусть это субъективно, но мой собственный "десктоп" работает лучше и гораздо функциональнее любого "десктоп" решения от этой уважаемой корпорации. хотя бы потому, что позволяет делать вещи именно так, как я хочу, а не так, как считает правильным продукт от MS (который практически всегда считает себя "умнее" конечного пользователя/администратора). "I'll find a Way. Or make One" (Atlanta Clark University).
6) "...российское ПО также должно иметь статус свободного ПО с доступным пользователю исходным кодом и распространяться на основании свободной лицензии, то есть лицензии, позволяющей пользователю использовать исходный код ПО для своих нужд, в том числе вносить в него изменения и распространять его."
ДА!
7) "Создать такое ПО в РФ возможно, если использовать ПО, существующие в настоящее время, выверенные, основанные на открытом исходном коде и распространяемые на основании свободной лицензии. Это сократит финансовые..." (ещё бы! кто б сомневался!)
ДА!
нюанс: как правило нет в природе ПО, полностью свободного от ошибок. необходимо чётко отдавать себе в этом отчёт. огромнейшим преимуществом Open Source ПО является способность латать "дыры" в кратчайшие сроки и не делать тайны из найденных уязвимостей, что даёт грамотным администраторам возможность самостоятельно оперативно реагировать и закрывать уязвимости "подручными средствами", коих превеликое множество. и по моему скромному разумению необходимо и достаточно не заниматься тупой и бесполезной "выверкой" кода, а именно готовить толковых администраторов и программистов, способных находить и устранять подобные уязвимости. и всеми силами избегать схемы "security through obscurity" (это безопасно потому, что об этой опасности ещё никто не знает).
8) насчёт разработки дополнительных необходимых программ и последующего распространения на платной основе - немного непонятно, но вроде как ни одна из Open Source лицензий при условии соблюдения её требований подобного нe запрещаeт.
9) "...отказ от использования в деятельности по ведению делопроизводства и документооборота... так называемых документов с закрытым форматом, в частности DOC...и переход на использование документов с так называемым открытым международным форматом, в частности ODF"
ДА!
нюанс: во втором круге голосования неплохо бы нашей стране отказать Open XML документам от права называть себя "документами с так называемым открытым международным форматом" (а то в первом круге дружно проорали "одобрям-с!", а потом неделю искали того/тех, кто собственно орал...) или же добиваться полного открытия спеков на все форматы документов компании Microsoft.
10) "... Потребуется поддержка от государства в постановке задач по созданию и стандартизации программного обеспечения, управлению таким проектом, а также финансированию предусмотренных им приоритетных разработок."
а почему бы сразу не написать что-то типа:
"... Потребуется поддержка от государства в постановке задач по созданию и стандартизации программного обеспечения, управлению таким проектом, финансированию предусмотренных им приоритетных разработок а также по дальнейшей интеграции и поддержке развития всего Open Source Community."
именно акцентируя во-первых на чётко расставленных национальных приоритетах, а во-вторых на полное одобрение и поддержку со стороны государства (как минимум) подобной сферы деятельности. в этом случае правда придётся слова делами подкреплять не одномоментно, но постоянно. впрочем и так, как есть - вполне неплохо.
позвольте же мне после цифири 10 в меру скудоумия подвесть итогову черту: "Поезд тронулся, господа присяжные заседатели!"(О.Бендер)
я искренне и от всего сердца благодарю господина Алксниса за всё, что он делает по продвижению проекта "Информационная независимость России" и желаю Виктору Имантовичу "долгие лета", успехов и удачи в сём многотрудном начинании.
(Суворов)
"Политика - это искусство возможного"
(Отто фон Бисмарк)
поскольку по предмету "Политпроституция" в моей "зачётке" стоит твёрдый "Неуд.", или говоря проще - "единица" по любой из возможных систем оценок (5-ти бальной, 10-ти и т.д.), то особого смысла "марать бумагу" вроде как и нет. но, ежели рассматривать сей опус как некое развлекательное чтиво (а-ля pulp fiction), то "пуркуа бы и не па"?
коли вдруг сие "творение" вызовет абсолютно нехарактерный для моего блога наплыв "камментов" - заранее предупреждаю: любые высказывания личностного характера, наносящие ущерб чести и достоинству упомянутых в этом трэде юридических и физических лиц, будут удалены. меня же можете костерить насколько хватит фантазии, ибо всегда приятно оценивать человека по его высказываниям.
для начала - краткий экскурс в историю.
с момента падения династии Романовых и замены института монархии на институт "вся власть - советам" многострадальная "одна шестая часть" мирового сухопутного пространства стала напоминать герметичный аквариум со стенками из "кривого" стекла, искажающего восприятие в обе стороны, окружённый водами мирового океана. поскольку ограниченность ресурсов и деятельности существ в условиях безграничности потребностей есть суть аксиома экономической науки, то в упомянутом "аквариуме" царствовало плановое распределение имеющихся ресурсов (иначе именуемое как "Планирование", поскольку "прости, дорогая, но так получилось"), без малейшей оглядки на насущные потребности индивидуумов (к слову сказать сам термин "индивидуум" был до недавнего времени ругательным). несмотря на то, что ограниченные природные и человеческие ресурсы "аквариума" с лихвой могли обеспечить более-менее сносное существование и воспроизводство популяции, "Планом" сей факт учтён не был, что приводило к неизбежным контактам с окружающим "океаном" (для э-э-э... "поддержания тонуса"). к слову сказать и сами "океаняне" были и остаются в этих контактах зело заинтересованы, ибо более чем уверены (и не без оснований кстати), что могут распоряжаться ресурсами аквариума гораздо эффективнее (читай - дорваться к сырьевой базе, что уже есть свершившийся факт). принимая во внимание этот махонький "конфликт интересов" абсолютно логично выглядит, что "План" аквариума не предусматривал гармоничного и всестороннего развития общества, что и привело к значительному дисбалансу в некоторых отраслях и сферах по сравнению с сообществом "океанян". одна из таких "сфер", где "аквариум" значительно отстал - это IT (information technology). вот и попытаемся о ней поговорить, используя нормативную лексику.
место, которое наша страна занимает сегодня в мировой индустрии IT, можно назвать "призовым" с сильной "натяжкой" (во всех смыслах, оттенках и позах этого слова). дабы не "растекаться мыслию по древу" настоятельно рекомендую ознакомиться со следующим изумительным по красоте изложения и сути произведением г-на Картунова, дающим представление о заслугах некоторых весьма уважаемых лиц перед Отечеством:
Кое-что об Эльбрусе-2000
из прочих "активов" заслуживает упоминания "свечной заводик" в славном городе Зеленограде, и пожалуй ещё возможность выпуска микропроцессорного комплекта Л1839 (аналога VAX-11/750):
"ЭЛИНС-36"
итого: "тишь, гладь, да Божья Благодать". а ежели следовать логике поговорки "нас е*** - а мы крепчаем!", то состояние наше по "крепости" думаю уже давно превышает любые мыслимые и немыслимые параметры всех известных (и неизвестных впрочем тоже) науке жидкостей, материалов и т.п.. пожалуй стоит откровенно признать, что подобное состояние вполне закономерно. почему? да потому, что "как-то так сложилось", что людям, способным думать и творить, создавать что-то новое и идти вперёд нет места в структурах нашего Отечества (опять же, "место" скорее всего таки есть, только вот оценка их труда по сравнению с "альтернативными" "местами" не выдерживает никакого сравнения). а людей, способных данные качества воспитать и развить у детей... да вы и сами всё знаете... "знак червонца проступает вместо лика на доске"(БГ). а с таким подходом альтруисты и фанатики своего дела долго здесь не задерживаются. "климат здесь не тот" (Розенбаум).
лирическое отступление: ни в коей мере не стоит считать, что только у нас всё плохо, а "за морем" всё хорошо. "хорошо там - где нас нет!" внимательно изучим следующую статью:
"DEC_Alpha"
как мне кажется на её основе стоит сделать несколько очевидных выводов:
1) наиболее ценным ресурсом в любых аспектах деятельности являются именно люди, а не материалы (сырьё);
2) наиболее передовую и перспективную разработку прикрыла более успешная/ые коммерческие компания/ии (опять же - люди, менеджмент, стратегическое планирование, позиционирование на рынке, расширение своего бизнеса и т.п.);
3) благодаря опять таки людям (команде разработчиков "Альфы") наработки не пропали даром, а используются сегодня, как в AMD, так и в Intel (такое ощущение, что порвали "Альфу", как Тузик тряпку, и куски этой "тряпки" ноне жёстко конкурируют меж собой за доли рынка).
поучительная история, не правда ли?
и на фоне этого благолепия вдруг (практически все незапланированные события случаются "вдруг"... вопрос лишь в том, является ли рассматриваемое нами событие незапланированным...) нежданно и негаданно "что-то случилось само собой в кармане полковничьих брюк"("Наутилус") и вуа-ля! "здравствуйте! я - ваша тётя!". встречаем:
"Виктор Имантович Алкснис"
"Пудинг - это Алиса! Алиса - это Пудинг! Унесите Пудинг!" (Л. Кэррол) и унеслось... настоятельно советую всем внимательно изучить "блог" этого человека и составить своё собственное мнение о его делах и поступках, ежели есть к тому малейшее желание. нас же в первую очередь интересует следующий Документ:
проект "Информационная независимость России"
постараюсь выделить некоторые моменты без отрыва от контекста (пожалуйста, укажите на возможные допущенные ошибки, "пробелы". спасибо):
1) фраза насчёт "последних пятнадцати лет" звучит как-то чересчур оптимистично в свете того, что на тайваньском заводе TSMC по модели отечественной разработки для комплекса "Эльбрус-3М1" был выпущен процессор R500 с тактовой частотой в 300Mhz, в то время как в 1992-ом году 64-разрядная версия процессора "Альфы" EV4S была способна работать на частоте 200 МГц. мы что, таки 15 лет назад имели сопоставимые продукты и инфраструктуру для их выпуска??? "а мужики-то не знают..." (рекламная пауза). или сравнение с "передовиками капиталистического труда" не входит в наши планы?
2) "Удручающее состояние...создаёт угрозу...препятствует проведению преобразований..." стоп, стоп, стоп... "я вам не скажу за всю Одессу..."(Утёсов), но:
>:/sda@black::
[21:34:32] : ~ > uname -a
Linux black 2.6.23-ARCH #1 PREEMPT Sun Oct 28 20:11:25 MSK 2007 i686 AMD Athlon(tm) 64 Processor 3700+ AuthenticAMD GNU/Linux
таки да! всё "железо" без исключения - "вражеское, забугорное". вы можете не верить, да только мне это ну ни капельки не создаёт никаких "угроз" и "препятствий". а вот операционная система (ОС) и все прикладные программы (кои целиком и полностью уже много лет удовлетворяют все мои потребности) - Open Source (с открытыми исходными кодами) - и я в праве модифицировать их так, как считаю нужным (чем иногда и занимаюсь по мере необходимости). при этом не нарушаю ни один из пунктов законодательства своей страны, связанный с незаконным использованием ПО (программного обеспечения). а основные причины, по которым произошёл отказ от использования проприетарного ПО - именно низкое качество, дикая дороговизна и банальное отсутствие оного для полного удовлетворения всех моих потребностей (наряду с прочими). да, сейчас довольно много качественного Open Source софта портировано на платформу MS Windows, токмо аналогов связки iptables+iproute(2) до сих пор и близко нет. возможно, что и не будет. если же говорить о довольно субъективном критерии "качества" и объективном критерии "функционал" - то лишь линейка продуктов компании Adobe превосходит Open Source аналоги. поскольку грубо говоря "Gimp"-а + "Evince" + утилит формирования pdf файлов мне хватает с избытком, то и надобности в продуктах от Adobe пока нет. есть правда ещё пунктик об OCR (Optical Character Recognition) - тут я полный профан, бо на сегодня схема: "картинка" со сканера -> оптимизация "картинки" -> pdf как-то прекрасно работает и без OCR.
внимание вопрос: "а что же мешает другим гражданам поступать аналогично?" на самом деле только тот предмет, который мешает плохому танцору. главное - это всегда иметь возможность осознанного выбора. если человек осознанно выбирает платформу Apple или Microsoft - это его выбор, достойный уважения. значит ему проще, удобнее, легче именно работать с этой платформой. значит он согласен платить за это свою цену. я же свою цену - цену сидения за "манами" и прочей документацией вплоть до исходных кодов - заплатил и продолжаю платить в том же духе. и честное слово, я уважаю всех, кто осознанно сделал свой выбор и также заплатил по счёту, буде то чек за лицензию на продукты Microsoft или же чек за Apple. но постойте! позор мне! опять "убежал вперёд паровоза"! "кондуктор! нажми на тормоза!"
3) "Реализация данного национального проекта должна обеспечить создание российских программных средств общего назначения, а так же производство в Российской Федерации конкурентоспособных образцов компьютерной техники и комплектующих к ней".
вопрос нумеро уно: "именно создание с нуля или адаптация уже существующего"? (это очень и очень разные суммы денег, доложу я вам).
меня так всё устраивает как оно есть ноне в исходниках. и документация на английском радует. а была бы нужная документация на китайском - так засел бы за словари или знакомого китайца попросил бы помочь. нет знакомого китайца? и интернета нет? тогда с тихой грустью и лютой пролетарской ненавистью "рыл" бы исходники... в мире Open Source не бывает безвыходных ситуаций.
вопрос нумеро дуо: "производство в Российской Федерации конкурентоспособных образцов компьютерной техники и комплектующих к ней... на какой основе? база где? что мы тут собрались производить? и самое главное - для кого?"
про ограниченное количество ресурсов не забыли? "Ну а здесь, знаешь ли, приходится бежать со всех ног, только чтобы остаться на том же месте! Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!"(Л.Кэррол) мы безнадёжно отстали в "производстве конкурентоспособных образцов компьютерной техники и комплектующих к ней". и вопрос не в деньгах. предположим на мгновение, что денег у нас - как атомов во вселенной. люди. основного ресурса у нас нет. не лучше ли вместо этой более чем сомнительной инициативы сконцентрироваться на том, что мы до сих пор умеем делать и делаем лучше других? и развивать именно эти направления, потихоньку "вытягивая" смежные отрасли из трясины? или кроме сырьевой базы в качестве "ресурсов" уже ничего не осталось?
"нет повести печальнее на свете, чем повесть о....." эх... "Испокон веков на Руси всего две проблемы... Первая - это дороги. Вторая же успешно решается при помощи асфальтоукладчика..."
4) "на первом этапе его реализации...должно быть предусмотрено создание российских программных средств общего назначения... для использования органами государственной власти, органами местного самоуправления, государственными и муниципальными унитарными предприятиями, государственными и муниципальными образовательными учреждениями."
ура! чётко очерчена "целевая аудитория". то есть можно набравшись смелости констатировать свершившийся факт: Государство призадумалось и пытается выработать для себя какие-то "правила поведения", хотя более уместно уже говорить о "правилах выживания в экстремальных условиях" и на первое место выносить именно "муниципальные образовательные учреждения". в этом контексте представляют определённый интерес проверки коммерческих структур на предмет "лицензионного ПО". "Врачу - исцелися сам!" хотя... признаю. осознанное использование коммерческой структурой нелицензионного ПО автоматически означает готовность принять на себя все риски и отвечать за последствия данного шага. но вот подобная проверка упомянутой "целевой аудитории" имеет гораздо больший смысл. особенно если была выделена и ПЕРЕЧИСЛЕНА определённая целевая сумма из бюджета в конкретно проверяемое учреждение. впрочем, я опять забегаю вперёд паровоза. хочу лишь настоятельно рекомендовать к прочтению следующую "страничку":
Дело Поносова
горжусь своим Президентом, способным внятно изложить точку зрения:
"Хватать и не пущать — это простое дело, а разобраться по существу это всегда сложнее. Если необходимо внести изменения в законодательство, которое, как я вижу, является не очень совершенным, значит, подумаем над этим.
Но вот так хватать человека, который купил там какой-то компьютер, и грозить ему тюрьмой это чушь собачья"
(В.Путин)
5) "В настоящее время сложилось доминирующее положение...является разработкой корпорации Майкрософт. При этом необходимо учитывать, что большинство ПО этой корпорации основано на недоступном пользователю исходном тексте (далее - исходный код) и в связи с этим создаются значительные трудности в обеспечении информационной безопасности"
наконец-то! "аз есмь истина!" "дети прыгали до потолка - папа в козыря попал!"(поговорка в Преферансе) и вот тут позвольте вернуться к сути пункта №4 и спросить: "так что же мешает изменить это положение дел?" ведь по большому счёту уважительных причин-то нет! было бы желание! в мире Open Source НЕТ разницы, кем создано ПО. исходники доступны и модификация исходников как правило не запрещена. кем бы ни было создано Open Source ПО - конечный пользователь всегда обладает тотальным контролем над ним (исходники-то под рукой). и не надо даже заикаться о наличии специализированного софта и отсутствии Open Source аналогов! отказ от использования продукции Майкрософт высвободит такие средства бюджета, на которые не только аналоги гипотетическому спец. софту можно будет создать с нуля, но и детишкам в детские дома и интернаты подкупить новых игрушек, одежду, отремонтировать что не так.
и опять несколько нюансов... основное здесь - что слово Linux напрямую фигурирует только в привязке к КНР, а мы все знаем, чем там дело закончилось:
Конец проекта Red Flag
но даже если события развернутся аналогичным образом - то всё равно высвободятся колоссальные средства бюджета. на детские дома должно хватить. коды же самой ОС Windows в теории должны быть (уже) открыты госструктурам РФ. вопрос только в цене лицензии на их возможную модификацию. то есть вопрос этот ещё и не вопрос вовсе. что же до создания Open Source приложений под Windows - так их и ноне ужо портировано вагон с телегой, да и в Microsoft работают далеко не идиоты - уже зарегистрировали 2 своих Open Source лицензии. им-то подавно не надо самим себе доказывать всю ущербность собственного ПО по сравнению с Open Source аналогами. я конечно же утрирую. Microsoft безусловно создала некоторые очень функциональные программные продукты (тот же Active Directory), но посмотрите сами на долю решений от MS, работающих в top 500! и пусть это субъективно, но мой собственный "десктоп" работает лучше и гораздо функциональнее любого "десктоп" решения от этой уважаемой корпорации. хотя бы потому, что позволяет делать вещи именно так, как я хочу, а не так, как считает правильным продукт от MS (который практически всегда считает себя "умнее" конечного пользователя/администратора). "I'll find a Way. Or make One" (Atlanta Clark University).
6) "...российское ПО также должно иметь статус свободного ПО с доступным пользователю исходным кодом и распространяться на основании свободной лицензии, то есть лицензии, позволяющей пользователю использовать исходный код ПО для своих нужд, в том числе вносить в него изменения и распространять его."
ДА!
7) "Создать такое ПО в РФ возможно, если использовать ПО, существующие в настоящее время, выверенные, основанные на открытом исходном коде и распространяемые на основании свободной лицензии. Это сократит финансовые..." (ещё бы! кто б сомневался!)
ДА!
нюанс: как правило нет в природе ПО, полностью свободного от ошибок. необходимо чётко отдавать себе в этом отчёт. огромнейшим преимуществом Open Source ПО является способность латать "дыры" в кратчайшие сроки и не делать тайны из найденных уязвимостей, что даёт грамотным администраторам возможность самостоятельно оперативно реагировать и закрывать уязвимости "подручными средствами", коих превеликое множество. и по моему скромному разумению необходимо и достаточно не заниматься тупой и бесполезной "выверкой" кода, а именно готовить толковых администраторов и программистов, способных находить и устранять подобные уязвимости. и всеми силами избегать схемы "security through obscurity" (это безопасно потому, что об этой опасности ещё никто не знает).
8) насчёт разработки дополнительных необходимых программ и последующего распространения на платной основе - немного непонятно, но вроде как ни одна из Open Source лицензий при условии соблюдения её требований подобного нe запрещаeт.
9) "...отказ от использования в деятельности по ведению делопроизводства и документооборота... так называемых документов с закрытым форматом, в частности DOC...и переход на использование документов с так называемым открытым международным форматом, в частности ODF"
ДА!
нюанс: во втором круге голосования неплохо бы нашей стране отказать Open XML документам от права называть себя "документами с так называемым открытым международным форматом" (а то в первом круге дружно проорали "одобрям-с!", а потом неделю искали того/тех, кто собственно орал...) или же добиваться полного открытия спеков на все форматы документов компании Microsoft.
10) "... Потребуется поддержка от государства в постановке задач по созданию и стандартизации программного обеспечения, управлению таким проектом, а также финансированию предусмотренных им приоритетных разработок."
а почему бы сразу не написать что-то типа:
"... Потребуется поддержка от государства в постановке задач по созданию и стандартизации программного обеспечения, управлению таким проектом, финансированию предусмотренных им приоритетных разработок а также по дальнейшей интеграции и поддержке развития всего Open Source Community."
именно акцентируя во-первых на чётко расставленных национальных приоритетах, а во-вторых на полное одобрение и поддержку со стороны государства (как минимум) подобной сферы деятельности. в этом случае правда придётся слова делами подкреплять не одномоментно, но постоянно. впрочем и так, как есть - вполне неплохо.
позвольте же мне после цифири 10 в меру скудоумия подвесть итогову черту: "Поезд тронулся, господа присяжные заседатели!"(О.Бендер)
я искренне и от всего сердца благодарю господина Алксниса за всё, что он делает по продвижению проекта "Информационная независимость России" и желаю Виктору Имантовичу "долгие лета", успехов и удачи в сём многотрудном начинании.
понедельник, 5 ноября 2007 г.
E17 и "прозрачность"
традиционно в *nix X Window System за "прозрачность" ответственен 'Composite' модуль xorg-а (XFree86). проверить его наличие можно следующей командой:
> xdpyinfo | grep Composite
Composite
для "включения" в работу нужно чуток модифицировать ваш xorg.conf. владельцам видеокарт nvidia стоит воспользоваться следующими командами:
> nvidia-xconfig --composite
> nvidia-xconfig --allow-glx-with-composite
и в Device секцию "добросить" строку:
Option "RenderAccel" "true"
если после упомянутых трудов есть желание посмотреть на эталонную работу WM-а с прозрачностью окон - ставьте E16. у "старшего брата" (E17-го) с этим пока далеко не всё гладко. как вариант - поиграть с модулем 'bling':
> enlightenment_remote -module-load bling
> enlightenment_remote -module-enable bling
но рекомендовать для повседневного пользования сие не могу. в этой ситуации гораздо более разумным решением является связка 'xcompmgr'+'transset'. дёшево и сердито. перед использованием стоит ознакомиться с man страницей xcompmgr-а. для себя поступил очень просто:
> cat ~/bin/xcompmgr_01
#!/bin/sh
xcompmgr -c -f -F -n &
> cat ~/bin/transset_01
#!/bin/sh
transset .9
после чего повесил на хоткеи команды transset, transset_01, xcompmgr_01, 'killall xcompmgr'. результат более чем скромен, но меня очень радует (учитывая отказ urxvt работать в E17 с "URxvt*inheritPixmap: true"):
> xdpyinfo | grep Composite
Composite
для "включения" в работу нужно чуток модифицировать ваш xorg.conf. владельцам видеокарт nvidia стоит воспользоваться следующими командами:
> nvidia-xconfig --composite
> nvidia-xconfig --allow-glx-with-composite
и в Device секцию "добросить" строку:
Option "RenderAccel" "true"
если после упомянутых трудов есть желание посмотреть на эталонную работу WM-а с прозрачностью окон - ставьте E16. у "старшего брата" (E17-го) с этим пока далеко не всё гладко. как вариант - поиграть с модулем 'bling':
> enlightenment_remote -module-load bling
> enlightenment_remote -module-enable bling
но рекомендовать для повседневного пользования сие не могу. в этой ситуации гораздо более разумным решением является связка 'xcompmgr'+'transset'. дёшево и сердито. перед использованием стоит ознакомиться с man страницей xcompmgr-а. для себя поступил очень просто:
> cat ~/bin/xcompmgr_01
#!/bin/sh
xcompmgr -c -f -F -n &
> cat ~/bin/transset_01
#!/bin/sh
transset .9
после чего повесил на хоткеи команды transset, transset_01, xcompmgr_01, 'killall xcompmgr'. результат более чем скромен, но меня очень радует (учитывая отказ urxvt работать в E17 с "URxvt*inheritPixmap: true"):
четверг, 1 ноября 2007 г.
Взгляд ушастого ламера на компиляцию ядра из исходников... Монолит или модули?
я таки подозревал, что придётся "ответ держать". извольте.
спрашивали?
Attila комментирует...
А вот почему бы не вкомпилить модули, необходимые для работы жёсткого диска, сетевой карты, корневой файловой системы и т.п монолитно? Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти.
Всё в ядре и вообще никакой мороки с модулЯми?
отвечаем...
любое подобное "включение" приводит к снижению уровня "гибкости" системы. начиная от банальной потери возможности передать модулю какие-то параметры при загрузке и заканчивая тупой аксиомой - "а яго ужо не выгрузишь". примерно процитирую высказывания с LDP о преимуществах использования модулей:
1) нет нужды пересобирать каждый раз ядро;
2) любой баг в ядре гораздо труднее отследить, чем баг в модуле;
3) любой баг в модуле менее критичен, чем баг в самом ядре и отслеживается в разы быстрее (спорно, но это правда);
3) более оптимальное использование памяти компьютера;
4) нет прироста в производительности при жёстком включении.
с учётом вышесказанного никакого смысла нет в ядро пихать даже драйвер корневой файловой системы - Initial Ramdisk придумали явно не зря, не так ли?
морока именно имеет место быть, когда люди от большого ума пытаются засунуть в ядро абсолютно лишние компоненты. история из реальной жизни. один знакомый молодой человек, начитавшись статей многоуважаемого г-на Федорчука, решил поставить себе на ноут Zenwalk. да только не обратил, сердешный, внимания в пылу энтузиазма на фразу: "В Zenwalk функции управления тактовой частотой ноутбучных процессоров вкомпилированы в ядро, а не собраны с виде модуля, как это делается обычно. Поэтому, если обладателя двухгигарецового процессора раздражает работа на тактовой частоте 800 Mhz (а меня, например, это раздражает весьма сильно), то придется пересобирать ядро, чем я намерен заняться в ближайшее время." очень интересная фраза... я буду весьма признателен, если кто-нибудь мне объяснит необходимость пересборки ядра в данном случае. необходимо и достаточно поставить пакет "cpufrequtils" и ознакомиться с man-страницей или просто разобраться в схеме управления параметрами ядра через /proc, /sys. в нашем же случае всё было с точностью до наоборот. ядро Zenwalk-а раскочегарило "Кору-дуру" так, что вентиляторы были готовы "рвануть в небо", а на клавиатуре можно было еду разогревать. пакета "cpufrequtils" знакомый не нашёл (что не повод делать выводы, хотя...), посему тупенько через /sys выставили дефолтный cpu governor на ondemand. и всё. "сковородочка стала остывать".
включение в ядро только минимума стимулирует "любознательность" не в пример сильнее, чем безалаберное пихание в него чего ни попадя. да и на будущее в разы полезнее.
отдельно выделим фразу: "Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти". а вот в компании Red Hat в "Red Hat Enterprise Linux 4: Руководство по системному администрированию" считают иначе:
"Ядро Linux имеет модульную структуру. При загрузке в память загружается только минимальное резидентное ядро. После этого, если пользователь вызывает функцию, отсутствующую в резидентном ядре, нужный модуль ядра, иногда называемый драйвером, динамически загружается в память."
правда на правду? или всё же RTFM? что и находит подтверждение в LDP: "LKMs did not exist in Linux in the beginning. Anything we use an LKM for today was built into the base kernel at kernel build time instead. LKMs have been around at least since Linux 1.2 (1995)." то бишь с 1995-го года ядро имеет "модульную структуру", а мы всё заикаемся о "некоторой поддержкой модульнотсти" и рвёмся "придется пересобирать ядро, чем я намерен заняться в ближайшее время". вот это и называется "Пиздец", господа, и именно с большой буквы "П".
спрашивали?
Attila комментирует...
А вот почему бы не вкомпилить модули, необходимые для работы жёсткого диска, сетевой карты, корневой файловой системы и т.п монолитно? Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти.
Всё в ядре и вообще никакой мороки с модулЯми?
отвечаем...
любое подобное "включение" приводит к снижению уровня "гибкости" системы. начиная от банальной потери возможности передать модулю какие-то параметры при загрузке и заканчивая тупой аксиомой - "а яго ужо не выгрузишь". примерно процитирую высказывания с LDP о преимуществах использования модулей:
1) нет нужды пересобирать каждый раз ядро;
2) любой баг в ядре гораздо труднее отследить, чем баг в модуле;
3) любой баг в модуле менее критичен, чем баг в самом ядре и отслеживается в разы быстрее (спорно, но это правда);
3) более оптимальное использование памяти компьютера;
4) нет прироста в производительности при жёстком включении.
с учётом вышесказанного никакого смысла нет в ядро пихать даже драйвер корневой файловой системы - Initial Ramdisk придумали явно не зря, не так ли?
морока именно имеет место быть, когда люди от большого ума пытаются засунуть в ядро абсолютно лишние компоненты. история из реальной жизни. один знакомый молодой человек, начитавшись статей многоуважаемого г-на Федорчука, решил поставить себе на ноут Zenwalk. да только не обратил, сердешный, внимания в пылу энтузиазма на фразу: "В Zenwalk функции управления тактовой частотой ноутбучных процессоров вкомпилированы в ядро, а не собраны с виде модуля, как это делается обычно. Поэтому, если обладателя двухгигарецового процессора раздражает работа на тактовой частоте 800 Mhz (а меня, например, это раздражает весьма сильно), то придется пересобирать ядро, чем я намерен заняться в ближайшее время." очень интересная фраза... я буду весьма признателен, если кто-нибудь мне объяснит необходимость пересборки ядра в данном случае. необходимо и достаточно поставить пакет "cpufrequtils" и ознакомиться с man-страницей или просто разобраться в схеме управления параметрами ядра через /proc, /sys. в нашем же случае всё было с точностью до наоборот. ядро Zenwalk-а раскочегарило "Кору-дуру" так, что вентиляторы были готовы "рвануть в небо", а на клавиатуре можно было еду разогревать. пакета "cpufrequtils" знакомый не нашёл (что не повод делать выводы, хотя...), посему тупенько через /sys выставили дефолтный cpu governor на ondemand. и всё. "сковородочка стала остывать".
включение в ядро только минимума стимулирует "любознательность" не в пример сильнее, чем безалаберное пихание в него чего ни попадя. да и на будущее в разы полезнее.
отдельно выделим фразу: "Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти". а вот в компании Red Hat в "Red Hat Enterprise Linux 4: Руководство по системному администрированию" считают иначе:
"Ядро Linux имеет модульную структуру. При загрузке в память загружается только минимальное резидентное ядро. После этого, если пользователь вызывает функцию, отсутствующую в резидентном ядре, нужный модуль ядра, иногда называемый драйвером, динамически загружается в память."
правда на правду? или всё же RTFM? что и находит подтверждение в LDP: "LKMs did not exist in Linux in the beginning. Anything we use an LKM for today was built into the base kernel at kernel build time instead. LKMs have been around at least since Linux 1.2 (1995)." то бишь с 1995-го года ядро имеет "модульную структуру", а мы всё заикаемся о "некоторой поддержкой модульнотсти" и рвёмся "придется пересобирать ядро, чем я намерен заняться в ближайшее время". вот это и называется "Пиздец", господа, и именно с большой буквы "П".
среда, 31 октября 2007 г.
Взгляд ушастого ламера на компиляцию ядра из исходников...
приветствуются любые замечания, предложения, дополнения и т.п.. тема заезжена, ни на какую оригинальность сей опус не претендует, но, может кто найдёт сей метод более удобным, поскольку он предполагает довольно быстрый и удобный способ модификации конфига.
какие могут быть причины для подобного шага? их всего три:
1) использование новых функций, отсутствующих в текущем ядре дистрибутива;
2) оптимизация под текущую конфигурацию "железа";
3) если установлено специфичное оборудование или возникает конфликт аппаратного обеспечения со стандартным ядром
вторая причина довольно неоднозначна, ибо эффект от модернизации самого железа, который достигается за, не побоюсь этого слова, копейки, в разы перекроет любую оптимизацию программного обеспечения. но она же подразумевает сборку ядра без лишних компонентов/модулей, что оправдано для ряда специализированного оборудования. всё остальное - не серьёзно. можно заниматься этиим ради удовлетворения собственного любопытства, можно экспериментировать с флагами опримизации, можно... можно даже встать на уши, разогнаться и впечататься в ближайшую стену - гулять так с музыкой... третью причину ранее смело выносили на первое место, да времена ужо не те.
нюанс... при дороговизне трафика сборка из исходников полностью себя оправдывает. тратить деньги за десяток килобайт на сжатый diff файл или тянуть десяток мегабайт кем-то скомпиленного готового ядра? это справедливо для любых "крупных" пакетов, будь то OpenOffice, kernel, E17 :).
ещё один спорный момент: монолит или модульное? на ваше усмотрение, господа присяжные заседатели. с точки зрения "ламера ушастого" - монолит ноне не нужен.
что нам понадобится из "инструментария":
Meld
( пользователи SuSE имеют в "загашнике" JMeld )
и конфиг ядра дистрибутива, работающего в данный момент (стоит ли напомнить, что желательно иметь одинаковую major версию ядра - например 2.6.*?). предположим, что конфиг вкомпилен в ядро и его можно "достать" командой:
zcat /proc/config.gz
что мы и делаем в качестве нашего первого шага:
zcat /proc/config.gz > /home/USER/config_current
распаковываем исходники нового ядра и выполняем:
make menuconfig
затем выбираем опцию: "Load an Alternate Configuration File" -> /home/USER/config_current
тем самым загружая текущую конфигурацию ядра. после сразу же делаем:
"Save an Alternate Configuration File" -> /home/USER/config_new
всё, что нам осталось сделать, это пройтись meld-ом по этим двум файлам (config_current и config_new) и сформировать наш будущий конфиг с учётом всех новых опций, загрузив его уже известным "Load an Alternate Configuration File". если есть сомнения в параметрах новых опций - ставим "=m", видим явно лишнюю опцию - комментируем, ставя в начало строки "#". желаете описание каждой опции в параметрах конфигурации ядра - читайте документацию. основное правило: в ядро - только необходимый минимум, всё, что только можно, - вынести в модули. именно при таком подходе можно получить выигрыш во времени как при старте системы (подгружая только необходимое), так и по использованию памяти самим ядром.
N.B. товарищ, помни: "автоматом" подгрузить модуль можно, но выгрузить - только "вручную" (как вариант - использовать скрипты-"обвязки").
дальнейшие команды по сборке и установке нового ядра (make dep && make clean успели устареть):
make
make modules
sudo make modules_install
sudo make install
необязательные (но иногда крайне полезные) команды, выполняемые после установки (но до перезагрузки). если внимательно смотреть на вывод предыдущих 2-х команд, то в них нужды особой нет (так как именно они и выполняются в процессе), хотя...:
sudo depmod -a
(sudo depmod -aq)
смотрим на вывод команды и проверяем, какие модули будут активированы при загрузке того или иного установленного в системе ядра и собственно проверяем корректность .map файла нового ядра. эта каманда позволит сравнить загружаемые модули вашего старого/(старых) и только что установленного нового кернела. излишне пожалуй говорить, что практически все проблемы разряда "сабрал новае видро а ано нигрузиццо..." могут/должны быть устранены на этой стадии.
в зависимости от системы можно (естественно при желании) пересобрать Initial RAM Disk командами "mkinitrd" или "mkinitcpio" (обратите внимание на /etc/mkinitcpio.conf !!! отсутствие необходимых опций в нём может привести к провалу при загрузке нового кернела) - читайте справку по опциям. приведу для примера свой /etc/mkinitcpio.conf:
MODULES="pata_via sata_via reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata usbinput keymap filesystems"
сие означает, что на чипсете VIA имею IDE и SATA винты, плюс пользую reiserfs. основная же нагрузка падает на HOOKS. для понимания оных - читайте доки и комментарии в самом /etc/mkinitcpio.conf (мне хватило комментариев).
на закуску - несколько интересных статей в продолжение темы:
Ядерная физика для домохозяйки
ещё одна абсолютно чумовая статейка с использованием временных "рэперов" и живым примером перехода от 2.4 до 2.6:
Установка ядра linux-2.6.1 (вместо 2.4.x)
намеренно не затронут вопрос модификации загрузчика (внесения нового ядра в список оного) - ибо пошло и неинтересно.
какие могут быть причины для подобного шага? их всего три:
1) использование новых функций, отсутствующих в текущем ядре дистрибутива;
2) оптимизация под текущую конфигурацию "железа";
3) если установлено специфичное оборудование или возникает конфликт аппаратного обеспечения со стандартным ядром
вторая причина довольно неоднозначна, ибо эффект от модернизации самого железа, который достигается за, не побоюсь этого слова, копейки, в разы перекроет любую оптимизацию программного обеспечения. но она же подразумевает сборку ядра без лишних компонентов/модулей, что оправдано для ряда специализированного оборудования. всё остальное - не серьёзно. можно заниматься этиим ради удовлетворения собственного любопытства, можно экспериментировать с флагами опримизации, можно... можно даже встать на уши, разогнаться и впечататься в ближайшую стену - гулять так с музыкой... третью причину ранее смело выносили на первое место, да времена ужо не те.
нюанс... при дороговизне трафика сборка из исходников полностью себя оправдывает. тратить деньги за десяток килобайт на сжатый diff файл или тянуть десяток мегабайт кем-то скомпиленного готового ядра? это справедливо для любых "крупных" пакетов, будь то OpenOffice, kernel, E17 :).
ещё один спорный момент: монолит или модульное? на ваше усмотрение, господа присяжные заседатели. с точки зрения "ламера ушастого" - монолит ноне не нужен.
что нам понадобится из "инструментария":
Meld
( пользователи SuSE имеют в "загашнике" JMeld )
и конфиг ядра дистрибутива, работающего в данный момент (стоит ли напомнить, что желательно иметь одинаковую major версию ядра - например 2.6.*?). предположим, что конфиг вкомпилен в ядро и его можно "достать" командой:
zcat /proc/config.gz
что мы и делаем в качестве нашего первого шага:
zcat /proc/config.gz > /home/USER/config_current
распаковываем исходники нового ядра и выполняем:
make menuconfig
затем выбираем опцию: "Load an Alternate Configuration File" -> /home/USER/config_current
тем самым загружая текущую конфигурацию ядра. после сразу же делаем:
"Save an Alternate Configuration File" -> /home/USER/config_new
всё, что нам осталось сделать, это пройтись meld-ом по этим двум файлам (config_current и config_new) и сформировать наш будущий конфиг с учётом всех новых опций, загрузив его уже известным "Load an Alternate Configuration File". если есть сомнения в параметрах новых опций - ставим "=m", видим явно лишнюю опцию - комментируем, ставя в начало строки "#". желаете описание каждой опции в параметрах конфигурации ядра - читайте документацию. основное правило: в ядро - только необходимый минимум, всё, что только можно, - вынести в модули. именно при таком подходе можно получить выигрыш во времени как при старте системы (подгружая только необходимое), так и по использованию памяти самим ядром.
N.B. товарищ, помни: "автоматом" подгрузить модуль можно, но выгрузить - только "вручную" (как вариант - использовать скрипты-"обвязки").
дальнейшие команды по сборке и установке нового ядра (make dep && make clean успели устареть):
make
make modules
sudo make modules_install
sudo make install
необязательные (но иногда крайне полезные) команды, выполняемые после установки (но до перезагрузки). если внимательно смотреть на вывод предыдущих 2-х команд, то в них нужды особой нет (так как именно они и выполняются в процессе), хотя...:
sudo depmod -a
(sudo depmod -aq)
смотрим на вывод команды и проверяем, какие модули будут активированы при загрузке того или иного установленного в системе ядра и собственно проверяем корректность .map файла нового ядра. эта каманда позволит сравнить загружаемые модули вашего старого/(старых) и только что установленного нового кернела. излишне пожалуй говорить, что практически все проблемы разряда "сабрал новае видро а ано нигрузиццо..." могут/должны быть устранены на этой стадии.
в зависимости от системы можно (естественно при желании) пересобрать Initial RAM Disk командами "mkinitrd" или "mkinitcpio" (обратите внимание на /etc/mkinitcpio.conf !!! отсутствие необходимых опций в нём может привести к провалу при загрузке нового кернела) - читайте справку по опциям. приведу для примера свой /etc/mkinitcpio.conf:
MODULES="pata_via sata_via reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata usbinput keymap filesystems"
сие означает, что на чипсете VIA имею IDE и SATA винты, плюс пользую reiserfs. основная же нагрузка падает на HOOKS. для понимания оных - читайте доки и комментарии в самом /etc/mkinitcpio.conf (мне хватило комментариев).
на закуску - несколько интересных статей в продолжение темы:
Ядерная физика для домохозяйки
ещё одна абсолютно чумовая статейка с использованием временных "рэперов" и живым примером перехода от 2.4 до 2.6:
Установка ядра linux-2.6.1 (вместо 2.4.x)
намеренно не затронут вопрос модификации загрузчика (внесения нового ядра в список оного) - ибо пошло и неинтересно.
четверг, 25 октября 2007 г.
Kernel 2.6.23
начитавшись страшилок и пару раз обжёгшись "иду на второй круг"... и сразу же "по полной программе" - ибо к чёрту полумеры:
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
(это значит, что переходим на новый диспетчер управления ресурсами и сажаем "под капот" сразу 1000 лошадей :)). запущены: сборка kernel26 2.6.23.1-4, сборка E17-го, OOo, mpd, mplayer, xmms, ffmpeg потрошит авишку, плюс до кучи демонов и служб. имеем (может не совсем удачно, но общий смысл предельно ясен):
top - 21:54:24 up 1:25, 0 users, load average: 3.06, 2.68, 2.39
Tasks: 120 total, 7 running, 117 sleeping, 0 stopped, 0 zombie
Cpu(s): 73.4%us, 25.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st
Mem: 1035436k total, 984068k used, 51368k free, 73564k buffers
Swap: 2104472k total, 4k used, 2104468k free, 620396k cached
тормозов и заиканий нет.
из приятного - CONNLIMIT таки внесли в исходники (теперь можно не извращаться с глобальным ограничением количества соединений с одного IP-а). на запись правда примонтировать партицию Mac OS X не рискнул (бэкап староват для такого развлечения).
вердикт: must have! что по-русски значит - все на kernel.org за исходниками!
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
(это значит, что переходим на новый диспетчер управления ресурсами и сажаем "под капот" сразу 1000 лошадей :)). запущены: сборка kernel26 2.6.23.1-4, сборка E17-го, OOo, mpd, mplayer, xmms, ffmpeg потрошит авишку, плюс до кучи демонов и служб. имеем (может не совсем удачно, но общий смысл предельно ясен):
top - 21:54:24 up 1:25, 0 users, load average: 3.06, 2.68, 2.39
Tasks: 120 total, 7 running, 117 sleeping, 0 stopped, 0 zombie
Cpu(s): 73.4%us, 25.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st
Mem: 1035436k total, 984068k used, 51368k free, 73564k buffers
Swap: 2104472k total, 4k used, 2104468k free, 620396k cached
тормозов и заиканий нет.
из приятного - CONNLIMIT таки внесли в исходники (теперь можно не извращаться с глобальным ограничением количества соединений с одного IP-а). на запись правда примонтировать партицию Mac OS X не рискнул (бэкап староват для такого развлечения).
вердикт: must have! что по-русски значит - все на kernel.org за исходниками!
Заметки (перенесено с rootshell.be)
Поскольку любимый мной rootshell.be закрыли/перенесли с потерей учётной записи - потихоньку буду выкладывать здесь наиболее интересный материал...
Пару слов об этом замечательном WM-е. Основные грабли - русификация (что характерно). Разберём на примере темы "winter". На самом деле это довольно интимное занятие и оно различается от темы к теме для e16. Моя версия - 0.16.8.7-0.00 из cvs. Как я его собирал - скриптик дан вверху странички, пользуйтесь. Для этой темы надо в 'путь_к_установленному_Вами_e16/share/e16/themes/winter/ttfonts' положить допустим шрифт verdana.ttf и verdanab.ttf (любые шрифты поддерживающие Вашу locale. Dejavu тоже подойдёт (даже лучше будет), но под рукой нету) в дополнение к уже присутствующим (надеюсь) Vera.ttf и VeraBd.ttf и выполнить (от рута)
mkfontscale && mkfontdir
стоя в 'путь_к_установленному_Вами_e16/share/e16/themes/winter/ttfonts'
Затем идём в ~/.e16/cached/cfg и открываем файлик
.*.share.e16.themes.winter.fonts.cfg.preparsed
вместо * у Вас будет что-то написано ессно. Это делается для проверки, дабы избежать внесения изменений в
'путь_к_установленному_Вами_e16/share/e16/themes/winter/fonts.cfg'
и избежать операции "purge cache all". Приводим этот файлик (это - аналог нашего fonts.cfg) вот в такой вид:
1001 1
21 999
font-default "verdanab/7"
font-border "verdanab/7"
font-coords "verdanab/7"
font-dialog "verdana/7"
font-dialog-hilite "verdana/8"
font-epplet "verdana/6"
font-epplet-small "verdana/6"
font-epplet-medium "verdana/8"
font-epplet-large "verdana/10"
font-focus "verdanab/7"
font-iconbox "verdanab/7"
font-init "verdanab/8"
font-menu "verdana/7"
font-pager "verdanab/7"
font-tooltip "verdanab/7"
1000
Всё. Restart. Если заголовки окон в норме - рихтуйте
'путь_к_установленному_Вами_e16/share/e16/themes/winter/fonts.cfg'
и purge cashe all
Самое важное здесь - ставить именно те шрифты, которые поддерживают Вашу locale. Для темы же 'aqua' всё немного по-другому (определение шрифтов разнесено по нескольким конфигурационным файлам), посему - ищите да обрящете...
Тут есть ещё такой "ньюанс" - вполне возможно/вероятно, что для версии 0.16.8.1 данный способ не подойдёт. Посему - upgrade пожалуйста...
После длительного перерыва решил продолжить, ибо тема E16 не раскрыта совершенно. Полагаю, что это - лучший WM на сегодня, да и на ближайшее обозримое будущее тоже. Количество тем офрмления для него просто огромно (с версии E 16.8.10 темы требуют доработки):
http://themes.freshmeat.net/browse/60/
Вот что установлено у меня в ~/.e16/themes и на скриншоте - самая верхняя, 23OZ, с которой пришлось чуток повозиться путём рихтовки всех конфигурационных файлов, содержащих инструкции по использованию отсутствующего у меня шрифта/семейства шрифтов "helvetica". Кроме того на скриншоте "gkrellm" с темой "23ozglass" и индикатором писем из темы "CoplandOS". В отличие от "стандартной" темы "winter" в "23OZ" (как и в большинстве старых тем) внимания требуют практически все конфигурационные файлы, ибо стандарта по созданию тем как такового нет до сих пор. Кроме того добавил теме своё собственное звуковое оформление. Для этого достаточно разобраться с файлом ~/.e16/themes/23OZ/sound.cfg (если тема установлена в ~/.e16/themes).
Но основное внимание стоит уделить файлу "~/.e16/bindings.cfg". Он имеет 3 секции:
Aclass BUTTONBINDINGS normal
Aclass DESKBINDINGS normal
Aclass KEYBINDINGS global
соответственно первая в ответе за отклик окон на различные комбинации "щёлканья" мышкой (и опционально - с клавиатурой), вторая - за "кликанье" мышкой (опять же +- клавиатура) на рабочем столе и последняя даёт волю в выборе "горячих" клавиш. Ограничений - практически никаких. Есть утилита для установки некоторых функций "горячих" клавиш в gui - "e16keyedit". Изменения попадут в секцию "Aclass KEYBINDINGS global". Желающие "огласить весь список" могут набрать в консоли:
eesh help full
и очень рекомендуется к прочтению следующий документ:
README
Если мы к примеру добавим в конец файла "~/.e16/bindings.cfg" следующую строку:
KeyDown - F1 menus show windowlist
то по нажатию кнопки "F1" вылетит окно со списком всех запущенных приложений. Понятно, что для "подгонки" приложений под выбранную/созданную тему придётся всё равно "ковырять" настройки gtk/qt, но это уже совсем другая "песня". Ещё пожалуй стоит упомянуть утилиту "e16menuedit2", которая для E-0.16.8 и выше позволяет "визуально" редактировать списки меню с перечнем доступных приложений. Если есть желание расположить на рабочем столе "иконки" для запуска документов или приложений - смотрите в сторону программы idesk. Enlightenment был и остаётся самым красивым и функциональным WM в истории *nix.
ENLIGHTENMENT (E16)
Пару слов об этом замечательном WM-е. Основные грабли - русификация (что характерно). Разберём на примере темы "winter". На самом деле это довольно интимное занятие и оно различается от темы к теме для e16. Моя версия - 0.16.8.7-0.00 из cvs. Как я его собирал - скриптик дан вверху странички, пользуйтесь. Для этой темы надо в 'путь_к_установленному_Вами_e16/share/e16/themes/winter/ttfonts' положить допустим шрифт verdana.ttf и verdanab.ttf (любые шрифты поддерживающие Вашу locale. Dejavu тоже подойдёт (даже лучше будет), но под рукой нету) в дополнение к уже присутствующим (надеюсь) Vera.ttf и VeraBd.ttf и выполнить (от рута)
mkfontscale && mkfontdir
стоя в 'путь_к_установленному_Вами_e16/share/e16/themes/winter/ttfonts'
Затем идём в ~/.e16/cached/cfg и открываем файлик
.*.share.e16.themes.winter.fonts.cfg.preparsed
вместо * у Вас будет что-то написано ессно. Это делается для проверки, дабы избежать внесения изменений в
'путь_к_установленному_Вами_e16/share/e16/themes/winter/fonts.cfg'
и избежать операции "purge cache all". Приводим этот файлик (это - аналог нашего fonts.cfg) вот в такой вид:
1001 1
21 999
font-default "verdanab/7"
font-border "verdanab/7"
font-coords "verdanab/7"
font-dialog "verdana/7"
font-dialog-hilite "verdana/8"
font-epplet "verdana/6"
font-epplet-small "verdana/6"
font-epplet-medium "verdana/8"
font-epplet-large "verdana/10"
font-focus "verdanab/7"
font-iconbox "verdanab/7"
font-init "verdanab/8"
font-menu "verdana/7"
font-pager "verdanab/7"
font-tooltip "verdanab/7"
1000
Всё. Restart. Если заголовки окон в норме - рихтуйте
'путь_к_установленному_Вами_e16/share/e16/themes/winter/fonts.cfg'
и purge cashe all
Самое важное здесь - ставить именно те шрифты, которые поддерживают Вашу locale. Для темы же 'aqua' всё немного по-другому (определение шрифтов разнесено по нескольким конфигурационным файлам), посему - ищите да обрящете...
Тут есть ещё такой "ньюанс" - вполне возможно/вероятно, что для версии 0.16.8.1 данный способ не подойдёт. Посему - upgrade пожалуйста...
Доводим до ума E16...
После длительного перерыва решил продолжить, ибо тема E16 не раскрыта совершенно. Полагаю, что это - лучший WM на сегодня, да и на ближайшее обозримое будущее тоже. Количество тем офрмления для него просто огромно (с версии E 16.8.10 темы требуют доработки):
http://themes.freshmeat.net/browse/60/
Вот что установлено у меня в ~/.e16/themes и на скриншоте - самая верхняя, 23OZ, с которой пришлось чуток повозиться путём рихтовки всех конфигурационных файлов, содержащих инструкции по использованию отсутствующего у меня шрифта/семейства шрифтов "helvetica". Кроме того на скриншоте "gkrellm" с темой "23ozglass" и индикатором писем из темы "CoplandOS". В отличие от "стандартной" темы "winter" в "23OZ" (как и в большинстве старых тем) внимания требуют практически все конфигурационные файлы, ибо стандарта по созданию тем как такового нет до сих пор. Кроме того добавил теме своё собственное звуковое оформление. Для этого достаточно разобраться с файлом ~/.e16/themes/23OZ/sound.cfg (если тема установлена в ~/.e16/themes).
Но основное внимание стоит уделить файлу "~/.e16/bindings.cfg". Он имеет 3 секции:
Aclass BUTTONBINDINGS normal
Aclass DESKBINDINGS normal
Aclass KEYBINDINGS global
соответственно первая в ответе за отклик окон на различные комбинации "щёлканья" мышкой (и опционально - с клавиатурой), вторая - за "кликанье" мышкой (опять же +- клавиатура) на рабочем столе и последняя даёт волю в выборе "горячих" клавиш. Ограничений - практически никаких. Есть утилита для установки некоторых функций "горячих" клавиш в gui - "e16keyedit". Изменения попадут в секцию "Aclass KEYBINDINGS global". Желающие "огласить весь список" могут набрать в консоли:
eesh help full
и очень рекомендуется к прочтению следующий документ:
README
Если мы к примеру добавим в конец файла "~/.e16/bindings.cfg" следующую строку:
KeyDown - F1 menus show windowlist
то по нажатию кнопки "F1" вылетит окно со списком всех запущенных приложений. Понятно, что для "подгонки" приложений под выбранную/созданную тему придётся всё равно "ковырять" настройки gtk/qt, но это уже совсем другая "песня". Ещё пожалуй стоит упомянуть утилиту "e16menuedit2", которая для E-0.16.8 и выше позволяет "визуально" редактировать списки меню с перечнем доступных приложений. Если есть желание расположить на рабочем столе "иконки" для запуска документов или приложений - смотрите в сторону программы idesk. Enlightenment был и остаётся самым красивым и функциональным WM в истории *nix.
Подписаться на:
Сообщения (Atom)
