LinuxMint.com.ru

Chocobo писал(а): ↑

16 июн 2018, 20:28

Так это ж нормальная практика вроде

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

А так ПО на всяких электронах больше напоминает натягивание скинов на движок, чем на привычное программирование.

Тот же скайп до покупки микрософтом использовал библиотеки Qt, и это ок, сейчас насколько я знаю, это б***ь полноценный браузер, на который натянули скин. Весит много? Жрет много? Ну и пофиг, не можешь запустить пяток приложений каждое из который содержит по яваскрипт машине и хтмл/хмл/добавитьещедесятокаббревиатуритехнологий приложений - иди покупай планки памяти нищеброд

(тут могло быть еще упоминание революционной технологии пакетов flatpack, которая революционно запакована со всеми зависимостями. скажем да сотне версий одной и той же библиотеки )

Всем спасибо, я кончил.

zuzabrik писал(а): ↑

16 июн 2018, 20:03

Возможно стоит подумать о 8гб ОЗУ и более,

так и сделал вынул из компа жены 4 г и вставил себе... Теперь хорошо....

Ким чен ин писал(а): ↑

16 июн 2018, 21:36

вынул из компа жены 4 г и вставил себе... Теперь хорошо...

не забывай что месть, это блюдо которое подают холодным, и спи с открытыми глазами

А еще помогает антискрипт.

Dja писал(а): ↑

17 июн 2018, 14:11

А еще помогает антискрипт.

Если ты про блокировку JavaScript в браузере, то это отличный совет для человека который

Ким чен ин писал(а): ↑

15 июн 2018, 20:47

Мне по роду деятельности как раз нужно такое приложение которое содержит большой объем js данных.

Никто не мешает включать именно те, которые нужны.

zuzabrik писал(а): ↑

16 июн 2018, 21:18

тут могло быть еще упоминание революционной технологии пакетов flatpack

А уж они то чем-то тебе жить мешают? Дублирование либ не особо коррелирует с прожорливостью, запущенный процесс будет жрать столько же, сколько и дебка.

zuzabrik писал(а): ↑

16 июн 2018, 21:14

Это нормально для игр ААА класса, но для ПО - не думаю. Увы, но пока ПО будут (и ведь сука будут) делать поверх другого ПО

Приклад - прикладу рознь. Я в чем то с тобой согласен, что аппликухи вроде скайпа не должны бы отжирать по 2-3гб озу в своем функционале. Но есть и обратная тенденция, такая как "среда позоволяющая рисовать GUI не должна жрать больше чем сама программа с GUI"

Chocobo писал(а): ↑

17 июн 2018, 17:16

Дублирование либ не особо коррелирует с прожорливостью, запущенный процесс будет жрать столько же, сколько и дебка.

А вот тут ты немного не прав... Если либа дублируется - она именно что будет жрать больше. Не всегда правда, а тогда когда эту же библиотеку должна использовать еще какая-то программа. При нормальной работе линковка динамическая - одна либа может быть использована кучей программ, а в памяти она будет в единственном экземпляре. В случае flatpack или статической линковки - не так. С каждой программой загружается собственная копия нужных либ. Памяти на это надо побольше... Разумеется - с точки зрения общей занятой памяти.

slant, Да, разумеется все так. Но на практике оно в частном случае не должно вылиться в лишнюю сотню метров потребления, и при статической линковке. Ну или нужно явно N-ное количество одновременных изолированных процессов программы с раздельными копиями библиотек. Ну и это же является платой за отсутсвие dependency hell

Плюс флэтпак, насколько я помню, еще и формирует свой рантайм из компонентов (отдельно от хост системы), которые могут использоваться разными процессами, что также должно несколько снизить этот аспект потребления в сценарии с преобладанием рабочих flatpak-контейнеров.

Ну а appimage запросто использует библиотеки хост-системы если они не были явно включены в пакет

Ну вот блин, прошло 3 месяца, теперь FF пожирает всю добавленную память. Вот что делать? Еще добавлять?