За счет чего более новые ОС Линукс требуют больше ресурсов ПК чем более старые?

ну, у каждой библиотеки свои плюсы. мне нравится musl.

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

Лююююююддддиииии... Вы разучились в аналитику?

Бери РСем 15й, бери дистры от шапки 5.2 до 9й, изучай «регрессии». Лучше бы какой реальный пенёк ммх, но если нет такого, можно и в эмуляторе.

Там всё, как на ладошках покушать принесли, только успевай чавкать... в смысле статистику снимать.

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

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

почему не MPV/mplayer?

Открываете любой дистрибутив в версии года 2010 и современный. И сидя с выпученными глазами узрите просто список процессов. Когда отойдете от колличества процессов, посмотрите сколько они жрут. Телеграмм 120 мб. Куча вкладок браузера, с открытыми по сути текстовыми страницами, 60 - 180 мб. В каком-то 2010 году ещё было веянье компов разлива пень-атлонХР-соплерон-семпрон с 256-384-512 озу с шикарными видухами на 16-32-64 мб и идешными жёсткими дисками, всякими максторами и плексторами, которые особенно в вариациях на 20-40-60 гигов были мягко говоря неспешными. Тогда сильно не разгонишся, ибо просто не будет работать, и всё. Но потом в одночасье, наверно, все разработчики закончили школу. Обновили компы до ультра-топа. И началась новая эра разработчиков, которые просто дописывают код как попало и их не смущает что их программа, которая раньше жрала 10 мб жрёт 500. Ну оперативы много, компы быстрые, время разработчика стоит дорого, а железо ничего. На том и порешыли.

атлонХР
512 озу

Мой i486 c 16мб озу всплакнул с этой игровой сборочки для детей...

1. Увеличение разрядности к 64 битам.

2. Больше распакованых текстур для быстрой анимации

3. Мнимое увеличение памяти за счет кешей - софт пользуется таким количеством памяти, которое ему доступно

Как раз текстуры должны быть упакованы в аппататно поддерживаемый видеокартой формат (dxtc). Распакованные медленнее работают, тк жрут больше пропускной способности видеопамяти.

Кстати тут становится видна очередная убогость линуксового гуя - иконки и прочее говно в нём на диске лежать во всяких png/svg а не в dxt*. Как и шрифты, хотя их можно было хотя бы для самых типичных размеров сразу отрендерить в текстурку с прозрачностью...

У программистов вообще. Плюс менеджеры ещё за спиной с графиками.

целевой аудитории

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

Ну и людям, не входящим в целевую аудиторию, не мешают сидеть на старых версиях софта.

но у меня Debian с консолькой использует всего 45 МБ примерно памяти

В 1997 году слака с иксами работала на 16Мб. (После напильника, но всё же).

svg а не в dxt*

Ты приравниваешь вектор к растровому битмэпу? SVG можно на любом DPI нарисовать не потеряв в качестве.

А что такое dxtc?

lossy texture compression algorithms

Сравни:

PNG uses DEFLATE, a non-patented lossless data compression algorithm

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

Недавно поставил Antix с IceWM на старенький ноут. Понравилось. Правда снес както странно попавшего в дистр слоняру файрфокса. Хромиумим вместо него оказался скромнягой ничего жрущим. Так что для ТС еще не все потерянно. :)

приравниваешь вектор к растровому битмэпу

Не я приравниваю, а уже используют набор png разных размеров, но этот момент ты почему-то упустил.

паршивых текстур

Каких паршивых? Только dxtc обычно и используется, на сраных иконках никто никакой разницы не видит (в игорях есть для примера наворченая гуйня).

За счет того, что погромисты нынешние — рукожопые обезьяны. И кодить не умеют!!!

Во времена Убунту 7.10 список процессов в диспетчере задач помещался на один экран. Сейчас он занимает 7 экранов, хотя ничего особенного не запущено.

Slackware64-current blackbox: список процессов занимает пол экрана.

на сраных иконках никто никакой разницы не видит

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

Какие все юзкейсы? У иконок один юзкейс - оказаться в видеопамяти в качестве текстурки (вполне возможно она на лету в dxt* уже и пережимается, каждый раз при загрузке).

городишь какие-то

Я ничего не горожу - это индустриальный стандарт, который неизбежно уже реализован в твоих видеодровах.

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

Спасибо! То есть сейчас качество кода и уровень программистов значительно ниже чем был во всех сферах раньше?

Спасибо, интересно!

Десктопный линукс в заметной степени пилится компаниями под корпоративных юзеров

И дебиан с убунту тоже?

качество кода и уровень программистов

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

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

Если он уже реализован в видеокарте, то выгоднее хранить картинки в lossless формате, чтобы не допустить lossy2lossy compression. Если он не реализован в видеокарте, то выгоднее хранить в lossless формате, чтобы не допустить lossy compression.

То есть твой dtx так или иначе в ауте, маня

Какой ещё lossy2lossy? DXTn заливается напрямую с диска в память видеокарты и она аппаратно на лету распаковывает, быстрее, чем читает уже распакованный из той же памяти.

не реализован

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

То есть если ты засунешь туда PNG-шку, то никакой компрессии и вовсе не будет. Че хвостом-то виляешь, пёс-барбос? Даже если видюха поддерживает быструю декомпрессию какого-то ущербного lossy формата - я не буду умышленно его использовать, я же не дурак.

А jpeg[/h264/mp3] почему-то все используют, больше чем png. Вот дураки-то!

А jpeg[/h264/mp3] почему-то все используют, больше чем png. Вот дураки-то!

Ну попробуй залить на лор скриншот в jpeg и посмотришь что тебе на это скажут.

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

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

если ты засунешь туда PNG-шку

При создании текстурки можно указать, чтобы дрова её сжали сами.

Просто потому что перешли на ot5 и gtk3 и потом ядро усложнили , но в основе идиот это gtk3 потому что gtk2 столько не жрет и хитрые корпорасты надо же им скрыть что на gtk2 тоже возможен hdpi и всякая всячина т.е от того что некий фаил с именем css отредактировался и поменял директорию с gtk2 на gtk3 он весить меньше не стал.

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

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

у mplayer/mpv нет гуи как такового, при запуске открывается окно с видео и mpv можно скриптовать с помощью lua, ещё у него есть ipc-сервер который принимает комманды в формате JSON. Возможность выводить видео напрямую через drm/kms, но это и VLC наверное умеет. В целом функциональных различий между ними немного, т.к. все на ffmpeg. mplayer вроде бы самый легковесный из трёх, mpv это форк mplayer'а и он самый популярный/активноразвивающийся из трёх.

В версии ядра 1.0 переключение задач выглядело так, а в версии 4.14 вот так.

Взято отсюда.

Сомневаюсь, что много кого устроит, чтобы убрали поддержку pthreads (tls) или сохранение sse* avx* регистров (которых не было во времена ядра 1.0) и так далее. Кроме того, новое железо делает это всё быстрее - на штеуде sunny cove обещают скорость сисвызовов быстрее, чем любых процев даже до заплаток от spectre/meltdown.

Юникод ещё в Plan 9 появился.

Unicode развивается. Ваш КО.

И дебиан с убунту тоже?

В дебиан практически нет своего софта (только сборка 3rd-party), а убунту — вполне.

От некоторых не совсем адекватных личностей даже слыхал, что саботажем кода занимаются шпионы SJW

в-третьих, так крупно гадить там, где делают бизнес корпорации — это точно не по силам нашим «друзьям»

А не проще ли предположить, что именно корпорации этим и занимаются? И никаких SJW не нужно.

А у корпораций мотив простой, как глоток водки морозным январским вечером — чтобы люди (и другие корпорации, помельче) покупали новое железо. Делали это постоянно. Считали, что по-другому нельзя. Ну и разумеется, это не только про линукс. Это про любые сколько-нибудь популярные системы.

слияние двух классических юниксов

Почти название эротического фильма...

Просто интересен механизм, почему так происходит?

Как обычно, это дилемма яйца и курицы. То ли потому, что сейчас в процессоре L3 кэша больше чем было ОЗУ на ПК где гоняли уже довольно зрелые дистры линукса и надо это аппаратное добро как то использовать, то ли наоборот. Никто не знает точно.

Кодеры любят измерять объём проведённой работы строчками кода

Ой, я вас таки умоляю. Не кодеры, а менеджеры, причём плохо понимающие специфику работы программерского труда.

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

соглашусь со всеми пунктами, кроме последнего, конспирологического.

пожалуй, можно добавить ещё разброд и шатания в сборках. когда разработчики не хотят открывать сорцы или тупо ленятся патчить код под нужные библиотеки и собирают бинари вместе со всем говном. и они тащат с собой кучу старых версий непонятно чего. получается прямо как маздай - dll-hell и вот это всё. собственно, от чего изначально уходили, к тому всё и скатывается. ещё и впаривают такие «пакетные» установщики левого бинарного софта как нечто годное.

еще некоторый материал на тему устаревания товаров

По ссылке какая-то вялая политкорректщина. Лучше о том же самом прочитать Введение в копроэкономику от Двух Капитанов (осторожно, по ссылке 5.1 — и похоже, я знаю, как зовут одного из капитанов...)

Можно на примере gtk2 vs gtk3.

а почему не gtk1 vs более новые версии?