Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
>> Вспомните Windows 98
Вспомните NT4.0 годы теже а стабильность крайне разная.
>> Windows 10 требует и в принципе хорошо работает на 1 гигабайте памяти (версия 32 бита). Умещается на 16 гигабайтном разделе. Это очень здорово.
XP у меня умещалась на на 4Gb разделе(когда то ставил на CF карту), и там ещё оставалось место как бы не два гига, оперативки можно было даже 512 дать. У меня лично есть пример работы XP в течении 3 лет без перезагрузок, и ещё и симпатишно выглядела.
И что поменялось Win 10 сколько она после установки занимает? Я предполагаю что минимум 5 гигов, памяти её надо минимум гиг, выглядит ну скажем на любителя. Со стабильностью всё упирается в дрова которые таки да научились писать под NT ядро за всё время которое прошло с выхода XP.
Скажем так с арены ушли жирные проги, зачастую не потому что они жирные, а потому что стали не нужны. NERO ну а кому сейчас нужно писать диски(я понимаю что такие есть но далеко не как раньше)? ACDSee, плееры ушли в веб, и теперь там жрут с удовольствием память и проц не хуже чем раньше. Skype тоже шустрей не стал.
Вспомните NT4.0 годы теже а стабильность крайне разная.
>> Windows 10 требует и в принципе хорошо работает на 1 гигабайте памяти (версия 32 бита). Умещается на 16 гигабайтном разделе. Это очень здорово.
XP у меня умещалась на на 4Gb разделе(когда то ставил на CF карту), и там ещё оставалось место как бы не два гига, оперативки можно было даже 512 дать. У меня лично есть пример работы XP в течении 3 лет без перезагрузок, и ещё и симпатишно выглядела.
И что поменялось Win 10 сколько она после установки занимает? Я предполагаю что минимум 5 гигов, памяти её надо минимум гиг, выглядит ну скажем на любителя. Со стабильностью всё упирается в дрова которые таки да научились писать под NT ядро за всё время которое прошло с выхода XP.
Скажем так с арены ушли жирные проги, зачастую не потому что они жирные, а потому что стали не нужны. NERO ну а кому сейчас нужно писать диски(я понимаю что такие есть но далеко не как раньше)? ACDSee, плееры ушли в веб, и теперь там жрут с удовольствием память и проц не хуже чем раньше. Skype тоже шустрей не стал.
NERO ну а кому сейчас нужно писать диски
Зэкам флешки нельзя, смотрят с дисков:)
Только что ставил на EeePC 701. 4Gb — SSD. 0.98Gb — голая винда без драйверов. 2.7Gb — свободно.
Не понимаю, куда оно память девает… На 4 мегабайтах отлично работала 3.11 (минимум 2), а 95 со скрипом, но тоже ворочалась (это ее минимум). 64 мегабайта вполне хватало Windows 2000 (минимум 32). Windows XP на 256 работает нормально, на 512 так вообще "ни в чем себе не отказывай" (заявленный минимум 64).
И вот какого же… гуглохром вот прямо сейчас жрет 960 мегабайт из 32 гигабайт? Мне не жалко, но не так давно столько памяти могло вообще не быть в системе, сколько нужно "легкому и быстрому" браузеру для показа пяти табов...
И вот какого же… гуглохром вот прямо сейчас жрет 960 мегабайт из 32 гигабайт? Мне не жалко, но не так давно столько памяти могло вообще не быть в системе, сколько нужно "легкому и быстрому" браузеру для показа пяти табов...
Я прекрасно помню, как на Pentium 133 (или какой там был? Короче тот, который немного мощнее 486) с 32 мегабайтами памяти, если включить музыку (особенно с битрейтом 320кбит), то на диалапе рендеринг веб-страниц начинал тормозить. Приходилось слушать 128кбит :-(.
Ох, интересные были времена… "Четверки" были сильно разные, были и те, что обгоняли младшие пентиумы, немного, правда, и за счет вдвое большей тактовой. Но это поздняя четверочная "элита" из мира клонов, а параллельно с ней были и ужасы с тактовой в 25 без множителя, так что запустить музычку в WinAmp на иной было можно, но хоть что-то делать — уже нет. Пенек-133, а тем более с MMX на борту — совсем другие пироги...
960 на 5 вкладок — это всего лишь 192Мб на вкладку, а это реально мало.
Современные сайты, особенно соцсети, весят со всем своим набором скриптов и картинок не менее 30Мб на страничку, а часто и больше. И это только сырые данные, которые ещё надо распарсить, преобразовать в удобный формат, построить дерево DOM и наконец отрендерить.
Причём CSS — это такое кошмарное нагромождение совершенно идиотских костылей, что правильный рендер этого всего сам по себе жрёт огромную кучу ресурсов.
Отдельное веселье — Javascript, ведь это же язык с автоматическим управлением памятью. А если у нас где-то работает GC, то мы уже заранее готовимся к перерасходу памяти — GC ведь не запустишь каждый раз, когда удаляется очередной объект, а только когда мусора набирается достаточно много.
Отключите в браузере загрузку графики, CSS и JS, и вы увидите, как сильно сократится потребление памяти.
Современные сайты, особенно соцсети, весят со всем своим набором скриптов и картинок не менее 30Мб на страничку, а часто и больше. И это только сырые данные, которые ещё надо распарсить, преобразовать в удобный формат, построить дерево DOM и наконец отрендерить.
Причём CSS — это такое кошмарное нагромождение совершенно идиотских костылей, что правильный рендер этого всего сам по себе жрёт огромную кучу ресурсов.
Отдельное веселье — Javascript, ведь это же язык с автоматическим управлением памятью. А если у нас где-то работает GC, то мы уже заранее готовимся к перерасходу памяти — GC ведь не запустишь каждый раз, когда удаляется очередной объект, а только когда мусора набирается достаточно много.
Отключите в браузере загрузку графики, CSS и JS, и вы увидите, как сильно сократится потребление памяти.
Ну вот меня и поражает, что 192-на-вкладку для них мало. На смом деле двести мегабайт памяти это очень-очень дофига, но до современных людей это плохо доходит. Многие не видели модуль памяти на 8 килобайт размером с материнку… А такая прожорливость — по сути, апофеоз неоптимального расходования ресурсов, машина мощная, стерпит и не такое.
Сейчас идёт размен функционала и скорости работы на память. Альтернатива — более тщательная разработка функционала но в 10-100 раз дольше чем сейчас. Если бы не такая возможность, то сейчас бы только-только заканчивалась разработка Win3.11 а на аналог 95-й винды надо было бы времени еще лет 30. Но зато они летали бы на 80286-х только так.
Прожорливость… нынешние компьютеры потребляют энергии в десятки раз меньше чем машины 20-30 летней давности, а производительность выросла в тысячи а то и миллионы раз. Глупо не пользоваться такими возможностями.
Потребление памяти браузерами можно уменьшить кардинально, но едва ли вам это понравится — ценой будет существенное снижение скорости работы. Возьмём к примеру какие-то банальные картинки — на страничке допустим десяток джепегов размером по 100кб, казалось бы всего 1мБ но ведь это СЖАТЫЕ изображения, чтобы их отобразить на экране их нужно развернуть. И тут у браузера есть два пути: 1) разжимать изображения непосредственно перед показом когда страничка будет прокручена до его позиции и освободить память когда изображение находится вне пределов экрана 2) разжать все изображения сразу(можно даже по мере необходимости) и хранить их в памяти пока страничка открыта, а может и дольше, вдруг пользователь передумает и снова его откроет.
Первый вариант сильно нагружает процессор и при прокрутке обязательно будут лаги(поинтересуйтесь у гугла какие нынче результаты распаковки JPEG по времени у наилучших алгоритмов — речь идёт на десятки милисекунд, из которых складываются доли секунд которые и раздражают).
А теперь немного математики обычная такая себе картинка 1024x768 — примерно четверть современного экрана а то и сильно меньше имеет примерно 1млн пикселей, каждый из которых в разжатом виде в памяти представлен 4-мя байтами итого какая-то средненькая картинка в памяти будет занимать 4Мб… фигак-фигак, и на картинки средненького сайта уже 100мб памяти ушло ибо браузеры используют второй вариант. развернуть DOM-дерево, подгрузить шрифты, экземпляр интерпретатора JAVA, злополучный флеш(пока ещё, но его по потреблению ресурсов скоро HTML5 заменит) и еще 50...90Мб как не бывало.
Всё это несомненно можно оптимизировать, написать на чистом Си… но это примерно лет 100 технического долга. Через 100 лет это переписанное изделие уже не будет иметь актуальности… да оно уже через 10 лет не будет актуально! Но тем не менее, с картинками мы ничего не сможем поделать — как ни крутись а хранить их в памяти будет нужно т.е. потребление в 100мб на вкладку ещё сохранится. Смысл тратить усилия десятков тысяч человеко-лет чтобы сократить потребление памяти всего в 2 раза? да через пол года-год технического прогресса проще будет установить в систему памяти в 2 раза больше…
Прожорливость… нынешние компьютеры потребляют энергии в десятки раз меньше чем машины 20-30 летней давности, а производительность выросла в тысячи а то и миллионы раз. Глупо не пользоваться такими возможностями.
Потребление памяти браузерами можно уменьшить кардинально, но едва ли вам это понравится — ценой будет существенное снижение скорости работы. Возьмём к примеру какие-то банальные картинки — на страничке допустим десяток джепегов размером по 100кб, казалось бы всего 1мБ но ведь это СЖАТЫЕ изображения, чтобы их отобразить на экране их нужно развернуть. И тут у браузера есть два пути: 1) разжимать изображения непосредственно перед показом когда страничка будет прокручена до его позиции и освободить память когда изображение находится вне пределов экрана 2) разжать все изображения сразу(можно даже по мере необходимости) и хранить их в памяти пока страничка открыта, а может и дольше, вдруг пользователь передумает и снова его откроет.
Первый вариант сильно нагружает процессор и при прокрутке обязательно будут лаги(поинтересуйтесь у гугла какие нынче результаты распаковки JPEG по времени у наилучших алгоритмов — речь идёт на десятки милисекунд, из которых складываются доли секунд которые и раздражают).
А теперь немного математики обычная такая себе картинка 1024x768 — примерно четверть современного экрана а то и сильно меньше имеет примерно 1млн пикселей, каждый из которых в разжатом виде в памяти представлен 4-мя байтами итого какая-то средненькая картинка в памяти будет занимать 4Мб… фигак-фигак, и на картинки средненького сайта уже 100мб памяти ушло ибо браузеры используют второй вариант. развернуть DOM-дерево, подгрузить шрифты, экземпляр интерпретатора JAVA, злополучный флеш(пока ещё, но его по потреблению ресурсов скоро HTML5 заменит) и еще 50...90Мб как не бывало.
Всё это несомненно можно оптимизировать, написать на чистом Си… но это примерно лет 100 технического долга. Через 100 лет это переписанное изделие уже не будет иметь актуальности… да оно уже через 10 лет не будет актуально! Но тем не менее, с картинками мы ничего не сможем поделать — как ни крутись а хранить их в памяти будет нужно т.е. потребление в 100мб на вкладку ещё сохранится. Смысл тратить усилия десятков тысяч человеко-лет чтобы сократить потребление памяти всего в 2 раза? да через пол года-год технического прогресса проще будет установить в систему памяти в 2 раза больше…
Требования постоянно растут из-за роста объёма и сложности контента. Вот казалось бы, что такое картинка с разрешением 1024x768? Довольно скромненькая… а памяти требует только для хранения в разжатом виде порядка 4Мб. Потому что так проще и быстрее её вывести на дисплей, а потом фигак — нужен масштаб 150%… картинка увеличивается, исходник остаётся и рядом ложится отмасштабированая на 6Мб готовая к выводу на дисплей по первому требованию.
И это, блин, всего лишь картинка размером в четверть площади современного дисплея не самого большого разрешения. А как быть с дисплеями ретина? Там где 4К и эта картинка будет составлять всего 1/16 по площади… На одних только картинках памяти уже нужно сколько. А есть ещё сложное дерево DOM странички сайта, которое надо распарсить и внезапно каждый элемент этого дерева в памяти представлен объектом, ибо универсальность, а это значит что каждая мелочь это уже сотня байт в памяти. Копейка к копейке и смотришь уже 50Мб набралось. и тут на странице вылазит Джава-скрипт, который вынуждает браузер держать в памяти джава-интерпретатор…
Если этого всего не делать, а держать в памяти всё в сжатом виде и распаковывать всё только по требованию то мы сразу же упрёмся в процессор — его станет не хватать, начнутся подтормаживания, задержки и т.д.
Поэтому браузер лёгкий, по меркам современных требований к поддержке необходимых для работы технологий.
И это, блин, всего лишь картинка размером в четверть площади современного дисплея не самого большого разрешения. А как быть с дисплеями ретина? Там где 4К и эта картинка будет составлять всего 1/16 по площади… На одних только картинках памяти уже нужно сколько. А есть ещё сложное дерево DOM странички сайта, которое надо распарсить и внезапно каждый элемент этого дерева в памяти представлен объектом, ибо универсальность, а это значит что каждая мелочь это уже сотня байт в памяти. Копейка к копейке и смотришь уже 50Мб набралось. и тут на странице вылазит Джава-скрипт, который вынуждает браузер держать в памяти джава-интерпретатор…
Если этого всего не делать, а держать в памяти всё в сжатом виде и распаковывать всё только по требованию то мы сразу же упрёмся в процессор — его станет не хватать, начнутся подтормаживания, задержки и т.д.
Поэтому браузер лёгкий, по меркам современных требований к поддержке необходимых для работы технологий.
Я бы сказал, что во многих случаях софт становится проще и жирнее. Загадка прям...
Точка зрения виндового сисадмина и просто хоумюзера.
По моему софт так и продолжает разбухать, но часть собственных, уникальных для каждого приложения «велосипедов» переехала ниже уровнем на общепринятые фреймворки/движки и тому подобное (точно также как и у сайтов) и их уже как бы не надо разрабатывать и оптимизировать (C Runtime, .NET). Зачастую ПО средней паршивости шустро вертится только на компах, видимо стоящих у разработчиков (а-ля i7, SSD, 8-16Gb RAM, etc.), но с большим трудом шевелится на слабых и средненьких машинках, которых вообще-то большинство у пользователей.
А Win 10 на гигабайте это из той же оперы, что и вин 7 на гигабайте. Оптимизация за счет отключения «ненужных» функций. Сходу не вспомню что вырубается в довольно неплохо документированной семерке (напомню, что по внутренностям 10 инфы кот наплакал), но в том же офисе автоматом вырубится проверка орфографии, иначе машина умрет при проверке 10-ти страничного дока.
По моему софт так и продолжает разбухать, но часть собственных, уникальных для каждого приложения «велосипедов» переехала ниже уровнем на общепринятые фреймворки/движки и тому подобное (точно также как и у сайтов) и их уже как бы не надо разрабатывать и оптимизировать (C Runtime, .NET). Зачастую ПО средней паршивости шустро вертится только на компах, видимо стоящих у разработчиков (а-ля i7, SSD, 8-16Gb RAM, etc.), но с большим трудом шевелится на слабых и средненьких машинках, которых вообще-то большинство у пользователей.
А Win 10 на гигабайте это из той же оперы, что и вин 7 на гигабайте. Оптимизация за счет отключения «ненужных» функций. Сходу не вспомню что вырубается в довольно неплохо документированной семерке (напомню, что по внутренностям 10 инфы кот наплакал), но в том же офисе автоматом вырубится проверка орфографии, иначе машина умрет при проверке 10-ти страничного дока.
Конечно продолжает. Смотрю в диспетчер задач. Chrome (9 открытых вкладок + 9 установленных расширений) — сожрал 1.5 гб. Slack — 0.65 гб. Сейчас я открою еще 20 вкладок по работе. Открою Android Studio. Включу музыку, возможно открою еще парочку программ и все, мои 8 гб кончатся. А бывает когда нужно открыть две студии, открыть больше вкладок и т д и т п и тут уже мой комп дохнет. Так что в следующие пол года, когда я буду брать новый ноут, мой выбор падет на максимальный i7 + SSD + 16 гб (а лучше больше, но зависит от бюджета). Этого хватит с лихвой, но я подозреваю лишь на первое время.
Да, некоторый софт периодически становится легче и проще и оптимизированней, но если брать скоуп программ которыми пользуешься постоянно, тенденция явно на увеличение потребляемых ресурсов.
С другой стороны, в этом нет ни чего плохого, как и нет ни чего хорошего. Это просто факт, законы рынка и физики.
Да, некоторый софт периодически становится легче и проще и оптимизированней, но если брать скоуп программ которыми пользуешься постоянно, тенденция явно на увеличение потребляемых ресурсов.
С другой стороны, в этом нет ни чего плохого, как и нет ни чего хорошего. Это просто факт, законы рынка и физики.
> Chrome (9 открытых вкладок + 9 установленных расширений) — сожрал 1.5 гб.
Это что у вас за Хром такой? Или, что за сайты во вкладках открыты?
У меня (Хром 49.0.2623.110 m — 64-bit) сейчас открыто 18 вкладок и установлено 16 расширений: память — 525,5 Мб, ЦП — 6,2%.
Это что у вас за Хром такой? Или, что за сайты во вкладках открыты?
У меня (Хром 49.0.2623.110 m — 64-bit) сейчас открыто 18 вкладок и установлено 16 расширений: память — 525,5 Мб, ЦП — 6,2%.
Последняя версия 64-bit. Вкладки: 3 — гигтаймс, 3 — трелло, 1 — wordmemo.ru, 1 — english-e-reader.net, 1 — github. Расширения самые обычные — адблок, ghostery, nimbus, colorzilla, etc., ну и плюс еще пара chrome приложений работает — hangout и postman. Вот вроде и все, но может быть повлияло то, что я не перезагружал давно, но я ни разу не видел, что бы хром с открытыми вкладками у меня кушал меньше гигабайта.
Я не знаю, почему у вас так много сжирается памяти. Может действительно из-за того, что долго не перезагружали компьютер.
У меня следующая картина: https://youtu.be/JnRZkptff2I
Расширения следующие:
1. Adblock Plus
2. Application Launcher for Drive
3. Google Similar Pages
4. Google в качестве поиска по умолчанию
5. Google Hangouts
6. Google Документы оффлайн
7. IBA Opt-out
8. Pure URL
9. Video AdBlock for Chrome
10. ZenMate VPN
11. Изображение по центру
12. Яндекс.Диск
13. Google Keep
14. Google Презентации
P. S. Всего в системе 4 Гб.
У меня следующая картина: https://youtu.be/JnRZkptff2I
Расширения следующие:
1. Adblock Plus
2. Application Launcher for Drive
3. Google Similar Pages
4. Google в качестве поиска по умолчанию
5. Google Hangouts
6. Google Документы оффлайн
7. IBA Opt-out
8. Pure URL
9. Video AdBlock for Chrome
10. ZenMate VPN
11. Изображение по центру
12. Яндекс.Диск
13. Google Keep
14. Google Презентации
P. S. Всего в системе 4 Гб.
У меня та же картина. Пять вкладок, nnm-club, два geektimes, zdnet и MS technet — 982732 килобайта. Хром 49.0.2623.110 m (64-bit), расширения AdBlock 2.53 и friGate 2.0.328. И вообще у меня кроме браузера, FAR и Task Manager, в котором смотрел циферки, не открыто ничего, а 4.31 гиг памяти кем-то заняты… Т.е. на 1-2-и-4 гигах это еще бы и свопилось? Да такой объем памяти еще не так давно не на всяком суперкомпьютере был… А задачи? Сижу и читаю текст, пописываю в ответ — точно такие же задачи решались на мегабайте оперативки… А на 12 (да, неровно) уже книжку верстали со всеми наворотами. Что и как оптимизировали гении в хроме, что его ТАК ПРЕТ?
Надеюсь, веб тоже станет легче и мы вернёмся к страничкам, весящим килобайты (без учёта графики) и массовому применению простого HTML. Когда же люди (особенно заказчики) поймут, что быстрая безглючная работа и функциональность важнее "дизайна" и украшательств.
А мне кажется, что сейчас все идет не к "простым HTML страничкам на килобайты", а к SPA везде, т.е. первоначальная загрузка скрипта/разметки и потом уже обмен с сервером этими килобайтами чистых данных.
И меня это бесит. И многих это бесит. И всем пофиг.
Дальше будет короткий текст вида «накипело».
Сколько раз я слышал одну и ту же фразу по поводу жЫрноты сайтов «да сейчас у меня телефон работает быстрее атома, а LTE с безлимитом вообще про траф позволяет забыть» и ведь никто не задумается, что эта скорость сжирает аккум, а у кого-то может быть и GPRS. То есть на пользователей все клали — мы лучше загрузим побольше JS(CSS+HTML)-фреймворков, чтобы отрендерить страницу с сообщением, максимальная длина которого 140 символов. Или в шапку лэнда выведем видео 1080p.
Далеко ходить не надо. У меня был телефон HTC 8s (винда, два! ядра и 512Мб RAM), использовался для звонков и одной вкладки браузера (больше себе дороже). Рассказать как весело загружается geektimes? Сначала прогружается, потом виснет намертво для загрузки рекламы, и только после полуминуты тормозов можно просмотреть список постов. На Yotaphone такого нет, но тут за все расплачивается заряд.
Простите, вырвалось, но исключительно потому что я знаю, что можно делать иначе, чтобы все были довольны.
Дальше будет короткий текст вида «накипело».
Сколько раз я слышал одну и ту же фразу по поводу жЫрноты сайтов «да сейчас у меня телефон работает быстрее атома, а LTE с безлимитом вообще про траф позволяет забыть» и ведь никто не задумается, что эта скорость сжирает аккум, а у кого-то может быть и GPRS. То есть на пользователей все клали — мы лучше загрузим побольше JS(CSS+HTML)-фреймворков, чтобы отрендерить страницу с сообщением, максимальная длина которого 140 символов. Или в шапку лэнда выведем видео 1080p.
Далеко ходить не надо. У меня был телефон HTC 8s (винда, два! ядра и 512Мб RAM), использовался для звонков и одной вкладки браузера (больше себе дороже). Рассказать как весело загружается geektimes? Сначала прогружается, потом виснет намертво для загрузки рекламы, и только после полуминуты тормозов можно просмотреть список постов. На Yotaphone такого нет, но тут за все расплачивается заряд.
Простите, вырвалось, но исключительно потому что я знаю, что можно делать иначе, чтобы все были довольны.
Хуже того, при настройках серверов ещё и таймауты ставят минимально возможные, так что в случае GPRS нередко бывает так, что половину сайтов невозможно загрузить вообще — сервер рвёт соединение по таймауту.
Старые приложения, запущенные на старых ОС, хороши тем, что они работают быстрее мысли. Пользоваться ими — самый настоящий кайф, они даже не летают — они парят.
Никаких лагов, задержек, микро-подтормаживаний. Всего того, от чего в современных приложениях невозможно избавиться.
Ну не смешно ли, что на двухъядерной машине с 2Гб памяти какой-то долбанный твиттер в браузере прокручивается с ощутимой задержкой? Что если крутануть туда-сюда колёсико мыши, страничка дёрнется с ощутимым запозданием? Да на этой машине Mass Effect без проблем работает! Убейтесь вместе со своими бутстрапами, ангулярами или чего вы туда напихали, что оно настолько тяжеловесно.
В Linux тоже в последнее время невесело: KDE сейчас вообще не могу пользоваться, т.к. вот эти микроскопические притормаживания утомляют неимоверно. Вот скажите мне, что такого принципиально нового появилось в KDE 5.6, что он стал жрать настолько больше ресурсов? Или там каждую строчку кода начали по 2 раза писать, чтоб достичь подобного эффекта?
В XFce кстати тоже как-то прибавилось неуклюжести. LXDE+OpenBox пока ещё более-менее быстрый, но и тут горе-кодеры спешат всё на Qt перевести, ну чтоб уж наверняка тормозило.
От тормозов в мобильных приложениях я уже и не мечтаю избавиться. Вероятно, тот счастливый момент, когда они начнут работать действительно гладко и плавно, не наступит никогда и ни при каком количестве ядер и памяти, скорее уж на Земле коммунизм построят...
Старые приложения, запущенные на старых ОС, хороши тем, что они работают быстрее мысли. Пользоваться ими — самый настоящий кайф, они даже не летают — они парят.
Никаких лагов, задержек, микро-подтормаживаний. Всего того, от чего в современных приложениях невозможно избавиться.
Ну не смешно ли, что на двухъядерной машине с 2Гб памяти какой-то долбанный твиттер в браузере прокручивается с ощутимой задержкой? Что если крутануть туда-сюда колёсико мыши, страничка дёрнется с ощутимым запозданием? Да на этой машине Mass Effect без проблем работает! Убейтесь вместе со своими бутстрапами, ангулярами или чего вы туда напихали, что оно настолько тяжеловесно.
В Linux тоже в последнее время невесело: KDE сейчас вообще не могу пользоваться, т.к. вот эти микроскопические притормаживания утомляют неимоверно. Вот скажите мне, что такого принципиально нового появилось в KDE 5.6, что он стал жрать настолько больше ресурсов? Или там каждую строчку кода начали по 2 раза писать, чтоб достичь подобного эффекта?
В XFce кстати тоже как-то прибавилось неуклюжести. LXDE+OpenBox пока ещё более-менее быстрый, но и тут горе-кодеры спешат всё на Qt перевести, ну чтоб уж наверняка тормозило.
От тормозов в мобильных приложениях я уже и не мечтаю избавиться. Вероятно, тот счастливый момент, когда они начнут работать действительно гладко и плавно, не наступит никогда и ни при каком количестве ядер и памяти, скорее уж на Земле коммунизм построят...
Лично мое мнение, что монструозность ПО опережает мощности компьютеров широкого потребления. Что раньше, что сейчас.
Да, если сейчас поставить на современный четырехъядерный компьютер с 16 Гб памяти WinXP и Photoshop 5, то они будут летать, но на компьютерах тех лет тормоза все равно будут.
Да, если сейчас поставить на современный четырехъядерный компьютер с 16 Гб памяти WinXP и Photoshop 5, то они будут летать, но на компьютерах тех лет тормоза все равно будут.
XP возьмет свои 4Гб(а из-за аппаратных особенностей материнки будет доступно всего 2.75Гб к примеру) и дальше всё… остальное только через своп на RAM-диске, но это способен настроить не каждый, да и всё же доступ к RAM через своп не такой уж быстрый.
XPx64 в расчёт не берём, слишком уж малораспространённая система.
XPx64 в расчёт не берём, слишком уж малораспространённая система.
Сама страничка может весить килобайты, но для ее рендеринга потребуются сотни мегабайт.
Мне кажется дело в том, что человечество накопило большую базу вспомогательного кода, библиотек/фреймворков/модулей, и что не менее мало важно — средств для того, что бы ими делиться. В купе с развитием культуры опенсорса и интернетов в целом (до всяких гитхабов и дешевого интернета кода тоже было много, только у каждого свои запасы), меньше времени тратится на «реализацию задач хоть как-то», и гораздо больше на улучшение качества кода/пользовательского опыта. Субъективный вывод из субъективного мнения: это естественный ход вещей. Не то, что бы раньше не понимали, что хороший и простой код это круто. Просто доводить до такого состояния программы имели возможность не все.
Странно, мне как-то и 2 гига хватает. Естественно по 40 вкладок у меня не открыто (для чего такое количество может понадобиться не знаю), максиму 10-15, но в основном до 5.
Достаточно удалить хром и поставить firefox...
Который у меня вот прямо сейчас накопил 2.4 ГБ за неделю использования (вкладок, конечно, много открыто)
Ну, тут только рестартить или неиспользуемые вкладки аддонами выгружать.
Недавно у меня Firefox простоял сутки с открытой 1 табой, в которой был загружен список видео twitch (то есть не само видео, а только грид с превьюшками) — 5,5 ГБ оперативы скушано.
Ставьте (и algot тоже) 32х битную версию Лисы, она больше 2 ГБ ни при каких условиях не отожрёт, что прекрасно, да и глюков в ней меньше.
32-битные программы легко получают почти 4ГБ юзерспейса, если в PE-заголовке выставлен флаг IMAGE_FILE_LARGE_ADDRESS_AWARE (а у FF он выставлен, т.к. современные компиляторы выставляют его по умолчанию).
Вот уж не знаю, раньше не было таких монстров, как Electron. Когда я вижу софт, гуй которого написан на html и крутится на веб-движке, то становится трудновато поверить, что эпоха жирного ПО позади.
Это промежуточная стадия. Во-первых html+css всетаки распространеннее (как ни крути сейчас это так) и гибче (ну тут еще вопрос подхода — то что исходники фактически всегда открыты) чем классический ui-фреймворки. Во-вторых граница web'а и desktop'а размываются.
В идеале — html+css надо в качестве основного UI операционки пихать. Только с js не знаю че делать, все таки для десктопа над иметь возможность компилять в натив и нормальную производительность показывать. Может встроить компилятор системного языка в ОС и распространять код приложений на этом языке а не на js. И странички тоже в вебе на нативе делать. Дальше полезут вопросы безопасности ))
Ну это так… фантазии…
В идеале — html+css надо в качестве основного UI операционки пихать. Только с js не знаю че делать, все таки для десктопа над иметь возможность компилять в натив и нормальную производительность показывать. Может встроить компилятор системного языка в ОС и распространять код приложений на этом языке а не на js. И странички тоже в вебе на нативе делать. Дальше полезут вопросы безопасности ))
Ну это так… фантазии…
Есть неплохие сторонние программы для поиска файлов, например Everything. Мне сильно не хватает подобной программы под Linux, в которой GUIшный поиск файлов кажется до ужаса тормознутым. Очень хочется нормальную GUI-обёртку над Locate, чтоб список найденного обновлялся бы сам уже по мере набора регулярки, мгновенно, без видимых задержек в несколько секунд.
Про W10 — по моим субьективным ощущениям, она работает медленее чем W8.1. Тоже самое касательно W10M — по сравнению WP8.1 — десятка это просто монстр лагающий, да еще перегруженный ненужными (на телефоне) вещами.
Так что все относительно.
Так что все относительно.
Node.js с его традицией писать десктопный софт внутри браузера явно отражает тенденцию на сбрасывание лишнего веса. Скорее мы просто привыкли к тому, что программы жирнели раз в два года, а теперь у них скорость обрастания жиром снизилась до раз в три года, и мы уже рады изменению первой производной.
Я был бы безумно счастлив согласиться с автором, но увы, практика показывает ровно обратное.
Про веб вообще лучше промолчу, да и здесь все уже написали:
https://habrahabr.ru/post/278655/
Десктопный же софт все тяжелеет, а умеет все меньше, причем по какому-то недоразумению это даже позиционируется как достоинство.
А с модой держать все в облаках и лазить туда на каждый чих появляется все больше тормозов на плохих соединениях и зависимости от внешних сервисов, даже там, где без них спокойно можно было бы обойтись.
Недавно был вынужден перейти со связки Miranda+Gmail на Telegram. У последнего нашлось ровно два клиента под десктоп:
По сравнению с крошечной Мирандой, умеющей в 10 раз больше (хотя бы мгновенный поиск по всей истории по любой подстроке, а не слову) и весящей в 10-100 раз меньше, это даже не шаг, это гигантский скачок назад.
(Из плюсов: наконец-то мессенджеры научились передавать файлы и подтверждать прочтение сообщений. Это, конечно, маленький, но уверенный шаг вперед.)
Короче, я очень надеюсь, что спрос на компактные и быстрые решения снова будет расти, работы здесь — непаханое поле.
Про веб вообще лучше промолчу, да и здесь все уже написали:
https://habrahabr.ru/post/278655/
Десктопный же софт все тяжелеет, а умеет все меньше, причем по какому-то недоразумению это даже позиционируется как достоинство.
А с модой держать все в облаках и лазить туда на каждый чих появляется все больше тормозов на плохих соединениях и зависимости от внешних сервисов, даже там, где без них спокойно можно было бы обойтись.
Недавно был вынужден перейти со связки Miranda+Gmail на Telegram. У последнего нашлось ровно два клиента под десктоп:
- Официальный, который официально не умеет (и официально не хочет уметь) киллер-фичу телеграма — секретные чаты. Поиска по истории нет вообще, точнее, он не работает, понадобилось найти сообщение годичной давности — извольте мотать бесконечный скролл до посинения пальцев.
(неужели такая проблема в 2016 году хранить пару мегабайт текста и искать по нему локально?) - Cutegram, про который достаточно знать то, что он весит несколько сотен (!) мегабайт и при установке распаковывает несколько десятков тысяч мелких файлов с картинками (я представляю, каково здесь обладателям HDD). При этом, кроме чатов, умеет он не сильно больше официального.
По сравнению с крошечной Мирандой, умеющей в 10 раз больше (хотя бы мгновенный поиск по всей истории по любой подстроке, а не слову) и весящей в 10-100 раз меньше, это даже не шаг, это гигантский скачок назад.
(Из плюсов: наконец-то мессенджеры научились передавать файлы и подтверждать прочтение сообщений. Это, конечно, маленький, но уверенный шаг вперед.)
Короче, я очень надеюсь, что спрос на компактные и быстрые решения снова будет расти, работы здесь — непаханое поле.
А автор сравнивал скорость работы разных систем в тестах или определил прирост производительности "на глазок"? По тестам, семерка существенно опережает висту только в скорости загрузки. В остальных сценариях использования, разница между системами незначительна. Тоже самое можно сказать и про более новые системы Майкрософт: если там что-то и оптимизировали, то это успешно компенсируется сомнительными нововведениями. Все эти "живые" плитки, синхронизация с облаком, глубоко интегрированная в систему поддержка тач и планшетных функций — все это весьма не бесплатно. Теперь вот еще будет синхронизация со смартфоном и прокидывание звонков по типу handoff и continuity у Apple.
Последней системой МС, которой я пользовался, была Windows Server 2008 R2. Если в семерке после свежей установки я обычно отключал полтора десятка служб, убирал все из автозапуска и потом пол дня лазал по системе отключая неиспользуемые функции (вроде offline файлов и индексации системного диска), то в серверной системе нужно было наоборот включить несколько служб и установить пару ролей, чтобы комфортно пользоваться компьютером. Результат того стоил — ноутбук работал от аккумулятора в полтора раза дольше.
Последней системой МС, которой я пользовался, была Windows Server 2008 R2. Если в семерке после свежей установки я обычно отключал полтора десятка служб, убирал все из автозапуска и потом пол дня лазал по системе отключая неиспользуемые функции (вроде offline файлов и индексации системного диска), то в серверной системе нужно было наоборот включить несколько служб и установить пару ролей, чтобы комфортно пользоваться компьютером. Результат того стоил — ноутбук работал от аккумулятора в полтора раза дольше.
До сих пор для меня нет лучшего просмоторщика изображений, чем ACDSee 2.43. Родом он из 2000 года похоже. Как-то в древние времена раздобыл его с серийником, так на все свои компьютеры и продолжаю ставить уже 16 лет. Наряду с FAR Manager это похоже самая долгоживущая программа. Хотя FAR я скачиваю свежий с интернета, а вот ACDSee беру все с того же архива.
Почему? Мне нужно просто посмотреть картинку. И все! Не нужны все эти библиотеки, облака, звездочки-оценки… Как-то, лет 10 назад попробовал поставить свежий на тот момент ACDSee. Получил ужасный комбайн из свистелок, который еще и что-то там тайно индексировал.
Причина "комбайнизации" мне кажется в том, что у менеджера продукта стоит задача как-то этот продукт развивать. Самый очевидный способ — добавлять новый функционал. Конкурент впилил просмотр видео, значит и мы должны, чтобы не отставать. К тому же есть команда программистов, которая должна получать зарплату. А чтобы она её не просто так получала, нужно давать ей задания.
Почти во всех продуктовых компаниях, где я работал был как раз такой принцип развития и поддержки продуктов. В итоге код раздувается, его становится все тяжелее поддерживать и развивать, все тормозит, куча багов. Программисты без работы то не останутся. Но в целом качество продукта постепенно падает.
Почему? Мне нужно просто посмотреть картинку. И все! Не нужны все эти библиотеки, облака, звездочки-оценки… Как-то, лет 10 назад попробовал поставить свежий на тот момент ACDSee. Получил ужасный комбайн из свистелок, который еще и что-то там тайно индексировал.
Причина "комбайнизации" мне кажется в том, что у менеджера продукта стоит задача как-то этот продукт развивать. Самый очевидный способ — добавлять новый функционал. Конкурент впилил просмотр видео, значит и мы должны, чтобы не отставать. К тому же есть команда программистов, которая должна получать зарплату. А чтобы она её не просто так получала, нужно давать ей задания.
Почти во всех продуктовых компаниях, где я работал был как раз такой принцип развития и поддержки продуктов. В итоге код раздувается, его становится все тяжелее поддерживать и развивать, все тормозит, куча багов. Программисты без работы то не останутся. Но в целом качество продукта постепенно падает.
Попробуйте FastStone Image Viewer. Когда то давно тоже использовал ACDsee (ещё в начале 00), но сейчас пользую ФэстСтоун, тк современен, бесплатен и не перегружен.
Когда несколько лет назад я его пробовал FastStone меня убивала его скорость, там даже есть опция "быстро, но плохо" и реально очень плохо, но быстро почти как ACD, а по умолчанию видно как открывалась картинка в плохом качестве быстро и следом перерисовывалась качественно уже.
Там плохо из-за архитектуры приложения, они даже элементарную поддержку unicode для имён файлов только в 2015 году добавили (раньше приложение такие файлы и папки просто не видело) и до сих пор они не умеют в многопоточность почти нигде, так например обход дерева файлов при его выводе вешает софтину полностью.
Доп: рендеринг и обработка изображений тоже вешают софтину на весь процесс обработки.
Доп: рендеринг и обработка изображений тоже вешают софтину на весь процесс обработки.
Fast Stone Image Viewer или Irfan Viewer.
Лучше конечно ACDSee 3.01, но у него есть одна досадная проблема — файл где кешируются превью всех открытых картинок когда переваливает за смешные 800Мб перестаёт работать предпросмотр, приходится его вручную удалять. А если отключить превью, то становится жутко неудобно работать с каталогами изображений.
И в нём к сожалению нет очень нужной функции — он игнорирует EXIF-тег ориентации фотографии.
Поэтому не так давно перешёл на FastStone по скорости работы(открытие тяжелых картинок) он немного не дотягивает до ACDSee 3.01 но обладает всеми нужными современными функциями и нормально поддерживает современные графические форматы вплоть до RAW.
И в нём к сожалению нет очень нужной функции — он игнорирует EXIF-тег ориентации фотографии.
Поэтому не так давно перешёл на FastStone по скорости работы(открытие тяжелых картинок) он немного не дотягивает до ACDSee 3.01 но обладает всеми нужными современными функциями и нормально поддерживает современные графические форматы вплоть до RAW.
Спасибо вам, добрый человек! Ваша рекомендация сделала мой день. Это как бальзам на душу после всех этих перегруженных софтин. К тому же ещё и настройки хранит в .ini, просто великолепно! Сам пользовался до сегодняшнего дня IrfanView в связке с Total Commander.
Ух, да она прекрасна! Еще б теперь выпилить штатный просмотрщик, чтоб зазря место не занимал.
А штатный это какой? Если я правильно понимаю, то он, вместе с остальным хламом отключается в компонентах.
Если у вас Windows 10, то удалить встроенные приложения очень просто.
Запускаем Windows PowerShell (есть в меню Пуск) от имени Администратора и удаляем следующими командами:
Обязательно:
Get-AppxPackage *OneNote* | Remove-AppxPackage
Get-AppxPackage *people* | Remove-AppxPackage
Get-AppxPackage *3d* | Remove-AppxPackage
Get-AppxPackage *communi* | Remove-AppxPackage
Get-AppxPackage *bing* | Remove-AppxPackage
Get-AppxPackage *zune* | Remove-AppxPackage
Get-AppxPackage *phone* | Remove-AppxPackage
Необязательно:
Get-AppxPackage *camera* | Remove-AppxPackage
Get-AppxPackage *photo* | Remove-AppxPackage
Get-AppxPackage *solit* | Remove-AppxPackage
Get-AppxPackage *soundrec* | Remove-AppxPackage
Get-AppxPackage *xbox* | Remove-AppxPackage
Get-AppxPackage *maps* | Remove-AppxPackage
Get-AppxPackage *alarms* | Remove-AppxPackage
Вернуть все назад:
Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Вам походу нужна вот эта: Get-AppxPackage *photo* | Remove-AppxPackage
Запускаем Windows PowerShell (есть в меню Пуск) от имени Администратора и удаляем следующими командами:
Обязательно:
Get-AppxPackage *OneNote* | Remove-AppxPackage
Get-AppxPackage *people* | Remove-AppxPackage
Get-AppxPackage *3d* | Remove-AppxPackage
Get-AppxPackage *communi* | Remove-AppxPackage
Get-AppxPackage *bing* | Remove-AppxPackage
Get-AppxPackage *zune* | Remove-AppxPackage
Get-AppxPackage *phone* | Remove-AppxPackage
Необязательно:
Get-AppxPackage *camera* | Remove-AppxPackage
Get-AppxPackage *photo* | Remove-AppxPackage
Get-AppxPackage *solit* | Remove-AppxPackage
Get-AppxPackage *soundrec* | Remove-AppxPackage
Get-AppxPackage *xbox* | Remove-AppxPackage
Get-AppxPackage *maps* | Remove-AppxPackage
Get-AppxPackage *alarms* | Remove-AppxPackage
Вернуть все назад:
Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Вам походу нужна вот эта: Get-AppxPackage *photo* | Remove-AppxPackage
ACDSee тяжел и перегружен свистоперделками, но встроенная поддержка RAW со всех камер, до которых я могу дотянуться, просмотр фотошоповских и прочих файлов — это удобно. Простые вьюеры легко показывают JPG с PNG, но шаг в сторону и приплыли.
Мало распространенный, наилегчайший, бесплатный просмотрщик imagine. http://www.nyam.pe.kr/blog/entry/Imagine
Добавлю XnView в коллекцию.
Вообще эта ветка на самом деле очень много говорит в контексте записи — у ACDSee огромное количество быстрых и бесплатных альтернатив, но люди даже не пытаются их искать.
А если большинству не нужны альтернативы тормознутым решениям...
Вообще эта ветка на самом деле очень много говорит в контексте записи — у ACDSee огромное количество быстрых и бесплатных альтернатив, но люди даже не пытаются их искать.
А если большинству не нужны альтернативы тормознутым решениям...
AСDSee был очень удобен до своего превращения в тормознутый комбайн ненужных свистоперделок (версии выше третьей). Настолько удобен и интуитивно понятен, что пользователей альтернатив можно было только пожалеть. Пользовался всем вышеперечисленным (кроме jpegview), но в плане удобства они кошмарны до сих пор.
P.S. За неимением лучшего пользуюсь FastStone и стараюсь это делать пореже, так как у него UI/UX на голову вывихнут.
P.S. За неимением лучшего пользуюсь FastStone и стараюсь это делать пореже, так как у него UI/UX на голову вывихнут.
Я не спорю, что альтернативы есть — быстрее, бесплатнее, новее. Но если что-то устраивает полностью, зачем менять? У каждой программы свой своеобразный интерфейс и философия, к которой придется привыкать. И я бы не назвал древний ACDSee тормознутым. Писался он во времена, когда процессоры были не чета современным.
В тему на счет выбора линейки Windows для встраеваемых устройств по объему накопителя информации
Windows Embedded Standard 2009 (Компонентная сборка, аналог Windows XP) HDD Space- 2GB to support a full image with .NET 3.0 is enough.
Windows 7 Embedded 7 GB free hard drive space for complete installation
Windows 8 Embedded Standart( Компонентная сборка) 3 GB of free space on the hard disk (HDD) or flash-based Solid State Drive (SSD) (6 GB recommended)
Windows 8.1 Industry 16 GB for 32-bit OS 20 GB for 64-bit
Windows 10 for desktop editions 16 GB (32-bit) or 20 GB (64-bit)
Windows Embedded Standard 2009 (Компонентная сборка, аналог Windows XP) HDD Space- 2GB to support a full image with .NET 3.0 is enough.
Windows 7 Embedded 7 GB free hard drive space for complete installation
Windows 8 Embedded Standart( Компонентная сборка) 3 GB of free space on the hard disk (HDD) or flash-based Solid State Drive (SSD) (6 GB recommended)
Windows 8.1 Industry 16 GB for 32-bit OS 20 GB for 64-bit
Windows 10 for desktop editions 16 GB (32-bit) or 20 GB (64-bit)
Что в этом списке делает W10 desktop?
По той причине, что меня не интересуют ограниченые мобильные сборки и нужна универсальность для выполнения традиционных задач РС.
Windows 10 for desktop editions аn OS that is designed for performing traditional PC tasks that uses the desktop experience. This OS runs native Win32 apps, Universal Windows apps, and existing apps from the Windows Store.
Жиреет, да. UI полного пакета Maya со всеми стандартными плагинами похож на панель управления в кабине шаттла. Есть две причины — Legacy и космонавт. Мы можем дать космонавту UI с двумя кнопками «IGNT» и «EJCT», только это никому не нужно, потому что космонавт обучен работе с UI шаттла и он его не пугает. Новичок? Научится, или на его место придет другой. Legacy существует из-за проблем с новыми функциями или что нибудь похожее. Не знаю, о каких «тенденциях к снижению веса в профессиональном софте» автор ведет речь, зачем отрывать шасси или радар фронтовому бомбардировщику? Может лучше поставить эту новенькую систему РЭБ? Нет? Ах, да, тенденция ведь идет к уменьшению, так что отпиливайте нахер крылья, ребята, автор статьи знает лучше о профессиональном софте. Вообще непонятно откуда у автора такие выводы.
Быть может, десктопные приложения и худеют, но вот сайты наоборот — жиреют день ото дня. Что выглядит довольно иронично на фоне их минималистичного, а иногда и откровенно примитивного дизайна. Я бы мог сверстать большинство таких сайтов на HTML4 и CSS 1.0 — и они бы шустро работали в IE6 на первом Pentium. Но современные веб-дизайнеры ухитряются сделать так, чтобы примитивный сайт тормозил даже на шестиядерном Core i7 с 16 гигабайтами оперативки.
Сейчас время дороже ресурсов. Слишком дорого получается оптимизировать сайты и писать их вручную — это могут позволить себе только мелкие разработчики которые никуда не спешат и не считают расходов.
Не сомневаюсь что можно сделать очень компактно и минималистично по ресурсам, но это получится очень дорогой штучный товар, совершенно неконкурентоспособный.
Не сомневаюсь что можно сделать очень компактно и минималистично по ресурсам, но это получится очень дорогой штучный товар, совершенно неконкурентоспособный.
Но раньше ведь как-то писали достаточно компактные сайты, и я бы не сказал что старые стандарты были сложнее современных. И потом, сайты обычно всегда пишутся вручную — WYSIWYG-редакторы здесь как-то не прижились…
Сейчас слишком много уделяется деталям. Раньше как писали? <table>, и пусть браузер сам решит, как показывать. А теперь куда ни глянь, от википедии до рутрекера, везде ненавязчивые, но приятные глазу градиенты и блоки с чуть большей/меньшей яркостью, чем фон страницы.
«Вручную» — это без бустрапов, ангуляров, реактов и подобных им. WYSIWYG-конструкторы тут совсем не при чем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эпоха «жирного» программного обеспечения подходит к концу?