>Менеджер пакетов — такой же софт, как и всё остальное. Периодически появляется
>необходимость что-то дорабатывать, переделывать. Это системный софт, делаемый 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 или просто фоновыми сканами с хоста (у которого утилсы свои, не протрояненые и хаксору вообще невидимые) пропалится быстренько (если админу оно было надо и он озадачился этим).
>Да понимаю, понимаю. Сам когда-то так же думал, чего греха таить. :)
Я могу понять юзеж перла для веб-приложений на мощных серверах. Но для пакетных манагеров... гхм. Они работают не только на мощных серверах! Я попробовал показать вам некоторые промашки в вашей логике. Получилось едко но я старался чтобы еще и конструктив присутствовал.
Вариант для распечатки
Разговоры, обсуждение новостей (Public)
on 25-Сен-09, 16:25 
