А аз, грешный, вот принадлежу к обеим кастам сразу (а может, ни к одной?). Дело в том, что у нас заказчик определяет, Win или LINUX ставить. Часть заказчиков хотят Win, чаcть — Linux, часть — и то, и другое (Linux — на сервере, Win — на клиентах). Mac OS вот пока никто не хотел :). Так что у меня на ноуте дома и на десктопе на работе стоят обе системы сразу. И к какой касте таких, как я, отнести?
Во-во! Именно — ВПЕРЕДИ! Так и бывает частенько — у Линукса «всё впереди», а заказчик требует здесь и сейчас и ждать, когда добрые дяди решат эти проблемы в некоем будущем отказывается. А в Винде уже здесь и сейчас всё, что требует от тебя заказчик, уже работает
Вообще, за эти годы LINUX сделал большой шаг вперёд по поддержке оборудования. Сейчас подобных проблем всё меньше и меньше. Вот, поставил себе на ноут Russian Fedora Remix 14 (раньше ASP Linux 12 стоял) — всё хорошо работает. Даже представьте себе, есть у меня eSATA-диск, который только под LINUX и работает ( и под АСПом работал, и под Ф14 работает, а Винда долго кряхтит при загрузке, когда он подключен, а потом в результате видеть его отказывается — во как!). Ещё узнать бы, как Skylink EVDO-USB-модем под ним запустить — цены бы ему не было (редко, но нужен иногда бывает)
так ведь эта самая Станция должна была запускаться именно на процессоре клиентского компа, ибо сервер крутит модели в реальном времени и его процессоры перегружать воспрещается. Ну, на крайняк иногда можно пустить и с сервера, но уж не пять-десять одновременно — сама модель отвалится тогда по превышению времени счёта шага (не будет успевать считать в реальном времени). Да я же и говорю, из коробки другого драйвера тогда не было, а Интеловский на тот момент поледний был с багом, который именно в нашей конфигурации и проявился. В IGDE 5.2 было исправлено, но наш поезд уже давно ушёл (тренажёр уже сдали :))
так ведь эта самая Станция должна была запускаться именно на процессоре клиентского компа, ибо сервер крутит модели в реальном времени и его процессоры перегружать воспрещается. Ну, на крайняк иногда можно пустить и с сервера, но уж не пять-десять одновременно — сама модель отвалится тогда по превышению времени счёта шага (не будет успевать считать в реальном времени)
А многие, кстати, и с Винды работали через X-клиента (разработчики тех самых моделей, что крутятся на сервере). Но там опять же — Станции Инструктора написаны были на Яве, и им пофиг, винда у тебя или LINUX (для того на Яве и писали, заказчики разные у нас были, и переносить GUI с Win на LINUX и ещё и IRIX впридачу — ещё та задача). А запусакть эту самую программу под X-клиентом тоже можно, но зачем, когда она просто под Виндой запускается (при этом работает в несколько раз быстрее, чем под X-клиентом). И ещё раз говорю — для поиска и проверки «любого» LINUX нужно потратить изрядно времени и иметь быстрый канал в Интернете. У меня там ещё другой случай был — пришлось откат давать вообще на сервере с RHEL 4 на RHEL 3 (из-за очень медленной работы gettimeofday() на RHEL 4, как потом выяснилось). Так мне пришлось просить родственников, чтобы мне диски RHEL 3.7 отправили поездом и встречать их, ибо по Инету их закачать ещё дольше бы вышло. Специфика ситуации.
Ну так и покупали. И клиентские станции покупали тоже уже с LINUX в комплекте. Однако там же нельзя сказать, что вообще ничего не работало — не работало конкретное разрешение экрана в конкретном неудачном сочетании оборудования. А так с 1920x1200- без проблем, однако круги в овалы растягивались
К тому же, RHEL 4 был куплен (он не бесплатен, между прочим — там подписка на обновления и на техподдержку стоит денег), а RHEL 5 тогда ещё возможности загрузить не было. На поиски и проверки других дистрибутивов требуется время и быстрый доступ к инету, чего не было. Попробуй-ка, когда жареный петух стоит над тобой!.. Ну а так — любое свежее ПО является устаревшим — это один из законов Мерфи для программирования. К тому же, это были клиентские машины (Станции Инструктора), а основное ПО (тренажёр ядерного реактора) крутилось на сервере, где стоял RHEL 4 сервер и прекрасно свои функции выполняет (и до сих пор)
Да, забыл указать, что RHEL 5 тоже не заработал бы в этой конкретной ситуации, ибо драйвер IGDE 5.1 имел баг, не зависящий от дистрибутива LINUX, на который мы и нарвались. Хотя, может, там кто-либо и написал бы другой драйвер именно для этих карт. А времени на разборки и проверки не было — проект идёт. Да и не вышел RHEL 5 ещё на тот момент — RHEL 4 и был последним, а отнюдь не «древним». К тому же, качать и пробовать другую ОС с инета не было возможности — доступ к инету был сильно ограничен по соображениям безопасности. Да и где гарантия, что заработало бы с другим дистрибутивом?
Нет, ошибаетесь. На момент возникновения проблемы RHEL 4 был самым новым — наиновейшим дистрибутивом! Проблема-то возникла аж в 2006 году. Сейчас понятно, что всё это заработало бы. Но для этого тогда надо было бы перенестись в будущее. Так что извините, Ваши обвинения меня в косности мышления безосновательны
Вот привожу пример того, что не заработало (хотя это было года 4 назад, а сейчас именно это заработало бы, но где гарантия, что нет другого подобного?). Вот попал я как-то на одном проекте в такую ситуацию: были заказаны компы с интегрированными видеокартами Intel и DVI-подключением монитора. Драйвера для этих видеокарт в той версии Linux (Red Hat Enterprise Linux Workstation 4) не оказалось — пришлось использовать драйвер VESA. Всё бы ничего, если бы мониторы были 4:3, а они были широкоэкранные — 16:9. Т.е. для корректного изображения графических объектов (т.е. чтобы круг был кругом, а не эллипсом), требовалось установить разрешение дисплея 1920x1080, что было невозможно сделать при использовании драйвера vesa. Тогда я нашёл у Intel-а драйвер, кажется, IGDE 5.1 для этих видеокарт и инструкцию аж из 20 (!!!) пунктов по его установке (а ну-ка представьте себе такое в Windows?). Ну ничего — поставил. Разрешение нужное установил — вроде всё классно. Однако жмём Ctrl-Alt-F1- и всё — чёрный экран вместо текстового терминала и обратно уже не вернёшься. Что делать? Выключаем комп, перегружаемся, лезем на сайт Intel и выясняем, что уже заявлен для этого драйвера такой баг — именно при DVI-подключении первого монитора возникает чёрный экран. Баг НЕ ИСПРАВЛЕН на тот момент. Заказчик говорит, что с такой проблемой ему система не нужна. Ждать, пока Intel выпустит следующую версию драйвера с исправлением этого бага (ну она вышла спустя год, да...) времени нет — проект имеет свои сроки сдачи этапов, а время-деньги. Ваши действия? Возможно два варианта, и все денег стоят:
1. Купить для всех пяти компов видеокарты, для которых есть отлаженные LINUX-драйверы (на тот момент nVidia, например) и тратить время на их замену (причём, не факт, что не влипнешь в похожую историю опять!)
2. Купить пять копий Windows XP, где сразу всё пойдёт без всякого подобного геморроя, благо приложение, с которым работают компы, написано на Java и ему пофиг, Win или Linux им управляет
Естественно, пошли по второму пути, т.е. снесли LINUX и поставили Windows. Так что мы уже знаем, что если заказчик хочет использовать LINUX — надо в расписание проекта отвести время на борьбу с ОС LINUX, ибо никогда не знаешь, куда влипнешь. Так что дело не только в косности, но и в том, что есть сговор на рынке между Microsoft и производителями железа, чтобы в первую очередь поддерживать именно Windows, и многие производители не предоставляют нормальных драйверов под LINUX для своих устройств
Не скажите. Вот «плохая поддержка периферийного оборудования» зачастую мешает. Вот попал я как-то на одном проекте в такую ситуацию: были заказаны компы с интегрированными видеокартами Intel и DVI-подключением монитора. Драйвера для этих видеокарт в той версии Linux (Red Hat Enterprise Linux Workstation 4) не оказалось — пришлось использовать драйвер VESA. Всё бы ничего, если бы мониторы были 4:3, а они были широкоэкранные — 16:9. Т.е. для корректного изображения графических объектов (т.е. чтобы круг был кругом, а не эллипсом), требовалось установить разрешение дисплея 1920x1080, что было невозможно сделать при использовании драйвера vesa. Тогда я нашёл у Intel-а драйвер, кажется, IGDE 5.1 для этих видеокарт и инструкцию аж из 20 (!!!) пунктов по его установке (а ну-ка представьте себе такое в Windows?). Ну ничего — поставил. Разрешение нужное установил — вроде всё классно. Однако жмём Ctrl-Alt-F1- и всё — чёрный экран вместо текстового терминала и обратно уже не вернёшься. Что делать? Выключаем комп, перегружаемся, лезем на сайт Intel и выясняем, что уже заявлен для этого драйвера такой баг — именно при DVI-подключении первого монитора возникает чёрный экран. Баг НЕ ИСПРАВЛЕН на тот момент. Заказчик говорит, что с такой проблемой ему система не нужна. Ждать, пока Intel выпустит следующую версию драйвера с исправлением этого бага (ну она вышла спустя год, да...) времени нет — проект имеет свои сроки сдачи этапов, а время-деньги. Ваши действия? Возможно два варианта, и все денег стоят:
1. Купить для всех пяти компов видеокарты, для которых есть отлаженные LINUX-драйверы (на тот момент nVidia, например) и тратить время на их замену (причём, не факт, что не влипнешь в похожую историю опять!)
2. Купить пять копий Windows XP, где сразу всё пойдёт без всякого подобного геморроя, благо приложение, с которым работают компы, написано на Java и ему пофиг, Win или Linux им управляет
Естественно, пошли по второму пути, т.е. снесли LINUX и поставили Windows. Так что мы уже знаем, что если заказчик хочет использовать LINUX — надо в расписание проекта отвести время на борьбу с ОС LINUX, ибо никогда не знаешь, куда влипнешь. Так что дело не только в косности, но и в том, что есть сговор на рынке между Microsoft и производителями железа, чтобы в первую очередь поддерживать именно Windows, и многие производители не предоставляют нормальных драйверов под LINUX для своих устройств
Понятно, но в ASP Linux 12 (Fedora 7) это проходило, а тут перестало. Также в другом приложении — при линковке выдалось сообщение, что sincos@@GLIBC_2.1.1 требуется, определено в libm.so.6 и дан совет включить эту библиотеку в командную строку линкера (надо же! Ещё и советы даёт, чего включить, а не просто неопределённые ссылки!). В Fedora 7 это приложение линковалось нормально. Ну тут я, воспользовавшись советом, просто -lm добавил в строку линковки — и тут заработало. В общем, вернул Russian Fedora Remix 14 и продолжаю его использовать. А насчёт стандартов кодописания — иногда можно включать <math.h>, а иногда не очень удаётся (если, например, объявить переменную тем же именем, что и функция из math.h). Но тут, видимо, в RF 14 в libm.so.6 функции сидят C-шные, а не C++-ные, а в math.h они все, видимо, объявлены как extern «C». Поэтому и не линкуется, если сам объявляешь. А в старой системе была ещё и libm.a, где могли и C++-ные версии сидеть. Хотя, т.к. я в math.h не заглядывал, не могу сказать, так это или нет
В общем, у страха глаза велики :). Когда такое к концу дня возникает, не можешь сразу сообразить. Так что, похоже, с учётом вышеописанного всё будет работать нормально. Т.е. если честно включать math.h — всё хорошо, а если самому объявлять эти функции — всё плохо. Хотя раньше пролетало и то, и другое. Так что снова поставлю себе Russian Fedora Remix 14, уж больно нравится мне. Есть там недоделки с русификацией ряда программ (в ASP-е они обычно это доводили до ума), зато сразу опознался видеоадаптер, сразу заработала встроенная видеокамера и WiFi работает через nm-applet — солидно. К тому же, у меня образ диска уже остался, где стояли все нужные мне пакеты — считаю и время сэкономлю
О! Решил эту проблему сам. Вот попробуйте такой код (tm.cpp):
#include <stdio.h>
double fabs(double);
int main (int argc, char **argv) {
float x=9.0;
printf(«fabs=%7.2f\n»,x);
}
Теперь g++ tm.cpp -o tm — отлуп:
tm.cpp:(.text+0x1a): undefined reference to `fabs(double)'
Когда убираем строчку double fabs(double); и пишем просто #include <math.h> — всё пролетает на ура. Надо в math.h заглянуть — видать, там какая-то хитрость. Хотя man fabs говорит, что double fabs(double); — это нормальное объявление.
Та же команда в Russian Fedora Remix 14 даёт только динамическую версию libm, а статическую не даёт:
s -la /usr/lib/libm.*
-rw-r--r-- 1 root root 514776 Июл 17 2007 /usr/lib/libm.a
lrwxrwxrwx 1 root root 19 Янв 28 2008 /usr/lib/libm.so -> ../../lib/libm.so.6
Может, тут следует копать? Тогда вопрос: а где взять libm.a для Fedora 14? Т.е. какой rpm её содержать должен — кто-нибудь в курсе?
Вот поэтому-то «самые новые и крутые» Линуксы для реальной работы часто не годятся — вот из-за таких «чудес» — приходится откат давать на старые версии
Ну да, у меня тоже нормально работает в Ф 14, если я просто напишу одну программку test.cpp, где вызову fabs (кстати, та же история и с sin, cos и т.п.) и просто сделаю g++ test.cpp -o ttest. А если несколько объектников собирать? А у меня оттуда ещё вызываются сокеты, например. В общем, за конечное время эту проблему не решить, как я и предполагал. Потому и правильно откатился на старую Федору, где всё работало. Я не могу остановить все работы и искать причину такого странного поведения линковщика (ибо заказчику это не нужно, у него ASP Linux Server V, это мне нужно было чисто для моего удобства). Поэтому я поставлю RF 14 под VMWare в стороночку и попробую на досуге создать более простой пример, который бы не работал таким же образом — просто интересно выяснить, что же не нравится. О результатах сообщу.
1. Купить для всех пяти компов видеокарты, для которых есть отлаженные LINUX-драйверы (на тот момент nVidia, например) и тратить время на их замену (причём, не факт, что не влипнешь в похожую историю опять!)
2. Купить пять копий Windows XP, где сразу всё пойдёт без всякого подобного геморроя, благо приложение, с которым работают компы, написано на Java и ему пофиг, Win или Linux им управляет
Естественно, пошли по второму пути, т.е. снесли LINUX и поставили Windows. Так что мы уже знаем, что если заказчик хочет использовать LINUX — надо в расписание проекта отвести время на борьбу с ОС LINUX, ибо никогда не знаешь, куда влипнешь. Так что дело не только в косности, но и в том, что есть сговор на рынке между Microsoft и производителями железа, чтобы в первую очередь поддерживать именно Windows, и многие производители не предоставляют нормальных драйверов под LINUX для своих устройств
1. Купить для всех пяти компов видеокарты, для которых есть отлаженные LINUX-драйверы (на тот момент nVidia, например) и тратить время на их замену (причём, не факт, что не влипнешь в похожую историю опять!)
2. Купить пять копий Windows XP, где сразу всё пойдёт без всякого подобного геморроя, благо приложение, с которым работают компы, написано на Java и ему пофиг, Win или Linux им управляет
Естественно, пошли по второму пути, т.е. снесли LINUX и поставили Windows. Так что мы уже знаем, что если заказчик хочет использовать LINUX — надо в расписание проекта отвести время на борьбу с ОС LINUX, ибо никогда не знаешь, куда влипнешь. Так что дело не только в косности, но и в том, что есть сговор на рынке между Microsoft и производителями железа, чтобы в первую очередь поддерживать именно Windows, и многие производители не предоставляют нормальных драйверов под LINUX для своих устройств
#include <stdio.h>
double fabs(double);
int main (int argc, char **argv) {
float x=9.0;
printf(«fabs=%7.2f\n»,x);
}
Теперь g++ tm.cpp -o tm — отлуп:
tm.cpp:(.text+0x1a): undefined reference to `fabs(double)'
Когда убираем строчку double fabs(double); и пишем просто #include <math.h> — всё пролетает на ура. Надо в math.h заглянуть — видать, там какая-то хитрость. Хотя man fabs говорит, что double fabs(double); — это нормальное объявление.
s -la /usr/lib/libm.*
-rw-r--r-- 1 root root 514776 Июл 17 2007 /usr/lib/libm.a
lrwxrwxrwx 1 root root 19 Янв 28 2008 /usr/lib/libm.so -> ../../lib/libm.so.6
Та же команда в Russian Fedora Remix 14 даёт только динамическую версию libm, а статическую не даёт:
s -la /usr/lib/libm.*
-rw-r--r-- 1 root root 514776 Июл 17 2007 /usr/lib/libm.a
lrwxrwxrwx 1 root root 19 Янв 28 2008 /usr/lib/libm.so -> ../../lib/libm.so.6
Может, тут следует копать? Тогда вопрос: а где взять libm.a для Fedora 14? Т.е. какой rpm её содержать должен — кто-нибудь в курсе?