OpenRC ищет нового разработчика

>Ну ладно. В двух словах. Генту нужна лишь тем, кто любит наблюдать за загрузкой процессора. Иными словами - если нужна лёгкая и удобная компиляция и мельчайшее увеличение производительности - то пожалуйста, генту то что Вам нужно. Для всего остального Генту мало подходит.

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

> Ну ладно. В двух словах. Генту нужна лишь тем, кто любит наблюдать за загрузкой процессора. Иными словами - если нужна лёгкая и удобная компиляция и мельчайшее увеличение производительности - то пожалуйста, генту то что Вам нужно. Для всего остального Генту мало подходит.

Поскольку ты не понимаешь работы с генту, или просто наслушался лоро/лурко-троллей, то ты не можешь придумать зачем она нужна. Так и пиши. Не надо тут откровения писать, ты не Ванга, и твоё мнение никого не интересует, или не забудь отметить, что это твоё личное мнение. Или в крайнем случае если ты считаешь, что твое мнение должно быть хоть кому-то важно, то отметь причину этого мнения, хотя обычно такие люди в тролло темах не пишут или напишут 1-2 поста.

Разработчик понял это и с генту свалил, за что ему +1.

разработчик понял, что ему ВоВ важнее.

P.S. нашёлся уже человек, который собирается поддерживать openRC и отписался в соотв местах.

суть генты не в компиляции и не в увеличении производительности на 5%

суть в гибкости и отсутствии «прибитых гвоздями» зависимостей

хочешь так соберешь, хочешь по другому, нужен hal - пожалуйста, не нужен - ну и не надо, бесит mono ? ну и USE -mono

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

а то компиляция... прирост производительности....
отнюдь не это, просто удобно, толстые пакеты типа ООО есть и -bin

у гентушников вообще все детекторы атрофированы, , благодаря постоянному ощущению боли в руках, глазах и всем прочем теле из-за использования gentoo jmu/pinups :)

>а то компиляция... прирост производительности....

Как минимум производительность не на последнем месте. Просто все это связано и зависит друг от друга. Благодаря удобной системе установки, получается легкая система, следовательно быстрая.

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

Не стоит возводить её в идеал, а то набегут всякие axios и JB и начнут орать «кааанпеляяяция», «логи gcc», «смотреть на текст».

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

> Конечно проверяется, вот я федору 13 поставил на посмотреть, так там sendmail при загрузке сегфолтится. Сколько интересно человек его тестило? Я понимаю, что федора это несколько анстейбл, но не настолько же? Да и в прочих дистрах через день пользования косяков находится достаточно. Так что не рассказывай тут сказки про тщательно оттестированые пакеты.

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

В бинарных дистрах нет проблемы, потому что она тупо игнорируется.

то есть как игнорируется? Это даже как то сложно представить. Ты хотя бы пример приводи что ли

Банально поставить софт с предыдущей версии уже проблема.

как ставить определенную версию пакета я уже тут рассказывал. А про бекпорты совсем не понятно к чему было сказано

Ага, заказывали x86, а приехали итаники что-ли?

приехали с другим рейд контроллером

> Читаю сейчас этот тред и вспомнились мне события двухлетней давности. Особенно убийственный аргумент про wvdial и как «гентушники» с ним разбирались http://www.linux.org.ru/jump-message.jsp?msgid=2656025&cid=2656750

это тот тред где выяснилось, что для нормальной сборки необходим патч, которого не было в портаже? =)

> А JB-то какой противный человечек оказывается. А я даже не замечал раньше.

ты мне явно льстишь

> Я ли. Может я просто описал неправильно, но выглядело это именно так. Если визуально - теперь при загрузке не выводится на экран список этих модулей. Занимало это секунд 5-7.

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

> и плазма не будет падать?

нет, это фантастика

> Нет, про 1000% я про потребление. На бубунте 2гб, на генту 200метров.

это скорее в кде косяк всплыл, может какой нибудь сервис задуплился и отожрал кучу памяти. Ты хоть в top'е смотрел какой процесс столько памяти занял?

А вот ускорение в 2-5 раз минимум в разных программах. Где-то работает так же как в убунту, а где-то значительно, как в том же кейт. Те же алгоритмы сжатия работают ненамного быстрее, зато отрисовки интерфейса намного лучше.

я полагаю пруфлинки на бенчмарки и их результаты просить бессмысленно? ;)

Кстати, интересно: уважаемые гентушники, а зачем вы делаете на десутопе себе немонолитные ядра?

немонолитные - это какие?

>это скорее в кде косяк всплыл, может какой нибудь сервис задуплился и отожрал кучу памяти. Ты хоть в top'е смотрел какой процесс столько памяти занял?

Писал уже: В основном какой-то «непомук» и его производные. Но что это меняет? Кэйт тоже тормозит изза них? ОСЬ это симбиоз, там все связанно. И проблема в одном месте всегда скажется на другом.

я полагаю пруфлинки на бенчмарки и их результаты просить бессмысленно? ;)

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

что именно имеется ввиду под «немонолитными» ?
сами по себе модули не являются минусом )
если вопрос стоит про initrd , то это сущность несколько лишняя, драйвер для контроллера ide/sata/scsi , драйвер для диска ide/scsi и драйвер для файловой системы / включить в ядро не сложно

Сервер баз данных база 24гига запрос select * from <самая жирная таблица>

CentOS: ~2м30сек Gentoo: ~1м40сек

С точность до секунд лень в почте своей искать. Еще вопросы есть ?

> Писал уже: В основном какой-то «непомук» и его производные. Но что это меняет? Кэйт тоже тормозит изза них? ОСЬ это симбиоз, там все связанно. И проблема в одном месте всегда скажется на другом.

ну так тогда и речи о 1000% разницы быть не может. Если поставить непомук в генте, то может получится точно так же

В общем если уж сравнивать потребление памяти, то сравнивать один и тот же набор софта, а не как получится

> С точность до секунд лень в почте своей искать. Еще вопросы есть ?

ты бы лучше sql-bench запустил, а не select из таблицы

>>Кстати, интересно: уважаемые гентушники, а зачем вы делаете на десутопе себе немонолитные ядра?

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

не монолитные = с наличием модулей.

>ну так тогда и речи о 1000% разницы быть не может. Если поставить непомук в генте, то может получится точно так же

Ну не один же он. Я уже говорил, ось это не софт, а система. Все связано.

гибкость, иногда что-то не всегда нужно, что-то вообще про запас собрано, что-то нужно иметь возможность выгрузить или перезагрузить

более быстрая загрузка маленького ядра в случае некоторых (например lilo) загрузчиков

nvidia.ko все равно будет модулем... так что поддержку модулей в целом тем кто пользуется драйверами nvidia не выкинуть

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

еще не все модули, будучи засунутыми монолитно в ядро, хорошо переживают суспенд и хибернейт

> Ну не один же он. Я уже говорил, ось это не софт, а система. Все связано.

просто в данном случае сравнивать занимаемую память убунты и того, что наустанавливал ты сам совершенно неправильно

тогда какой от дебиана толк?

>просто в данном случае сравнивать занимаемую память убунты и того, что наустанавливал ты сам совершенно неправильно

Как минимум, в убунту мусор сложнее выпилить. Система установки не такая удобная. Плюс железо у всех разное. О чем спорить, все и так понятно.

> тогда какой от дебиана толк?

экономия на счетах к офтальмологу, очевидно же

>Ну ладно. В двух словах. Генту нужна лишь тем, кто любит наблюдать за загрузкой процессора. Иными словами - если нужна лёгкая и удобная компиляция и мельчайшее увеличение производительности - то пожалуйста, генту то что Вам нужно. Для всего остального Генту мало подходит.

Разработчик понял это и с генту свалил, за что ему +1.

Свалил в WoW. Я Вам тоже желаю туда же. ++!

по сравнению с чем?

в генте уже есть система установки? Попсеет дистрибутив =)

по сравнению с гентой

казалось бы, причем здесь гента

так тред как бы ей посвещен

тогда вот это:

по сравнению с гентой

дутое преимущество. примерно как говорить: «у нас теплее, чем в Якутии»

>в генте уже есть система установки? Попсеет дистрибутив =)

не поверишь, да.. Ее тоже нужно устанавливать и софт в ней. Он тут не по воле Перуна появляется.

какой был вопрос, такой получился и ответ

> не поверишь, да.. Ее тоже нужно устанавливать и софт в ней. Он тут не по воле Перуна появляется.

я инсталлятор имел ввиду

Не вижу --as-needed в LDFLAGS.

зачем это?

> Разработчик понял это и с генту свалил, за что ему +1.
Разработчик вообще не имел отношения к Gentoo, использовал NetBSD. Кстати, этот же человек — разработчик dhcpcd.

т.е. вся ценность дебиана сводится к отсутствию необходимости компилять?

> зачем это?
Тролль ты, а не гентушник.
http://blog.flameeyes.eu/tag/asneeded

> т.е. вся ценность дебиана сводится к отсутствию необходимости компилять?

по сравнению с source-based? Да

>>Разработчик вообще не имел отношения к Gentoo, использовал NetBSD. Кстати, этот же человек — разработчик dhcpcd.

Кстати на редкость кривое и неудобное поделие, dhclient ровнее и удобнее для кастомных маршрутов.

тогда она равна 0

>>Разработчик вообще не имел отношения к Gentoo, использовал NetBSD. Кстати, этот же человек — разработчик dhcpcd.

Кстати на редкость кривое и неудобное поделие, dhclient ровнее и удобнее для кастомных маршрутов.

Status: CLOSED
Resolution: WORKSFORME

для любителей компилировать вероятно выгода действительно нулевая

> Монолитное собрать сегодня достаточно сложно хотя бы из-за scsi_wait_scan.ko которое по определению модуль.

А ты в курсе, что в конце загрузки монолитного ядра автоматически выполняются ровно те же действия, что при загрузке scsi_wait_scan.ko? Сравни http://lxr.free-electrons.com/source/init/do_mounts.c и http://lxr.free-electrons.com/source/drivers/scsi/scsi_wait_scan.c - и там и там вызывается wait_for_device_probe(), а потом ждем, пока нужное устройство не появится.