The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Разработчики Linux ядра не успевают реагировать на..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Разработчики Linux ядра не успевают реагировать на..."  
Сообщение от opennews (ok) on 13-Сен-07, 12:38 
В трекере ошибок ядра в настоящее время накопилось (http://www.linuxworld.com/news/2007/091207-kernel.html) около 1500  нерешенных проблем, 50 проблем ожидают первичного рассмотрения.
Процесс исправления ошибок нуждается в оптимизации. Andrew Morton предлагает учредить должность "bugmaster" для помощи в рассмотрении сообщений об ошибках, доведения информации до конечного разработчика и контроля за исправлением.

URL: http://www.linuxworld.com/news/2007/091207-kernel.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=12007

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 13-Сен-07, 12:38 
Мы тоже не успеваем... и в федоре тоже... и в opensuse, помнится, тоже... и в дебиане -- тоже тоже...

Но пойманная и зафиксированная в багтрекере ошибка -- всё равно гораздо лучше, чем сообщение в список рассылки, лично разработчику или высказанное потолку и шторам :)

Мортон, разумеется, прав -- по-хорошему, BTS заметного проекта такие люди жизненно нужны, как и секретари-референты заметным конторам.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Vladimir A (ok) on 13-Сен-07, 12:47 
в ядро ежедневно вносится масса модификаций и зачастую получается что исправляя одну проблему они пораждают три - четыре других. это вполне естественно при таких объемах монолитного строительства.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 13-Сен-07, 13:02 
>в ядро ежедневно вносится масса модификаций и зачастую получается что исправляя одну
>проблему они пораждают три - четыре других. это вполне естественно при
>таких объемах монолитного строительства.

Да когда же все повторятели слова "монолитный" применительно к ОС пойдут и исправят все-все проблемы и функциональные недостатки профессорского поделия?  Например, чтоб драйвер tty хоть перезапускался, если его кильнуть.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Vladimir A (ok) on 13-Сен-07, 14:38 
если возникает необходимость "убивать" tty - использования монолита - не лучший выбор. может тогда в сторону qnx посмотреть? они кстати исходники выложили.. возможно в недалеком будущем увидем некоторые измения в ядре линукса ^_^
p.s. одни создают - другие пользуются.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 13-Сен-07, 14:45 
>если возникает необходимость "убивать" tty - использования монолита - не лучший выбор.

[beep].  Я про Minix3, если Вы вдруг тоже ещё не проснулись.

>может тогда в сторону qnx посмотреть? они кстати исходники выложили..

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

>p.s. одни создают - другие пользуются.

_Пользуются_, а не высказывают своё высочайшее мнение по архитектуре.  Или таки шлют патчи.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от tux2002 email on 14-Сен-07, 07:50 
Интересно, почему у меня в Minix отваливается сетевое подключение ethernet при простое? Может я глупый или напильник устаревший :)?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Аноним on 14-Сен-07, 10:11 
>И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.

Когда увидел этот опус, сразу дежавю ощутил... Где же я это уже видел? Точно, в книжке Торвальдса "Just for Fun". Там он отжигал про "человеческий мозг" и "усложнение взаимодействия в микроядре":

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

Так вот, исходники Minix3 (с КОММЕНТАРИЯМИ) помещены в книгу (в русском издании на CD), и их вполне можно ЧИТАТЬ и досконально изучить за семестр. Представляете себе исходники ядра линукс (пусть даже самые базовые, без драйверов), помещенные в книгу? Да там черт ногу сломает. И человек, видивший исходники Minix3 и Linux никогда не согласится с тем, что "Простота, обеспечиваемая микроядром, является мнимой". И сравните время компиляции Minix3 со всеми утилитами и голого ядра линукса. Да, оно гораздо функциональнее, однако оно по устройству своему сложнее. В любом случае, развитие всех современных ОС так или иначе движется в сторону микроядра, даже в линуксе уже заходят разговоры о необходимости стандартизации API драйверов и перенос некоторых их них в user space. Так что Линусу скоро будет стыдно за все эти выкрики, которые он делал по молодости. А идиотам, орущим в свое время "Таненбаум - старый маразматик" уже ничего не поможет, даже когда Linux в конечном итоге микроядерным станет, мозгов у них не прибавится.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "опять сильные, но лёгкие микроядерщики? :)"  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 11:42 
>>И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие
>>между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.
>Когда увидел этот опус, сразу дежавю ощутил... Где же я это уже
>видел? Точно, в книжке Торвальдса "Just for Fun".

Именно.  А у меня было дежавю, когда этот кусок читал -- поскольку там было обёрнуто в слова то ощущение, которое возникло от "исторического спора".

>"Простота, обеспечиваемая микроядром, является мнимой."
>Так вот, исходники Minix3 (с КОММЕНТАРИЯМИ) помещены в книгу (в русском издании
>на CD), и их вполне можно ЧИТАТЬ и досконально изучить за семестр.

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

(домашнее задание: рассчитаться за покупки наличностью с применением палочек при проверке сдачи)

>Представляете себе исходники ядра линукс (пусть даже самые базовые, без
>драйверов), помещенные в книгу?

И "Apache в комментариях" тоже представляю, но вообще-то Understanding the Linux Kernel -- обычный талмуд несколько тяжелей APUE, а что? (это не листинг, а объяснение более высокоуровневым языком, чем C -- английским; плюс индекс по исходникам)

>И человек, видивший исходники Minix3 и Linux никогда не согласится
>с тем, что "Простота, обеспечиваемая микроядром, является мнимой".

Покрутив Minix3 в руках, меня уже совсем не тянет ещё и в его исходники смотреть.  Даже не потому, что оно попросту не годится ни для одной из тех задач, что у меня есть (включая образовательные, но не для системщиков).  Я не вижу в этом смысла, а учебные ядра есть и другие -- AtheOS, например.

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

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

>И сравните время компиляции Minix3 со всеми утилитами и голого ядра линукса.
>Да, оно гораздо функциональнее, однако оно по устройству своему сложнее.

Это почти тавтология, ну да кто бы спорил.

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

>В любом случае, развитие всех современных ОС так или иначе движется в сторону микроядра,

Можно пальцем указать?
NT -- уходит от микроядра, хоть и современная с натяжкой.
OSX -- сидит, впрочем, чуточку зная Джобса -- как только оно ему помешает прикрутить финтифлюшку, будет выкинуто точно в той же пропорции, как и Гейтсом после NT 3.51.
QNX -- пока скорее не развивается, а завивается, как ни жаль.
Solaris -- не наблюдаю такого вообще.

Про Linux речь и так вот, а ведь это претензия на пост-UNIX, которую сложно оспаривать (OpenSolaris мож сможет -- если сани поймут, как _эффективно_ работать с сообществом и что никому особо не нужен халявный юникс, который разрабатывается закрытой кучкой, и претворят это понимание в жизнь).

>даже в линуксе уже заходят разговоры о необходимости стандартизации API драйверов
>и перенос некоторых их них в user space.

В линуксе не разговоры заходят, а давным-давно куча всего работает или отдельными kthreads, или именно что юзерспейсными процессами.  Никакой фанатической позиции по поводу "да это же так, как профессор говорил, а он лох!" -- не наблюдал.  Скорее золотая середина -- где разумно/работает, там вытаскивается, где неразумно или не работает (см. скипнутую цитату) -- там нет.

>Так что Линусу скоро будет стыдно за все эти выкрики, которые он делал по молодости.

Вообще-то, наверное, каждому разумному человеку бывает стыдно за выкрики, которые он делал по молодости -- но Линус-то с Таненбаумом уже давно успели перетереть по поводу старых флеймов (удивительно культурных по современным меркам), дружески сфотографироваться в обнимку и согласиться, что у них разные подходы к архитектуре ОС.

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

Поэтому я тут даже скорее за Таненбаума рад -- старшему-то сложнее.

>А идиотам, орущим в свое время "Таненбаум - старый маразматик" уже ничего не поможет

Вы перечитайте прогнозы Таненбаума про "everyone will be running...", потом сравните со своими и мож подумайте, что сказать-то хотели, пока не забыли? :]

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

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

Я же рискну поставить (на LF20?) ящик черниговского против Вашего имени, что мои оракулские (или аналитические :) способности попрактичней будут -- бишь Linux ни в каком конечном итоге микроядерным не станет, к этому попросту нет предпосылок (включая single-image massive multiprocessors).  Если LKML или ещё кто вдруг найдёт решение для проблемы взаимодействия -- то это будет как минимум не линукс, а другой фромскратч, который только взлетать будет ещё несколько лет.  _Если_.

Кстати, самым лучшим способом доказать свою правоту для Вас может оказаться участие в таком поиске.  Заодно и насчёт идиотов-маразматиков будет возможность подумать. :)

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Аноним on 13-Сен-07, 13:24 
до тех пор пока они наконец не заморозят API и перестанут наконец оперировать на открытом сердце и прочих органах, будет наблюдаться этот хаос.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Пользователи Linux ядра не успевают сниматься с ручника"  
Сообщение от Michael Shigorin email(ok) on 13-Сен-07, 14:09 
>до тех пор пока они наконец не заморозят API и перестанут наконец
>оперировать на открытом сердце и прочих органах, будет наблюдаться этот хаос.

Ещё один оракул со стажем...

Когда заморозят и перестанут, оно сможет спокойно отправляться на кладбище.  Увы, отрасль не в том состоянии, когда можно действительно предсказуемо разрабатывать.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Пользователи Linux ядра не успевают сниматься с ручника"  
Сообщение от Vladimir A (ok) on 13-Сен-07, 14:47 
>Увы, отрасль не в том состоянии, когда можно действительно предсказуемо разрабатывать.

чем крупнее архитектура - тем дольше строительство. microsoft тоже в сроки постоянно не попадает.

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

сколько помню - нечетные ветки всегда шли как unstable или nightly builds.. сейчас ядро 2.6 даже Торвальдс не признает стабильным (о чем он уже ругался в нескольких своих интервью), поэтому смысла и нет в создании 2.7 ветки (unstable vs very-unstable О_О)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "upstream vs/with distros"  
Сообщение от Michael Shigorin email(ok) on 13-Сен-07, 15:02 
>>С другой стороны, то, что до сих пор нет ветки 2.7 --
>>не может не радовать: управление разработкой вместе с самим проектом вышли
>>на уровень, когда необязательно всё перелопачивать и половину разламывать только для
>>того, чтобы что-то добавить.
>сколько помню - нечетные ветки всегда шли как unstable или nightly builds..

Какие-такие nightlies, или это не про линукс?

"Правило нечётных=нестабильных веток" -- насколько знаю, линуксового происхождения, вот только и там были версии что в 1.1, что в 2.5.

>сейчас ядро 2.6 даже Торвальдс не признает стабильным (о чем он
>уже ругался в нескольких своих интервью), поэтому смысла и нет в
>создании 2.7 ветки (unstable vs very-unstable О_О)

Он не _ругался_.  Просто апстрим (LKML) наконец-то пришёл к практическому пониманию того простого факта, что всё равно большинство ядер, которые используются -- вендорской сборки, с вендорскими патчами и вендорским QA.  Поэтому kernel.org лучше сосредоточиться на более быстром мерже этих патчей и затыкании тех же дырок, чем вылизывании того, что всё равно соберут аж триста человек на планете, в ущерб более быстрому втягиванию полезного и вытаптывания в нём багов и несоответствий.

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от gmm20 email(??) on 13-Сен-07, 14:52 
> до тех пор пока они наконец не заморозят API

Documentation\stable_api_nonsense.txt

http://www.kroah.com/log/linux/stable_api_nonsense.html

[...]

This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still works just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.

[...]

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от gmm20 email(??) on 13-Сен-07, 16:20 
> до тех пор пока они наконец не заморозят API и перестанут наконец

http://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stable-userspace-driver-api/

Linux kernel 2.6.23 to have stable userspace driver API

Linus Torvalds included patches into the mainline tree which implement a stable userspace driver API into the Linux kernel.

The stable driver API was already announced a year ago by Greg Kroah-Hartman. Now the last patches where uploaded and the API was included in Linus’ tree.

[...]

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от gmm20 email(??) on 13-Сен-07, 20:11 
>до тех пор пока они наконец не заморозят API и перестанут наконец

http://lwn.net/Articles/162686/

Linux in a binary world... a doomsday scenario

What if.. what if the linux kernel developers tomorrow accept that
binary modules are OK and are essential for the progress of linux.

[...]

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Светочка on 14-Сен-07, 01:21 
Может вообще пора отделить разработку ядра от разработки драйверов, создав стабильный API для драйверов?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 01:23 
>Может вообще пора отделить разработку ядра от разработки драйверов, создав стабильный API
>для драйверов?

Народ из xorg уже согласился с тем, что это плохо работает, и кивал именно на linux kernel с подходом "то, что in-tree, точно живо, ну или около того".

Ссылку, к сожалению, сейчас искать уже сонный, но сам немного удивился тогда.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Светочка on 14-Сен-07, 01:27 
Что же касается монолитных ядер/микроядер, то оба подхода имеют право на существование. Однако, желательно и монолитные ядра разбивать на компоненты с четко определенными интерфейсами (например, подсистема управления процессами, подсистема управления памятью, и т. п.), что позволит проводить их тестирование по-отдельности. Если я не ошибаюсь, в Linux тестирование компонентов по-отдельности не производится. При использовании компонентного подхода язык C++ оказался бы лучше C (по крайнем мере, за счет наличия в нем пространств имен, позволяющих скрывать детали реализации).
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 01:33 
>Что же касается монолитных ядер/микроядер, то оба подхода имеют право на существование.

Однозначно.

>Однако, желательно и монолитные ядра разбивать на компоненты с четко определенными
>интерфейсами (например, подсистема управления процессами, подсистема управления памятью, и т. п.),

Вы давно в vm/ заглядывали, btw?  Я-то по мере надобности и понимания только в fs/isofs/ ковырялся когда-то, да и то давным-давно как положено исправили...

>что позволит проводить их тестирование по-отдельности. Если я не ошибаюсь, в
>Linux тестирование компонентов по-отдельности не производится.

Конечно, и разрабатывается всё в куче -- пришёл человек, ляпнул патч туда, патч сюда, Линус это вместе сгрёб и заработало. :]

Не говоря о тестировании и отчётах по регрессам -- даже бенчмарками совсем никто не балуется, особенно при доказательстве преимуществ нового патча на VM или скедулера процессов/IO.

Все балуются плюшками.  И тушью. :)

>При использовании компонентного подхода язык C++ оказался бы лучше C
>(по крайнем мере, за счет наличия в нем пространств имен, позволяющих
>скрывать детали реализации).

См. тж. kobjects?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Denis email(??) on 14-Сен-07, 08:33 
Ну-ну.
Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского. И к сожалению привлечение только программистов непозитивно. Но - тестировать можно на любом языке, и на С и на С++. Компонентный подход - ну может и поможет. Надо править стратегию, управлять этим процессом некому. Не может Линус управлять этим процессом, не может или не хочет. А вот управленца по лицензии GPL найти наверное невозможно.
Так что скорее всего дело в этом. Надо четко разделять, это пишем, это тестируем, это доводим до кондиции, это в ядро включаем для работы. И все будет хорошо.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "пользователи продолжают не успевать..."  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 16:19 
>Ну-ну.
>Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского.
>И к сожалению привлечение только программистов непозитивно. Но - тестировать можно
>на любом языке, и на С и на С++. Компонентный подход - ну может и поможет.

Это всё правда.

>Надо править стратегию, управлять этим процессом
>некому. Не может Линус управлять этим процессом, не может или не
>хочет. А вот управленца по лицензии GPL найти наверное невозможно.

А это -- феерический бред, простите.  Управленцев не ищут "по лицензии", их ищут по умениям и на ставку.  Торвальдсу давным-давно изрядно платят аккурат за управление процессом разработки ядра Linux, и у него действительно получается.

>Так что скорее всего дело в этом. Надо четко разделять, это пишем,
>это тестируем, это доводим до кондиции, это в ядро включаем для
>работы. И все будет хорошо.

Вот именно так сейчас и поставлено -- деревья индивидуальных разработчиков; ответственных за подсистемы; ответственных за staging tree; ответственных за official tree; поставщиков дистрибутивов.

И всё довольно неплохо ;-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Светочка on 14-Сен-07, 01:46 
> См. тж. kobjects?

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 01:48 
>> См. тж. kobjects?
>Зачем реализовывать объекты на C, когда можно их использовать на C++, имея
>поддержку со стороны языка?

Зачем тащить весь головняк C++, если можно реализовать нужное на C?

(такой кошмар, как неуправляемое множественное наследование в ядре ОС, мне лично ещё не снился)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от northbear (??) on 14-Сен-07, 09:49 
Если в языке есть какая-то конструкция, то это не значит, что вы обязаны его использовать.
Я тоже считаю множественное наследование извращением. В природе ведь как, можно конечно скрестить осла с лошадью, но сие творение (мул по моему называется) потомков иметь не может.

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 13:15 
>Если в языке есть какая-то конструкция, то это не значит, что вы
>обязаны его использовать.

Да, конечно.  Только есть такая штука, как культура около языка и ожидания от проекта, который "на нём" (e.g. "да как же мы без STL" или вообще "без boost").  Думаю, можно погуглить историю плюсового кода в адаптековском драйвере, чтобы выудить мнение разработчиков Linux конкретно о перспективах использования C++ в этом ядре.

>А с завалами в багтрекере, это нормальное явление.

О чём и спич.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Denis email(??) on 14-Сен-07, 08:37 
Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло. Там можно боком приспособить структуры как дешовую подделку обьектов. Но самих обьектов на С небыло. Не заставляйте меня сомневаться.
У-у-у. Настоятельно рекомендую почитать книгу про компилятор GCC, ну и по С тоже.
Что касается kobject - они пишутся на С, так указанно в книжке Лава "Программирование ядра Линукс"
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "(offtopic) ООП и Linux"  
Сообщение от Michael Shigorin email(ok) on 14-Сен-07, 16:13 
>Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло.

_В_ C -- нет, _на_ C -- бывают.  Удивлены?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Разработчики Linux ядра не успевают реагировать на сообщения..."  
Сообщение от Аноним on 15-Окт-07, 01:29 
>Обьекты на С ? Где на С обьекты ?

А что мешает на сях создавать объекты?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру