Евгений Любимкин, ранее участвовавший в разработке APT, представил (http://lists.debian.org/debian-devel-announce/2009/09/msg000...) в списке рассылки разработчиков Debian GNU/Linux бета версию первого релиза написанной на языке Perl системы управления пакетами Cupt 1.0 (http://wiki.debian.org/Cupt), продолжающей развитие APT. Работа над Cupt была начата зимой 2008 года с целью создания переработанного варианта APT, устраняющего проблемы, связанные с архитектурой и реализацией. В настоящее время cupt интегрирован в "unstable" ветку Debian. Проект еще далек до использования в качестве полной замены APT, но может использоваться совместно с такими утилитами как apt-get, apt-cache и aptitude, так как он базируется на стандартных для APT индексах, кэшах и файлах конфигурации.
Реализованные в Cupt возможности:
- Полнофункциональная строгая система разрешения проблем с зависимостями;
- APT-подобная утилита для работы из командной строки;
- Возможность регистро-независимого п...URL: http://lists.debian.org/debian-devel-announce/2009/09/msg000...
Новость: http://www.opennet.me/opennews/art.shtml?num=23577
Перл???
Он самый. Что замечательно (от слова "замечать"), в OpenBSD поступили в своё время аналогично: унаследованные от фряшной системы портов утилиты pkg_* были переписаны (и впоследствии значительно доработаны) на Perl. На скорость никто не жалуется. Perl, кстати, вообще довольно быстрый, когда дело касается ввода-вывода: у меня получалось терять не более 25% производительности на задачах типа "скопировать вон ту кучу файлов, сжимая по дороге через gzip".
for infile in *.pl; do gzip -9 -c $infile > /path_to_pomoika/$infile.gz; doneА уж при чём "скорость" перла в такой задаче ... он ну очень быстро передаёт имя файла в cp, gzip и иже с ними? Угадал? А кто медленно? В общем - смотри пп 1.
>
>for infile in *.pl; do gzip -9 -c $infile > /path_to_pomoika/$infile.gz; done
>
>А уж при чём "скорость" перла в такой задаче ... он ну
>очень быстро передаёт имя файла в cp, gzip и иже с
>ними? Угадал? А кто медленно? В общем - смотри пп 1.Не-не-не. Речь в моём случае о том, что Perl через pipe передаёт данные gzip'у, оттуда они попадают в SSH и далее в сеть. То есть цепочка:
диск => perl => gzip => ssh => сеть => ssh => perl => диск
Производительность мерялась на учатке "диск => perl => gzip" по сравнению с аналогичной реализацией на C (смею уверить, не безграмотнее версии на Perl).
При наличии смекалки это решается через pipe и ssh -cДругой вопрос, что если нужно реально независимое от платформы решения (даже для оффтопика), то тогда perl надежда и опора администратора.
>При наличии смекалки это решается через pipe и ssh -cА я и не говорил, что задача была только в передаче файлов. :) Там бизнес-логики тоже хватает. По сути, задача была в написании бэкапной системы. Решения рассматривались разные, от bacula до собственной реализации на C. По различным причинам, в которые вдаваться долго, лень и нет смысла, было выбрано написание своей системы на Perl.
>Другой вопрос, что если нужно реально независимое от платформы решения (даже для
>оффтопика), то тогда perl надежда и опора администратора.И это тоже верно.
Вообще-то тестовые варианты rpm тоже были сначала на перле написаны. И уже потом, после отработки функциональности оно было переписано на C.
Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге мало того что он тормозной что пипец, так еще и жирные пакеты с кучей зависимостей на low resource машинах (128 мегов RAM, etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну памяти видите ли не хватает - во новости! Да, блин, теперь 128 мегов (без иксов и с почти нифига в системе, где полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут городить тормозных прожорливых монстров на перле?
>Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге
>мало того что он тормозной что пипец, так еще и жирные
>пакеты с кучей зависимостей на low resource машинах (128 мегов RAM,
>etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну
>памяти видите ли не хватает - во новости! Да, блин, теперь
>128 мегов (без иксов и с почти нифига в системе, где
>полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут
>городить тормозных прожорливых монстров на перле?Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на сях написать такое гуано, что будет охренительно тормозить. Прежде всего — алгоритмы: код на Python с O(n) будет лучше кода на C с O(n!) на хоть сколько-то заметном количестве обрабатываемых объектов. Ну а на небольшом количестве (в случае с пакетным менеджером) вообще пофиг: вы заметите в его случае разницу между 0,1 с и 0,001 с? ;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает меньше багов. Вы предпочитаете программы, которые делают 1000 операций в секунду, на которые будет возникать в среднем пять ошибок, или 500, но всего с одной?
>Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на
>сях написать такое гуано, что будет охренительно тормозить.Да, но при *равных* условиях (один и тот же алгоритм реализованный не слишком криворуким програмером) жрать ресурсов сишная байда будет в разы меньше.И тормозить - тоже. А то что тормозную дрянь можно написать даже на асме никто и не сомневался, хоть и придется больше стараться для этого :)
>Прежде всего — алгоритмы: код на Python с O(n) будет лучше кода на C
>с O(n!) на хоть сколько-то заметном количестве обрабатываемых объектов.А еще дважды два равно четыре. Вот только если код с O(n) переписать на сях, он питона порвет с таааааким отрывом, что народ будет выпавшие челюсти выгребать из-под стола.
>Ну а на небольшом количестве (в случае с пакетным менеджером) вообще пофиг:
>вы заметите в его случае разницу между 0,1 с и 0,001 с?Я замечаю когда yum тупит на виртуалках чтопиндец и нарывается на идиотский аут памяти тогда как apt в тех же условиях и не тупит и памяти ему хватает. Вполне заметная такая на глаз разница. Ога?
>;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней
>логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает
>меньше багов.Знаете, я пока на баги в дебианской пакетной системе не жаловался. За несколько лет юзания я умудрялся поставить пакетный манагер в позу всего три раза. И все три достаточно легко вышибал его обратно в работоспособное состояние. Так что шли б теоретики с их теоретическими преимуществами и тормозными ресурсожоркими скриптоподелиями заодно?
>Вы предпочитаете программы, которые делают 1000 операций в секунду,
>на которые будет возникать в среднем пять ошибок, или 500, но
>всего с одной?Я что-то не заметил 500 ошибок в текущем пакетном манагере. Даже если они там есть - реальным операциям они не мешают особо. Пользоваться ради каких-то чисто теоретических плюсов более тормозной и ресурсожоркой байдой меня не прет, извините. А вот разработанный по рапидному принципу (то бишь "на отвали") пакетный манагер - это, гм, финиш.
>>Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на
>>сях написать такое гуано, что будет охренительно тормозить.
>
>Да, но при *равных* условиях (один и тот же алгоритм реализованный не
>слишком криворуким програмером) жрать ресурсов сишная байда будет в разы меньше.И
>тормозить - тоже. А то что тормозную дрянь можно написать даже
>на асме никто и не сомневался, хоть и придется больше стараться
>для этого :)Напишете? На сях? Чисто для сравнения? ;)
>>;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней
>>логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает
>>меньше багов.
>
>Знаете, я пока на баги в дебианской пакетной системе не жаловался. За
>несколько лет юзания я умудрялся поставить пакетный манагер в позу всего
>три раза. И все три достаточно легко вышибал его обратно в
>работоспособное состояние. Так что шли б теоретики с их теоретическими преимуществами
>и тормозными ресурсожоркими скриптоподелиями заодно?"Теоретик", если вы посмотрите внимательно, долго занимался поддержкой и разработкой этой самой apt. Так что кто ещё из вас теоретик...
>>Вы предпочитаете программы, которые делают 1000 операций в секунду,
>>на которые будет возникать в среднем пять ошибок, или 500, но
>>всего с одной?
>
>Я что-то не заметил 500 ошибок в текущем пакетном манагере. Даже если
>они там есть - реальным операциям они не мешают особо. Пользоваться
>ради каких-то чисто теоретических плюсов более тормозной и ресурсожоркой байдой меня
>не прет, извините. А вот разработанный по рапидному принципу (то бишь
>"на отвали") пакетный манагер - это, гм, финиш.Плюсы вам обозначили вполне конкретные. Про "на отвали" - чисто ваши домыслы, означающие изначальное недоверие к человеку, который для конкретной выбирает Perl вместо C только потому, что он этот выбор делает. Вас никто не заставляет сейчас пользоваться новым пакетным менеджером.
И если ещё раз затрагивать тему тормозов: чтобы реализовать многие полезные возможности Perl в рамках программы на C уходят человеко-часы разработки — вы, видимо, совсем не уважаете open source разработчиков, если не цените их время. Более того, скажем, те же хэши в Perl тщательно оптимизированы, в силу обширного их использования. Достигнуть такого же уровня на голом C можно, но нужно ли? Усилится тормознутость системы (за счёт дополнительного оверхеда), уменьшится надёжность (пока код не будет вылизан)…
Более того, повторюсь, использование Perl позволяет заметно легче разрабатывать, внедрять, отлаживать и рефакторить бизнес-логику. Что означает, в том числе, и повышение производительности. Пока в Вилла-Риба одни реализуют супер-мега-концепт, а другие сосут лапу и терпят тормоза и отсутствие функционала в ожидании, в Вилла-Баджио уже давно всё установилось и работает. ;)
А в виртуалке (окромя паравиртуальной среды) всё всегда будет тормозить по определению. ;) Если вы пользуетесь виртуализацией, стремясь к производительности, то поступаете ничуть не лучше человека, который делает сайты на голом статическом HTML, стараясь сделать их удобными и функциональными.
>Напишете? На сях? Чисто для сравнения? ;)Да, умничать все сильны. А почему бы не задать этот вопрос разработчикам вон той поделки?Ну или спросить у них - куда они там так торопятся в создании системного компонента который делается раз и на чуть ли не десятки лет?Им настолько впадлу его делать?Или в чем прикол?Я еще могу понять когда так рассуждает какой-то жабист пишущий ява-крап для бизнесменов, но вот для манагера пакетов, системного компонента который делается раз и на вагон времени - это за пределами моего понимания.
>"Теоретик", если вы посмотрите внимательно, долго занимался поддержкой
>и разработкой этой самой apt. Так что кто ещё из вас теоретик...Отлично, тогда пусть он расскажет - куда он там так торопится, что ему приспичило системный инструмент ваять на перле?И зачем в дебиане нечто, сделанное на уровне бизнес-поделий?Манагер пакетов - это такая кондовая штука которая делается на века.И собственно apt - вполне нормальный на мое имхо.Если уж делать - так наверное что-то лучше, а?И человек не подумал что например дебияновские средства используются много где?В частности в эмбеддед там, на машинках типа нокий nXX0, на виртуалках, когда могучий сервант попилен на вагон маломощный контейнеров, ...? И уж конечно когда куцему арму с парой сотен мегагерц и 128 мегов оперативы (в которых втискиваются иксы и вообще по сути полноценный дебиан) еще и подпихнут тормозной интерпретер который до кучи вагон памяти выжрет, настанет всеобщий супер-рулез, ага :\.Грубо говоря - это называется так: програмера колебет только как бы ему побыстрее и попроще написать вон ту хрень. Так с таким подходом надо бизнес-приложения писать, а не манагеры пакетов. ИМХО. Там то на крутые сервера крутые дядьки денег как-нить наскребут.
>Плюсы вам обозначили вполне конкретные. Про "на отвали" - чисто ваши домыслы,
>означающие изначальное недоверие к человеку, который для конкретной выбирает Perl вместо
>C только потому, что он этот выбор делает.Разумеется - сразу видно что человек настроен сделать задачу как можно быстрее а на качество и что там потом случится с юзерами всего этого (ну и как следствие с дистрибом вообще) ему ... наплевать? Как плевать и на то что не везде где встречается дебиан - четырехъядерник с избытком оперативы? Может быть и арм в полторы комариных силы и мизером свободной RAM. И вот только перла то там и не хватало, ага. Чтобы юзеры застрелились глядя на то как это работает?
> Вас никто не заставляет сейчас пользоваться новым пакетным менеджером.
И слава богу. Но вот есть опасность что эту поделку засунут потом по дефолту а у остальных будет головняк - что ж делать с дебияном на low resource машинах? И потом всяким хостерам, нокиям и прочим придется усиленно велосипедить. Вот только этого то и не хватало, бэть. Чтобы потом в дебиане стал разнобой с пакетными манагерами как в редхатовской байде, ага.
>И если ещё раз затрагивать тему тормозов: чтобы реализовать многие полезные возможности
>Perl в рамках программы на C уходят человеко-часы разработки — вы, видимо,
>совсем не уважаете open source разработчиков, если не цените их время.Я уважаю тех кто делает свою работу качественно. А рапидные принципы - это айда бизнес-логику лабать, там таких ждут с распростертыми объятиями. С их скриптоподелками - бизнесмены если что народ богатый, если старый сервак что не тянет - они новый купят, даже несколько. И на чем написано им похрену - хоть на брейнфаке, это им вообще не интересно. Если надо будет поставить крутой сервак - они пойдут и поставят. Накукуй надо по этому принципу лабать манагер пакетов я не понимаю - это ж не бизнес приложение а кондовая штука, которая если удачно сделать будет лет 10 в ходу пожалуй. На вагоне разных платформ. С весьма разными ресурсами. И время не жмет, ибо текущий манагер пакетов всех устраивает в основном - можно сделать все аккуратно, цивильно и не спеша, а не как факинг рапидчики. И вот неспешность может в частности обеспечить и отсутствие багов. Ну не бывает быстро написанный софт без багов. Не видел я его. Посему ваши сказки про то что быстрое написание софта означает отсутствие багов оставьте для детей.
>Более того, скажем, те же хэши в Perl тщательно оптимизированы,
Я боюсь что там зато не оптимизировано дохрена другого. Поэтому в сумме есть риск что я застрелюсь пока на N??? с ее хилым армом и мизером опертивы установится разлапистый пакет. А глядя на то сколько оперативы жрет тривиальная байда писаная на перле ... ну не знаю, как-то мне не по себе и в сказки про его чудесный перфоманс и скромное поедание ресурсов верится с трудом. А дебиан работает нынче много где. Включая и мелкие виртуалки и эмбеддед железки. Кто этого не замечает пристроив попу в тепле и комфорте за своим четырехъядерником с вагоном оперативки где все чудесненько пашет и на перле и на чем там еще - ну я его поздравляю. Зато вот с редхатовской байдой yum на питоне я уже вкусил, спасибо. И как-то совсем не хочется чтобы такое же говно случалось с дебияном.
>в силу обширного их использования. Достигнуть такого же уровня на голом
>C можно, но нужно ли? Усилится тормознутость системы (за счёт дополнительного
>оверхеда), уменьшится надёжность (пока код не будет вылизан)…Дополнительный оверхед на сях vs перл - это достаточно оригинальная мысль.А, гм, какой-то пруф этой мысли предполагается? Или почему предполагается что на перле напишет кто-то пряморукий а на сях - всенепременно жопорукий и безмозглый? Как по мне так обычно картина ровно обратная (это не наезд и не подкол а просто наблюдение, уж простите если оно кого-то задевает за живое).
>Более того, повторюсь, использование Perl позволяет заметно легче разрабатывать,
Вот это - факт. Да. Только вот это единственный плюс. А вот остальное зато - минусы.
> внедрять,
А вот это уже совсем не факт, особенно на low-resource платформах и т.п..И дебиан - это не ваша любимая бздя которая есть только на серверах, у которых ресурсов сроду как грязи и уж конечно на таком железе хрен потормозишь(да, там дури столько что это еще и стараться надо). Дебиян встречается много где. И ресурсов там не везде дофига.
>отлаживать
Да вот что-то по жизни рапидные поделки - самые глючные.Так, нескромное тестерское наблюдение.Собственно скорость написания на скорость доведения до ума влияет мало.Напротив, появляется соблазн наворотить много всего. В итоге ... оказывается что глюков столько что только и остается что...
>и рефакторить
...да, только и остается что заниматься онани^W рефакторингом, ибо то что получилось с первого раза - настолько ж%$&, что проще зачастую плюнуть и переписать заново. Как знакомо. В итоге просирается масса времени, на выходе удивительно паршивый результат. Но зато в деле новомодные скриптотехнологии и кульные концепции. Проблема только одна - обычно по этому принципу пишут не пакетные манагеры а бизнес-крап, который должен кой-как ползать, можно с глюками и полудохло, но самое главное - чтобы еще вчера.Ну, накрайняк, сегодня.Но никак не позже. У бизнесхренов время - деньги, ждать они не могут, поэтому вынуждены довольствоваться тем что дали и при нужде расширять и обновлять парк железа. И то вон микрософт с их дотнетом в итоге с позором послали нафиг заменив их байду на дотнете и винды на сиплюсплюсную приблуду и линухи. Это что, бизнес-крап теперь качественнее манагеров пакетов будет?! Во дожили, а?
> бизнес-логику.
Кхм. Бизнес-логика в замене апта - это что, отжиг сезона? Шутка? Или такой техничный и утонченный стеб? oO
> Что означает, в том числе, и повышение производительности.
Сказки это хорошо.Для детей, ага.
>Пока в Вилла-Риба одни реализуют супер-мега-концепт, а другие сосут лапу и терпят
>тормоза и отсутствие функционала в ожидании, в Вилла-Баджио уже давно всё
>установилось и работает. ;)Ага, посмотрим как оно у вас установится на задохлике с парой сотен мегагерц и 128 мег оперативы где еще и иксы и гуй живут. Вот как скажет система "ой память кончилась" и OOM killer ухайдакает полсистемы - так сразу все и установится, ага.
>А в виртуалке (окромя паравиртуальной среды) всё всегда будет тормозить по определению.
Скажите, это каким же ретардом и ретроградом надо быть чтобы в конце 2009 года пользоваться полной виртуализацией без какого либо ускорения?Это за гранью моего понимания.Наверное, для вас виртуализация - это нечто такое, на подрочить.А для меня - это повседневная реальность в боевых окружениях.И вы знаете, не больно то оно и тормозит. С нормальными системами и нормальными виртуализаторами (да, не полными) - не так уж далеко от перфоманса голой железки. А уж контейнеры типа опенвзы и вовсе от просто железки отличить по скорости - только с лупой. А вот когда толстый сервак пилится на вагон контейнеров - в пересчете на контейнер ресурсов не так уж и много. Ну да, вам наверное это не понять - вы поди виртуализацию только на картинках видели или до сих пор сидите в каком-нить тормозилове типа qemu чисто для развлечения.
>;) Если вы пользуетесь виртуализацией, стремясь к производительности,Да, поклонники опенбсд и в 2009 году просасывают, кто б сомневался. Да, для вас виртуализация до сих пор что-то типа этакого полета на луну, видимо. А для меня - это как две остановки на автобусе - повседневно, обычно, практично и работает.И скорость нормальная в общем то.Такая вот "небольшая разница".
>то поступаете ничуть не лучше человека, который делает сайты на голом статическом
>HTML, стараясь сделать их удобными и функциональными.Знаете, когда нагруженные сайты жизня прижимает - они доходят и до отдачи "ну почти совсем статики". То есть по возможности как раз все кешится и отдается как статика а перегенеряется - по мере надобности. В идеале как раз тяжелую работу большую часть времени рюхает простой и легкий сервант на сях, которому припершаяся сию секунды тыща юзвергов - как 2 пальца об асфальт. А то если на каждого дятла монстрильный интерпретер дергать - тогда на ферму серверов разориться можно. Разумеется, некоторые так и делают, у кого денег вагон. А некоторые делают иначе, т.к. если немного поизгаляться, можно прилично сэкономить на тех же серверах и их содержании. А зачем 1000 раз в секунду генерить страницу, если 999 дятлов ее посмотрело и закрыло и только 1 через минуту откоментит?Ну вот через минуту и сгенерить ее заново, фигле.Понятно что в лобешник - проще.Вот только фермы серверов - они, заразы, дорогие.
p.s. извиняюсь за несколько злой пост, для програмеров советую рассматривать это как всего лишь взгляд тестера на программы. Тогда будет понятно чего я злой.
(сорри, цитировать не буду, т.к. иначе получится ещё запутаннее)Менеджер пакетов — такой же софт, как и всё остальное. Периодически появляется необходимость что-то дорабатывать, переделывать.
Изначальный вопрос («на хрена?») был за вами, что ж вы его по-прежнему мне задаёте, а не разработчику? Он не скрывается, контакты доступны, даже, кажется, в этом обсуждении участвовал (Андрей). Боитесь ответа? :)
И почему вы вообще решили, что скорость разработки обязательно будет ухудшать качество? Я уже приводил пример, когда переход с C на Perl в аналогичной ситуации привёл к многочисленным улучшениям, в том числе — в скорости работы самих программ. Да, если взять несколько грамотных C-программистов, то можно добиться небольшого ускорения работы — не забывайте, что основное время при управлении пакетами уходит на ввод-вывод, да ещё, в случае с интерактивными оболочками, на ожидание ввода пользователя. Но честно скажите, оно того стоит? Или вы всегда напряжённо медитируете на бегущие проценты? :) Я лично просто переключаюсь на другую задачу. А если я не могу переключиться на что-то другое, значит, я плохо планирую своё время.
Вы таки удивитесь, но Perl далеко не настолько прожорливый, как тот же Python (которым, к слову, не брезгают Google и Yandex, а уж кому как не им знать цену тормозам и глюкам), не говоря о всяких Рельсах. Более того, столь усердно пинаемая вами OpenBSD работает и на платформах вроде gumstix и Soekris. С точно тем же Perl'ом и теми же написанными на нём утилитами pkg_*. Жаль, сейчас под руками рабочей машинки класса P5 нету, специально бы сравнил скорость. Ну а насчёт памяти — только что провёл эксперимент. Максимум командой pkg_add было отожрано 25 мегабайт — на наборе из нескольких пакетов (evolution + зависимости).
Никто не говорит, что быстрое написание софта гарантирует меньшее количество багов. Точно так же как использование молотка вместо микроскопа не гарантирует лучшее качество забивания гвоздей. Всё зависит в первую очередь от рук. Но! Когда есть руки, выдающие определённый результат за неделю, и руки, выдающие такой же результат за месяц, вы какие руки предпочтёте? Только честно. На Perl можно писать хорошие программы (хоть меня и воротит местами с этого языка, но это личное; его возможности действительно потрясающие). Как и на C. Как и на C#. Как и на JavaScript.
Кстати, зачем в embedded нужен apt*, мне так никто и не ответил. ;)
Да, на Perl пишут много говна. Но это вовсе не означает, что всё на нём написанное — говно. Тот же LiveJournal (который когда-то использовал двухярусную систему с предварительной компиляцией HTML-файлов — было забавно читать, как вы мне про эту схему рассказываете), например, издавна использует Perl. И до перехода под "СУП" жалоб на работу движка не припомню. Проблемы с железом — были, DDoS-ы — были, проблемы с провайдерами — были. А движок исправно работает.
Да что я тут распинаюсь — сходите и посмотрете список хороших, успешно работающих на Perl проектов. Он исчисляется отнюдь не единицами и даже не сотнями.
Ну а узнать, что означает фраза «бизнес-логика» в программировании, будет вашим домашним заданием, OK? ;)
Насчёт виртуализации: что это такое, я знаю не понаслышке. Стараюсь не использовать — святая правда. Потому что виртуализации вижу применение либо в роли костыля, либо в роли средства экономии. Первое, понятно, только для совсем форс-мажорных обстоятельств. Второе — либо для предоставления услуг (VPS — это модно!), это совсем отдельная тема; либо для изоляции задач, типа, из соображений безопасности; либо для обеспечения отказоустойчивости (Xen, например, уверенно движется в этом направлении). Во втором случае обычно делают много однотипных конфигураций, который однотипно же и ломаются — в чём тут безопасность, лично мне не понятно. Ну а насчёт третьего ничего особо плохого сказать не могу — это примерно то же, что использование Perl вместо C. ;)
>p.s. извиняюсь за несколько злой пост, для програмеров советую рассматривать это как
>всего лишь взгляд тестера на программы. Тогда будет понятно чего я
>злой.Да понимаю, понимаю. Сам когда-то так же думал, чего греха таить. :)
>Менеджер пакетов — такой же софт, как и всё остальное. Периодически появляется
>необходимость что-то дорабатывать, переделывать.Это системный софт, делаемый 1 раз и надолго. И в конечном итоге - переделывать и дорабатывать там если и надо то не так уж много. Как минимум - в тех базовых частях которые собственно пакетами занимаются. Я еще могу понять когда вот такое скажут про гуйную морду например (и то - стоит помнить что дебиян порой работает на low resource приблудах с гуем).
>Изначальный вопрос («на хрена?») был за вами, что ж вы его по-прежнему
>мне задаёте, а не разработчику?Вообще, я его задаю не лично вам - форум как бы не ваш приват, если что.
>Он не скрывается, контакты доступны, даже, кажется, в этом обсуждении
>участвовал (Андрей). Боитесь ответа? :)Мне кажется что если б я боялся ответа - я бы не спрашивал. Это самый надежный метод не получить ответа на свой вопрос :).
>И почему вы вообще решили, что скорость разработки обязательно будет ухудшать качество?
Потому что я видел это своими глазами зиллион раз на примере разных проектов. Живет себе проект, хороший, работающий, каши не просит. Тут кому-то шило в зад стреляет переписать его на дотнете, питоне, яве, ... .При этом появляется соблазн понафигачить фич побольше и раз все вроде как написано - выпустить побыстрей. В итоге - выпускается ... монструозное тормознутое глюкало. Это такой фирменный стиль работы проприетарщиков ориентированных на бизнес. Я на него насмотрелся выше крыши, и - оно реально за...ло. И я буду серьезно раздосадован если дебианщики скатятся до такого же подхода к написанию софта.
>Я уже приводил пример, когда переход с C на Perl в аналогичной ситуацииВаш пример был установщиком пакетов? Он работал на low resource платформах? Или вы просто впендюрили перловую байду на мощный сервант у которого проца хватало с многократным запасом что так что сяк и убедились что в такой конфиге все упирается в I/O? Да, конечно, некоторым бздунам с их жутко портабельной системой видевшим аж целый один (ну, может, два) сценарий юзания крайне трудно вообразить себе что дебиан испольузется не только на крутых сереврах где процессоров много и они мощные. А теперь включите голову и отдайте себе отчет в том что n900, *телефон*, крутит на себе доработанный дебиян. А также то что контейнеры и виртуалки - это не роскошь и не экзотика.А повседневная обыденность. Конечно, эти сценарии использования ОС с вашей любимой опенбздей просвистели мимо вас, у вас там все до сих пор на уровне пещерного человека. Но нахрена ж все по себе то мерять?!
>привёл к многочисленным улучшениям, в том числе — в скорости работы самих программ.
Знаете, в чем ваша проблема? Вы не рассмотрели *разные* платформы где работает дебиан. У разных платформ где он работает - очень разное соотношение между возможностями проца, ввода-вывода и прочая.И то что вы видите на вашем сраном писюшнике - это одно.А то что вы узрите на эмбедед или карманной железке например - несколько другое. Вы вашу байду бенчмаркали на таких платформах или как всегда только на мощном серванте с дофига оперативы прогнали и сделали масштабные выводы? Ваши выводы катят только для бздей которые никому нигде кроме серверов нахрен не впились. А дебиан нынче встречается много где еще. И даже если вы этого не видели, не знаете или вам просто вломак про это подумать - это не значит что этого не существует.
>Да, если взять несколько грамотных C-программистов, то можно добиться
>небольшого ускорения работыА давайте мы возьмем ARM на 200 мегагерц, впихнем ему 64 мег оперативы, впихнем туда гуй с иксами и потом - захотим там ставить пакеты. Вполне нормальная жизненная ситуация, она еще называлась Nokia 770. В n8x0 и 900 получше но не настолько уж и сильно. Клево будет если манагер пакетов будет полчаса свопом тарахтеть или нарвется на аут памяти, да?
>— не забывайте, что основное время при управлении пакетами уходит на ввод-вывод,
Не забывайте включить мозг и подумать что дебиан - это вам не бздя. И что он бывает на *разных* платформах. И у этих разных - очень разное соотношение цены I/O и времени проца. Давайте на n8x0 посмотрим?Скажите ка мне, мистер - а чойта там пакетный манагер проц нагружает, ась? Может, дело в том что пачка оптеронов или ксеонов на серванте обладает достаточным запасом дури чтобы отпедалить даже перл не особо тормозя (что так что сяк в основном упрется в I/O) а в n8x0 их арм с питанием от хилой батареечки не может молотить на гигагерцах в силу отсутствия на это энергии и упираться будет чаще в него чем в I/O, ась? Ну я понимаю что бздунов все это не колыхает - они дальше своих пыльных гробов с бздей взглянуть в принципе не способны. Лишний раз подтверждаете это. А я в отличие от вас понимаю что пакетный манагер - это *универсальная* штука, стало быть - должно нормально работать везде где работает эта ОС. А это и карманная мелочевка с телефон размером, и железки с пару пачек сигарет, типа сетевых коробок для жестких дисков, и виртуалки с контейнерами и что там блин еще.
>да ещё, в случае с интерактивными оболочками, на ожидание ввода пользователя.
Это нормально - машина должна ждать человека. Когда наоборот - плохо...
>Но честно скажите, оно того стоит?
Да, оно того не просто стоит - оно required. Потому что дебиан - это не ваша любимая опенбздя которая работает в основном только на железных серваках. Дебиан встречается в эмбеддед и карманных устройствах, на виртуальных окружениях, ... - где ресурсы более ограничены чем на вашем десктопе или серванте и соотношения между ценой IO и CPU могут довольно заметно варьироваться. О чем разумеется подумать вы не смогли.
>Или вы всегда напряжённо медитируете на бегущие проценты? :)
Я просто рассматриваю разные сценарии использования в отличие от вас. Не забывая о карманниках, эмбеддед, виртуалках, контейнерах и прочая.
>Я лично просто переключаюсь на другую задачу.
Попробуйте это для общего развития проделать на, допустим, Nokia N8x0 - там как раз система на основе дебиана и где-то в глубине всю работу делает дебианский манагер пакетов. Когда и без того не больно крутой 400МГц арм с 128 мег оперативы беззазренно кушается манагером пакетов, общая скорость работы системки очень не способствует таким потугам. Поэтому - там скорости много не бывает. Зуб даю. И даже конкретный сценарий использования дебиянистой системы в комплекте с ним любезно предоставил, как видите.
>А если я не могу переключиться на что-то другое, значит, я плохо планирую своё время.
Да нет, просто вы не хотите думать головой и рассматривать все сценарии использования дебияна где он реально встречается *сегодня*. Вас хватает только на то чтобы рассмотреть сценарий юзежа характерный для бзди. И .. все. Но дебиан есть на намного большем количестве платформ чем обожаемая вами опенбздя (которую я, честное слово, нигде кроме пыльных x86 серверов попросту не видел).
>Вы таки удивитесь, но Perl далеко не настолько прожорливый, как тот же
>Python (которым, к слову, не брезгают Google и Yandex,Есть только одна проблемка - у девайса с дохленьким проциком и мизером оперативки нет ресурсов как у серверов гугеля и яндекса. А вот дебиян там - есть. Очень даже. Ога?
Или мне в комплекте с мобилкой на тележке 19" стойку с серваками катать спецом для выполнения там всякой тормозной байды? :).И, знаете, да - меня не прет идея ффтыкать на проценты пока приложение на "супер-телефон" или "домашний nas" ставится. К тому же в "супер-телефоне" система будет тормозить из-за не слишком мощного проца и переключаться в другую задачу не быстро и уныло а у NAS вообще только вебморда - что такое "переключиться в другую задачу" применительно к работе с девайсом через вебморду например?Или благородный дон как всегда уперся в свои пыльные х86 сервера с бздей и ничего кроме них вокруг не видит?А Дебиян встречается много где еще. Сюрприз....>а уж кому как не им знать цену тормозам и глюкам),
Кому?Разработчикам embedded и battery-powered байды. Которые не могут в случае чего серверов в датацентр докупить или проц помощнее воткнуть. Да, как я уже сказал, дебиан - это вам не опенбсд, которая нигде кроме таковых серверов толком не встречается. И если кто делает манагер пакетов - он должен смотреть на *все* варианты юзежа дебияна. Иначе получится негодный манагер пакетов, остальные (типа нокий и прочих) вынужденно начнут лабать альтернативы. И начнется бардак с пакетными манагерами в духе редхатоподобных систем, где каждый городит в меру своей дури а при юзеже этого приходится мучаться с полудюжиной подвидов манагеров пакетов и их особенностей, их не-совсем-совместимостью и прочая.
>не говоря о всяких Рельсах. Более того, столь усердно пинаемая вами OpenBSD работает
>и на платформах вроде gumstix и Soekris.Чисто номинально она там конечно работает, но вот кто ее по факту там использует? Вы мне можете показать хоть 1 человека? Я могу в ответ показать миллион юзвергов с wi-fi роутерами, адсл-модемами, nas-устройствами и прочая где сроду работают разнообразные линухи (иногда бывает и допиленый вариант дебиана, в частности).
А если уж говорить о скорости и пакетных манагерах, то скорость работы дебиянского добра и потребление ресурсов ряд эмбедерщиков и так не устроило - в итоге появились ipkg и opkg, по мотивам дебианского но попроще и полегче. Вот только зоопарк - не рулит.
>С точно тем же Perl'ом и теми же написанными на нём утилитами pkg_*. Жаль, сейчас
>под руками рабочей машинки класса P5 нету,Да в задницу P5, я вам что, некрофил чтоли? Вы лучше на gumstix поупражняйтесь, раз уж у вас там все так хорошо работает. Вот и расскажете заодно как вам оно и как там с ценой IO супротив цены проца и сливает ли там ваша прога на перле всего на 20% или же слив получается более другой. Я выше привел свои мысли - возникшие на основе наблюдений за работой манагера пакетов на n8x0. Я бы не стал орать что меня радует его скорость работы там и потребление оным ресурсов. В моем понимании - так оно еще и в улучшении нуждается, а то когда секунд ..цать пакетный манагер занимает весь проц - это не очень здорово.
>специально бы сравнил скорость.
"бы" - не считается. Я вот на n8x0 на работу пакетного манагера насмотрелся. И сравнил. И знаете, я как-то не слишком доволен его скоростью работы *сейчас*. Куда уж хуже то? oO
>Ну а насчёт памяти — только что провёл эксперимент. Максимум командой
>pkg_add было отожрано 25 мегабайт — на наборе из нескольких пакетов
>(evolution + зависимости).Да, всего-то, елки. А теперь подумайте о том что если у меня на n800 запущены иксы, браузерок с парой страниц, файлманагер, кучка аплетиков на десктопе, почтовичок, пиджин и прочая байда и мне вдруг приспичило всего лишь программку поставить - выкроить в такой конфигурации 25 мегов - это ну совсем не ерунда. Если у юзера своп отрублен - он OOM отхватит вообще, к своему великому удовольствию. А со свопом будет ффтыкать на меееедленнное и печальное свопление всего каких-нибудь там полчаса. Ну да, опенбсд на этом не работает и вы такой сценарий использования поэтому "забыли". Но дебиан - это не опенбсд.
>Никто не говорит, что быстрое написание софта гарантирует меньшее количество багов.
По моим многолетним наблюдениям оно наоборот гарантирует БОЛЬШЕЕ качество багов. Дело в том что написание программы - это еще не все.
>Точно так же как использование молотка вместо микроскопа не гарантирует лучшее качество
>забивания гвоздей.Проблема только одна - вы хотите в роли молотка приволочь, высунув язык, большую и тяжелую кувалду, созданную для вхреначивания железнодорожных костылей в шпалы(как то жизня на мощных сервантах яндекса и гугля). Чтобы гвоздить быстро и наверняка. А то что забивать надо иногда и мебельные гвоздики а данной кувалдой это крайне медленно, мучительно и геморройно и может так оказаться что даже микроскопом будет лучше, вы немного так не подумали. Поэтому обычно у людей дома все-таки не упомянутая кувалда в более вменяемый и относительно универсальный молоток, сносно подходящий под множество сценариев использования.
>Всё зависит в первую очередь от рук. Но! Когда есть руки, выдающие
>определённый результат за неделю, и руки, выдающие такой же результат за месяц,
>вы какие руки предпочтёте?Для пакетного манагера - мне не принципиально, доведут его до ума за неделю или за месяц. У меня пока есть работающий манагер пакетов делающий свое дело. Успешно делающий. И поэтому подождать 3 недели - я вполне могу. А вот жить хренадцать лет с стремным манагером пакетов на перле - ну совсем не хочется, извините.Потому что в половине мест я или буду лицезреть его адские тормоза, или всякие конторы пошлют дебианщиков с такими манагерами в пешее эротическое и начнут велосипедостроение. В итоге придется осваивать пять-шесть вариантов и подвидов как для редхата? Спасибо за радужные перспективы, ага!
При том в случае бизнеса - ну я там понимаю, продажи надо толкать и экономия 3 недель означает что рубка капусты начнется на 3 недели раньше. Сейлсы будут пищать от счастья загребая бабло с лохов купивших это глюкало лопатой и все такое. Но я что-то никак не могу прикрутить в своем мозгу данную бизнес-модель к ... МАНАГЕРУ ПАКЕТОВ. Его, черт возьми, проблематично продавать кастомерам. Ну и куда там торопиться как на пожар тогда?
>Только честно. На Perl можно писать хорошие программы (хоть меня и воротит местами с
>этого языка, но это личное; его возможности действительно потрясающие).Весь вопрос в том - сколько ресурсов скушают эти программы и что будет с юзерами дебиана на low resource конфигурациях. А дебиан там как бы встречается. Это вам не опенбсдя и оно работает на вагоне эмбеддед, используется нокией как база для ... телефонов (!!!), крутится на зиллионе виртуалок и контейнеров и прочая.
>Как и на C. Как и на C#. Как и на JavaScript.
Скорее, я бы сказал что "даже на ассемблере можно написать кривое тормозилово настолько через задницу что оно сольет даже неплохому скрипту на JS". Но если писать нормально и не через зад (то есть, обе программы писали компетентные програмеры способные использовать эффективные алгоритмы) - черта с два JS обгонит C-шный код. Разве что по тормозам и выжранным ресурсам :).Для веба, где полтора скрипта раз в полчаса что-то делают - это не особая проблема. Хотя в случае ajax и прочая ... нуу... движки в браузерах оптимизят с таким остервенением наверное не для прикола? :)
>Кстати, зачем в embedded нужен apt*, мне так никто и не ответил. ;)
Чтобы ставить софт, Luke :).Ну вон те же n8x0 например - чем вам не нравятся как пример?
>Да, на Perl пишут много говна. Но это вовсе не означает, что
>всё на нём написанное — говно.Я не имею ничего против юзежа перла. Но я не понимаю зачем на нем делать системный тул типа манагера пакетов. Который к тому же имеет все шансы работать и на low resource конфигурациях (ибо это входит в сценарии юзания дебиана и систем на его кодовой базе).
>Тот же LiveJournal
Ага, нравится мне ваш подход - сказать что embedded не нужен и кивать на веб-проекты, где сервера мощные. Знаете как это называется? Это тот самый поиск ключей под фонарем. Не потому что вы их там потеряли а потому что там искать светлее, видите ли. Нет, так не пойдет - результат то будет нулевой. Ну то есть опенбсдю и не юзают практически в эмбеддед и на виртуалках с контейнерами. И хрен бы с ней. А дебиан вот юзают. Прикиньте?
>А движок исправно работает.
Угу, а теперь сравните тамошние сервера например с n8x0 :).Вместе посмеемся разнице в их horsepower :).А n8x0 - это чуток допиленный дебиан...
>Насчёт виртуализации: что это такое, я знаю не понаслышке. Стараюсь не использовать
>— святая правда.Ну и кто вам доктор? А мне нравятся возможности по перемещению машин, изоляции, дележу ресурсов, снапшотингу и прочая. Можно жить в пещере и готовить жратву на костре. Но в теплом хаусе и микроволновке - удобнее, пардон. И накукуй мне игнорировать блага прогресса?Особенно учтя что оверхед на приготовление в микроволновке супротив костра не так уж велик а ряд вещей так готовить проще и быстрее?При не особо больших потерях :) (какие-то копейки Чубайсу отстегнуть придется, тогда как дров на костер можно нахаляву насобирать в лесу).
>Потому что виртуализации вижу применение либо в роли костыля, либо в
>роли средства экономии.Я ее вижу в качестве удобного средства изоляции, дележа ресурсов и удобный инструмент дающий новые возможности типа создания снапшотов, живой миграции и т.п. - это дает больше возможностей для маневра, управления ресурсами и решения ряда проблем.Это не модно.И не круто.Оно такое, каким это и должно было бы быть с самого начала (у некоторых даже было, только простым смертным было не по карману, как электричество в начале XX века).
>Первое, понятно, только для совсем форс-мажорных обстоятельств.
Какой-то странный сценарий. Я такого юзежа виртуализации почти не видел.
>Второе — либо для предоставления услуг (VPS — это модно!),
Это не модно. Это - удобно и эффективно по использованию ресурсов железа. Можно купить крутой и дорогой сервак и он будет на 90% ничего не делать кроме отопления воздуха большую часть времени. А можно и получше его использовать. А вешать на 1 сервак множество ролей - очень на любителя. А потом таким любителям ломают их форумок, а потом и все остальное, от корпоративного сайта до почтовика.
>либо для изоляции задач, типа, из соображений безопасности;
Из соображений безопасности, полисовки и дележки ресурсов и просто более эффективного использования железа.
>либо для обеспечения отказоустойчивости (Xen, например, уверенно движется в
>этом направлении). Во втором случае обычно делают много однотипных конфигураций, который
>однотипно же и ломаютсяЗнаете, кулеры однотипно не ломаются в 1 день на всех серверах сразу, харды однотипно не сыпятся в один момент все сразу. А вот если скажем мониторинг информирует нас о том что однозначно приближается пиндец и надо б железяку в ремонт - дык задвинуть виртуалки на соседнюю железку по сети без прерывания сервиса так что у юзерья даже соединения не порвутся - соблазнительная фича вроде, а?
>— в чём тут безопасность, лично мне не понятно.
Безопасность в основном в том что виртуализаторами и контейнерами можно попилить все более иначе чем традиционно. В случае железа - выделять свою машину на все и вся весьма накладно. А вот виртуализатором и особенно контейнерной системой типа опенвзы (оверхед по ресурсам меньше, нет своей копии ядра и прочая) можно попилить мощный сервак по принципу 1 сервис = 1 контейнер. Тогда, если кто сломал вебсвервант через дыру в нем - он поимел только доступ к вебсерванту. А вот к почтовику или там еще чему - не поимел. Более того - в силу примитивности начинки контейнера (минимальная система нужная для работы вебсервака) ее просто мониторить на изменения и можно вместо системных утилит положить "ловушки" как и учинить без особого напряга тотальный мониторинг.И можно автоматически парировать действия, просто дернув упаравлятор виртуализатора и сообщив ему что надо потушить вон ту машину. Можно снапшот на изучение сделать. И откатить на снапшот до внедрежки. Вернув в вид как будто хакер вообще не заходил. При этом хакер не видит мониторинг и не может его убить даже будь он хоть пять раз рут в своем загончике.Рут то он рут но у физического хоста и управлятора виртуалками все-равно длиннее.И собссно физический хост вообще не обязан быть хаксору доступен по сети :).Гнусный чит, да? :).Тем более что до кучи можно ресурсы полисовать - хаксор даже загрузить проц, выжрать все место на диске и прогрузить сеть не сможет. В итоге - можно изгальнуться на весьма не дружественную к хакерам конфигурацию, которая легко и просто отстреливает поломанные сервисы и алертит админа и не дает особо ничего дестроить кроме разломанного сервиса (а раз он разломаный то невелика потеря). Да и с невидимыми руткитами для хакерья все сложнее становится.В какойнить опенвзе вообще модуль ядра рут контейнера не может грузить.А пакость в утилсах - штуками типа inotify или просто фоновыми сканами с хоста (у которого утилсы свои, не протрояненые и хаксору вообще невидимые) пропалится быстренько (если админу оно было надо и он озадачился этим).
>Да понимаю, понимаю. Сам когда-то так же думал, чего греха таить. :)
Я могу понять юзеж перла для веб-приложений на мощных серверах. Но для пакетных манагеров... гхм. Они работают не только на мощных серверах! Я попробовал показать вам некоторые промашки в вашей логике. Получилось едко но я старался чтобы еще и конструктив присутствовал.
(Много фигни skipped)Сравните: http://www.debian.org/releases/stable/ и http://www.openbsd.org/plat.html . И после этого говорите о том, кто у кого где поддерживается. И если до вас всё ещё не доходит: в OpenBSD, как и в Debian, платформы поддерживаются разработчиками при наличии интереса. Если бы не было пользователей, не было бы и поддержки. Надеюсь, это-то доказывать не надо?
>[оверквотинг удален]
>работой манагера пакетов на n8x0. Я бы не стал орать что
>меня радует его скорость работы там и потребление оным ресурсов. В
>моем понимании - так оно еще и в улучшении нуждается, а
>то когда секунд ..цать пакетный манагер занимает весь проц - это
>не очень здорово.
>>специально бы сравнил скорость.
>
>"бы" - не считается. Я вот на n8x0 на работу пакетного манагера
>насмотрелся. И сравнил. И знаете, я как-то не слишком доволен его
>скоростью работы *сейчас*. Куда уж хуже то? oOНу нету лично у меня под руками сейчас свободного тормозного железа. Максимум — Sparc через месяцок, возможно, освободится. Хотите — спросите сами на misc@openbsd.org, если вы хотите это знать. А если не хотите — то и не утверждайте, что заранее всё знаете.
>[оверквотинг удален]
>
>Да, всего-то, елки. А теперь подумайте о том что если у меня
>на n800 запущены иксы, браузерок с парой страниц, файлманагер, кучка аплетиков
>на десктопе, почтовичок, пиджин и прочая байда и мне вдруг приспичило
>всего лишь программку поставить - выкроить в такой конфигурации 25 мегов
>- это ну совсем не ерунда. Если у юзера своп отрублен
>- он OOM отхватит вообще, к своему великому удовольствию. А со
>свопом будет ффтыкать на меееедленнное и печальное свопление всего каких-нибудь там
>полчаса. Ну да, опенбсд на этом не работает и вы такой
>сценарий использования поэтому "забыли". Но дебиан - это не опенбсд.Никто ничего не забывал. Это вы забыли указать свои цифры, сколько сейчас ест apt. Самому, что ли, проверить…
>>Никто не говорит, что быстрое написание софта гарантирует меньшее количество багов.
>
>По моим многолетним наблюдениям оно наоборот гарантирует БОЛЬШЕЕ качество багов. Дело в
>том что написание программы - это еще не все.Поздравляю, вы сделали первый шаг к познанию истины.
>[оверквотинг удален]
>
>Проблема только одна - вы хотите в роли молотка приволочь, высунув язык,
>большую и тяжелую кувалду, созданную для вхреначивания железнодорожных костылей в шпалы(как
>то жизня на мощных сервантах яндекса и гугля). Чтобы гвоздить быстро
>и наверняка. А то что забивать надо иногда и мебельные гвоздики
>а данной кувалдой это крайне медленно, мучительно и геморройно и может
>так оказаться что даже микроскопом будет лучше, вы немного так не
>подумали. Поэтому обычно у людей дома все-таки не упомянутая кувалда в
>более вменяемый и относительно универсальный молоток, сносно подходящий под множество сценариев
>использования.Правильно. У людей дома Perl. GCC сейчас на Linux'овых машинах реже встречается. ;)
>>Всё зависит в первую очередь от рук. Но! Когда есть руки, выдающие
>>определённый результат за неделю, и руки, выдающие такой же результат за месяц,
>>вы какие руки предпочтёте?
>
>Для пакетного манагера - мне не принципиально, доведут его до ума за
>неделю или за месяц. У меня пока есть работающий манагер пакетов
>делающий свое дело. Успешно делающий.Вы прикидываетесь, что ли? Прочитайте обсуждение (не нашу с вами полемику, а вообще), там были конкретные ссылки. И не забывайте, что если часовая бомба не взорвалась в течение часа, это не значит, что она не взорвётся позднее.
> И поэтому подождать 3 недели -
>я вполне могу. А вот жить хренадцать лет с стремным манагером
>пакетов на перле - ну совсем не хочется, извините.Потому что в
>половине мест я или буду лицезреть его адские тормоза, или всякие
>конторы пошлют дебианщиков с такими манагерами в пешее эротическое и начнут
>велосипедостроение. В итоге придется осваивать пять-шесть вариантов и подвидов как для
>редхата? Спасибо за радужные перспективы, ага!Вы до сих пор оперируете фразами типа «я предвижу». И НИ ОДНОГО КОНКРЕТНОГО довода «против»!
>[оверквотинг удален]
>два JS обгонит C-шный код. Разве что по тормозам и выжранным
>ресурсам :).Для веба, где полтора скрипта раз в полчаса что-то делают
>- это не особая проблема. Хотя в случае ajax и прочая
>... нуу... движки в браузерах оптимизят с таким остервенением наверное не
>для прикола? :)
>
>>Кстати, зачем в embedded нужен apt*, мне так никто и не ответил. ;)
>
>Чтобы ставить софт, Luke :).Ну вон те же n8x0 например - чем
>вам не нравятся как пример?Это уже не embedded. Это вполне нормальный комп со специфическим управлением. Embedded — это те самые роутеры, мини-АТС и прочая.
>[оверквотинг удален]
>это входит в сценарии юзания дебиана и систем на его кодовой
>базе).
>
>>Тот же LiveJournal
>
>Ага, нравится мне ваш подход - сказать что embedded не нужен и
>кивать на веб-проекты, где сервера мощные. Знаете как это называется? Это
>тот самый поиск ключей под фонарем. Не потому что вы их
>там потеряли а потому что там искать светлее, видите ли. Нет,
>так не пойдет - результат то будет нулевой.Вообще-то это вы первый упомянули про то как сайты нагрузку снижают. Так что, батенька, слив засчитан.
>Ну то есть
>опенбсдю и не юзают практически в эмбеддед и на виртуалках с
>контейнерами. И хрен бы с ней. А дебиан вот юзают. Прикиньте?Ой, а ещё в виртуалках активно юзают Microsoft Windows… Прикиньте?
А OpenBSD вполне исправно виртуализируется. Просто не всем оно надо. Вам надо? Так пожалуйста, никто вас не ограничивает.
>>Первое, понятно, только для совсем форс-мажорных обстоятельств.
>
>Какой-то странный сценарий. Я такого юзежа виртуализации почти не видел.Ну вот когда нет возможности докупить железо или физически его поставить. Или когда Web-дизайнеру надо тестировать сайт в куче версий MS IE одновременно. Что ж вы, такой опытный специалист в виртуализации, и не подозревали о таких случаях? ;)
>[оверквотинг удален]
>харды однотипно не сыпятся в один момент все сразу. А вот
>если скажем мониторинг информирует нас о том что однозначно приближается пиндец
>и надо б железяку в ремонт - дык задвинуть виртуалки на
>соседнюю железку по сети без прерывания сервиса так что у юзерья
>даже соединения не порвутся - соблазнительная фича вроде, а?
>
>>— в чём тут безопасность, лично мне не понятно.
>
>Безопасность в основном в том что виртуализаторами и контейнерами можно попилить все
>более иначе чем традиционно.(рассказ о "возможностях" виртуализации в плане организации безопасности опущен)
Вы чем меня (или ещё кого) удивить-то хотите? Вы таки удивитесь, но с возможностями OpenVZ, Xen и прочая я вполне знаком. Особенно с рассказами о том как всё безопасно становится. Становится-то становится, но только до дырки в виртуализаторе. После этого хакер получает мегарута, у которого действительно руки до чего угодно уже дотянутся.
Насчёт того, что «хакер не будет знать, что находится в виртуализованной среде» — вообще бред. Хакер не идиот, и понимает, что если не видит тех или иных обычных сервисов, то это виртуалка.
Скажите только честно: вы сколько раз в жизни наблюдали работу хакеров на своих серверах?
>>Да понимаю, понимаю. Сам когда-то так же думал, чего греха таить. :)
>
>Я могу понять юзеж перла для веб-приложений на мощных серверах. Но для
>пакетных манагеров... гхм. Они работают не только на мощных серверах! Я
>попробовал показать вам некоторые промашки в вашей логике. Получилось едко но
>я старался чтобы еще и конструктив присутствовал.С конструктивом как раз не очень. Жду от вас честных цифр по apt, как на i386, так и на вашем ненаглядном смартфоне. А едкость приберегите для врагов… Хотя да, для вас BSD-шники — враги, а не коллеги, всё время забываю. Можете не рассказывать, почему, думаю, и так все в курсе.
P.S.: С большим уважением отношусь к проекту Debian и считаю Debian Linux единственным достойным дистрибутивом Linux из тех, с которыми сталкивался.
(сорри, забыл ответить)>>Я уже приводил пример, когда переход с C на Perl в аналогичной ситуации
>
>Ваш пример был установщиком пакетов? Он работал на low resource платформах?Да, это установщик пакетов. Работает на low-resource платформах. Код здесь: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/pkg_add/
>Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге
>мало того что он тормозной что пипец, так еще и жирные
>пакеты с кучей зависимостей на low resource машинах (128 мегов RAM,
>etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну
>памяти видите ли не хватает - во новости! Да, блин, теперь
>128 мегов (без иксов и с почти нифига в системе, где
>полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут
>городить тормозных прожорливых монстров на перле?Yum стал лучше в федоре 12й, попробуйте (а плагин presto - это счастье для пользователей медленного интернета).
> Yum стал лучше в федоре 12йА в 11 чем был плох? И presto там есть (если установить yum-presto).
>> Yum стал лучше в федоре 12й
>
>А в 11 чем был плох? И presto там есть (если установить
>yum-presto).Нет, мне йум всяко нравится и сейчас, но в 12й федоре стал быстрее заметно.
>Нет, мне йум всяко нравится и сейчас, но в 12й федоре стал
>быстрее заметно.Неплохо. Он и в 11-й не медленный, а тут.. :)
а почему нельзя просто доработать мажорную версию АРТ? АРТ совсем помер уже что ли?
Наверное, это создаст изменения, сильно меняющие APT.
Проблемы с архитектурой и реализацией - это какие? У меня не хватает мозга понять, видимо, это что-то маленькое но в итоге обидное.
Это проблемы мешающие добавлять новые фичи и исправлять ошибки без приведения кода в помойку.
> Это проблемы мешающие добавлять новые фичи и исправлять ошибки без приведения кода в помойку.а можно пример конкретный, а то одни слова что тут что на вики...
Например, в этом баге намек на сложность его исправления. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542767
>написанной на языке PerlСпасибо, не надо.
А кто загрузит и поставит перл, если сделана минимальная инсталляция оси?.. Ручками?
Зачем нужен менеджер пакетов, который сам зависит от десятков пакетов?
>А кто загрузит и поставит перл, если сделана минимальная инсталляция оси?.. Ручками?
>
>Зачем нужен менеджер пакетов, который сам зависит от десятков пакетов?Либо это инсталляция на нормальный комп и поставить Perl — не проблема, либо это что-то типа встраиваемых систем, но тогда что там забыл менеджер пакетов? :)
OpenWRT. что там забыл менеджер пакетов? О_о
зачем сразу так категорично?
Угу, а nokia Nxx0 или OpenWRT блаародный дон конечно не видел. Ну да, конечно, если делать по технологиям 80-х то конечно, можно и вовсе в ROM с ультрафиолетовым стиранием все шить.Только некрофилов знаете ли немного потому что гибкие и обновляемые решения нужны всем. Для начала - очень много добра работает с сетями. В частности обе упомянутых железки. И это означает что однажды они не будучи апдейтабельными попросту станут вкусными маленькими ботами. А миллиард комаров как известно поднимает в воздух слона. Не говоря о том что миллион роутеров начавших синхронно флудить вокруг - уронит все что роняется. Вы все еще считаете что манагеры пакетов блажь?Зря, 80-е закончились, 90-е прошли. И реалии нынче другие - орава хакерья ищет дыры везде, ради наживы на спаме и ддосах на конкурента.Так что по старинке уже во многих случаях не выйдет, реалии не те...