Помедленнее!

>что-то глобально изменит.
например ?

> например ?

ну, например, дрова, кроме инфраструктурных из ядра выкинет.

:-)

да, дрова не нужны.

>ну, например, дрова, кроме инфраструктурных из ядра выкинет.

стабилизирует API ?

> стабилизирует API ?

как же! столько лет доказывать, что stable API/ABI нинужно, и тут стабилизировать? :)

On Wed, 30 Apr 2008, David Newall wrote:
>
> I don't claim BSD to be perfect, but it appears to have a consistently
> good quality.

Lol. You should try VMS. Now *there* was a stable system.

Oh, but it didn't actually make any progress, did it?

Линус опять отжигает.

> стабилизирует API ?

если честно, у меня надежда на это лет много уже теплится. с одной стороны — малореально, но с другой — видимо что-то все-таки придется ядерщикам делать с этой ситуацией. рано или поздно.

> Линус опять отжигает.

да нет, что касается VMS он может быть и прав, но если взять, скажем, NetBSD-current то там проблем со сборкой то-же хватает. "потому что это current". со всеми вытекающими.

// wbr

> если честно, у меня надежда на это лет много уже теплится. с одной стороны — малореально, но с другой — видимо что-то все-таки придется ядерщикам делать с этой ситуацией. рано или поздно.

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

// wbr

> а смысл? если есть RedHat. хотите более-менее стабильности?

совсем не в тему, на мой вкус. это немного разные «стабильности».

> как же! столько лет доказывать, что stable API/ABI нинужно, и тут стабилизировать? :)

ну мало ли. вон сколько лет он говорил что система контроля версий не нужна вообще. а потом взял и git написал.

> совсем не в тему, на мой вкус. это немного разные «стабильности».

что значит - совсем разные? допустим, я - производитель некоего софта, который в том числе что-то делает в ядре. модуль свой туда подгружает и он там крутится. запросто. всё, что мне хочется - это стабильность ABI ядра. замечу, не только API но и ABI. в пределах 2.6 вполне хватит. пусть даже с шагом в три года [лучше конечно пять]. чтобы не исчезали при переходе от 2.6.8 на 2.6.16 целые подсистемы неведомо куда а на них заточен мой софт.

требовать такого рода стабильности от по сути своей базарной конторы - сумасшествие. это попросту нереально. а вот договориться с конкретным вендором которого к тому же можно назвать что мол "он - это на самом деле и есть Linux" вполне. если конечно ему это интересно финансово. ну да это уже дело не технарей.

LKM-овцы путь махают шашками. вендоры - считают бабки. и все довольны.

// wbr

> не только API но и ABI

> klalafuda

От кого же ещё можно ждать подобного идиотизма.

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

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

или это вообще о чем?

> требовать такого рода стабильности от по сути своей базарной конторы

ну почему. вон xorg-овцы — смогли. поломка abi/api только на 1.5 ожидается. а до тех пор та же nvidia с этой частью системы проблем не имеет.

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

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

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

вывод простой - нужно дружить с тем же RedHat. но, замечу, не с Линусом и не с Линуксом как таковыми, а именно с RedHat бо трахаться придётся как раз с последним а отнюдь не с ванилой. впрочем, это IMHO вполне нормальная ситуация.

> а на десктопе красной шапки больше нет, никому она на десктопе не сдалась.

и слава тебе Господи! и не нада.

> а в федоре, по старой красношапочной традиции, пихают ядра свежее свежего, и ни о какой стабильности речи не идет.

ну и бога ради! ставят то не федору и не 5cent :)

// wbr

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

а… ну, узконишевое решение. может быть.

>ну мало ли. вон сколько лет он говорил что система контроля версий не нужна вообще. а потом взял и git написал.

звучит правдоподобно... но как это будет выглядеть ?

>звучит правдоподобно... но как это будет выглядеть ?

Я к тому что Торвальдса то это разгрузит, но вот увеличит ли это стабильность ядра ???

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

Вантузным троллям лишь бы потрахаться.

> а… ну, узконишевое решение. может быть.

hm. не факт. допустим, разрабатывается достаточно универсальное решение с прозрачные бэкапом и восстановлением данных в реальном времени. это может быть и файловая система и что-то более application specific типа сервера базы данных etc etc. узконишевое это решение? как посмотреть. боюсь, что это гораздо больше половины от того, на что сегодня реально нужен и используется Linux.

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

// wbr

>звучит правдоподобно...

нет :-)

> Я к тому что Торвальдса то это разгрузит, но вот увеличит ли это стабильность ядра ???

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

> узконишевое это решение?

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

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

>чтобы не исчезали при переходе от 2.6.8 на 2.6.16 целые подсистемы неведомо куда

наверно потому и исчезают что переработка/перетряхивани/унификация идет

Нифига себе у Линуса ЧСВ. Прямо финский Лебедев. А проблемы со стабильностью таки есть - http://kerneloops.org/. Эх, хоть бы Hurd допилили когда-нибудь.

Нет, а Линус во многом прав. А Newall такой BSD троллик.

xtron> >>что-то глобально изменит. >например ?

Перепишет на пых-пыхе! Ведь это глобально и надёжно.

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

Хмм... А какой смысл форкать? Компании и так содержат программистов, которые допиливают ванильное ядро до юзабельного стабильного состояния. Вон, посмотри, в стабильном Debian и RHEL до сих пор 18 ядро. ИМХО, форк ядра приведёт только к торможению его развития, а это никому не нужно.

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

khm. мы по всей видимости смотрим с разных точек зрения на то, что означает "широкорыночное решение".

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

а вот оригинальные сервисы скажем для датацентров - это уже интереснее. по сравнению с законченными [и закрытыми] железками там конструктор и вполне можно придумать и пристроить что-то своё, чего ещё нет в самой системе или существующие решения почему-то не устраивают.

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

да не нужно его форкать ни RH ни IBM. зачем собственно форкать? чтобы жёстко заморозить? без проблем. но тогда будут соотв. проблемы с развитием. опять же, IMHO будет очень сложно продавать в 2010м году "супер-пупер весь из себя стабильный Linux на базе ядра 2.2 [утрируя]".

если же посмотреть на RHEL, то обилие их патчей к ядру впечатляет. равно как и то, что ребята ничуть не стесняются переворачивать с ног на голову всё, что им кажется "как-то не так". в принципе, это нормально бо право имеют. и уж коли они не ленятся все переделывать под себя, то IMHO договориться с ними, чтобы в их ядре релиза такого-то было то-то и то-то - осталось/добавилось/исправилось - заметно проще, нежели с абстрактным "Linux community".

ладно, дело прошлое и в принципе пофигу что у них там и как. не хотят заморачиваться на тему стабильного API/ABI и фиг с ними - дело хозяйское.

// wbr

Давно пора compiz и DirectX в ядро внедрить

>вот попомните мои слова — еще до конца года Линус что-то глобально изменит

Возможно мне с моим английским трудно понять где Линус заикнулся o переменах. Похоже что он готов пожертвовать стабильностью git ветки ради скорости разработки.