LINUX.ORG.RU

История изменений

Исправление Civil, (текущая версия) :

init_6

Самых свежих релизов софта

CentOS/RHEL это протухшие версии софта, за счет этого и стабильно. Даже в 7-ой софт заморожен на момент одно-двух летней давности. И 13 лет поддержки тут очень смешно звучат - тебе через 13 лет будет нужен php 5.4?

к примеру если сравнить количество заплаток у python2 то в gentoo их около 5ти а в centos их более 50ти. Как говорится почувствуйте разницу.

Важно понимать, что это за патчи и почему из в RHEL 50, а в генте 5. В RHEL добрая половина патчей нужна потому, что последняя версия у них 2.7.6 и они патчами её доводят до состояния 2.7.9. Еще часть патчей - фиксы всевозможных rpath'ов и прочей rhel-only лабуды + отсутствия поддержки юз-флагов. Если выфильтровавть беспользный мусор - останется не так много реально полезного. И честно говоря, проще апстримить патчи в генту (как всегда вопрос - где открытые тобой баги на баги питона в генте, которых нет в центоси?)

Благодаря тому что „помойка“ хранится в CVS а распространяется посредством rsync

От CVS постепенно пытаются уйти, есть разработчики которые активно над этим работают. Распространение по rsync - компактно (попробуй счекаутить ядро с историей и посмотри какой оверхед по колличеству данных), универсально (не забывай, что на инфраструктуру по поддержке rsync'а и зеркалированию оного - нужно меньше железа, чем на то же самое для git'а), да и внедрено уже давно, а для людей вполне работает. Опять же, если тебе по каким-то причинам надо иметь микс из stable + testing (большая часть из stable, один-два пакета из testing) - как ты на базе git'а и веток обеспечишь? А как с разработкой быть?

Да улучшится - в багзилле будут висеть фиксы… месяцами и годами… А потому-что майнтрейнеры в большинстве ещё и руководствуются велением своей левой пятки а не здравым смыслом и философией gentoo.

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

Очевидно что закрепление майнтрейнеров за конкретными ebuild-ами и дублирование работы ещё и на оверлеи никак не способствуют тому чтобы рук хватало на все. К тому же результаты ещё и в том что в деревt разброд и шатания даже по таким вопросам как в какой функции выполнять epatch.

Overlay - возможность дать пользователям работать над ебилдами + возможность иметь песочницу для разработки чего-то, реально могущего сломать все. Это считай просто сторонние репозитории. Поэтому никакого отношения к времени разработки они не имеют (скорее наоборот, ускоряют разработку, так как можно потестировать всторонке на какой-то базе пользователей). Про epatch - есть policy и в новых ебилдах все в одном месте (src_prepare). Обновление старых занимает какое-то время, да. Если где-то видишь в новых ебилдах бамп с нарушением policy - баг на багзиллу, такое быстро поправят и девелоперу дадут по шее.

В gentoo у каждого майнтрейнера есть свой набор ebuild-ов за которыми он, по идее, следит и они предпочитают тупо бампать их по любому поводу а в centos есть конкретная версия которую фиксят и доделывают, если это необходимо, короче говоря там эту версию поддерживают длительное время.

Зависит от конкретного бага - фиксят или добавлением патчей или бампом, если бампнутая версия отличается мало, а баг там уже поправлен. Что в этом плохого? Бэкпортирование возможностей из более новых версий софта, требует очень большого колличества времени и еще большего тестирования. Разработчикам RH платят за full-time работу над такими вещами. Ну и да, минус в том, что на момент выхода RH устарел на год, к концу поддержки софт в RH устареет лет на 10 с лишним. Такое полезно в Ынтерпрайзе, но очень вредно в остальном. Думаешь просто так многие компании сидят на Ubuntu на серверах? Потому что это компромис между RH и Gentoo - и софт не так сильно устаревает (а некоторый даже может сменить версию или иметь бэкпорты, даже в LTS), но и предсказуемые сроки поддержки (чего нет у дебиана, например). При этом софт более ванильный, чем в RH.

Про свободу в gentoo расскажешь мне после того как будет отвязаны: bash, gcc, openrc из профиля. Т.е. когда появится та самая свобода в выборе того что именно использовать…

Баш требуется portage'ем, ебилды используют башизмы. Что-то кроме gcc не может собрать все дерево портажей (собери шлангом ядро, не патча последнее, например), openrc отвязывается какое-то время уже (в смысле можно заменить openrc на systemd и выпилить openrc).

У меня тоже есть ссылка сырцы ChromeOS были в 2009-м и основан он на gentoo а использовал он upstart… ОЙ! :D И никому в голову не пришло взять их наработки в основное дерево?

Ебилды ChromeOS завязаны на гугловые средства сборки и гугловые eclass'ы очень сильно. Просто так не утащишь. Плюс какой толк от upstart, когда для эффективной работы нужно поддерживать еще и upstart-скрипты? А OpenRC по возможностям не так то сильно и отличается от него. Насколько я знаю, upstart люди не просили и разработчики не готовы были поддерживать одновременно. С systemd пример лучше - он достаточно быстро появился и поддерживается конечно не на тех же правах, на которых OpenRC но близок к этому.

А основная черта в том, что для того чтобы безболезненно использовать что угодно вместо gcc не делается вообще ничего.

Когда шлангом можно будет собрать основную систему (я про Linux в целом, а не про генту), тогда и будут думать о поддержке шланга как альтернативы. Так стандартными средствами (portage.env) можно менять компилятор испокон веков, притом чуть ли не для каждого пакета индивидуально.

Ищи в любимом поисковике по запросу „portage libbash“, удивляйся.

Над libbash еще работать и работать. Пока он не в состоянии парсить 100% ebuild'ов. И к сожалению, развивался он практически полностью в рамках GSoC. Если в состоянии подхватить проект и помочь ему достичь нормального состояния - все будут только рады.

«gcc мы официально поддерживаем а clang бэтка и всё такое и в общем на ваш страх и риск как и 9999.»

Ты с людьми хоть раз в жизни работал? Сделать так и не иметь хотя бы 90% покрытия системы шлангом (притом самой базы в первую очередь) - обречь себя и багзиллу на кучу воплей вида «А!!! Не грузится система! Я ничего не делал, клянусь мамой». Проверено на практике неоднократно.

СЮРПРИИИИЗ в gentoo с её от 250 до 300 разработчиками даже известные и незакрытые CVE висят годами

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

В общем все это о том, что куда эффективнее:

1. Поментяь свое мнение

2. Присоединится к разработке и сделать как правильно.

3. Пытаться понять почему сделано так, а не иначе. Не разбираясь очень легко делать заявления, которые ты делаешь периодически на протяжении уже многих лет. Хотя чтобы разобраться нужно то всего ничего, потратить немного времени.

Исходная версия Civil, :

Самых свежих релизов софта

CentOS/RHEL это протухшие версии софта, за счет этого и стабильно. Даже в 7-ой софт заморожен на момент одно-двух летней давности. И 13 лет поддержки тут очень смешно звучат - тебе через 13 лет будет нужен php 5.4?

к примеру если сравнить количество заплаток у python2 то в gentoo их около 5ти а в centos их более 50ти. Как говорится почувствуйте разницу.

Важно понимать, что это за патчи и почему из в RHEL 50, а в генте 5. В RHEL добрая половина патчей нужна потому, что последняя версия у них 2.7.6 и они патчами её доводят до состояния 2.7.9. Еще часть патчей - фиксы всевозможных rpath'ов и прочей rhel-only лабуды + отсутствия поддержки юз-флагов. Если выфильтровавть беспользный мусор - останется не так много реально полезного. И честно говоря, проще апстримить патчи в генту (как всегда вопрос - где открытые тобой баги на баги питона в генте, которых нет в центоси?)

Благодаря тому что „помойка“ хранится в CVS а распространяется посредством rsync

От CVS постепенно пытаются уйти, есть разработчики которые активно над этим работают. Распространение по rsync - компактно (попробуй счекаутить ядро с историей и посмотри какой оверхед по колличеству данных), универсально (не забывай, что на инфраструктуру по поддержке rsync'а и зеркалированию оного - нужно меньше железа, чем на то же самое для git'а), да и внедрено уже давно, а для людей вполне работает. Опять же, если тебе по каким-то причинам надо иметь микс из stable + testing (большая часть из stable, один-два пакета из testing) - как ты на базе git'а и веток обеспечишь? А как с разработкой быть?

Да улучшится - в багзилле будут висеть фиксы… месяцами и годами… А потому-что майнтрейнеры в большинстве ещё и руководствуются велением своей левой пятки а не здравым смыслом и философией gentoo.

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

Очевидно что закрепление майнтрейнеров за конкретными ebuild-ами и дублирование работы ещё и на оверлеи никак не способствуют тому чтобы рук хватало на все. К тому же результаты ещё и в том что в деревt разброд и шатания даже по таким вопросам как в какой функции выполнять epatch.

Overlay - возможность дать пользователям работать над ебилдами + возможность иметь песочницу для разработки чего-то, реально могущего сломать все. Это считай просто сторонние репозитории. Поэтому никакого отношения к времени разработки они не имеют (скорее наоборот, ускоряют разработку, так как можно потестировать всторонке на какой-то базе пользователей). Про epatch - есть policy и в новых ебилдах все в одном месте (src_prepare). Обновление старых занимает какое-то время, да. Если где-то видишь в новых ебилдах бамп с нарушением policy - баг на багзиллу, такое быстро поправят и девелоперу дадут по шее.

В gentoo у каждого майнтрейнера есть свой набор ebuild-ов за которыми он, по идее, следит и они предпочитают тупо бампать их по любому поводу а в centos есть конкретная версия которую фиксят и доделывают, если это необходимо, короче говоря там эту версию поддерживают длительное время.

Зависит от конкретного бага - фиксят или добавлением патчей или бампом, если бампнутая версия отличается мало, а баг там уже поправлен. Что в этом плохого? Бэкпортирование возможностей из более новых версий софта, требует очень большого колличества времени и еще большего тестирования. Разработчикам RH платят за full-time работу над такими вещами. Ну и да, минус в том, что на момент выхода RH устарел на год, к концу поддержки софт в RH устареет лет на 10 с лишним. Такое полезно в Ынтерпрайзе, но очень вредно в остальном. Думаешь просто так многие компании сидят на Ubuntu на серверах? Потому что это компромис между RH и Gentoo - и софт не так сильно устаревает (а некоторый даже может сменить версию или иметь бэкпорты, даже в LTS), но и предсказуемые сроки поддержки (чего нет у дебиана, например). При этом софт более ванильный, чем в RH.

Про свободу в gentoo расскажешь мне после того как будет отвязаны: bash, gcc, openrc из профиля. Т.е. когда появится та самая свобода в выборе того что именно использовать…

Баш требуется portage'ем, ебилды используют башизмы. Что-то кроме gcc не может собрать все дерево портажей (собери шлангом ядро, не патча последнее, например), openrc отвязывается какое-то время уже (в смысле можно заменить openrc на systemd и выпилить openrc).

У меня тоже есть ссылка сырцы ChromeOS были в 2009-м и основан он на gentoo а использовал он upstart… ОЙ! :D И никому в голову не пришло взять их наработки в основное дерево?

Ебилды ChromeOS завязаны на гугловые средства сборки и гугловые eclass'ы очень сильно. Просто так не утащишь. Плюс какой толк от upstart, когда для эффективной работы нужно поддерживать еще и upstart-скрипты? А OpenRC по возможностям не так то сильно и отличается от него. Насколько я знаю, upstart люди не просили и разработчики не готовы были поддерживать одновременно. С systemd пример лучше - он достаточно быстро появился и поддерживается конечно не на тех же правах, на которых OpenRC но близок к этому.

А основная черта в том, что для того чтобы безболезненно использовать что угодно вместо gcc не делается вообще ничего.

Когда шлангом можно будет собрать основную систему (я про Linux в целом, а не про генту), тогда и будут думать о поддержке шланга как альтернативы. Так стандартными средствами (portage.env) можно менять компилятор испокон веков, притом чуть ли не для каждого пакета индивидуально.

Ищи в любимом поисковике по запросу „portage libbash“, удивляйся.

Над libbash еще работать и работать. Пока он не в состоянии парсить 100% ebuild'ов. И к сожалению, развивался он практически полностью в рамках GSoC. Если в состоянии подхватить проект и помочь ему достичь нормального состояния - все будут только рады.

«gcc мы официально поддерживаем а clang бэтка и всё такое и в общем на ваш страх и риск как и 9999.»

Ты с людьми хоть раз в жизни работал? Сделать так и не иметь хотя бы 90% покрытия системы шлангом (притом самой базы в первую очередь) - обречь себя и багзиллу на кучу воплей вида «А!!! Не грузится система! Я ничего не делал, клянусь мамой». Проверено на практике неоднократно.

СЮРПРИИИИЗ в gentoo с её от 250 до 300 разработчиками даже известные и незакрытые CVE висят годами

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

В общем все это о том, что куда эффективнее:

1. Поментяь свое мнение

2. Присоединится к разработке и сделать как правильно.

3. Пытаться понять почему сделано так, а не иначе. Не разбираясь очень легко делать заявления, которые ты делаешь периодически на протяжении уже многих лет. Хотя чтобы разобраться нужно то всего ничего, потратить немного времени.