Здравствуйте, Евгений Акиньшин, Вы писали:
S>>Если есть выбор между несколькими несложным вещами, которые можно сделать, я предпочту ту, где доход за час работы больше. Кроссплатформенность приносит очень мало дополнительных денег на вложенный час. Есть, конечно, исключения, навроде вебсерверов.
ЕА>У меня есть желание (с которым я вот уже несколько лет успешно борюсь ) под Мак попробовать портировать. Маков сейчас уже достаточно много и аудитория там весьма платежеспособная.
Если под винду нету ничего нового написать, то почему бы и не попробовать.
Здравствуйте, Sharowarsheg, Вы писали:
S>Что, в принципе, подтверждается практическим опытом навроде фотошопа против гимпа, офиса против либреофиса, дельфи против лазаруса и проча.
Опенсорс с древнейших времён ориентирован на созадние масштабных промышелнных систем. В этом были заинтересованы многие,
так как запил таковых систем в пределах одной корпорации приводил к появления жутко дорого продукта. Модель опенсорса позоляла
создавать системы-монстры, с минимум затрат со стороны создателей. Сравните теперь те продукты, которые писались для промышленного
применения. Файловые системы, СУБД, демоны кластеризации, HPC фреймворки, специализированные модули сетевого взаимодействия и проча.
Нет вот выцепили тему, которая опенсорсниками никогда не воспринималась как первоочередная. Тот же гимп никто не собирался доводить
до состояния фотошопа в плане свисточихалок. А того функционала, что реализовали, создателям было достаточно.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, TheByteMan, Вы писали:
TBM>>...и реализовывать эти не сложные и довольно обыденные вещи...
Н>Это с высоты собственного опыта говорится?
Я с Java не особо знаком, но с точки зрения библиотек элементов интерфейса на С++ и остальных платформозависимых мелочей, эти вещи что вы перечисли — они заурядны, и решаемы.
Здравствуйте, TheByteMan, Вы писали:
TBM>Я с Java не особо знаком, но с точки зрения библиотек элементов интерфейса на С++ и остальных платформозависимых мелочей, эти вещи что вы перечисли — они заурядны, и решаемы.
Java я упомянул как квинтэссенцию всего плохого, чего только может случиться в UI в кроссплатформенном приложении.
А что касается заурядности и решаемости -- то тут ну совершенно не согласен. Даже в рамках одной платформы порой требуются незаурядные навыки филигранной резьбы по граблям (например, из своего опыта, поддержка работы на всех Windows Server начиная с версии 2003 и выше), чего уж говорить о вообще разных окружениях.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, 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
) под Мак попробовать портировать. Маков сейчас уже достаточно много и аудитория там весьма платежеспособная.
