Система разработки ядра Линукса даёт сбои

> А с чего вы взяли, что человек про Виндовс излагает?

С того, что прочитал его пост полностью :-P

> С того, что прочитал его пост полностью :-P

Блин, ну прочитайте ещё раз. Внимательнее. Вот же он что пишет: "поменял комп - сноси винду"

Т.е. У него был комп, под управлением некоей ОС. Он его поменял. Естественно новый пришёл с виндой, потому что с предустановленным QNXом у нас пока компы далеко не в каждом ларьке продают. Вот и жалуется человек, что каждый раз ему приходится сносить винду.

> него был комп, под управлением некоей ОС

А, так это упражнение в формальной логике... а я думал, здесь люди общаются.

>Есть другая версия... yfcrjkmrj z gjvy. предыдущие посты klalafluda у >qnx6 нет проблем в плане использования на desktop. Просто фирма -

Видете ли, я совершенно не спорю с тем что этот десктоп работает у
него лично. Проблема в том что это самое "общее назначение" предпологает что работать оно будет еще у многих миллионов человек для решения совершенно разных задач. _Предусмотреть_ как и что в этом случае будет пока никому не удавалось. Все GPOS прошли болезненный путь роста, когда от появления новых классов решаемых задач в связи с распостранением приходилось фактически полностью переделывать эту самую архитектуру ядра. Реально, QNX у этих самых миллионов "общих задач" не использовался. Это значит что и _ВЫЯВИТЬ_ эти самые
дефекты шанса не было.

>разработчик не хотела его распространять под это дело. Время упущено. >Поздно спорить. Что есть, то и имеем, но это не значит что qnx не может >использоваться под desktop - я не вижу технических проблем.

Вы не видите. И klalafluda не видит. И я не вижу, но потому что реально не вижу QNX "в жизни". А вот спорящие с ним люди видели и приводили примеры. Вполне можно предположить что таких людей _при широком распостранении_ в среде пользователей "в терминах Столлмена" может оказатся непомерная куча.

И лично мне кажется - но это чистое ИМХО, что фирма-разработчик QNX как раз таки _попробовала_. Я следил за процессом исключительно по сообщениям желтой прессы, и вникать в детали не стал. Но я прекрасно помню и начальный релиз этой самой "магической дискетки" и последовавшее распострание ее в среде программистов. Вскоре портировали KDE, учитывая ембеддет корни QT там вообще был почти изначально.

И мне кажется что эти самые товарищи, которые начали "щупать" QNX, и наткнулись на те самые проблемы, которые потребовали нового _полноценного_ цикла разработки с редизайном архитектуры. А фирма оценила что такой редизайн (в ее условиях !) потребует либо просто мегаденег либо мегаденег и форка. Так как нужно было совместить _устоявшиеся_ и _весьма суровые_ требования реальных кастомеров и потребности FOSS сообщества вокруг системы. И это в фирме которая занимается таким щепетильным рынком где ее продукты стоят на всяких опасных обьектах. Да там у менеджмента В ПРИНЦИПЕ_ заморочки такие, какие нам и не снились.

А ведь эта проблема вполне себе известна фирме-разработчику QNX так как перед их глазами были невеселые примеры и университетских разработок, и Mach3, и NT3.5.

Так что мое ИМХО это не то что они "время профукали" а то что поняли что жопа и рисковать не стали.

>> Скорее уж тогда возвысимся, поскольку микроядерность стоит на более высокой ступени эволюции :-)

> Да. на более высокой. тупиковой.

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

Безвыходных ситуаций не бывает http://www.migrationforunix.com/ http://support.microsoft.com/kb/314458

Можно ставить оценки и камменты, правда камменты не открыты

> Безвыходных ситуаций не бывает http://www.migrationforunix.com/ http://support.microsoft.com/kb/314458

> Можно ставить оценки и камменты, правда камменты не открыты

Тема сисек^W удаления Linux раскрыта полностью. Ждём wiki-страницу с подробны описанием rm -rf /mnt/windows :)

> Там был смайлик. Вам видимо просто не снижали оценку за ответ про "два уровня защиты" (студент-то помнит, что есть kernel/user) вместо "четырех" (как в спецификации i386, surprise!).

Студент помнит, что есть 0 и 3 кольцо (а это он обязательно помнит, если преподаватель рассказывает что есть "кольцо"), его это сильно смущает, потом он находит куда дели 1 и 2 в IA-32 или спрашивает у того, кто уже нашел. Так что тут неправильно ответить сложно. А если вы рассказываете о каких-то "уровнях защиты" и забываете это все свети к 2м битам, то как студент должен эти кольца считать?

> Как бы не силен насчет вима. Емакс очень даже катит под иде.

Почти согласен. Ни Emacs, ни Vim не содержат в себе ни отладчика, ни компилятора, ни системы управления версиями, ни UML редактора. Так что в соответствии с моими представлениями об IDE, я бы их IDE не называл. Зато пользователь своими личными телодвижениями может построить на основе этих текстовых редакторов и др. приложений IDE. Зачастую очень гибкую и удобную.

> Таскание контролов с панелки на форму

Делать проекты с трехуровневой архитектурой с ними достаточно сложно, зато люди на билдерах достаточно быстро умеют клепать прототипы. Сам этому искусству еще не научился, но думаю попробовать ))

> А разметку теха в делфишном редакторе - править не удобно.

Однажды в журнале LXF прочел про DocBook - документация пишется в xml, затем простым движением руки конвертируется в rtf, txt, tex, man, pdf, ... Я сам почти случайно о нем узнал, очень понравилось.

> На FreeBSD, родной ты мой, на фри... Фря - наиболее продвинутая и универсальня *BSD. А всякие форки типа MirBSD DragonflyBSD Debian etc можно вобще не рассматривать.

Debian - fork FreeBSD? Я удивлен.

> не удобен для автопродолжения и поиска функций струткур и так далее

ctags, cscope

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

В случае С : gcc с опцией -g, затем любимым отладчиком. Можно gdb, мне как-то kgdb ближе.

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

Все есть, просто нужно было искать, а не смотреть в сторону VS.

> Программист с ВисуалС мне кажется с большой неохотой перейдет разрабывать на Linux. <skipped> а потом при необходимости портируют под Линукс.

Если переходить с Visual Studio на Eclipse или комбинацию vim + компания, то привыкать пришлось, а обратно уже не тянет. Если с Windows на Linux, то как-то тоже ничего сверхсложного нет. А если использовать Java или Qt/GTK, то и портировать особо ничего не придется. Если посмотреть на OO, Firefox, Gimp, etc - то окажется, что Linux проекты портируют под Windows.

> У линукс - монолитное ядро. Учите матчасть. А микроядро, к примеру, у мастдая.

Правда? И там все драйверы в userspace?

> Так вот дебаггер в голове рулит. > no-dashi

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

Не проще ли воспользоваться дебагером и, как минимум локализовать функцию, содержащую ошибку.

Многопоточность отдельная тема, но там дебагер тоже может экономить время.

>> Led> Ну и где же "графика в Линухе"?

В X.

> В ядре, но её оттуда легко удалить (вырубаем Frame Buffer ;) ).

Это не то, что я привык называть словом "графика".

> Кстати, drm, nvidia.ko можно считать "графикой в Линухе"? Дык, ото тоже как бы в ядре.

nvidia.ko - это драйвер видео-карты. Или вы непосредственно с его помощью создаете графические окна?

>> только писать его должны не люди вроде Торвальдса, а доктора наук и их ассистенты в роли кодеров, иначе ничего путного не выйдет.

> Они умеют писать ядра лучше ветеранов этого дела, ага.

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

> Таких, как ты, называют "armchair coder" (что-то вроде "пикейного жилета").

Ты что-то имеешь против GNU-той идеологии разработки софта, с теоретически максимальным реюзом готовых наработок?

> Рейсы есть всегда, это не признак плохого программирования

Вы дебил. Пример ниже - типичный race:

#include <stdio.h>
#include <unistd.h>

int main() {
    if (fork()) {
        puts("parent pid =");
    } else {
        puts("child pid=");
    }
    printf("%d",getpid());
    return 0;
}

А вот здесь уже нет race - но только при условии что
процесс вывода внутри printf на stdout атомарный.

#include <stdio.h>
#include <unistd.h>

int main() {
    if (fork()) {
        printf("parent pid = %d", getpid());
    } else {
        printf("child pid = %d", getpid());
    }
    return 0;
}

Race condition как раз и есть последствие ошибки в коде.

чо охать и ахать над 2.6 ядром, есть и развиваецо 2.4

А может действительно стоит посмотреть в сторону MINIX 3? Я её немножко посмотрел, понятное дело, что она еще сырая, но идея заложеная в ней хорошая...

Пойду более подробнее на неё погляжу. Тем более что исходники все с нормальными комментами...