Comments 864
Переходи на 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 в венде, проследим как, когда и чем они обновляются?
Поясняю. Прямо сейчас (на тот момент) в системе стояли две библиотеки, старая и новая. С которыми слинкован прочий установленный софт. Ну собственно старую я поставил не из любви к искусству, её притащил по зависимостям слинкованный с ней софт. Т.е. ответ на ваш вопрос "Что будет" таков: софт стоит и работает.
А что с ними должно быть, если это разные файлы?
Чтобы не было проблем от такого конфликта, надо заниматься уже специализированными играми, которые учитывают такую возможность: или с visibility (сложнее), или с symbol versioning (проще, но надо не забывать это делать раньше, не откладывая).
Этот давно не погружался в особенности сишной сборки, но разве пространство экспорта не индивидуальное у каждой библиотеки, и разве в момент динамического связывания lib1.echo() и lib2.echo() — не разные функции и не будут подгружены по разным адресам в пространстве импорта?
Не говоря уже о том, что библиотеки и не должны экспортировать все свои импорты.
В ELF — нет. Например, вы через LD_PRELOAD грузите SO в котором malloc() и free(), и все ссылки из libc теперь будут резолвиться в эти версии, даже если эти функции в той же libc (как обычно). Из других библиотек — тем более.
В общем случае, в одном пространстве символ (или символ+версия, если символ версионирован) — какой первый найден, тот всем и отдаётся на запрос импорта. А дальше те регулировки, что я упоминал.
> Не говоря уже о том, что библиотеки и не должны экспортировать все свои импорты.
По умолчанию как минимум с GNU ld — всё что не static — экспортируется. Регулируется или компилятороспецифичными указаниями в исходниках, или скриптом линкера.
DLL hell — это всё же windows-специфичная проблема
Только из-за аббревиатуры DLL, а не из-за принципа работы.
не нужно далеко ходить, посмотрите на NPM и Composer зависимости любого сайта.
Раньше из всего JS было достаточно JQuery, а сейчас ? npm папка запросто может достигать гигабайтов, а потом от слишком большого количества файлов глючить и падать сборщик, прекрасно.
По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужнаНу да, если бы…
Скажите это Каноникал, которая везде продвигает Snap
Если вам не нравится Snap. Дело буквально двух команд.
Вот статья.
https://losst.ru/kak-udalit-snap-paket
Лично я сам удаляю на слабых машинах.
В snap насамом деле есть и плюсы и минусы. С одной стороны это контейнеризация, примерно как в docker. С другой стороны большее потребление ресурсов в совокупности с накладными расходами.
Самое главное, что это как опция, хочешь пользушься, хочешь отключаешь.
Ну а что разработчики должны, вместо того чтобы использовать, например, 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 стандарта «правильной» разработки опенсорса.
Идеальная Быстрая сортировка?
У вас может быть задача отсортировать данные, которые помещаются в память, а может быть задача про данные, которые не помещаются в память, надо тогда работать с диском или ещё с каким-то хранилищем. И вот у нас уже две Идеальные Быстрые сортировки.
Данные которые не помещаются в паять не надо сортировать Быстрой, для этого есть другие способы. Так что это не проблема, да — кубики лего должны быть одинаковыми и хорошо сделанными.
Говорить про пригодную для 99% случаев версию — ещё можно. Для всегда — нельзя.
Быстрая сортировка без обмена элементов существовать не может — это заложенно в её основе. Сравнение с несравнимых элементов — это так же не быстрая сортировка а видимо что-то типа NullQuickSort которая сначала выполняет некоторую логику (сдвигает нуллы куда-то), а потом уже сортирует оставшуюся часть нашей Идеальной Быстрой Сортировкой.
Так что как раз получается, что по опредлению такой алгоритм будет единственным, и уже поверх него можно городить доп. логику. Это и есть задача программиста. Взять готовый кубик (рабочую сортировку на множестве с определенным сравнением), и навесить на него сортировку флоатов.
Любая сортировка может быть сделана без обмена созданием массива индексов/указателей и перестановкой этих указателей вместо самих элементов. И это не зависит от того, она «быстрая», пузырёк или что-то другое.
> Сравнение с несравнимых элементов — это так же не быстрая сортировка а видимо что-то типа NullQuickSort
Возьмите массив float'ов, заполните случайными значениями и растыкайте среди них, например, процентов 10 NaNʼов. Дальше отсортируйте разными алгоритмами и посмотрите на результат. Получаются весьма забавные зависимости от подхода. Некоторые реализации вообще крэшатся на этом, но все известные мне сортировки из стандартных библиотек C и C++ выживают.
А вот Rust просто откажется такое компилировать — трейт floatʼа не помечен как допускающий total order.
Для разминки ума, кому интересно, может подумать об отвлеченной и более материальной задаче: сколько человечеству нужно узлов. Их ведь очень, очень много. И я, как простой "пользователь веревки", имею простые задачи вроде "привязать веревку к столбу прочно" или "привязать веревку к столбу и обеспечить сильный натяг". Но узлов - дохрена, и я так понимаю, что каждый из них иногда по своему хорош.
Вот мне, как человеку достаточно далекому от дел флота, альпинизма и строительства, даже полторы сотни кажутся невероятно избыточным количеством. Проблема в узости нашего кругозора. Пока мы очень узко видим задачу (узлы нужны чтобы натягивать веревку сушить белье!) - нам кажется, что нужен всего один узел, и все прочее - от лукавого. Чуть погружаемся в тему, и оказывается, нам нужен еще узел, чтобы можно было очень туго подтянуть веревку, и предыдущий тут не подходит. Погружаемся еще ниже, оказывается, нужен еще узел, который будет легко развязываться. А потом - чтобы он еще развязывался удаленно (просто дернув за конец). Потом узел, который можно завязать на середине веревки, не имея доступных концов.
Наверное, если я подумаю еще - то еще 3-4 потребности в узлах напишу, а про остальные даже и вообразить не смогу, зачем они нужны.
Ой вы навыдумывали. Узел вам нужен один - шнурки завязать.
Всю жизнь завязываю одним узлом, хоть в темноте за 2 секунды завязываю, а как они там называются мне без разницы. А у вас в голове много мусора, на простые действия десяток вариантов, и никаких действий в итоге, вся энергия в сотрясание и нагрев воздуха идёт.
Ну так будьте проще. У меня всё просто, у вас в том же месте какие-то сложности. Я помню как меня родители учили шнурки завязывать, потом сам друга научил, и вас могу научить. А ещё вы удивитесь сколько народу на велике не умеет ездить. Только я один с десяток людей научил никому ничего не навязывая. И всё это потому что объясняю просто, а не ссылками швыряю и десятки вариантов предлагаю.
Ну и? У меня то никогда не было скользких (: У вас тоже врядли, нагуглили небось какую-то дурость. Я себе скользкими шнурками скорее пальцы порежу чем завяжу их, и избавлюсь незамедлительно от такого счастья.
Это значит только то что вам продали обувь без шнурков, а на место шнурков какую-то леску натянули под видом шнурков, и вы зачем-то мучаетесь полумерами. Я бывает в магазине лечу людей, покупающих масло, мол это такое название продукта, "Масло 60%", если перевернуть и состав посмотреть то там будет уже молочный продукт или ещё какая гадость, а 60% масла просто не существует.
Если посмотреть контекст, то как раз ровно в этом и суть: нам, не-специалистам, нужен только один узел, а вообще их придумали несколько десятков для разных нужд. Аналогично и с алгоритмами: нам достаточно одного условного QuickSort, а вообще - совсем не факт.
Сортировки нужно две - устойчивая и не устойчивая, разумеется это можно добавить аргументом по умолчанию в библиотечную сортировку, тогда да, будет всего одна, и не сильно разбирающийся будет всегда устойчивую пользовать, как более универсальную но и более медленную, а профи поднастроит под свои данные. И старый код не ляснется от внезапно возникшего аргумента функции. Но появится новая проблема - этих аргументов по умолчанию возникнет 100500 на все случаи жизни. Хоть это и не такая существенная проблема но всё же возникнет в виде комбинаторного взрыва числа возможных состояний библиотечной функции.
Сортировки нужно две - устойчивая и не устойчивая
Умножьте на 2 для начала;). Массивы и связанные списки сортируются по разному.
Ну тогда нужна некая абстрактная перестановка местами двух элементов и абстрактное сравнение этих двух элементов в некоей абстрактной структуре данных. Каждой из этих абстракций автор библиотеки может докинуть аргументы по умолчанию. Так и совместимость с не абстрактным не потеряется, если первая реализация только для массивов, и чуть поправить можно. Но суть в том что всё это должно быть реализовано автором первоначального алгоритма, а не кем-нибудь относледовано и переделано. Т.е. Первоначальная задумка должна сохраняться, и при необходимости дополняться.
А потом библиотека, подтягивающая другие библиотеки вместе с другой многоколенной библиотекой подтягиваются в сто пятую библиотеку. И вот уже экспоненциальный рост пожирания ресурсов обгоняет технологический прогресс, а еще чуть позже на неописуемой скорости врезается своей огромной массой в нерушимый потолок физических ограничений. Все, закон Мура не действует, производители больше не могут наращивать производительность на единицу процессорной площади. И придётся все переписывать заново, зато не изобретали велосипед
Для удаленки взял свой старый медиацентр. Что бы не занимать ноутбук. Athlon x4 640. Добил до 8гб + ssd. Поставил, windows 10 и lubuntu lts последнюю. Все же lubuntu побыстрее и меньший жор ОЗУ. И не так часто вижу в top'e загрузку проца под 100%. Серфинг одинаков на обоих осях.
Я бы разбил проблему на части
Разделяемые библиотеки
Разделяемые библиотеки как раз и созданы для того чтобы избежать дублицирования кода, поэтому ничего плохого в их использовании нет. Но для того чтобы этот потенциал был реализован более полно, нужно чтобы (1) их лицензия позволяла программам в системе их использование и (2) программы были собраны именно с установленными в системе версиями библиотек, а не требовали другие версии. В случае дистрибутивов Линукса, казалось бы, эти условия выполняются чаще и лучше.
Но это преимущество имеет, правда, и свои негативные стороны. Например, когда в дистрибутиве десятки тысяч программных пакетов, обновление программы имеющей сотни зависимостей становится достаточно сложным, особенно для программ с несвободной лицензией. И чтобы решить эту проблему придумали всякие snap и flatpak, что полностью нивелирует преимущества разделяемых библиотек, то есть как раз в области, в которой дистрибутивы Линукс могут проявить себя лучше.
Умножение системных процессов.
В системах на основе Линукс, как и в Виндосе множатся и плодятся системные процессы. Причём почему-то с каждой новой версией они становятся всё более прожорливыми, пожирая память и процессор. Я уже смирился, что даже в Линуксе какой-то демон, ответственный за вывод звука иногда может есть процессорное время даже когда никакого звука в системе не проигрывается. Конечно, это пока это не дошло до крайностей, описанных в статье, но надо признать, тенденция в Линуксе такая же как и в Виндос.
Раздутые приложения-монстры
Некоторые приложения со временем растут, пока не превращаются в монстров которые содержат в себе ещё одну собственную операционную систему (иногда две или больше). Кажется что в конце-концов они должны погибнуть под тоннами собственного неподдерживаемого кода. Но они почему-то никак не погибают. Яркий пример - браузеры.
Приложения на электроне
Эта беда проникла как в Виндос, так и в Линукс и здесь Линукс ничем не отличается от Виндос. Это просто фабрика монстров.
Список можно продолжать. Но ясно что беда затронула и Виндос и Линукс.
Я не программист, потому интересуюсь, а зачем скачивать всю библиотеку? Почему бы не скачать те самые 1-2 функции с меткой к какой библиотеке они принадлежат?
Потому что библиотека — минимальный уровень деления законченного и готового к распространению кода.
Функция может использовать другие функции, которые даже не будут экспортироваться. Портянка констант может составлять существенную часть библиотеки. Имена функций в разных библиотеках могут совпадать. Она может экспортировать вообще не функции, а интерфейсы.
Библиотека объединяет это все в одну логическую единицу, уменьшая сложность управления.
Не правильно выразился, так не делается потому что это технически сложно или потому что так просто никто не делает и нет готовых решений? Исключая описанные вами случаи когда действительно придется качать всю библиотеку. Условно говоря чтоб с готовым продуктом шли не все библиотеки целиком, а только нужные в данном случае части, чтоб не было такого чтоб из библиотеки идущей с продуктом используется процентов 10. Тот файл с тем же именем, но облегченная версия, внутри которого есть список того что было вырезано. В таком случае это не решит проблему , но облегчит ее.
В компилируемых языках при статической линковке библиотеки из неё выбираются только нужные элементы. При динамической линковке библиотека (.so, .dll) одна для всех и ничего из неё удалить невозможно.
В интерпретируемых языках также бывают сборщики проектов (например, gulp или webpack для JS). Они также умеют выбирать только используемые элементы модулей и библиотек.
Господин не прав. Днесь пытался найти на ноутбук 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 и на том же проекте смог комфортно работать. Был удивлен и много думал о том, стоит ли продлять лицензии.
xUbuntu есть 400 мегабайт после старта!
"600-1000 МБ" Откуда вы такие цифры получили? И где вы нашли WinNT Workstation? Давайте с Windows 10 сравним, или с Windows 11.
"WinNT Workstation" - операционка которой уже больше 10 лет не существует, и на любом железе современном вы даже не запустите.
В таком случае нужен дистр минимально потребляющий ОЗУ. Что бы по серфинг оставить максимальное возможное количество памяти из 2-ух гигов.
У меня mint (xfce) вполне норм работает на eeePC c 2 Gb и 900 МГц "целероне", тянет офис и браузер, даже ютубчик в низком качестве при желании можно посмотреть. Разумеется я им не пользуюсь в повседневной практике, нет смысла никакого. Но как читалка, компактная печатная машинка, аудиоплеер, вполне норм.
Пробовал множество линуксов.
А какой был графический интерфейс? Я как-то разбирался, как ускорить работу Linux на старом компьютере, и обнаружил, что очень много ресурсов забирал на себя tracker, программа для индексации файлов. Причём вроде он работал даже если я использовал другое окружение рабочего стола. То есть, по сути компьютер работал бы быстрее, если бы я при установке просто убрал галочку напротив GNOME. Но, повторюсь, это касалось довольно старого компьютера, по логике вещей tracker нужен для того, чтобы ускорить работу (чтобы поиск был быстрее).
2005 год, простой Пентиум, да еще и М. Какие невероятные достоинства имеет конкретно этот ноут, чтобы пытаться им пользоваться? Его даже компактным не назвать, он весит почти ТРИ КИЛО, с отвратной TN-матрицей нижайшего разрешения. Его клавиатура тоже не представляет из себя — ничего особенного.
Практически по цене самовывоза можно найти ноут на Core2Duo и он будет отлично справляться с функциями пишушей машинки.
Мне кажется в каком-то месте маркетолог у нас сменил и программиста и инженера поэтому размеры приложений выросли в сотни раз когда калькулятор может весить сто мегабайт, а игра больше ста гигабайт. А все потому что медленный софт подгоняет железо и наоборот быстрое железо позволяет забить на оптимизацию, все ради того чтобы продавать, продавать и продавать без учёта ресурсов. Одно потребление так же ведет индустрию в тупик.
Для эксперимента советую antix. Возможно взлетит.
Возможно автору нравится копаться в старом железе. И пытаться их восстановить для текущих задач. Почему нет:)
Не такая уж и рухлядь. Смотрите на производительность одного ядра.
В том ноуте проц вот такой: www.cpubenchmark.net/compare/Intel-Pentium-M-1.73GHz-vs-Intel-Core2-Duo-E8290/1160vs1790
Сравнил с типичным ноутным кор2дуо
«ноутбук HP6110»
И моя рекомендация купить печатную машинку на c2d
Почитайте камент и посмотрите из чего тот ноут сделан
При чем тут райзен?
Говорили о проце pentium m. Но если сравнивать с десктопным e5500 производительность вполне себе. Но для серфинга будет боль.
Посыл то был в том, чтобы выкинуть эту рухлядь, дорогую как память — и купить б/у, но на к2д. Там совсем другая архитектура и она на порядки быстрее того старого пня, а всех делов — 5к деревянных
х220-40 довольно унылы, там заметно устаревшее железо, а 270 и выше — уже профанация, откровенно неудачные модели, сильно перегревающиеся и вообще не оптимальны. Убили такое приятное семейство, закачивая в него мощности больше, чем нужно.
Не соглашусь насчёт экономного расходования ресурсов. Отличие Linux только в том, что там принято ставить зависимости общими пакетами, а не тащить их каждый раз с собой. Ну да, небольшая экономия места на диске, но память всё так же будет забиваться.
Также добавлю тенденцию пихать всё в snap и в docker.
Предлагаю сравнить скрины по количеству забитой и свободной памяти? На реальных примерах.
На примерах чего именно?
Вообще, меня больше напрягает Telegram, который аж больше 1 гига жрёт.
Не знаю, что за дистрибутив а у меня вот так. И это xUbuntu. Сама ОС, практически ничего не ест, и отзывы мгновенные. Причем куча свободной памяти, и работает на Целероне
.
Все верно. Легкий дистрибутив и куча свободных ресурсов. Не перегруженность графиков. Вот основа быстрой и оптимальной системы.
У меня i7, 32 оперативы и 2 ssd.На одном стоит минт с синнамоном, на втором в дуалбуте вин 10. Так вот, вин 10 по сравнению с линухом тормозит. Тормозит безбожно. После загрузки в нее минут 5 надо погулять, чтобы она там что-то себе пошуршала и начала, наконец, хоть как-то работать. Но даже после такой паузы работать в винде гораздо менее комфортно. Я даже не могу сказать что конкретно не так, просто какие-то раздражающие микрофризы, которые в целом создают ощущение, что "все тормозит" по сравнению с линухом. Например, запустил простую программу, а она не мгновенно запустилась, а через несколько секунд и т.д, Железо, я напоминаю, одно и тоже и совсем не слабое.
Попробуйте отключить антивирус.
Но чисто отклик интерфейса — у линукс всегда будет лучше. Винда и Макос выглядят тормознутыми часто именно из-за микро-фризов интерфейса, а не самих программ.
Я от гнома отказался в самом начале перехода на linux. Мне нравится lxqt. Жручесть меньше. Скорость выше.
Согласен. Жирный плюс, что можно поставить любую DE.
Микрофризы в Linux у тех, кто его запускается чтобы посмотреть через виртуальную машину из другой Операционной системы :)
Но даже если так. поставьте в виртулке xUbuntu. Даже в виртуалке думаю фризов вы не заметите. Что говорить, про реальную установку, космос!
Ну а так, ниже правильно написали, если нужна 10ка, лучше взять LTSC — по дефолту там меньше всякого ненужного запущено. У винды ещё с XP была замечена тенденция по дефолту загружать разную блотварь, включая некоторые службы, но оно всё отключаемо.
У меня i7, 32 оперативы и 2 ssd
На одном стоит минт с синнамоном, на втором в дуалбуте вин 10. Так вот, вин 10 по сравнению с линухом тормозит. Тормозит безбожно. После загрузки в нее минут 5 надо погулять, чтобы она там что-то себе пошуршала и начала, наконец, хоть как-то работать.
У вас какой-то неправильный ssd видимо, или может ОЗУ. Тоже i7, тоже 2ssd, и тоже 32 гига озу. 17 секунд и уже можно пользоваться. Где вы 5 минут умудрились найти? У меня даже виртуальная машина образ которой на HDD стоит, грузится минуты 2.
Ничего подобно не наблюдается даже близко и на Win10 и на Win 11, конфигурация очень похожа, всё летает
Скиньте, мы посмотрим.
Там ещё аптайм чуть больше минуты — может, не всё прогрузилось :)
Не, ну если я вместо KDE поставлю Xfce4, памяти тоже побольше свободной будет.
Но смысл?
Смысл примерно тот о чем пишут в статье. Компактный дистрибутив, компактное ПО, вот один из идеальных примеров, того как должен выглядеть софт, и прекрасно работать даже на слабом железе. Не потреблять излишнее количество ресурсов, память ГПУ и т.д.
Ради интереса перегрузился в Xfce. Потребление оперативной памяти снизилось на полгига, потребление видеопамяти же, наоборот, выросло на полгига. Интересно, почему?
Thunderbird = 497 Мб, верните мой 2007 The bat! :)
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 — это, по сути, браузер.
Предлагаю обмениваться не на словах, а прямо скринами с монитором ресурсов из вашей операционной системы, где в целом видно сколько памяти всего, сколько ест операционная система, сколько все остальное вроде Оутлуга. и будем сравнивать.
С точки зрения быстродействия как раз интересуют конкретные приложения. Голая операционная система жрёт несущественно, даже Windows 11. Но как только вы к ней, или к вашей xUbuntu добавите банально браузер, всё сразу поменяется.
"несущественно, даже Windows 11" - это 3 гигабайта, несущественно? или сколько.
Вот xUbuntu ест 400 мегабайт после старта. А дальше навешиваются приложуши. Давайте сравним кто больше ресурсов ест.
Я предлагаю фактами обмениваться!
Вот xUbuntu ест 400 мегабайт после старта. А дальше навешиваются приложуши.
Ну так в Win 11 из той пары-тройки гигабайт, которые она жрёт после старта, минимум половина — тоже необязательный софт. Выключите виджеты, антивирус, визуальные эффекты, всякие фоновые приложения, Teams, OneDrive и прочее барахло, и будет у вас ну не 400 метров, но под гигабайт вы её покромсаете. Больше — тоже можно, но уже ценой функциональности системы.
Я предлагаю фактами обмениваться!
… но показывать вам я это не буду, потому что на это надо время тратить, а я не настолько хочу вас переспорить ;)
Это видимо ошибка какая-то. Наблюдал как память утекает в телеграм в Arch'е. В винде прямо сейчас - давно уже включенный телеграм 28mb занимает
Виндовый диспетчер задач показывает какую-то странную память, по ощущениям сильно далёкую от «реальности». Возможно, лучше смотреть какой-нибудь «рабочий набор» (но не уверен, там всё сложно)
Действительно, посмотрел в Process Hacker. 160Mb при запуске. Сразу пошёл проверять размер exe - 112Mb)
Диспетчер может и что-то не то показывает, но по процентам стабильно после 85% занятой памяти всё начинает тормозить(Диск hdd, 4Гб RAM)
Хотя конечно понятно было что он что-то не так показывает. Память кончалась быстрее, т.е. занято было всегда больше чем сумма занятой памяти которую он показывал, причём ещё до того как приложение подгружало данные из сети. Т.е. например до токо как в той же телеге я нажимал что-либо вообще
Но в линуксе что-то странное с телеграмом, похоже на утечку памяти. Я там просто листал текстовые сообщения и у меня htop всё больше показывал(прям мегабайтами росло)
Так конечно просто если чат с картинками листать то тоже расти будет. Не удивительно что можно хоть до 1Гб догнать. Не знаю будет ли он со временем их сжимать и/или на диск скидывать
Проверил. Полистал огромный чат в том числе с картинками, рядом поставил Process Hacker. Занятая RAM растёт медленно, временами уменшаясь.
Похоже в линуксе таки у него утечка.
При прокрутке чата вполне ожидаемо появляется нагрузка I/O, так что телега вполне хорошо оптимизирована. Немного печально что ей при запуске тоже надо 160Mb
Ну, вот более подробные сведения:
Всё равно, как-то скромнее:
А вы ~~на шкаф~~ залезьте на пару десятков каналов с картинками и видосиками. Он не только памяти нажрётся, но и крашнуться может. ;)
Нет, он не включает страницы из свопа. У меня был случай, когда у процесса был слишком низкий приоритет, поэтому казалось, что мало памяти используется, а на самом деле было много, но всё в свопе (при том, что физическая память была свободна).
Да, поэтому надо смотреть на "Private Bytes".
Да, но PeakWorkingSet64 есть, а PeakPrivateMemorySize64 нет. https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.privatememorysize64?view=net-6.0
А вообще всё, что процесс захотел себе зарезервировать (включая shared), отображается в commit size.
меня больше напрягает Telegram, который аж больше 1 гига жрёт.
Специфика аллокатора в glibc, если верить этому. На других ОС такой проблемы нет.
По которому из показателей?
Как Ваш Telegram смог столько сожрать?!?!
Не Linux, конечно, но:
Оперативки "итого" 8 ГиБ, занято менее трети, запущено 2 браузера (FF и Edge) с парой десятков вкладок в каждом (в одной из них данный комментарий набираю), почтовый клиент (да, Outlook у меня немолод, но он мне нравится больше более новых), WhatsApp, Telegram, Skype (прости, господи), играет Я.Музыка, 1С, встроенный антивирус и ещё куча всякого хлама...
Проблема с аллокацией памяти в Linux:
https://www.opennet.ru/tips/3184_telegram_memory_debug.shtml
Кажется у нас еще один конкурент Твиттера, хотя по функционалу он не очень далеко ушел от той же аськи. Видимо программисты там создают иллюзию деятельности.
Ну давайте сравним. На 10 летнем десктопе дома win10 сильно меньше кушает. Прекратите верить, что десктопный линукс с гуями - это некое чудо, которое не есть ресурсы.
Это Гном небось 20ГБ отъел? У меня вон KDE Neon с двумя месяцами аптайма гораздо лучше себя чувствует, ресурсы отжирают в основном браузеры и кое какие проги на Electron. Сами кеды при этом потребляют вместе с системой где-то полгига всего.
Мне кажется вы тут, что то под шаманили )) Чтобы нам показать фейк. Список процессов бы показали и отсортировали по потреблению.
Вот как у меня на другой машине.
Это еще при условии, что у меня куча докер контейнеров уже запущено и работает.
Вот, пожалуйста, старый добрый браузер. Там еще миникуб крутится где-то, докер, постгря, но браузеры нынче жутко жрущие до памяти. И да, тут не 100500 вкладок, но штук 30 будет.
Ну да, небольшая экономия места на диске, но память всё так же будет забиваться.
А можно поподробнее раскрыть идею? Ведь если используется одна и та же разделяемая библиотека, то код ее и все константы будут разделяться между всеми приложениями, использующими эту библиотеку. То есть допустим у нас запущено 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, разумеется что-то свопилось, но в принципе это было весьма комфортно (если не принимать в рассчет не стандартное разрешение)
тогда правда и хром был по легче
Основной бинарник первого компонента занимает 250 мегабайт. Бо́льшая часть из них там нафиг не нужна, это последствия включения нескольких толстых библиотек.
Ну и код написан так, что, например, чтобы собрать 3 параметра с кучи объектов, вся куча объектов пробегается по 1 разу на каждый параметр (с массой копирований...)
Но поскольку ресурсов хватает, это никого не волнует.
PS: Оно ещё и собирается и работает в докерах на основе древнего RHEL. Протестировать локально невозможно. Разработка замедляется на порядок. Зато стильно-модно-молодёжно-Linux.
PS[2]: я за Linux. Но я к тому, что убить преимущества можно у всего, и стандартные корпоративные подходы делают это влёгкую.
Поставьте на вашу убунту простенький Миднайт коммандер. Сколько пакетов он потянет за собой?
Совсем немного пакетов потянет. Midnight Commander - очень легкая, памяти почти не потребляет, регулярно пользуюсь, очень удобно.
А вы проверяли, сколько он пакетов тянет с собой? Они действительно не нужны и не используются, но сколько их? Насколько я помню, он по-дефолту требует Xorg и кучу пакетов из гнома. Консольный файловый менеджер. И именно об этом говорит автор статьи. Неважно, винда у вас, линукс, полуконский полупес... В современных реалиях при установки любого программного пакета вы установите кучу ненужного хлама, который просто будет лежать и занимать место. Под виндой - больше (не факт), под линуксом - меньше, но этого хлама будут тонны.
Сколько занимает сейчас glibc? Вот вы делали 10 лет назад программу, которая использовала этот пакет. Функционал этот программы нисколько не изменился. Но при установке этой программы вы притянете к ней glibc, размер которого увеличился минимум в 10 раз. Вот это - проблема.
А вы проверяли, сколько он пакетов тянет с собой?
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.
На самом деле, все проще. Я никогда не пользовался убунтой в повседневной работе, мне генту был ближе. А там все работает интересно - если в системном х.конф прописаны иксы, то миднайт ставит свои иксовые приблуды. При этом его даже не сильно волнует, что у меня настроено xfce - он ставит всякую гномовскую требуху.
ЗЫ. И, опять же, у меня данные сильно устаревшие, я уже лет 7 не пытаюсь использовать линуксы в качестве десктопных систем - корпоративными стандартами они не предусмотрены, а
Там тоже все плохо. Держу вот тут ностальгии ради архивный форум конца нулевых, но нынче с постоянными переездами решил перекинуть на микро-виртуалку с 256мб оперативки. В свое время и побольше вещи крутили, даже на роутерах с 32мб оперативы. Но нынче даже после всех возможных оптимизации все равно с OOM периодически крашится. А все потому что всякая мелкая ерунда раздулась до невероятных мсштабов. systemd-jourald отъедает 2мб на то чтобы просто писать логи в файл, logind 1.65мб на... просто так, snapd под 10мб чтобы засирать диск устаревшими копиями приложений, альпиновский скрипт проверки наличия обновлений системы работает на питоне и выедает под 30мб, вместо курла по крону, который тоже кстать на 800кб раздулся, это уж не говоря про апач и mysql которые в таких ограничениях просто говорят "кря".
К сожалению, на выбор есть лишь центось, федора, дебиан и убунта. Вроде, говорят, можно наживую его выкорчевать, но я пока не рискую. Ну и не особо это спасет от раздувания софта в целом. Если сегодня скрипт проверки обновлений столько отъедает, завтра столько же будет жрать пакетный менеджер, и чтобы обновить пакеты придется выключать бд.
Это можно рассказывать как анекдот: перешёл на убунту ради экономии ресурсов компа
Специальный инструмент загрузки на сервер, которым я пользуюсь сегодня, суммарно имеет 230 МБ клиентских файлов и задействует 2,7 тысяч файлов для управления этим процессом.
Проблема есть, но все вовлечены в процесс раздувания, разворота не видно. Сами работодатели всех заточили на фреймворки, спрашивают и там и тут. Там из этих 230 мб, можно целый CRM наверное сваять.
Ну и условно всех учат собрать Теслу из выданных компонентов, а реальные задачи от работодателя, это собрать из этих компонентов - фонарик.
это целая операционная система 32 и 16 битная одновременно.
еще 20 лет назад.
с тех пор ничего не поменялось в пользовательском опыте работы.
(не игр)
Всё-таки Вы слишком категоричны в "ничего не поменялось в пользовательском опыте". Поменялось очень многое, начиная от более удобных и интуитивно понятных интерфейсов, не требующих чтения учебных пособий по ним, заканчивая возросшей функциональностью программ.
Я не отрицаю проблему, которую поднял ТС, и сам солидарен с его позицией. Но это цена за то, что разработка становится дешевле, а значит у пользователя появляется намного больший выбор ПО, которое он может использовать. Можно писать программу максимально близко к железу и упарываться по производительности, иногда это оправдано. Но тут приходит какая-нибудь фирма, и говорит "сколько стоит написать сайтик корпоративный? 50 тыс. руб.?? а что так дорого?!" и разрабочик берёт готовый фреймворк (раздутый потому что универсальный) и быстро пишет на нём этот сайт.
разработка точно не становится дешевле, и тем более чем 20 лет назад.
Ох, если всё время придумывать новый способ организации данных (виндовс, машем ручкой всем твоим разновидностям диалогов, некоторые до сих пор из 98/nt4. Кстати, это эталонная помойка, за которую часто любят ругать линуксовые смешивания kde/gnome приложений).
Хороший пример "удорожания" разработки - 20 лет назад приходилось брать 3D модель, делать развёртку и рисовать в каком-нибудь фотошопе текстуру по этой развёртке. Сейчас, в том же блендере можно взять картинку и тупо рисовать частью этой картинки в текстуру, используя проекцию окна. Это просто фантастика для 2000 года. Я уже молчу про перевод из фоток в 3D в каком-нибудь Meshroom. Да, там надо редактировать и делать по сути новую сетку, но! это уже очень легко делается по готовым поверхностям в пространстве. 3D скульптинг - тоже "магия", когда с планшета просто "рисуешь", а не кропотливо решётку с нуля фигачить.
Но смысл изначально был в другом. У вас новый функционал, полезный и разнообразный. Хоть и раздутый код для его реализации. Я не знаю, может быть в фотошопе это оправдано, но калькулятор, который раньше ел меньше мегабайта, а сейчас за раз отъедает за 150 мегабайт оперативной памяти при таком же функционале - это действительно просто неприлично уже. В посте это и рассматривается, что крохотная приложенька делала то же самое, что и 200+ мегабайт и 2700 файлов.
Они же в составе ОС, зачем они отдельно? Да и крайне сомнительно, что поддержка тача увеличит код на 40-50 мегабайт
telegram.ext только ради Updater и CommandHandler. Почему не написали свою обвязку? Это же пара сетевых вызовов, ради которых вы инклюдите в проект большую библу, функционал которой на 99% не используете.
В соседнем файле для парсинга даты фиксированного формата вы юзаете
dateutil.parser. Это вместо того, чтобы написать простой regexp. А ради парсинга пары аргументов запуска, юзаете argparse в котором еще тонна ненужного вашему софту функционала.Вы когда этот код писали, вам кто на ухо мантры для остановки размышления начитывал? :)
Я понимаю, сторонние пакеты, но чем вам argparse-то не угодил? Он же в стандартной библиотеке, так что по-любому есть всегда и нисколько не увеличивает конечный объём приложения — глупо отказываться от предоставляемого им функционала даже «ради парсинга пары аргументов запуска».
Если отложить в сторону рантайм, а распространять скриптом/исходником, а не инсталлером/дистрибом, исходя из того, что питон (со стандартной библой) есть на целевой тачке, тогда ваше замечание в тему, но такое распространение — это частный случай. Ну и тут больше про win приложения, кмк, топят. Ну и весь мой коммент был не более, чем примером на скорую руку, но надеюсь суть я донес :)
Вы где грань проводите что еще можно, а что уже нельзя? К примеру, если telegram.ext можно, а qt нельзя, то как этому прийти?
При этом свой кейс вы оправдываете, а про остальные язвительно пишете "«Ты что! Не лезь! Сложно же, там тач, хайдипиай, конверсия валют и другие какие-то штуки важные»", удобряя это заключениями об остановке размышления современных программистов.
Вот это одна из главных причин (и на мой взгляд - уважаемая причина) неоптимизированного кода. Код нужен не чтобы красиво исполняться, а чтобы решать какие-то задачи, зарабатывать деньги. Если неоптимизированной код есть 4Gb RAM вместо 64Kb, и это стоит лишние 10-20 баксов в месяц (а приносит 10-20 тысяч баксов в месяц) - да и пусть!
Гораздо важнее стоимость разработки. И оплачиваемые человеко-часы, и скорость получения результата. Кривая и немного глючная криптобиржа, которую вы запустите в 2010 году покорит мир и принесет миллиарды долларов. Эталонная, которую вы бы начали в 2010, и допилили к 2022 - была бы мало кому не нужна, потому что рынок уже поделен.
Я для себя решил забивать не ресурсоемкость (хотя и люблю арендовать low-end VPSки за копейки), писать на Python. И для проектов с парой сотен пользователей - это вполне норм! Будет миллион пользователей - тогда, может быть и денег будет достаточно на железо или же перепишу 1% кода (самый ресурсожрущий) на чем-то более шустром.
А разве при распространении дистрибутивом стандартная библиотека режется? По-моему, она просто рядышком вся упаковывается, вот и всё.
Если мы говорим про размер дистриба, то чтобы ваша софтина поддерживала нужные фичи, вам придется заюзать какой-ить qt и прочие .net-ы, что увеличит размер дистриба.
Ну или можете написать все это сами.
Откуда 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, соответственно) и обе же требуют сред исполнения.
Умельцы даже сделали для дельфи библиотеки KOL/MCK, которые реализовывали графический интерфейс на винапи, сохраняя удобство VCL. Такие приложения весили от 12 кб.
VCL действительно тормозил на старом компьютере и жрал память как не в себя.
Чтобы сделать хороший "интуитивно понятный интерфейс", надо уметь делать хорошие интерфейсы. Это почти никак не связано с кодом.
Почему бы не совместить быструю разработку и адекватный по ресурсам фреймворк? Фреймворк это абстракция над ниже лежащим уровнем. Ситуация больше похожа на строительство абстракций над абстракциями. К примеру CMake генерирующий текста для разных билд систем. С каждой версией становится больше и сложнее и не удивлюсь если скоро выйдет новая тулза, которая генерирует текст для CMake, так как это проще, чем юзать сам CMake. Сама по себе задача, по сборке программ не изменилась, собрать программу, ну ок дополнительные телодвижения по интеграции, прогонов тестов(если они есть:))
Поменялось очень многое, начиная от более удобных и интуитивно понятных интерфейсов, не требующих чтения учебных пособий по ним, заканчивая возросшей функциональностью программ.
Вы знаете, вот по поводу более интуитивно понятных интерфейсов - не соглашусь! Взять "простейший" LightRoom или Krita - без чтения учебных пособий там даже файлик открыть не все в состоянии.
И да, лично был свидетелем, как парень лет 18-ти не смог сдать экзамен в ГАИ, где на экзаменационных местах, кажется, был запущен официальный портал с билетами в режиме киоска. Бедолага просто впервые увидел компьютерную мышь - первые пару минут он пытался тыкать пальцем в экран, а на рекомендацию тыкать не пальцем, а мышью, просто погрустнел лицом и вышел из аудитории. Вот такая интуитивная понятность бывает.
Давняя мудрость гласит, что действительно интуитивно-понятный интерфейс только у соски. А все прочие "интуитивные" вещи - уже основаны на каком-то обучении, культуре, традициях...
Бедолага просто впервые увидел компьютерную мышь
Ну если он к 18 годам не побывал даже в компьютерном классе в своей школе, и побоялся взять мышь в руки и попробовать ей воспользоваться, все вокруг только выиграли от того, что этот человек не будет выезжать на дорогу в качестве водителя, и он сам в том числе :)
Прикиньте если бы почти все популярные клиенты мгновенных сообщений были написаны на макросах word, на бейские, и поставлялись бы с копией ворда. Электрон — это вот настолько же нелепо.
whatsapp для компьютера - это электрон
Пользователю глубоко пофигу, на чем написано, лишь бы работало. А с копией ворда есть немало плюсов взаимной интеграции. Можно отправку сообщений из ворда автоматизировать не через гребанный API, а напрямую, например. Можно дорабатывать клиент под требования бизнес-процессов.
тут цепная реакция - новое ПО наращивает объем кода, пользователю приходится наращивать железо, как правило, с излишком от требований ПО. Новое ПО закладывается под излищки - нефиг оптимизировать, если ресурса и так полно, и на какой-то этапе ресурс исчерпывают, пользователь покупает новое железо.
А если не покупает и сидит на старых версиях - то начинают лезть вопросы совместимости форматов, сценариев, обязательно требуют для просмотра/проигрывания файла прикрутить свистоперделку, которую или не поставишь на старое железо\ОС, или жрет ресурс как не в себя.
А на деле даже в 2022 году сам Microsoft продаёт типа современные ноутбуки Surface Go, которые начинаются с 4 ГБ оперативной памяти, ставишь туда такие Slack, Discord и прочие шедевры и всё - приехали.
Меня больше бесит Teams, который суть — обёртка над браузером.
Но если аналогичные сервисы Google прекрасно работают из браузера, в т.ч. и из Firefox, то Teams не работает и требует запуска через приложение. Пусть горят в аду.
Собственно, в браузере он мне нравится больше, чем стэндэлон.
P.S. При открытии ссылки на конференцию Zoom тоже требует скачать программу без вариантов. Если обновить страницу, появляются варианты. Может, и тут так же.
В смысле: нельзя устроить аудио/видеоконференцию.
Zoom — нативный клиент, а Teams — Electron, поэтому ограничения кажутся искусственными.
Несмотря на то, что у Zoom нативный клиент, отличий в UX в браузерной версии я не нашел. Допускаю, что они есть, не суть.
Я, видимо, чего-то не понимаю, но... в браузерной версии Teams, точно как в десктопной, назначаю встречу, присоединяюсь и провожу видеоконференцию. С демонстрацией экрана.
Микрософт тупо проверяет User Agent. Если подставить юзер агент от хрома, то звонки магически начинают работать. Я сейчас точно не помню, я так делал примерно 2 года назад, но кажется проблемы были только с расшариванием экрана.
Насколько я помню, клиент электронной почты Outlook до сих пор рендерит html в письмах с помощью движка Word. Такие дела.
Видимо браузер, в итоге, оказался лучшим решениям для построения кроссплатформенных приложений. Что там конкурирует?
Мёртвые Adobe Flash/JavaFX?
Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год? Да так, что уже видно что это тенденция и не хочется инвестировать время в то, что через год закопают. Сколько их было и есть? Silverlight, WinForms, XAML, Xamarin, Avalonia, вот сейчас всех на MAUI перетягивают. Ждём следующую MS THE CURRENT THING, которая, конечно, опять будет лучше и на которую надо будет всем переползать, выбросив в мусор инвестиции своего времени в изучение всех предыдущих THING. Уверен, что забыл ещё с десяток "вот теперь точно последних кросс-платформенных фреймворков для создания приложений" от одних только MS. Они там вообще ку-ку?
Qt с их неудобными и дорогими лицензиями? И в целом есть ощущение, что проект перестал развиваться.
Гуггловый Flutter? Похоже, единственный адекватный вариант на замену электрону. Только за чей счёт будут переписываться тонны того, что кодеры сейчас ставят из npm - большой вопрос.
Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год?
Конкретно под винду — WinAPI работает и будет работать всегда. Тут как я с андроидом: все бесятся и носятся и обожают все эти гугловые абстракции и прочие jetpack compose, а я просто беру и использую всё системное.
Вы считаете так. А те, кто платят деньги за разработку, чтобы зацепить как можно больше пользователей и не имеют столько же бабла, сколько Uber или Facebook - считают иначе. :) Заплатить один раз на условном Unity/Flutter/Adaptive Web или заплатить много раз на iOS, Android, Win, Mac, Web - хм, что же выбрать?
WinApi работает. Но работает только на винде. Вопрос "только на винде" не стоит, потому что в мире существует не только винда. И ещё вопрос - зачем тогда Microsoft ТАК мечется? Есть же WinApi.
Вы считаете так
Да нет, все считают так. В мире приложений почти все ходовые приложения - нативные. Уже даже стартапы сразу пишут нативные приложения, потому что их потом при росте не нужно будет переписывать на нативные (а пользователи и разработчики обязательно попросят). Самые известные примеры - AirBnb (выкинули React Native) и Slack (переписали с Electron целиком).
В мире игр вообще кроссплатформенности почти нет. На моем маке могу запустить только 10% библиотеки Steam. Если "все считают", что кроссплатформенность нужна, то где версия под мак? Или под линукс без Proton?
Вы только что привели пример Slack, которые изначально писался как раз на Electron, чтобы писать код только один раз - для Web, а потом использовать его везде. Потом они заработали бабла и смогли себе позволить нативные приложения. Это уже опровергает тезис, что «все считают так». Именно Slack считал, что пока бабла нет, его надо экономить.
Не знаю насчёт AirBnb, они стартовали с React Native, или пытались удешевиться и ускориться за счёт него. Если пытались удешевиться и ускориться - значит всё не так прекрасно с нейтивами? А если же стартовали - это, опять же, опровергает тезис что «все считают так». Именно, что «все» (если не брать уже богатые компании или стартапы с бесконечным финансированием) сначала экономят деньги. А потом, когда денег становится много - пишут нэйтивы. Собственно, пример со слаком именно об этом. Насчёт AirBnb не возьмусь судить, не знаю истории.
Тут ещё вспоминается ClubHouse, который изначально был под iOS только. И много других iOS-only приложений, которые потом заходят на Android. И не пишут сразу на обе платформы, потому что денег делать одно и то же по 2 раза, наступать и исправлять двойные грабли (а в случае когда надо много платформ - многократные) просто нет.
Slack (переписали с Electron целиком).Разве его переписали на натив? Я помню, что читал, что да, они его переписали, но всё на том же чёртовом веб-стеке. Типа, вместо 2 гигов оперативки он теперь жрёт 500 мегабайт. Офигеть достижение для клиента мгновенных сообщений.
Кто будет оплачивать этот банкет?
Это всё прекрасные рассуждения, но ответьте: сколько будет стоить в описанном вами случае разработка одного приложения, которое должно работать как минимум под Linux, MacOS и Windows? А если оно же должно работать ещё и под Android? Как в этом случае помогает факт всегдашней работы WinAPI?
Безумно фрагментированные Microsoft'овские штуки, которые появляются и умирают каждый год? Да так, что уже видно что это тенденция и не хочется инвестировать время в то, что через год закопают. Сколько их было и есть? Silverlight, WinForms, XAML, Xamarin, Avalonia, вот сейчас всех на MAUI перетягивают.Silverlight — не предназначался для разработки настольных приложений, это плагин для браузера, его закопали вместе с другими плагинами для браузеров.
WinForms — уже 20 лет живёт и развивается, но он никогда не был кроссплатформенным, это изначально обёртка над классическим WinAPI.
Xamarin — для мобил, переродился в виде MAUI с поддержкой десктопа.
XAML — это язык разметки, который до сих пор используется в том же MAUI.
Avalonia — не имеет отношения к Microsoft.
Ну и надо не забывать что WPF жив здоров, хотя и не особенно приятен, но черт возьми, его пережил только winforms.
А зачем MS столько много всего для, по сути, одного и того же?
Нет, их создавали не для одного и того же. WinForms был тонкой обёрткой над WinAPI. Оно было создано во времена, когда у всех была одна и та же плотность пикселей, и справлялось плохо с нестандартными DPI. Классические API не позволяли вытворять всякие безумные вещи типа вращения контролов, ну назрела проблема с поддержкой нестандартных DPI, поэтому запилили WPF на базе DirectX. В WPF первая буква от слова Windows, оно тоже не планировалось кросс-платформенным (хотя это и осуществимо). UWP был (провалившейся) попыткой сделать новые нативные API и подсистему для Windows с системой прав как в Android и iOS, а не так, что всем приложениям сразу доступно почти всё. WinUI — библиотека новых нативных для Windows контролов, здесь опять ничего про поддержку других платформ.
Xamarin был разработан не в Microsoft, его купили и сделали бесплатным, когда Microsoft изменила курс на кроссплатформенность, но он был только для iOS и Android, и там надо было отдельно дизайнить приложение под разные платформы с использованием нативных контролов (самый правильный подход, ИМХО), только внутренняя логика приложения могла быть общей. На основе Xamarin был создан Xamarin.Forms для тех, кто не хотел отдельно дизайнить интерфейсы под iOS и Android. Этот проект оброс поддержкой десктопных платформ и переродился в виде MAUI — это первая разработка от Microsoft с заявленной кроссплатформенностью в том числе и для десктопных платформ. На Windows MAUI использует WinUI 3 для отображения контролов.
Кстати, Electron тоже принадлежит и разрабатывается в Microsoft, хоть и был изначально создан вне её. Microsoft достаточно большая, чтобы поддерживать и развивать сразу несколько технологий для кроссплатформенного GUI.
Спасибо за ликбез! Может есть ещё какие-то кросс-платформенные попытки от MS для десктопа?
В любом случае, судя по всеобщему огорчению, что много софта на электроне, электрон пока лидирует в деле кросс-платформенных десктопов... И на то есть причины, которые не решают другие фреймворки.
Ну и поддерживался Silverlight аж до октября 2021 года, то есть 14 лет. Правда, последние обновления с новыми фичами были в 2012, а потом только обновления с фиксами багов. Я сам рассматривал испольлзование Silverlight для админки CMS в 2010 году, но уже тогда было понятно, что он не жилец (как и Flash), поэтому мы взяли за основу популярный тогда Ext JS.
Если кому надо было десктопное приложение, брали полноценный WPF или WinForms.
А если кому надо было мультиплатформенное, то им предлагали Silverlight. Поэтому некорректно утверждать, что Silverlight не предназначался для разработки настольных приложений. Он пытался стать электроном своего времени :) Правда, даже flash больше преуспел. Ну так в том и претензия в комменте yokotoka была, что MS бросает развитие кучи своих продуктов.
Ну так в том и претензия в комменте yokotoka была, что MS бросает развитие кучи своих продуктов.А смысл развивать объективно ненужные продукты типа Silverlight? Он был изначально мертворожденным. Тут Microsoft сильно просчиталась. 5 лет вливала деньги в совершенно бесперспективную технологию (упорные!), и потом ещё 9 лет латали в ней дыры.
По-вашему она должна была закрыть глаза на реальность, что Silverlight провалился, что его почти никто не использовал даже после 5 лет вливаний денег? Они должны были не замечать, что что разработчики браузеров взяли курс на отказ от сторонних плагинов типа Flash и Silverlight, и упорно развивать технологию, которая вскоре просто не сможет выполнять свою основную функцию? Зачем? Чтобы оно работало только в IE на Windows?
Avalonia
Эцсамое, мы не Microsoft, мы сами по себе. Вот прям совсем отдельно, в порочащих связях с корпорациями замечены не были, беспощадны к врагам опенсорса. Не надо нас в очередь на кладбище проектов со всеми остальными ставить.
Прошу прощения, не знал, что Avalonia без MS. Тут пожелаю проекту только долгой и яркой жизни, развития и всех благ! Разделяю убеждение, что кросс-платформенный инструмент не имеет права быть не опенсорсным и принадлежать корпорациям.
Раздувание кода стало астрономическим