Есть такое выражение - "ванильное ядро". Оно означает "чистое", "без примесей" ядро линукса с сайта www.kernel.org, то есть без каких-либо изменений в исходном коде. Большинство разработчиков дистрибутивов изменяют исходники, дабы добавить какой-нибудь дополнительный функционал, исправить ошибки или еще что-нибудь. Не обошлось без этого и в убунте, где в ядро добавлено много своих и сторонних патчей. К сожалению, в интернете очень тяжело найти весь перечень этих патчей, я лично так и не нашел, поэтому пришлось разбираться самому.
Вот только то, что я сумел откопать:
* UnionFS (www.filesystems.org/project-unionfs.html) - "вспомогательная файловая система для Linux и FreeBSD, производящая каскадно-объединённое монтирование других файловых систем." Применяется в LiveCD убунты - так как LiveCD в режиме только для чтения, а некоторые файлы все равно должны изменяться в процессе работы системы - эта ФС записывает измененные файлы в оперативную память, а система видит эти измененные файлы, как будто они записаны в файловой системе LiveCD. То есть совмещает две ФС в одну.
* Aufs (aufs.sourceforge.net) - тоже самое, что UnionFS, только считается чуть лучшим
* SquashFS - ну об этом уже много раз писал...
* compcache (code.google.com/p/compcache) - сжимает данные в разделе подкачки, тем самым экономит оперативную память
пятница, 26 июня 2009 г.
вторник, 23 июня 2009 г.
SquashFS. Тестирование
В тестировании использовалось ядро 2.6.30 с поддержкой squashfs версии 4.0 и утилиты squashfs-tools тоже версии 4.0. Естественно, как обычно тесты просто "посмотреть", но все равно полезно интересующимся.
Для тестирования взял каталог /usr почти на свеже-установленной системе, размером в 2076824Кб, почти в два гигабайта. Сжал в образ squashfs вот так:
То есть используя параметры по умолчания (размер блока - 128кб). Файловая система создалась за 6 минут и 4 секунды. Файл usr.sqs сжался до размера 683924Кб. Следовательно, размер файла сократился ровно в три раза, что есть очень сильно... С использованием других параметров, особо ничего не изменилось (даже размер блока в мегабайт не дал особых результатов).
Ладно, скорость сжатия не низкая, несмотря на сильное сжатие. Но интересней больше скорость чтения, по теории она должна быть выше, чем работа с файлами на обычной файловой системе. На практике это подтвердилось. На копирование всех файлов с подмонтированной squashfs ушло 2 минуты и 18 секунд, а на копирование всех тех-же файлов с каталога /usr ушло 4 минуты и 58 секунд. Однако в первом случае, возросла нагрузка на процессор - в среднем 30%, а во втором случае - всего 8%. То есть, теория подтвердилась полностью, но нагрузка на процессор с использованием squashfs не такая уж сильная.
В итоге, пока так и не стало все полностью понятным. В интернете отсутствует подробная информация. Но по крайней мере понятно то, что squashfs справляется со своими задачами очень даже хорошо. На данный момент, на сколько я понял, утилиты squashfs и сама поддержка файловой системы в ядре, сжимают информацию с использованием gzip, когда как раньше были патчи, позволяющие использовать lzma. Буду копать дальше...
Для тестирования взял каталог /usr почти на свеже-установленной системе, размером в 2076824Кб, почти в два гигабайта. Сжал в образ squashfs вот так:
sudo mksquashfs /usr /usr.sqs
То есть используя параметры по умолчания (размер блока - 128кб). Файловая система создалась за 6 минут и 4 секунды. Файл usr.sqs сжался до размера 683924Кб. Следовательно, размер файла сократился ровно в три раза, что есть очень сильно... С использованием других параметров, особо ничего не изменилось (даже размер блока в мегабайт не дал особых результатов).
Ладно, скорость сжатия не низкая, несмотря на сильное сжатие. Но интересней больше скорость чтения, по теории она должна быть выше, чем работа с файлами на обычной файловой системе. На практике это подтвердилось. На копирование всех файлов с подмонтированной squashfs ушло 2 минуты и 18 секунд, а на копирование всех тех-же файлов с каталога /usr ушло 4 минуты и 58 секунд. Однако в первом случае, возросла нагрузка на процессор - в среднем 30%, а во втором случае - всего 8%. То есть, теория подтвердилась полностью, но нагрузка на процессор с использованием squashfs не такая уж сильная.
В итоге, пока так и не стало все полностью понятным. В интернете отсутствует подробная информация. Но по крайней мере понятно то, что squashfs справляется со своими задачами очень даже хорошо. На данный момент, на сколько я понял, утилиты squashfs и сама поддержка файловой системы в ядре, сжимают информацию с использованием gzip, когда как раньше были патчи, позволяющие использовать lzma. Буду копать дальше...
SquashFS. Введение
В ядро версии 2.6.29 внесли наконец поддержку squashfs. Это значит, что теперь эта файловая система поддерживается в самом ядре, без дополнительных патчей.
SquashFS - это файловая система, наподобие CramFS и Cloopfs. Эта файловая система поддерживает сжатие, причем даже уже мое любимое - LZMA. Применяется в основном на livecd и во встраеваемых устройствах. Работает только в режими чтения, то есть, внести новый файл или уже изменить существующий "на лету" никак не получиться.
Вы можете встретить ее на обычном livecd диске убунты. Файл SquashFS-образа находиться в папке casper на диске с убунтой и называется filesystem.squashfs. Если в ядре есть поддержка данной файловой системе, то вам достаточно лишь примонтировать этот файл, как вы монтировали когда-то обычные ".iso" образы:
В каталоге /mnt вы увидете структуру каталогов обычного дистрибутива линукса. Это и есть дистрибутив убунты. Убунту грузиться с компакт-диска монтирует данный файл и с помощью chroot запускает уже целиком систему. Если же вы начали инсталлировать убунту, то инсталлятор просто копирует содержимое данного файла на корневой раздел вашего винчестера. Ну дальше он доставляет некоторый софт, конфигурирует систему и т.п.
Получить файлы из этой файловой системы можно и другим способом. Помимо реализации самой данной файловой системы, существуют так-же и утилиты для управления ею. Скачать их можно отсюда. Они, конечно, есть и в стандартном репозитарии убунты:
Но эти утилиты и сама ФС в убунте обновлялись очень давно. В дистрибутиве до сих пор используется версия SquashFS за 2007 год, когда уже актуальная вышедшая в этом году четвертая версия. Поэтому лучше всего использовать ядро выше версии 2.6.29 и утилиты компилить вручную. Ну по крайней мере до тех пор, пока это чудо не обновиться в убунте.
Так вот, с помощью утилиты mksquashfs можно с легкостью создать данную файловую систему:
Или распаковать ее:
Преимуществ у данной ФС много. Помимо всего прочего - она использует очень сильное сжатие. Файлы сжимаются в два-три раза, причем на довольно высокой скорости. Чтобы достать один файл, не нужно распаковывать всю файловую систему целиком (как это делается с обычными архивами - tar.bz2 и т.п. - попробуйте распаковать всего один самый маленький файл из архива с исходниками ядра), а достаточно лишь ее подмонтировать. Скорость распаковки тоже впечатляет. Да и операции с файлами на такой ФС быстрее, так как файлы занимают в дво-трое меньший размер, чем в реальности. То есть скорость того-же копирования - в два-три раза быстрее, чем с обычной ФС. Из недостатков только то, что операции с файлами на данной ФС больше используют мощности процессоров, но на современных компьютерах это не заметно, а на встраеваемой технике обычно размер играет большее значение.
SquashFS - это файловая система, наподобие CramFS и Cloopfs. Эта файловая система поддерживает сжатие, причем даже уже мое любимое - LZMA. Применяется в основном на livecd и во встраеваемых устройствах. Работает только в режими чтения, то есть, внести новый файл или уже изменить существующий "на лету" никак не получиться.
Вы можете встретить ее на обычном livecd диске убунты. Файл SquashFS-образа находиться в папке casper на диске с убунтой и называется filesystem.squashfs. Если в ядре есть поддержка данной файловой системе, то вам достаточно лишь примонтировать этот файл, как вы монтировали когда-то обычные ".iso" образы:
mount -o loop /media/cdrom/casper/filesystem.squashfs /mnt
В каталоге /mnt вы увидете структуру каталогов обычного дистрибутива линукса. Это и есть дистрибутив убунты. Убунту грузиться с компакт-диска монтирует данный файл и с помощью chroot запускает уже целиком систему. Если же вы начали инсталлировать убунту, то инсталлятор просто копирует содержимое данного файла на корневой раздел вашего винчестера. Ну дальше он доставляет некоторый софт, конфигурирует систему и т.п.
Получить файлы из этой файловой системы можно и другим способом. Помимо реализации самой данной файловой системы, существуют так-же и утилиты для управления ею. Скачать их можно отсюда. Они, конечно, есть и в стандартном репозитарии убунты:
apt-get install squashfs-tools
Но эти утилиты и сама ФС в убунте обновлялись очень давно. В дистрибутиве до сих пор используется версия SquashFS за 2007 год, когда уже актуальная вышедшая в этом году четвертая версия. Поэтому лучше всего использовать ядро выше версии 2.6.29 и утилиты компилить вручную. Ну по крайней мере до тех пор, пока это чудо не обновиться в убунте.
Так вот, с помощью утилиты mksquashfs можно с легкостью создать данную файловую систему:
mksquashfs /usr /usr.squashfs
Или распаковать ее:
unsquashfs /media/cdrom/casper/filesystem.squashfs -d /ubuntu_live
Преимуществ у данной ФС много. Помимо всего прочего - она использует очень сильное сжатие. Файлы сжимаются в два-три раза, причем на довольно высокой скорости. Чтобы достать один файл, не нужно распаковывать всю файловую систему целиком (как это делается с обычными архивами - tar.bz2 и т.п. - попробуйте распаковать всего один самый маленький файл из архива с исходниками ядра), а достаточно лишь ее подмонтировать. Скорость распаковки тоже впечатляет. Да и операции с файлами на такой ФС быстрее, так как файлы занимают в дво-трое меньший размер, чем в реальности. То есть скорость того-же копирования - в два-три раза быстрее, чем с обычной ФС. Из недостатков только то, что операции с файлами на данной ФС больше используют мощности процессоров, но на современных компьютерах это не заметно, а на встраеваемой технике обычно размер играет большее значение.
пятница, 19 июня 2009 г.
Снова ".deb" и lzma
В сети пока не легко найти инфу по архиватору lzma, который вроде не такой уж новый, но популярность начал обретать лишь недавно. Мой скрипт по перепаковки ".deb" пакетов из bz2/gz в lzma слишком сырой и кривой. Однако не только я, оказывается, интересовался этой проблемой. Есть уже более подробная информация и более подробным сравнением. Встречайте:
https://wiki.ubuntu.com/dpkg-lzma
воскресенье, 14 июня 2009 г.
Отключение надоедливого спикера
Жутко раздражает меня эта пищалка. Отключается довольно просто - надо всего-лишь выгрузить модуль "pcspkr". То есть:
Но это отключит его только на данный сеанс, чтобы отказаться вообще от этой пищалки, открываем файл
И в конец добавляем строчку "blacklist pcspkr". Сохраняем и перезагружаемся, дабы проверить.
sudo modprobe -r pcspkr
Но это отключит его только на данный сеанс, чтобы отказаться вообще от этой пищалки, открываем файл
sudo gedit /etc/modprobe.d/blacklist.conf
И в конец добавляем строчку "blacklist pcspkr". Сохраняем и перезагружаемся, дабы проверить.
пятница, 12 июня 2009 г.
Скрипт для перепаковки ".deb" пакетов
Вот составил черновой вариант. Пользоваться так:
#!/bin/bash
PACKAGE=$1
PACKAGENAME=`basename ${PACKAGE}`
TMPDIR=/tmp
BUILDDIR=`echo ${PACKAGENAME} | sed s/".deb"/""/g`
mkdir ${TMPDIR}/${BUILDDIR}
cp ${PACKAGE} ${TMPDIR}/${BUILDDIR}
mv ${PACKAGE} `echo ${PACKAGE} | sed s/".deb"/"_old.deb"/g`
cd ${TMPDIR}/${BUILDDIR}
ar x ${PACKAGENAME}
mkdir DEBIAN
if [ -f control.tar.gz ]
then
tar zxf control.tar.gz -C DEBIAN
rm control.tar.gz
fi
if [ -f data.tar.gz ]
then
tar zxf data.tar.gz
rm data.tar.gz
fi
if [ -f control.tar.bz2 ]
then
tar jxf control.tar.bz2 -C DEBIAN
rm control.tar.bz2
fi
if [ -f data.tar.bz2 ]
then
tar jxf data.tar.bz2
rm data.tar.bz2
fi
rm debian-binary ${PACKAGENAME}
cd ${TMPDIR}
dpkg-deb -b -z9 -Zlzma ${BUILDDIR} `echo ${PACKAGE} | sed s/".deb"/"_lzma.deb"/g`
rm -rf ${TMPDIR}/${BUILDDIR}
deb_lzma_repack.sh /полный/путь/до/пакета/пакет.debКод:
#!/bin/bash
PACKAGE=$1
PACKAGENAME=`basename ${PACKAGE}`
TMPDIR=/tmp
BUILDDIR=`echo ${PACKAGENAME} | sed s/".deb"/""/g`
mkdir ${TMPDIR}/${BUILDDIR}
cp ${PACKAGE} ${TMPDIR}/${BUILDDIR}
mv ${PACKAGE} `echo ${PACKAGE} | sed s/".deb"/"_old.deb"/g`
cd ${TMPDIR}/${BUILDDIR}
ar x ${PACKAGENAME}
mkdir DEBIAN
if [ -f control.tar.gz ]
then
tar zxf control.tar.gz -C DEBIAN
rm control.tar.gz
fi
if [ -f data.tar.gz ]
then
tar zxf data.tar.gz
rm data.tar.gz
fi
if [ -f control.tar.bz2 ]
then
tar jxf control.tar.bz2 -C DEBIAN
rm control.tar.bz2
fi
if [ -f data.tar.bz2 ]
then
tar jxf data.tar.bz2
rm data.tar.bz2
fi
rm debian-binary ${PACKAGENAME}
cd ${TMPDIR}
dpkg-deb -b -z9 -Zlzma ${BUILDDIR} `echo ${PACKAGE} | sed s/".deb"/"_lzma.deb"/g`
rm -rf ${TMPDIR}/${BUILDDIR}
Сборка ".deb"-пакета с использованием lzma-сжатия
Решил попробовать собрать ".deb"-пакет с использованием lzma, вместо стандартного gzip и популярного bzip2. Взял уже готовый пакет с новым ядром линукса, который был в bzip2, распаковал его и собрал заново, но уже с параметрами lzma.
Вот так вот выглядит сборка:
"dpkg-deb -b -z9 -Zlzma linux-image-2.6.30-generic_i386/ linux-image-2.6.30-generic_i386.deb"
Где "-z9" - это степень сжатия, "-Zlzma" - тип сжатия.
Пакет собрался ровно за 2 минуты.
Установился обычной командой "dpkg -i linux-image-2.6.30-generic_i386.deb", всего за 13 секунд (Пакет можно устанавливать и двойным кликом или другим способом - он по-сути ничем не отличается от обычных пакетов).
Пакет с использованием bzip2 собрался за 16 секунд (конечно быстрее, чем lzma), а установился за 16 секунд.
А с gzip - почему-то собрался за 54 и установился за 18 секунд.
Разница в размере - 24Мб у пакета с использованием bzip2, 27Мб с gzip и 20Мб у пакета с использованием lzma. Что странно, пакет с использованием bzip2 собирается быстрее и быстрее ставиться, чем с gzip. А вот пакет с lzma-сжатием ставится быстрее всех, но дольше собирается.
Обычный пользователь и не заметит, с помощью какого архиватора создан пакет, который он устанавливает, но разницу в размере заметят все.
Выводы делайте уже сами)
Вот так вот выглядит сборка:
"dpkg-deb -b -z9 -Zlzma linux-image-2.6.30-generic_i386/ linux-image-2.6.30-generic_i386.deb"
Где "-z9" - это степень сжатия, "-Zlzma" - тип сжатия.
Пакет собрался ровно за 2 минуты.
Установился обычной командой "dpkg -i linux-image-2.6.30-generic_i386.deb", всего за 13 секунд (Пакет можно устанавливать и двойным кликом или другим способом - он по-сути ничем не отличается от обычных пакетов).
Пакет с использованием bzip2 собрался за 16 секунд (конечно быстрее, чем lzma), а установился за 16 секунд.
А с gzip - почему-то собрался за 54 и установился за 18 секунд.
Разница в размере - 24Мб у пакета с использованием bzip2, 27Мб с gzip и 20Мб у пакета с использованием lzma. Что странно, пакет с использованием bzip2 собирается быстрее и быстрее ставиться, чем с gzip. А вот пакет с lzma-сжатием ставится быстрее всех, но дольше собирается.
Обычный пользователь и не заметит, с помощью какого архиватора создан пакет, который он устанавливает, но разницу в размере заметят все.
Выводы делайте уже сами)
четверг, 11 июня 2009 г.
Тестирование производительности архиваторов
Вступление
В линуксе архиваторы существуют уже давно как часть GNU утилит. Ими сжимается образ ядра, мануалы, пакеты и много чего другого. Они призваны экономить место на носителях данных.
Сейчас, наиболее популярными архиваторами в линуксе являются gzip, bzip2 и сравнительно более новый архиватор - lzma. Поддержка всех этих трех архиваторов уже есть в новом ядре и в некоторых пакетных менеджерах, таких как dpkg. Это значит, что вы можете сжать ядро, чтобы оно меньше занимало места на носителе (удобно для встраеваемых устройств). Так-же, в том же дистрибутиве Ubuntu используются ".deb" пакеты, в которых находятся сжатые файлы (сами бинарники программы, документация и т.п.). В основном, для содержимого ".deb" пакетов используется gzip. Но при создании пакетов, давно можно использовать уже bzip2 или lzma. Пакет будет выглядеть как обычно и устанавливаться как обычно, измениться лишь его размер и скорость установки, в зависимости от архиватора.
Меня заинтересовала идея сжать свой репозитарий, чтобы он меньше занимал место на компакт-диске, чтобы на один диск поместилось больше пакетов. Но для начала, нужно было сравнить производительность этих архиваторов. В интернете полно информации по этому поводу и полно самих тестов и их результатов. Но я решил опробовать все на своей машине.
Тестирование
Был взят, как обычно, архив исходников свежего ядра, упакованный в ".tar".
Размер файла - 337Мб
Процессор на тестируемой машине: Intel Core 2 Duo E2160 1.80ГГц
Оперативная память: 1024Мб
Результаты
Быстрое сжатие (-1):
Сильное сжатие (-9):
Вывод
LZMA все-таки годится для создания пакетов. Он очень медленно сжимает, если использовать сильное сжатие (10 минут, против двух минут у bzip2 и неполной минуте у gzip), зато сжимает сильнее всех архиваторов, да и разница очень ощутима (47Мб против 57Мб у bzip2 и 73Мб у gzip). То есть, пакеты все-таки будут занимать гораздо меньше места. Но, все-таки, скорость распаковки тоже влияет на выбор архиватора. Вот в этом lzma преуспел - он распаковывает почти в три раза быстрее bzip2 и лишь чуть-чуть медленнее gzip.
Одним словом, lzma выиграл по всем параметрам у bzip2, кроме скорости сжатия. И то только при сильном сжатии, при слабом сжатии lzma сжимает быстрее bzip2, но при слабом сжатии почти не заметна разница в размере сжатого файла. GZIP сильно проигрывает всем архиваторам по размеру сжатого файла, но зато он сжимает и распаковывает быстрее всех.
ИМХО, лучше я потрачу несколько часов для перепаковки всех пакетов в lzma, но сэкономлю много места и при этом не проиграю в скорости установки этих пакетов.
В линуксе архиваторы существуют уже давно как часть GNU утилит. Ими сжимается образ ядра, мануалы, пакеты и много чего другого. Они призваны экономить место на носителях данных.
Сейчас, наиболее популярными архиваторами в линуксе являются gzip, bzip2 и сравнительно более новый архиватор - lzma. Поддержка всех этих трех архиваторов уже есть в новом ядре и в некоторых пакетных менеджерах, таких как dpkg. Это значит, что вы можете сжать ядро, чтобы оно меньше занимало места на носителе (удобно для встраеваемых устройств). Так-же, в том же дистрибутиве Ubuntu используются ".deb" пакеты, в которых находятся сжатые файлы (сами бинарники программы, документация и т.п.). В основном, для содержимого ".deb" пакетов используется gzip. Но при создании пакетов, давно можно использовать уже bzip2 или lzma. Пакет будет выглядеть как обычно и устанавливаться как обычно, измениться лишь его размер и скорость установки, в зависимости от архиватора.
Меня заинтересовала идея сжать свой репозитарий, чтобы он меньше занимал место на компакт-диске, чтобы на один диск поместилось больше пакетов. Но для начала, нужно было сравнить производительность этих архиваторов. В интернете полно информации по этому поводу и полно самих тестов и их результатов. Но я решил опробовать все на своей машине.
Тестирование
Был взят, как обычно, архив исходников свежего ядра, упакованный в ".tar".
Размер файла - 337Мб
Процессор на тестируемой машине: Intel Core 2 Duo E2160 1.80ГГц
Оперативная память: 1024Мб
Результаты
Быстрое сжатие (-1):
| Архиватор | Сжатие (время) | Распаковка (время) | Размер сжатого файла | |
| gzip | 0m13.035s | 0m7.899s | 91M | |
| bzip2 | 1m22.186s | 0m22.271s | 69M | |
| lzma | 0m44.433s | 0m12.920s | 66M |
Сильное сжатие (-9):
| Архиватор | Сжатие (время) | Распаковка (время) | Размер сжатого файла | |
| gzip | 0m47.401s | 0m7.102s | 73M | |
| bzip2 | 1m51.064s | 0m28.974s | 57M | |
| lzma | 9m56.781s | 0m10.475s | 47M |
Вывод
LZMA все-таки годится для создания пакетов. Он очень медленно сжимает, если использовать сильное сжатие (10 минут, против двух минут у bzip2 и неполной минуте у gzip), зато сжимает сильнее всех архиваторов, да и разница очень ощутима (47Мб против 57Мб у bzip2 и 73Мб у gzip). То есть, пакеты все-таки будут занимать гораздо меньше места. Но, все-таки, скорость распаковки тоже влияет на выбор архиватора. Вот в этом lzma преуспел - он распаковывает почти в три раза быстрее bzip2 и лишь чуть-чуть медленнее gzip.
Одним словом, lzma выиграл по всем параметрам у bzip2, кроме скорости сжатия. И то только при сильном сжатии, при слабом сжатии lzma сжимает быстрее bzip2, но при слабом сжатии почти не заметна разница в размере сжатого файла. GZIP сильно проигрывает всем архиваторам по размеру сжатого файла, но зато он сжимает и распаковывает быстрее всех.
ИМХО, лучше я потрачу несколько часов для перепаковки всех пакетов в lzma, но сэкономлю много места и при этом не проиграю в скорости установки этих пакетов.
среда, 10 июня 2009 г.
Установка ядра 2.6.30 в Ubuntu
Предисловие (можно пропустить :) )
Есть большое количество способов установить самое свежее ядро в дистрибутивах линукса. Самое популярное из них - это скачивание исходников самого последнего ядра, конфигурирование и компилирование.
Но дистрибутив Ubuntu цениться своей легкостью и удобством. Многие забывают об этом и собирают ядра в этом дистрибутиве из исходников. Конечно, это очень полезный процесс - можно сконфигурировать ядро так, как вам этого хочется, использовать самое главное преимущество линукса - гибкость. Но, как было однажды сказано на linux.org.ru - "Одним движением make install любой дистрибутив превращается в слаку" (После установки софта таким способом из исходников, этот самый софт потом тяжело удалить, обновить или вообще проводить какие-либо операции, то есть исчезает одно преимущество линукса - менеджер пакетов больше не сможет управлять программой, установленной таким способом). Этот недостаток можно решить сборкой из исходников .deb пакета, с помощью некоторых утилит. Но есть способ проще...
Простая установка свежего ядра в дистрибутиве Ubuntu
Разработчики данного дистрибутива сами собирают свежие ядра, дабы радовать пользователей и испытывать эти ядра на этих самых хомячках, то есть пользователях. Пакеты лежат в виде .deb файлах, рассортированных по папкам с версиями ядер, на вот этой странице:
http://kernel.ubuntu.com/~kernel-ppa/mainline/
Собственно, сама установка ядра 2.6.30:
Скачиваем три вот этих файла в любую папку:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-image-2.6.30-020630-generic_2.6.30-020630_i386.deb (~24 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630_2.6.30-020630_all.deb (~8.8 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630-generic_2.6.30-020630_i386.deb (~598 Кб)
Последние два файла нужны в основном для сборки других программ и драйверов, не вошедших в ядро, но при любом раскладе, советую их ставить тоже.
Если у вас 64х битная система, замените в ссылках "i386" на "amd64".
Все скаченные файлы можно теперь установить по порядку, дважды кликнув по ним.
Можно так-же установить их в консоли всего одной коммандой:
На вопрос "что делать с файлом menu.lst" отвечаем, чтобы "установил версию из пакета". Не волнуйтесь, он не заменит целиком старый файл новым, он просто обновит его - добавит все ядра, установленные в вашей системе с параметрами по умолчанию. Если вы изменяли файл "/boot/grub/menu.lst", например, удаляли в нем в параметрах ядра слова "splash", можно просто сделать так, чтобы при любом автоматическом обновлении файла "menu.lst", использовались только ваши параметры. Перед установкой нового ядра, откройте файл "/boot/grub/menu.lst" с правами рута:
Заключение
В общем, это все. Скачать три файла и кликать по ним по два раза. С более новыми ядрами или более старыми с сайта "kernel.ubuntu.com" поступать точно так-же.
Есть большое количество способов установить самое свежее ядро в дистрибутивах линукса. Самое популярное из них - это скачивание исходников самого последнего ядра, конфигурирование и компилирование.
Но дистрибутив Ubuntu цениться своей легкостью и удобством. Многие забывают об этом и собирают ядра в этом дистрибутиве из исходников. Конечно, это очень полезный процесс - можно сконфигурировать ядро так, как вам этого хочется, использовать самое главное преимущество линукса - гибкость. Но, как было однажды сказано на linux.org.ru - "Одним движением make install любой дистрибутив превращается в слаку" (После установки софта таким способом из исходников, этот самый софт потом тяжело удалить, обновить или вообще проводить какие-либо операции, то есть исчезает одно преимущество линукса - менеджер пакетов больше не сможет управлять программой, установленной таким способом). Этот недостаток можно решить сборкой из исходников .deb пакета, с помощью некоторых утилит. Но есть способ проще...
Простая установка свежего ядра в дистрибутиве Ubuntu
Разработчики данного дистрибутива сами собирают свежие ядра, дабы радовать пользователей и испытывать эти ядра на этих самых хомячках, то есть пользователях. Пакеты лежат в виде .deb файлах, рассортированных по папкам с версиями ядер, на вот этой странице:
http://kernel.ubuntu.com/~kernel-ppa/mainline/
Собственно, сама установка ядра 2.6.30:
Скачиваем три вот этих файла в любую папку:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-image-2.6.30-020630-generic_2.6.30-020630_i386.deb (~24 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630_2.6.30-020630_all.deb (~8.8 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630-generic_2.6.30-020630_i386.deb (~598 Кб)
Последние два файла нужны в основном для сборки других программ и драйверов, не вошедших в ядро, но при любом раскладе, советую их ставить тоже.
Если у вас 64х битная система, замените в ссылках "i386" на "amd64".
Все скаченные файлы можно теперь установить по порядку, дважды кликнув по ним.
Можно так-же установить их в консоли всего одной коммандой:
dpkg -i linux-*-2.6.30*.deb
На вопрос "что делать с файлом menu.lst" отвечаем, чтобы "установил версию из пакета". Не волнуйтесь, он не заменит целиком старый файл новым, он просто обновит его - добавит все ядра, установленные в вашей системе с параметрами по умолчанию. Если вы изменяли файл "/boot/grub/menu.lst", например, удаляли в нем в параметрах ядра слова "splash", можно просто сделать так, чтобы при любом автоматическом обновлении файла "menu.lst", использовались только ваши параметры. Перед установкой нового ядра, откройте файл "/boot/grub/menu.lst" с правами рута:
sudo gedit /boot/grub/menu.lstИ найдите там строчку:
# defoptions=Добавьте туда только ваши личные параметры или вообще удалите все значения, если они вам не нужны. Раскоментировать строчку не надо, она нужна только для автоматического обновления (изменения) этого файла. То есть, приведя эту строчку к такому виду:
# defoptions=noresumeДля всех установленных ядер будут применяться параметр noresume и вам больше не придется редактировать этот файл.
Заключение
В общем, это все. Скачать три файла и кликать по ним по два раза. С более новыми ядрами или более старыми с сайта "kernel.ubuntu.com" поступать точно так-же.
Вышло ядро Linux 2.6.30
Торвальдс сделал мне подарочек на мой день рождения - сегодня зарелизилось новое ядро - 2.6.30))
Изменений много, тупо копировать не будут, дам лишь ссылки:
http://www.opennet.ru/opennews/art.shtml?num=22084 - на русском языке
http://kernelnewbies.org/Linux_2_6_30 - более полный список изменений на английском языке
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро (Торвальдс пока на главной странице не выложил)
http://mirror.yandex.ru/kernel.org/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро с зеркала на яндексе
http://kernel.ubuntu.com/~kernel-ppa/mainline/ - а вот здесь скоро должен появится бинарный пакет с новым ядром. То есть это для тех, кому лень компилить. Пакет от самой убунты и для самой убунты.
P.S.: Скоро буду тестить производительность в сравнении с ядром 2.6.28 (то есть дефолтным).
Изменений много, тупо копировать не будут, дам лишь ссылки:
http://www.opennet.ru/opennews/art.shtml?num=22084 - на русском языке
http://kernelnewbies.org/Linux_2_6_30 - более полный список изменений на английском языке
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро (Торвальдс пока на главной странице не выложил)
http://mirror.yandex.ru/kernel.org/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро с зеркала на яндексе
http://kernel.ubuntu.com/~kernel-ppa/mainline/ - а вот здесь скоро должен появится бинарный пакет с новым ядром. То есть это для тех, кому лень компилить. Пакет от самой убунты и для самой убунты.
P.S.: Скоро буду тестить производительность в сравнении с ядром 2.6.28 (то есть дефолтным).
Подписаться на:
Сообщения (Atom)