Комментарии 24
«Развод в стиле gentoo» — как будто дженту кого-то разводила и подала пример…
+2
Пересборка для 64бит какой-то смысл имеет?
Я читал что так как 64бит довольно новое дело, все оптимизации уже включены (не надо как на 32бит ориентироватся на сборку которая даже на старейших проц будет работать)
Я читал что так как 64бит довольно новое дело, все оптимизации уже включены (не надо как на 32бит ориентироватся на сборку которая даже на старейших проц будет работать)
0
Буквально на днях тоже попробовал apt-build.
Плюсы:
— необнаружены.
Минусы:
— нужно залезть в readme, подглядеть там адскую строку которая выгребает установленные пакет, это в итоге будет «мир»
— руками из файла в который все это дело поместили нужно удалить «некоторые» пакеты, конкретно указан только GCC
— в той же генте при пересбоке можно указать use-флаги, в бубунте же пакет тупо пересоберется
— у меня при каждом обновлении мира стягивалось несколько «необходимых» пакетов и каждый раз мне потом предлагалось их удалить за ненадобностью
Вобщем реального смысла для себя в пересборке пакетов на убунте не нашел.
Плюсы:
— необнаружены.
Минусы:
— нужно залезть в readme, подглядеть там адскую строку которая выгребает установленные пакет, это в итоге будет «мир»
— руками из файла в который все это дело поместили нужно удалить «некоторые» пакеты, конкретно указан только GCC
— в той же генте при пересбоке можно указать use-флаги, в бубунте же пакет тупо пересоберется
— у меня при каждом обновлении мира стягивалось несколько «необходимых» пакетов и каждый раз мне потом предлагалось их удалить за ненадобностью
Вобщем реального смысла для себя в пересборке пакетов на убунте не нашел.
+2
Хмм, может они исправят это когда-нить.
Кстати, возникла интересная идея. Подсчитывать, какие бинарики используются юзером чаще и во время простоя машины пересобирать их с оптимизацией под его машину.
Естесственно должна быть возмодность, чтобы юзер вручную указывал, что пересобирать. Я бы пересобрал всё даже если б пересборка длилась две недели. Главное, что не в ручную, а юзер-френдли — т.е. мне не нужно разбираться, ОС сама ускоряется.
Кстати, а кто-нибудь знает, информация о том, с какими флагами оптимальней всего собирать бинарики, может быть получена автоматом?
Кстати, возникла интересная идея. Подсчитывать, какие бинарики используются юзером чаще и во время простоя машины пересобирать их с оптимизацией под его машину.
Естесственно должна быть возмодность, чтобы юзер вручную указывал, что пересобирать. Я бы пересобрал всё даже если б пересборка длилась две недели. Главное, что не в ручную, а юзер-френдли — т.е. мне не нужно разбираться, ОС сама ускоряется.
Кстати, а кто-нибудь знает, информация о том, с какими флагами оптимальней всего собирать бинарики, может быть получена автоматом?
0
В FreeBSD пересборка установленных пакетов из исходников/портов с учётом флагов оптимизации в make.conf:
% portupgrade -ap
(флаг "-a" — пересобирать все установленные пакеты; флаг "-p" указывает на создание бинарного пакета в отдельном каталоге для дальнейшей дистрибуции-передаче другим лицам).
На работающей машине с двухъядерным процем вполне терпимо, приложения переднего плана не тормозят, проигрывание MP3 не заикается, можно смотреть видео DivX — общая загрузка CPU порядка 90%. Пересборкой в основном занимается одно ядро.
% portupgrade -ap
(флаг "-a" — пересобирать все установленные пакеты; флаг "-p" указывает на создание бинарного пакета в отдельном каталоге для дальнейшей дистрибуции-передаче другим лицам).
На работающей машине с двухъядерным процем вполне терпимо, приложения переднего плана не тормозят, проигрывание MP3 не заикается, можно смотреть видео DivX — общая загрузка CPU порядка 90%. Пересборкой в основном занимается одно ядро.
0
И ещё. Типичный десктоп с мультимедийными приложениями и без OpenOffice можно пересобрать в автоматическом режиме за шесть-семь часов из заранее подготовленных исходников. Сборка OOo3.1 длится порядка шести-восьми часов на среднем по характеристикам CPU.
0
У меня сейчас манов под рукой нету, но, кажется, суть в том, что оно использует gcc не напрямую, а через свою обёртку, которая выставляет правильно все параметры.
0
Зато самовнушение :)
+1
на https://launchpad.net/ уже знают о проблеме?
не думаю что хорошо забивать на проблему изобретая костыли
не думаю что хорошо забивать на проблему изобретая костыли
0
Без паники!
Q: gcc and g++ do not seem to be called with good options!
A: *** They are called with them! ***
What you see on your screen is the command called by make, but
the wrapper wraps (yeah, it does) calls to gcc/g++ and adds options you
specified in the apt-build configuration file.
You won't see this on your screen.
Try `ps ax | grep gcc' instead as a proof, while building.
Q: gcc and g++ do not seem to be called with good options!
A: *** They are called with them! ***
What you see on your screen is the command called by make, but
the wrapper wraps (yeah, it does) calls to gcc/g++ and adds options you
specified in the apt-build configuration file.
You won't see this on your screen.
Try `ps ax | grep gcc' instead as a proof, while building.
+4
Хочу поинтересоваться. Когда я ставлю программу из репозитария, она уже кем то скомпилированна под все возможное железо, в итоге теряем производительность. А если я сам скомпилирую, то значит она будет работать хорошо быстрее? Тогда вопрос, почему бы не сделать отдельный репозитарий для всех моделей EeePc, они и так еле крутят эту убунту. Хотя бы какой нить не официальный домашний ;)
0
Одним железом оптимизация обычно не ограничивается.
Во-первых, есть оптимизация, которая влияет на стабильность системы: например, кто-то считает, что уровень -O2 недостаточно стабилен, а некоторые ставят -O3 и не обращают внимание на редкие сегфолты.
Во-вторых, есть оптимизация по использованию других библиотек: например, нет смысла собирать многие пакеты с поддержкой Gnome, если сам гном вы ставить не собираетесь.
Вывод: одним репозиторием вы вряд ли обойдетесь, проще выпускать готовые live-образы той же Gentoo.
Во-первых, есть оптимизация, которая влияет на стабильность системы: например, кто-то считает, что уровень -O2 недостаточно стабилен, а некоторые ставят -O3 и не обращают внимание на редкие сегфолты.
Во-вторых, есть оптимизация по использованию других библиотек: например, нет смысла собирать многие пакеты с поддержкой Gnome, если сам гном вы ставить не собираетесь.
Вывод: одним репозиторием вы вряд ли обойдетесь, проще выпускать готовые live-образы той же Gentoo.
+1
Скучно с Убунтой?
Поставь Генту!
;)
Поставь Генту!
;)
+3
Всё там нормально! Я помнб вдоль и поперёк его исходники облазил — тоже сомневался. Он использует свой собственный враппер при компиляции и естественно ничего не выводит на монитор. Достаточно заглянуть в config.c и вы поймёте своё заблуждение.
+1
читал в разных местах что нужно выставить в /etc/apt/preferences
Package: *
Pin: release o=apt-build
Pin-Priority: 990
чтобы собранные пакеты не заменялись из репозитария.
но apt-cache policy всё равно говорит, что приоритет у репозитария apt-build — 500.
что не так делаю?
может кто сталкивался с таким вопросом?
Package: *
Pin: release o=apt-build
Pin-Priority: 990
чтобы собранные пакеты не заменялись из репозитария.
но apt-cache policy всё равно говорит, что приоритет у репозитария apt-build — 500.
что не так делаю?
может кто сталкивался с таким вопросом?
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Аpt-build. Неработающая оптимизация.