|
| 1.6, Лимуриец (?), 09:29, 25/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что-то вот только проект Layer7 Filter застопорился, последняя версия там 2.9. На кернел больше, чем 2.6.19 она не накладывается. Ужо предложили бы для включения в vanilla что-ли, IMHO весчь нужная в корпоративных сетях.
| | |
| |
| 2.8, pavel_simple (ok), 10:52, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Что-то вот только проект Layer7 Filter застопорился, последняя версия там 2.9. На
>кернел больше, чем 2.6.19 она не накладывается. Ужо предложили бы для
>включения в vanilla что-ли, IMHO весчь нужная в корпоративных сетях.
они его пытаються переделать через netlink и в user space
так что патчи к ядру вскоре непонадобяться | | |
| 2.9, andyS1976 (??), 10:53, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Я раньше пользовал 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 точно не помню) остановится.
| | |
| |
| 3.11, sabitov (??), 11:07, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
Угу, а если тебе надо, например, аську закрыть, или еще чего-нибудь?..
Или Вы, сударь, полагаете, что аська с другими номерами портов работать не умеет? :) | | |
| |
| 4.15, sash (??), 12:23, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Может проще вообще НАТ из корпоратива убрать? Просто сквид-прокси. :) | | |
| 4.21, andyS (?), 13:54, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
У меня не стояла задача закрытия всего и вся, а стояла задача как для большинства: дать интернет в локалку таким образом, чтобы люди могли качать мега или гига байтами и при этом у других интернет не тормозил из-за качек.
Если в вашей задачей все отслеживать и закрывать, тогда наверно действительно лучше 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.
| | |
| |
| 5.22, andyS (?), 14:06, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
Забыл добавить, что ситуация с начальной тормознутостью загрузки сайта усугубляется тем, что в одной страничке может быть много банеров, на каждый банер открывается своя сессия следовательно Layer-7 проверяет при открытии каждой сессии
HTTP ICQ .....
Если я не прав, поправьте! | | |
|
|
|
| 2.14, HFSC (??), 12:10, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
если внимательно ознакомиться с положением дел layer7, то разработчики хотят полностью перейти на userspace версию,которая не имеет зависимости от версии ядра и работает через NFQUEUE | | |
| |
| 3.16, belkin (?), 13:09, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
Да, все хотят отвязаться от этого монстроидального ядра.
Может быть ещё при жизни Таненбаум получит признание. | | |
| |
| 4.27, Michael Shigorin (?), 16:32, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Да, все хотят отвязаться от этого монстроидального ядра.
И заодно от хардваре.
>Может быть ещё при жизни Таненбаум получит признание.
Мгм. Предположение оказалось правильным.
Видите ли, он и так уже получил заслуженное признание как выдающийся теоретик и неудачник-практик. Если бы не выпендривался, дело бы, пожалуй, ограничилось первым. | | |
|
|
|
| 1.7, belkin (?), 09:37, 25/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Как вы думаете, что раньше случится - Лайнус сменит архитектуру ядра, чтобы его части стали более независимыми друг от друга или у всех случится помешательство от постоянно пересобирания всего этого "большого куска" ? | | |
| |
| 2.12, Michael Shigorin (?), 11:37, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Поищите по словам "in-tree drivers" и "stable kernel api", тема достаточно изжёванная.
Вкратце (и в меру моего чайнического понимания) -- это вопрос не технический ("архитектура ядра"), а организационный ("архитектура управления"). По крайней мере постольку, поскольку ядро и так модульное больше десяти лет, при этом в его развитии участвует гораздо больше компетентного народу, чем в пожалуй что любом другом.
Не шибко давно после распила xorg на кусочки (включая драйверы) и опыта разработки/поддержки в таком виде тамошний люд пришёл к подозрению, что "linux kernel got it right" и содержать конкретно драйверы в одной ветке исходников -- сильно менее проблемно при изменениях в инфраструктуре как для обновления кода, так и для отлавливания протухлости оного.
А вот утверждений насчёт возможности большей параллелизации разработки тех же микроядер (с исходно относительно простыми модулями, но усложняющимся в геометрической прогрессии взаимодействии по мере роста числа объектов, которым надо уметь общаться) что-то пока не видать. Подтверждённых практикой. | | |
| |
| 3.18, belkin (?), 13:48, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Поищите по словам "in-tree drivers" и "stable kernel api", тема достаточно изжёванная.
Детали меня не интересуют. Мне и так всё ясно.
>Вкратце (и в меру моего чайнического понимания) -- это вопрос не технический
>("архитектура ядра"), а организационный ("архитектура управления"). По крайней мере постольку,
>поскольку ядро и так модульное больше десяти лет, при этом в
>его развитии участвует гораздо больше компетентного народу, чем в пожалуй что
>любом другом.
Всё проще. Лайнус сам сказал, что ОС на микроядре они не потянут - много больше работать надо будет.
>Не шибко давно после распила xorg на кусочки (включая драйверы) и опыта
>разработки/поддержки в таком виде тамошний люд пришёл к подозрению, что "linux
>kernel got it right" и содержать конкретно драйверы в одной ветке
>исходников -- сильно менее проблемно при изменениях в инфраструктуре как для
>обновления кода, так и для отлавливания протухлости оного.
Вернулись к тому, от чего бежали. Энтузиасты желали хорошего ПО, а когда начали уже писать решили не заморачиваться и делать как проще.
>А вот утверждений насчёт возможности большей параллелизации разработки тех же микроядер (с
>исходно относительно простыми модулями, но усложняющимся в геометрической прогрессии взаимодействии по
>мере роста числа объектов, которым надо уметь общаться) что-то пока не
>видать. Подтверждённых практикой.
На пути к лучшему всегда много трудностей, они решаемы. У разработчиков Linux другая - они не видят концептуальной отсталости в своём продукте. Лечение начинается когда больной признаёт себя больным. | | |
| |
| 4.23, andyS1976 (??), 15:22, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> У разработчиков Linux другая - они не видят концептуальной
>> отсталости в своём продукте.
Можно на пальцах, в чем концептульно Линукс ядро неправильно,
и к чему это может привести через лет 5?
Какой концептуальный подход Вы полагаете верным в мире разработчиков отурытых ядер?
| | |
| |
| 5.24, belkin (?), 16:05, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>> У разработчиков Linux другая - они не видят концептуальной
>>> отсталости в своём продукте.
>Можно на пальцах, в чем концептульно Линукс ядро неправильно,
>и к чему это может привести через лет 5?
>
>Какой концептуальный подход Вы полагаете верным в мире разработчиков отурытых ядер?
Ядро должно быть ядром а не кучей всего. Драйверы должны быть отдельны, сервисы тоже. Тогда не будет всех этих глупых проблем. Такое разделение не только положительно скажется напрямую в работе ПО, но и заставит разработчиков тщательней продумывать интерфейсы между модулями и документировать их.
Ну что повторять-то, уже всё тысячу раз объясняли доказывали и показывали. Проблема в том, что до народа не доходит. Они уткнулись в свою писанину и у них времени нет посмотреть на своё чудо с точки зрения чужого опыта. Можно долго рассказывать о том, что и как сделать лучше, но смысла нет. Они элементарных кривых вещей не видят типа маразма от совмещения иерархии каталогов ФС с горизонтальными безклассовыми линками (Soft/Hard Links). Куда там предлагать более сложные вещи типа сменить C (на Bliss например), переделать IPC. Создать барьеры между OS и Apps, между самими Apps. А эти ну просто тупейшие заморочки с менеджерами пакетов ? Хотя всё это уже к ядру не относится, но имеет туже причину.
Куча существующих проблем может быть решена только большими измениями.
Самые плохие последствия для Linux/OpenSource это то, что талантливые опытные системные программисты (не я) хотели бы поучаствовать, но когда смотрят как там всё криво и всех это устраивает, отварачиваются. Делать в одиночку это ещё одна никому не нужная ОС. | | |
| |
| |
| 7.28, andyS1976 (??), 17:15, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Интересно есть ли на данный момент в мире попытки создать правильное (с точки зрения концепции) ядро ОС, на базе уже написанного кода ядра линукса?
И что бы на этом ядре могли работать уже написанные программы под Линукс, или что бы можно было сделать типа
rpmbuild -ta xxxx.src.fc6 --target=PRAVILJNOE_JADRO :)
PS
МОжет недостатком концеции ядра линукса стало то, что в начале неопределились что надо иметь и рамки за которые не нельзя выходить (это на тему что изменения в ядре делают неработоспособными код уже написанных драйверов и такие патчи как patch-o-matic, IMQ, и тому подобное) | | |
|
|
|
|
|
|
| 1.13, rihad (?), 11:47, 25/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
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 | | |
| 1.19, belkin (?), 13:49, 25/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот вам для развлечения:
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 стабильным на ближайши% | | |
| 1.20, belkin (?), 13:50, 25/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
20) Является ли ядро 2.6.16 стабильным на ближайшие 2-3 года?
21) КДЕ и Гном будут воевать вечно.
22) BSD рулит. Особенно OpenBSD.
23) Зря форкнули X.org/XFree86, зря форкнули cdrkit/cdrtools, а Apache 2.0
может сам себя заDoSить.
24) hibernation и standby не работают.
| | |
| |
| 2.26, Michael Shigorin (?), 16:26, 25/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Извините, но это не фак, а полубред. Особенно плохо то, что в нём где-то до трети внятных утверждений перемешаны с третью жёсткого бреда и третью просто глупостей.
Отфильтровать никак не получалось? | | |
| |
| 3.30, Михрютка (?), 00:53, 26/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Отфильтровать никак не получалось?
:) это уже отфильтрованное.
Вы прослушали икзекьютив резюме статьи The Sorry State of the Open Source Today
http://beranger.org/feature/sorryfeature.php
Там еще один пунктик в резюме надо было добавить: "Уже сейчас ясно, что все это будет глючить и тормозить" | | |
| |
| 4.31, Michael Shigorin (?), 13:39, 26/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Отфильтровать никак не получалось?
>:) это уже отфильтрованное.
Боюсь, не столько отфильтрованное, сколько намешанное. Как понимаю, ими, а не Вами.
>Вы прослушали икзекьютив резюме
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)
У нас же исторически принято пользоваться головой, а не только в неё есть. | | |
|
|
|
| 1.32, Аноним (-), 19:10, 26/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
у меня на ноуте новые ядра нестабильны,ака 2.6.21 2.6.21.1
ругаются clocksource tsc unstable и намертво виснут
посижу пока на 2.6.20 | | |
|
