Спустя менее чем три месяца с момента выхода прошлой версии 2.6.32 (http://www.opennet.me/opennews/art.shtml?num=24504), Линус Торвальдс представил (http://lkml.org/lkml/2010/2/24/301) следующий релиз Linux ядра - 2.6.33 (http://www.kernel.org/). В новое ядро принято 11708 исправлений от 1354 разработчиков, размер патча - 54Мб (добавлено 869 тыс. строк кода, удалено - 489 тыс.).
Основные новшества (http://kernelnewbies.org/Linux_2_6_33):- Дисковая подсистема, ввод/вывод и файловые системы
- В состав ядра принят код DRBD (http://www.drbd.org/), реализация распределенного реплицируемого блочного устройства (RAID-1 по сети);
- Из ядра удалена поддержка планировщика ввода/вывода Anticipatory Scheduler, вместо него рекомендуется использовать CFQ;
- В ядро интегрирована система "Block I/O controller", предназначенная (http://lwn.net/Articles/360958/) для организации ограничения пропускной способности блочных устройств. Одно из наиболее интересных применений разра...
URL: http://lkml.org/lkml/2010/2/24/301
Новость: http://www.opennet.me/opennews/art.shtml?num=25565
pread*(), теперь вот recvmsg().. похвально. Предвижу в версии 2.6.40 появление recvfrom() и sendmsg().
> pread*(), теперь вот recvmsg().. похвально. Предвижу в версии 2.6.40 появление recvfrom() и sendmsg().
> Добавлен новый системный вызов recvmsg(), позволяющий организовать получение в рамках
> одного системного вызова сразу нескольких сообщений, которые ранее потребовали бы
> отдельных вызовов recvmsg().Я так понимаю POSIX уже не котируется?
Котируется, но сам факт появления системных вызовов BSD спустя 20-25 лет в линуксе умиляет.
не-не.
В новости просто ошибка.
Новый сискол не recvmsg, а recvmmsg!
Ага, вот это совсем другое.
Судя по патчу, некий враппер для recvmsg() для заряжения приема данных за один вызов.
http://patchwork.ozlabs.org/patch/33726/
А в 2.6.45 MessageBox() ;)
>Статус модуля для карт ATI Radeon изменён с экспериментального на стабильный;А у меня HD2600xt AGP все еще ни в какую не хочет работать.
почему? у меня дома на компе проблем нет. проверь:
cat /var/log/Xorg.0.log | grep EE
Да, а в 3.0.12 будет QObject::connect(object1,SIGNAL(msg()),object2,SLOT(rcvmsg()));
да! :)
Ух ты, они ещё разогнали reiserfs v3 на на многоядерных и многопроцессорных системах. Круто.
Собрал 33-е, первое что заметил -- скайп перестал звук поганить ^_^ Люблю это ядро.
>Compcache - система для организации хранения содержимого системных кэшей в сжатом виде.Кто-то это уже пробовал, на сколько оно эффективно?
>>Compcache - система для организации хранения содержимого системных кэшей в сжатом виде.
>
>Кто-то это уже пробовал, на сколько оно эффективно?Я пробовал на системе PII 300, 160Mb RAM. Выделил 32MB под compcache. В итоге стало чуть полегче с памятью(а соответственно временем запуска), особенно Firefox и OpenOffice.org. Замеров не проводил - все субъективно. Попробуйте, вроде бы не сложно.
У меня на n810 compcache прикручен - реально заметно. Необходимая технология, где I/O медленный
Что-то я не совсем понял фишку compcache: свап используют, когда не хватает оперативки. А в данном случае количество оперативки ещё уменьшают за счёт свапа-в-памяти-с-компрессией? Или эта штука показывает перфоманс только когда "немного нехватает памяти"? У меня, например, celeron-M-1500 + 1.5G RAM, окружение лекговесное (xfce), swap - 512, который почти никогда, как я вижу по датчикам, не используется. Используется он реально, если я прогу написал с мэмори-ликом, или когда открываю какую-нибудь тяжеловесную картинку в GIMP. Как я понимаю compcache мне не поможет? Или я не прав? Какие у него юс-кейсы?
ммм. у модуля ramzswap есть настройки, позволяющие задать предел (по дефолту, емнип, 15%), до которого будет применяться компрессия в памяти, а после - своп на задаваемое в тех же параметрах устройство.
если собрано не модулем, см. страницу проекта и тарболл, там утилита есть.
Интересно, а какая оптимальная конфигурация, например, в моём случае? 1.5 GB RAM (800 из которых /tmp TMPFS) + 512 SWAP?
И ещё... почему бы в обычный свап не ложить сжатые страницы?
>Интересно, а какая оптимальная конфигурация, например, в моём случае? 1.5 GB RAM
>(800 из которых /tmp TMPFS) + 512 SWAP?Полагаю, это можно посчитать, собрав данные по использованию свопа.
>И ещё... почему бы в обычный свап не ложить сжатые страницы?
Не реализовал никто. Наверное потому, что дисковые гигабайты нынче дешёвые. Смысл compcache, он же не в экономии дискового пространства, а в том, чтобы до определённого предела, при незначительном использовании свопа, избежать дисковых операций вообще.
Вот только то, что включено в ядро, работает несколько кривовато. Оно вроде бы есть, но его вроде бы и нет. Разумнее собирать оригинальный тарболл (модуль ramzswap.ko + rzscontrol) и пользоваться ими. Навроде
modprobe ramzswap num_devices=1 backing_swap=/dev/mapper/luksswap
mkswap /dev/ramzswap0
swapon /dev/ramzswap0
А зачем Anticipatory Scheduler убрали? Застарелый баг с iowait вроде профиксили, по крайней мере в 12 федоре уже не ощущается, однако на десятой именно этот планировщик выручал.
CFQ он тоже anticipatory, только еще более продвинутый.
>CFQ он тоже anticipatory, только еще более продвинутый.И сильнее всех подвержен багу.
>А зачем Anticipatory Scheduler убрали? Застарелый баг с iowait вроде профиксили, по
>крайней мере в 12 федоре уже не ощущается, однако на десятой
>именно этот планировщик выручал.«Профиксили», ага… 2.6.32 — на месте, никуда не делся…
Когда можно будет начать использовать юзеру, начиная с 2.6.33.1, 2.6.33.2 или 2.6.33.3 - в плане безопасности в сети и закрытию уязвимостей?
Лол! Каждый сам для себя решает когда можно.
Самое интересное:
1. Безопасность - не какой-то окончательный результат выбитый в камне а непрерывный процесс. Как борьба брони и снаряда.
2. А что, в линуксе есть сильно крутые дыры с сетью? Припоминаются только какие-то досы на экзотичных протоколах раз в сто лет. Это так уж страшно? oO
еще вспоминается менее пол года назад ping-of-death в linux.
когда ядро умирало от специально фрагментированого icmp..
или icmp - это уже экзотика ?
а давайте на пруфлинк посмотрим?
http://www.linux.org.ru/news/security/4333485Если вы об этом, то это не ICMP. Впрочем, тоже неприятная штука.
1. В каком месте там ICMP был? Нельзя ли пруфлинк на то как линуксное ядро icmp-ом завалили не далее чем полгода назад?
2. Если посмотреть новости, можно пожалуй и про других узнать что-нить интересненькое. Особенно на тематических ресурсах. Например припоминается как крЮтые Juniper-ы с правильной операционкой что-то уходили в ребут от специфичных пакетиков :).
3. По мере нахождения грабля была запатчена. Как ни странно, все остальные делают точно так же. Что-то не так? Или вы это так, потроллить? :) Кстати запатчили вообще в RC версии, если меня не глючит (приветы Zenitur'у).
Кому-нибудь известно, какой код удаляют в основном? Выходящих из моды устройств типа COM-мышек и ISA-звуковых карт?
Удаляют в процессе "написания" с заменой на новые строчки" или тот, который требует продолжения разработки, но не поддерживается. Драйвера на устаревшее оборудование не трогают - работают замечательно и кушать не просят =)
Ладно тогда. А то я уже огорчился...
так вы же часто компилируете, там в конфигурационнике обычно написано: deprecated если что-то выкидывается.
в-основном, не удаляют, а заменяют (правят баги и т.д.)
>в-основном, не удаляют, а заменяют (правят баги и т.д.)Иногда переводят на новые подсистемы.
Например, вместо пяти разных больших участков кода, делают один большой и пять маленьких, которые его используют)
не вполне понятен прогиб под проприетарную вмварь :(
Опен то опен но кушать все хотят, даже опен.
Потому кто платит, тот и музыку заказывает.
а! Piter_Ring нашёл крючок за который хоть как-то можно зацепиться? :Dзы:
но радоваться вам пока рановато. по вашему (закрыто/открытому) пути никто не пошёл.
сами дрова VWware Virtual GPU для акселерации графического вывода открыты.
и никто не мешвет задействовать их например в kvm.
>Опен то опен но кушать все хотят, даже опен.
>Потому кто платит, тот и музыку заказывает.Почему бы и не включить GPL-ный код?! Он актуален и облегчает жиизнь прользователям несвободной программы. Драйвер NVIDIA же тоже несвободен, но я уверен, просьбы его создателей учитываются разработчиками ядра.
>Драйвер NVIDIA же тоже несвободен, но я уверен, просьбы его создателей учитываются разработчиками ядра.Уверенность это хорошо, но не всегда. NVIDIA это одна из самых гнусных анти-FOSS компаний, никогда не стеснявшаяся этого.
Интересно, а кто по вашему развивает ядро? По-моему почти на 100% это коммерческие компании. Если ядро не будет представлять коммерческого интереса - не будет и его развития, т.к. платить за его разработку будет некому.
> Интересно, а кто по вашему развивает ядро? По-моему почти на 100% это коммерческие компании.на 85%.
http://lwn.net/Articles/372938/
>не вполне понятен прогиб под проприетарную вмварь :(Чтобы форточник запустил образ убунты под вмварью и почувствовал комфорт, скорость и красоту, которая была ему недоступна. И начал бы задумываться.
Хотя в общем случае ты прав, прогибаться под проприетарщика стратегически не верно, особенно когда есть более качественные и удобные OSS альтернативы.
>В состав ядра включены два драйвера для оптимизации работы гостевых окружений в системе виртуализации VMwareударение на слове "гостевых". после осмысления на слове "драйвера".
зы:
"фирма <такая-то> написала открытый драйвер <такой-то>, который включили в состав ядра" - это уже прогиб под проприетарщиков? ну-ну.
а когда патч от мс брали это наверное вообще означает - "мс выкупила ядро линуха"? да?
> позволило частично повысить производительность reiserfs на многоядерных и многопроцессорных системах.vs.
This means that its SMP scalability is very poor. This release won't fix that issue
[...]
Due to the subtle semantics of the locking changes, some workloads may have small performance regressions and other have improvements.-- То есть, не только улучшения, но и ухудшения.
"частично повысить производительность"
????
потому что производительность повышается только при определенных условиях. ее нельзя увеличить сразу во всем. это надо так понимать.
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33Ой, и про меня не забыли :)
> agp/amd64: Remove GART dependency on AGP_AMD64
Долго сотрудник AMD сопротивлялся тому, что ихний IOMMU умеет работать без AGP :)
Так что, владельцы Turion/Athlon64/Opteron, кто юзает IOMMU,
можете смело вырубать AGP, конечно если его не используете.