https://mobile.opennet.me/openforum/vsluhforumID3/38394.html В трекере ошибок ядра в настоящее время накопилось (http://www.linuxworld.com/news/2007/091207-kernel.html) около 1500 нерешенных проблем, 50 проблем ожидают первичного рассмотрения. <br>Процесс исправления ошибок нуждается в оптимизации. Andrew Morton предлагает учредить должность "bugmaster" для помощи в рассмотрении сообщений об ошибках, доведения информации до конечного разработчика и контроля за исправлением.<br><br>URL: http://www.linuxworld.com/news/2007/091207-kernel.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=12007<br> https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#28 Sun, 14 Oct 2007 21:29:11 GMT &gt;Обьекты на С ? Где на С обьекты ?<br><br>А что мешает на сях создавать объекты? <br> https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#27 Fri, 14 Sep 2007 12:19:06 GMT &gt;Ну-ну. <br>&gt;Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского. <br>&gt;И к сожалению привлечение только программистов непозитивно. Но - тестировать можно <br>&gt;на любом языке, и на С и на С++. Компонентный подход - ну может и поможет. <br><br>Это всё правда.<br><br>&gt;Надо править стратегию, управлять этим процессом <br>&gt;некому. Не может Линус управлять этим процессом, не может или не <br>&gt;хочет. А вот управленца по лицензии GPL найти наверное невозможно. <br><br>А это -- феерический бред, простите. Управленцев не ищут "по лицензии", их ищут по умениям и на ставку. Торвальдсу давным-давно изрядно платят аккурат за управление процессом разработки ядра Linux, и у него действительно получается.<br><br>&gt;Так что скорее всего дело в этом. Надо четко разделять, это пишем, <br>&gt;это тестируем, это доводим до кондиции, это в ядро включаем для <br>&gt;работы. И все будет хорошо.<br><br>Вот именно так сейчас и поставлено -- деревья индивидуальных разработчиков; ответственных за подсистемы; ответственных за staging tree; https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#26 Fri, 14 Sep 2007 12:13:14 GMT &gt;Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло.<br><br>_В_ C -- нет, _на_ C -- бывают. Удивлены?<br> https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#25 Fri, 14 Sep 2007 09:15:19 GMT &gt;Если в языке есть какая-то конструкция, то это не значит, что вы <br>&gt;обязаны его использовать.<br><br>Да, конечно. Только есть такая штука, как культура около языка и ожидания от проекта, который "на нём" (e.g. "да как же мы без STL" или вообще "без boost"). Думаю, можно погуглить историю плюсового кода в адаптековском драйвере, чтобы выудить мнение разработчиков Linux конкретно о перспективах использования C++ в этом ядре.<br><br>&gt;А с завалами в багтрекере, это нормальное явление.<br><br>О чём и спич.<br> https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#24 Fri, 14 Sep 2007 07:42:05 GMT &gt;&gt;И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие <br>&gt;&gt;между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.<br>&gt;Когда увидел этот опус, сразу дежавю ощутил... Где же я это уже <br>&gt;видел? Точно, в книжке Торвальдса "Just for Fun".<br><br>Именно. А у меня было дежавю, когда этот кусок читал -- поскольку там было обёрнуто в слова то ощущение, которое возникло от "исторического спора".<br><br>&gt;"Простота, обеспечиваемая микроядром, является мнимой." <br>&gt;Так вот, исходники Minix3 (с КОММЕНТАРИЯМИ) помещены в книгу (в русском издании <br>&gt;на CD), и их вполне можно ЧИТАТЬ и досконально изучить за семестр.<br><br>Дальше-то что? Счётные палочки тоже можно досконально изучить за старшую группу ползункового отделения. Вот только сами палочки потом бесполезны, а навыки претерпевают множество трансформаций для того, чтобы стать полезными. При этом таки да, становясь не передаваемыми непосредственно оной группе.<br><br>(домашнее задание: рассчитаться за покупки наличностью с примен https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#23 Fri, 14 Sep 2007 06:11:38 GMT &gt;И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.<br><br>Когда увидел этот опус, сразу дежавю ощутил... Где же я это уже видел? Точно, в книжке Торвальдса "Just for Fun". Там он отжигал про "человеческий мозг" и "усложнение взаимодействия в микроядре":<br><br>"Мне это казалось глупым. Да, каждая отдельная часть получается простой.<br>Но при этом их взаимодействие становится гораздо более сложным, чем при<br>включении ряда сервисов в состав ядра, как это сделано в Linux. Представьте<br>себе человеческий мозг. Каждая его составляющая проста, но их взаимодействие<br>превращает мозг в очень сложную систему. В этом-то все и дело: целое больше<br>частей. Если взять проблему, разделить ее пополам и сказать, что каждая<br>половинка вполовину проще, то при этом вы игнорируете сложность интерфейса<br>между половинками. Сторонники микроядра предлагали разбить ядро на пятьдесят<br>независимых частей так, чтобы каждая https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#22 Fri, 14 Sep 2007 05:49:42 GMT Если в языке есть какая-то конструкция, то это не значит, что вы обязаны его использовать.<br>Я тоже считаю множественное наследование извращением. В природе ведь как, можно конечно скрестить осла с лошадью, но сие творение (мул по моему называется) потомков иметь не может. <br><br>В этом смысле С++ лишнее подтверждение этому. Для того, чтобы классы с множественным наследованием хоть как-то жили Бъярну пришлось ввести в язык кучу сущностей, которые в обычных языках бессмыслены и бесполезны. И все равно, попытка использовать этот инструмент на этапе проектирования приводит к тому, что при реализации вплывают системные конфликты, которые невозможно было предусмотреть на этапе проектирования. <br><br>А с завалами в багтрекере, это нормальное явление. Это говорит о том, что продукт живет и развивается. Было бы странно если бы этого не было, учитывая, что людей, которые были бы материально ответственны за оперативное исправление ошибок нет. <br>Во многих организациях где есть такие люди, завалы багрепортов тоже обычное явлени https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#21 Fri, 14 Sep 2007 04:37:34 GMT Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло. Там можно боком приспособить структуры как дешовую подделку обьектов. Но самих обьектов на С небыло. Не заставляйте меня сомневаться.<br>У-у-у. Настоятельно рекомендую почитать книгу про компилятор GCC, ну и по С тоже.<br>Что касается kobject - они пишутся на С, так указанно в книжке Лава "Программирование ядра Линукс"<br> https://mobile.opennet.me/openforum/vsluhforumID3/38394.html#20 Fri, 14 Sep 2007 04:33:07 GMT Ну-ну. <br>Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского. И к сожалению привлечение только программистов непозитивно. Но - тестировать можно на любом языке, и на С и на С++. Компонентный подход - ну может и поможет. Надо править стратегию, управлять этим процессом некому. Не может Линус управлять этим процессом, не может или не хочет. А вот управленца по лицензии GPL найти наверное невозможно. <br>Так что скорее всего дело в этом. Надо четко разделять, это пишем, это тестируем, это доводим до кондиции, это в ядро включаем для работы. И все будет хорошо.<br>