В Linux ядре 2.6.21.2 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.21.2) исправлено около 70 ошибок в таких подсистемах, как Crypto API, CPUFREQ, NetFilter (*_conntrack, *_nat_proto_gre), JFS, USB HID, sky2, SPARC64, IpSEC, SCTP, IPV6, TCP, sata_via, libata, ALSA, md/raid1, UDF-fs, knfsd, ppp, reiserfs, ACPI и т.д.URL: http://www.kernel.org
Новость: http://www.opennet.me/opennews/art.shtml?num=10899
otlichno - teper' smotrish i Gre perestanet utuxat' :-)
вообще-то на кернел.орг уже 2.6.21.3 лежит...
Вообще-то уже скомпилён
Что-то вот только проект Layer7 Filter застопорился, последняя версия там 2.9. На кернел больше, чем 2.6.19 она не накладывается. Ужо предложили бы для включения в vanilla что-ли, IMHO весчь нужная в корпоративных сетях.
>Что-то вот только проект Layer7 Filter застопорился, последняя версия там 2.9. На
>кернел больше, чем 2.6.19 она не накладывается. Ужо предложили бы для
>включения в vanilla что-ли, IMHO весчь нужная в корпоративных сетях.они его пытаються переделать через netlink и в user space
так что патчи к ядру вскоре непонадобяться
Я раньше пользовал Layer-7 (старенькая заметка http://www.dzti.edu.lv/isp-serv/index.php?l=3),но потом отказался, можно и без него.
Например есть модуль connbytes, сколько байтов передано через сессию и с его помощью
можно ограничить прокачку больших файлов, так удобнее и проще.сижу пока на недавно установленном 2.6.20.11 (работает connbytes, connlimit,esfq) вчера попробовал 2.6.21.2 --> проблемы с IMQ, connbytes... просто зра потерянное время.
Где то читал в инете что для серваков лучше 2.6.(17 или 18 точно не помню) остановится.
Угу, а если тебе надо, например, аську закрыть, или еще чего-нибудь?..
Или Вы, сударь, полагаете, что аська с другими номерами портов работать не умеет? :)
Может проще вообще НАТ из корпоратива убрать? Просто сквид-прокси. :)
Так Аська и через Squid лезет без проблем, через 80-й к своим сервакам.
Ну так лезет то она не по ИП-никам. :) а по .icq.com
У меня не стояла задача закрытия всего и вся, а стояла задача как для большинства: дать интернет в локалку таким образом, чтобы люди могли качать мега или гига байтами и при этом у других интернет не тормозил из-за качек.Если в вашей задачей все отслеживать и закрывать, тогда наверно действительно лучше squid.
---------------------
А по поводу Layer-7
---------------------
"some users have reported kernel crashes when they using SMP with the kernel version of l7-filter."
По поводу ICQ (в Layer-7 это AIM ?) для aim скорость работы медленная или средняя
(Slow: >33 seconds --> Not so fast: 3.3–33 seconds.)
http-->(Slow: >33 seconds --> Not so fast: 3.3–33 seconds.)Тут я не знаток, но насколько понял если каждый раз при установленине соединения, придется запускать вначале проверку на HTTP (ведь через HTTP можно пропускать что угодно) а в случае если не сработало то AIM (ICQ) то при начале соединения интернет будет притормаживать (Кстате в моей конфигурации, которую описал в http://www.dzti.edu.lv/isp-serv/index.php?l=3#qs_markschema студенты жаловались что в начале сайт очень медленно начинает открываться а потом быстро грузится).
Потом Layer-7 не может отлавливать https.....
Да и вообще я пришел после всех экспериментов, что лучше всего это connbyte...
по портам выделяю DNS, HTTP, HTTPS если кто то много прокачивает через эти порты
данных то connbyte перекиывает в менее приоритетный класс в HTB.
Забыл добавить, что ситуация с начальной тормознутостью загрузки сайта усугубляется тем, что в одной страничке может быть много банеров, на каждый банер открывается своя сессия следовательно Layer-7 проверяет при открытии каждой сессии
HTTP ICQ .....Если я не прав, поправьте!
если внимательно ознакомиться с положением дел layer7, то разработчики хотят полностью перейти на userspace версию,которая не имеет зависимости от версии ядра и работает через NFQUEUE
Да, все хотят отвязаться от этого монстроидального ядра.
Может быть ещё при жизни Таненбаум получит признание.
>Да, все хотят отвязаться от этого монстроидального ядра.
И заодно от хардваре.>Может быть ещё при жизни Таненбаум получит признание.
Мгм. Предположение оказалось правильным.Видите ли, он и так уже получил заслуженное признание как выдающийся теоретик и неудачник-практик. Если бы не выпендривался, дело бы, пожалуй, ограничилось первым.
Как вы думаете, что раньше случится - Лайнус сменит архитектуру ядра, чтобы его части стали более независимыми друг от друга или у всех случится помешательство от постоянно пересобирания всего этого "большого куска" ?
для MINIX напишут win drivers host ;-)
Поищите по словам "in-tree drivers" и "stable kernel api", тема достаточно изжёванная.Вкратце (и в меру моего чайнического понимания) -- это вопрос не технический ("архитектура ядра"), а организационный ("архитектура управления"). По крайней мере постольку, поскольку ядро и так модульное больше десяти лет, при этом в его развитии участвует гораздо больше компетентного народу, чем в пожалуй что любом другом.
Не шибко давно после распила xorg на кусочки (включая драйверы) и опыта разработки/поддержки в таком виде тамошний люд пришёл к подозрению, что "linux kernel got it right" и содержать конкретно драйверы в одной ветке исходников -- сильно менее проблемно при изменениях в инфраструктуре как для обновления кода, так и для отлавливания протухлости оного.
А вот утверждений насчёт возможности большей параллелизации разработки тех же микроядер (с исходно относительно простыми модулями, но усложняющимся в геометрической прогрессии взаимодействии по мере роста числа объектов, которым надо уметь общаться) что-то пока не видать. Подтверждённых практикой.
>Поищите по словам "in-tree drivers" и "stable kernel api", тема достаточно изжёванная.Детали меня не интересуют. Мне и так всё ясно.
>Вкратце (и в меру моего чайнического понимания) -- это вопрос не технический
>("архитектура ядра"), а организационный ("архитектура управления"). По крайней мере постольку,
>поскольку ядро и так модульное больше десяти лет, при этом в
>его развитии участвует гораздо больше компетентного народу, чем в пожалуй что
>любом другом.Всё проще. Лайнус сам сказал, что ОС на микроядре они не потянут - много больше работать надо будет.
>Не шибко давно после распила xorg на кусочки (включая драйверы) и опыта
>разработки/поддержки в таком виде тамошний люд пришёл к подозрению, что "linux
>kernel got it right" и содержать конкретно драйверы в одной ветке
>исходников -- сильно менее проблемно при изменениях в инфраструктуре как для
>обновления кода, так и для отлавливания протухлости оного.Вернулись к тому, от чего бежали. Энтузиасты желали хорошего ПО, а когда начали уже писать решили не заморачиваться и делать как проще.
>А вот утверждений насчёт возможности большей параллелизации разработки тех же микроядер (с
>исходно относительно простыми модулями, но усложняющимся в геометрической прогрессии взаимодействии по
>мере роста числа объектов, которым надо уметь общаться) что-то пока не
>видать. Подтверждённых практикой.На пути к лучшему всегда много трудностей, они решаемы. У разработчиков Linux другая - они не видят концептуальной отсталости в своём продукте. Лечение начинается когда больной признаёт себя больным.
>> У разработчиков Linux другая - они не видят концептуальной
>> отсталости в своём продукте.
Можно на пальцах, в чем концептульно Линукс ядро неправильно,
и к чему это может привести через лет 5?Какой концептуальный подход Вы полагаете верным в мире разработчиков отурытых ядер?
>>> У разработчиков Linux другая - они не видят концептуальной
>>> отсталости в своём продукте.
>Можно на пальцах, в чем концептульно Линукс ядро неправильно,
>и к чему это может привести через лет 5?
>
>Какой концептуальный подход Вы полагаете верным в мире разработчиков отурытых ядер?Ядро должно быть ядром а не кучей всего. Драйверы должны быть отдельны, сервисы тоже. Тогда не будет всех этих глупых проблем. Такое разделение не только положительно скажется напрямую в работе ПО, но и заставит разработчиков тщательней продумывать интерфейсы между модулями и документировать их.
Ну что повторять-то, уже всё тысячу раз объясняли доказывали и показывали. Проблема в том, что до народа не доходит. Они уткнулись в свою писанину и у них времени нет посмотреть на своё чудо с точки зрения чужого опыта. Можно долго рассказывать о том, что и как сделать лучше, но смысла нет. Они элементарных кривых вещей не видят типа маразма от совмещения иерархии каталогов ФС с горизонтальными безклассовыми линками (Soft/Hard Links). Куда там предлагать более сложные вещи типа сменить C (на Bliss например), переделать IPC. Создать барьеры между OS и Apps, между самими Apps. А эти ну просто тупейшие заморочки с менеджерами пакетов ? Хотя всё это уже к ядру не относится, но имеет туже причину.
Куча существующих проблем может быть решена только большими измениями.
Самые плохие последствия для Linux/OpenSource это то, что талантливые опытные системные программисты (не я) хотели бы поучаствовать, но когда смотрят как там всё криво и всех это устраивает, отварачиваются. Делать в одиночку это ещё одна никому не нужная ОС.
>>Какой концептуальный подход Вы полагаете верным в мире разработчиков отурытых ядер?
И попрошу уточнить -- на основании какого практического опыта?>Ядро должно быть ядром а не кучей всего. Драйверы должны быть отдельны,
>сервисы тоже.
Мне оно ничего не должно, например. Хотя выбирается то, что работает.>Тогда не будет всех этих глупых проблем.
Тогда будет куча других, гораздо менее глупых и решаемых. По взаимодействию кусков.>Такое разделение не только положительно скажется напрямую в работе ПО, но и заставит
>разработчиков тщательней продумывать интерфейсы между модулями и документировать их.
Что характерно, разработчики не любят, когда их заставляют. Дальше рассказывать или сами уже догадались, сколько волонтеров так найдёте?>Ну что повторять-то, уже всё тысячу раз объясняли доказывали и показывали.
>Проблема в том, что до народа не доходит.
Что и до какого?>Они уткнулись в свою писанину и у них времени нет посмотреть на своё чудо с
>точки зрения чужого опыта.
А он работает вообще?>Можно долго рассказывать о том, что и как сделать лучше, но смысла нет.
Так эта. Посмотрел тут как-то на minix3, если Вы вот конкретно профессора перечитались и толкаете его мысли занедорого. Попробуйте там отстрелить драйвер tty для разнообразия.
>Они элементарных кривых вещей не видят типа маразма от совмещения иерархии каталогов ФС
>с горизонтальными безклассовыми линками (Soft/Hard Links).
Я тоже не вижу тут маразма. Работает и удобно.>Куда там предлагать более сложные вещи типа сменить C (на Bliss например)
Замените.>переделать IPC.
Переделайте.>Создать барьеры между OS и Apps, между самими Apps.
Создайте.>А эти ну просто тупейшие заморочки с менеджерами пакетов ?
>Хотя всё это уже к ядру не относится, но имеет туже причину.
Открыть Вам один маленький секрет?Быть треплом, которое лучше всех знает, кому чем заняться -- не работает. Хоть и семи пядей во лбу. Проверено.
Работает -- сделать что-то живое и опубликовать, плюс уважать право других на своё мнение и свои действия. Несмотря на многие несогласности, в этом из своего опыта с Линусом согласен на все сто.
>Самые плохие последствия для Linux/OpenSource это то, что талантливые опытные
>системные программисты (не я)
Так Вы системщик или нет? Если системщик -- идите помогите тому же Таненбауму или вон AtheOS поковыряйте. Если нет -- можете поверить (тоже несистемщику и тоже с претензией на аналитический склад ума), можете проверить сами, но цена Вашему вышеизложенному мнению на практике -- ломаный грош. Вроде как человек неглупый, надеюсь, поймёте правильно.
Интересно есть ли на данный момент в мире попытки создать правильное (с точки зрения концепции) ядро ОС, на базе уже написанного кода ядра линукса?И что бы на этом ядре могли работать уже написанные программы под Линукс, или что бы можно было сделать типа
rpmbuild -ta xxxx.src.fc6 --target=PRAVILJNOE_JADRO :)
PS
МОжет недостатком концеции ядра линукса стало то, что в начале неопределились что надо иметь и рамки за которые не нельзя выходить (это на тему что изменения в ядре делают неработоспособными код уже написанных драйверов и такие патчи как patch-o-matic, IMQ, и тому подобное)
2.6.12.2 был решающим апгрейдом для меня т.к. из-за бага в sis900 (Ethernet) не мог сойти с 2.6.11 - висла наглухо. Теперь все нормально и не нарадуюсь CONFIG_NO_HZ.commit 83eaefe01d85bff38ee9b520ef40d0f308b73643
Author: Neil Horman <nhorman@tuxdriver.com>
Date: Thu Apr 26 13:47:36 2007 -0400[PATCH] sis900: Allocate rx replacement buffer before rx operation
Вот вам для развлечения:
From: "Yaroslav Bilozor" <aslav@basic.maxnet.ru>Hi All,
коммент сабжевой статьи с лора. местами - хоть в фак добавляй ;-)
Краткое содержание для тех, кто по ссылкам не ходит:
1) Число багов в ядре растет, API нестабильный.
2) Опенсорс означает, что дыры в безопасности надо латать ОЧЕHЬ быстро.
Опенофис чинить не хотят.
3) Патенты -- зло и глупость несусветная. Особенно американские.
4) Патенты -- зло и глупость несусветная. Особенно американские.
5) Патенты -- зло и глупость несусветная. Сделка Microsoft-Novell -- тоже.
6) Борьба за GPLv3 бесполезна. Такую б энергию да на развитие HURD.
7) RHEL -- единственный прибыльный дистрибутив.
8) Hет ни "RPM hell", ни "DEB hell". Зато полно проблем с менеджерами пакетов
и левыми репозиториями.
9) Дистрибутив должен иметь стабильную ветку. Как Slackware, Debian, RHEL...
10) Зря все увлекаются 3D-десктопами. Минимализм рулит.
11) В Freepire сделали полурута. Это -- дыра в безопасности ради удобства, шаг
в сторону Windows и начало конца для всех.
12) Sun -- не друг опенсорсу. Потому, что занят зарабатыванием денег.
13) Mono -- дрянь. Ей не догнать джаву и питон, а PHP популярнее. Бигль --
кривулина, gnome-search-tool был лучше.
14) Ubuntu врёт о сертификатах, Novell пользуется MS Office, а Red Hat забыл
про лицензии BSD и MIT
15) С документацией плохо.
16) Баги не чинят. Или чинят, но не так.
17) Разработчики Дебиана совсем охренели.
18) С патентованными кодеками всё плохо.
19) Зря в ядре 2.6.20 переименовали hda в sda. (Правда что ли?!?!?)
20) Является ли ядро 2.6.16 стабильным на ближайши%
20) Является ли ядро 2.6.16 стабильным на ближайшие 2-3 года?
21) КДЕ и Гном будут воевать вечно.
22) BSD рулит. Особенно OpenBSD.
23) Зря форкнули X.org/XFree86, зря форкнули cdrkit/cdrtools, а Apache 2.0
может сам себя заDoSить.
24) hibernation и standby не работают.
Извините, но это не фак, а полубред. Особенно плохо то, что в нём где-то до трети внятных утверждений перемешаны с третью жёсткого бреда и третью просто глупостей.Отфильтровать никак не получалось?
>Отфильтровать никак не получалось?:) это уже отфильтрованное.
Вы прослушали икзекьютив резюме статьи The Sorry State of the Open Source Today
http://beranger.org/feature/sorryfeature.php
Там еще один пунктик в резюме надо было добавить: "Уже сейчас ясно, что все это будет глючить и тормозить"
>>Отфильтровать никак не получалось?
>:) это уже отфильтрованное.
Боюсь, не столько отфильтрованное, сколько намешанное. Как понимаю, ими, а не Вами.>Вы прослушали икзекьютив резюме
it's called executive summary btw>статьи The Sorry State of the Open Source Today
>Там еще один пунктик в резюме надо было добавить: "Уже сейчас ясно,
>что все это будет глючить и тормозить"
Так это как раз один из пунктиков "от лохов".Может быть, им даже сейчас ясно, что все они сдохнут и никто их не вспомнит; а вот линуксы у меня после довольно унылого переезда на 2.6.x (когда действительно _прибавилось_ и глюков, и тормозов) порезвели назад примерно на 2.6.16 и glibc-2.5 (плюс когда в альте внедрили по умолчанию сборку с -Wl,--as-needed и хлам в виде лишних прилинкованных "заодно" библиотек, как в большинстве Обычных Дистрибутивов (ТМ), не стал ни загружаться с диска, ни висеть в памяти). Что весьма сильно порадовало, а то чуть в такие же лохи с упадническими настроениями не подался.
Для них ведь всё просто обязано тормозить по возрастающей, потому что им положено бабло на апгрейд отстёгивать не тогда, когда осмысленно воспользоваться дешёвыми гига{герцами,байтами}, а просто шоб не тормозило. ;o)
У нас же исторически принято пользоваться головой, а не только в неё есть.
у меня на ноуте новые ядра нестабильны,ака 2.6.21 2.6.21.1
ругаются clocksource tsc unstable и намертво виснут
посижу пока на 2.6.20