| 1.1, Michael Shigorin (ok), 12:38, 13/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Мы тоже не успеваем... и в федоре тоже... и в opensuse, помнится, тоже... и в дебиане -- тоже тоже...
Но пойманная и зафиксированная в багтрекере ошибка -- всё равно гораздо лучше, чем сообщение в список рассылки, лично разработчику или высказанное потолку и шторам :)
Мортон, разумеется, прав -- по-хорошему, BTS заметного проекта такие люди жизненно нужны, как и секретари-референты заметным конторам.
| | |
| 1.2, Vladimir A (ok), 12:47, 13/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
в ядро ежедневно вносится масса модификаций и зачастую получается что исправляя одну проблему они пораждают три - четыре других. это вполне естественно при таких объемах монолитного строительства.
| | |
| |
| 2.3, Michael Shigorin (ok), 13:02, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>в ядро ежедневно вносится масса модификаций и зачастую получается что исправляя одну
>проблему они пораждают три - четыре других. это вполне естественно при
>таких объемах монолитного строительства.
Да когда же все повторятели слова "монолитный" применительно к ОС пойдут и исправят все-все проблемы и функциональные недостатки профессорского поделия? Например, чтоб драйвер tty хоть перезапускался, если его кильнуть.
И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.
| | |
| |
| 3.6, Vladimir A (ok), 14:38, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
если возникает необходимость "убивать" tty - использования монолита - не лучший выбор. может тогда в сторону qnx посмотреть? они кстати исходники выложили.. возможно в недалеком будущем увидем некоторые измения в ядре линукса ^_^
p.s. одни создают - другие пользуются.
| | |
| |
| 4.7, Michael Shigorin (ok), 14:45, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>если возникает необходимость "убивать" tty - использования монолита - не лучший выбор.
[beep]. Я про Minix3, если Вы вдруг тоже ещё не проснулись.
>может тогда в сторону qnx посмотреть? они кстати исходники выложили..
Hint: выложили вовсе не от того, что техническая и бизнес-модель побеждает. Хотя это как раз скорее огорчает, продукт интересный и лавка явно интересная.
>p.s. одни создают - другие пользуются.
_Пользуются_, а не высказывают своё высочайшее мнение по архитектуре. Или таки шлют патчи.
На высказывание не стоит тратить ни своего, ни чужого времени -- а то ведь ещё менее опытные могут и купиться на, гм, неправду, потом и получается, что "всё знаем", ничего не делая.
| | |
| |
| 5.19, tux2002 (?), 07:50, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Интересно, почему у меня в Minix отваливается сетевое подключение ethernet при простое? Может я глупый или напильник устаревший :)?
| | |
|
|
| 3.23, Аноним (-), 10:11, 14/09/2007 [^] [^^] [^^^] [ответить] | +/– | Когда увидел этот опус, сразу дежавю ощутил Где же я это уже видел Точно, в ... большой текст свёрнут, показать | | |
|
|
| 1.4, Аноним (-), 13:24, 13/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
до тех пор пока они наконец не заморозят API и перестанут наконец оперировать на открытом сердце и прочих органах, будет наблюдаться этот хаос.
| | |
| |
| 2.5, Michael Shigorin (ok), 14:09, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>до тех пор пока они наконец не заморозят API и перестанут наконец
>оперировать на открытом сердце и прочих органах, будет наблюдаться этот хаос.
Ещё один оракул со стажем...
Когда заморозят и перестанут, оно сможет спокойно отправляться на кладбище. Увы, отрасль не в том состоянии, когда можно действительно предсказуемо разрабатывать.
С другой стороны, то, что до сих пор нет ветки 2.7 -- не может не радовать: управление разработкой вместе с самим проектом вышли на уровень, когда необязательно всё перелопачивать и половину разламывать только для того, чтобы что-то добавить.
| | |
| |
| 3.8, Vladimir A (ok), 14:47, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Увы, отрасль не в том состоянии, когда можно действительно предсказуемо разрабатывать.
чем крупнее архитектура - тем дольше строительство. microsoft тоже в сроки постоянно не попадает.
>С другой стороны, то, что до сих пор нет ветки 2.7 --
>не может не радовать: управление разработкой вместе с самим проектом вышли
>на уровень, когда необязательно всё перелопачивать и половину разламывать только для
>того, чтобы что-то добавить.
сколько помню - нечетные ветки всегда шли как unstable или nightly builds.. сейчас ядро 2.6 даже Торвальдс не признает стабильным (о чем он уже ругался в нескольких своих интервью), поэтому смысла и нет в создании 2.7 ветки (unstable vs very-unstable О_О)
| | |
| |
| 4.10, Michael Shigorin (ok), 15:02, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>С другой стороны, то, что до сих пор нет ветки 2.7 --
>>не может не радовать: управление разработкой вместе с самим проектом вышли
>>на уровень, когда необязательно всё перелопачивать и половину разламывать только для
>>того, чтобы что-то добавить.
>сколько помню - нечетные ветки всегда шли как unstable или nightly builds..
Какие-такие nightlies, или это не про линукс?
"Правило нечётных=нестабильных веток" -- насколько знаю, линуксового происхождения, вот только и там были версии что в 1.1, что в 2.5.
>сейчас ядро 2.6 даже Торвальдс не признает стабильным (о чем он
>уже ругался в нескольких своих интервью), поэтому смысла и нет в
>создании 2.7 ветки (unstable vs very-unstable О_О)
Он не _ругался_. Просто апстрим (LKML) наконец-то пришёл к практическому пониманию того простого факта, что всё равно большинство ядер, которые используются -- вендорской сборки, с вендорскими патчами и вендорским QA. Поэтому kernel.org лучше сосредоточиться на более быстром мерже этих патчей и затыкании тех же дырок, чем вылизывании того, что всё равно соберут аж триста человек на планете, в ущерб более быстрому втягиванию полезного и вытаптывания в нём багов и несоответствий.
А вендоры, со своей стороны, усиленно думают переезжать с бэкпорта новых фич и драйверов на древние "энтерпрайз"-ядра к обновлению базовых версий.
И это очень правильно, как и любое называние вещей своими именами с последующим выравниванием работы по ним.
| | |
|
|
| 2.9, gmm20 (??), 14:52, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
 > до тех пор пока они наконец не заморозят 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.
[...]
| | |
| 2.11, gmm20 (??), 16:20, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> до тех пор пока они наконец не заморозят API и перестанут наконец
http://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stable-use
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.
[...]
| | |
| 2.12, gmm20 (??), 20:11, 13/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>до тех пор пока они наконец не заморозят 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.
[...]
| | |
|
| 1.13, Светочка (?), 01:21, 14/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Может вообще пора отделить разработку ядра от разработки драйверов, создав стабильный API для драйверов?
| | |
| |
| 2.14, Michael Shigorin (ok), 01:23, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Может вообще пора отделить разработку ядра от разработки драйверов, создав стабильный API
>для драйверов?
Народ из xorg уже согласился с тем, что это плохо работает, и кивал именно на linux kernel с подходом "то, что in-tree, точно живо, ну или около того".
Ссылку, к сожалению, сейчас искать уже сонный, но сам немного удивился тогда.
| | |
|
| 1.15, Светочка (?), 01:27, 14/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что же касается монолитных ядер/микроядер, то оба подхода имеют право на существование. Однако, желательно и монолитные ядра разбивать на компоненты с четко определенными интерфейсами (например, подсистема управления процессами, подсистема управления памятью, и т. п.), что позволит проводить их тестирование по-отдельности. Если я не ошибаюсь, в Linux тестирование компонентов по-отдельности не производится. При использовании компонентного подхода язык C++ оказался бы лучше C (по крайнем мере, за счет наличия в нем пространств имен, позволяющих скрывать детали реализации).
| | |
| |
| 2.16, Michael Shigorin (ok), 01:33, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Что же касается монолитных ядер/микроядер, то оба подхода имеют право на существование.
Однозначно.
>Однако, желательно и монолитные ядра разбивать на компоненты с четко определенными
>интерфейсами (например, подсистема управления процессами, подсистема управления памятью, и т. п.),
Вы давно в vm/ заглядывали, btw? Я-то по мере надобности и понимания только в fs/isofs/ ковырялся когда-то, да и то давным-давно как положено исправили...
>что позволит проводить их тестирование по-отдельности. Если я не ошибаюсь, в
>Linux тестирование компонентов по-отдельности не производится.
Конечно, и разрабатывается всё в куче -- пришёл человек, ляпнул патч туда, патч сюда, Линус это вместе сгрёб и заработало. :]
Не говоря о тестировании и отчётах по регрессам -- даже бенчмарками совсем никто не балуется, особенно при доказательстве преимуществ нового патча на VM или скедулера процессов/IO.
Все балуются плюшками. И тушью. :)
>При использовании компонентного подхода язык C++ оказался бы лучше C
>(по крайнем мере, за счет наличия в нем пространств имен, позволяющих
>скрывать детали реализации).
См. тж. kobjects?
| | |
| 2.20, Denis (??), 08:33, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Ну-ну.
Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского. И к сожалению привлечение только программистов непозитивно. Но - тестировать можно на любом языке, и на С и на С++. Компонентный подход - ну может и поможет. Надо править стратегию, управлять этим процессом некому. Не может Линус управлять этим процессом, не может или не хочет. А вот управленца по лицензии GPL найти наверное невозможно.
Так что скорее всего дело в этом. Надо четко разделять, это пишем, это тестируем, это доводим до кондиции, это в ядро включаем для работы. И все будет хорошо.
| | |
| |
| 3.27, Michael Shigorin (ok), 16:19, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Ну-ну.
>Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского.
>И к сожалению привлечение только программистов непозитивно. Но - тестировать можно
>на любом языке, и на С и на С++. Компонентный подход - ну может и поможет.
Это всё правда.
>Надо править стратегию, управлять этим процессом
>некому. Не может Линус управлять этим процессом, не может или не
>хочет. А вот управленца по лицензии GPL найти наверное невозможно.
А это -- феерический бред, простите. Управленцев не ищут "по лицензии", их ищут по умениям и на ставку. Торвальдсу давным-давно изрядно платят аккурат за управление процессом разработки ядра Linux, и у него действительно получается.
>Так что скорее всего дело в этом. Надо четко разделять, это пишем,
>это тестируем, это доводим до кондиции, это в ядро включаем для
>работы. И все будет хорошо.
Вот именно так сейчас и поставлено -- деревья индивидуальных разработчиков; ответственных за подсистемы; ответственных за staging tree; ответственных за official tree; поставщиков дистрибутивов.
И всё довольно неплохо ;-)
| | |
|
|
| 1.17, Светочка (?), 01:46, 14/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> См. тж. kobjects?
Зачем реализовывать объекты на C, когда можно их использовать на C++, имея поддержку со стороны языка?
| | |
| |
| 2.18, Michael Shigorin (ok), 01:48, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> См. тж. kobjects?
>Зачем реализовывать объекты на C, когда можно их использовать на C++, имея
>поддержку со стороны языка?
Зачем тащить весь головняк C++, если можно реализовать нужное на C?
(такой кошмар, как неуправляемое множественное наследование в ядре ОС, мне лично ещё не снился)
| | |
| |
| 3.22, northbear (??), 09:49, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Если в языке есть какая-то конструкция, то это не значит, что вы обязаны его использовать.
Я тоже считаю множественное наследование извращением. В природе ведь как, можно конечно скрестить осла с лошадью, но сие творение (мул по моему называется) потомков иметь не может.
В этом смысле С++ лишнее подтверждение этому. Для того, чтобы классы с множественным наследованием хоть как-то жили Бъярну пришлось ввести в язык кучу сущностей, которые в обычных языках бессмыслены и бесполезны. И все равно, попытка использовать этот инструмент на этапе проектирования приводит к тому, что при реализации вплывают системные конфликты, которые невозможно было предусмотреть на этапе проектирования.
А с завалами в багтрекере, это нормальное явление. Это говорит о том, что продукт живет и развивается. Было бы странно если бы этого не было, учитывая, что людей, которые были бы материально ответственны за оперативное исправление ошибок нет.
Во многих организациях где есть такие люди, завалы багрепортов тоже обычное явление. Одна 1С чего стоит...
| | |
| |
| 4.25, Michael Shigorin (ok), 13:15, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Если в языке есть какая-то конструкция, то это не значит, что вы
>обязаны его использовать.
Да, конечно. Только есть такая штука, как культура около языка и ожидания от проекта, который "на нём" (e.g. "да как же мы без STL" или вообще "без boost"). Думаю, можно погуглить историю плюсового кода в адаптековском драйвере, чтобы выудить мнение разработчиков Linux конкретно о перспективах использования C++ в этом ядре.
>А с завалами в багтрекере, это нормальное явление.
О чём и спич.
| | |
|
|
| 2.21, Denis (??), 08:37, 14/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло. Там можно боком приспособить структуры как дешовую подделку обьектов. Но самих обьектов на С небыло. Не заставляйте меня сомневаться.
У-у-у. Настоятельно рекомендую почитать книгу про компилятор GCC, ну и по С тоже.
Что касается kobject - они пишутся на С, так указанно в книжке Лава "Программирование ядра Линукс"
| | |
| |
| 3.28, Аноним (28), 01:29, 15/10/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Обьекты на С ? Где на С обьекты ?
А что мешает на сях создавать объекты?
| | |
|
|
|
