И как вы себе это представляете? Легитимные на то и легитимные, так как используются другим ПО для работы на конкретной системе. Мне легче рассуждать про тот же Linux, и там есть куча зависимостей, запуск того же bash и других командных интерпретаторов, python, возможно где-то даже perl остался. И вот теперь прикол — разрешая те же bash/python/perl вы по сути разрешаете запуск любого кода, так как не существует механизмов, позволяющих корректно это контролировать. Выстрелить себе в ногу тут очень просто. Фильтрация аргументов — это задача ещё сложнее, так как даже у разных версий одной софтины они могут быть разные, это дополнительно осложняется тем, что опции в аргументах могут идти в любом порядке, плюс могут агрегироваться, а также иметь краткую и полную форму. Тут выстрелить себе в ногу ещё проще, чем очень просто. И самое смешное, что это в итоге не поможет, так как существуют пути безфайлового запуска (то есть пути к исполняемому файлу нет, аргументов тоже) или ещё более продвинутые техники по инъекции кода в уже существующий процесс. В общем, вариантов достаточно и это не то чтобы какая-то недоступная массам технология — рабочих экземпляров достаточно лежит в паблике.
Та же упомянутая в статье Evo.industry 2025 указывает, что основная аудитория — это всевозможные директора, которые и сами не знают, как у них всё устроено. Крупные компании используют харденинг, но это не панацея, как уже отметили выше. Есть достаточное количество легитимных и идущих из коробки утилит, которые позволяют обойти ограничения того же SRP или noexec (в случае Linux) и закинуть нужный софт туда, откуда можно. Если уж вспоминать про атаки тех же ransomware-групп, то они первоочередной целью ставят получение доступа к контроллеру домена, а там уже с правами администратора домена их уже сложно будет остановить. Атак на протокол Kerberos в AD существует достаточно, и вот чтобы их вовремя ловить и нужен мониторинг, причём речь не только про сами логи, но и правила детекта этих атак. Но это такой взгляд со стороны линуксоида, которому коллеги-эксперты по Windows показывают атаки на неё. Впрочем, у нас в Linux хватает своих особенностей и векторов атак, что даже 100% исполнение того же CIS DIL ничего не даст — скорее всего, система уже будет ему соответствовать в большей степени уже из коробки, ибо в стандарте уж совсем дикие мисконфиги. И вот для детекта атак на Linux снова нужен мониторинг, и снова нужны правила и детекты, которые не всегда бесплатно лежат в паблике, а те что есть, скорее всего, будут фолзить, так как система даёт возможности решать задачу множеством разных способов.
Когда у Астры появится нормальная информация по уязвимостям? Не на NAS'е закрытом паролем, а где-нибудь на сайте в публичном доступе, с версией исправленного пакета во ВСЕХ бюллетенях (в том числе в методических указаниях), а не только в новых. Почему так сложно добавить всю нужную информацию в старые бюллетени, которые сейчас существуют без версии исправленного пакета?
Я конечно понимаю, что Skyrim бесконечная игра, но речь всё же о новых проектах, которым даже 4 гигабайт топовой 980 будет не хватать, например тот же Doom Eternal, который считается, что хорошо оптимизирован, что уж говорить про CP2077.
То что на 1050 Ti играет приличное число людей — не означает, что её хватает, просто демонстрация факта, что даже middle-end видеокарты всё ещё не особо доступны, что уж тут говорить про топовые и предтоповые модели. Если посмотреть статистику Steam, то ещё больше довольствуется встройкой.
Ну а если что-то там спецом не заводится, хотя могло бы — это проблемы не железа.
Нет, это как раз проблемы железа. То, что ушлые маркетологи решили разделить DX12 на "уровни поддержки", как раз демонстрация этих проблем, которые пытаются скрыть. А потом пользователи ложно считают, что их видеокарта что-то там умеет.
Так что обновление раз в 3-5 лет — это вполне реальные сроки жизни игрового ПК, а не "плохие разработчики опять не оптимизировали игру под мой хлам". Если мы, естественно, говорим об актуальных проектах, а не Скайриме и Героях 3. Но для этого и встройки хватит.
Ну про 8-10 лет вы загнули. Просто зайдите на Wiki и посмотрите, что тогда были за процессоры и видеокарты. Как я помню, только начинали появляться "нормальные" Intel Core (Sandy/Ivy Bridge), по видеокартам уже сложнее, но что-то подсказывает, что тогда были GeForce 6-ой и 7-ой серии. Сейчас это всё упрётся как минимум в объём видеопамяти, даже если брать топовые решения, процессор будет просто добавлять какие-то свои проблемы. То есть в среднем это уровень 720p с нестабильным FPS на самых низких настройках. А какие-то игры вообще не запустятся, потому что требуют "полноценного" DX12 (тот же Death Stranding) у видеокарты.
Плюс у каждого свои требования к играм, то что для вас достаточно, чтобы она хоть как-то запустилась, не значит, что остальным это будет допустимо. А кто-то вообще хочет 4к с лучами и максималками.
Карты поколения 10-ой серии (даже топовые) уже плохо справляются с современными требовательными играми. Плюс недавно Nvidia заявила, что их новомодный DLSS 3.0 не будет работать на картах 20-ой и 30-ой серии, так что чисто формально он был прав про 3 года. Конечно к концу поколения (консольного) всё стабилизируется в плане лучей и всяких навороченных методов апскейла, но думаю и там что-нибудь новое придумают.
Даже диски с 5400 RPM достаточно греются, поэтому если вы хотите обеспечить их долгую работу, то нужно хоть какое-то охлаждение. Диски с 7200 RPM же просто быстро умирают без охлаждения, для них оно обязательно. Без охлаждения "нормально" живут разве что 2.5" на 5400 RPM, и то лучше бы они отдавали тепло куда-нибудь на корпус. Ну и производительность у них соответствующая.
Проще вообще не портировать, так как там вся соль в плагинах, которые придётся переписывать с нуля (чем в итоге far2l и занимается). Легче потратить силы на развитие того же Midnight Commander, если уж так нужен двухпанельный файловый менеджер а-ля Norton Commander.
И это прям существенная разница в полтора или два раза, чтобы тратить на это время и силы? Почти всё перешло на 64 бита, но находятся люди, которые выполняют некие шаманские ритуалы, потому что им кажется, что "потребляет меньше". А тебе потом приходится поддерживать 32-битные syscall'ы, потому что это всё выбросить не могут из системы.
Давно пора выбросить сборку 32-битных версий приложений. Надо — собирай сам.
И всё же память реально дешёвая (особенно если не бегать за оверклокерскими вариантами) относительно остальных компонентов.
16 ГБ — это реально современный минимум, чтобы запустить пару небольших виртуалок, рабочие приложения и чтобы ещё браузеру осталось. Но кто-то не согласится и скажет, что вообще 32 ГБ надо. Для определённых видов деятельности вполне возможно.
Я помню старую рекламу Windows 7 от российского офиса (скорее всего этот пост тоже ссылался на неё https://habr.com/ru/post/68418/), где представители MS рассказывали, что 7-ке "гига достаточно", но это всё ложь, ложь и ещё раз ложь. 2 ГБ минимум, чтобы что-то вообще делать, а так 4 ГБ — это обязательный минимум, 8 ГБ для ресурсоёмких приложений. С того времени больше 10 лет прошло, так что 16 ГБ — это оправданный минимальный объём памяти для рабочих задач.
1) Но явно не стоит свеч в плане экономической выгоды. Я тоже занимался подобной фигнёй, но понял, что даже "гипотетические" сотни сохранённых мегабайт не стоят тех трат времени, что на это тратятся. Дешевле докупить памяти. Или вообще сменить устройство. Из всех компаний разве что Apple занимется оптимизацией ПО, лично ощутил на своём iPhone SE. Но в российском ИТ-сообществе принято считать технику оверпрайсом и не покупать её. Зато какой-нибудь ванплас на 100500 ГБ ОЗУ — это нормальное дело. Так что надо определиться, в какую сторону вы воюете. Хотите экономии ресурсов, оптимизации и долгий срок поддержки — придётся заплатить за это. Бесплатно вы не получите ничего.
2) Нет. Windows в плане обратной совместимости — это рандом на рандоме рандомом погоняет. На 10-ке и 11-ой сейчас не запустится приличная часть старого софта, то что ваши 3,5 приложения запустились — просто ошибка выжившего. Лучше тут себя 7-ка чувствует, но есть приложения, которые и на ней не запускаются, в таком случае приходится откатываться на XP или ещё ниже (тут как повезёт). Походите по тому же GoG и почитайте жалобы, что "на 10-ке не работает, или работает криво". То же самое с какими-нибудь визуальными новеллами (особенно времён нулевых). Корпоративный софт вообще отдельная тема, мне хватило плясок с бубном вокруг неподписанного ActiveX.
3) GPU умеет декодировать только определённые профили кодеков. Шаг влево, шаг вправо — и тут он говорит "кря". Про кодирование вообще можно даже не говорить. Именно поэтому нормальные стримеры кодируют на процессоре, иначе на "стандартных" профилях будет каша из пикселей. Ну и да, чтобы поддерживались современные кодеки (в том числе тот же AV1) вам просто придётся купить новое устройство, что опять же перечёркивает некрофилию с устаревшими железками.
И ещё раз. Я прям не вижу засилья ПО на Electron. Только Skype помню и всё. Нативные приложения будут там, где за них платят. в том числе по подписке. Бесплатно вам никто делать не будет.
Тут уже зависит от разработчиков сайта. Некоторые из них (привет, Твиттер) умудряются тормозить даже на десктопе с его-то мощностями, что уж говорить о мобильных устройствах.
Ещё раз. От битности не зависит объём памяти выделяемой под структуры данных. Только от разработчика. Он может установить некий лимит их размера, и тогда они в обоих случаях будут занимать один объём памяти, но у нас будут жёсткие ограничения в ПО по каким-то возможностям. Либо он не делает так, тогда объём открываемых данных зависит от имеющихся ресурсов. Тут уже на нём лежит обработка ситуаций, когда их не будет хватать, и что ПО будет делать в таких случаях.
Наоборот. Как мы видим у Apple всё хорошо с обратной совместимостью, они два раза делали транслятор/эмулятор кода при переезде на другую архитектуру. И что-то я не слышу сожалений об "утраченном ПО эпохи PowerPC". Как раз отказ от 32-битных приложений дал пинка разработчикам, чтобы они обновили приложения. А Microsoft так и не достиг успехов в плане своей ARM64-версии Windows. Что более иронично, она лучше всего работает через Parallels на компьютерах Mac с Apple Silicon.
И да, покупка нового устройства — это самый логичный шаг. И суть даже не в том, что память не расширить. Сам процессор уже не справляется. В том числе из-за ограничений шин данных до других компонентов. Сложно требовать от какого-нибудь Core 2 Duo качественного воспроизведения 1080p, ибо очень он стар, да и из архитектур и чипсетов там тоже тот ещё бардак. Срок жизни устройства — 5 лет, в крайних случаях 7, этого вполне достаточно. Технологии всё же развиваются.
Это сейчас на складах может быть запас уже произведённого оборудования или компонентов. Интереснее посмотреть ситуацию через год-два, когда они будут истощены большим спросом, чтобы заменить импортное оборудование.
Нет. Это так не работает. Память не жрёт тот софт, что спроектирован в определённые лимиты. И он одинаково не будет жрать ресурсы как в 32-битном виде, так и в 64-битном, разве что 64-битные регистры могут помочь ему в улучшении быстродействия (больше данных обрабатываем — быстрее завершаем работу и высвобождаем память). В реальности 32-битный браузер просто будет чаще падать, если будет открыто много вкладок, а техподдержка будет отвечать, что "ставьте 64-битную версию". Скорее всего 32-битная версия проходит только автоматические тесты и редко используется пользователями, значит её проблемы будут реже решать. Так что никакого преимущества нет.
Популярные дистрибутивы Linux всё ещё тащят за собой 32-битные библиотеки, в итоге только путаница происходит из-за всего этого. За столько лет можно было всё пересобрать. Так что та же Apple всё правильно сделала, выкинув 32-бита. На примере Linux видно, к чему приводит обратное.
Память дешёвая. 16 ГБ — это современный минимум. Пора перестать мучить устройства с <4 ГБ. Их уже ничего не спасёт.
Для мобильных уже есть PWA, но популярностью не пользуется, в том числе с подачи Apple и Google. Мобильникам меньше всего надо беспокоиться об отсутствии нативных приложений. Вот у десктопов всё плохо. Если macOS ещё может выиграть за счёт единого SDK и получать нативные приложения, то на ту же Windows забили. Linux тут в двойственном положении — с одной стороны есть независимые разработчики, которые пытаются писать свою реализацию, с другой владельцы сервисов в этой ОС ещё меньше заинтересованы. В целом, я пока только Skype видел, как пример очень плохого Electron приложения.
У меня был опыт с 32-битным браузером в 64-битной системе. В результате он регулярно падал. Да, открыто 100500 вкладок, но это не особо помогло ему экономить память системы. В 32-битной системе мало что изменится, разве что swap будет насиловаться чаще.
Если уж так надо, чтобы приложение не потребляло больше N ГБ, то его надо проектировать исходя из этого. В том числе задавать жёсткие ограничения на объём входных данных. Но никто этого не будет делать, так как память дешёвая, а ухудшать пользовательский опыт — очень плохо.
То что достаточно, не означает, что надо упарываться этим. Поддержка 32-bit-only окружения просто добавит лишней работы. Даст это какие-то плюсы в экономии ресурсов на устройстве? Сомнительно. Да, знаю, что некоторые специально ставили 32-битные ОС на устройства, которые в целом и 64-бит поддерживают, объясняя это фразой "так меньше будет ресурсов жрать". Какой-то технической базы под эти ритуалы предоставить не смогли. И да, мы сейчас не про совсем микро-микроконтроллеры говорим для тех же SIM-карт и прочего. Там уже давно всё написано, да и у ребят свой путь. В остальных системах (в том числе встраиваемых) не вижу смысла в 32-бит, просто очередной повод придумать себе проблему, которую потом будут героически решать.
Если говорить о более приземлённых вещах, тех же Atom'ах, которые тут вспоминали, то им давно пора на помойку. Неудачная попытка Intel вкатиться в мобильные устройства. Сейчас есть ARM64-процессоры, которые лучше во всём. Если же надо что-то на x86, то у Intel и AMD есть целые линейки процессоров с низким потреблением. А стюардессу пора закопать.
Фундаментальной науки вполне достаточно для создания прикладных производств.
Нет. И это не зависит от "советских" или "не советских" учёных/специалистов. Одно дело в лабораторных условиях собрать несколько экземпляров, совершенно другое — наладить массовое производство с минимальным числом брака. С последним СССР так и не справился. Даже сейчас с вроде как "доступными" технологиями эффективно могут использовать их единичные компании. Хотя все принципы расписаны в научных статьях, патентах, etc. Не просто так передовые техпроцессы есть у двух-трёх компаний в мире. Следует подумать почему так.
Как раз в ней и проблема. Делать 100500 верий под разные API или его ревизии никто не будет. Особенно на общем тренде отказа от десктопов. Тот же SDK Apple позволяет быстро сделать версию для нескольких платформ, а теперь уже даже запустить нативную версию с iOS на macOS, поэтому на ней реже встречаются приложения на базе Electron. В основном страдают от этого подхода Windows и Linux. Первый, потому что у пользователей зоопарк версий ОС на устройствах, второй — потому что нет единого графического API. А так, в целом, софт очень даже оптимизируется. Firefox перестал адски жрать память после внедрения компонентов на Rust, да и Chrome'у тоже порезали аппетиты по ресурсам. Чудес, естественно, не будет, чтобы это работало на 2-4ГБ ОЗУ, да и не нужно, когда она достаточно дешёвая. Про 32-бита вообще пора бы забыть окончательно.
Ну и ещё один фактор — финансовый. Тот же Telegram старается, чтобы были нативные приложения, под какие-то платформы даже есть выбор из двух. Но что-то никто не побежал массово оплачивать премиум, чтобы отблагодарить разработчиков. Все хотят всё бесплатно, да ещё и чтобы под их хлам десятилетней давности что-то оптимизировали. Может пора начать платить за софт? Или обновить железо хотя бы?
Так что проблема "раздутости ПО" раздута. Да, есть такие приложения, но прям массовой проблемы нет. Софт сейчас вполне себе оптимизирован, особенно платный.
А есть ли "раздувание кода"? Конкретные проблемы, описанные в статье, касаются Windows, которой приходится тащить за собой кучу костылей. Другие системы (macOS/Linux) просто выбросили всё наследие ценой совместимости со старым ПО.
Если же смотреть реально, то мы ушли от якобы "оптимизированных" утилит, которые работали только на одной ОС с однобайтовой кодировкой, да ещё и с ограничением по объёму данных — тот же Outlook когда-то имел ограничение в 2ГБ для PST-файлов, потом оно выросло до 20ГБ, но кто-то всё равно упирался в это ограничение.
Так что объёмы данных растут. Увеличивается и размер самих файлов, так как они хранят больше информации, чтобы отображать содержимое качественно на современных средствах вывода. И не важно что это — текст, изображения, видео, аудио, etc.
Современные ресурсы позволяют получать приложения быстрее, а не ждать их годами. Тот core-функционал, что годами прорабатывали в старых приложениях, теперь обязателен в MVP, на который есть значительно меньше времени. Теперь не надо десятилетиями ждать версии для Linux или macOS, тот же FAR Manager сейчас всё ещё портируют под Linux, вот только кому он теперь нужен? Надо было вместе с версией для Windows выпускать.
А качество кода растёт. Я сейчас смотрю на внутренности старого продукта (который меньше ресурсов требует) и ужасаюсь. Новый требует на порядок больше ресурсов, но его возможности на голову выше, чем у старого, да и кодовая база там теперь приведена в порядок. За счёт этого продукт удалось за два года перевести на Linux (требование настоящего времени), а со старым такое не получится.
Оптимизация всегда имеет свою цену в виде зависимости от архитектуры процессора, версии ОС, библиотек, etc. Но самое главное — ограничения в расширениии функционала. Можете посмотреть на nginx и попытки реализации QUIC в нём. Продукт отличный, но рынок требует новых возможностей, в том числе для оптимизации объёмов трафика.
И как вы себе это представляете? Легитимные на то и легитимные, так как используются другим ПО для работы на конкретной системе. Мне легче рассуждать про тот же Linux, и там есть куча зависимостей, запуск того же bash и других командных интерпретаторов, python, возможно где-то даже perl остался. И вот теперь прикол — разрешая те же bash/python/perl вы по сути разрешаете запуск любого кода, так как не существует механизмов, позволяющих корректно это контролировать. Выстрелить себе в ногу тут очень просто. Фильтрация аргументов — это задача ещё сложнее, так как даже у разных версий одной софтины они могут быть разные, это дополнительно осложняется тем, что опции в аргументах могут идти в любом порядке, плюс могут агрегироваться, а также иметь краткую и полную форму. Тут выстрелить себе в ногу ещё проще, чем очень просто. И самое смешное, что это в итоге не поможет, так как существуют пути безфайлового запуска (то есть пути к исполняемому файлу нет, аргументов тоже) или ещё более продвинутые техники по инъекции кода в уже существующий процесс. В общем, вариантов достаточно и это не то чтобы какая-то недоступная массам технология — рабочих экземпляров достаточно лежит в паблике.
Та же упомянутая в статье Evo.industry 2025 указывает, что основная аудитория — это всевозможные директора, которые и сами не знают, как у них всё устроено. Крупные компании используют харденинг, но это не панацея, как уже отметили выше. Есть достаточное количество легитимных и идущих из коробки утилит, которые позволяют обойти ограничения того же SRP или noexec (в случае Linux) и закинуть нужный софт туда, откуда можно. Если уж вспоминать про атаки тех же ransomware-групп, то они первоочередной целью ставят получение доступа к контроллеру домена, а там уже с правами администратора домена их уже сложно будет остановить. Атак на протокол Kerberos в AD существует достаточно, и вот чтобы их вовремя ловить и нужен мониторинг, причём речь не только про сами логи, но и правила детекта этих атак. Но это такой взгляд со стороны линуксоида, которому коллеги-эксперты по Windows показывают атаки на неё. Впрочем, у нас в Linux хватает своих особенностей и векторов атак, что даже 100% исполнение того же CIS DIL ничего не даст — скорее всего, система уже будет ему соответствовать в большей степени уже из коробки, ибо в стандарте уж совсем дикие мисконфиги. И вот для детекта атак на Linux снова нужен мониторинг, и снова нужны правила и детекты, которые не всегда бесплатно лежат в паблике, а те что есть, скорее всего, будут фолзить, так как система даёт возможности решать задачу множеством разных способов.
Когда у Астры появится нормальная информация по уязвимостям? Не на NAS'е закрытом паролем, а где-нибудь на сайте в публичном доступе, с версией исправленного пакета во ВСЕХ бюллетенях (в том числе в методических указаниях), а не только в новых. Почему так сложно добавить всю нужную информацию в старые бюллетени, которые сейчас существуют без версии исправленного пакета?
Я конечно понимаю, что Skyrim бесконечная игра, но речь всё же о новых проектах, которым даже 4 гигабайт топовой 980 будет не хватать, например тот же Doom Eternal, который считается, что хорошо оптимизирован, что уж говорить про CP2077.
То что на 1050 Ti играет приличное число людей — не означает, что её хватает, просто демонстрация факта, что даже middle-end видеокарты всё ещё не особо доступны, что уж тут говорить про топовые и предтоповые модели. Если посмотреть статистику Steam, то ещё больше довольствуется встройкой.
Нет, это как раз проблемы железа. То, что ушлые маркетологи решили разделить DX12 на "уровни поддержки", как раз демонстрация этих проблем, которые пытаются скрыть. А потом пользователи ложно считают, что их видеокарта что-то там умеет.
Так что обновление раз в 3-5 лет — это вполне реальные сроки жизни игрового ПК, а не "плохие разработчики опять не оптимизировали игру под мой хлам". Если мы, естественно, говорим об актуальных проектах, а не Скайриме и Героях 3. Но для этого и встройки хватит.
Ну про 8-10 лет вы загнули. Просто зайдите на Wiki и посмотрите, что тогда были за процессоры и видеокарты. Как я помню, только начинали появляться "нормальные" Intel Core (Sandy/Ivy Bridge), по видеокартам уже сложнее, но что-то подсказывает, что тогда были GeForce 6-ой и 7-ой серии. Сейчас это всё упрётся как минимум в объём видеопамяти, даже если брать топовые решения, процессор будет просто добавлять какие-то свои проблемы. То есть в среднем это уровень 720p с нестабильным FPS на самых низких настройках. А какие-то игры вообще не запустятся, потому что требуют "полноценного" DX12 (тот же Death Stranding) у видеокарты.
Плюс у каждого свои требования к играм, то что для вас достаточно, чтобы она хоть как-то запустилась, не значит, что остальным это будет допустимо. А кто-то вообще хочет 4к с лучами и максималками.
Карты поколения 10-ой серии (даже топовые) уже плохо справляются с современными требовательными играми. Плюс недавно Nvidia заявила, что их новомодный DLSS 3.0 не будет работать на картах 20-ой и 30-ой серии, так что чисто формально он был прав про 3 года. Конечно к концу поколения (консольного) всё стабилизируется в плане лучей и всяких навороченных методов апскейла, но думаю и там что-нибудь новое придумают.
Даже диски с 5400 RPM достаточно греются, поэтому если вы хотите обеспечить их долгую работу, то нужно хоть какое-то охлаждение. Диски с 7200 RPM же просто быстро умирают без охлаждения, для них оно обязательно. Без охлаждения "нормально" живут разве что 2.5" на 5400 RPM, и то лучше бы они отдавали тепло куда-нибудь на корпус. Ну и производительность у них соответствующая.
Проще вообще не портировать, так как там вся соль в плагинах, которые придётся переписывать с нуля (чем в итоге far2l и занимается). Легче потратить силы на развитие того же Midnight Commander, если уж так нужен двухпанельный файловый менеджер а-ля Norton Commander.
И это прям существенная разница в полтора или два раза, чтобы тратить на это время и силы? Почти всё перешло на 64 бита, но находятся люди, которые выполняют некие шаманские ритуалы, потому что им кажется, что "потребляет меньше". А тебе потом приходится поддерживать 32-битные syscall'ы, потому что это всё выбросить не могут из системы.
Давно пора выбросить сборку 32-битных версий приложений. Надо — собирай сам.
И всё же память реально дешёвая (особенно если не бегать за оверклокерскими вариантами) относительно остальных компонентов.
16 ГБ — это реально современный минимум, чтобы запустить пару небольших виртуалок, рабочие приложения и чтобы ещё браузеру осталось. Но кто-то не согласится и скажет, что вообще 32 ГБ надо. Для определённых видов деятельности вполне возможно.
Я помню старую рекламу Windows 7 от российского офиса (скорее всего этот пост тоже ссылался на неё https://habr.com/ru/post/68418/), где представители MS рассказывали, что 7-ке "гига достаточно", но это всё ложь, ложь и ещё раз ложь. 2 ГБ минимум, чтобы что-то вообще делать, а так 4 ГБ — это обязательный минимум, 8 ГБ для ресурсоёмких приложений. С того времени больше 10 лет прошло, так что 16 ГБ — это оправданный минимальный объём памяти для рабочих задач.
1) Но явно не стоит свеч в плане экономической выгоды. Я тоже занимался подобной фигнёй, но понял, что даже "гипотетические" сотни сохранённых мегабайт не стоят тех трат времени, что на это тратятся. Дешевле докупить памяти. Или вообще сменить устройство. Из всех компаний разве что Apple занимется оптимизацией ПО, лично ощутил на своём iPhone SE. Но в российском ИТ-сообществе принято считать технику оверпрайсом и не покупать её. Зато какой-нибудь ванплас на 100500 ГБ ОЗУ — это нормальное дело. Так что надо определиться, в какую сторону вы воюете. Хотите экономии ресурсов, оптимизации и долгий срок поддержки — придётся заплатить за это. Бесплатно вы не получите ничего.
2) Нет. Windows в плане обратной совместимости — это рандом на рандоме рандомом погоняет. На 10-ке и 11-ой сейчас не запустится приличная часть старого софта, то что ваши 3,5 приложения запустились — просто ошибка выжившего. Лучше тут себя 7-ка чувствует, но есть приложения, которые и на ней не запускаются, в таком случае приходится откатываться на XP или ещё ниже (тут как повезёт). Походите по тому же GoG и почитайте жалобы, что "на 10-ке не работает, или работает криво". То же самое с какими-нибудь визуальными новеллами (особенно времён нулевых). Корпоративный софт вообще отдельная тема, мне хватило плясок с бубном вокруг неподписанного ActiveX.
3) GPU умеет декодировать только определённые профили кодеков. Шаг влево, шаг вправо — и тут он говорит "кря". Про кодирование вообще можно даже не говорить. Именно поэтому нормальные стримеры кодируют на процессоре, иначе на "стандартных" профилях будет каша из пикселей. Ну и да, чтобы поддерживались современные кодеки (в том числе тот же AV1) вам просто придётся купить новое устройство, что опять же перечёркивает некрофилию с устаревшими железками.
И ещё раз. Я прям не вижу засилья ПО на Electron. Только Skype помню и всё. Нативные приложения будут там, где за них платят. в том числе по подписке. Бесплатно вам никто делать не будет.
Тут уже зависит от разработчиков сайта. Некоторые из них (привет, Твиттер) умудряются тормозить даже на десктопе с его-то мощностями, что уж говорить о мобильных устройствах.
Ещё раз. От битности не зависит объём памяти выделяемой под структуры данных. Только от разработчика. Он может установить некий лимит их размера, и тогда они в обоих случаях будут занимать один объём памяти, но у нас будут жёсткие ограничения в ПО по каким-то возможностям. Либо он не делает так, тогда объём открываемых данных зависит от имеющихся ресурсов. Тут уже на нём лежит обработка ситуаций, когда их не будет хватать, и что ПО будет делать в таких случаях.
Наоборот. Как мы видим у Apple всё хорошо с обратной совместимостью, они два раза делали транслятор/эмулятор кода при переезде на другую архитектуру. И что-то я не слышу сожалений об "утраченном ПО эпохи PowerPC". Как раз отказ от 32-битных приложений дал пинка разработчикам, чтобы они обновили приложения. А Microsoft так и не достиг успехов в плане своей ARM64-версии Windows. Что более иронично, она лучше всего работает через Parallels на компьютерах Mac с Apple Silicon.
И да, покупка нового устройства — это самый логичный шаг. И суть даже не в том, что память не расширить. Сам процессор уже не справляется. В том числе из-за ограничений шин данных до других компонентов. Сложно требовать от какого-нибудь Core 2 Duo качественного воспроизведения 1080p, ибо очень он стар, да и из архитектур и чипсетов там тоже тот ещё бардак. Срок жизни устройства — 5 лет, в крайних случаях 7, этого вполне достаточно. Технологии всё же развиваются.
Это сейчас на складах может быть запас уже произведённого оборудования или компонентов. Интереснее посмотреть ситуацию через год-два, когда они будут истощены большим спросом, чтобы заменить импортное оборудование.
Нет. Это так не работает. Память не жрёт тот софт, что спроектирован в определённые лимиты. И он одинаково не будет жрать ресурсы как в 32-битном виде, так и в 64-битном, разве что 64-битные регистры могут помочь ему в улучшении быстродействия (больше данных обрабатываем — быстрее завершаем работу и высвобождаем память). В реальности 32-битный браузер просто будет чаще падать, если будет открыто много вкладок, а техподдержка будет отвечать, что "ставьте 64-битную версию". Скорее всего 32-битная версия проходит только автоматические тесты и редко используется пользователями, значит её проблемы будут реже решать. Так что никакого преимущества нет.
Популярные дистрибутивы Linux всё ещё тащят за собой 32-битные библиотеки, в итоге только путаница происходит из-за всего этого. За столько лет можно было всё пересобрать. Так что та же Apple всё правильно сделала, выкинув 32-бита. На примере Linux видно, к чему приводит обратное.
Память дешёвая. 16 ГБ — это современный минимум. Пора перестать мучить устройства с <4 ГБ. Их уже ничего не спасёт.
Для мобильных уже есть PWA, но популярностью не пользуется, в том числе с подачи Apple и Google. Мобильникам меньше всего надо беспокоиться об отсутствии нативных приложений. Вот у десктопов всё плохо. Если macOS ещё может выиграть за счёт единого SDK и получать нативные приложения, то на ту же Windows забили. Linux тут в двойственном положении — с одной стороны есть независимые разработчики, которые пытаются писать свою реализацию, с другой владельцы сервисов в этой ОС ещё меньше заинтересованы. В целом, я пока только Skype видел, как пример очень плохого Electron приложения.
У меня был опыт с 32-битным браузером в 64-битной системе. В результате он регулярно падал. Да, открыто 100500 вкладок, но это не особо помогло ему экономить память системы. В 32-битной системе мало что изменится, разве что swap будет насиловаться чаще.
Если уж так надо, чтобы приложение не потребляло больше N ГБ, то его надо проектировать исходя из этого. В том числе задавать жёсткие ограничения на объём входных данных. Но никто этого не будет делать, так как память дешёвая, а ухудшать пользовательский опыт — очень плохо.
То что достаточно, не означает, что надо упарываться этим. Поддержка 32-bit-only окружения просто добавит лишней работы. Даст это какие-то плюсы в экономии ресурсов на устройстве? Сомнительно. Да, знаю, что некоторые специально ставили 32-битные ОС на устройства, которые в целом и 64-бит поддерживают, объясняя это фразой "так меньше будет ресурсов жрать". Какой-то технической базы под эти ритуалы предоставить не смогли. И да, мы сейчас не про совсем микро-микроконтроллеры говорим для тех же SIM-карт и прочего. Там уже давно всё написано, да и у ребят свой путь. В остальных системах (в том числе встраиваемых) не вижу смысла в 32-бит, просто очередной повод придумать себе проблему, которую потом будут героически решать.
Если говорить о более приземлённых вещах, тех же Atom'ах, которые тут вспоминали, то им давно пора на помойку. Неудачная попытка Intel вкатиться в мобильные устройства. Сейчас есть ARM64-процессоры, которые лучше во всём. Если же надо что-то на x86, то у Intel и AMD есть целые линейки процессоров с низким потреблением. А стюардессу пора закопать.
Нет. И это не зависит от "советских" или "не советских" учёных/специалистов. Одно дело в лабораторных условиях собрать несколько экземпляров, совершенно другое — наладить массовое производство с минимальным числом брака. С последним СССР так и не справился. Даже сейчас с вроде как "доступными" технологиями эффективно могут использовать их единичные компании. Хотя все принципы расписаны в научных статьях, патентах, etc. Не просто так передовые техпроцессы есть у двух-трёх компаний в мире. Следует подумать почему так.
Как раз в ней и проблема. Делать 100500 верий под разные API или его ревизии никто не будет. Особенно на общем тренде отказа от десктопов. Тот же SDK Apple позволяет быстро сделать версию для нескольких платформ, а теперь уже даже запустить нативную версию с iOS на macOS, поэтому на ней реже встречаются приложения на базе Electron. В основном страдают от этого подхода Windows и Linux. Первый, потому что у пользователей зоопарк версий ОС на устройствах, второй — потому что нет единого графического API. А так, в целом, софт очень даже оптимизируется. Firefox перестал адски жрать память после внедрения компонентов на Rust, да и Chrome'у тоже порезали аппетиты по ресурсам. Чудес, естественно, не будет, чтобы это работало на 2-4ГБ ОЗУ, да и не нужно, когда она достаточно дешёвая. Про 32-бита вообще пора бы забыть окончательно.
Ну и ещё один фактор — финансовый. Тот же Telegram старается, чтобы были нативные приложения, под какие-то платформы даже есть выбор из двух. Но что-то никто не побежал массово оплачивать премиум, чтобы отблагодарить разработчиков. Все хотят всё бесплатно, да ещё и чтобы под их хлам десятилетней давности что-то оптимизировали. Может пора начать платить за софт? Или обновить железо хотя бы?
Так что проблема "раздутости ПО" раздута. Да, есть такие приложения, но прям массовой проблемы нет. Софт сейчас вполне себе оптимизирован, особенно платный.
А есть ли "раздувание кода"? Конкретные проблемы, описанные в статье, касаются Windows, которой приходится тащить за собой кучу костылей. Другие системы (macOS/Linux) просто выбросили всё наследие ценой совместимости со старым ПО.
Если же смотреть реально, то мы ушли от якобы "оптимизированных" утилит, которые работали только на одной ОС с однобайтовой кодировкой, да ещё и с ограничением по объёму данных — тот же Outlook когда-то имел ограничение в 2ГБ для PST-файлов, потом оно выросло до 20ГБ, но кто-то всё равно упирался в это ограничение.
Так что объёмы данных растут. Увеличивается и размер самих файлов, так как они хранят больше информации, чтобы отображать содержимое качественно на современных средствах вывода. И не важно что это — текст, изображения, видео, аудио, etc.
Современные ресурсы позволяют получать приложения быстрее, а не ждать их годами. Тот core-функционал, что годами прорабатывали в старых приложениях, теперь обязателен в MVP, на который есть значительно меньше времени. Теперь не надо десятилетиями ждать версии для Linux или macOS, тот же FAR Manager сейчас всё ещё портируют под Linux, вот только кому он теперь нужен? Надо было вместе с версией для Windows выпускать.
А качество кода растёт. Я сейчас смотрю на внутренности старого продукта (который меньше ресурсов требует) и ужасаюсь. Новый требует на порядок больше ресурсов, но его возможности на голову выше, чем у старого, да и кодовая база там теперь приведена в порядок. За счёт этого продукт удалось за два года перевести на Linux (требование настоящего времени), а со старым такое не получится.
Оптимизация всегда имеет свою цену в виде зависимости от архитектуры процессора, версии ОС, библиотек, etc. Но самое главное — ограничения в расширениии функционала. Можете посмотреть на nginx и попытки реализации QUIC в нём. Продукт отличный, но рынок требует новых возможностей, в том числе для оптимизации объёмов трафика.