Pull to refresh

Comments 848

Переходи на Linux, в частности я работаю на xUbuntu 20.04. Там намного экономней расходуются ресурсы. Проблему, что вы описываете не так ощущается. На простеньком целерончике данная система работает вероятно быстрее и отзывчивее, чем Винда на мощном железе с внешней видеокартой!

Вполне проявляется, достаточно попробовать собрать любой опенсоурс проект, он тут же потянет к себе миллиарды таких же опенсорсных библиотек. Из которых многие нужны только ради одной двух функций.

А та же винда 10 у меня работает на 12 летнем деле и ей нормально )

Зачем собрать опенсорс проект, если все можно поставить из готовых пакетов?

"он тут же потянет к себе миллиарды таких же опенсорсных библиотек" давайте на примере разберем, что именно вы собираете, и что у вас там подтягиватся под Linux?

А в готовом пакете бинарники, простите, собраны из чего? Не из такого же сонма инклюдов, на уровне исходников, а в скомпилированном виде всё равно тянущие зависимости от внешних бинарников от прочих библиотек? И всё это прыгает по экспоненте сall-ов. Если бы не SSD, доступная оперативка, и аппаратные инструкции в процессорах и их многопоточность, работа компьютеров под управлением любой современной ОС была бы печальным зрелищем.

По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужна.

На других системах тот же ICU системный так просто не заиспользуешь, и люди тянут свой, а это 30 МиБ только ресурсов (можно собрать урезанные для части локалей, но всё же), не считая мегабайтов самого кода. Потом curl (полмегабайта), openssl (более мегабайта), libpng и прочие аналогичные, zlib, OpenAL...

И ведь всё это не будешь самостоятельно писать (и лучше и не надо, без того же ICU почти наверняка локализация будет неправильной).

По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужна.

И сразу получаем DLL Hell в полный рост.

DLL hell — это всё же windows-специфичная проблема. Ад зависимостей может существовать и в linux'е, но для библиотек как правило всё хорошо. Да и разные мажорные версии утилит обычно могут быть установлены одновременно (тот же python).

для библиотек как правило всё хорошо

2 разные версии openssl, или libjpeg без танцев с бубном я бы не ставил.

Прямо сейчас:
dev-libs/openssl-1.1.1o - для современных приложений
dev-libs/openssl-compat-1.0.2u-r2 для старья. после окончательного перехода старья на новые либы (или выпиливания оного в пользу более нового функционального аналога) compat версия с очередным обновлением будет выпилена из системы. C libjpeg чуть иначе, но в целом ровно то же самое.
Установка штатная, танцев с бубном не наблюдается, обновление централизованное и штатное. Посчитаем сколько версий libjpeg в венде, проследим как, когда и чем они обновляются?

А зачем сравнивать с виндой? Что будет, если libbuka захочет новую SSL, libzuka — старую, и потребуется слинковать приложение с обеими?

DLL hell — это всё же windows-специфичная проблема

Только из-за аббревиатуры DLL, а не из-за принципа работы.

не нужно далеко ходить, посмотрите на NPM и Composer зависимости любого сайта.

Раньше из всего JS было достаточно JQuery, а сейчас ? npm папка запросто может достигать гигабайтов, а потом от слишком большого количества файлов глючить и падать сборщик, прекрасно.

По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужна
Ну да, если бы…

Скажите это Каноникал, которая везде продвигает Snap

Если вам не нравится Snap. Дело буквально двух команд.

Вот статья.

https://losst.ru/kak-udalit-snap-paket

Лично я сам удаляю на слабых машинах.

В snap насамом деле есть и плюсы и минусы. С одной стороны это контейнеризация, примерно как в docker. С другой стороны большее потребление ресурсов в совокупности с накладными расходами.

Самое главное, что это как опция, хочешь пользушься, хочешь отключаешь.

Ну как сказать — опция. В современном гуи убунты это основной способ установки приложений. Конечно, никто не запрещает написать apt install, но встроенный менеджер приложений устанавливает именно через snap

Ну а что разработчики должны, вместо того чтобы использовать, например, libpng, писать свою собственную альтернативу этой библиотеки и юзать её? Так проблему это тоже не решит, просто вместо libpng будет свой велосипед.

Только у автора скорее проблема с bloated приложениями на фреймворках типа Electron, а не из-за dll'ок. Так-то это нормально использовать для определённой функции какую-то библиотеку, реализующую конкретную функцию.

Хе-хе, PNG стандарт, пишите сколько хотите реализаций, а вот этот libpng для ленивых. Что, не хотите писать? Так может и PNG этот не особо нужен? Векторная графика покрасивше будет. Хотя нет, ASCII графика ещё лучше! И проще! И поддерживать не надо! Хотя нет, семисегментный индикатор куда больше полезной информации показывает! Зачем усложнять когда можно упростить?

Про PNG как раз случай был. Надо по png-картинке было понять её размер, да ещё всё мультиплатформенно сделать. Разработчик начал было искать библиотеки для парсинга PNG (ImageMagick отлично справляется с задачей), но оказалось - что по стандарту - надо прочитать несколько байтиков из заголовка файла.

Вот что лучше - тянуть огромную библиотеку, следить за ней, обновлять, или написать свой велосипед на 3 строчки кода?

Вот что лучше

Ну, если речь шла исключительно о png, никакие другие форматы обрабатывать не потребуется никогда в жизни, и ничего кроме размера этой пнгшки никогда не понадобится — то выбор очевиден.
Кто даст такие гарантии?


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


А, тем временем, в соседнем отделе другой такой же гений пишет в соседний модуль того же приложения свою реализацию ресайзера с самописными вариациями бикубического фильтра и lancroz. На чистом lua.

Кто даст такие гарантии

А кто мешает затащить либу потом, когда (если) эти потребности реально появятся?

Никто.
И будет в итоге развесистая петрушка из либы для апскейла, либы для даунскейла, либы для загрузки/сохранения (этот не слишком оптимистичен, не? одной же хватит на все случаи жизни? ладно, возьмем по одной на формат) и кучка костылей для жонглирования байтами.


Потому что задача никогда не появляется одна, но если кушайц слона по слишком маленьким частям, то выйдет monkey patching в виде годовых колец.
И когда дойдет, что надо было сразу прикручивать imagemack — придется рефакторить вообще все.

Ну, если речь шла исключительно о png, никакие другие форматы обрабатывать не потребуется никогда в жизни, и ничего кроме размера этой пнгшки никогда не понадобится — то выбор очевиден.

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

А, тем временем, в соседнем отделе другой такой же гений пишет в соседний модуль того же приложения свою реализацию ресайзера с самописными вариациями

Было дело, был у меня алгоритм SuperOboyeUlutshatel, который пытался убрать шакаленные артефакты джпега (зная, что он использует квадраты 8x8 и обрабатывая только эти участки). Хотя это больше по фану было и не продакшен, просто вспомнилось в рамках обсуждения.

Ну, про сверхузкоспециализированный случай, когда ничего никуда никогда не растет и не дорабатывается, каджит, собственно, там же и написал.
Но такой случай — пекулярный, из выборки такие выбрасываются для повышения репрезентативности.
Это значит, что он не подходит ни как мерило, ни даже как пример.
Но узнать о таком курьезе забавно и поучительно, спасибо, что поделились.


Хотя это больше по фану было и не продакшен

Для себя исследовать какую-то область — всегда полезно ) Даже если получившееся решение непрактично, оно дает опыт.

lua разный бывает. На 4-ом пишет, или на 5-ом, который до сих пор не закончен?

А еще с jit'ом или без.
Но simd все равно быстрее в разы, а знание математики помогает дополнительно оптимизировать задачу. Одиночке будет крайне сложно переплюнуть труд сотен.
Особенно если настолько некопенгаен, что пилит свой велосипед, вместо того, чтобы взять готовую и отлаженную библиотеку, не имея против того серьезных возражений.

Миллиарды опенсорс библиотек это хорошо. Главное чтобы LTO работало.


Пусть в мире будет одна Идеальная Быстрая сортировка, Идеальный способ открыть файл, Идеальный способ отправить емейл через SMTP. И пусть этот идеальный способ экспортируется и распространяется как библиотека. Это приводит к тысячам библиотек? Да, и что плохого? Это неприятие велосипедов возведенное в абсолют. Это прекрасное будущее где ты создаешь только код который никто до тебя в мире ещё не написал, а потом им пользуются миллионы других разработчиков по всему миру.


Немного утопично, но это куда ближе к хорошему чем "если это реализовывать меньше 80 часов то напишем свой велосипед".

Для этого в опенсорсе должна быть модерация и голосование, какой пакет принять за основной. А потом основная библиотека перестаёт поддерживаться, появляются форки, и… ну вы поняли, было 11 стандартов, решили стандартизировать их все - теперь 12 стандартов.

А ещё основные библиотеки точно так же жиреют со временем в попытках сохранить обратную совместимость и вообще в экономии времени на оптимизацию, так что легковесные аналоги появляются и есть буквально для всего. И это не плохо, это, своего рода, конкуренция (хотя в опенсорсе… конкуренция?), но ни о каком "едином стандарте" речи быть не может.

А ещё мейнтейнерское "я так вижу, хотите свою фичу в моём пакете - делайте форк".

А ещё… продолжать можно долго.

Для этого в опенсорсе должна быть модерация и голосование, какой пакет принять за основной. 

И тут же возникает проблема на уровне, где система для опенсорса с голосованием за форки порождает альтернативную площадку с «легковесной» подачей и быстрой доставкой фич без голосования. И вот у нас и тут становится минимум 2 стандарта «правильной» разработки опенсорса.

Идеальная Быстрая сортировка?

У вас может быть задача отсортировать данные, которые помещаются в память, а может быть задача про данные, которые не помещаются в память, надо тогда работать с диском или ещё с каким-то хранилищем. И вот у нас уже две Идеальные Быстрые сортировки.

Данные которые не помещаются в паять не надо сортировать Быстрой, для этого есть другие способы. Так что это не проблема, да — кубики лего должны быть одинаковыми и хорошо сделанными.

Есть 100500 других особенностей. Где-то крайне дорог или невозможен обмен местами элементов. Где-то — очень дорогое сравнение, нельзя терять его результат, а конкретная реализация Идеальной Быстрой Сортировки проверяет только на <, а не на <=>. Где-то нужно уметь сортировать при наличии несравнимых элементов, несмотря на формальный запрет таковых (привет, float), где-то нет.
Говорить про пригодную для 99% случаев версию — ещё можно. Для всегда — нельзя.

Быстрая сортировка без обмена элементов существовать не может — это заложенно в её основе. Сравнение с несравнимых элементов — это так же не быстрая сортировка а видимо что-то типа NullQuickSort которая сначала выполняет некоторую логику (сдвигает нуллы куда-то), а потом уже сортирует оставшуюся часть нашей Идеальной Быстрой Сортировкой.


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

> Быстрая сортировка без обмена элементов существовать не может — это заложенно в её основе.

Любая сортировка может быть сделана без обмена созданием массива индексов/указателей и перестановкой этих указателей вместо самих элементов. И это не зависит от того, она «быстрая», пузырёк или что-то другое.

> Сравнение с несравнимых элементов — это так же не быстрая сортировка а видимо что-то типа NullQuickSort

Возьмите массив float'ов, заполните случайными значениями и растыкайте среди них, например, процентов 10 NaNʼов. Дальше отсортируйте разными алгоритмами и посмотрите на результат. Получаются весьма забавные зависимости от подхода. Некоторые реализации вообще крэшатся на этом, но все известные мне сортировки из стандартных библиотек C и C++ выживают.
А вот Rust просто откажется такое компилировать — трейт floatʼа не помечен как допускающий total order.

Для разминки ума, кому интересно, может подумать об отвлеченной и более материальной задаче: сколько человечеству нужно узлов. Их ведь очень, очень много. И я, как простой "пользователь веревки", имею простые задачи вроде "привязать веревку к столбу прочно" или "привязать веревку к столбу и обеспечить сильный натяг". Но узлов - дохрена, и я так понимаю, что каждый из них иногда по своему хорош.

Да их полторы сотни, более-менее отличающихся друг от друга по свойствам. Всё остальное либо для красоты, либо просто варианты без принципиальной разницы

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

Наверное, если я подумаю еще - то еще 3-4 потребности в узлах напишу, а про остальные даже и вообразить не смогу, зачем они нужны.

Ой вы навыдумывали. Узел вам нужен один - шнурки завязать.

Для шнурков есть как минимум два десятка вариантов узлов https://www.fieggen.com/shoelace/knots.htm. Правда половина из них — это просто разные этапы или способы вязки одного и того же узла, но всё же :)


Рекомендую проверить, не завязываете ли вы случайно «бабьим» узлом, а то примерно 50% страдают от того, что шнурки развязываются. А Ian’s Secure вариант не только красив, но и вообще никогда не развязывается и не тянется, даже на скользких шнурках.

Всю жизнь завязываю одним узлом, хоть в темноте за 2 секунды завязываю, а как они там называются мне без разницы. А у вас в голове много мусора, на простые действия десяток вариантов, и никаких действий в итоге, вся энергия в сотрясание и нагрев воздуха идёт.

Это у симфонического оркестра вся энергия в сотрясание воздуха идёт. А от моих комментариев максимум электромагнитные волны.


Рад, что вы так быстро завязываете шнурки и даже в темноте, но как это характеризует содержимое вашей головы — даже предположить не берусь.

Ну так будьте проще. У меня всё просто, у вас в том же месте какие-то сложности. Я помню как меня родители учили шнурки завязывать, потом сам друга научил, и вас могу научить. А ещё вы удивитесь сколько народу на велике не умеет ездить. Только я один с десяток людей научил никому ничего не навязывая. И всё это потому что объясняю просто, а не ссылками швыряю и десятки вариантов предлагаю.

Почти все на свете умеют завязывать шнурки. Это не какой-то повод для гордости.


Но, вы не поверите, люди иногда делают вещи сверх минимально необходимого. Да-да, в случае с узлами, не только десять видов узлов для шнурков, ещё и разные шнуровки придумывают и даже, о ужас для любителей простоты, декоративные узлы плетут. Могли бы быть проще, все поверхности плоские, углы прямые, узел один. Но нет, придумывают себе какие-то сложности.

У вас может и все просто, но есть вот ужасные скользские жесткие шнурки которые если обычным способом завязывать развяжутся спустя пару км хотьбы, если не раньше.

Ну и? У меня то никогда не было скользких (: У вас тоже врядли, нагуглили небось какую-то дурость. Я себе скользкими шнурками скорее пальцы порежу чем завяжу их, и избавлюсь незамедлительно от такого счастья.

Видимо вам очень повезло, я несколько раз такие кроссовки покупал, а менять шнурки — это париться надо.

Это значит только то что вам продали обувь без шнурков, а на место шнурков какую-то леску натянули под видом шнурков, и вы зачем-то мучаетесь полумерами. Я бывает в магазине лечу людей, покупающих масло, мол это такое название продукта, "Масло 60%", если перевернуть и состав посмотреть то там будет уже молочный продукт или ещё какая гадость, а 60% масла просто не существует.

Оффтопик конечно, но качество обуви легко определить по шнуркам. Если производитель сэкономил на шнурках - не нужно это брать.

Если посмотреть контекст, то как раз ровно в этом и суть: нам, не-специалистам, нужен только один узел, а вообще их придумали несколько десятков для разных нужд. Аналогично и с алгоритмами: нам достаточно одного условного QuickSort, а вообще - совсем не факт.

Сортировки нужно две - устойчивая и не устойчивая, разумеется это можно добавить аргументом по умолчанию в библиотечную сортировку, тогда да, будет всего одна, и не сильно разбирающийся будет всегда устойчивую пользовать, как более универсальную но и более медленную, а профи поднастроит под свои данные. И старый код не ляснется от внезапно возникшего аргумента функции. Но появится новая проблема - этих аргументов по умолчанию возникнет 100500 на все случаи жизни. Хоть это и не такая существенная проблема но всё же возникнет в виде комбинаторного взрыва числа возможных состояний библиотечной функции.

Сортировки нужно две - устойчивая и не устойчивая

Умножьте на 2 для начала;). Массивы и связанные списки сортируются по разному.

Ну тогда нужна некая абстрактная перестановка местами двух элементов и абстрактное сравнение этих двух элементов в некоей абстрактной структуре данных. Каждой из этих абстракций автор библиотеки может докинуть аргументы по умолчанию. Так и совместимость с не абстрактным не потеряется, если первая реализация только для массивов, и чуть поправить можно. Но суть в том что всё это должно быть реализовано автором первоначального алгоритма, а не кем-нибудь относледовано и переделано. Т.е. Первоначальная задумка должна сохраняться, и при необходимости дополняться.

Это прекрасное будущее где ты создаешь только код который никто до тебя в мире ещё не написал

Да, это прекрасно.


а потом им пользуются миллионы других разработчиков по всему миру.

А это — нет.

а потом им пользуются миллионы других разработчиков по всему миру.

А это — нет.

Эм, почему?

Сразу ответственность какая-то, хотят что-то. Да ну нафиг, я попенсорс по фану пишу.

Ну вот, опять докопался до формализма необходимости/достаточности :(

А потом случится какая-то ерунда в твоей жизни и ты запилишь какой-нить баннер или зловред в либу и миллионы разработчиков от этого подгорят.

Хм, убедили. К миллионам зависящих разработчиков действительно стоит стремиться.

А потом библиотека, подтягивающая другие библиотеки вместе с другой многоколенной библиотекой подтягиваются в сто пятую библиотеку. И вот уже экспоненциальный рост пожирания ресурсов обгоняет технологический прогресс, а еще чуть позже на неописуемой скорости врезается своей огромной массой в нерушимый потолок физических ограничений. Все, закон Мура не действует, производители больше не могут наращивать производительность на единицу процессорной площади. И придётся все переписывать заново, зато не изобретали велосипед

У вас от библиотек производительность будет лучше, а не хуже. Попробуйте собрать любое раст приложение — там в реальной аппке на пару тыщ строк вероятон будет пара сотен транзитивных зависимостей. Попробуйте теперь сказать, что код получился медленным и раст тормозит.

Для удаленки взял свой старый медиацентр. Что бы не занимать ноутбук. Athlon x4 640. Добил до 8гб + ssd. Поставил, windows 10 и lubuntu lts последнюю. Все же lubuntu побыстрее и меньший жор ОЗУ. И не так часто вижу в top'e загрузку проца под 100%. Серфинг одинаков на обоих осях.

Я бы разбил проблему на части

Разделяемые библиотеки

Разделяемые библиотеки как раз и созданы для того чтобы избежать дублицирования кода, поэтому ничего плохого в их использовании нет. Но для того чтобы этот потенциал был реализован более полно, нужно чтобы (1) их лицензия позволяла программам в системе их использование и (2) программы были собраны именно с установленными в системе версиями библиотек, а не требовали другие версии. В случае дистрибутивов Линукса, казалось бы, эти условия выполняются чаще и лучше.

Но это преимущество имеет, правда, и свои негативные стороны. Например, когда в дистрибутиве десятки тысяч программных пакетов, обновление программы имеющей сотни зависимостей становится достаточно сложным, особенно для программ с несвободной лицензией. И чтобы решить эту проблему придумали всякие snap и flatpak, что полностью нивелирует преимущества разделяемых библиотек, то есть как раз в области, в которой дистрибутивы Линукс могут проявить себя лучше.

Умножение системных процессов.

В системах на основе Линукс, как и в Виндосе множатся и плодятся системные процессы. Причём почему-то с каждой новой версией они становятся всё более прожорливыми, пожирая память и процессор. Я уже смирился, что даже в Линуксе какой-то демон, ответственный за вывод звука иногда может есть процессорное время даже когда никакого звука в системе не проигрывается. Конечно, это пока это не дошло до крайностей, описанных в статье, но надо признать, тенденция в Линуксе такая же как и в Виндос.

Раздутые приложения-монстры

Некоторые приложения со временем растут, пока не превращаются в монстров которые содержат в себе ещё одну собственную операционную систему (иногда две или больше). Кажется что в конце-концов они должны погибнуть под тоннами собственного неподдерживаемого кода. Но они почему-то никак не погибают. Яркий пример - браузеры.

Приложения на электроне

Эта беда проникла как в Виндос, так и в Линукс и здесь Линукс ничем не отличается от Виндос. Это просто фабрика монстров.

Список можно продолжать. Но ясно что беда затронула и Виндос и Линукс.

Господин не прав. Днесь пытался найти на ноутбук HP6110 с 32-разрядным процессором вменяемое ПО, при наличии 2-х гигов памяти. К удивлению своему - НИЧЕГО! Ничего, что бы вменяемо работало с Интернетом. Даже маленький Alpine - и тот уже не торт.

Пробовал множество линуксов.

Однако старая версия Runtu движется быстро и хорошо - прекрасна во всех отношениях - но не открывает современные сайты, и поэтому бесполезна...

при наличии 2-х гигов памяти

Мне кажется тут дело немножко в другом.

Попробуйте firefox + umatrix.

Вы про Alpine, а я про хUbuntu. У xUbuntu сообщество в сотни раз больше.

"Пробовал множество линуксов." Зачем пробовать, поставьте один вроде xUbuntu, и работайте. Хватит пробовать. Я вот запустил и работаю, уже лет 10

А чем Вам ОСь поможет то? Проблема в том, что сами сайты состоят из говнокода чуть более чем полностью и одна страница "весит" сотню мегабайт. Это на стороне сервера оптимизировать надо, иначе никак.

Потому что ОС, это основа всего. Если сама ОС вроде Виндовс, жрет памяти немеряно, то что останется на все остальное?

В Linux есть дистрибутивы например xUbuntu, которые очень легкие, и работают одинакого быстро и на простом железе и на хорошем.

Еще раз. Если с сервера в браузер приезжает жирный js-код, который выполняется на вашем процессоре, то не очень принципиально, сколько ест система, обычно это единицы процентов ресурсов процессора.

XUbuntu жрёт 600-1000 МБ просто загрузившись, для хоть какой-то работы ей надо 2 ГБ. WinNT Workstation запускалась и работала на 64 МБ, Win2K на 128, WinXP на 256. Ну, ОК, это не совсем честно, потому что NT/2K/XP были 32-битные, банально для CALL по полному адресу надо адрес 64-битный, но разница даже с WinXP в 8 раз. Справедливости ради - рабочая станция на Linux всё-таки больше условных 1-2 ГБ "сразу после загрузки" не съедает (тайловые ВМ - 0,5, голый KDE/xfce - 0,7-0,9, гном с навесами 1,2), а Win10/11 - запросто 3-4.
Ну и, да, согласен с @hyperwolf- основные ресурсы съедаются не голой машиной, а приложениями на ней. Браузер, IDEA, VSCode и куча других приложений съедают примерно одинаково (много) почти независимо от ОС. Да вот пример прямо в углу монитора у меня: Jetbrains Toolbox. Ёлы-палы, это же приложеньице для загрузки и обновления IDE. Оно съедает 200-500 МБ оперативной памяти. Штоа? Как это? Зачем? Ладно, у меня 48 ГБ в одной машине и 128 ГБ в другой и я почти смирился с тулбоксом, но всё-таки, я всё еще помню время, когда на сервере СУБД (СУБД, Карл!) в моей организации было меньше памяти, чем жрёт эта иконка в трее (то, что у тулбокса нет CLI раздражает больше).

Win10/11 — запросто 3-4

Ну, не совсем запросто


(впрочем, работать на этом компьютере всё равно немножко грустно)

Продукты JetBrains невероятно прожорливы. Ещё пару-тройку лет назад пересадили компанию на Rider при моем же участии. А на днях мне пришлось работать на докрымском ноуте. Райдер не смог. Он сожрал весь проц, разогрел его и дико тормозил на простом вводе текста. Запустил VisualStudio и на том же проекте смог комфортно работать. Был удивлен и много думал о том, стоит ли продлять лицензии.

Rider — молодец, умеет в многопоточность. На мощных системах он работает гораздо шустрее студии.

Я ненастоящий программер, но мне кажется — что у JB наиболее адекватная автоподстановка, уровня «я бы сам почти так думал подставить»

Так было. Мы сидели на решарпере, потом на райдере. Но время идёт, vs2022 просто дописывает всю строку кода за меня, невероятные подстановки. MS не стоит на месте, в отличие от. То, что предлагает райдер, в половине случаев приходится удалять. Ну и глюки эти вечные, при этом трудновоспроизводимые.

xUbuntu есть 400 мегабайт после старта!

"600-1000 МБ" Откуда вы такие цифры получили? И где вы нашли WinNT Workstation? Давайте с Windows 10 сравним, или с Windows 11.

"WinNT Workstation" - операционка которой уже больше 10 лет не существует, и на любом железе современном вы даже не запустите.

В таком случае нужен дистр минимально потребляющий ОЗУ. Что бы по серфинг оставить максимальное возможное количество памяти из 2-ух гигов.

У меня mint (xfce) вполне норм работает на eeePC c 2 Gb и 900 МГц "целероне", тянет офис и браузер, даже ютубчик в низком качестве при желании можно посмотреть. Разумеется я им не пользуюсь в повседневной практике, нет смысла никакого. Но как читалка, компактная печатная машинка, аудиоплеер, вполне норм.

Вот если все это поставить на нормальный комп! Сколько экономии в ресурсах произойдет, по сравнению с перегруженными системами. У меня стоит xUbuntu с xfce, все летает, никаких тормозов. Софт по сути одинаков везде. На xUbuntu стоят все те же программы, только ресурсов больше свободных.

Пробовал множество линуксов.

А какой был графический интерфейс? Я как-то разбирался, как ускорить работу Linux на старом компьютере, и обнаружил, что очень много ресурсов забирал на себя tracker, программа для индексации файлов. Причём вроде он работал даже если я использовал другое окружение рабочего стола. То есть, по сути компьютер работал бы быстрее, если бы я при установке просто убрал галочку напротив GNOME. Но, повторюсь, это касалось довольно старого компьютера, по логике вещей tracker нужен для того, чтобы ускорить работу (чтобы поиск был быстрее).

А ЗАЧЕМ на это старое говно пытаться что-то натянуть, как сову на глобус?

2005 год, простой Пентиум, да еще и М. Какие невероятные достоинства имеет конкретно этот ноут, чтобы пытаться им пользоваться? Его даже компактным не назвать, он весит почти ТРИ КИЛО, с отвратной TN-матрицей нижайшего разрешения. Его клавиатура тоже не представляет из себя — ничего особенного.

Практически по цене самовывоза можно найти ноут на Core2Duo и он будет отлично справляться с функциями пишушей машинки.

Современный ноут будет где-то 50х быстрее по процу, 100х быстрее по видяхе, в бесконечность раз быстрее/экономичнее по всяким видеокодекам, в 100х быстрее чтение/запись по диску (а задержки в 10000х быстрее). Конечно современный софт будет тормозить, ведь никто не будет оптимизировать быстрее пусть будет 1/10 секунды на операцию на современном железе, что превратится на старом в 10 секунд :)

То есть — ничего удивительного в том, что оно все унылое и еле шевелится :)

Но ведь девяносто восьмая винда на нём летала бы!

Так пускай запускает на нем 98ю винду :)

Мне кажется в каком-то месте маркетолог у нас сменил и программиста и инженера поэтому размеры приложений выросли в сотни раз когда калькулятор может весить сто мегабайт, а игра больше ста гигабайт. А все потому что медленный софт подгоняет железо и наоборот быстрое железо позволяет забить на оптимизацию, все ради того чтобы продавать, продавать и продавать без учёта ресурсов. Одно потребление так же ведет индустрию в тупик.

Для эксперимента советую antix. Возможно взлетит.

Надо просто выкинуть это древнее говно, а не пытаться заниматься с ним роскомпозором. Ноут на Core2Duo можно купить тысяч за 5, который будет на порядки быстрее этого мрака мрачного на пне-м

Возможно автору нравится копаться в старом железе. И пытаться их восстановить для текущих задач. Почему нет:)

Тогда бы он знал — чего ждать от этой рухляди и не жаловался бы тут ))

Не такая уж и рухлядь. Смотрите на производительность одного ядра.

Не обратил внимание просто смотрел массовый проц core2duo. Производительность конечно всратенькая:)

Это сравнение чего с чем? :)

Так E5500 — это же и есть корка, да ещё и десктопная.

Но я то сравнивал ноут на старом пне, и к2д
Почитайте камент и посмотрите из чего тот ноут сделан
При чем тут райзен?
Я без понятия) Спросил его о том же)

Перепутал я. Просто взял массовый проц core2duo. А нужно срравеивать с pentium m.

Говорили о проце pentium m. Но если сравнивать с десктопным e5500 производительность вполне себе. Но для серфинга будет боль.

Надо сравнивать сравнимое. Средненький ноут на пентиум-м и средний ноут на к2д

Посыл то был в том, чтобы выкинуть эту рухлядь, дорогую как память — и купить б/у, но на к2д. Там совсем другая архитектура и она на порядки быстрее того старого пня, а всех делов — 5к деревянных

А лучше конечно брать нормальный десятилетний ноут, если совсем уж не хватает на нормальный трёхлетний. Причём брать из топовой линейки, потому что старье всё одинаково стоит. Какой-нибудь x220 — он конечно уже напрягает (даже с 16гб памяти и ссд) по сравнению с современными ноутбуками, но для того, кому пентиум м хорош — будет просто бомба :)

Потому я выбрал х260, 16 памяти, ссд — очень приятственно работается. Если чисто серфинг, то 11 часов выдерживает, а еще есть увеличенный внешний акк в запасе. Еще и матрицу воткнул в него 1080

х220-40 довольно унылы, там заметно устаревшее железо, а 270 и выше — уже профанация, откровенно неудачные модели, сильно перегревающиеся и вообще не оптимальны. Убили такое приятное семейство, закачивая в него мощности больше, чем нужно.

А я уже думаю отринуть любовь к старью и взять что-нибудь типа Asus Zenbook 13 OLED на 6800…

Вопрос целесообразности, мне не нужен мощный ноут.

Для фотошопа у меня десктоп есть и с покупкой ноута я его почти перестал включать. Разве что в пубг погоняться, развеяться

Десктоп остался в далёкой России, кочевая жизнь требует мощности и лёгкости.

Ну, у меня пока так не получается…

Не соглашусь насчёт экономного расходования ресурсов. Отличие Linux только в том, что там принято ставить зависимости общими пакетами, а не тащить их каждый раз с собой. Ну да, небольшая экономия места на диске, но память всё так же будет забиваться.


Также добавлю тенденцию пихать всё в snap и в docker.

Предлагаю сравнить скрины по количеству забитой и свободной памяти? На реальных примерах.

На примерах чего именно?


Вообще, меня больше напрягает Telegram, который аж больше 1 гига жрёт.

Не знаю, что за дистрибутив а у меня вот так. И это xUbuntu. Сама ОС, практически ничего не ест, и отзывы мгновенные. Причем куча свободной памяти, и работает на Целероне

.

Правильно ли я понял, что на экране мы видим 4 ядра и 8 гигов оперативы, как доказательство того, что «этот линукс летает даже на простеньком целерончике»?

Все верно. Легкий дистрибутив и куча свободных ресурсов. Не перегруженность графиков. Вот основа быстрой и оптимальной системы.

Я могу в ответ скрин со своего компа скинуть. Там тоже будет куча свободных ресурсов и не перегруженность графиков. Получится, что Windows 10 — офигенно лёгкий дистрибутив.

У меня i7, 32 оперативы и 2 ssd.На одном стоит минт с синнамоном, на втором в дуалбуте вин 10. Так вот, вин 10 по сравнению с линухом тормозит. Тормозит безбожно. После загрузки в нее минут 5 надо погулять, чтобы она там что-то себе пошуршала и начала, наконец, хоть как-то работать. Но даже после такой паузы работать в винде гораздо менее комфортно. Я даже не могу сказать что конкретно не так, просто какие-то раздражающие микрофризы, которые в целом создают ощущение, что "все тормозит" по сравнению с линухом. Например, запустил простую программу, а она не мгновенно запустилась, а через несколько секунд и т.д, Железо, я напоминаю, одно и тоже и совсем не слабое.

Попробуйте отключить антивирус.

Я не использую антивирусное ПО.

Если вы ставили Windows 10, и не тюнинговали систему после установки, то используете :)
Снести винду и поставить все заново. Стандартный совет для таких вещей. Можно даже не обычную винду, а LTSC — оно и места меньше займет, и куче всяких украшалок крутить в фоне не будет

Но чисто отклик интерфейса — у линукс всегда будет лучше. Винда и Макос выглядят тормознутыми часто именно из-за микро-фризов интерфейса, а не самих программ.
Винда и Макос выглядят тормознутыми часто именно из-за микро-фризов интерфейса, а не самих программ.

Только наоборот, это в линуксе постоянные микрофризы :)

Мой опыт показывает обратное. Отзывчивость интерфейса у линухов замечательная, винда и мсакось подлагивают. К этому привыкаешь, пока не пересаживаешься за линь и замечаешь разницу

Ну вот, а мой опыт говорит обратное. Хотя может это как обычно был неправильный линукс (убунта). И помню эпический баттл каноникал за оптимизацию гнома, чтобы не было статтера хотя бы на быстрых машинах и как этому сопротивлялись мейнтейнеры, которым всё было норм, а тут пришёл какой-то корпорат и начал вливать непонятные патчи с оптимизациями.

Тоже убунта. Все чуть быстрее, отрисовка окошек, элементов интерфейса, тп

Ну хз, может быть моей 1080ti сильно нехватало (фак нвидия, все дела), но даже при анимации стартового меню были затыки. А на винду вернулся и прям ощущение, как при отключении двойной буферизации в старых играх — лёгкая резиновость пропадает.

зависит от настроек ядра:


Preemptible kernel (low-latency desktop)
Voluntary kernel preemption (desktop)
No forced preemption (server)

а еще, возможно, от оконного менеджера/композера и видеодрайверов.

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

1080ti

Не могу ничего сказать, кроме «УМВР», что на ещё более старой 980, что на встройке у кастрированного U-шного скайлейка, что у какого-то 11-летнего core 2 (но я его последний раз года три назад включал).


Но да, не убунта и кеды вместо гнома.

у нас десктоп на убунте/минте тормозит больше, чем на вин10. Астра на дебиане и флай дм - летает на том же железе

Я от гнома отказался в самом начале перехода на linux. Мне нравится lxqt. Жручесть меньше. Скорость выше.

Согласен. Жирный плюс, что можно поставить любую DE.

Микрофризы в Linux у тех, кто его запускается чтобы посмотреть через виртуальную машину из другой Операционной системы :)

Но даже если так. поставьте в виртулке xUbuntu. Даже в виртуалке думаю фризов вы не заметите. Что говорить, про реальную установку, космос!

Если 7ка поддерживает то железо, можно для интереса сравнить и её :)

Ну а так, ниже правильно написали, если нужна 10ка, лучше взять LTSC — по дефолту там меньше всякого ненужного запущено. У винды ещё с XP была замечена тенденция по дефолту загружать разную блотварь, включая некоторые службы, но оно всё отключаемо.

У меня i7, 32 оперативы и 2 ssd

На одном стоит минт с синнамоном, на втором в дуалбуте вин 10. Так вот, вин 10 по сравнению с линухом тормозит. Тормозит безбожно. После загрузки в нее минут 5 надо погулять, чтобы она там что-то себе пошуршала и начала, наконец, хоть как-то работать. 

У вас какой-то неправильный ssd видимо, или может ОЗУ. Тоже i7, тоже 2ssd, и тоже 32 гига озу. 17 секунд и уже можно пользоваться. Где вы 5 минут умудрились найти? У меня даже виртуальная машина образ которой на HDD стоит, грузится минуты 2.

У меня даже на старом, не самом быстром SSD всё летало - грузилось полминуты, а потому сразу в бой. 5 минут это только на старых HDD винда могла себя так вести.

Ничего подобно не наблюдается даже близко и на Win10 и на Win 11, конфигурация очень похожа, всё летает

А вам есть с чем сравнивать? А то может то, что для вас "летает", для меня "тормозит"? :)


Как говорится, если вы никогда не пробовали другие туфли, то наши туфли самые лучшие (с)

Я на техническом ресурсе пишу, а не на пикабу, наверно понимаю о чём говорю

Там ещё аптайм чуть больше минуты — может, не всё прогрузилось :)

Не, ну если я вместо KDE поставлю Xfce4, памяти тоже побольше свободной будет.
Но смысл?

Смысл примерно тот о чем пишут в статье. Компактный дистрибутив, компактное ПО, вот один из идеальных примеров, того как должен выглядеть софт, и прекрасно работать даже на слабом железе. Не потреблять излишнее количество ресурсов, память ГПУ и т.д.

Ради интереса перегрузился в Xfce. Потребление оперативной памяти снизилось на полгига, потребление видеопамяти же, наоборот, выросло на полгига. Интересно, почему?

Скрин пришлите, из приложения nvtop? У меня xfce не расходует видеопамяти совсем. Там будет видно какие процессы едят видеопамять и сколько.

Какой-то странный скриншот у вас, хотя бы один процесс Xorg обязательно должен быть. Это случайно не ноутбук со встройкой и оптимусом каким-нибудь?

Outlook express из Windows 98 вполне закрывала все задачи электронной почты. Надо будет поставить на виртуалку, и проверить, насколько она актуальна сейчас…
Угу, кроме безопасности.

SSL/TLS.

Без шифрования ничего нынче не работает, хотя оно и нахрен не сдалось, ибо кому надо тевсе равно имеют доступ ко всему что передается и хранится.

Как раз к передается доступа нет.

Давайте я вам пример приведу, из той же категории. Claws Mail - легковесный почтовик. Не требует ресурсы. До сих пор поддерживается и обновляется, работает под Linux, и не только.

И как вы на нем будете открывать динамические письма с кнопками и анимацией?

Вообще, выполнение скриптов в почте — не очень хорошо для безопасности…
В браузере — песочница

Кнопкой "Send to Trash", ибо ничего полезного в таких письмах по определению не приходит :-)


А вообще, он умеет в браузере HTML-письма открывать, что зачастую куда удобнее (и безопаснее), чем в почтовике.

А вы уверены, что браузер поддерживает динамические письма?

А что в них может присутствовать, кроме тройки HTML+CSS+JS? Вопрос без подвоха, я действительно исходил из того, что тело письма - это всегда не более чем веб-страница.

https://developers.google.com/gmail/ampemail/supported-platforms

Ну и, если уж на то пошло, кто может быть уверен, что почтовый клиент будет поддерживать ту или иную проприетарную технологию (если, конечно, это не клиент от владельцев технологии)?

Не туда смотрите, 497М — это только shared mem, а есть ещё resident на 1082М.
И да, Thunderbird — это, по сути, браузер.

А у меня Аутлук. Который не экспресс, а обычный, и более-менее современный, с календариками/планировщиками там всякими, хорошей интеграцией с другим софтом и т.д. Открыто два ящика на 5 гигов писем каждый, жрёт 65 метров памяти, 170 зарезервировано. Работает мгновенно. Старая школа :)

Предлагаю обмениваться не на словах, а прямо скринами с монитором ресурсов из вашей операционной системы, где в целом видно сколько памяти всего, сколько ест операционная система, сколько все остальное вроде Оутлуга. и будем сравнивать.

У меня на компе работает Visual Studio, три мессенджера, три сотни вкладок браузера, две виртуальные машины с убунтами и докер, а, ещё недоигранный Cyberpunk 2077 свёрнутый в фоне лежит. Что вы у меня сравнить сможете?
С точки зрения быстродействия как раз интересуют конкретные приложения. Голая операционная система жрёт несущественно, даже Windows 11. Но как только вы к ней, или к вашей xUbuntu добавите банально браузер, всё сразу поменяется.

"несущественно, даже Windows 11" - это 3 гигабайта, несущественно? или сколько.

Вот xUbuntu ест 400 мегабайт после старта. А дальше навешиваются приложуши. Давайте сравним кто больше ресурсов ест.

Я предлагаю фактами обмениваться!

Вот xUbuntu ест 400 мегабайт после старта. А дальше навешиваются приложуши.

Ну так в Win 11 из той пары-тройки гигабайт, которые она жрёт после старта, минимум половина — тоже необязательный софт. Выключите виджеты, антивирус, визуальные эффекты, всякие фоновые приложения, Teams, OneDrive и прочее барахло, и будет у вас ну не 400 метров, но под гигабайт вы её покромсаете. Больше — тоже можно, но уже ценой функциональности системы.

Я предлагаю фактами обмениваться!

… но показывать вам я это не буду, потому что на это надо время тратить, а я не настолько хочу вас переспорить ;)

Я привёл два скрина от разных "диспетчеров задач" - как раз, с "полновесным" MS Outlook - ну, скромные у него аппетиты... хотя да, пару лет как числится "неподдерживаемым", но... всего пару лет.

Это видимо ошибка какая-то. Наблюдал как память утекает в телеграм в Arch'е. В винде прямо сейчас - давно уже включенный телеграм 28mb занимает

Виндовый диспетчер задач показывает какую-то странную память, по ощущениям сильно далёкую от «реальности». Возможно, лучше смотреть какой-нибудь «рабочий набор» (но не уверен, там всё сложно)

Действительно, посмотрел в Process Hacker. 160Mb при запуске. Сразу пошёл проверять размер exe - 112Mb)

Диспетчер может и что-то не то показывает, но по процентам стабильно после 85% занятой памяти всё начинает тормозить(Диск hdd, 4Гб RAM)

Хотя конечно понятно было что он что-то не так показывает. Память кончалась быстрее, т.е. занято было всегда больше чем сумма занятой памяти которую он показывал, причём ещё до того как приложение подгружало данные из сети. Т.е. например до токо как в той же телеге я нажимал что-либо вообще

Но в линуксе что-то странное с телеграмом, похоже на утечку памяти. Я там просто листал текстовые сообщения и у меня htop всё больше показывал(прям мегабайтами росло)

Так конечно просто если чат с картинками листать то тоже расти будет. Не удивительно что можно хоть до 1Гб догнать. Не знаю будет ли он со временем их сжимать и/или на диск скидывать

Проверил. Полистал огромный чат в том числе с картинками, рядом поставил Process Hacker. Занятая RAM растёт медленно, временами уменшаясь.

Похоже в линуксе таки у него утечка.

При прокрутке чата вполне ожидаемо появляется нагрузка I/O, так что телега вполне хорошо оптимизирована. Немного печально что ей при запуске тоже надо 160Mb

Ну, вот более подробные сведения:

Всё равно, как-то скромнее:

А вы ~~на шкаф~~ залезьте на пару десятков каналов с картинками и видосиками. Он не только памяти нажрётся, но и крашнуться может. ;)

Если хочется узнать, что в действительности использует, надо отобразить Private working set.

Нет, он не включает страницы из свопа. У меня был случай, когда у процесса был слишком низкий приоритет, поэтому казалось, что мало памяти используется, а на самом деле было много, но всё в свопе (при том, что физическая память была свободна).

Да, поэтому надо смотреть на "Private Bytes".

Можно, конечно, но туда, по ходу, и просто memory-mapped files попадут… И вообще, там не обязательно то, что именно записано в своп, а то, что зарезервировалось, но пока не используется.

А вообще всё, что процесс захотел себе зарезервировать (включая shared), отображается в commit size.

Ключевое слово "захотел". Часто бывает, что процесс закоммитил с десяток гигов, а реально пользуется только парой гигов, остальное — нулевые страницы. С другой стороны, в Windows нет overcommit, поэтому да, commit size — хороший способ изменения памяти.

меня больше напрягает Telegram, который аж больше 1 гига жрёт.

Специфика аллокатора в glibc, если верить этому. На других ОС такой проблемы нет.

Интересные, конечно, утечки памяти у телеграма на линуксе, на винде у меня сейчас 80мб private working set и если не смотреть в нём видео, примерно так и будет, ну, может ещё на +100мб разрастётся в процессе (а видео добавляет ещё около 200 на время просмотра). Правда, не официальный клиент, а 64Gram.
> Вообще, меня больше напрягает Telegram, который аж больше 1 гига жрёт.

По которому из показателей?
> cat /proc/16454/status
Name:   telegram-deskto
...
VmHWM:   1109904 kB
VmRSS:    866900 kB
RssAnon:          700264 kB
RssFile:          159744 kB
RssShmem:           6892 kB
...

Как минимум, можно на RssAnon посмотреть.

Как Ваш Telegram смог столько сожрать?!?!

Не Linux, конечно, но:

Оперативки "итого" 8 ГиБ, занято менее трети, запущено 2 браузера (FF и Edge) с парой десятков вкладок в каждом (в одной из них данный комментарий набираю), почтовый клиент (да, Outlook у меня немолод, но он мне нравится больше более новых), WhatsApp, Telegram, Skype (прости, господи), играет Я.Музыка, 1С, встроенный антивирус и ещё куча всякого хлама...

Кажется у нас еще один конкурент Твиттера, хотя по функционалу он не очень далеко ушел от той же аськи. Видимо программисты там создают иллюзию деятельности.

Ну давайте сравним. На 10 летнем десктопе дома win10 сильно меньше кушает. Прекратите верить, что десктопный линукс с гуями - это некое чудо, которое не есть ресурсы.

Это Гном небось 20ГБ отъел? У меня вон KDE Neon с двумя месяцами аптайма гораздо лучше себя чувствует, ресурсы отжирают в основном браузеры и кое какие проги на Electron. Сами кеды при этом потребляют вместе с системой где-то полгига всего.

Мне кажется вы тут, что то под шаманили )) Чтобы нам показать фейк. Список процессов бы показали и отсортировали по потреблению.

Вот как у меня на другой машине.

Это еще при условии, что у меня куча докер контейнеров уже запущено и работает.

Вот, пожалуйста, старый добрый браузер. Там еще миникуб крутится где-то, докер, постгря, но браузеры нынче жутко жрущие до памяти. И да, тут не 100500 вкладок, но штук 30 будет.

Отображение потоков стоит выключить, чтоб не мешались


Ну и мой скриншот, чтоб коммент не был пустым

Это не потоки, это модный snap + браузер, который на каждый чих плодит процесс.

$ ps auxf | grep firefox | wc -l
28


Зелёный цвет в htop — это потоки. Я не отрицаю большое количество процессов, но отображать в htop потоки, которых ещё больше, всё равно ни к чему

Да, вы правы. Редко пользуюсь htop, спасибо. Без тредов:

Ну да, небольшая экономия места на диске, но память всё так же будет забиваться.

А можно поподробнее раскрыть идею? Ведь если используется одна и та же разделяемая библиотека, то код ее и все константы будут разделяться между всеми приложениями, использующими эту библиотеку. То есть допустим у нас запущено 20 приложений KDE, каждое из которых используют 50 мегабайтный Qt с кучей плагинов, если бы каждое приложение использовало бы свою копию Qt на полную, то в результате у нас ~1ГБ оперативки ушел бы на всю эту фигню. А за счет того что Qt одна, страницы памяти разделяются и получаем экономию.

Это не совсем так, so (shared objects) на то и shared, что переиспользуются в памяти между всеми процессами их загрузившими. Отсюда и большие значения в колонке SHR.

У меня есть подходящий пример по поводу 'простенького целерончика'. А именно, легендарный (в своё время) asus eeepc 900, с гигабайтом памяти (и апгрейдом до ssd накопителя).

OS - NetBSD, которая сильно легче линукса -- одно ядро раз в 10 меньше.

Сборка GCC -- не хватает гигабайта памяти и вываливается в своп немного.

То же самое, если попытаться ходить по интернету браузером palemoon (разновидность firefox) -- gmail, wiki, google -- уже тоже начинает из гигабайта вываливаться в своп и конечно же жутко тормозит. В остальном -- работает нормально (иксы, без DE и лёгкий WM типа fluxbox).

Так что нет, гигабайта памяти и скорости легких целерончиков уже совсем не хватает.

я на eeepc 1015 веб разработкой занимался, хром + IDE, разумеется что-то свопилось, но в принципе это было весьма комфортно (если не принимать в рассчет не стандартное разрешение)

тогда правда и хром был по легче

Для wiki и google (в смысле, именно поисковик) palemoon более 200-300мб памяти не будет жрать, вот с gmail, как и всё, что «веб-приложение» уже проблема, да.

У gmail есть режим простого html, в 99% случаев мне его хватает - грузиться и работает моментально. Даже под firefox. В хроме полный вариант грузиться/работает заметно лучше, чем в фаерфоксе.
Не смотря на достаточно мощный комп использую этот режим

Работаю сейчас над проектом, который запускается в Linux.
Основной бинарник первого компонента занимает 250 мегабайт. Бо́льшая часть из них там нафиг не нужна, это последствия включения нескольких толстых библиотек.
Ну и код написан так, что, например, чтобы собрать 3 параметра с кучи объектов, вся куча объектов пробегается по 1 разу на каждый параметр (с массой копирований...)
Но поскольку ресурсов хватает, это никого не волнует.
PS: Оно ещё и собирается и работает в докерах на основе древнего RHEL. Протестировать локально невозможно. Разработка замедляется на порядок. Зато стильно-модно-молодёжно-Linux.
PS[2]: я за Linux. Но я к тому, что убить преимущества можно у всего, и стандартные корпоративные подходы делают это влёгкую.

На Си пишешь и собираешь или на другом языке?

C++ (относительно низкоуровневый, смесь C-с-классами и 11).

Поставьте на вашу убунту простенький Миднайт коммандер. Сколько пакетов он потянет за собой?

Совсем немного пакетов потянет. Midnight Commander - очень легкая, памяти почти не потребляет, регулярно пользуюсь, очень удобно.

А вы проверяли, сколько он пакетов тянет с собой? Они действительно не нужны и не используются, но сколько их? Насколько я помню, он по-дефолту требует Xorg и кучу пакетов из гнома. Консольный файловый менеджер. И именно об этом говорит автор статьи. Неважно, винда у вас, линукс, полуконский полупес... В современных реалиях при установки любого программного пакета вы установите кучу ненужного хлама, который просто будет лежать и занимать место. Под виндой - больше (не факт), под линуксом - меньше, но этого хлама будут тонны.
Сколько занимает сейчас glibc? Вот вы делали 10 лет назад программу, которая использовала этот пакет. Функционал этот программы нисколько не изменился. Но при установке этой программы вы притянете к ней glibc, размер которого увеличился минимум в 10 раз. Вот это - проблема.

А вы проверяли, сколько он пакетов тянет с собой?

На Ubuntu Server вот столько

andreymal@ubuntu:~$ sudo apt install mc
Следующие НОВЫЕ пакеты будут установлены:
libgpm2 libslang2 libssh2-1 mc mc-data
Обновлено 0 пакетов, установлено 5 новых пакетов, для удаления отмечено 0 пакетов, и 1 пакетов не обновлено.
Необходимо скачать 2 567 kB архивов.
После данной операции объём занятого дискового пространства возрастёт на 9 943 kB.
Хотите продолжить? [Д/н]

это вы пробуете на своей конкретной системе (где уже установлено что-то). А на чисто ОС? Мне правда лень ковыряться в пакете, но раньше там было очень много зависимостей на гноме-окружение.

Это чистый Ubuntu Server, никакого гнома на нём отродясь не было

А чего в нем ковыряться, если можно просто взять и посмотреть зависимости через apt:


~$ apt show mc
<cut/>
Depends: libc6 (>= 2.15), libext2fs2 (>= 1.37), libglib2.0-0 (>= 2.59.2), libgpm2 (>= 1.20.7), libslang2 (>= 2.2.4), libssh2-1 (>= 1.2.8), mc-data (= 3:4.8.24-2ubuntu1)
Recommends: mime-support, perl, unzip
Suggests: arj, bzip2, catdvi | texlive-binaries, dbview, djvulibre-bin, epub-utils, file, genisoimage, gv, imagemagick, libaspell-dev, links | w3m | lynx, odt2txt, poppler-utils, python, python-boto, python-tz, xpdf | pdf-viewer, zip
<cut/>

Все, что может потребовать иксов, находится даже не в Recommends.

Откуда у mc в требованиях xorg? Отлично работает на серверах, где вообще никогда не было иксов…
Есть GUI-сборки mc. Может, у него как раз такая.

На самом деле, все проще. Я никогда не пользовался убунтой в повседневной работе, мне генту был ближе. А там все работает интересно - если в системном х.конф прописаны иксы, то миднайт ставит свои иксовые приблуды. При этом его даже не сильно волнует, что у меня настроено xfce - он ставит всякую гномовскую требуху.
ЗЫ. И, опять же, у меня данные сильно устаревшие, я уже лет 7 не пытаюсь использовать линуксы в качестве десктопных систем - корпоративными стандартами они не предусмотрены, а

Там тоже все плохо. Держу вот тут ностальгии ради архивный форум конца нулевых, но нынче с постоянными переездами решил перекинуть на микро-виртуалку с 256мб оперативки. В свое время и побольше вещи крутили, даже на роутерах с 32мб оперативы. Но нынче даже после всех возможных оптимизации все равно с OOM периодически крашится. А все потому что всякая мелкая ерунда раздулась до невероятных мсштабов. systemd-jourald отъедает 2мб на то чтобы просто писать логи в файл, logind 1.65мб на... просто так, snapd под 10мб чтобы засирать диск устаревшими копиями приложений, альпиновский скрипт проверки наличия обновлений системы работает на питоне и выедает под 30мб, вместо курла по крону, который тоже кстать на 800кб раздулся, это уж не говоря про апач и mysql которые в таких ограничениях просто говорят "кря".

А если попробовать найти что-то без systemd?

К сожалению, на выбор есть лишь центось, федора, дебиан и убунта. Вроде, говорят, можно наживую его выкорчевать, но я пока не рискую. Ну и не особо это спасет от раздувания софта в целом. Если сегодня скрипт проверки обновлений столько отъедает, завтра столько же будет жрать пакетный менеджер, и чтобы обновить пакеты придется выключать бд.

Специальный инструмент загрузки на сервер, которым я пользуюсь сегодня, суммарно имеет 230 МБ клиентских файлов и задействует 2,7 тысяч файлов для управления этим процессом.

Проблема есть, но все вовлечены в процесс раздувания, разворота не видно. Сами работодатели всех заточили на фреймворки, спрашивают и там и тут. Там из этих 230 мб, можно целый CRM наверное сваять.

Ну и условно всех учат собрать Теслу из выданных компонентов, а реальные задачи от работодателя, это собрать из этих компонентов - фонарик.

230 мегабайт это больше чем windows 2000 или windows 98.
это целая операционная система 32 и 16 битная одновременно.
еще 20 лет назад.
с тех пор ничего не поменялось в пользовательском опыте работы.
(не игр)

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

Я не отрицаю проблему, которую поднял ТС, и сам солидарен с его позицией. Но это цена за то, что разработка становится дешевле, а значит у пользователя появляется намного больший выбор ПО, которое он может использовать. Можно писать программу максимально близко к железу и упарываться по производительности, иногда это оправдано. Но тут приходит какая-нибудь фирма, и говорит "сколько стоит написать сайтик корпоративный? 50 тыс. руб.?? а что так дорого?!" и разрабочик берёт готовый фреймворк (раздутый потому что универсальный) и быстро пишет на нём этот сайт.

разработка точно не становится дешевле, и тем более чем 20 лет назад.

Ох, если всё время придумывать новый способ организации данных (виндовс, машем ручкой всем твоим разновидностям диалогов, некоторые до сих пор из 98/nt4. Кстати, это эталонная помойка, за которую часто любят ругать линуксовые смешивания kde/gnome приложений).

Хороший пример "удорожания" разработки - 20 лет назад приходилось брать 3D модель, делать развёртку и рисовать в каком-нибудь фотошопе текстуру по этой развёртке. Сейчас, в том же блендере можно взять картинку и тупо рисовать частью этой картинки в текстуру, используя проекцию окна. Это просто фантастика для 2000 года. Я уже молчу про перевод из фоток в 3D в каком-нибудь Meshroom. Да, там надо редактировать и делать по сути новую сетку, но! это уже очень легко делается по готовым поверхностям в пространстве. 3D скульптинг - тоже "магия", когда с планшета просто "рисуешь", а не кропотливо решётку с нуля фигачить.

Но смысл изначально был в другом. У вас новый функционал, полезный и разнообразный. Хоть и раздутый код для его реализации. Я не знаю, может быть в фотошопе это оправдано, но калькулятор, который раньше ел меньше мегабайта, а сейчас за раз отъедает за 150 мегабайт оперативной памяти при таком же функционале - это действительно просто неприлично уже. В посте это и рассматривается, что крохотная приложенька делала то же самое, что и 200+ мегабайт и 2700 файлов.

Калькулятору 20-летней давности не приходилось думать о hidpi, 4k, мультимониторных конфигурациях, тач-управлении, поддержке десятка тем интерфейса, синхронизации в облако, подгрузке из интернета курсов валют и еще вагону функционала, который отдельному пользователю может и не нужен, но нужен другим пользователям, а писать 100500 версий под каждого юзера нерентабельно.
Дело в том, что современному калькулятору тоже не приходится об этом думать. Все эти темы/тачи/hidpi и иже с ними — всё это разруливают библиотеки операционной системы. А в плане функционала он не слишком ушёл от калькулятора 20-летней давности, зато жрёт ресурсов примерно как AutoCAD или MathLab 20-летней давности
Вот именно этими библиотеками, входящими в состав калькулятора, и набираются те мегабайты, которые в этой теме хейтят.

Они же в составе ОС, зачем они отдельно? Да и крайне сомнительно, что поддержка тача увеличит код на 40-50 мегабайт

Это характерное мышление некоторых современных программистов, оправдание раздутости невероятной сложностью: «все эти тачи/hidpi/unicode» — это просто мантра для остановки размышления. «Ты что! Не лезь! Сложно же, там тач, хайдипиай, конверсия валют и другие какие-то штуки важные»

Давайте посмотрим на ваш код. В нем вы юзаете огромный telegram.ext только ради Updater и CommandHandler.
Почему не написали свою обвязку? Это же пара сетевых вызовов, ради которых вы инклюдите в проект большую библу, функционал которой на 99% не используете.

В соседнем файле для парсинга даты фиксированного формата вы юзаете dateutil.parser. Это вместо того, чтобы написать простой regexp. А ради парсинга пары аргументов запуска, юзаете argparse в котором еще тонна ненужного вашему софту функционала.

Вы когда этот код писали, вам кто на ухо мантры для остановки размышления начитывал? :)

Когда я этот код писал (форкал, на самом деле), то даже и не думал, что буду хоть кем-то называться “программистом” восемь лет спустя. :)

А кто-то из посетителей этого поста запускает ваш бот и причитает, что автор раздул свой софт на ровном месте и заюзал большие библы там, где не стоило и поэтому оно теперь жрет много памяти и диска :)

Репа, кстати, не форкнута :)
Репа, кстати, не форкнута :)

Ибо я тогда и не умел особо, скопировал себе, потом запушил. Или что-то такое. А может и вообще просто из примеров накидал, не помню.


Если у этого кода есть хоть один пользователь, то я буду очень удивлён :) А вот когда такой же код встречается в проектах, которыми пользуется миллиард пользователей — это уже беда.

Хотите сказать, что если этот ваш проект начнет использоваться некоторым количеством человек, то вы вложите в него свои ресурсы (финансовые и временные), чтобы все переписать без зависимостей?

Хочу сказать, что если я буду делать проект для значительного количества пользователей, то я буду вкладывать в него свои финансовые и временные ресурсы :)


Где пошла речь про переписывание без зависимостей я не заметил. Обсуждаемый бот имеет самую большую зависимость — интерпретатор питона, запускается на любом тостере и жрёт практически ноль процессора, потому что ограничен скоростью опроса API (что-то типа раз в минуту было в то время допустимо).

Я понимаю, сторонние пакеты, но чем вам argparse-то не угодил? Он же в стандартной библиотеке, так что по-любому есть всегда и нисколько не увеличивает конечный объём приложения — глупо отказываться от предоставляемого им функционала даже «ради парсинга пары аргументов запуска».

А какая разница стандартная или нет? Если представить, что мы собираем дистриб для распространения, то в него будет включено только то, что мы заюзали, а не всё, что с питоном прилетело. В рантайме аналогично — оперативу есть будет только то, что мы подключили, а не все, что есть в стандартной библе.
Если отложить в сторону рантайм, а распространять скриптом/исходником, а не инсталлером/дистрибом, исходя из того, что питон (со стандартной библой) есть на целевой тачке, тогда ваше замечание в тему, но такое распространение — это частный случай. Ну и тут больше про win приложения, кмк, топят. Ну и весь мой коммент был не более, чем примером на скорую руку, но надеюсь суть я донес :)

Если бы я делал сейчас, то бахнул бы на Rust’e, вкомплил бы всё в один бинарь с LTO и использовал бы реально минимум. Но это сейчас, потому что я как раз и прошёл путь от «могу накидать скрипт на питоне и мне пофиг на ресурсы» до «специально изучил новые инструменты, чтобы снизить оверхед из-за того, что это моя ценность как разработчика».


На практике никакой разницы бы не было — минимальная тачка на AWS t1.micro была бы пустой не на 99%, а на 99.9%, но всё равно было бы приятно. И скорость разработки бы ничуть не пострадала.

Покажите ваш современный коммерческий код :) Пошаримся в нем на предмет сторонних библов :) Уверен, что найдем оч много :)

Ещё раз — откуда пошло, что сторонних зависимостей быть не должно вообще?

С вашего коммента.
Вы где грань проводите что еще можно, а что уже нельзя? К примеру, если telegram.ext можно, а qt нельзя, то как этому прийти?

Из коммента не следует, что сторонних зависимостей не должно быть, из него только следует, что нельзя сходу оправдывать многократный рост размеров тем, что приложение содержит что-то, что считается «сложным» в разработке. Тут в комментариях уже много вариантов такого «сложного» мелькало, кому то парсинг форматов кажется магией («ты что! Там тыщи типов файлов поддерживаются, сам будешь писать — там уязвимости будут, вот на их закрытие и уходят мегабайты»), кому-то якобы юникод раздувает, кому-то кажется, что поддержка нескольких мониторов должна быть сложной, или рендер шрифтов в терминале.


А на практике, libpng — это не то, что раздувает код. А поддержка webgpu и джойстиков, родная для хрома, который электрон, который нужен для запуска текстового чатика :)


Использование telegram.ext вместо собственной логики запросов к телеграму добавило килобайт 100 кода на питоне. Не думаю, что это bloat. А вот распространять такой проект в каком-нибудь докере внутри virtualbox’a — уже да. И я так говорю, потому что такой софт есть.

Вам показалось сложной в разработке реализация запросов к серверам телеги и вы взяли telegram.ext. Кому-то показалось сложной в реализации аналогичная штука — запросы к биржам за курсами валют для калькулятора и он взял готовую библу биржи. Еще кому-то показалась сложной своя реализация поддержки hidpi и он переехал на qt.
При этом свой кейс вы оправдываете, а про остальные язвительно пишете "«Ты что! Не лезь! Сложно же, там тач, хайдипиай, конверсия валют и другие какие-то штуки важные»", удобряя это заключениями об остановке размышления современных программистов.

Именно так, себя восьмилетней давности я бы не называл программистом вообще. Тем более хорошим. Даёт это мне право называть делающих также плохо — плохими программистами? :)

Вы покажите ваш сегодняшний код и тогда будет понятно :) Я уверен, что в нем вы не пишете свою реализацию гуёв, а берёте тяжелый qt. А ваши олдовые пользователи жалуются, что раньше гуи столько не жрали :)

Вот это одна из главных причин (и на мой взгляд - уважаемая причина) неоптимизированного кода. Код нужен не чтобы красиво исполняться, а чтобы решать какие-то задачи, зарабатывать деньги. Если неоптимизированной код есть 4Gb RAM вместо 64Kb, и это стоит лишние 10-20 баксов в месяц (а приносит 10-20 тысяч баксов в месяц) - да и пусть!

Гораздо важнее стоимость разработки. И оплачиваемые человеко-часы, и скорость получения результата. Кривая и немного глючная криптобиржа, которую вы запустите в 2010 году покорит мир и принесет миллиарды долларов. Эталонная, которую вы бы начали в 2010, и допилили к 2022 - была бы мало кому не нужна, потому что рынок уже поделен.

Я для себя решил забивать не ресурсоемкость (хотя и люблю арендовать low-end VPSки за копейки), писать на Python. И для проектов с парой сотен пользователей - это вполне норм! Будет миллион пользователей - тогда, может быть и денег будет достаточно на железо или же перепишу 1% кода (самый ресурсожрущий) на чем-то более шустром.

Если неоптимизированной код есть 4Gb RAM вместо 64Kb, и это стоит лишние 10-20 баксов в месяц (а приносит 10-20 тысяч баксов в месяц) — да и пусть!

А если неоптимизированный код стоит лишние 300 баксов в месяц ресурсов облака, и это 3600 в год? Это ведь куда более частый кейс…

А разве при распространении дистрибутивом стандартная библиотека режется? По-моему, она просто рядышком вся упаковывается, вот и всё.

Это, наверное, смотря как паковать. Я не настоящий питонист, но кажется мне, что возможность не паковать всю stdlib в нем должна быть. Там ведь каждый модуль в отдельном файле. Просто оставить нужные, вроде, ничего не мешает.
Если мы говорим про рантайм, то пофиг где лежит библа на диске (в составе ОС или не в составе), она будет в памяти процесса и будет увеличивать размер занимаемой оперативки.
Если мы говорим про размер дистриба, то чтобы ваша софтина поддерживала нужные фичи, вам придется заюзать какой-ить qt и прочие .net-ы, что увеличит размер дистриба.
Ну или можете написать все это сами.
Только что запустил виндовый калькулятор — 5,6 мегов в оперативке занял

Откуда 150?

Безотносительно потребления памяти - но я отчётливо помню как "новый" калькулятор в вин8 меня поразил в самую пятку, когда при запуске показал крутилочку пока загружался UI. Честно признаюсь, память не замерял

Запустил калькулятор - около 20 мб, потыкал, скачал курсы валют, построил графики - 80 мб. В свернутом состоянии 3,5 мб.

При этом страничка данной статьи в браузере - 2гб.

Поменялось очень многое, начиная от более удобных и интуитивно понятных интерфейсов

По-моему интуитивной понятности стало меньше. Но это, конечно, моя субъективная оценка.

В пользовательском опыте ничего не поменялось.
Графический интерфейс.
Все офисные программы в графике.
Мышка все дела.
Броузер тоже уже был и там все работало.
По работе обычного офисного планктона ничего не поменялось.

разработка иде тоже была и вполне работала.
автоподстановка тоже была.
весь Delphi7 весил меньше чем сейчас один голый редактор.

именно пользовательский опыт рабочего места специалиста не изменился.
тот же 1с его дизайн сейчас в 2022 хуже чем был в 2002 когда вышла 8 версия.
тоже графический)

На Делфи не писал. Но самое простое и юзабельно в плане разработки GUI, с чем я сталкивался - это VB6. IDE, маленький бинарь. Потом я перекатился на C#, и там уже все тянет за собой целый .NET, и Qt, который тоже немаленький.

Еще был (есть) C++ Builder, в котором был и редактор форм, и целая хренова туча виджетов, втч всяких сложных. И еще помню были всякие пакеты компонетов для C++ Builder. Эх, времена.

Что касается GUI, то чем более новая технология, тем она сложнее и выше порог входа.

VB6. IDE, маленький бинарь. Потом я перекатился на C#, и там уже все тянет за собой целый .NET

Бинарь маленький, но не самодостаточный. А .NET встраивается в винды начиная с версии XP. Обе технологии используют виртуальные машины (интерпретирующие P-код и CIL, соответственно) и обе же требуют сред исполнения.

Посыпаю голову пеплом.

А .NET встраивается в винды начиная с версии XP

Насколько я помню, там либо не было .NET, либо был очень-очень старый (чуть ли не 1.0)

Во времена до появления usb флешек любили хаять Delphi[1-2-3] за большой размер exe-шника, который не влазил на дискету. Олды плевались от vcl и говорили, что ванильный winAPI рулит :) Теперь Delphi7 — ориентир для отсчета :)
У Delphi 4 пустое приложение весило килобайт 350, если мне память не изменяет, и очень хорошо архивировалось. Ну т.е. на дискету много чего было можно всунуть :)
За пустое приложение зачет не поставят :) А еще ресурсов напихать надо! Но архивировалась эта балалайка хорошо, да!

Умельцы даже сделали для дельфи библиотеки KOL/MCK, которые реализовывали графический интерфейс на винапи, сохраняя удобство VCL. Такие приложения весили от 12 кб.

VCL действительно тормозил на старом компьютере и жрал память как не в себя.

Чтобы сделать хороший "интуитивно понятный интерфейс", надо уметь делать хорошие интерфейсы. Это почти никак не связано с кодом.

Почему бы не совместить быструю разработку и адекватный по ресурсам фреймворк? Фреймворк это абстракция над ниже лежащим уровнем. Ситуация больше похожа на строительство абстракций над абстракциями. К примеру CMake генерирующий текста для разных билд систем. С каждой версией становится больше и сложнее и не удивлюсь если скоро выйдет новая тулза, которая генерирует текст для CMake, так как это проще, чем юзать сам CMake. Сама по себе задача, по сборке программ не изменилась, собрать программу, ну ок дополнительные телодвижения по интеграции, прогонов тестов(если они есть:))

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

Вы знаете, вот по поводу более интуитивно понятных интерфейсов - не соглашусь! Взять "простейший" LightRoom или Krita - без чтения учебных пособий там даже файлик открыть не все в состоянии.

И да, лично был свидетелем, как парень лет 18-ти не смог сдать экзамен в ГАИ, где на экзаменационных местах, кажется, был запущен официальный портал с билетами в режиме киоска. Бедолага просто впервые увидел компьютерную мышь - первые пару минут он пытался тыкать пальцем в экран, а на рекомендацию тыкать не пальцем, а мышью, просто погрустнел лицом и вышел из аудитории. Вот такая интуитивная понятность бывает.

Давняя мудрость гласит, что действительно интуитивно-понятный интерфейс только у соски. А все прочие "интуитивные" вещи - уже основаны на каком-то обучении, культуре, традициях...

Бедолага просто впервые увидел компьютерную мышь

Ну если он к 18 годам не побывал даже в компьютерном классе в своей школе, и побоялся взять мышь в руки и попробовать ей воспользоваться, все вокруг только выиграли от того, что этот человек не будет выезжать на дорогу в качестве водителя, и он сам в том числе :)

Уверен, что Гагарин тоже компьютерную мышь никогда не видел ;)

Но, конечно, в непонятной ситуации всё бросать и уходить - всем лучше, если этот человек права не получит.

При этом rclone, который умеет загружать и синхронизировать файлы на все возможные облака (включая то, куда льёт автор с вероятностью 99%), а так же на всякие виртуальные/шифрованные/сжатые таргеты — весит 13мбайт. И то, только потому что написан на Go, который компилит всё в «гигантский» статический бинарь.

В последнее время developer experience считается едва ли не самым важным. Типа, код красивый, писать мало/удобно, вот это всё. А то, что оно тащит за собой грёбаный браузер, и вообще, писать полноценные приложения на макросах для гипертекста не может быть адекватной идеей, никого не останавливает. Продукт побочен и вторичен, важен исключительно сам процесс.

Прикиньте если бы почти все популярные клиенты мгновенных сообщений были написаны на макросах word, на бейские, и поставлялись бы с копией ворда. Электрон — это вот настолько же нелепо.

whatsapp для компьютера - это электрон

Пользователю глубоко пофигу, на чем написано, лишь бы работало. А с копией ворда есть немало плюсов взаимной интеграции. Можно отправку сообщений из ворда автоматизировать не через гребанный API, а напрямую, например. Можно дорабатывать клиент под требования бизнес-процессов.

Так оно и работает, только херово. У пользователей планка качества просто уже под землю ушла, поэтому они когда видят что-то, что работает быстро даже на старом железе и не занимает под сотню мегабайт, реально удивляются.

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

А если не покупает и сидит на старых версиях - то начинают лезть вопросы совместимости форматов, сценариев, обязательно требуют для просмотра/проигрывания файла прикрутить свистоперделку, которую или не поставишь на старое железо\ОС, или жрет ресурс как не в себя.

А на деле даже в 2022 году сам Microsoft продаёт типа современные ноутбуки Surface Go, которые начинаются с 4 ГБ оперативной памяти, ставишь туда такие Slack, Discord и прочие шедевры и всё - приехали.

У меня оперативки 64, но дискордом всё равно пользуюсь в браузере. Отличий от отдельного приложения вообще никаких, UX такой же бесячий, но хотя бы не обновляется по 5 минут с 3 перезапусками без возможности отключить обновления.

Меня больше бесит Teams, который суть — обёртка над браузером.
Но если аналогичные сервисы Google прекрасно работают из браузера, в т.ч. и из Firefox, то Teams не работает и требует запуска через приложение. Пусть горят в аду.

В смысле «не работает»?

Собственно, в браузере он мне нравится больше, чем стэндэлон.

P.S. При открытии ссылки на конференцию Zoom тоже требует скачать программу без вариантов. Если обновить страницу, появляются варианты. Может, и тут так же.

В смысле: нельзя устроить аудио/видеоконференцию.
Zoom — нативный клиент, а Teams — Electron, поэтому ограничения кажутся искусственными.

Несмотря на то, что у Zoom нативный клиент, отличий в UX в браузерной версии я не нашел. Допускаю, что они есть, не суть.

Я, видимо, чего-то не понимаю, но... в браузерной версии Teams, точно как в десктопной, назначаю встречу, присоединяюсь и провожу видеоконференцию. С демонстрацией экрана.

Микрософт тупо проверяет User Agent. Если подставить юзер агент от хрома, то звонки магически начинают работать. Я сейчас точно не помню, я так делал примерно 2 года назад, но кажется проблемы были только с расшариванием экрана.

Вот это и отвратительно. Поменял User Agent — и действительно, стало лучше. К слову, по неведомой причине, родной клиент Teams в Linux позволяет шарить только весь экран, а браузер — отдельные окна.

Насколько я помню, клиент электронной почты Outlook до сих пор рендерит html в письмах с помощью движка Word. Такие дела.