Arch Linux на Acer Extensa 4220 (Core 2 Duo T6570)

Я тоже, и меня запишите!

Это ТС`у, который по твоим словам мучается. )

Где ты мучения увидел?

Я использовал на своей древности reiser4 и btrfs со сжатием. По скорости +- одинаково.

А вот ssd дал хорошего пинка системе. А главное - на 3 гигах памяти в своп лезть стало сильно быстрее)

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

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

Я у тебя спросил, за счёт чего конкретно будет достигнуто ускорение, а ты пошел какие-то религиозные бредни писать.

Иди голову полечи.

может поэтому он такой слоупочный даже без браузера? )

Он их жмёт когда RAM заканчивается, а не на каждой операции IO.

может поэтому он такой слоупочный даже без браузера? )

Ждём от тебя видео.

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

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

так там же 3гига всего, они же сразу и заканчиваются прямо в процессе закрузки. многие дистры отказываются грузится если в системе менее 2гигов рама

видео чего ты так жаждешь от меня?

Я не win10 гружу, чтобы она 2000 метров сожрала на старте. Там 300 или 400 метров используется.

нудануда. но ты как использовать то будешь это изделие? вот загрузил систему оно сожрало 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, вынесший туеву хучю модернизаций, с ХР и БилдеромСи++ на борту. Федорный ЛивЦД на ём також небыстрый.

Чутка попозжее водружу на него чё-нить *никсоподобное, возможно даже Фрю. Ну, после того, как свои вендовые поделки перенесу на платформу посвежее, нежели ХР.

Ого, кто-то еще помнит билдер)

Ну а чо, норм же тема была, не?

Говорят, оно всё ещё дрыгается жыво. По крайней мере я скачивал на рабочий комп Trial-версию, норм вполне. Дрова компилялись))

btrfs со сжатием

Я путем долгих экспериментов пришел к выводу, что использовать сжатие кроме 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 вкладок до начала сброса данных на диск. А ведь это ещё не финишь, только начао трудностей.

давай посчитаем

Видяха там еще отожрёт себе кусок, не забывай.

В пределах погрешности. Физической то там 3072 а не 2900.

В пределах погрешности.

До 256 метров, ЕМНИП.

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