Здравствуйте, velkin, Вы писали:
V>Нет, серьёзно, на кой писать не кроссплафторму аж в 2015 году, когда это не несёт никаких дополнительных усилий со стороны программистов.
Если делать "программку", то возможно и не несёт. А если делать полноценный продукт -- то еще как, и для типичного шароварщика-одиночки поддержка нескольких платформ может обернуться обширной головной болью.
Нужно писать с учетом особенностей платформы (реестр и всякие специальные папки в Windows, что-то там свое в Linux и Mac OS X), нужно добиваться того, чтобы приложения выглядели не как типичное кроссплатформенное говно на Swing'е, нужно разобраться с зависимостями и потенциальными конфликтами библиотек, где требуется -- нужно написать инсталлятор и деинсталлятор, нужно написать документацию -- в идеале с картинками, нужно отвечать на письма в поддержку. Кучу работы нужно проделать. И выходит, что тезис о "не требует никаких усилий" -- это не совсем уж и правда.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Anton Batenev, Вы писали:
> Второе — это то, что под Linux очень много хорошего свободного ПО на все случаи жизни
Они об этом не знают. Думают что нет жизни за пределами вантуза.
> по этому программа должна представлять собой нечто экстраординарное, чтобы быть купленной вместо имеющегося аналога.
Стандартное-платное рекламируется, его не надо искать, его впаривают. И ещё то, что, если платно, значит качественно,
если бесплатно, значит кактус.
Здравствуйте, Khimik, Вы писали:
K> И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
Тут надо только понимать, что wine — это "игрушка" для того, чтобы поставить, посмотреть и снести все. Т.е. никто не будет в обычной жизни на Linux использовать ПО под Wine (ну если только совсем-совсем полная безнадега, но как пользователь я слабо себе это представляю). Второе — это то, что под Linux очень много хорошего свободного ПО на все случаи жизни и конкурировать с ним очень-очень непросто, по этому программа должна представлять собой нечто экстраординарное, чтобы быть купленной вместо имеющегося аналога.
Здравствуйте, Sharowarsheg, Вы писали:
S>Что, в принципе, подтверждается практическим опытом навроде фотошопа против гимпа, офиса против либреофиса, дельфи против лазаруса и проча.
Опенсорс с древнейших времён ориентирован на созадние масштабных промышелнных систем. В этом были заинтересованы многие,
так как запил таковых систем в пределах одной корпорации приводил к появления жутко дорого продукта. Модель опенсорса позоляла
создавать системы-монстры, с минимум затрат со стороны создателей. Сравните теперь те продукты, которые писались для промышленного
применения. Файловые системы, СУБД, демоны кластеризации, HPC фреймворки, специализированные модули сетевого взаимодействия и проча.
Нет вот выцепили тему, которая опенсорсниками никогда не воспринималась как первоочередная. Тот же гимп никто не собирался доводить
до состояния фотошопа в плане свисточихалок. А того функционала, что реализовали, создателям было достаточно.
Здравствуйте, rean, Вы писали:
V>>Нет, серьёзно, на кой писать не кроссплафторму аж в 2015 году, когда это не несёт никаких дополнительных усилий со стороны программистов. R>Со стороны молодого и неопытного программиста, да, это не несет никаких дополнительных усилий. R>В реальной же жизни, даже на уровне стандартной библиотеки C не выходя дальше консоли имеются серьезные проблемы в портируемости кода. Над этим лучшие програмерские умы уже десятилетиями бьются, но чудо-шареварщику, оказывается, все по силе, даже то, о чем он не догадывается или просто по наивности не хочет принимать.
Начать хотя бы с Boost, Qt и других подобных, дальше придёт понимание, что огромное множество кроссплатформенных библиотек совместимы с этими решениями. В том и дело, что эти технологии доступны даже неопытному программисту. Очень хорошо подмечено, по наивности или глупости программисты отказываются принимать современные технологии. Возможно им просто лень развиваться.
Что касается стандартных библиотек, то нужно очень хорошо постараться, чтобы добиться несовместимости. Причём знающие люди понимают, что несовместимость может быть лишь в нестандартных реализациях. И зачем в таком случае применять нестандартные решения от какого-либо производителя выходящие за рамки спецификации стандартной библиотеки.
Нужно применять стандарт, сказания о каких-то серьёзных проблемах выглядят как миф. Для подстраховки можно использовать компиляторы подобные gcc, mingw (порт для windows) и так далее, которые более приближены к стандартам, чем некоторые проприетарные компиляторы. Но это уже борьба с ветряными мельницами, поиск проблем, которых нет.
Причём речь именно про реальную жизнь. Одно дело драйвера, но если человек пишет прикладные приложения для Windows, GNU/Linux, BSD, Mac OS X и так далее, и они у него не кроссплафторменные, то в наше время это более чем печально. Исключением могут быть лишь такие поделища как Android, iOS, Windows Phone, там проблемы несовместимости созданы искусственно, а сносить их и ставить GNU/Linux рискованно и пока ещё преждевременно.
Здравствуйте, TheByteMan, Вы писали:
TBM>Я с Java не особо знаком, но с точки зрения библиотек элементов интерфейса на С++ и остальных платформозависимых мелочей, эти вещи что вы перечисли — они заурядны, и решаемы.
Java я упомянул как квинтэссенцию всего плохого, чего только может случиться в UI в кроссплатформенном приложении.
А что касается заурядности и решаемости -- то тут ну совершенно не согласен. Даже в рамках одной платформы порой требуются незаурядные навыки филигранной резьбы по граблям (например, из своего опыта, поддержка работы на всех Windows Server начиная с версии 2003 и выше), чего уж говорить о вообще разных окружениях.
HgLab: Mercurial Server and Repository Management for Windows
Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система? Или как вообще выглядит процесс запуска программы из-под Wine? Как сделать, чтобы шаровара наилучшим образом работала под Wine? И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K>Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система? Или как вообще выглядит процесс запуска программы из-под Wine? Как сделать, чтобы шаровара наилучшим образом работала под Wine? И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
Wine в *nix'ах — это слой совместимости с Win32 поверх нативного линуксового API, который пилит отдельная независимая банда. Примерно как Posix подсистема под Windows (её, правда, MS сама пилила; и которую вроде выпилили в текущих версиях винды), или какой-нибудь cygwin.
Как сделать — да никак. Если повезет, то будет работать (к слову, обычное приложение скорее всего будет работать, Far3 работает вполне удовлетворительно, например)
Портировать — ну, не понадобится, но тут либо надо убедить пользователя поставить и настроить Wine (что тру-линуксоиды не любят), либо самому ставить с программой свою копию Wine'а.
Вообщем, на Wine я бы не расчитывал.
А самое главное, под линуксом не принято что-то покупать. Линуксоиды готовы жрать бесплатный опен-сорц кактус, но платить не будут.
Здравствуйте, Khimik, Вы писали:
K>Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система?
Это не операционная система, это несколько библиотек и других файлов, реализующих использование Win32API, немного Native API в Linux и Mac. Что позволяет запускать программы для Windows в Linux. Иногда нормально запускаются даже 3D-игры, иногда глючит в разной степени.
Разработчики wine ведут БД со списком программ и насколько они успешно запускаются в wine. https://appdb.winehq.org/
K> Или как вообще выглядит процесс запуска программы из-под Wine?
$wine имя_экзешника
K> Как сделать, чтобы шаровара наилучшим образом работала под Wine?
По возможности не использовать функции, которые в wine не реализованы или реализованы плохо. Не использовать какие-нибудь необычные шрифты. То есть, запускаешь прогу в wine и тестируешь как она работает. Если все устраивает ничего не меняешь, если нет надо разбираться, что не так. Обычно wine пишет в лог (в консоль) ошибки.
K> И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
Зависит от многого. Один из дешевых методов портирования — это слинковать с winelib и вычистить косяки.
Здравствуйте, Marty, Вы писали:
M>А самое главное, под линуксом не принято что-то покупать. Линуксоиды готовы жрать бесплатный опен-сорц кактус, но платить не будут.
Это предубеждение, платить никто не любит на самом деле, просто в Linux в этом смысле пользователи продвинутее на предмет найти "опен-сорц кактус", ну и их самих меньше. В Windows еще та проблема (а кому наоборот — ), что найти просто бесплатную программу поиском в гугле обычному пользователю непросто, много всякого адваре и вообще малвари развелось.
Здравствуйте, Michael7, Вы писали:
M>>А самое главное, под линуксом не принято что-то покупать. Линуксоиды готовы жрать бесплатный опен-сорц кактус, но платить не будут.
M>Это предубеждение, платить никто не любит на самом деле, просто в Linux в этом смысле пользователи продвинутее на предмет найти "опен-сорц кактус", ну и их самих меньше. В Windows еще та проблема (а кому наоборот — ), что найти просто бесплатную программу поиском в гугле обычному пользователю непросто, много всякого адваре и вообще малвари развелось.
Платить никто не любит, но виндовые пользователи давно приучены. И под Линуксом много технических проблем — нужно собирать пакеты как минимум под основные дистры и основные архитектуры, думать, как защищать, и тп. С учетом количества Линукса на десктопах, и той доли пользователей из них, которая готова покупать, овчинка не стоит выделки.
Здравствуйте, Marty, Вы писали:
M>Платить никто не любит, но виндовые пользователи давно приучены. И под Линуксом много технических проблем — нужно собирать пакеты как минимум под основные дистры и основные архитектуры, думать, как защищать, и тп. С учетом количества Линукса на десктопах, и той доли пользователей из них, которая готова покупать, овчинка не стоит выделки.
Shareware под Linux тем не менее есть, хотя и мало. Технические проблемы... С одной стороны сложнее защищать, из-за более продвинутых возможностей вплоть до пересборки ядра, и вообще готовые протекторы для Linux даже не знаю, кто-то делает? Электронные ключи делают.
С другой, крякать как-то не очень принято, не нужно всякие цифровые подписи и сертификаты покупать. Что до разнообразия архитектур и дистров, сейчас в винде тоже не просто с этим. По-хорошему, надо поддерживать до сих пор WinXP, Win7 32 и 64 бита и Win8,8.1 тоже 32 и 64 бита, скоро Win10 добавится, а совсем по-хорошему, не грех и на серверных версиях протестировать, разные локализации тоже могут сюрпризов подбросить.
Я не призываю локализировать shareware под Linux, очень возможно из-за меньшего количества пользователей это не окупится, но и проблемы в общем-то решаемые.
Здравствуйте, Khimik, Вы писали:
K>Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система? Или как вообще выглядит процесс запуска программы из-под Wine? Как сделать, чтобы шаровара наилучшим образом работала под Wine? И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
. Что касается запуска, то если делать совсем по нубски, то процесс запуска в Wine вглядит абсолютно так же как в Windows. Программы при установке загрязняют меню "Пуск" линукса подобно тому как это происходит в Windows и можно запустить оттуда, или *.exe файл из проводника. Просто взять и щёлкнуть на нём так же как в Windows.
Чтобы шаровара хорошо работала под Wine нужно её делать под win32, хуже если это .NET, хотя тоже будет работать. Но лучше всего сразу писать кроссплатформенные приложения, тогда это не потребует каких-то дополнительных усилий на портирование. Лично моё мнение, что те, кто пишут обычные прикладные приложения не кроссплатформенными, отстали от индустрии программирования на 10-15 лет.
Выбор между Windows, GNU/Linux, BSD, Mac OS X и прочими не имеет смысла. Какой резон выбирать, когда везде всё и так прекрасно работает. Да, Wine запустит традиционные архитектуры от Intel и AMD, но что если понадобится arm, sparc и прочие. Вот именно поэтому программа изначально являющаяся кроссплатформенной гораздо лучше.
По поводу денег считаю, что это традиционное заблуждение. Просто кое кому уже давно пора покинуть программную индустрию. Высокотехнологичный бизнес крайне не выгоден по сравнению с низкотехнологичным. А это в свою очередь обогащает тех, кто так сказать попал в струю и одновременно делает бедными всех остальных.
Большинство программистов это пушечное мясо и больших денег им никогда не видать. А крупные корпорации так и будут манить их морковками на верёвке, но они их не получат.
Нет, серьёзно, на кой писать не кроссплафторму аж в 2015 году, когда это не несёт никаких дополнительных усилий со стороны программистов.
Здравствуйте, Michael7, Вы писали:
M>Shareware под Linux тем не менее есть, хотя и мало. Технические проблемы... С одной стороны сложнее защищать, из-за более продвинутых возможностей вплоть до пересборки ядра, и вообще готовые протекторы для Linux даже не знаю, кто-то делает? Электронные ключи делают.
Электронные ключи делают шароварщики? Мы еще о шароваре говорим?
M> С другой, крякать как-то не очень принято, не нужно всякие цифровые подписи и сертификаты покупать. Что до разнообразия архитектур и дистров, сейчас в винде тоже не просто с этим. По-хорошему, надо поддерживать до сих пор WinXP, Win7 32 и 64 бита и Win8,8.1 тоже 32 и 64 бита, скоро Win10 добавится, а совсем по-хорошему, не грех и на серверных версиях протестировать, разные локализации тоже могут сюрпризов подбросить.
Цифровые подписи и сертификаты и под виндой не особо нужно покупать. Поддержка ОС от WinXP до Win8.1 x86/x64 от меня вообще ничего не требует. Это примерно то же, что поддержка Debian от 4 до 7/8.
M>Я не призываю локализировать shareware под Linux, очень возможно из-за меньшего количества пользователей это не окупится, но и проблемы в общем-то решаемые.
Здравствуйте, Khimik, Вы писали:
K>Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система? Или как вообще выглядит процесс запуска программы из-под Wine? Как сделать, чтобы шаровара наилучшим образом работала под Wine? И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
Wine — это костыли. Если хотите, чтобы пользователь пользовался костылями, не портируйте, конечно. Но он наверняка предпочтет протез.
Здравствуйте, Michael7, Вы писали:
M>Shareware под Linux тем не менее есть, хотя и мало. Технические проблемы... С одной стороны сложнее защищать, из-за более продвинутых возможностей вплоть до пересборки ядра, и вообще готовые протекторы для Linux даже не знаю, кто-то делает?
Wine это альтернативная реализация Windows API.
K>Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система?
Нет, операционная система это OS X или Linux.
K> Или как вообще выглядит процесс запуска программы из-под Wine?
wine program.exe
K> Как сделать, чтобы шаровара наилучшим образом работала под Wine?
Запустить, проверить работоспособность. При проблемах исправить их в Wine, отослать разработчикам патчи. Возможно исправить свою программу.
K> И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
Я не думаю, что пользователям понравится этот вариант, но в целом без наличия нормальных альтернатив я думаю это приемлемый способ.
Н>Нужно писать с учетом особенностей платформы (реестр и всякие специальные папки в Windows, что-то там свое в Linux и Mac OS X), нужно добиваться того, чтобы приложения выглядели не как типичное кроссплатформенное говно на Swing'е, нужно разобраться с зависимостями и потенциальными конфликтами библиотек, где требуется -- нужно написать инсталлятор и деинсталлятор, нужно написать документацию -- в идеале с картинками, нужно отвечать на письма в поддержку. Кучу работы нужно проделать. И выходит, что тезис о "не требует никаких усилий" -- это не совсем уж и правда.
Крч. нужно РАБОТАТЬ и реализовывать эти не сложные и довольно обыденные вещи, а не херней страдать — что есть самая большая помеха в жизни любого шароваршика и человека работающего на себя.
Здравствуйте, TheByteMan, Вы писали:
TBM>Здравствуйте, Нахлобуч, Вы писали:
Н>>Нужно писать с учетом особенностей платформы (реестр и всякие специальные папки в Windows, что-то там свое в Linux и Mac OS X), нужно добиваться того, чтобы приложения выглядели не как типичное кроссплатформенное говно на Swing'е, нужно разобраться с зависимостями и потенциальными конфликтами библиотек,
TBM>Крч. нужно РАБОТАТЬ и реализовывать эти не сложные и довольно обыденные вещи, а не херней страдать — что есть самая большая помеха в жизни любого шароваршика и человека работающего на себя.
Если есть выбор между несколькими несложным вещами, которые можно сделать, я предпочту ту, где доход за час работы больше. Кроссплатформенность приносит очень мало дополнительных денег на вложенный час. Есть, конечно, исключения, навроде вебсерверов.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, TheByteMan, Вы писали:
TBM>>Здравствуйте, Нахлобуч, Вы писали:
Н>>>Нужно писать с учетом особенностей платформы (реестр и всякие специальные папки в Windows, что-то там свое в Linux и Mac OS X), нужно добиваться того, чтобы приложения выглядели не как типичное кроссплатформенное говно на Swing'е, нужно разобраться с зависимостями и потенциальными конфликтами библиотек,
TBM>>Крч. нужно РАБОТАТЬ и реализовывать эти не сложные и довольно обыденные вещи, а не херней страдать — что есть самая большая помеха в жизни любого шароваршика и человека работающего на себя.
S>Если есть выбор между несколькими несложным вещами, которые можно сделать, я предпочту ту, где доход за час работы больше. Кроссплатформенность приносит очень мало дополнительных денег на вложенный час. Есть, конечно, исключения, навроде вебсерверов.
У меня есть желание (с которым я вот уже несколько лет успешно борюсь ) под Мак попробовать портировать. Маков сейчас уже достаточно много и аудитория там весьма платежеспособная.
S>Стандартное-платное рекламируется, его не надо искать, его впаривают. И ещё то, что, если платно, значит качественно, S>если бесплатно, значит кактус.
Что, в принципе, подтверждается практическим опытом навроде фотошопа против гимпа, офиса против либреофиса, дельфи против лазаруса и проча.
Здравствуйте, Евгений Акиньшин, Вы писали:
S>>Если есть выбор между несколькими несложным вещами, которые можно сделать, я предпочту ту, где доход за час работы больше. Кроссплатформенность приносит очень мало дополнительных денег на вложенный час. Есть, конечно, исключения, навроде вебсерверов.
ЕА>У меня есть желание (с которым я вот уже несколько лет успешно борюсь ) под Мак попробовать портировать. Маков сейчас уже достаточно много и аудитория там весьма платежеспособная.
Если под винду нету ничего нового написать, то почему бы и не попробовать.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, TheByteMan, Вы писали:
TBM>>...и реализовывать эти не сложные и довольно обыденные вещи...
Н>Это с высоты собственного опыта говорится?
Я с Java не особо знаком, но с точки зрения библиотек элементов интерфейса на С++ и остальных платформозависимых мелочей, эти вещи что вы перечисли — они заурядны, и решаемы.
Здравствуйте, Khimik, Вы писали:
K> И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
wine это конкретный костыль. Просто зацените вот это
одно дублирование менюшек чего стоит. Вообщем если есть возможность — делать нейтивное или пользоватся либами типа Qt
Здравствуйте, smeeld, Вы писали:
S>>Что, в принципе, подтверждается практическим опытом навроде фотошопа против гимпа, офиса против либреофиса, дельфи против лазаруса и проча.
S>Опенсорс с древнейших времён ориентирован на созадние масштабных промышелнных систем.
Форум-то про шаровару, а не про масштабные промышленные системы. Мы масштабные промышленные системы не пишем, и не покупаем.
S>В этом были заинтересованы многие, S>так как запил таковых систем в пределах одной корпорации приводил к появления жутко дорого продукта. Модель опенсорса позоляла S>создавать системы-монстры, с минимум затрат со стороны создателей. Сравните теперь те продукты, которые писались для промышленного S>применения. Файловые системы, СУБД, демоны кластеризации, HPC фреймворки, специализированные модули сетевого взаимодействия и проча.
Не видел никого, у кого дома стояло бы что-то из этого. Файловые системы FAT да NTFS, а всего остального нет.
Здравствуйте, velkin, Вы писали:
V>Что касается стандартных библиотек, то нужно очень хорошо постараться, чтобы добиться несовместимости. Причём знающие люди понимают, что несовместимость может быть лишь в нестандартных реализациях. И зачем в таком случае применять нестандартные решения от какого-либо производителя выходящие за рамки спецификации стандартной библиотеки.
С одной стороны все правильно сказал, но и преувеличил тоже. Простой пример: sizeof(long) в 64-битной программе в Windows стандартно — 4 байта, в Linux — 8 байт (64 бита). И это надо учитывать. Это то, где можно вляпаться в несовместимость на уровне даже стандартных библиотек.
Здравствуйте, Sharowarsheg, Вы писали:
S>Не видел никого, у кого дома стояло бы что-то из этого. Файловые системы FAT да NTFS, а всего остального нет.
Извиняюсь что влез в домашние тапочки системы. Unix-ы и Unix-like-и изначально промышленные
системы, и, коль скоро тут говорится про одну из них, то счёл нужным акцентировать на это внимание.
Кстати, забыл выше упомянуть про виртуализацию. Вантузовский Hyper-V ещё более ущербный, по сравнению с
Xen/KVM/OpenVZ, чем гимпы и либреофисы ущербны в сравнении с фотошопами и прочими МС офисами.
Здравствуйте, Khimik, Вы писали:
K>Поясните сабж. Если пользователи Mac или Linux могут таким образом запускать Windows-программы, получается что Wine это как бы операционная система? Или как вообще выглядит процесс запуска программы из-под Wine? Как сделать, чтобы шаровара наилучшим образом работала под Wine? И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
Wine — это VmWare для бедных (тут Капитан Оч намекает на размер рынка и количество технических подкидонов у возжелавших). Задумывайтесь про Wine только тогда, когда у Вас все остальные проблемы уже решены.
Здравствуйте, Нахлобуч, Вы писали:
Н>Если делать "программку", то возможно и не несёт. А если делать полноценный продукт -- то еще как, и для типичного шароварщика-одиночки поддержка нескольких платформ может обернуться обширной головной болью.
Н>Нужно писать с учетом особенностей платформы (реестр и всякие специальные папки в Windows, что-то там свое в Linux и Mac OS X), нужно добиваться того, чтобы приложения выглядели не как типичное кроссплатформенное говно на Swing'е, нужно разобраться с зависимостями и потенциальными конфликтами библиотек, где требуется -- нужно написать инсталлятор и деинсталлятор, нужно написать документацию -- в идеале с картинками, нужно отвечать на письма в поддержку. Кучу работы нужно проделать. И выходит, что тезис о "не требует никаких усилий" -- это не совсем уж и правда.
Для описанных задач можно использовать Qt 4.8.x, для настроек QSettings, графический интерфейс будет выглядеть аналогично нативному. Что касается инсталлятора, то для Windows лучший выбор NSIS, для GNU/Linux есть deb, rpm и прочие. Для автоматической сборки под все платформы разом Jenkins. Для документации прекрасно подходит Doxygen, причём так же можно генерировать документацию с помощью Jenkins.
Что касается огромных программных продуктов уровня Enterprise, то здесь главное иметь возможность поддержки плагинов, и в Qt 4.8.x она имеется. Тем более, раз есть код, то и сама программа и плагины можно скомпилировать под множество операционных систем и архитектур процессоров.
То, что не потребует усилий — абсолютная правда, но давайте уточним. Если человек программирует в Qt Creator, то да, не потребует, более того можно сгенерировать проект для той же Visual Studio. Если же программист использует Visual Studio, то для перевода проекта в кроссплатформу потребуются усилия, даже если использовались кроссплафторменные библиотеки.
Можно использовать qmake, можно cmake и так далее, конечно программисту придётся иметь об этом представление. С другой стороны можно было бы использовать какой-нибудь nmake, его точно так же надо настраивать, с той лишь разницей, что это не кроссплатформа.
Ну и наконец не хочется поддерживать множество платформ, так и не надо. Если человек по каким-то причинам выбрал за основу Windows или Mac OS X, так и хорошо. Важно другое, в кроссплатформе можно простой компиляцией создать исполняемый файл для другой операционной системы.
Ещё раз повторю мысль, предположим человек прожжёный виндузятник, ну так и хорошо, программируй в винде для винды. Однако труд этого программиста принадлежит ему лично, а не корпорации Microsoft. Для шароварщика нет причин завязывать своё прикладное приложение на ОС.
Понятно, что есть приложения не нужные в других ОС, например, очередной оптимизатор Windows. Но это частный случай, причём сдаётся мне подобные программы потихоньку уходят в прошлое. Вообще большие корпорации действуют по следующему принципу:
Покуда живы жадины вокруг,
Удачи мы не выпустим из рук.
Какое небо голубое,
Мы не сторонники разбоя:
На жадину не нужен нож, —
Ему покажешь медный грошь
И делай с ним, что хошь!
Покуда есть на свете дураки,
Обманом жить нам, стало быть, с руки.
Какое небо голубое,
Мы не сторонники разбоя:
На дурака не нужен нож, —
Ему с три короба наврешь
И делай с ним, что хошь!
Например, аналитики уже давно говорят о том, что рынок мобильных приложений принесёт подавляющему числу разработчиков убытки, или по крайне мере не ту прибыль на которую они рассчитывали Тем не менее, Apple, Google и Microsoft продолжают зомбировать разработчиков.
Пользователи смартфонов и планшетов все чаще и чаще обращаются к сервисам рекомендаций, друзьям, социальным сетям или обращают внимание на рекламу в поиске мобильных приложений для своих девайсов вместо того, чтобы просеивать тысячи приложений, доступных в App Store и Google Play. Исследовательская компания Gartner полагает, что в 2018 году менее 0,01% мобильных приложений для потребителей будут считаться финансово успешными с точки зрения их разработчиков.
Пузырь доткомов — экономический пузырь, существовавший в период приблизительно с 1995 по 2001 год. Кульминация произошла 10 марта 2000 года, когда индекс NASDAQ достиг 5132,52 пункта в течение торгов и упал до 5048,62 при закрытии.
Последствия
Крах доткомов состоял в утере доверия к ценным бумагам высокотехнологических фирм, связанных с предоставлением услуг через интернет. Это было вызвано с одной стороны существенной переоценкой т. н. постиндустриальных технологий, которые на практике не оправдали приписываемых им ожиданий, с другой стороны имелись неконтролируемые спекуляции на этих ожиданиях, которые многократно усилили негативный эффект от падения доверия. Фактически прекратил свое существование целый сектор услуг, востребованность и ценность которых оказалась дутой. Это сопровождалось разорением тысяч фирм и компаний разного уровня, по большей части новообразованных.
Так вот, доткомы всё же успокоились. Со временем на рынок вышли новые SaaS, одни из них магазины приложений. Тем временем до десктопов и серверов наконец дошла возможность с лёгкостью создавать кроссплатформенные приложения. С помощью технологий 2000-х годов не сделать того, что сейчас не вызывает усилий.
Но это вовсе не значит, что подобные преимущества должны получить какие-нибудь школьники, тем более для них есть новый пузырь мобильных доткомов и они будут отвлечены им. С другой стороны некоторые бросают программирование после 30-ти, кто-то отказывается изучать улучшенные технологии.
Я исхожу из того, что шароварщики всё же не дураки, во всяком случае гораздо умнее школьников. Если никто не давит, то зачем писать в мусорку.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Wine — это VmWare для бедных
S>Бред. В линуксах из коробки два решения аппаратной виртуализации, ничем VmWare не уступающие, и wine S>к ним никакого отношения не имеет
Дык я почему и говорю — "для бедных". Т.е. это не полноценная виртуалка, а некая попытка натянуть сову на глобус, чтобы одна ось прикидывалась другой.
А, во, нашёл нужное слово: Wine — это софтверный трансвестит!
Здравствуйте, rean, Вы писали:
V>>Нужно применять стандарт, сказания о каких-то серьёзных проблемах выглядят как миф.
R>Мда. Вот как минимум те места, которые лично мне доставили немало головной боли:
R>Различие между типами std::wstring между Windows и другими (32 бит против 16) R>Разная кодировка у char* и std:string между Windows и другими (utf-8 против ansi/oem) R>Про открытие файлов с русскими именами лучше промолчу. А что делать с поддержкой длинных путей (>255 символов)? R>Буквально на прошлой неделе еще столкнулся с необходимостью на винде консоль переключать в бинарный вид, т.к. в линуксах все иначе.
Проще везде использовать UTF-8, нет никакого "utf-8 против ansi/oem". Это не проблема кроссплатформенности, это проблема того, что вам всё ещё не удалось на неё перейти.
R>В довесок почитайте MacOS и Windows user interface guidelines. Там все кардинально разнится. Программа, сделанная под винду, под маком выглядит странно, и наоборот. Про линуксовские библиотеки типа GTK вообще без слез нельзя говорить. Приплюсую сюда разницу между фонтами и их наличии в разных системах. А где хранить настройки и данные?
Читайте мой комментарий выше:
Для описанных задач можно использовать Qt 4.8.x, для настроек QSettings, графический интерфейс будет выглядеть аналогично нативному.
R>Не говорю уже про кардинальную разницу в API. Ну-ка, дайте мне доступ к DirectX на макосе. А также меня интересует доступ к другим специфичным апи, каких или не существует или они совсем другие. QT, говорите? Эта штука как наркота, добавив однажды ее в проект, уже от нее не избавиться никогда. Некоторые тащутся, разумеется.
Используйте OpenGL и движки на его основе, они ничем не уступают DirectX.
Причём здесь мои программы, посмотрите хотя бы на OpenCASCADE, OpenSceneGraph, BulletPhysics и огромное множество других библиотек. Они как раз стыкуются с теми самыми кнопочками из Qt 4.8.x. Кажется я писал уже это сотни раз, но повторюсь ещё один, основная фишка Qt 4.8.x вовсе не графическая библиотека виджетов, хотя и она на высоте, основная фишка это метаобъектная система.
Меня лично всё это не трогает, охота создавать не кроссплатформу, на здоровье. Просто аргументы уж больно наивные и не отражают действительность.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Wine — это VmWare для бедных (тут Капитан Оч намекает на размер рынка и количество технических подкидонов у возжелавших). Задумывайтесь про Wine только тогда, когда у Вас все остальные проблемы уже решены.
Да не сказал бы. У меня стоит на маке Parallels и я люто ненавижу запускать его. Пока вся эта дура прогрузится... тьфу. А Wine — оно "под рукой", сразу нужное приложение запускается и все. Ну, совместимость, ясное дело, хужее.
Здравствуйте, rean, Вы писали:
R>Согласен с вами, вы его писали, не имея реального опыта. Это вполне простительно начинающим программистам, поэтому с вами и не согласны.
. К программированию приобщился 17 лет назад, к линуксу 7-8, и возможно я действительно забыл, что такое тратить усилие на портирование. Это наверное как с компилятором, сначала допускаешь ошибки, он пишет, а ты не знаешь почему. Потом он пишет, и уже знаешь почему, а ошибки сразу исправляются. Но через десятилетия пишешь и ошибок больше нет.
Для меня не критично убить любое количество времени на изучение нужной мне технологии. В принципе я не против виндузятников, в конце концов сам таким был и прекрасно понимаю какими технологиями они орудуют. Немного жаль, что они попросту теряют время, но с другой стороны у каждого своя дорога.
R>Остальной ваш, извините, бред, комментировать не буду.
Ну, на нет, и суда нет. Хотя бы не будет бессмысленных батхёртов.
Здравствуйте, AlexRK, Вы писали:
ARK>Да не сказал бы. У меня стоит на маке Parallels и я люто ненавижу запускать его. Пока вся эта дура прогрузится... тьфу.
у меня (в вмваре под виндой) годами не перегружается линуксовая виртуалка. я её просто останавлива.ю когда нужно, потом возобновляю. гиг содерджимого озу считывается с диска и всё — можно работать
. К программированию приобщился 17 лет назад, к линуксу 7-8, и возможно я действительно забыл, что такое тратить усилие на портирование. Это наверное как с компилятором, сначала допускаешь ошибки, он пишет, а ты не знаешь почему. Потом он пишет, и уже знаешь почему, а ошибки сразу исправляются. Но через десятилетия пишешь и ошибок больше нет.
о, может хоть ты, большой белый человек подскажешь мне как:
— выводить юникодный текст на консоль
— получить криптографически случайные данные
— работать с файлами, имеющими имена в 1000 символов
— узнать общий объём озу, сколько из них доступно программе, и размер максимального доступного блока памяти
— записать данные в файл aux.cpp
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Khimik, Вы писали:
K>> И если она будет хорошо работать, тогда может быть и не потребуется портировать программу с Windows на Mac и Linux?
AB>Тут надо только понимать, что wine — это "игрушка" для того, чтобы поставить, посмотреть и снести все. Т.е. никто не будет в обычной жизни на Linux использовать ПО под Wine (ну если только совсем-совсем полная безнадега, но как пользователь я слабо себе это представляю). Второе — это то, что под Linux очень много хорошего свободного ПО на все случаи жизни и конкурировать с ним очень-очень непросто, по этому программа должна представлять собой нечто экстраординарное, чтобы быть купленной вместо имеющегося аналога.
>Т.е. никто не будет в обычной жизни на Linux использовать ПО под Wine
Бред. Мою программу используют под Wine на линуксе и даже на маке.
>что под Linux очень много хорошего свободного ПО на все случаи жизни и конкурировать с ним очень-очень непросто
Спасибо, посмеялся.
Здравствуйте, Zenden, Вы писали:
Z> >Т.е. никто не будет в обычной жизни на Linux использовать ПО под Wine Z> Бред. Мою программу используют под Wine на линуксе и даже на маке.
Ну либо она представляет из себя нечто уникальное, либо у тебя недостоверная информация.
Z> >что под Linux очень много хорошего свободного ПО на все случаи жизни и конкурировать с ним очень-очень непросто Z> Спасибо, посмеялся.
Пожалуйста, но мне, как пользователю у которого Linux является основной (и единственной) системой, все же виднее.
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, BulatZiganshin, Вы писали:
BZ>о, может хоть ты, большой белый человек подскажешь мне как: BZ>- выводить юникодный текст на консоль
Можно создать свою встраиваемую консоль с помощью QProcess, над ней будет полный контроль, махом решается множество проблем, появляются огромные возможности.
BZ>- получить криптографически случайные данные
Цель не ясна, для меня в своё время лучшим выбором была Crypto++ Library, лицензия Boost Software License 1.0, кроссплатформа.
BZ>- работать с файлами, имеющими имена в 1000 символов
Зависит от файловой системы, как и размер файлов. Некоторые проекты используют вместо имени файла его хеш-сумму, а описания хранят в базе данных, хотя другие утверждают, что без базы эти файлы станут бесполезны. К тому же здесь дело не просто в файле, а в полном пути к файлу. Учитывая разнообразие файловых систем лично я бы не стремился к 1000, иначе при копировании с одной ФС на другую выйдет очень большая пакость.
BZ>- узнать общий объём озу, сколько из них доступно программе, и размер максимального доступного блока памяти
Для прикладных приложений это называется системный монитор. В гугле вижу готовые кроссплатформенные решения, но сам ничего предлагать не буду, так как мне это на практике никогда не пригождалось.
Вообще, если рекомендую библиотеку, то не просто потому что взял первую попавшуюся и мне понравилось, а потому что попробовал все топовые аналоги и эта была лучшей. Минимальные требования — максимальная функциональность, кроссплатформенность, открытый исходный код, бесплатное использование в коммерческих целях.
) под Мак попробовать портировать. Маков сейчас уже достаточно много и аудитория там весьма платежеспособная.
