EL[michlen]

Поддерживаю. У меня та же ситуация, только парк компьютеров, похоже, поменьше. В нашем случае мы занимаемся разработкой специализированных приложений для Windows, Linux, xBSD и PocketPC. И тоже не испытываем проблем в работе с какими-либо из этих ОС. С точки зрения разработки есть преимущества у всех перечисленных систем. Есть и недостатки. Так, например, весьма неприятно (только на мой взгляд) сделана поддержка UI в WinAPI для языка C++. Гораздо удобнее был бы объектно-ориентированный интерфейс типа Linux-ового QT. Но в то же время, при программировании на ассемблере, лучше WinAPI в этой области мало что существует на данный момент. Да и работает QT медленнее. Все это - как пример. Если для себя вы выбираете одну систему, вы можете сказать, ПОЧЕМУ. Так вот, если ваш сосед использует другую ОС, то он тоже может это обосновать в той или иной степени, я не сомневаюсь. sergeygs правильно сказал: будьте терпимее к чужому выбору. P.S. Просто ради интереса: что это за софтина такая за $90 000?

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

По сравнению с tar.gz - возможно. Но по сравнению с rpm - не согласен. Да и приятней мне работать с dselect в качестве интерфейса, нежели писать ручками команды (хотя, кому как больше нравится), тем более, что там сразу все зависимости отслеживаешь и т.п. И не надо упрекать меня в том, что, мол, из консоли оно быстрее и т.п. - я все это прекрасно знаю, сам пользуюсь постоянно. А если сравнивать dselect с KDE-шным менеджером пакетов (не помню, как там его, kpackage, кажется), то dselect симпатичней получается. Но на вкус и цвет - давайте все дружно ставить из исходников! =)

Самый простой и логичный способ - использовать сокеты или следить за PID-ом. Можно сделать двухпоточного ребенка, где один поток следит за PID-ом родителя (getppid() в цикле), а другой ждет сигнала. Если родитель помер, первый сам посылает второму какой-нибудь сигнал, раз уж надо его разбудить. =) То же самое с сокетами. Еще есть функция atexit() (см. man), но она работает только при нормальном завершении, при сигнале KILL и т.п. она не выполнится. А еще, по-моему, можно использовать select для синхронизации между процессами по pipe-ам.

Есть куча видов IPC: * Полудуплексные каналы UNIX * FIFO (именованные каналы) * Очереди сообщений в стиле SYSV * Множества семафоров в стиле SYSV * Разделяемые сегменты памяти в стиле SYSV * Сетевые сокеты (в стиле Berkeley) * Полнодуплексные каналы (каналы потоков) (см. Linux Programmer's Guide, Scott Burkett) Может синхронизировать это по каналам? Скажем, ребенок изредка спрашивает родителя: "Чувак, ты еще жив?", на что родитель должен ответить: "Да живая я, спокуха!" =) Ну или отслеживать Process ID.

В Debian существует великая программа dselect. Наверняка она есть в этих ста метрах.

Я бы посоветовал прочитать книжку "Linux Device Drivers" (O'Reilly); авторы: Alessandro Rubini, Jonathan Corbet; 573 стр., доступна где-то в инете в виде PDF.

В комментарии к форуму Gentoo Linux опечатка: Цитата: Обсуждение дистрибутивов Dentoo Linux

Цитата: пользователь запустил скрип со своими привелегиями Такое возможно, если пароль для su прописать в самом скрипте. Если боитесь, что юзер будет просматривать текст скрипта, можно записать туда пароль в закодированном виде. Например, методом // Пример на С для наглядности: char *code(char *str2code, char *code2use) { // str2code - строка, которую мы кодируем // code2use - некая строка, которую мы используем в качестве кода while (strlen(str2code) > strlen(code2use)) { strcat(code2use,"A"); // Если длина кода меньше, чем строка, увеличиваем эту длину } for (int i=0; i<strlen(str2code); i++) { str2code = str2code ^ code2use; // Собственно, кодирование =) } return str2code; } /* В данном случае для декодирования строки используется эта же функция. При другом code2use, оригинальную строку мы уже не получим, т.е. нужно использовать один и тот же код для кодирования и декодирования (можно задать его константным, а можно использовать для разных пользователей). */ а при выполнении su декодировать его и передавать на ввод su, таким образом избегая его явного просмотра. Тогда в этом сможет разобраться только программист, хотя это и несложно.

Здесь собрано чуть-чуть: http://michlen.nm.ru/linux_modules.html (скачано с ныне покойного сайта журнала "Программист")

Можно попробовать установить FocusPolicy в значение NoFocus. See QT3 manual (http://www.trolltech.com) for details - there are lot's of samples. P.S. Sorry for english - got no rus keyboard at the moment.

В какой среде? KDE/QT, Gnome/Gtk+, XLib, Java или что?

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

1. OSS и ALSA - драйвера. Драйвер в ядре в Debian bf24 есть драйвер OSS (программа modconf поможет все это настроить). Но чтобы был 5.1-звук, нужна ALSA. 2. 2.4.18 (то, что в Debian woody) не поддерживает запись в ntfs. Ядро 2.6 скачать и поставить можно, но когда я в Debian пытался это сделать, меня обматерили на этапе modules_install, там надо было кое-что подправить ручками. 3. Интерфейс стандартный, только нужно точно знать, какие файлы заменять. Можно отдельно скачать и поставить драйвер на скомпилированное ядро - проблем быть не должно. Надеюсь, помог.