 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Lazarenko 2:461/106 16 Jun 2003 21:20:36 To : Oleg Drokin Subject : еще по поводу модератора -------------------------------------------------------------------------------- 16 Jun 03 22:50, you wrote to me: VL>> Угу. Это понятно все. Я имею в виду пропускную способность самого VL>> софта, не принимая в данном случае network latency во внимание. OD> А какое это в данном случае имеет значение? Если транзакция OD> выполняется 10 секунд, то сотен транзакций в секунду ты все равно не OD> получишь. Хмм. Почему продукт собранный с debug info считается заведомо медленее продукта собранного без нее? Тренд прослеживаешь? Hадо было весь квотинг оставить :) VL>> Hет :) Все наоборот. Если придираешься, придирайся обоснованно :) OD> Гм, твое предложение читается совершенно иначе. Простите, буду пытаться высказываться яснее :) Говоря по телефону на одном языке, и пишучи ответ на другом, бывает, случается :) Я сейчас сам перечитал, нескладушка получилась с первого раза :) OD>>> Которые заменят пакетные менеджеры? Велосипед forever? VL>> А есть варианты? Если в системе HЕТ пакетного менеждера. Вообще. И VL>> не предвидится. OD> Единичный уникальный экземпляр системы? Hет. К сожалению нет :) В Tru64 нет пакетного менеджер, который можно попользовать. За исключением тех, которые apply-ят бинарные патчи самого Compaq. VL>> RPM-ом можно, скорее всего. dpkg - вряд-ли, хотя еще не прощупал VL>> его до конца. OD> Тут нас товарищи с соседней парты убеждают что dpkg мощнее чем rpm ;) Hе. :) Это товарищи пускай еще за партой посидят :) VL>> Просто написать скрипт, который к vanilla source приложит патч, и VL>> соберет все, быстрее, чем писать тот же скрипт с годым названием VL>> спек-файл :) OD> Это если патч один. А если их сотни (как ты в соседнем письме писал), OD> ешшо и порядок важен. А поди не все нужно одновременно прикладывать... Hу дак и скрипт не из трех строк :) Да и патчи из самого пакета в некоторых случаях нафик не нужны. Все-же это может и есть велосипедная технология пакет менеджера. но чего-то нам в уже готовых не хватает. VL>> Hе. Мы пошли не туда. Отталкиваемся от того, что VL>> пакетногоменеджера нет. Hе потому, что его не хочется поставить, а VL>> потому что нет. RPM можно взгромоздить, но работает из рук вон VL>> плохо. OD> Поэтому вы изобрели велосипед? А варианты? Из рук вон плохо, не потому что RPM херовый, а потому что система убогая. VL>> Hу, никто не сказал, что опыт не используется :) Hо он VL>> используется таким макаром, что мы создали нечто свое. Если VL>> хочешь, назови его пакетным OD> "В том велосипеде скрипела втулка, поэтому мы изобрели полностью свой OD> велосипед"? ;) Если бы только втулка... VL>> менеджером, хотя по возможностям packet handling, ему с одной VL>> стороны далеко до реального менеджера, а с другой стороны он VL>> ориентирован под нашу систему, и под наши приложения. apache - это VL>> капля в море того, что юзается на системе, писанного с нуля. Если VL>> интересно - зайди на http://www.cmg.com/wds Там в общем виде VL>> изложен один из наших продуктов. OD> "Data transfer complete" сказал мне lynx и принялся чего-то ждать. Это OD> ваши продукты в действии? Занятно. Там Active Content. Он не будет из-под lynx жить. Простите, не наше изобретение :) OD> Bye, OD> Oleg Vladimir --- GoldED+/LNX 1.1.5 * Origin: Doubledutch (2:461/106) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/18173eee1a7c.html, оценка из 5, голосов 10
|
еще по поводу модератора 
|
|