Windows vs Linux - Как десктоп , и игровая станция.

Цитата Pourtous @ 17.09.08, 02:41

Я имела ввиду, что среди программистов, пишущих под никс, гораздо меньше "сделанных инструментарием", чем среди программистов, пишущих под вин. Среда не распоолагает.

Есть те кто учится хорошо, есть те, кто учится плохо. Последних - всегда большинство. Есть те, кому нравится их работа, есть те, кто лишь выполняет свои обязанности. Последних - всегда большинство. Инструментарий не делает специалистов. Это ошибка малоопытных людей, ещё раз повторяю. Никакой инструментарий, никакие подходы в обучении не в состоянии качественно изменить человека. Иными словами, дерьмовый программный продукт - это никогда не результат использования того или иного инструментария и никогда не результат использования тех или иных подходов к разработке и/или проектированию.

Цитата Pourtous @ 17.09.08, 02:41

А тут --- кому нравится кодит бэкенды, кому нравится --- придумывает удобные интерфейсы. Разделение труда.

Не всё так просто. Создатель т. н. back-end'а в первую очередь не рассчитывает на какой-либо front-end. Он серьёзным образом ограничивает интерфейс своего творения и для реализации действительно удобного и многофункционального интерфейса придётся затратить огромное количество усилий. Так что позитив мнимый

Цитата Pourtous @ 17.09.08, 06:21

Фронтенд должен реализовывать доступ если не ко всей, то к большей части функциональности бэкенда. При этом бэкенд должен являть самостоятельным приложением(а не одним системным вызовом). Любая программа не является прослойкой ко всему апи.

Любая программа не является прослойкой к чему либо. Любая программа реализует некий функционал посредством чего-либо.

Добавлено 17.09.08, 09:05

Цитата MumiyTroll2008 @ 17.09.08, 08:11

Пусть лучше свою MSDN курят, которую как раз без обкурки, особенно по некоторым библиотекам типа MFC и прочего читать невозможно.

Буковки не те? Или на иврите пишут?

Цитата MumiyTroll2008 @ 17.09.08, 09:23

Что скажете сами как спец по java, что лучше или логичнее построено справочная система по java или MSDN?

А что вам может ответить java-разработчик, как вы думаете? А между тем, многие новички, которые осознали перспективность подходов, применямых в java и, соответственно, в dotnet, выбирают dotnet из-за качества документации.

Цитата wind @ 16.09.08, 17:24

И чем это отличается от всевозможных softlist'ов или коров?

а) я не знаю этих ваших софтлистов
б) one click install
А сейчас - изволь погуглить и посмотреть десяток банеров с риском подхватить какую-нибудь заразу.

Цитата wind @ 16.09.08, 17:24

VESA - вполне чётко определённая спецификация, так что никто не будет писать под чьё-то расширение этой спецификации.

Не парь мозги. VBE 2.0 - это фреймбуффер. ЕМНИП и на VBE 1.2 иксы вполне себе пахали. В драйвере vesa также был код поддержки дополнительных функций некоторых видеокарт. В любом случае, я на любой видюхе с этим драйвером мог получить 1024x768, 24bpp @ 100MHz (напомню, что в 2004-м году это было хорошее рабочее разрешение), а вот на Win 98 распишитесь в получении 640x480, 4bpp @ 60Hz.

Цитата wind @ 16.09.08, 17:24

И когда это opengl-игры не работали?

1) берешь GeForce 440MX/Riva TNT2/любой жефорс
2) ставим XP (SP1, SP2 - не суть, думаю, и на SP3 та же хрень)
3) запускаем CS 1.6 в редиме DirectX - ok, есть 3D. Запускаем CS 1.6 в режиме OpenGL - fail, запускаем первый Neverwinter Nights - fail. Ставим дрова от Nvidia, повторяем все операции - все работает. Вот и говнодрова от MS.

Цитата wind @ 16.09.08, 17:24

Они там чуть не отродясь, linuxfan. Найдите, если не поленитесь, дистрибутив третьих форточек и полюбопытствуйте

Не было. Proof me wrong. Стоило мне выбрать драйвер, отличный от ET6000 и я сидел в том же самом 640x480 4bpp в 98-й винде. Скорость отрисовки при этом была настолько фантастической, что очевидно было, что винда рисует не во фреймбуффер VBE 2.0, а переключает цветовые плоскости (или двигает окно графическог вывода - уже запамятовал), как в VBE 1.2.

Цитата $im @ 16.09.08, 17:58

Прямо сейчас проверил (прям интересно стало, ни разу не пробовал что-то смотреть во время игры) - все работает.

А вот у меня на 8800GT не работает. В Linux OpenGL и XVideo (аппаратный yuv видеооверлей) превосходно дружат. И там и там драйвера для видеокарты от производителя. Мораль: либо у винды кривая внутренняя архитектура, либо под винду одни говнодрайверы. В любом случае, поддержка популярного железа - полный саксь => win не может быть десктопной осью по этому критерию.

Цитата $im @ 16.09.08, 17:58

Дада, помню помню... Попытался сразу после установки линя wmv посмотреть - мне фигу показали.

Делов не знаю. mplayer все играет. А вот винда икспишная «искаропки» не проигрывала половину моих лицензионных DVD, которые в том же линуксе на ура шли. Опять фейл. Снова винда не справляется с такой простой задачей, как воспроизведение видео.

Цитата $im @ 16.09.08, 17:58

net stop [служба] еще никто не отменял...

Ага. И пиши это порой километровое имя службы ручками. Винда ведь у нас никогда лаконичностью не славилась: «Program Files», «Document and Settings» -- истинные шедевры инженерной мысли.

Цитата $im @ 16.09.08, 17:58

Согласен, фтупил. Он ведь даже в хрюше есть.

В XP я его впервые увидел. Я был искренне поражен, что generic драйвер появился так поздно. Я бы еще с удовольствием подискутировал на тему «почему винда не видит UDF на флешках», но ведь никто не скажет, почему.

Цитата $im @ 16.09.08, 17:58

В хрюше, если мне память не изменяет, встроены 1.1 версия ГЛ, в висте 2.0.

А я слышал, что в висте с OpenGL все совсем плохо.

Цитата linuxfan @ 17.09.08, 10:01

И пиши это порой километровое имя службы ручками.

Откуда километровые? По обыкновению они не длиннее, чем в лине.

Цитата linuxfan @ 17.09.08, 10:01

А я слышал, что в висте с OpenGL все совсем плохо.

А я слышал, что для защиты рубежей РФ будут использовать огромных человекоподобных роботов. В Висте с ОпенГЛ все не хуже, чем в ХР - сам раньше ГЛ пользовал, перешел потом на ДХ.

Цитата linuxfan @ 17.09.08, 10:01

1) берешь GeForce 440MX/Riva TNT2/любой жефорс
2) ставим XP (SP1, SP2 - не суть, думаю, и на SP3 та же хрень)
3) запускаем CS 1.6 в редиме DirectX - ok, есть 3D. Запускаем CS 1.6 в режиме OpenGL - fail, запускаем первый Neverwinter Nights - fail. Ставим дрова от Nvidia, повторяем все операции - все работает. Вот и говнодрова от MS.

Говнодрова тут не при чем. Как я уже писал, в хрюше по умолчанию лежит спека ОГЛ 1.1. Тот же NWN использует 1.5 спеку. То есть, не найдя нужных расширений, рендер просто падает в софтвар моде. Универсальный ОГЛ мелкософт не пихает в винды по причине бессмысленности оного - у nVidia и ATI слишком разные реализации OpenGL + у каждой свои уникальные расширения (бывало напишешь что-то для нвидии - прекрасно работает, тестишь на ати - софтвар о_О). Посему и лежат в винде по умолчанию дрова только для простейшего рендера. Точнее - лежит полностью определенная спека ОГЛ (к которой не надо подрубать новые расширения). На момент выхода хрюши это была 1.1, для висты - 1.5.

Цитата wind

Есть те кто учится хорошо, есть те, кто учится плохо. Последних - всегда большинство. Есть те, кому нравится их работа, есть те, кто лишь выполняет свои обязанности. Последних - всегда большинство. Инструментарий не делает специалистов. Это ошибка малоопытных людей, ещё раз повторяю. Никакой инструментарий, никакие подходы в обучении не в состоянии качественно изменить человека.

Все верно. Тут говорят о том, что некоторые инструментарии и подходы поощряют это самое быдловское "большинство" .

Цитата $im @ 17.09.08, 11:00

Тот же NWN использует 1.5 спеку.

Игра 2000-лохматого года использует OpenGL 1.5? Ну-ну
И линк, пожалуйста, на то, что WinXP в своих майкрософтовских драйверах поддерживает OpenGL. Что-то нигде не могу найти подтверждения этому факту.

Цитата $im @ 17.09.08, 11:00

В Висте с ОпенГЛ все не хуже, чем в ХР

Слышал в свое время, что с Aero и OpenGL были проблемы. Правда или нет -- не интересовался, Vista не входит в список моих интересов.

Цитата linuxfan @ 17.09.08, 10:01

я не знаю этих ваших софтлистов

Цитата linuxfan @ 17.09.08, 10:01

А сейчас - изволь погуглить и посмотреть десяток банеров с риском подхватить какую-нибудь заразу.

Уж что-нибудь одно

Цитата linuxfan @ 17.09.08, 10:01

Не парь мозги. VBE 2.0 - это фреймбуффер. ЕМНИП и на VBE 1.2 иксы вполне себе пахали. В драйвере vesa также был код поддержки дополнительных функций некоторых видеокарт.

Русский нихт ферштейн? Именно линейный framebuffer, мозгопропариватель вы мой, А НЕ ПОДДЕРЖКА "2D-УСКОРЕНИЯ", КОТОРОГО ТАМ НЕ БЫЛО, НЕТ И НЕ БУДЕТ.

Цитата linuxfan @ 17.09.08, 10:01

Вот и говнодрова от MS.

Мать-мать-мать... Вы ничего не перепутали? Дрова для существуют только от nvidia, вместе с системой полноценные драйверы не поставляются, ибо таково желание поставщика оборудования.

Цитата linuxfan @ 17.09.08, 10:01

Не было. Proof me wrong. Стоило мне выбрать драйвер, отличный от ET6000 и я сидел в том же самом 640x480 4bpp в 98-й винде.

БЫЛИ.

Цитата linuxfan @ 17.09.08, 10:01

И пиши это порой километровое имя службы ручками. Винда ведь у нас никогда лаконичностью не славилась: «Program Files», «Document and Settings» -- истинные шедевры инженерной мысли.

Для нормальных людей ведь делалось, а не для линуксоидов Нормальные люди не понимают этих ваших "абырвалгов".

Цитата linuxfan @ 17.09.08, 10:01

А я слышал, что в висте с OpenGL все совсем плохо.

В висте с opengl вообще никак. Как и в хрюше, как и до неё, как и в любой другой системе. OpenGL реализует вендор.

Цитата D_KEY @ 17.09.08, 11:03

Все верно. Тут говорят о том, что некоторые инструментарии и подходы поощряют это самое быдловское "большинство"

нет, тут говорят о том что некоторые инструментарии упрощают процесс разработки.
А то что "неопытное большинство" быстро научилось, в какойто степени, этими инструментами пользоваться и понаписало кучу кривых программ (как раз вследствие своей неопытности и нежелания глубоко разбираться), просто еще раз подтверждает простоту работы с этим инструментарием, а не дискредитирует его.

Цитата Deus @ 17.09.08, 07:45

Напомню ваше сообщение:

Цитата Pourtous @ 17.09.08, 04:18

а) сделать неюзабельный консольный интерфейс намного сложнее чем неюзабельный гуй. Простора для ошибок меньше. Соответственно, встречается реже, намного.

в чем смысл высказывания? в том что в консоли нет места для ошибок проектирования интерфейса свойственных GUI?
Ну так хоть это показали бы вместо лекций, а то как пример приводите ошибки, подобные которым легко могут иметь место и в консоли.

Что-то перепутать в консольном приложении не сложно
Причем, напротив - сделать текстовый интерфейс удобным сложнее, чем графический.

Цитата Pourtous @ 17.09.08, 06:21

полезно для решения широкого круга пользовательских задач.

для каких например?
я не считаю пользовательской задачей попытки иправить интерфейс консольной программы написанием скриптов.

Что имеется ввиду под консольным интерфейсом?

Возможно два варианта: попытка закосить под GUI с использованием какого-нибудь ncurses (программы типа mc и aptitude), или чисто консольные утилиты проде grep/find/sed/awk.

Закос под GUI вообще говоря полная убогость, и при таком подходе врядли можно сделать существенно меньше ошибок чем при работе с нормальным GUI. Такой подход может быть удобен при удаленной настройке серверов, но для пользовательского десктопа это не вариант сегодня.

Если же имеется ввиду неудобное взаимодействие с консольной утилитой, то здесь уже можно попытаться поправить обертками/скриптами ситуацию. Вроде бы как раз такое вышло с git в начале его разработки: вроде программа мощная и функциональная получилась, но пользоваться ей самой по себе было не удобно, в результате понаписали оберток на bash и perl, стало гораздо удобнее пользоваться. Но опять же это ни разу не вариант для десктопа, обычные пользователи не будут разбираться со сложной и запутанной консольной утилитой.

Более подходящий пример GUI front end - это K3b, записывалка CD/DVD дисков. Т.е. она не пишет диски сама, а вызывает консольные утилиты.

Вообще разделение на GUI front end и консольные утилиты далеко не всегда хорошо работает. И сложностей может появляться очень много. Использование библиотек куда более правильное решение. Особенно это относится к интерактивные программам, когда постояно требуется вмешательство пользователя и нужна быстрая реакция на его действия. Для этого зачастую приходится постоянно держать запущенной консольную утилиту, да еще и придумывать протокол обмена с ней.

А вот batch processing, зачастую удобней через консольные утилиты организовывать. Но опять же для специализированных задач (вроде массового изменения размера фоток) уже есть GUI, и ими простому пользователю удобнее.

Цитата Deus

нет, тут говорят о том что некоторые инструментарии упрощают процесс разработки.
А то что "неопытное большинство" быстро научилось, в какойто степени, этими инструментами пользоваться и понаписало кучу кривых программ (как раз вследствие своей неопытности и нежелания глубоко разбираться), просто еще раз подтверждает простоту работы с этим инструментарием, а не дискредитирует его.

Если период начального освоения того же С/С++ или Java заканчивается или переходом на другой язык или ростом квалификации, то ламерский период программирования под некоторые среды/языки(не будем тыкать пальцем ) может с высокой долей вероятности длиться годами. Естественно, есть хорошие программисты, использующие такие среды/языки. Но это скорее исключения из правила, которые, как известно, только его подтверждают. Кроме того, как правило, такие программисты практически не используют то, чем так гордятся новички.
Я сам писал на делфи. Единственное преимущество этого языка - мощный RTTI. А не мышкотыкание.
В большом проекте мышкотыканием в делфи ничего создать не получится, компонент слишком много. Посмотрите на исходники каких-нибудь утилит.
Кроме того в профессиональной разработке, задачами написания гуя занимается зачастую отдельно взятый человек. Остальные с гуем не взаимодействуют.
А вообще, проектирование интерфейса задача не программерская.

Цитата D_KEY @ 17.09.08, 11:46

Я сам писал на делфи. Единственное преимущество этого языка - мощный RTTI.

Вы ГУЙ там писали? Например, для АБС? Я бы посмотрел, как бы вы обошлись без мышкотыкания, рисуя тысячи всевозможных формочек

Цитата D_KEY @ 17.09.08, 11:46

Кроме того в профессиональной разработке, задачами написания гуя занимается зачастую отдельно взятый человек. Остальные с гуем не взаимодействуют.

Чушь.

Цитата wind @ 17.09.08, 11:54

Цитата D_KEY @ 17.09.08, 11:46

Я сам писал на делфи. Единственное преимущество этого языка - мощный RTTI.

Вы ГУЙ там писали? Например, для АБС? Я бы посмотрел, как бы вы обошлись без мышкотыкания, рисуя тысячи всевозможных формочек

Для АБС гуй не писал. Вы уверены, что в этом случае у делфи есть приемущества в плане именно мышкотыкания?
Я таким вещами не занимался, судить не могу.

Цитата wind @ 17.09.08, 11:54

Цитата D_KEY @ 17.09.08, 11:46

Кроме того в профессиональной разработке, задачами написания гуя занимается зачастую отдельно взятый человек. Остальные с гуем не взаимодействуют.

Чушь.

Во всех конторах где я работал, во всех проектах, в которых был гуй, им занимались один/два человека. Остальные занимались основным функционалом приложения. Кроме того, всегда существовал дизайнер, проектирующий интерфейс.

Цитата D_KEY @ 17.09.08, 12:13

Вы уверены, что в этом случае у делфи есть приемущества в плане именно мышкотыкания?
Я таким вещами не занимался, судить не могу.

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

Цитата D_KEY @ 17.09.08, 12:13

Во всех конторах где я работал, во всех проектах, в которых был гуй, им занимались один/два человека. Остальные занимались основным функционалом приложения.

Это были утилиты типа чейнджеров обоев? Или куда? Поддержка графического интерфейса пользователя вплетена в основной фукционал приложения очень прочно (как уже говорилось - это до трёх четвертей кода клиентского приложения), и если у вас этим занимались один-два человека, то всего программеров было три?

Цитата D_KEY @ 17.09.08, 12:13

Кроме того, всегда существовал дизайнер, проектирующий интерфейс.

Дизайнер не программирует. Иначе следует кричать "караул" и бежать из такой конторы.

Цитата wind @ 17.09.08, 12:26

Цитата D_KEY @ 17.09.08, 12:13

Вы уверены, что в этом случае у делфи есть приемущества в плане именно мышкотыкания?
Я таким вещами не занимался, судить не могу.

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

А чем тот же Qt Designer для этого плох?

Цитата wind @ 17.09.08, 12:26

Цитата D_KEY @ 17.09.08, 12:13

Во всех конторах где я работал, во всех проектах, в которых был гуй, им занимались один/два человека. Остальные занимались основным функционалом приложения.

Это были утилиты типа чейнджеров обоев? Или куда? Поддержка графического интерфейса пользователя вплетена в основной фукционал приложения очень прочно (как уже говорилось - это до трёх четвертей кода клиентского приложения), и если у вас этим занимались один-два человека, то всего программеров было три? И это мы называем профессиональным ПО?

С чего вы взяли, что "поддержка графического интерфейса пользователя вплетена в основной фукционал приложения очень прочно"? Вам не кажется, что все зависит от приложения ?
Обычно, на одном проекте было от 7 до 15-20 программистов.

Цитата wind @ 17.09.08, 12:26

Цитата D_KEY @ 17.09.08, 12:13

Кроме того, всегда существовал дизайнер, проектирующий интерфейс.

Дизайнер не программирует. Иначе следует кричать "караул" и бежать из такой конторы.

Естественно, но и программист не должен проектировать интерфейс

Сообщение отредактировано: D_KEY - 17.09.08, 12:37

Цитата D_KEY @ 17.09.08, 12:36

А чем тот же Qt Designer для этого плох?

Не видел, но, думаю, ничем. Разве что некоторой ограниченностью - только для создания визуальной части форм. Но вас, похоже, и это не устраивает.

Цитата D_KEY @ 17.09.08, 12:36

С чего вы взяли, что "поддержка графического интерфейса пользователя вплетена в основной фукционал приложения очень прочно"? Вам не кажется, что все зависит от приложения?

Потому что это так. Исключением могут быть всевозможные rcp-based приложения, где всё это уже реализовано.

Цитата D_KEY @ 17.09.08, 12:36

Обычно, на проекте было от 7 программистов.

А, ну понятно То есть с проектом, где заняты 100-200 человек, вы не сталкивались. Откуда тогда компетентное мнение о профессиональной разработке?

Цитата D_KEY @ 17.09.08, 12:36

Естественно, но и программист не должен проектировать интерфейс

Целиком и полностью поддерживаю. Но есть нюанс - когда программист один, больше некому этим заняться. Получается - либо не браться, либо "отвечать за базар"