>Salt Lake City Airport, Dec 4, 2005

Эти [censored] из солтлэйка мне никогда не нравились... Особенно после олимпиады. И дата какая-то странная...

>Today, if you want a consistent software experience, you have little choice but to go with Windows. Remember: Real Programmers Don't Care.

Угу, если хочешь писать для леммингов всю жизнь - go with Windoze сколько угодно. А для real programmers имхо нет ничего лучше юниховой консоли. Странно такое слышать от человека, который UNIX system administrator with 20+ years experience, and a Windows system administrator since Windows 1.0.

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

>Статья очень спорная и не совсем правильная. То есть как всегда, слова все верные, но верние ли они на самом деле не знает никто. Просьба экономить серое вешество себя и собеседника, мир не стал иным от того, что кто-то написал еще одну спорную статью.

Просьба не пропускать спорные статьи, которые являются провокацией флейма.

>that Adobe, Macromedia, Corel, and so forth have blithely continued to
>remain virtually Windows-only

Интересно, не с сайта Adobe ли я скачивал не так давно Acrobat Reader?
И не с сайта Macromedia я скачивал flash player?
Да и у Corel есть ряд продуктов для Linux.

В общем, обычное безграмотное словоблудие.

Но в чем-то автор ведь прав.

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

А смысл?

а все это происходит всего лишь из-за того что люди не смогли
придти к соглашению.

Или взять Linux дистрибутивы. У Gentoo и Debian есть куча скриптов для
сборки, и куча патчей написанная их пользователями. Почему бы все это
не соединить. От этго мир только выиграет,
но ведь нет они никогда не договоряться.

и ведь список можно продолжать.

Раньше это было производной свободы.

для любого решения были альтернативы.
теперь же это смахивает на маразм.

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

>Просьба не пропускать спорные статьи, которые являются провокацией флейма.

Почему же? У автора есть мнение, оно довольно интересное. Только не надо флеймить и все будет хорошо.

а почему флеймить не надо?
пофлеймят чуток ну и пусть. кому-нибудь разве это мешает?

В том то и дело! Сначала говорят, давайте пусть будет KNOME и Dentoo, а потом начинают вообще все решения под одну гребенку чесать. Вот зачем есть Lots и Groupware? Ведь есть Exchange?

не вижу темы для флейма. unix мёртв.
хоть обспорьтесь.

> если хочешь писать для леммингов всю жизнь - go with Windoze сколько угодно. А для real programmers имхо нет ничего лучше юниховой консоли.

Уже, по-моему, давно сложилась стабильная ситуация: хочеш неплохо заработать - пиши для Вынь, хочеш действительно что-то хорошее сваять - грузи Юникс...

Судя по требованиям рынка труда, как раз наоборот. При этом под Win существует "низшая каста" - мордописец.

> unix мёртв. хоть обспорьтесь.

Всем атас! Зомби захватывают веб-сервера и десктопы! Спасайтесь, кто может :)

По сути - да, configure скрипты automake, autoconf утилиты, RPM, deb - совершенно не относятся к программированию и жутко раздражают. Возникает нелепая ситуация, когда программисту, чтобы написать программу, нужно быть еще и администратором.

А что касается утверждания о том, что Windows - решение всех проблем в этом плане - то стоит посмотреть на метания майкрософт от COM к SOAP и XML технологиям, от WinAPI к .NET и всяким фреймворкам. Недавно была статья, про backwards compatibility со старыми приложениями, на которую майкрософт имеет тенденцию положить болт. На то, что майкрософт обожает конкурировать со своимим партнёрами - к примеру написали вы приложение под Windows - и что дальше? Пришел микрософт и всех выгнал, предложив то же самое в составе другого продукта.

> Судя по требованиям рынка труда, как раз наоборот. При этом под Win существует "низшая каста" - мордописец.

Просто если уже пишешь под Юникс на заказ - то зарабатываешь ОЧЕНЬ много :)

А насчет делфиваятелей и заваленных free-, shareware-серверов - об этих "талантах" с ихними переключателями раскладок я вообще молчу...

> Вот зачем есть Lots и Groupware? Ведь есть Exchange?

вот не надо перевирать фразу анонимуса.

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

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

Использование так огромных ресурсов OpenSource для того чтобы сделать
одну и ту же вещь дважды, помоему маразм.

Программинг программингом. А автор не задумывался
о тех серверах по всему миру, которые работают на UNIX?

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

Если UNIX действительно мертв, то как работает сеть интернет?

У UNIX есть своя ниша, и там он будет всегда.

>По сути - да, configure скрипты automake, autoconf утилиты, RPM, deb - совершенно >не относятся к программированию и жутко раздражают.

не понял почему при этом надо быть администратором?

В проектах для Windows надо писать инсталятор.

Также как в проетах для *nix надо писать spec для rpm.

в чем разница?

Больной скорее жив, чем мертв.

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

А по-моему это свобода выбора. На чём хочу, на том качу. Главное, что в одном направлении и без рельс.

В чем разница? А что проще написать и в чем потом меньше багов?

Колонку вместе с редактором -- в /dev/null.

Его универсальную платформу -- туда же.

Гибель UNIX'oв или разделяй

Больше всего мне понравилось пакеты под Slackware делать... Собираешь make потом make install DESTDIR=/то/куда/свалить/собранное потом если не требуется больше ни каких скриптов то makepkg имяпакета... Вот и все....

>По сути - да, configure скрипты automake, autoconf утилиты, RPM, deb - совершенно не относятся к программированию и жутко раздражают.

Рекомендую взглянуть на KDevelop.

> Microsoft/Intel was careful to guarantee them a consistent software experience across a broad selection of hardware. Equally important, application developers flocked to that consistent software experience because it meant their products were cheaper to develop without the headaches of version-specific differences.

А вот с этого я просто плакалъ... No comments, господа.

V winde net /dev/null :)

PS sorry za transliteraciju

Ставим Cygwin, в нем есть /dev/null...

> Или взять Linux дистрибутивы. У Gentoo и Debian есть куча скриптов для сборки, и куча патчей написанная их пользователями. Почему бы все это не соединить. От этго мир только выиграет, но ведь нет они никогда не договоряться.

Я уверен, что всё, что нужно, они друг у друга берут. Debian'ские ментейнеры и upstream авторам репорты отсылают. Очень удобно - пользуешься одной программой reportbug, а уж кто её исправлять будет - они сами разберутся.

> configure скрипты automake, autoconf утилиты, RPM, deb - совершенно не относятся к программированию и жутко раздражают.

А InstallShield не раздражает? Кроме того, autotools, хоть и кривовато, но облегчают задачу написания портируемых приложений. В Win такого нет по причине отсутствия культуры распространения в исходниках. Я помню как мучался с Unicode'ом, который должен был работать и в OS WinNT, и в недоOS Win98.

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

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

А если это кивок в сторону расстановки прав доступа, то да - в OS семейства Windows, являющихся, по сути, однопользовательскими системами, этим никто не заморачивается, а потому - проще. Как только разработчик решит этим заморочиться, ситуация будет в пользу Unix.

>>>Взять например, Gnome и KDE. Они же практически в последнее время трудяться на одними и теми же фишками, куча человеко/часов тратиться чтобы сделать одно и то же дважды.

Одно и то же надо сделать раз 10 - как минимум. Только после этого оно будет хоть на что-то похоже. Кроме того, обилие конкурирующих продуктов еще никогда не вредило пользователю. Жаль что остались только гном да кде - оба весьми далеки от совершенства.

>Рекомендую взглянуть на KDevelop.

kdevelop не умеет работать с чистыми makefile'ами. То есть если у меня есть большой проект - перенести его в kdevelop - проблематично.

А инсталлятор для Windows уже написан, куча как свободных так и несвободных.

specs для rpm - это как раз то, чем я не хочу заниматься.

>Взять например, Gnome и KDE. Они же практически в последнее >время трудяться на одними и теми же фишками, куча человеко/часов >тратиться чтобы сделать одно и то же дважды. А смысл? С другой стороны кому-то не нравится KDE и нравится Gnome. Он пишет для Gnome и не будь Gnome для KDE бы он не писал. Так что смысл очень даже есть.

И потом, мне влом создавать этот rpm, поскольку у меня вообще Debian. Вы еще мне тут посоветуйте ebuild скрипты писать :) Оно мне надо спрашивается?

> Оно мне надо спрашивается?

тебе как разработчику это не надо

этим занимаются разработчики дистрибутивов, собирают твоих исходники в пакеты

это если проект опенсурсный :)

> это если проект опенсурсный :)

перенимай опыт у Adobe, NVidia, VMWare и т.п.

>перенимай опыт у Adobe, NVidia, VMWare и т.п.

да всё это не очень сложно на самом деле, только влом :)

а как вообще в дебиан ставите софт для которого нет .deb пакета ?

> а как вообще в дебиан ставите софт для которого нет .deb пакета ?

./configure make checkinstall

> а как вообще в дебиан ставите софт для которого нет .deb пакета ?

А что, остался еще недебианизированный софт?

> ./configure make checkinstall

man dh_make

и что эти два варианта умеют разрешать зависимости по требованию автоконфа ??

Умеют.

Всем курить про инфраструктуру сборки в Дебиане. А после этого выбрасывать на помойку все то, что не имеет сравнимой инфраструктуры.

Почитал статью. Мне смешно, автора -- в топку.

зачем ему работать с "чистыми makefile'ами" если он замечательно расписывает исходники и хедеры по переменным классам етц. ? мейкфайл вообще достаточно погодозависим чтобы быть универсальным средством сохранения настроек проекта, вы знаете более простые примеры переноса проекта из одной среды разработки в другую ?

можно кинуть в меня ссылкой, а то: 1. я не очень ориентируюсь в инфраструктуре документации дебиана, и боюсь недотреплю до счасливого момента откровения на этот предмет 2. удобство, а следовательно удовлетворенность решением проблемы установки не входящего в репозитарий софта в gentoo не позволят убивать много усилий/времени на отыскание альтернативных решений, это психология;))

>зачем ему работать с "чистыми makefile'ами" если он замечательно расписывает исходники и хедеры по переменным классам етц.? мейкфайл вообще достаточно погодозависим чтобы быть универсальным средством сохранения настроек проекта, вы знаете более простые примеры переноса проекта из одной среды разработки в другую ?

Немного менее сумбрно можно? :) И желательно с пониманием проблемной области :)

> не вижу темы для флейма. unix мёртв.
хоть обспорьтесь.

Как (почти) сказал Б.Г.

unix-way мертв, а я - еще нет
unix-way мертв, а я - ...
те кто нас любят - смотрят нам вслед
unix-way мертв, а я
еще нет

:)

Экологию учи. Diversity - рулез немерянный.

> зачем ему работать с "чистыми makefile'ами" если он замечательно расписывает исходники и хедеры по переменным классам етц.?

Он удавится при первой же платформной несовместимости. А что лучше -- какой-то config.h ручонками для каждой платформы править? Нафиг, нафиг...

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

Я не знаю, какие с этим проблемы могут быть. Подумаешь, из vim в emacs перешел, с emacs в vim. Или вы имеете в виду разные компиляторы? Так какая разница, где кучу conditional'ов, которые все равно при этом нужны, прописывать?

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

> с пониманием проблемной области :)

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

> Он удавится при первой же платформной несовместимости

т. е. тут уже видимо имеется ввиду automake или gcc ?

> Во всяком случае, хранить в самих исходниках проекта его настройки -- это архибезумнейший маразм..

да, именно поэтому, файл настроек хранится в каталоге программы, а исходный код в src

>mjr.
>Salt Lake City Airport, Dec 4, 2005

да он писал все это на коленке в аэропорту, наверняка накуренный =))