Комментарии 63
Довольно печально, что такие оптимизации делаются "из-за кризиса памяти", а не ради просто улучшения/оптимизации работы приложения
Памяти сейчас достаточно для пары тройки приложений на Electron, больше обычно никто не запускает.
Ну вот всем достаточно (якобы), а ведь дело не в том, сколько приложений можно запустить, а в том, сколько ресурсов они жрут для выполнения элементарных задач. Десятилетиями неэффективный код компенсировали наращиванием железа. Только закон Мура не гарантирует бесконечного роста, а физические пределы никто никогда не отменял. В итоге вместо оптимизации научились просто просить... Нет, - требовать больше памяти
За оптимизацию мало платят, да и акциями софтверных и хардверных компаний владеют одни и те же фонды: оптимизация будет снижать доходы производителей памяти, процессоров и тд
Лично мне 8 GB на планшете / смартфоне и 16 GB на компьютере достаточно для использования, даже с Electron приложениями. Было больно когда памяти было 4/8 GB.
Вряд-ли сейчас вернёмся к тем временам даже с дефицитом памяти.
Вряд ли сейчас вернёмся к тем временам даже с дефицитом памяти.
А как насчёт дефицита денег?
Вы опять путаете достаточность ресурсов с эффективностью их использования. То, что вам сегодня хватает 16 ГБ не означает, что завтра их будет достаточно. При таком подходе разработчиков растут не только возможности приложений, но и их аппетиты к ресурсам, зачастую без соразмерного увеличения функциональности. Любую неэффективность можно оправдать наличием свободной памяти, пока однажды она не закончится. И вместо того чтобы писать нормальный код, снова предложат обмазаться железом. И про закон Мура, видимо, стоит пояснить. Он описывает историческую тенденцию роста числа транзисторов на микросхемах, и не гарантирует бесконечный рост производительности и доступных ресурсов. У полупроводниковых технологий есть физические и экономические ограничения. Десятилетиями рост возможностей железа позволял маскировать неэффективность софта, это просто факт. Только вот рассчитывать, что процессоры и память будут бесконечно компенсировать глупые инженерные решения, - довольно сомнительная стратегия. И мы сейчас как раз находимся в том самом времени, когда закон Мура начинает выстреливать
Тут скорее наложился и кризис, и доступность ЛЛМ - стало проще делать нативные интерфейсы, да и код писать. Хорошо, что дошли хотя бы до этого, а многие компании клали с препаратом на оптимизации.
Ну и хорошо, наконец-то настал момент когда не только фичи будут пилится, а ещё и задачи со стороны бизнеса об оптимизации. От этого будет хорошо всем.
я думаю в этой истории замешана доступность и уровень текущих ии.
это да, я вот себе на андроид сделал несколько приложений
приложение с таймерами и уведомлениями и редактированием таймеров (чего нет в базовых часах на андроиде) и оно весит 30кб (апк)
приложение для тахографа, что бы учитывать много таймеров одновременно при этом они переключаются по gps и там даже умные расчёты по потере сигнала в тунелях, с журналами, графиками и тд. и оно весит всего 3мб (апк)
а почему обычные часы с будильником у меня весят как...
часы
1 приложение, апк 29кб
2 приложение, апк 3.3мб
p.s. и да всё это написано нейронкой, правильно работает в фоне, даже если закрыть приложение всё учитывается, и ещё к тому же собиралось на самом телефоне в термукс->proot+debian->codex
p.s.s. просто представьте, если бы всё ПО было бы написано оптимизированно и не занимало бы море памяти и ресурсов пк, на текущем железе.. "640 килобайт хватит всем!"
Чертовски напрягает что весь или почти весь код будет написан ИИ. Поверхность атаки безумная, особенно с WebView, проверять будут только типичные баги. С электроном было ещё хуже, но...
занимает всего 290 МБ
И судя по этой “оптимизации” весь код писал ИИ
Найдутся токены на написание, найдутся и на проверку уязвимостей.
Поверхность атаки безумная
вы думаете что до этого было лучше?
Поверхность атаки безумная
Я не думаю, что в этом плане в настоящее время ИИ сделает хуже, чем те, кто написали это приложение. Уже то, сколько приложение жрет ОЗУ (и не только его) говорит о том, как там относятся к эффективному кодингу и оптимизациям
Так и люди писали с дикими уязвимостями, просто не было фонарика хорошего подсветить. Лишь за недавнее время LLM открыли миру PHP2Shell (CVE-2026-109618) и удивительную sshhole (CVE-2026-123158). Все эти уязвимости написаны людьми
Покажите реально рабочий пример использования данных уязвимостей? Чтобы вариант был также универсальнум.
Пока не разу не смог найти такой реализации....
А с чего Вы решили, что эксплуатация уязвимости обязана быть универсальной? CVE описывает конкретную ошибку и условия её эксплуатации, а не какой-то гарантированный способ взломать любую систему. Для sshhole уже есть публичные reproducer'ы, а PHP2Shell вообще эксплуатируется в реальных атаках. Вы не смогли найти рабочий пример или даже разобраться в условиях эксплуатации, но на этом основании решили поставить под сомнение сами уязвимости? С таким подходом может ещё и переполнение буфера будете отрицать, если эксплойт не сработал на вашем компьютере?)
Вторая вроде как эксплуатируется как нефиг делать, 257 букв "A" в качестве пароля и ты вошёл в систему. Главное - найти уязвимый сервер и угадать логин.
А ты вот на ИИ ну ничего никогда не писал.
Тенденция радует, web технологии чаще всего использовали, чтобы быстро сделать приложение сразу под все платформы. Если ИИ позволит использовать нативные технологии платформ, без особого снижения скорости, увеличения затрат на разработку, то это большой плюс для конечного пользователя продуктов, т.к. нативные приложения обычно ощущаются куда качественее и приятнее в использовании.
И жрут не 500 мб чисто для UI, а 10-20
т.к. нативные приложения обычно ощущаются куда качественее и приятнее в использовании.
Они будут переписывать его на GPUI — это фреймворк, который рендерит собственные виджеты через GPU. Нативные виджеты не используются.
Так еще, чего доброго, снова начнут использовать JavaScript только для написания интерактивных веб-страниц, а не для создания бизнес-логики платежных систем
Давно пора. Сейчас дискорд держит вечно занятыми 400Мб видеопамяти. Мне приходится его выключать, чтобы запускать LLMки. И я так понимаю, у тех игрунов, у которых 8Гб видеопамяти, (которых хватит всем) он так же резервирует 400 Мб?
Интересно было бы узнать, что стало решающим фактором. Переписать все клиентские приложения задача масштабная. Что не так с текущей архитектурой? Тяжело поддерживать? Как-то не верится, что это только ради экономии ОЗУ.
Сбор данных вероятно. Discord же вроде бы использует следилки. Если будет жрать меньше памяти , пользователя будет меньшего мотивация его вырубать. У меня например он где-то 500-600 МБ ест
У них сколько лет была утечка памяти в клиенте, которая через какое-то время начинала жрать больше 4Гб озу. Как они это решили? Да никак, добавили скрипт который принудительно перезагружает приложение. Discord настолько разросся по функционалу, что поддерживать этот зоопарк на электроне стало невозможно.
Получается C++ в нулевых все-же был лучше по оптимизации, чем современный Rust: мессенджеры тогда весили на порядок меньше
Что касается переписывания, правильно было переписать БЛ (коннект, запросы, работу с контактами и всё почее) на Rust. А вот переписать сам UI на GPUI… Ну, флаг им в руки.
Типичный мессенджер из нулевых
Это только кажется, что тут градиенты, а на самом деле — owner draw + блиттинг. Причём, насколько я помню, даже без альфа-канала. Альфа-канал в битмапках винда стала поддерживать довольно поздно.
Нагрузка при этом никакая, но то же масштабирование уже не сделать. Не говоря про прочие перечисленные вещи типа медиаэлементов.
Только текст и малюсенькие аватарки и смайлики. Ни фоток по 10 Mb каждая, ни видосов.
Получается C++ в нулевых все-же был лучше по оптимизации, чем современный Rust.
Очевидно, дело было не в бобине (с)
А видеозвонки в тех мессенджерах были? Поделиться экраном было можно? И как там с адаптивностью интерфейса?
всего 290 МБ
У меня GUI агентная обвязка со всеми фичами, с сотней параллельно работающих агентов, потребляет 70 МБ (с одним агентом 40 МБ).
Из-за блокировок со стороны РКН попробовал нативный клиент для mamble. Он сожрал целых 23 Мб!
В итоге не стал искать костыли для запуска дискорда, остались на self-hosted мамбле. Поставил сторонний сервер, тоже очень легкий. Может работать на роутере под OpenWRT.
Текущий переход на Rust могу только приветствовать, но вот использование GPUI жрет видеопамять, что не приемлемо для игроков. КМК идеально было бы все же использовать по настоящему нативные решения, типа WinAPI и т.п.
эх, капец моему Vencord клиенту с его 20+ шикарными плагинами :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Discord отказывается от Electron и переписывает клиенты на Rust