Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Переношу в Прочее из Философии программирования.
Если начнётся неконструктивный флейм, топик будет удалён. Если будет что интересное, вернём его в Философию.
Право называться "философским топиком" надо заработать!
Здравствуйте RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Здравствуйте RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
"Если звезды зажигаются на небе, значит это кому-нибудь нужно..."
Здравствуйте RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Java вам поможет (может быть).
Как правило Linux — это серверная платформа для Интранет/Интернет.
На серверных платформах (иногда используют Win2000, как правило, работают сервера приложений.
Сервера приложений, как правило, поддерживают Java2 Platform Enterprise edition(J2EE), в частности, Enterprise JavaBeans(EJB — далёкий аналог COM+, но для Java), Java Server Pages(JSP/Servlets).
Итак, Java, благодаря своей многоплатформенности (Windows, Linux, UNIX, MacOS, Netware, VMS,etc.) сегодня представляет единственную независящую от железа платформу, на которой работают около 70% приложений бизнеса.
Конечно, есть сервера приложений и для технологий от MS (DCOM, COM+, ASP, ASP.Net), но они используются ТОЛЬКО на платформе WINTEL и не имеют никакого отношения к Linux.
Сервер приложений MS Windows.NET Server пока находится в стадии разработки.
Microsoft прихлопнула еще трех «клопов»
Джо Уилкокс (Joe Wilcox), CNET News.com
18 октября, 2002, 10:58
<...>
Эти предупреждения пополнили длинный список секьюрити-бюллетеней Microsoft. В начале месяца компания исправила другие ошибки в SQL Server и во всех версиях Windows, а также предупредила об уязвимости Outlook Express. С начала года Microsoft распространила 61 предупреждение об ошибках — это немного больше, чем за весь 2001 год.
В тот же день Microsoft признала факт взлома своего веб-сервера, которым пользуются 20 тыс. бета-тестеров Windows, и порекомендовала им сменить пароли.
Здравствуйте iZEN, Вы писали:
ZEN>Здравствуйте Алекс, Вы писали:
А>>Linux — MUST DIE!
ZEN>Что сегодня? ZEN>Смотрим: http://zdnet.ru/?ID=289922 ZEN>Чт мы видим: ZEN> ZEN>Microsoft прихлопнула еще трех «клопов» ZEN>Джо Уилкокс (Joe Wilcox), CNET News.com ZEN>18 октября, 2002, 10:58 ZEN><...> ZEN>Эти предупреждения пополнили длинный список секьюрити-бюллетеней Microsoft. В начале месяца компания исправила другие ошибки в SQL Server и во всех версиях Windows, а также предупредила об уязвимости Outlook Express. С начала года Microsoft распространила 61 предупреждение об ошибках — это немного больше, чем за весь 2001 год. ZEN>В тот же день Microsoft признала факт взлома своего веб-сервера, которым пользуются 20 тыс. бета-тестеров Windows, и порекомендовала им сменить пароли.
Вообщем Денис же писал, что флуда то не нада. А это флуд, что первое, что второе сообщение.
Можете что хотите говорить о багах в Linux но для них достаточно
быстро выпускаются Update-ы. Тогда как MS баги мусолит годами
Вот 2 сообщения с BugTrack сравните даты
Microsoft: опять двойка.
01.04.02 10:20
Т.е. дырка. Хорошая такая, связанная с подсистемой отладки WindowsNT и
Windows2000. В результате, любой пользователь, даже с самыми
минимальными привилегиями (GUEST, например), сможет выполнить код с
правами администратора. Пример можно посмотреть здесь, а "лекарство" взять
тут.
Источник: PCWorld
Бага в дебаггере
28.05.02 08:16
Microsoft выпустила очередной бюллетень, посвященный
обнаруженной в отладчике Windows NT и Windows 2000
ошибке. Ошибка позволяет пользователю, имеющему доступ к
системе, повысить уровень своих привилегий.
Источник: newsfactor
Дак вот Microsoft-у понадобилось 2 месяца чтобы поправить
баг который они сами оценили как Critical, хотя люди которые
его нашли дали защитную фиговину прямо вместе с ним.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Алекс, Вы писали:
А>Здравствуйте RonWilson, Вы писали:
RW>>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
А>Linux — MUST DIE!
Мля, ну говорят же Windows — MUST DIE. Почему Linux нельзя? Или я забыл рожицу поставить?
В принципе ожидал подобную реакцию, но что столько нулей и сразу! Е-мое! Похоже на цензуру!
Я ведь нигого не оскорбил, выражался прилично, кратко, словом не нарушил ни одного правила. И что? Цензура!
Ну просто у меня хорошее настроение с утра было, и просто я забыл наставить рожиц ( )
Давайте, уважаемые дяди, либо уберем нолики, либо обоснуем вашу позицию!
Начнем со свеженайденного страшного Windows-бага, против которого вроде
как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая
программа может послать любому окну любое сообщение (на самом деле, с
некоторыми оговорками, о которых позже), при этом источник сообщения
определить невозможно. Так было заведено давным давно, и даже не с NT 3.5
(3.1 на самом деле), как пишет автор сообщения, а со старого доброго
16-битного Windows — потому как смена этого механизма привела бы к не
самым большим, но все же проблемам по переносу старого 16-битного софта
под Win32 (если кто не помнит, для перехода индустрии под Win32
потребовался выход Windows'95, до тех же пор многие производители софта
особо и не утруждали себя этим переносом).
Итак, схема взлома. Находим подходящий сервис, исполняющийся из-под
аккаунта, с бОльшими правами, чем наш текущий, который будет способен
принимать оконные сообщения, что мы ему собираемся посылать (грубо
говоря, способный открывать окна . Находим в окне, открытом сервисом,
подходящий элемент управления (edit box) и вставляем туда побольше
символов, включающих в том числе внедряемый код (между делом для этого,
возможно, придется снять ограничение на количество символов, которые
можно вставить в текстовое поле, но и это можно сделать, послав сообщение,
так что это непринципиально). В итоге все это хозяйство оказывается где-то в
недрах адресного пространства данного приложения. Где именно — можно
определить экспериментальным путем, вставив в текст некую сигнатуру и
найдя ее с помощью отладчика. Далее внедренный код надо бы как-то
выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве
одного из параметров которого можно указать адрес callback-функции. Стало
быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших
засланных команд, после чего наш засланный код выполняется с правами того
аккаунта, из-под которого был запущен сервис, если повезет — с системными. Из
вышесказанного делается вывод о наличии принципиальной уязвимости
системы передачи сообщений Windows и затягивается очередная песня про
мастдай, потому как MSовцы ничего в ней не хотят менять.
Сразу скажу свое мнение о данной уязвимости. Схема хороша и заслуживает
занесения в список проверяемых потенциальных уязвимостей отдельных
сервисов (по сути это действительно новый класс уязвимостей, аналогичный
buffer overflow), но говорить о жуткой принципиально неизлечимой дырке
рановато. Полный запрет приема сообщений от всех сторонних процессов,
пожалуй, не имеет смысла и потому нереален. Конечно, наличие
идентификатора источника сообщения могло бы пригодиться при
программировании, но и в этом случае его анализ требовал бы усилий со
стороны программиста. К тому же, добавление к сообщению информации об
источнике приведет к необходимости перетряхнуть весь существующий софт,
потому как просто так добавить опциональный параметр в оконную функцию
вряд ли удастся. Наконец, подобная радикальная смена существующего API
просто не нужна, поскольку начиная с NT 3.51 существует вполне рабочий
механизм Window Stations и Desktops, созданный, по утверждению MSDN, в
первую очередь именно для разработчиков интерактивных сервисов и
обладающий всеми средствами по разграничению доступа.
Итак, какие средства у нас есть на руках, чтобы бороться с данной проблемой.
Во-первых, рабочие станции и десктопы, у которых с защитой все в порядке —
сервис, к примеру, вполне в состоянии создать окно, которое будет
выполняться в контексте текущего пользователя. Во-вторых, даже если забыть о
десктопах, есть вполне стандартная схема, обеспечивающая взаимодействие
сервиса с пользователем — написание вспомогательной программки,
запускающейся с пользовательскими правами и тем или иным способом
взаимодействующей с сервисом (по уму — с помощью защищенных объектов
ядра). Далее, не совсем верно утверждение, что WM_TIMER не попадает в
очередь сообщений и его нет возможности игнорировать — цитируя MSDN,
"You can process the message by providing a WM_TIMER case in the window
procedure. Otherwise, the default window procedure will call the TimerProc callback
function specified in the call to the SetTimer function used to install the timer.".
Желающие могут проверить — без какого-никакого цикла обработки сообщений
никакой callback от таймера работать не будет, а стало быть, вставить свою
обработку таки можно. Другой вопрос, кто этим озаботился — тем более что в
оконную функцию сообщение все же не попадет, и проверку придется
встраивать непосредственно в цикл обработки сообщений. Наконец, особые
параноики наподобие авторов PGP, вообще не используют стандартные классы
окон и до кучи используют дополнительный драйвер, защищающий память
приложения.
Таким образом, из общесистемной проблема все-таки переходит в разряд
проблем авторов сервисов, на которых и надо перевести стрелки — в конце
концов, и в проблеме постоянно вылезающих buffer overflow можно обвинять
создателей C, но это нефункционально Вот если б в примере оказался
какой-нибудь стандартный сервис, это было бы гораздо интереснее. Однако ж
ситуация вовсе не безоблачна. Написав этот абзац, полез смотреть, что
творится у меня под носом — увы, сходу нашлась пара примеров, Outpost и
MDaemon, которые, похоже, ведут себя так же. К чести Norton Antivirus, тот
запускает отдельную программку с пользовательскими правами. Видимо, в
целом картина не сильно успокаивающая и можно найти немало других
популярных сервисов, которые можно поймать на эту уловку.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
A>(Источник bugtrack.ru)
A> Начнем со свеженайденного страшного Windows-бага, против которого вроде A> как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая
Ну вот Ё-маё. Понеслось. Это видь не канструктив. Суть вапроса была не в том...
Здравствуйте Anatolix, Вы писали:
A>(Источник bugtrack.ru)
[]
Для того, чтобы просмотреть что-либо в чужом процессе ты должен иметь права PROCESS_VM_READ. Ты их не получишь для системных процессов, если не будешь иметь привилегий (которую еще включить надо) SE_DEBUG_NAME. По умолчанию юзера не имеют этой привилегии.
Ну предположим ты админ. Сообщение WM_SETTEXT пересылает текст, а не двоичные данные. Ну ладно, ты написал код, в котором нули не встречаются . Ты каким-то образом посылаешь сервису сообщение о нажатии кнопки, он считывает строку во внутренний буфер.
И чего? Ты будешь сканировать адресное пространство процесса пока не найдешь свою сигнатуру? И сколько ты это будешь делать?
Здравствуйте Anatolix, Вы писали:
A> найдя ее с помощью отладчика. Далее внедренный код надо бы как-то A> выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве A> одного из параметров которого можно указать адрес callback-функции. Стало A> быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших A> засланных команд, после чего наш засланный код выполняется с правами того A> аккаунта, из-под которого был запущен сервис, если повезет — с системными.
Может я чего не понимаю — но кто сказал что попытка выполнить код в странице, в которой находяться данные контрола не приведет к исключению?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Алекс, Вы писали:
А>>В принципе ожидал подобную реакцию, но что столько нулей и сразу! Е-мое! Похоже на цензуру!
AVK>Ты еще попробуй сказать "С++ — маздай"
Не, С++ я уважаю!
Мля, RSDN'овцы совсем, по моему, заработались. Стоит рожу не поставить сразу в штыки.
Здравствуйте Алекс, Вы писали:
А>И чего? Ты будешь сканировать адресное пространство процесса пока не найдешь свою сигнатуру? И сколько ты это будешь делать?
Нет она вполне возможно будет всегда выкладываться по одному и тому же адресу,
а его можно на своей машине узнать дизассемблером.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Anatolix, Вы писали:
A>> найдя ее с помощью отладчика. Далее внедренный код надо бы как-то A>> выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве A>> одного из параметров которого можно указать адрес callback-функции. Стало A>> быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших A>> засланных команд, после чего наш засланный код выполняется с правами того A>> аккаунта, из-под которого был запущен сервис, если повезет — с системными.
AVK>Может я чего не понимаю — но кто сказал что попытка выполнить код в странице, в которой находяться данные контрола не приведет к исключению?
Кстати да, это тема.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Хитрик Денис, Вы писали:
ХД>Переношу в Прочее из Философии программирования. ХД>Если начнётся неконструктивный флейм, топик будет удалён. Если будет что интересное, вернём его в Философию.
Накаркал!
ХД>Право называться "философским топиком" надо заработать!
Здравствуйте AndrewVK, Вы писали:
AVK>Может я чего не понимаю — но кто сказал что попытка выполнить код в странице, в которой находяться данные контрола не приведет к исключению?
Рихтер пишет, что на x86 и Alpha аттрибут PAGE_EXECUTE не поддерживается. ... Перечисленные процессоры воспринимают запрос на чтение как на исполнение...
Здравствуйте Алекс, Вы писали:
А>Мля, ну говорят же Windows — MUST DIE. Почему Linux нельзя? Или я забыл рожицу поставить?
А>В принципе ожидал подобную реакцию, но что столько нулей и сразу! Е-мое! Похоже на цензуру!
А ты попробуй тоже про Windows сказать. А потом посчитаем нули и вичислим коэфицент предвзятости.
А>Я ведь нигого не оскорбил, выражался прилично, кратко, словом не нарушил ни одного правила. И что? Цензура!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
А>>В принципе ожидал подобную реакцию, но что столько нулей и сразу! Е-мое! Похоже на цензуру!
AVK>Ты еще попробуй сказать "С++ — маздай"
Да! Дельный совет. Но учти в этом форуме это будет офтопик. Так что пиши в С++. И не цитируй ничего, а то в оверквотинге обвинят.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Anatolix, Вы писали:
A>Здравствуйте Алекс, Вы писали:
А>>И чего? Ты будешь сканировать адресное пространство процесса пока не найдешь свою сигнатуру? И сколько ты это будешь делать?
A>Нет она вполне возможно будет всегда выкладываться по одному и тому же адресу, A>а его можно на своей машине узнать дизассемблером.
Еще про WM_TIMER.
Попробовал я вызвать
SendMessage(hWnd,WM_TIMER,0,(LPARAM)timerproc);
Нифига не вышло. Пишет The handle is invalid. Видимо, проверяется внутренний список установленных таймеров, которые имеют процедуру обработки, (а может быть это асоциативный массив?) и если соответствие не найдено — юк!
И вообще странно в MSDN написано If you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER.
Однако из опыта знаю, что никакая WinProc не вызывается. Вместо нее вызывается TimerProc. Это подтверждает следующая фраза из того же MSDN (из документации на DispatchMessage()) If the lpmsg parameter points to a WM_TIMER message and the lParam parameter of the WM_TIMER message is not NULL, lParam points to a function that is called instead of the window procedure.
А событие это генерит GetMessage(). При чем только в том случае, если в очереди потока установлен флаг QS_TIMER (т.е. имеется необходимость обработать сообщения от таймера). Установить это флаг вручную документированным способом нельзя. И даже если удастся, нет гарантии того, что DispatchMessage() не поведет себя также как и DefWindowProc(), т.е. не вернет код ошибки 6.
Здравствуйте, Anatolix, Вы писали:
A>(Источник bugtrack.ru)
A> Итак, схема взлома. Находим подходящий сервис, исполняющийся из-под A> аккаунта, с бОльшими правами, чем наш текущий, который будет способен A> принимать оконные сообщения, что мы ему собираемся посылать (грубо A> говоря, способный открывать окна . Находим в окне, открытом сервисом, A> подходящий элемент управления (edit box) и вставляем туда побольше A> символов, включающих в том числе внедряемый код (между делом для этого, A> возможно, придется снять ограничение на количество символов, которые A> можно вставить в текстовое поле, но и это можно сделать, послав сообщение, A> так что это непринципиально). В итоге все это хозяйство оказывается где-то в A> недрах адресного пространства данного приложения. Где именно — можно A> определить экспериментальным путем, вставив в текст некую сигнатуру и A> найдя ее с помощью отладчика.
А без отладчика? Слабо? На словах все очень просто...
A> Далее внедренный код надо бы как-то A> выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве A> одного из параметров которого можно указать адрес callback-функции. Стало A> быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших A> засланных команд, после чего наш засланный код выполняется с правами того A> аккаунта, из-под которого был запущен сервис, если повезет — с системными.
С чего это он будет выполняться? Подробнее можно? Таймер будет думать, что его функция в адресном пространстве твоего процесса. К тому же код твоец пресловутой функции будет находиться в сегменте данных, а не кода, забыл? Хотя и возможно сделать программу с кодом в секции данных (сам писал такие на асме), но в данном случае не уверен, что сработает, все же это данные системного контрола...
А серьезно — этот баг использовался?
Здравствуйте, Алекс, Вы писали:
А>Здравствуйте RonWilson, Вы писали:
RW>>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
А>Linux — MUST DIE!
Батенька.... умерьте свое либидо..... данные высказывания для мальчиков только познакомившихся с компутером....
Здравствуйте, Adekamer, Вы писали:
А>>Linux — MUST DIE! A>Батенька.... умерьте свое либидо..... данные высказывания для мальчиков только познакомившихся с компутером....
Добро пожаловать в наш форум! Это ведь твой первый постинг.
Как тебе понравится такая ситуация: в твою большую компанию, в которой ты всех знаешь, приходит неизвестный человек и первая фраза, которой он бросается, — это "умерьте свое либидо..."?
Я бы с таким человеком разговаривать не стал. Постарайся быть тактичнее и конструктивнее. В Правилах есть пункт о неуважении других участников форума и о манерах поведения вообще.
Что насчёт Алекса, то ты ошибся на его счёт. Он давно на форуме, многим помогает решать проблемы. Думаю, что своим постингом он просто сознательно спровоцировал народ. За что и получил тучу нулей в свой адрес
Здравствуйте Adekamer, Вы писали:
А>>Linux — MUST DIE!
A>Батенька.... умерьте свое либидо..... данные высказывания для мальчиков только познакомившихся с компутером....
Linux Must Die
Windows Must Die
Программирование масдай
Компьютеры масдай
Телевизор масдай и сакс
Асфальт масдай
Куплю водки и уеду на природу бухать, ибо это самый что ни на есть мастлив и рулез форева!
Здравствуйте, AndrewVK, Вы писали:
AVK>Linux Must Die AVK>Windows Must Die AVK>Программирование масдай AVK>Компьютеры масдай AVK>Телевизор масдай и сакс AVK>Асфальт масдай AVK>Куплю водки и уеду на природу бухать, ибо это самый что ни на есть мастлив и рулез форева! AVK>
Здравствуйте, AndrewVK, Вы писали:
AVK>Linux Must Die AVK>Windows Must Die AVK>Программирование масдай AVK>Компьютеры масдай AVK>Телевизор масдай и сакс AVK>Асфальт масдай
AVK>Куплю водки и уеду на природу бухать, ибо это самый что ни на есть мастлив и рулез форева!
Антил скорый маздай because of because of because of one man! и хренового самогона.
Здравствуйте zeus, Вы писали:
AVK>>Куплю водки и уеду на природу бухать, ибо это самый что ни на есть мастлив и рулез форева! AVK>>
Z>От водки печень MUST DIE.
-- Мы — нигилисты-поисты-маздаисты! Все вокруг маздай!
-- Винда маздай?
-- Маздай.
-- А Линукс?
-- Линукс маздай.
-- И девки маздай?
-- Нет, девки не маздай.
-- Но ведь неувязочка выходит?
-- А неувязочка маздай!
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Куплю водки и уеду на природу бухать, ибо это самый что ни на есть мастлив и рулез форева! AVK>>>
Z>>От водки печень MUST DIE.
AVK>MAY DIE
MIGHT DIE
AVK>Отсутствие тормозов масдай.
При отсутствии тормозов will be dead.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, RonWilson, Вы писали:
RW>Слушайте, кто может что-нибудь сказать серьезного о программировании под Linux? Народ чего-то шевелится всякими там Kylix-ами и GNU C — а толку мало..... Надо ли все это????
Извиняюсь за поздний ответ, но надеюсь он Вам поможет
Итак ответ:
НАДО!!!
Но нужно, как и в любой отрасли программирования, найти свою нишу. В данный момент, с моей точки зрения наиболее перспективной является разработка shareware программ и баз данных. И не надо думать, что *nix — это только open source, ничего подобного. Shareware выгодно из-за того, что пользователи *nix не избалованны всяческими органайзерами, часиками и прочими полезняшками, и самое главное — они согласны за это платить (и платят)! Что бы не говорили о том, что *nix — это не домашняя система, она все-таки стоит у очень многих. Причем сейчас просматривается весьма интересная тенденция — многие конторы начинают постепенно переходить именно на linux, из-за его бесплатности, т.к. далеко не все хотят покупать Windows, MS офис, кучу приложений, необходимых в работе и прочее, а под Linux большинство подобных приложений все-таки бесплатно. Но вот этот переход как раз и дает второй пункт (базы данных) — им же понабодятся всё те же бухгалтерсие базы данных, генераторы отчетов и тому подобная радость.
Что касается средств разработки, то не надо относиться к ним с пренебрежением. GCC — имхо один из лучших компиляторов С, ничем не уступающий VC. Для любителей Pascal есть FreePascal — полная совместимость синтаксиса с TP 7.0, поддерживаются некоторые конструкции delphi, хотя тут ничего определенного сказать не могу, пишу все-таки на си. Среды разработки тоже есть (мне, например оч нравится KDevelop ). SQL серверов на порядок больше, чем под win, и они достаточно удобны, а MySQL работает даже пошустрее MS SQL 2000.
Web-приложения (имхо) по *nix создавать даже удобнее: PHP, Perl, Java, Python + одна из систем автоматизации разработки на выбор MidGard, BLADE или Zope. С последней не работал, а из первых двух, имхо вторая удобней.
Если так уж нужна .NET, то сейчас уже осуществляется её перенос на FreeBSD, ну а с неё уже не очень сложно спортировать и на Linux. (Кстати, команда Red Hat этим уже, кажется, занимается).
Так что поле для деятельности есть и, что приятно, работу найти довольно просто (по крайней мере в Питере не сложнее чем программисту под Win)
PS Ну и шпилька напоследок: интерфейс под иксы программировать много проше и приятней, чем под GUI, хотя это наверно из-за того, что я их лучше знаю
, как правило, работают сервера приложений.
Е-мое! Похоже на цензуру!
Перекуём баги на фичи!
исты-маздаисты! Все вокруг маздай!
Если нам не помогут, то мы тоже никого не пощадим.
