The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Представлена бета-версия Cupt, проекта продолжающего развити..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от opennews on 25-Сен-09, 16:25 
Евгений Любимкин, ранее участвовавший в разработке 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...
Новость: https://www.opennet.ru/opennews/art.shtml?num=23577

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от kost BebiX email on 25-Сен-09, 16:25 
Перл???
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 25-Сен-09, 16:59 
Он самый. Что замечательно (от слова "замечать"), в OpenBSD поступили в своё время аналогично: унаследованные от фряшной системы портов утилиты pkg_* были переписаны (и впоследствии значительно доработаны) на Perl. На скорость никто не жалуется. Perl,  кстати, вообще довольно быстрый, когда дело касается ввода-вывода: у меня получалось терять не более 25% производительности на задачах типа "скопировать вон ту кучу файлов, сжимая по дороге через gzip".
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Представлена бета-версия Cupt, проекта продолжающего развити..."  –2 +/
Сообщение от Warhead Wardick on 25-Сен-09, 18:11 

for infile in *.pl; do gzip -9 -c $infile > /path_to_pomoika/$infile.gz; done

А уж при чём "скорость" перла в такой задаче ... он ну очень быстро передаёт имя файла в cp, gzip и иже с ними? Угадал? А кто медленно? В общем - смотри пп 1.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 25-Сен-09, 18:23 

>
>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).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от Аноним (??) on 25-Сен-09, 18:36 
При наличии смекалки это решается через pipe и ssh -c

Другой вопрос, что если нужно реально независимое от платформы решения (даже для оффтопика), то тогда perl надежда и опора администратора.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 25-Сен-09, 18:40 
>При наличии смекалки это решается через pipe и ssh -c

А я и не говорил, что задача была только в передаче файлов. :) Там бизнес-логики тоже хватает. По сути, задача была в написании бэкапной системы. Решения рассматривались разные, от bacula до собственной реализации на C. По различным причинам, в которые вдаваться долго, лень и нет смысла, было выбрано написание своей системы на Perl.

>Другой вопрос, что если нужно реально независимое от платформы решения (даже для
>оффтопика), то тогда perl надежда и опора администратора.

И это тоже верно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от stranger (??) on 25-Сен-09, 17:38 
Вообще-то тестовые варианты rpm тоже были сначала на перле написаны. И уже потом, после отработки функциональности оно было переписано на C.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от User294 (ok) on 29-Сен-09, 06:13 
Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге мало того что он тормозной что пипец, так еще и жирные пакеты с кучей зависимостей на low resource машинах (128 мегов RAM, etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну памяти видите ли не хватает - во новости! Да, блин, теперь 128 мегов (без иксов и с почти нифига в системе, где полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут городить тормозных прожорливых монстров на перле?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 29-Сен-09, 09:42 
>Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге
>мало того что он тормозной что пипец, так еще и жирные
>пакеты с кучей зависимостей на low resource машинах (128 мегов RAM,
>etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну
>памяти видите ли не хватает - во новости! Да, блин, теперь
>128 мегов (без иксов и с почти нифига в системе, где
>полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут
>городить тормозных прожорливых монстров на перле?

Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на сях написать такое гуано, что будет охренительно тормозить. Прежде всего — алгоритмы: код на Python с O(n) будет лучше кода на C с O(n!) на хоть сколько-то заметном количестве обрабатываемых объектов. Ну а на небольшом количестве (в случае с пакетным менеджером) вообще пофиг: вы заметите в его случае разницу между 0,1 с и 0,001 с? ;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает меньше багов. Вы предпочитаете программы, которые делают 1000 операций в секунду, на которые будет возникать в среднем пять ошибок, или 500, но всего с одной?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от User294 (ok) on 02-Окт-09, 13:27 
>Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на
>сях написать такое гуано, что будет охренительно тормозить.

Да, но при *равных* условиях (один и тот же алгоритм реализованный не слишком криворуким програмером) жрать ресурсов сишная байда будет в разы меньше.И тормозить - тоже. А то что тормозную дрянь можно написать даже на асме никто и не сомневался, хоть и придется больше стараться для этого :)

>Прежде всего — алгоритмы: код на Python с O(n) будет лучше кода на C
>с O(n!) на хоть сколько-то заметном количестве обрабатываемых объектов.

А еще дважды два равно четыре. Вот только если код с O(n) переписать на сях, он питона порвет с таааааким отрывом, что народ будет выпавшие челюсти выгребать из-под стола.

>Ну а на небольшом количестве (в случае с пакетным менеджером) вообще пофиг:
>вы заметите в его случае разницу между 0,1 с и 0,001 с?

Я замечаю когда yum тупит на виртуалках чтопиндец и нарывается на идиотский аут памяти тогда как apt в тех же условиях и не тупит и памяти ему хватает. Вполне заметная такая на глаз разница. Ога?


>;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней
>логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает
>меньше багов.

Знаете, я пока на баги в дебианской пакетной системе не жаловался. За несколько лет юзания я умудрялся поставить пакетный манагер в позу всего три раза. И все три достаточно легко вышибал его обратно в работоспособное состояние. Так что шли б теоретики с их теоретическими преимуществами и тормозными ресурсожоркими скриптоподелиями заодно?

>Вы предпочитаете программы, которые делают 1000 операций в секунду,
>на которые будет возникать в среднем пять ошибок, или 500, но
>всего с одной?

Я что-то не заметил 500 ошибок в текущем пакетном манагере. Даже если они там есть - реальным операциям они не мешают особо. Пользоваться ради каких-то чисто теоретических плюсов более тормозной и ресурсожоркой байдой меня не прет, извините. А вот разработанный по рапидному принципу (то бишь "на отвали") пакетный манагер - это, гм, финиш.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 02-Окт-09, 15:05 
>>Во-первых, Perl далеко не настолько прожорливый, как Python. Во-вторых, можно и на
>>сях написать такое гуано, что будет охренительно тормозить.
>
>Да, но при *равных* условиях (один и тот же алгоритм реализованный не
>слишком криворуким програмером) жрать ресурсов сишная байда будет в разы меньше.И
>тормозить - тоже. А то что тормозную дрянь можно написать даже
>на асме никто и не сомневался, хоть и придется больше стараться
>для этого :)

Напишете? На сях? Чисто для сравнения? ;)

>>;) В-третьих же, читайте внимательнее: Perl используется для упрощения внутренней
>>логики. А упрощение оной приводит к меньшим проблемам в поддержке, что означает
>>меньше багов.
>
>Знаете, я пока на баги в дебианской пакетной системе не жаловался. За
>несколько лет юзания я умудрялся поставить пакетный манагер в позу всего
>три раза. И все три достаточно легко вышибал его обратно в
>работоспособное состояние. Так что шли б теоретики с их теоретическими преимуществами
>и тормозными ресурсожоркими скриптоподелиями заодно?

"Теоретик", если вы посмотрите внимательно, долго занимался поддержкой и разработкой этой самой apt. Так что кто ещё из вас теоретик...

>>Вы предпочитаете программы, которые делают 1000 операций в секунду,
>>на которые будет возникать в среднем пять ошибок, или 500, но
>>всего с одной?
>
>Я что-то не заметил 500 ошибок в текущем пакетном манагере. Даже если
>они там есть - реальным операциям они не мешают особо. Пользоваться
>ради каких-то чисто теоретических плюсов более тормозной и ресурсожоркой байдой меня
>не прет, извините. А вот разработанный по рапидному принципу (то бишь
>"на отвали") пакетный манагер - это, гм, финиш.

Плюсы вам обозначили вполне конкретные. Про "на отвали" - чисто ваши домыслы, означающие изначальное недоверие к человеку, который для конкретной выбирает Perl вместо C только потому, что он этот выбор делает. Вас никто не заставляет сейчас пользоваться новым пакетным менеджером.

И если ещё раз затрагивать тему тормозов: чтобы реализовать многие полезные возможности Perl в рамках программы на C уходят человеко-часы разработки — вы, видимо, совсем не уважаете open source разработчиков, если не цените их время. Более того, скажем, те же хэши в Perl тщательно оптимизированы, в силу обширного их использования. Достигнуть такого же уровня на голом C можно, но нужно ли? Усилится тормознутость системы (за счёт дополнительного оверхеда), уменьшится надёжность (пока код не будет вылизан)…

Более того, повторюсь, использование Perl позволяет заметно легче разрабатывать, внедрять, отлаживать и рефакторить бизнес-логику. Что означает, в том числе, и повышение производительности. Пока в Вилла-Риба одни реализуют супер-мега-концепт, а другие сосут лапу и терпят тормоза и отсутствие функционала в ожидании, в Вилла-Баджио уже давно всё установилось и работает. ;)

А в виртуалке (окромя паравиртуальной среды) всё всегда будет тормозить по определению. ;) Если вы пользуетесь виртуализацией, стремясь к производительности, то поступаете ничуть не лучше человека, который делает сайты на голом статическом HTML, стараясь сделать их удобными и функциональными.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от User294 (ok) on 03-Окт-09, 03:12 
>Напишете? На сях? Чисто для сравнения? ;)

Да, умничать все сильны. А почему бы не задать этот вопрос разработчикам вон той поделки?Ну или спросить у них - куда они там так торопятся в создании системного компонента который делается раз и на чуть ли не десятки лет?Им настолько впадлу его делать?Или в чем прикол?Я еще могу понять когда так рассуждает какой-то жабист пишущий ява-крап для бизнесменов, но вот для манагера пакетов, системного компонента который делается раз и на вагон времени - это за пределами моего понимания.

>"Теоретик", если вы посмотрите внимательно, долго занимался поддержкой
>и разработкой этой самой 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ообщить модератору

31. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 03-Окт-09, 12:21 
(сорри, цитировать не буду, т.к. иначе получится ещё запутаннее)

Менеджер пакетов — такой же софт, как и всё остальное. Периодически появляется необходимость что-то дорабатывать, переделывать.

Изначальный вопрос («на хрена?») был за вами, что ж вы его по-прежнему мне задаёте, а не разработчику? Он не скрывается, контакты доступны, даже, кажется, в этом обсуждении участвовал (Андрей). Боитесь ответа? :)

И почему вы вообще решили, что скорость разработки обязательно будет ухудшать качество? Я уже приводил пример, когда переход с 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. извиняюсь за несколько злой пост, для програмеров советую рассматривать это как
>всего лишь взгляд тестера на программы. Тогда будет понятно чего я
>злой.

Да понимаю, понимаю. Сам когда-то так же думал, чего греха таить. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от User294 (ok) on 03-Окт-09, 21:15 
>Менеджер пакетов — такой же софт, как и всё остальное. Периодически появляется
>необходимость что-то дорабатывать, переделывать.

Это системный софт, делаемый 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 или просто фоновыми сканами с хоста (у которого утилсы свои, не протрояненые и хаксору вообще невидимые) пропалится быстренько (если админу оно было надо и он озадачился этим).

>Да понимаю, понимаю. Сам когда-то так же думал, чего греха таить. :)

Я могу понять юзеж перла для веб-приложений на мощных серверах. Но для пакетных манагеров... гхм. Они работают не только на мощных серверах! Я попробовал показать вам некоторые промашки в вашей логике. Получилось едко но я старался чтобы еще и конструктив присутствовал.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 03-Окт-09, 21:49 
(Много фигни 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ообщить модератору

34. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 03-Окт-09, 22:31 
(сорри, забыл ответить)

>>Я уже приводил пример, когда переход с C на Perl в аналогичной ситуации
>
>Ваш пример был установщиком пакетов? Он работал на low resource платформах?

Да, это установщик пакетов. Работает на low-resource платформах. Код здесь: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/pkg_add/

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от kost BebiX email on 29-Сен-09, 10:28 
>Зато в yum редхат оттянулся, сделав этот крап на питоне. В итоге
>мало того что он тормозной что пипец, так еще и жирные
>пакеты с кучей зависимостей на low resource машинах (128 мегов RAM,
>etc - виртуалки там, etc) оно вообще поставить не может.Этому гумну
>памяти видите ли не хватает - во новости! Да, блин, теперь
>128 мегов (без иксов и с почти нифига в системе, где
>полтора процесса вообще) - оказывается ... мало! Дебиянщики туда же, будут
>городить тормозных прожорливых монстров на перле?

Yum стал лучше в федоре 12й, попробуйте (а плагин presto - это счастье для пользователей медленного интернета).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от Tav on 29-Сен-09, 12:41 
> Yum стал лучше в федоре 12й

А в 11 чем был плох? И presto там есть (если установить yum-presto).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от kost BebiX email on 29-Сен-09, 13:00 
>> Yum стал лучше в федоре 12й
>
>А в 11 чем был плох? И presto там есть (если установить
>yum-presto).

Нет, мне йум всяко нравится и сейчас, но в 12й федоре стал быстрее заметно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от Slavaz (ok) on 29-Сен-09, 13:35 
>Нет, мне йум всяко нравится и сейчас, но в 12й федоре стал
>быстрее заметно.

Неплохо. Он и в 11-й не медленный, а тут.. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от Oleole on 25-Сен-09, 16:46 
а почему нельзя просто доработать мажорную версию АРТ? АРТ совсем помер уже что ли?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от Zenitur email on 25-Сен-09, 16:48 
Наверное, это создаст изменения, сильно меняющие APT.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Представлена бета-версия Cupt, проекта продолжающего развити..."  –1 +/
Сообщение от Zenitur email on 25-Сен-09, 16:47 
Проблемы с архитектурой и реализацией - это какие? У меня не хватает мозга понять, видимо, это что-то маленькое но в итоге обидное.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +/
Сообщение от Андрей email(??) on 25-Сен-09, 16:59 
Это проблемы мешающие добавлять новые фичи и исправлять ошибки без приведения кода в помойку.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Представлена бета-версия Cupt, проекта продолжающего развити..."  +1 +/
Сообщение от Аноним (??) on 25-Сен-09, 17:22 
> Это проблемы мешающие добавлять новые фичи и исправлять ошибки без приведения кода в помойку.

а можно пример конкретный, а то одни слова что тут что на вики...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Представлена бета-версия Cupt, проекта продолжающего развити..."  –1 +/
Сообщение от Андрей email(??) on 26-Сен-09, 00:12 
Например, в этом баге намек на сложность его исправления. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542767
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Представлена бета-версия Cupt - проекта, продолжающего разви..."  +1 +/
Сообщение от Аноним (??) on 25-Сен-09, 21:54 
>написанной на языке Perl

Спасибо, не надо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Представлена бета-версия Cupt - проекта, продолжающего разви..."  +/
Сообщение от gogo on 26-Сен-09, 23:24 
А кто загрузит и поставит перл, если сделана минимальная инсталляция оси?.. Ручками?
Зачем нужен менеджер пакетов, который сам зависит от десятков пакетов?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Представлена бета-версия Cupt - проекта, продолжающего разви..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 26-Сен-09, 23:30 
>А кто загрузит и поставит перл, если сделана минимальная инсталляция оси?.. Ручками?
>
>Зачем нужен менеджер пакетов, который сам зависит от десятков пакетов?

Либо это инсталляция на нормальный комп и поставить Perl — не проблема, либо это что-то типа встраиваемых систем, но тогда что там забыл менеджер пакетов? :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Представлена бета-версия Cupt - проекта, продолжающего разви..."  +/
Сообщение от yurror on 28-Сен-09, 12:51 
OpenWRT. что там забыл менеджер пакетов? О_о
зачем сразу так категорично?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Представлена бета-версия Cupt - проекта, продолжающего разви..."  +/
Сообщение от User294 (ok) on 29-Сен-09, 06:20 
Угу, а nokia Nxx0 или OpenWRT блаародный дон конечно не видел. Ну да, конечно, если делать по технологиям 80-х то конечно, можно и вовсе в ROM с ультрафиолетовым стиранием все шить.Только некрофилов знаете ли немного потому что гибкие и обновляемые решения нужны всем. Для начала - очень много добра работает с сетями. В частности обе упомянутых железки. И это означает что однажды они не будучи апдейтабельными попросту станут вкусными маленькими ботами. А миллиард комаров как известно поднимает в воздух слона. Не говоря о том что миллион роутеров начавших синхронно флудить вокруг - уронит все что роняется. Вы все еще считаете что манагеры пакетов блажь?Зря, 80-е закончились, 90-е прошли. И реалии нынче другие - орава хакерья ищет дыры везде, ради наживы на спаме и ддосах на конкурента.Так что по старинке уже во многих случаях не выйдет, реалии не те...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру