Все разумно расписал, только не учел, что на данном ноуте уже используется сжатие. И жмет именно core2duo. Да, не файловую жмет, а всего лишь данные в ram.
ахахахаха ну так всегда я уже привык.
это не тролинг, но действительно, словами не описать того опыта которого у тебя нет, видосик не передаст. это нужно локально просидеть прочувствовать.
засчет чего быстрее. все просто. их, ядра всмысле, собирают под современое железо которое дохренапоточное, плюс к этому потоки у них не равнозначные, чтобы оно адекватно работало на современом железе прикручен большой и сложный механизм оптимизации всего этого зоопарка. Для 20 поточного с ддр5 накладные расходы ничтожны в сравнении с прибавкой. А вот для древнего c2d эта вся хуеверть абсолютно бессмыслена но создает существеный лаг.
нудануда. но ты как использовать то будешь это изделие? вот загрузил систему оно сожрало 300м и все? и больше ты с этим ничего не делаешь, типа обогревателя и светильника да? ты ж начнешь там какой то софт запускать да? чето делать как то пользоватся. ну и кончатся твои 3гига моментально глазом не успеешь моргнуть. и полезет оно все в пожатый своп лагать и тормозить.
«Да карочи если ядро пересобрать, то всё будет быстрее, патамушта на непересобранном ядре медленнее. Там это карочи таво, многоядерность, вот эта вот, поэтому аптимизация, ИММОЛЕЙТ ИМПРУВЕД, ты понял да? А вы ни шарити. Какие опции я вам ни скажу, потому что вы вендузятники слепошарые всё равно не поймёте величие линукса своими глазами залитыми, а мне еще попонтоваться надо!»
Ну понятно.
так всегда я уже привык
Привык, что если ведёшь себя как м***к, то к тебе так и относятся. Логично.
Воткни туда дешёвый ssd гигов на 128-256 и не мучайся.
Я наверное туда в качестве эксперимента свой терабайтник Крушиал воткну на время. Потому что пока я дойду до магазина и куплю SSD, еще полгода пройдёт)
ну какое найх сжатие. там нужно максимальное разжатие чтобы ему считать как можно меньше было.
«Нужно максимальное разжатие (c)». Есть семейство дистров, а-ля Puppy Linux, там файловая сжата в squashfs-архивы. И вот эта фича (помимо фс в ram) считается конкурентным преимуществом, особенно для непроизводительного железа на медленных HDD.
Если у кого желание проверить на древнем железе, с которого уже сыпется песок, и сравнить производительность с привычными дистрами - easy-5.6.4-amd64.img.
Записать с dd на флешку, загрузиться с нее, при старте запустится скрипт который разобьет флешку на два раздела и отформатирует. В итоге, полноценная система с возможностью записи сессии.
(Это дистр от BarryK, отца-основателя Puppy, который официально отошел от дел, но постоянно ‘мутит’ разные задумки в плане Linux.)
Я насколько понимаю, там еще фишка в том, что если у тебя ОС лежит в виде нескольких ro-образов, то ты не будешь сталкиваться с фрагментацией ФС.
Я тут пытался эксперимент поставить.
Есть один каталог на HDD с тысячами файлов. И вот если его открывать в stuurman, он настолько долго читает содержимое каталога, что успевает перейти в режим показа прогресса загрузки в строке состояния. (На быстрых операциях он это не использует, чтобы интерфейсом не моргать.)
Чтобы можно было записывать это на видео (не показывая там личные данные), я пытался накидать аналогичное количество файлов в новый каталог, но он читает его достаточно быстро, чтобы отстреляться до обновления строки состояния. Потому что нет фрагментации.
У мну е Асер Эспайр 5315, вынесший туеву хучю модернизаций, с ХР и БилдеромСи++ на борту. Федорный ЛивЦД на ём також небыстрый.
Чутка попозжее водружу на него чё-нить *никсоподобное, возможно даже Фрю. Ну, после того, как свои вендовые поделки перенесу на платформу посвежее, нежели ХР.
Я путем долгих экспериментов пришел к выводу, что использовать сжатие кроме zstd:3 не имеет смысла. У меня есть тестировачный дамп SQL в 25 гигов, с zstd:3 он ужимается в 9 раз, с zstd:8 в 11, но скорость записи падает на порядок, нагрузка на проц увеличивается в три раза, казалось бы а какая разница, но у меня из 150 данных, сжатые это где-то 40 гигов, ну сэкономия 3-4 гигов мало что меняет. Так как сжатие нельзя применить к большинству типов данных: музыка, картинки, видео - они уже сжатые. И выходит, что фича та крутая, но малоприменима, вот без сжатия у меня бы было занято 200 гигов вместо 150, а с другой стороны - отпадает необходимость вообще всякие папочки архивировать, можно про это забыть раз и навсегда.
Если жать каким нибудь lzma - тогда да, там будет 1,5-10 Мб/с. Но есть всякие lzo/lz4 которые будут сжиаться по гигабайту в секунду, что может только ускорить работу диска если звёзды сойдутся.
Прежде чем пересобирать ядро - нужно значь чего ты там хочешь поменять и зачем. Будь это какой нибудь raspberry pi 2/3, можно было бы выиграть немного производительности за счёт серверного режима переключения задач + снизито до 100Гц таймер прерываний... Короче ценой отзывчивости.
А вот в обратную сторону, больше отзывчивости - хрен накрутишь. Всякие pf-sorces работали далеко не у всех и больше как плацебо. Всякие там анти-спектры отключаются без пересборки.
Настройка типа цпу генерик/интел/амд особо ничего не даёт.
Ничего фантастичного, Core 2 + пара ГБ оперативки + любой дешманский SSD + Linux с лёгковесным рабочим столом = вполне юзабельная система… если браузер не запускать) или хотя бы открывать не более одной вкладки.
alex0x08 удивлялся, что на таком железе Линукс просто работает без танцев с бубном для оптимизации. Мне теперь интересно посмотреть, что там в BSD. Вроде тоже никаких преград не должно быть для аналогичного результата.
И что конкретно ты предлагаешь? Ядро 3.10 или лучше 2.6.32? Я как то пропустил момент, когда появился выбор и настройка цпу-шедулера или как он там правильно называется.
Нормально там с кучей вкладок. Да, это правда, каждая конкретная вкладка на старых ядрах рисуется долго, но ночто не мешает открывать их пачкой в фон и потом смотреть когда прорисуются. И это всё ещё лучше чем на большинстве arm. А на арм не так уж плохо.
Когда я пробовал FreeBSD - стандартная система с KDE почему-то потребляла в 2 (два, Карл!) раза больше оперативки, чем Linux, и знатно тормозила. Да и в целом я не раз слышал, что BSD ощутимо медленнее Линуксов.
Звиздишь как дышишь. И видео не смотрел, там после загрузки 300_с_чем_то Мб и не более трети-четверти с учётом всего дискового кеша. А в своп он вообще полез только после запуска файерфокса с кучей вкладок и потом гимпа с мегафоткой.
Дело не в 3Гб, дело в медненном i/o и в том, что современный веб написан под более быстрые цпу. С ЛОРом то 0 проблем.
чето делать как то пользоватся. ну и кончатся твои 3гига моментально глазом не успеешь моргнуть
Ну, давай посчитаем. 350М системы, 300М ядра фокса, по 150М в среднем на вкладку. 20 вкладок. Итого 3650М. Сколько у нас есть? 1500 зрам которые займут ~500М физических. 1500+2900-500=3900М в наличии.
Вывод: машинка как раз на 20 вкладок до начала сброса данных на диск. А ведь это ещё не финишь, только начао трудностей.