Здравствуйте, alpha21264, Вы писали:

A>В Линуксе совместимость на уровне исходников. И оно работает уже как минимум 20 лет.
Нихрена подобного. Там тоже любят добавить какю-нибудь basic_string::compare что бы понасрать.
Вы попробуйте на старом линухе qt6 приложение запустить. Или наоборот собрать то что требовало старые библиотеки, начинается несовместимости.
Например openssl решила что обратная совместимость это для слабаков. Да куда не плюнь, везде стараются сделать побольше треша, угара и копоти.
Если раньше консоль могла разные кодировки и прозрачный фон, то совремнная больше не может. Старые методы криптографии, вместо отключения по умолчанию, просто
выкидывают. В результате не возмоно подключится к старому оборудованию. Куда не глянь работает только здесь и сейчас на текущих версиях, что будет завтра всем пофиг.
Даже при сборке из докера с фиксированными верисями можно столкнуться что определённые версии удалены из-за соображений "безопасности",
а с другими без бубна не собирается или собирается, но работает как-то не так.

Здравствуйте, scf, Вы писали:

scf>Под линуксом еще веселее — хочешь собрать гуевое приложение, которое без проблем запустится через 10 лет? Линкуй всё статически и молись, чтобы xorg не сломали.

В Линуксе совместимость на уровне исходников. И оно работает уже как минимум 20 лет.

scf>таскай с собой библиотеки компонетов и рендер.
Использование библиотек и компонентов — это решение задач сведением к предыдущей.

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

Затем задачу упростили: предложен чайник, наполненный водой и плита с горящим газом. Цель та же — вскипятить воду. Физик ставит чайник на огонь. Математик выливает из чайника воду, выключает газ и говорит: "Задача свелась к предыдущей."

Нужен ИИ, переписывающий код на без компонентов. В сплошной гетерастический монолит.

Здравствуйте, scf, Вы писали:

scf>У меня есть ответ и я хотел бы поделиться им с вами: совместимость и мультиплатформенность.

scf>В старые добрые времена можно было подключить в проект COMCTL32.dll (1-2 мегабайта) и рисовать гуй, а добрый Макйрософт своими силами обеспечивал запуск вашего приложения на любой винде.
ну и сейчас можно взять mono и рисовать на winforms.
ругают электрон. но посмотрите. рсдн жрет под 100МБ в обычном браузере.
потому что много визуала. с другой стороны возьмите оберон (хотя бы блэкбокс), 4МБ среда разработки и исполнения.
Компилил exe с msgbox. 4К. старт молниеносный. Но при этом интерфейс аля виндос 95 или даже хуже.
Софт сейчас делают не для обработки данных, а для увеличения продаж.
те тоже сайт это побочка главная цель напихать в него скрытой рекламы.
например прайм кнопка яркая(купить), вторичная — серая (отмена).

скорость света уменьшается, астрономы не дадут соврать
вот и замедляются электроны в ЭВМ

Здравствуйте, scf, Вы писали:

scf>У меня есть ответ и я хотел бы поделиться им с вами: совместимость и мультиплатформенность.

А я читал статью и там утверждалось, что на производительность не закладываются финансы. Банально нужны более квалифицированные программисты, больше времени на разработку и кто-то ещё должен за это платить.

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

Есть ещё расслабляющие факторы, такие как производительное аппаратное обеспечение и цифровое распространение программ. Но главная причина именно в том, что изначально не закладываются требования производительности.

Здравствуйте, Doom100500, Вы писали:

D>На что конкретно здесь смотреть?

На сумму чисел в Private Bytes для всех процессов хрома.
Ибо это вся эта трахомудия нужна чтоб показать даже одну сраную страницу.

У меня есть ответ и я хотел бы поделиться им с вами: совместимость и мультиплатформенность.

В старые добрые времена можно было подключить в проект COMCTL32.dll (1-2 мегабайта) и рисовать гуй, а добрый Макйрософт своими силами обеспечивал запуск вашего приложения на любой винде.

А сейчас? На обратную совместимость все забили, хочешь стабильного запуска на всех системах — тестируй на всех системах или таскай зависимости с собой. Хочешь мультиплатформенный гуй — таскай с собой библиотеки компонетов и рендер.

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

Здравствуйте, scf, Вы писали:

scf> А сейчас? На обратную совместимость все забили, хочешь стабильного запуска на всех системах — тестируй на всех системах или таскай зависимости с собой. Хочешь мультиплатформенный гуй — таскай с собой библиотеки компонетов и рендер.

Или просто бери Delphi/C++Builder и будет тебе счастье! Сто лет инструментам, а до сих пор нос утирают всем вокруг на раз-два.

Здравствуйте, Разраб, Вы писали:

Р>рсдн жрет под 100МБ в обычном браузере.
Р>потому что много визуала.

Я Вас умоляю. На весь "визуал", что есть в RSDN, с лихвой достаточно пары-тройки мегабайт.

Здравствуйте, scf, Вы писали:

На самом деле правильный ответ — потому что в индустрии стало слишком много людей, которые хорошо умеют говорить и очень плохо умеют кодить. Брукс писал про эту проблему лет 15 назад, и с тех пор стало еще намного хуже.

S>Статически собранные QWidgets + QCore и сейчас дадут 5-6 мегабайт и будут работать почти на любой платформе.

Чтобы получилось нативное решение придется вести разработку вести на С++, либо использовать биндинги к языкам, компилируемым в нативный код: Rust, Go lang, D lang и пр. (https://wiki.qt.io/Language_Bindings)
В этом плане интерес представляет разработка на GTK: можно писать код на Vala (язык похож на C#), который затем транспайлится в С++ и компилируется в нативный.

Я ещё хотел попробовать Dart (там тоже траспайлер), но нет компиляции нативного кода под 32битный x86.

Здравствуйте, Skorodum, Вы писали:

scf>>Вообще есть — Java. Но этот путь хоть и легче, но с особенностями.
S>А есть примеры широко используемых приложений кросс-плотформенных приложений на Java?
S>Я в жизни таких не видел

SmartGit

Здравствуйте, rudzuk, Вы писали:


R>Или просто бери Delphi/C++Builder и будет тебе счастье! Сто лет инструментам, а до сих пор нос утирают всем вокруг на раз-два.

Только вакансий по ним нет

Здравствуйте, scf, Вы писали:


Приложения на Электроне всё сожрут, что смогут

Здравствуйте, Mihal9, Вы писали:

M>Приложения на Электроне всё сожрут, что смогут
Их порвёт раньше.
Даже крохотные прилаги жрут как не в себя, никакая жаба с дотнетом по ресурсоёмкости не сравнится

Здравствуйте, alpha21264, Вы писали:

A>В Линуксе совместимость на уровне исходников. И оно работает уже как минимум 20 лет.

А ты пробовал программу, написанную 20 лет назад, компилировать современным gcc/clang.

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

P.S. Ну а внутри ядра совместимость по исходникам никто не обещал и никто и не поддерживает...

Здравствуйте, Разраб, Вы писали:

Р>ругают электрон. но посмотрите. рсдн жрет под 100МБ в обычном браузере.
И правильно ругают, ибо дотнетовый клиент Janus жрёт в два раза меньше и при этом работает куда быстрее и удобнее.

Здравствуйте, scf, Вы писали:

scf>совместимость и мультиплатформенность.

В каком месте они находятся у функционально примитивных андроидных приложений на 10-50-100 Мб?

scf>В старые добрые времена можно было подключить в проект COMCTL32.dll (1-2 мегабайта) и рисовать гуй, а добрый Макйрософт своими силами обеспечивал запуск вашего приложения на любой винде.

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Разраб, Вы писали:

Р>>рсдн жрет под 100МБ в обычном браузере.
Р>>потому что много визуала.

ЕМ>Я Вас умоляю. На весь "визуал", что есть в RSDN, с лихвой достаточно пары-тройки мегабайт.
посмотрите в хром, доп инструменты диспетчер задач

Здравствуйте, scf, Вы писали:

scf>Вообще есть — Java. Но этот путь хоть и легче, но с особенностями.
А есть примеры широко используемых приложений кросс-плотформенных приложений на Java?
Я в жизни таких не видел

Здравствуйте, Skorodum, Вы писали:

scf>>Вообще есть — Java. Но этот путь хоть и легче, но с особенностями.
S>А есть примеры широко используемых приложений кросс-плотформенных приложений на Java?
S>Я в жизни таких не видел
Burp?

Здравствуйте, Mihal9, Вы писали:

M> R>Или просто бери Delphi/C++Builder и будет тебе счастье! Сто лет инструментам, а до сих пор нос утирают всем вокруг на раз-два.

M> Только вакансий по ним нет

Есть

Здравствуйте, Osaka, Вы писали:

O>Нужен ИИ, переписывающий код на без компонентов. В сплошной гетерастический монолит.
Т.е. статическая линковка

Здравствуйте, scf, Вы писали:

scf>Под линуксом еще веселее — хочешь собрать гуевое приложение, которое без проблем запустится через 10 лет? Линкуй всё статически и молись, чтобы xorg не сломали.

Разве X11 (он же xorg) когда-нибудь ломали? Иксы — это старая школа. Они вам здесь вам не тут.

O>>Нужен ИИ, переписывающий код на без компонентов. В сплошной гетерастический монолит.
CC>Т.е. статическая линковка
Это не решает проблему прожорливости. Нужно исключить "выливание воды из чайника". Вместо вызова длинной подпрограммы из универсального компонента (которая тоже вызывает подпрограммы, и так далее на 1000 уровней вложенности) — нужно откопипастить из них всех только то что требуется сделать в данной ситуации.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, alpha21264, Вы писали:

A>>В Линуксе совместимость на уровне исходников. И оно работает уже как минимум 20 лет.

Pzz>А ты пробовал программу, написанную 20 лет назад, компилировать современным gcc/clang.

Pzz>Нет, если она очень аккуратно написана, то даже, наверное, очень-то больших проблем и не будет. Но что всё совсем гладко и без усилий пройдет, не поручусь...

Пробовал.
Вот прямо сейчас я работаю с Qt-2.3.2
Она именно в 2005 году и была написана.
Собирается и работает.

И вообще, я такие вещи довольно часто пробую.
Как равило, получается.

Pzz>P.S. Ну а внутри ядра совместимость по исходникам никто не обещал и никто и не поддерживает...

Интересно, что ты имеешь в виду под "совместимость по исходникам внутри ядра"?
Кусок из одного ядра вставить в другое? Ну разумеется, работать не будет.
Ну так это же две разные программы! Да и зачем это может понадобиться?

Здравствуйте, alpha21264, Вы писали:

Pzz>>P.S. Ну а внутри ядра совместимость по исходникам никто не обещал и никто и не поддерживает...

A>Интересно, что ты имеешь в виду под "совместимость по исходникам внутри ядра"?
A>Кусок из одного ядра вставить в другое? Ну разумеется, работать не будет.
A>Ну так это же две разные программы! Да и зачем это может понадобиться?

Драйвера, модули...

Здравствуйте, Osaka, Вы писали:

O>Нужно исключить "выливание воды из чайника". Вместо вызова длинной подпрограммы из универсального компонента (которая тоже вызывает подпрограммы, и так далее на 1000 уровней вложенности) — нужно откопипастить из них всех только то что требуется сделать в данной ситуации.

Ты описал IPO/WPO, только ты хочешь на уровне доказательства всех путей по которым может пойти исполнение.

Р>ругают электрон. но посмотрите. рсдн жрет под 100МБ в обычном браузере.

смотрю about:performance в Firefox: вкладки RSDN занимают 4-12MB каждая.

Здравствуйте, m2user, Вы писали:

M>смотрю about:performance в Firefox: вкладки RSDN занимают 4-12MB каждая.
Это всё свистёш
Что показывает ProceXP?

Здравствуйте, Pzz, Вы писали:

Pzz>Разве X11 (он же xorg) когда-нибудь ломали? Иксы — это старая школа. Они вам здесь вам не тут.

Идут работы по его выкидыванию.

Здравствуйте, CreatorCray, Вы писали:

CC>Что показывает ProceXP?

На что конкретно здесь смотреть?

Здравствуйте, Doom100500, Вы писали:

Pzz>>Разве X11 (он же xorg) когда-нибудь ломали? Иксы — это старая школа. Они вам здесь вам не тут.

D>Идут работы по его выкидыванию.

уж давно идут...

Здравствуйте, scf, Вы писали:

scf>В старые добрые времена можно было подключить в проект COMCTL32.dll (1-2 мегабайта) и рисовать гуй, а добрый Макйрософт своими силами обеспечивал запуск вашего приложения на любой винде.
Статически собранные QWidgets + QCore и сейчас дадут 5-6 мегабайт и будут работать почти на любой платформе.

Здравствуйте, m2user, Вы писали:

M>Чтобы получилось нативное решение придется вести разработку вести на С++, либо использовать биндинги к языкам, компилируемым в нативный код: Rust, Go lang, D lang и пр. (https://wiki.qt.io/Language_Bindings)
M>В этом плане интерес представляет разработка на GTK: можно писать код на Vala (язык похож на C#), который затем транспайлится в С++ и компилируется в нативный.
Можно, но зачем? Чем С++ не нравится для кросс-платформенной разрабоки декстопных приложений?

Здравствуйте, Евгений Музыченко, Вы писали:

scf>>совместимость и мультиплатформенность.

ЕМ>В каком месте они находятся у функционально примитивных андроидных приложений на 10-50-100 Мб?

ios. Никто не горит желанием пилить отдельное приложение с тем же функционалом на свифте.

M>>смотрю about:performance в Firefox: вкладки RSDN занимают 4-12MB каждая.

CC>Это всё свистёш
CC>Что показывает ProceXP?

ProceXP у меня нет, воэтому вот так.
Без вкладок и после открытия четырёх вкладок: нода форумов и 3 темы.

	Цифырьки действительно другие.
	<===========================================================================================================> <===========================================================================================================>

Здравствуйте, scf, Вы писали:

scf>ios. Никто не горит желанием пилить отдельное приложение с тем же функционалом на свифте.

Да ладно. Примитивных приложений в десятки мегабайт хватало и десять лет назад, когда их делали только для андроида.

Здравствуйте, m2user, Вы писали:

M>Чтобы получилось нативное решение придется вести разработку вести на С++
Не вижу проблемы

Здравствуйте, m2user, Вы писали:

M>Чтобы получилось нативное решение придется вести разработку вести на С++, либо использовать биндинги к языкам

В dotnet сейчас много сил вкладывается в NativeAot. У Avalonia UI есть поддержка. GtkSharp тоже можно собрать нативно.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Doom100500, Вы писали:

D>>На что конкретно здесь смотреть?

CC>На сумму чисел в Private Bytes для всех процессов хрома.
CC>Ибо это вся эта трахомудия нужна чтоб показать даже одну сраную страницу.

И как по этому определить что именно было потрачено на обработку rsdn.js и рендер rsdn.html, а не не поиск обновлемний, отправку телеметрии, google keylogger, и т.д?
Сумма Private bytes на пустой странице у меня вышла больше, чем при открытии example.com

S>Можно, но зачем? Чем С++ не нравится для кросс-платформенной разрабоки декстопных приложений?

С/C++ годится при наличии достаточного опыта проф. разработки на нем. Если такого нет, то тратить время на изучение может быть нецелесообразно.

M>>Чтобы получилось нативное решение придется вести разработку вести на С++, либо использовать биндинги к языкам

A>В dotnet сейчас много сил вкладывается в NativeAot.

да, стоит тоже посмотреть, но для self-contained размер приличный
https://old.reddit.com/r/csharp/comments/13gsdat/self_contained_net_apps_have_a_big_size_why/?sort=old


Кроме того, нет кросс-компиляции:
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/cross-compile

Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL.

И нет поддержки 32битных ОС (также как у Dart)
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows#platformarchitecture-restrictions

A>GtkSharp тоже можно собрать нативно.

Чего-то сходу не нахожу информации по нативной сборке в GtkSharp.

Здравствуйте, Doom100500, Вы писали:

D>И как по этому определить что именно было потрачено на обработку rsdn.js и рендер rsdn.html
А какая разница сколько потрачено именно на это если всё равно надо запускать и держать всё дерево процессов браузера чтоб на эту страничку смотреть и что то с ней делать?

Здравствуйте, m2user, Вы писали:

M>да, стоит тоже посмотреть, но для self-contained размер приличный

Self-contained это когда дотнетовский рантайм идет вместе с приложением, можно уменьшить размер с помощью PublishTrimmed, если библиотеки поддерживают. У NativeAot размер изначально значительно меньше, так как он делает trim по умолчанию.

M>Кроме того, нет кросс-компиляции:

Сейчас виртуалку поднять не проблема, тем более она все-равно понадобится для тестирования.

A>>GtkSharp тоже можно собрать нативно.

M>Чего-то сходу не нахожу информации по нативной сборке в GtkSharp.

Тоже что-то не могу , похоже, спутал с PublishTrimmed.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Doom100500, Вы писали:

D>>И как по этому определить что именно было потрачено на обработку rsdn.js и рендер rsdn.html
CC>А какая разница сколько потрачено именно на это если всё равно надо запускать и держать всё дерево процессов браузера чтоб на эту страничку смотреть и что то с ней делать?

Эта ветка началась с обвинения именно кывта в прожорливости, разве нет?

Здравствуйте, Разраб, Вы писали:

ЕМ>>На весь "визуал", что есть в RSDN, с лихвой достаточно пары-тройки мегабайт.

Р>посмотрите в хром, доп инструменты диспетчер задач

Почему именно в хром, а не в карман, ящик или телескоп?

Здравствуйте, m2user, Вы писали:

M>С/C++ годится при наличии достаточного опыта проф. разработки на нем. Если такого нет, то тратить время на изучение может быть нецелесообразно.
Так альтернатив не так чтобы много и порог вхождения там тоже не такой уж и маленикий.
Сделать хорошее кросс-платформенное приложение это не дешево и по времени и по требуемым навыкам, тут какого-то особого легкого пути.

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

Ну если взять тот же QT и поставить условием компиляцию в нативный код, то для QT есть биндинги (third party):
Qt for Rust
Qt for Go
Qt for D
и др. тут https://wiki.qt.io/Language_Bindings

У Golang то всяко порог вхождения меньше.

Здравствуйте, Skorodum, Вы писали:

S>Сделать хорошее кросс-платформенное приложение это не дешево и по времени и по требуемым навыкам, тут какого-то особого легкого пути.

Вообще есть — Java. Но этот путь хоть и легче, но с особенностями.

Здравствуйте, Doom100500, Вы писали:

D>Эта ветка началась с обвинения именно кывта в прожорливости, разве нет?
Электрона

Здравствуйте, Wawan, Вы писали:

W>вот и замедляются электроны в ЭВМ

Дак то в ЭВМ. Которые уже давно компьютерами заменили везде, где только можно. Электрону бежать ближе. Препятствий меньше.

Здравствуйте, Codealot, Вы писали:

C>На самом деле правильный ответ — потому что в индустрии стало слишком много людей, которые хорошо умеют говорить и очень плохо умеют кодить. Брукс писал про эту проблему лет 15 назад, и с тех пор стало еще намного хуже.

Не соглашусь. Я вот хорошо умею кодить и как-то захотел сделать мультиплатформенное приложение. И осознал, что всё требует жертв (со стороны пользователя) — и мультиплатформенность, и совместимость.
"олд скул" подход — писать 3 разных приложения под 3 разных ОС. Но это дорого и долго, и остается вопрос, что делать с прямой совместимостью? Это под виндой отлично работают приложения, созданные для win95, в линуксе все тухло. С маком не знаком, не могу рассуждать.

Здравствуйте, scf, Вы писали:

scf>Не соглашусь. Я вот хорошо умею кодить и как-то захотел сделать мультиплатформенное приложение. И осознал, что всё требует жертв (со стороны пользователя) — и мультиплатформенность, и совместимость.
scf>"олд скул" подход — писать 3 разных приложения под 3 разных ОС. Но это дорого и долго, и остается вопрос, что делать с прямой совместимостью? Это под виндой отлично работают приложения, созданные для win95, в линуксе все тухло. С маком не знаком, не могу рассуждать.

Прямой совместимости нет. Для кроссплатформенного приложения нужно выбирать хорошую оболочку — джаву какую, например, qt, electron итд.

Мы лет 10 назад держали 4 платформы на одной кодовой базе, даже жээсом это довольно трудно — затейники в эпле ухитряются ломать самые неожиданные места и так каждый! релиз.

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

После перехода на кроссплатформенную архитектуру команда разработки вместе с тестированием ужалась основательно — раза в три.

Здравствуйте, scf, Вы писали:

scf>Не соглашусь. Я вот хорошо умею кодить и как-то захотел сделать мультиплатформенное приложение. И осознал, что всё требует жертв (со стороны пользователя) — и мультиплатформенность, и совместимость.
scf>"олд скул" подход — писать 3 разных приложения под 3 разных ОС. Но это дорого и долго, и остается вопрос, что делать с прямой совместимостью? Это под виндой отлично работают приложения, созданные для win95, в линуксе все тухло. С маком не знаком, не могу рассуждать.

Это вообще параллельно. Так что непонятно, с чего ты решил не соглашаться.

Здравствуйте, Skorodum, Вы писали:

S>Здравствуйте, scf, Вы писали:

scf>>Вообще есть — Java. Но этот путь хоть и легче, но с особенностями.
S>А есть примеры широко используемых приложений кросс-плотформенных приложений на Java?
S>Я в жизни таких не видел


я с вами согласен на 101% но

https://www.ibm.com/products/websphere-application-server
SonarQube

Здравствуйте, sergey2b, Вы писали:

S>я с вами согласен на 101% но

S>https://www.ibm.com/products/websphere-application-server
S>SonarQube

Звучит как "кровавый энтерпрайз", оно?

Страница пару минут загрузилась

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>SmartGit
Спасибо. Заявляют 100К установок, это уже хоть что-то.

Здравствуйте, scf, Вы писали:

scf>"олд скул" подход — писать 3 разных приложения под 3 разных ОС. Но это дорого и долго, и остается вопрос, что делать с прямой совместимостью? Это под виндой отлично работают приложения, созданные для win95, в линуксе все тухло.
Привиди пример, где в ядре линукса неоправдано ломали прямую совместимость.

Здравствуйте, Skorodum, Вы писали:


S>Звучит как "кровавый энтерпрайз", оно?

да

S>Страница пару минут загрузилась

в США и канаде половина гос организаций используют этот сервер

Здравствуйте, sergey2b, Вы писали:

S>в США и канаде половина гос организаций используют этот сервер
Это, конечно же, очень денежный рынок, и если туда попал, то жизнь удалась, но интересуют примеры где надо выживать в условиях открытого рынка. Примеров коммерчески успешных кросс-платформенных десктопных приложений на яве которыми пользуются миллионы как-то не особо видно.

Здравствуйте, Igore, Вы писали:

I>Burp?
Звучит как отрыжка