В случае FAR там и альтернативы нет, учитывая завязанность на сравнительно низкоуровневую работу с файловой системой, для портирования на другую ОС необходимо дописывать специфичный для неё код. Но в far2l решили постараться, да.
Там ещё добавлялось то, что практически весь софт был 32-битным и поэтому особого смысла ставить 64-бита и не было… Это уже потом подтянулись, со временем.
1) Зависит, особенно заметно, если структур много (можно проверить через about:memory в чём-то firefox-подобном).
2) Если «обратная совместимость» заключается в том, чтобы на время добавить в ОС эмулятор предыдущей архитектуры и «дать толчок» на переписывание софта для новой… ну это такое. Самое стабильное в плане обратной совместимости сейчас, как ни странно — Windows…
3) В плане качественного воспроизведения 1080p это, скорее, к GPU (которые быстро развиваются и поэтому и устаревают быстрее). Причем, как я помню, это работало ещё на GTS 450, если это H264. Технологии, может, и развиваются, но требовать для софта выделения кучи ресурсов просто потому, что разработчик не смог в нативное приложение и написал всё под браузер… Нет, пусть лучше такие организации обанкротятся и их место займёт кто-то более вменяемый.
PWA это просто ярлык на рабочий стол для сайта, ну разница в том, что не электрон, а системный браузер будет отображать сайт. Нативное приложение это не заменит, если, конечно, не имелся в виду просто доступ к сайту через webview.
В плане выделения памяти под различные структуры, если их много, разница достаточно заметна. Конечно, если нужно использовать памяти больше, чем лимит для 32 бит, альтернативы 64-битным приложениям нет.
Apple же может себе позволить не то, что 32 бита выкинуть, а и на совсем другую архитектуру перейти, обратная совместимость это не их сильная сторона.
Память, может, и дешёвая, но иногда её просто некуда добавлять, т.е. альтернатива — купить новое устройство.
Можно, конечно, но туда, по ходу, и просто memory-mapped files попадут… И вообще, там не обязательно то, что именно записано в своп, а то, что зарезервировалось, но пока не используется.
А вообще всё, что процесс захотел себе зарезервировать (включая shared), отображается в commit size.
Ну, в линуксах — да, наверное, ведь не все дистрибутивы тащат с собой 32-битные библиотеки. А так — ничего закапывать не надо, 32-битный процесс технически жрёт меньше памяти, чем 64-битный (особенно заметно на браузерах), в этом и преимущество.
p.s. у меня 32-битный браузер не падает. Наверное, потому, что я не пытаюсь использовать больше памяти, чем ему может быть доступно :)
И к мобильным, и к десктопным версиям всё равно нужен свой нативный интерфейс, иначе будет одинаково плохо и на мобилках и на десктопах. Браузер здесь не подходит.
К счастью, пока проще забыть о веб-софте на десктопе, чем страдать от его тормознутости, кривого интерфейса и жора памяти (ну лично мне… может, где-то есть и безальтернативный такой софт, но пока не встречался).
Про скайп могу только сказать, что он прошёл стадию «был продан другой компании и затем практически уничтожен», не в последнюю очередь из-за «переписать заново» — выбранного нового стека (веб-технологии вместо нативного), ну и редизайна интерфейса.
Нет же. Основные проблемы не в обратной совместимости, а в том, что стали тащить веб-технологии на десктоп. Просто надо использовать технологии по назначению, иначе продукт в итоге будет одинаково негодным, что на Windows, что на Linux…
Вообще, есть нормальный софт, работающий на десктопах с разными ОС, это, в основном, опенсорс, вот только не на мобилках. Впрочем и у мессенджеров для мобилок совершенно отдельные нативные приложения.
Для построения кроссплатформенных приложений лучше взять не интерпретируемый язык программирования и компилировать под каждую платформу нативный код. И да, интерфейс под каждую платформу должен быть тоже нативным. Телеграм ведь как-то справляется…
Для wiki и google (в смысле, именно поисковик) palemoon более 200-300мб памяти не будет жрать, вот с gmail, как и всё, что «веб-приложение» уже проблема, да.
А, ещё если видеокарта встройка — разумеется, ей надо откуда-то брать свою память.
2) Если «обратная совместимость» заключается в том, чтобы на время добавить в ОС эмулятор предыдущей архитектуры и «дать толчок» на переписывание софта для новой… ну это такое. Самое стабильное в плане обратной совместимости сейчас, как ни странно — Windows…
3) В плане качественного воспроизведения 1080p это, скорее, к GPU (которые быстро развиваются и поэтому и устаревают быстрее). Причем, как я помню, это работало ещё на GTS 450, если это H264. Технологии, может, и развиваются, но требовать для софта выделения кучи ресурсов просто потому, что разработчик не смог в нативное приложение и написал всё под браузер… Нет, пусть лучше такие организации обанкротятся и их место займёт кто-то более вменяемый.
Apple же может себе позволить не то, что 32 бита выкинуть, а и на совсем другую архитектуру перейти, обратная совместимость это не их сильная сторона.
Память, может, и дешёвая, но иногда её просто некуда добавлять, т.е. альтернатива — купить новое устройство.
А вообще всё, что процесс захотел себе зарезервировать (включая shared), отображается в commit size.
p.s. у меня 32-битный браузер не падает. Наверное, потому, что я не пытаюсь использовать больше памяти, чем ему может быть доступно :)
К счастью, пока проще забыть о веб-софте на десктопе, чем страдать от его тормознутости, кривого интерфейса и жора памяти (ну лично мне… может, где-то есть и безальтернативный такой софт, но пока не встречался).