Emerge vs. RPM

Added by jone j 21 days ago

Вот почему emerge по сравнению с rpm так долго просчитывает зависимости?
Точнее, почему каждый раз заново? Включение cache.sqlite.database не дает ни малейшего прироста производительности. Выходит разработчик Paludis был прав, говоря что portage/emerge это "лапша из процедурного быдлокода на bash и python"?


Replies (31)

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 19 days ago

возможно для кодера с точки зрения чистоты кода и так ,но,есть моментик с которым друие пакетманагеры включая РПМ не сталкиваются, отрабатывая каждый раз,ибо основаны на системе бинарных репов с медленно меняющимися списком ,а не сырцовых ..,ситуация актуальности версий пакетов и их депенденсов,заметьте не только прямых(как делается в РПМ и других иже с ним),но и обратных, входящих в набор на конкретной машине,может меняться по нескольку раз за сутки,и что,всё это держать в синхроне рилтайм? гораздо проще,и логичнее сделать просчёт как раз тогда когда он и необходим т.е. по получении команды на обновление или синхронизацию...,да и скорость просчёта на самом деле не настолько актуальна,учитывая частоту запросов на обновки на среднестатистической машине...сдаётся мне что Вы пытаетесь сравнивать мягкое с горячим,другими словами несколько некорректное сравнение...ни на что не претендую,просто ИМХО
P.S. ну и кроме того и этот момент,впрочем как почти всё в генте тоже можно регулировать в определённых пределах задавая портэжу/эмежу глубину просчётов прямых и обратных зависимостей,механизм есть и он работает,и даже частенько может помочь с решением циклических блкировок автоматизировав львиную долю ручного "разруливания " и,насколько помню,в кальке глубина по дефолту весьма большая,что значительно облегчает жизнь неподготовленным пользователям,кстати...
P.P.S. стоит внимательно почитать ман портежа и выяснить как и когда стоит увеличивать глубину,когда можно уменьшить или вовсе отключить просчёт обратных депенденсов уменьшив соответственно и время затрачиваемое на просчёт...

RE: Emerge vs. RPM - Added by jone j 19 days ago

ситуация актуальности версий пакетов и их депенденсов,заметьте не только прямых(как делается в РПМ и других иже с ним),но и обратных, входящих в набор на конкретной машине,может меняться по нескольку раз за сутки [...] гораздо проще,и логичнее сделать просчёт как раз тогда когда он и необходим т.е. по получении команды на обновление или синхронизацию...

.. или на удаление, или на установку, то есть на любой чих. Так действительно проще? Или все-таки проще каким-то образом кэшировать уже рассчитанное дерево зависимостей и пересчитывать его только тогда, когда это действительно необходимо (при обновлении @world)? А ведь у нас еще и сет @custom, к обновлению пакетов из которого могут быть совсем другие требования..
--
Я конечно разбираюсь и мануалы тоже читаю, но почему-то ни одном мануале мне никогда не попадались разборы концептуальных вопросов. Да и странно было бы ожидать подобного от короткой сопроводительной инструкции (которой мануал и является). Как и странно ожидать от новичка, что он сразу во все въедет))

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 18 days ago

сразу во всё вьехать это наврядли конечно ) ,попробуйте в консоли наберите man emerge и гдето в районе 1235 строки весьма подробно развернутых описаний функций этой утилиты обнаружите раздел bactracing это как раз о глубине просчёта прямых и главное обратных зависимостей с УЧЁТОМ юз-флагов, и примерно такие же маны по всем утилитам входящим в сам портэж и по нему самому и всё прямо у Вас в машине,не в сети... ну и есть ещё хендбук где основное,и не только,показано на примерах использования...новичкам переходящим в генту-базед из других линукс-платформ не сталкивавшихся с таким понятием вовсе это вызывает главные трудности и непонимания...если бы Вы занимались разработкой софта или хотябы попробовали упаковать пакет для красношляпы или дэбы то уже имели бы представление о юзах (то биш,ключах компиллятора по сути,задающих вариант сборки бинарного пакета из сорцов задающих наличие и поддержку в конечном бинарнике тех или иных функций)...если более доступно,то весь функционал конкретного пакета или его часть будет представлена в конечном бинарнике решает разраб или майнтэйнер,размещающий и ведущий поддержку пакета в репозитории,а конечный пользователь "кушает что ему дали", так обстоит дело в бинарных репозиториях основных платформ и их клонов,а вот в генту всё иначе,как в бсд, и что включить/выключить из доступных вариантов функционала пакета решает юзер,исходя из своих соображений или требований,отсюда возникает весьма сложная головоломка из основных пакетов и зависимых от них других пакетов и библиотек,ведь если включить в пакете один из двух взаимоисключающих ключей (например +gtk?-qt) то потребуются
один из двух наборов зависимостей ... а так как зависить от одной либы могут несколько независимых пакетов то и производится весь просчёт и при установке и при удалении и при обновлении и при смене юз-флага для какого либо одного пакета,чтобы ничего случайно не было из системы выкинуто нужного какому либо приложению(а это уже обратная зависимость),и рассчёты на самом деле весьма сложные,и если в систему привносится что либо в обход пакетного менеджера (в данном случае портежа) то поломка всего дерева будет гарантирована ,а последствия могут быть самыми разными от мелких глюков гуя до полного краха системы...генту и всё что на её базе славится высокой скоростью работы,стабильностью при марафонских аптаймах,и возможностью тончайшей настройки всего и вся под конкретное железо и требования,за это пришлось заплатить сложностью иерархии зависимостей и жёстким контролем целостности этой иерархии в конечной системе пользователя... вот поэтому и ,ДА,проще каждый раз проверять и перепроверять перед какими либо действиями( "семь раз отмерь-один раз отреж",или такой подход не верен по Вашему),чем содержать отдельную систему отслеживания и архивирования всех изменений ошибки в которой будут неизбежно возникать и накапливаться с течением времени и приведут к невозможности функционирования... это конечно не полно и не абсолютно точно я тут описал,а весьма популяризованно, но думаю понять поможет почему сделано всё так как сделано,и как это всё работает в общих чертах и главное что даёт в первую очередь, ведь профит при таком подходе намного превышает мелкое неудобство связанное с ожиданием подсчёта перед внесением изменений в состав системы...а вникнуть дальше самому,человеку грамотному и не ленивому умом,не составит большого труда

RE: Emerge vs. RPM - Added by jone j 18 days ago

Я продрался через ваш ответ :) Да, тут много всего, но давайте на простом примере - как работает Calculate Console - Обновление системы.
1. Есть сертификат с паролем (задал для теста).
2. По крону запускается emerge -uDN -pv @world или что-то подобное.
3. Рассчитывает, есть обновления => значок в трее, клик по значку, и.. что происходит дальше? А дальше ввод пароля и снова запуск того же расчета зависимостей, т. к. предыдущий прогон был практически вхолостую.
Понятно, что это Gentoo тут как бы и не причем, так и дистрибутив тоже не Gentoo)) Это вовсе не кажется разумным!
Может и частный случай, но не единственный..

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 17 days ago

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

RE: Emerge vs. RPM - Added by jone j 17 days ago

В фоне? ;) Этот "фоновый" процесс полностью отжирает одно ядро процессора! Вот компиляцию я настроил действительно в фоне, идет она долго (webkitgtk собирался больше 4х часов), зато действительно незаметно.

дебри из версий и юзов всё таки дебри и портэжу приходится через них продираться

У меня сейчас около 1000 пакетов в системе, ну пусть на каждый будет по 10 use-флагов - это много для расчета? Ну блин, не на калькуляторе же считается))

но претензии по его несовершенству или непонятности почему именно так, а не просто,это уже к дэвам генты )))

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

RE: Emerge vs. RPM - Added by Alexander Tratsevskiy 17 days ago

Есть разные варианты кэширования просчитанного обновления. Если "заморозить" просчитанные портежами зависимости, то они будут нагружать память пока пользователь не согласиться установить обновление. Поэтому такой вариант даже не рассматривался. Какое-то время было реализовано кэширование с сохранением лога просчёта зависимостей с последующей установкой попакетно уже без просчёта. Но в этом случае может быть некорректное замещение версий пакетов из слотов. Поэтому в случае если версии пакетов удалялись зависимости просчитывались по новой. К релизу 17.6 планировали включить новый механизм просчёта, но не успели. Идея заключается в следующем. Состояние наличия обновлений будут определять утилиты сравнивая текущие версии пакетов. Для этого не понадобится скачивать портежи и просчитывать зависимости, это будет выполняться пользователем при запуске обновления. Изменённые пользователем маски пакетов будут запоминаться чтобы не происходило лжесрабатывание.
Так же можно снизить трафик опционально перестав выкачивать все портежи. Это так же даст небольшой прирост в просчете зависимостей, но ценой перехода на использование только бинарных пакетов.

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 17 days ago

Александр,а если таки организовать, как я предлагал как то,только с учётом уже особенностей структуры оверлеев,..пусть в оверлее кальки и системе будет некий "нулевой пакет" в котором будет только инфа по наличию обновления(дате обновки) ,ну,в качестве маркера,и утилиты с машины пользователя будут обращаться только к нему,для проверки обновок,а уже при наличии обновок в ГЛАВНОМ оверлее кальки включится уже всё как сейчас...сильно сдаётся что подавляющее большинство текущих пользователей кальки ничего не меняют и оставляют дефолт,над этим ты с командой хорошо поработали и менять незачем по большому счёту...если это принять за точку отправления то этот пакетик будет маркером для утилит ,не более,но позволит,и уменьшить траффик,и исключит известные по багрепортам варианты когда просчёт переходит в бесконечный цикл и грузит машину до оверхед(наверняка помниш как с этим боролись,кста не слишком успешно,и сейчас зависоны не исключены,столкнулся на днях,благо помню как победить... :) ...старую мыслю оформил по новому не более )))

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 17 days ago

з.ы. подозреваю что одним пакетиком не отскочить так как профилей систем не счесть,но,таки,решаемо...и кол-во не будет запредельным жеш...

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 17 days ago

а кто запрещает? ))) а если удачно прикрутить получится думаю и разрабы против не будут если хауту выложите ) давайте вместе всем миром улучшать то,что уже неплохо состряпано... а разрабы НАШЕЙ Кальки люди открытые для свежих идей,знаю не по наслышке,общался вживую,могу судить о таком...

RE: Emerge vs. RPM - Added by Alexander Tratsevskiy 15 days ago

Нулевой пакет не нужен. Информация о состоянии репозиториев, времени обновления и так хранится в ini.env файле.

RE: Emerge vs. RPM - Added by Pavel Zhukov 15 days ago

Александр, а вы знакомы с проектом рефакторинга portage - pkgcore?

Я его попробовал. Конечно ещё не готов, но на моей системе задачу emerge -uDN @world отрабатывает корректно. Причём просчёт зависимостей pmerge выполняет секунд за 10 (i3-2120), в то время как emerge работает около 3 минут! И использует все ядра при этом параллельно.
Всё дело в эффективном алгоритме обработки дерева билд-файлов. И язык программирования здесь не является узким местом - Python вполне справляется с этой задачей.
Один из главных пожирателей CPU в Portage при просчёте зависимостей - парсинг bash-кода билд-файлов, причём в один поток. И в Pkgcore на это уделено специальное внимание - там для разбора билд-файлов используется не запуск bash, а специальная библиотека snakeoil.
Команда pkgcore отличные цели поставила:
  • сохранить формат билд-файлов
  • обеспечить прозрачную полную совместимость с gentoo/Portage, в том числе и с конфигами Portage
  • добавить поддержку альтернативных форматов конфигов

Мне кажется, что цели pkgcore гораздо правильнее чем в paludis - переработать существующий инструмент вместо изобретения несовместимого своего.
Так и подмывает предложить Вам подключиться к проекту Pkgcore и внедрить его в Calculate!

RE: Emerge vs. RPM - Added by jone j 14 days ago

Что-то мне подсказывает, что комментариев от господ разработчиков мы не дождемся :)

Мне кажется, что цели pkgcore гораздо правильнее чем в paludis - переработать существующий инструмент вместо изобретения несовместимого своего.

Тут согласен. Причем стоит наверно добавить, что Paludis - это вовсе не единственное в своем роде решение, другие gentoo-based дистрибутивы создают свои инструменты в борьбе с кривизной Portage (Entropy в Sabayon например). Так что в отношении Calculate это вопрос ресурсов* и наличия разработчиков, которые могут кодить еще и на C/C++, а не только на Python))
[*] вы где-нибудь видели, чтобы Бизнес стремился к идеалу? Хоть как-то работает - и б-г с ним :)

RE: Emerge vs. RPM - Added by Pavel Zhukov 14 days ago

Не понимаю, при чем тут умение программировать на C/C++ ?

и наличия разработчиков, которые могут кодить еще и на C/C++, а не только на Python

Тот же Paludis написан на C++, а ни разу не быстрее, чем Portage.
Детские отговорки про Python и про сложную задачу просчёта зависимостей не принимаются.
Сама задача вычислительно по силам для современных процессоров. Тут проблема в грамотном алгоритме.
А вот решение с кэшированием зависимостей я считаю неоправданно громоздким и хрупким. Ведь в системе и так уже всё есть - база установленных пакетов, дерево билд-файлов, конфиги менеджера пакетов. Причём объём всего этого по современным меркам невелик - не более 10^7 узлов-записей.
Надо только научиться всё это быстро обрабатывать.

вы где-нибудь видели, чтобы Бизнес стремился к идеалу?

А бизнесу от прочистки тормозов Portage и выгода может получиться.
У нас вот, в организации, возможно и применили Calculate вместо Debian/Ubuntu, может даже поддержку у разработчиков купили бы.
Но вот попробовали... и сразу наткнулись на две детские проблемы:
  1. Оказалось невозможно инсталлировать Calculate в изолированной сети с закрытым git
  2. Очень (!) долго для binary-дистрибутива считаются зависимости. Само обновление зачастую происходит быстрее, чем вычисление списка обновляемых пакетов.

И вот, замечательные потенциальные возможности продукта оказались незамеченными!
Так что бизнесу тоже выгодно улучшать свой продукт.
Надо только найти способ монетизации своих усилий.
Вот, например, ребята на рефакторинг Vim (Neovim) нашли ресурсы!
И здесь можно придумать, например такую схему. Какая-то команда, скажем Calculate, под свои гарантии, организует краудфандинговую компанию, подключается к вменяемому проекту, например - Pkgcore, и совместными усилиями проект доводится до ума. И всем - польза.

RE: Emerge vs. RPM - Added by Alexander Tratsevskiy 14 days ago

CL не продаём, платную поддержку не оказываем, планов по грандиозному внедрению не ставим, акцент ведём в первую очередь на свои задачи, благо они у большинства компаний совпадают.

Для установки системы интернет не нужен. Вы можете подготовить образ с необходимым набором ПО и установить. Делается это прямо на флешке. При желании на ней же можно создать несколько вариантов установки.

Не знаю в какой момент вы тестировали, но определённые тормоза в просчёте зависимостей были убраны. Например раньше при каждом выполнении emerge было обращение к зеркалу и скачивание файла Packages (сейчас он весит 11 Мб). Emerge пытается определить по заголовку что файл не изменился но делает это не всегда эффективно и работает к тому же только с http. При проблемах с интернетом и вовсе могли появляться длительные задержки. Сейчас скачивается архив Packages (1,3 Мб) и только один раз вместе с обновлением портежей.

Pkgcore посмотрим.

RE: Emerge vs. RPM - Added by jone j 13 days ago

Pavel Zhukov wrote:

Детские отговорки про Python и про сложную задачу просчёта зависимостей не принимаются.

Это не детские оговорки, увы, за примерами дальше этого дистрибутива и ходить не нужно. Для какой-то своей ниши оно может и неплохо, но когда на нем начинают клепать системные инструменты, то гарантированно начинается лажа проблемы.
Честно говоря начинаю жалеть, что выбрал Calculate для знакомства с gentoo-based, тут ни форума толкового нет, ни документации человеческой (например, про шаблоны никакого намека на howto в принципе не существует).. нет ничего хорошего, кроме репо с бинарными пакетами.

RE: Emerge vs. RPM - Added by Alexander Tratsevskiy 11 days ago

(например, про шаблоны никакого намека на howto в принципе не существует)

http://www.calculate-linux.org/projects/ru/boards/47

RE: Emerge vs. RPM - Added by Pavel Zhukov 11 days ago

Про Python.

Для какой-то своей ниши оно может и неплохо, но когда на нем начинают клепать системные инструменты, то гарантированно начинается лажа проблемы.

Мне кажется, что это опрометчивое высказывание. У меня есть примеры отличных инструментов как на Python, так и на C/C++, причём в разных областях, а также и совершенно негодных, написанных на разных языках. И использование какого-то конкретного языка программирования ничего не говорит о квалификации разработчика. Мало того, сейчас часто системы разрабатывают на смеси нескольких языков по вполне обоснованным причинам.

Про Calculate.

... нет ничего хорошего, кроме репо с бинарными пакетами.

Это неправда.
Есть ещё предсказуемая и надёжная операционка с возможностью гибкого выбора.
Есть аккуратно реализованная совместимость с Gentoo, а значит - возможность взаимопроникновения знаний между этими дистрибутивами.
Есть налаженная схема сборки своих коллекций бинарных пакетов (а значит можно Gentoo/Calculate использовать на медленных/старых машинах без компиляции).
Есть удобный способ заворачивать любой софт в пакеты (хотя это заслуга Gentoo). Попробуйте сделать такое грамотно в Debian/Ubuntu - сам на работе профессионально вынужден этим заниматься - это ж кошмар кошмарный - вот где действительная лажа!

На мой взгляд, Calculate - это замечательный проект с правильными целями.
Вообще, задача сделать и постоянно поддерживать в тонусе дистрибутив-экосистему - огромна.
А здесь я вижу классный результат! Вы же не думаете, что все, кто пользуется дистрибутивом - сумасшедшие, которые насильно себя истязают, а потом рассказывают всем сказки, как им хорошо страдать в Calculate?!
Причём, ведь разработка Calculate, насколько я понял, ведётся в интересах конкретного (не ИТ) производства, и поэтому откровенную туфту ребятам сделать не дадут.

Да. Кальке есть ещё к чему стремиться, но уже сейчас ею приятно пользоваться. Мне, например, гораздо приятнее, чем Debian, Ubuntu или Arch. В Gentoo/Calculate как-то всё удобно на своих местах расположено.
И, как правило, как написано в документации, так и работает. Бывают конечно мелкие косячки. Но разрешимые достаточно легко.

По сути, Calculate - это Gentoo с уменьшенными затратами на сборку пакетов и некоторыми принятыми по умолчанию безопасными решениями (которые, кстати, пользователь может спокойно, без геморроя, как в binary-дистрибутивах, изменить).
Можно сказать, что Gentoo очень неплохо звучит в исполнении Calculate!
Отсюда вывод, что надо пользоваться документацией Gentoo и понимать, какие нерешённые (или недорешённые) задачи Gentoo и как решают дополнительные инструменты Calculate.
Поэтому неплохо сначала пощупать Gentoo, а потом Calculate.

А так, да, трудно пока оставаться в рамках исключительно экосистемы Calculate.
Я вот, например, рассматриваю для себя Calculate, как бинарный профиль Gentoo, некий инструмент для генерации конкретных решений. Может быть это и есть правильное и важное место для Calculate.

А вообще, чрезмерно эмоционировать - вредно для реального понимания проблемы.
Более того - бурное личное негодование - причина остановиться и осмотреться.
Гораздо полезнее внимательно поискать, что сам лично не понимаешь и поточнее поставить вопрос.

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 10 days ago

jone j wrote

Честно говоря начинаю жалеть, что выбрал Calculate для знакомства с gentoo-based, тут ни форума толкового нет, ни документации человеческой (например, про шаблоны никакого намека на howto в принципе не существует).. нет ничего хорошего, кроме репо с бинарными пакетами.

да...видимо надо было начать уже совсем с того что попроще?из семейства Gentoo,и оптимально будет пожалуй с ChromeOS/ChromiumOS,шутю,таки да,но не смейтесь,это тоже Gentoo-based дистрибутивы и гуглю не смущает всё то что вы к минусам приплели,вся мешанина из разных языков внутри системы и системных пакетов...настраиваемость отдельных компонентов как и адаптивность системы в целом,совместимость с гигантской базой,быстрота работы,стабильность независимость системы от "прогрессивных"разработок интегрированных в другие базы практически насильно,интегрируемость с сетевыми технологиями и т.д и т.п,как раз то,что,судя по всему,вызывает у Вас ступор,привлекло и помогло сделать систему и с успехом распространять предустановленно на простых машинках...а "Калька"идёт своим путём,сделанная изначально для конкретных нужд и казалось бы узконаправленной,позволяет применение в весьма широком спектре от хоуммалтимедиа и гейммашин до центра управления станками чпу,практически в дефолтном состоянии...ну и напоследок я запамятовал название ,но гугл Вам поможет,есть такой гибридный дистр вроде генту но построенный на рпм а не портэже,вот Вам подошёл бы,и вопрос отпал бы сам собой... а по большому счёту,RPM vs PORTAGE,ответ прост- RPM в анусе по любасу,ибо сам по себе вовсе не умеет зависимости решать и автоматом ставить,это за него делают надстройки типа YUM и прочие,в разных дистрах на базе рпм... так что вопрос то Ваш изначально ниочём...и таки подучите уже матчасть,походу Вы и того чем пользуетесь глубоко не осмысливали...отсюда у Вас и вопрос такой возник"почему рпм просчитывает зависимости быстрее портэжа" да потому что он их и не считает,а получает из репо список файлов необходимых в системе для работы того или иного пакета и выводит его в консоль,список файлов,Карл!,не пакетов заметьте, а только файлов... а дальше уже не RPM-a дело что с этим списком делать, этим надстройка-оболочка занимается тот же YUM,хотябы, самый вменяемый в плане сохранения зависимостей или другой какой,не такой строгий...

RE: Emerge vs. RPM - Added by jone j 10 days ago

А вообще, чрезмерно эмоционировать - вредно для реального понимания проблемы.
Более того - бурное личное негодование - причина остановиться и осмотреться.
Гораздо полезнее внимательно поискать, что сам лично не понимаешь и поточнее поставить вопрос.

Прошу заметить, это будет оффтопик в теме "Emerge vs. RPM", но да, я не понимаю:
1. почему в процессе установки у меня 3 раза подряд упал инсталлер (за 6 лет работы исключительно с linux никогда такого не видел),
2. почему пришлось целиком переразмечать диск MBR->GPT и возится с бекапом /home, чтобы таки появилась возможность довести процесс установки до конца (user-friendly говорите?),
3. почему cl-update-gui жрет процессор в режиме ожидания ответа, уже после просчета зависимостей (конечно python тут не причем, несмотря на вывод htop),
...
и это только начало списка. Дальше можно про старую документацию, про реальные провалы в документации (ага, такая calculate-специфичная вещь как шаблоны), и т. д.
С этим, господа, можно мириться, поскольку у дистрибутива однозначно есть свои плюсы, например грамотно собранные бинарные пакеты с адекватными зависимостями (но не все конечно, это было бы слишком хорошо), но закрывать на все прочее глаза.. так будет слишком по-русски :) Собственно, Calculate и был выбран в основном из-за пиара в рунете, в стиле "Gentoo для обычного юзера". Ну я и говорю с позиции обычного юзера, а не как тестировщик бета версии - к бете был бы иной подход.

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 10 days ago

jone j wrote:
>> С этим, господа, можно мириться, поскольку у дистрибутива однозначно есть свои плюсы, но закрывать на это глаза.. это слишком по-русски :)
а кто Вам сказал что на это закрывают глаза ? команда разработчиков,на пальцах одной руки пересчитать,всего просто не могут успеть ,кто может из сообщества помочь ребятам сделать всё красиво и вовремя,помогают... критиковать видимо тренд нынешнего времени,причём просто ,без конструктива...есть идеи и предложения ? так делитесь,можете помочь-сделайте,как многие и делают и не жужжат что всё прям капут как нехорошо...вот как по русски,а не так как у Вас получается,слышал звон да не в курсе где он... и те "косяки" что Вы описываете большей частью давно преодолены и забыты,и например у меня, за семь лет использования кальки,падение инсталлера было только раз,и то не по вине дистра,а из-за специфики железки...знаете как когда то нас военрук на нвп отчитывал когда кто то чтото недогонял ?"ты один в ногу идёш а весь взвод не в ногу" вот у вас так и получается, у подавляющего большинства ВСЁ работает не падает не жрёт и доки адекватные и свежие чтобы разобраться, а Вам прям напасть,может стоит задуматься и взглянуть с другой стороны,возможно это Вы "замастерились" в других несорцовых дистрах и тут груз Ваших знаний начинает мешать,ибо он в архитектуре генту большей частью бесполезен,а уж на "невменяемый"форум наезд может сказать о Вас лиш одно,Вы ждали что вам разжуют и в рот положат(как на всяческих бунто-дэб и иже с ним форумах,где вам тупо пишут команду в терминал и остаётся только её вписать и ткнуть энтэр потому как у всех на машинах всё одинаково в пакетной каше),а тут Вас вдруг подумать/почитать послали с намёком или явным подтекстом о однобокости или малой глубине понимания проблемы(чтобы направить на правильные действия,чтобы уже само дошло что и как,так как причин и вариантов решения не одно и то что одному поможет у Вас просто не прокатит ,профили и юзы иные ) ,и что в итоге ? типичная реакция "я сам с усам" и неявная обида с ещё более нелепыми предьявами...как Вам и советовали выше, меньше эмоций,больше толка будет при спокойном мировосприятии...а гентушка вообще и калька в частности не любят суеты,нужно с чуством,с толком,с расстановкой,и неторопясь...и отложить на первое время весь багаж из бинарных дистров и опыта кодера, он мешает,проверено временем и огромным количеством людей...

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 10 days ago

jone j wrote:

2. почему пришлось целиком переразмечать диск MBR->GPT и возится с бекапом /home, чтобы таки появилась возможность довести процесс установки до конца (user-friendly говорите?),

вот этот вопрос показывает насколько неглубоки Ваши знания развития железа и софта, не смотря на шесть лет пользования линукс,Вы же полностью меняете при таком действии формат разметки диска и эти два формата ни разу не совместимы между собой...у Вас есть пример софтины которая не сделает полную переразметку разделов с форматированием при данной операции??? пруф в студию,даже интересно стало...
П.С. а если Вы задали установщику задачу установить уефи загрузку,но пытались подсунуть диск с мбр разметкой,или наоборот и он вам выдал вполне законное требование привести загрузку и разметку в соответствие ... тогда подите проштудируйте что вообще такое уефи загрузка и почему ему нужно обязательно гпт... походу Ваши знания и навыки так и остались в шести годах тому назад...

RE: Emerge vs. RPM - Added by jone j 10 days ago

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

Я умею только критиковать. И не умею писать на python..
--
Не хочу раздувать оффтопик, просто большинство дистрибутивов ставятся на уже существующую разметку (и им плевать, MBR там или GPT), а установщик Calculate так не может, вот и все.

RE: Emerge vs. RPM - Added by Aleksey Mikhaleff 10 days ago

jone j wrote:

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

Я умею только критиковать. И не умею писать на python..
--
Не хочу раздувать оффтопик, просто большинство дистрибутивов ставятся на уже существующую разметку (и им плевать, MBR там или GPT), а установщик Calculate так не может, вот и все.

да всё он умеет,и ставит на существующие разделы и в мбр и в гпт, и не хуже других установщиков,и даже прозрачней и аккуратней многих,и ему так же плевать куда ставиться,но не плевать когда пользователь хочет нереальную комбинацию...и две-три-четыре системы на один диск ему по зубам,и даже установить совершенно другой,"чужой",дистрибутив ,был бы исошник( что я лично проделывал уже неоднократно ставя людям по их просьбе бунты/минты федоры, прямо из лайва привычной кальки,и вот такой фичи точно ни в одном другом установщике не встречал никогда,ставят только "свой" дистр,с которого запущены,за исключенем пожалуй гайдзина,но он давно заброшен и неразвивается уже лет пять,да и не установщик ,а скорей универсальный загрузчик,не суть),а что имеет более глубокую "защиту от дурака" это да,присутствует,и заметьте именно это особенно полезно в ручном режиме ,как говорится и на старуху бывает проруха и новечёк может сунуться туда где не понимает всех буковок,а бывает и не новичёк,но тоже не понимает... а оффтопик Вы всё равно подняли,причём уже создав тему, с самого начала поставив некорректный вопрос,сравнивая ПМ с совершенно разными задачами и подходом к требованиям пресловутого "юзерфрендли" - автоматической установки любой программы(а это не единичный пакет обычно а целый набор из пакетов и либ)"одной кнопкой",которая в портеже,реализована в полной мере(пришло из БСД,а до прихода в линукс было завистью всех дэб и рпм линуксоводов ),и абсолютно отсутствует в рпм ,откуда и проистекает время обработки команд,за удобство надо платить,но если и это для Вас трудно в осмыслении, то может дело таки не в кривости дистра ? ;-)

RE: Emerge vs. RPM - Added by jone j 10 days ago

Да не буду я обсуждать вопросы установки в этой теме, резолюция по данному вопросу уже дана: NOTABUG.

1 2 Next » (1-25/31)

Thank you!