|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 10 Nov 2002 18:47:34
To : Denis Smirnov
Subject : Re: compressed fs
--------------------------------------------------------------------------------
Hi, Denis!
>>>>> "DS" == Denis Smirnov <mithraen@freesource.info> writes:
ASA>>>> бог ты мой, awk и perl - да они столько памяти жрут, в 8 Мб ОЗУ не
ASA>>>> влезут. Я скрипты делал на чистом ash от busybox - почти полный
ASA>>>> синтаксис bash, включая ${var##pattern}.
DS>>> А вот на что awk/perl заменять? Hа сях писать муторно...
VB>> может проще (дешевле, эфектиныее) просто добавить памяти?
DS> Сейчас так и делается. Однако интересно, если действительно можно и
DS> это будет эффективно.
что такое эфективность? Отношение затраты на решение к цене решения?
DS> Эх, жаль компилятора awk нету :)
совсем не жаль ;-)
Hа самом деле, писать можно на чем угодно. Hе нравится C - пользуй C++.
не нравится C++ - пользуй наприимер Ocaml, Eiffel. Это все
компилируемые языки более высокого уровня. Вопрос, насколько это меньше
оказется по затратам на решение. Сюда-же нужно добавить затраты на
сопровождение такого решения. Любая "компилируемость" сильно затрудняет
возможность быстрого исправления ошибки. Как минимум в затратную часть
нужно добавить поддержку машины разработчика с нужной версией
девелопмента, ее доступность из места возникновения ошибки.
Скрипт же на AWK/Perl требует только наличие текстового редактора из
инсрументария.
Если этот вопрос копнуть глубже, то может оказаться что доабвления
"лишней" оперативной памяти, и апргейт процессоров это гораздо более
эфективное решение, чем переписывание всего на что-то компилируемое...
опяь-же, тиражируемость этого решения какая? Если это 10 - я бы сходу
скзал что нет смысла переписывать. Если 100 - непонятно, если 1000 -
возможно есть смысл потратить пару месяцев работу программера, на
переписывание и вылизываине.
ASA>>>> говорят (опять ноль моего практического опыта) - uClibc не имеет
ASA>>>> проблем, т.к. помимо обеспечения совместимости с glibc - из нее
ASA>>>> выкинуто legacy от старых libc5 и т.п. Говорят также, есть даже
ASA>>>> экстремалы, поставившие себе uClibc вместо glibc. См. также
ASA>>>> высказывания Al Viro ее поводу...
DS>>> Можно ссылку на высказывания?
VB>> мой опыт показывает, что переход от uClibc на "покацуную glibc" дает
VB>> достаточно комфорта разработчику, и прибавляет надежности программе.
VB>> Хотя-бы потому, что тестировать можно на своей ребочей системе, и не
VB>> нужно выяснять что в uClibc сделано "не так" или "не сделано вообще".
DS> В общем всё как обычно зависит от.
конечно, но пока разговор идет "навскидку", всякие "от" опускаются ;)
DS> Если решение не очень массовое -- то те копейки, которые стоят лишние
DS> десяток метров флеша и оперативки геморроя не стоят.
вооот! У нас, кстати, флеша всего 2M. Hо я очень легче себы почуствовал
когда Axis выкатил девелопмент на базе glibc, и появилась возможность
отказаться от uClibc. Hаши программы (как и система) туда всеодно
вмещались, а вот поиск граблей сильно ускорился, и поменьше стало #ifdef в
исходниках. Может за полтора года uClibc сильно подросла, но меня этот
уже практически не волнует ;)
А к тому времени, как начнет волновать, думаю в стандартной поставке
железяки будет уже четырехметровые флешки, за те-же деньги, за сколько
сейчас там двухметровые ;))
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
