>>Я имел в виду «не додумывайте за меня».
>
>А я разве это делал? Да.
>>Не знаю, кем она считалась, но точно не мной.
>
>Ну то вы.А маковцы постоянно понтовались.
Вот с ними об этом и флудите.
>>Между прочим, до наступления гегемонии Windows на Макинтошах вирусы только так бегали.
>
>Я как-то не в курсе вирусов под маки, которые на PPC.Во всяком
>случае - юзеров этих штук видел и они все сроду прикалывались
>над виндузятниками по части заразы :)
Вы историю не на 5 лет назад мотайте, а на 25.
>>Если нет данных, на которые можно положиться, то правильное умозаключение не выведешь.
>
>А кто сказал что данных - нет?Я видел дохрена разного софта.Баги бывают
>везде кроме совсем уж примитивных конструкций. Которые в силу примитивизма можно
>вылизать до байтика за какой-то более-менее разумный срок (и то не
>всегда получается).Ну там и кода - с гулькин нос.Для проектов которые
>в скомпиленом виде занимают мегабайты такое не катит.
А что вы доказывали-то? Что ошибки есть везде? Так с этим-то никто не спорил. Следите за разговором, а?
>>Люди так или иначе верят глазам. Теория Коперника ничего бы не стоила,
>>если бы у неё не было доказательств.
>
>А кто сказал что доказательств нет?См. выше...
Вы доказывали, что ошибки есть везде. Я говорил немножечко о другом, читайте внимательнее.
>>Для того, чтобы понять, DoS это или RCE, не обязательно быть хакером,
>
>Вы видимо не понимаете - програмеры они вообще не хакеры зачастую.Если кто-то
>умеет программить и даже хорошо - еще не значит что он
>разбирается в том как там код выполнить можно :)
Это, конечно, в любом случае плохо. Но когда это касается весьма чувствительных компонентов _ядра_ОС_, такое отношение, ИМХО, недопустимо. Здесь ошибок не прощают.
>>нужно быть просто внимательным и знать, что происходит в каждой строчке кода.
>
>Програмеры это знают под немного другим углом.Ну не учат програмеров код выполнять
>через переполнения буфферов.
Слушайте, а вы вообще в курсе, как это делается? Не обязательно уметь юзать переполнение буфера чтобы от него защищаться. Достаточно аккуратно к этим самым буферам относиться.
>>Данный хакер не искал дырку, а анализировал имеющуюся.
>
>И в процессе этого явно сношал себе мозг некоторое время чтобы достичь
>выполнения кода.Строго говоря - там достаточно извращенно все получилось.То что програмеры
>не доперли что там можно код выполнить - имхо не показатель
>тупости программеров.Это скорее показатель того что у некоторых хакеров хорошо работает
>мозг, получше чем у других и в специфичном направлении :)
Сношал, угу. А программер, значит, расслаблялся пока код писал? :) Никто и не говорит, что он ничего не сделал. А если программисты ядра ОС сами не могут анализировать собственный код, то либо пусть просят кого-то помочь ("дяденька, я тут функцию написал, а мне сказали, что она неправильная, проверьте, пожаааааалуйста"), либо пусть идут писать банк-клиенты. Дело тоже нужное.
>>И слава богу. Как я уже сказал выше, у меня есть основания
>>полагать, что данная дырка была взята специально как малоопасная в практическом
>>плане.
>
>Я надеюсь что он тогда достигнет своей цели - построить програмеров.Все-таки ответственность
>на них нехилая и они должны ее понимать.
Абсолютно согласен.
>>Безответственно — когда обещают и не дают. Насчёт официальных портов в ветке
>>-STABLE все предупреждения висят.
>
>Предупрежления вместо новой версии - это весьма оригинально но требует внимательности и
>затрат времени.В случае щелкания клювом - возможно попадание в капкан :-).
Возможно. Как и в случае "pass on $lan_if from any to any", например. :)
>[оверквотинг удален]
>
>Ну так для остальных то систем эти "кто-то" находятся все-таки как правило.Просто
>если уж беретесь понтоваться безопасностью - будьте морально готовы что кто-то
>не оценив понтов накопает больное место.Понты безопасностью - наименее выигрышные.Всегда есть
>шанс о них пожалеть.Вот сколько я видел тех кто слишком упирает
>на безопасность - столько же я видел лолов как они начинают
>вертеться когда у них дырку находят.Один хрен - от файрфокса до
>цысок картина одинаковая.Сначала шумят как все круто.Потом когда их приложат -
>отскребаются от асфальта :).Некоторые, типа файрфокса, оперативно отскребаются правда и на
>будущее носят каску, что впрочем 1 фиг не всегда спасает :)
Можно сказать "мы самые крутые". А можно сказать "мы стараемся быть таковыми". Если вы посмотрите внимательно, OpenBSD'шники говорят второе. А вот те, кто о них пишут обычно не гнушаются чуть-чуть подправить текст, чисто для красоты и слога, ага.
>>Аналогично. Чем ещё померяемся? ;)
>
>А оно надо?Если вам нравится ваша система - какие проблемы то?Пользуйтесь себе,
>я что, против?Мне просто не нравится когда некоторые клеят ярлыки и
>т.п. - система это одно а кто за монитором - другое.
Эммм, а кто первый ярлыки-то начал клеить? ;)
>[оверквотинг удален]
>Неплохо и даже разобраться можно.Но - при условии что вы интересуетесь системными
>делами а компилер - ваш верный друг и товарищ и вся
>эта возня вам нравится и вы готовы выучить все это.А если
>вас не дай боже будут например, оперировать - может вы и
>будете знать некоторые детали.Но какой там скальпель и зажимы использовать в
>конкретный момент - дело хирурга все-таки, а ваше - надеяться на
>то что хирург - не лох.Ну а вот если хирург пришел
>пользоваться операционкой - он вправе хотеть чего-то аналогичного.Он же не заставляет
>вас изучить всю номенклатуру скальпелей и зажимов?А он почему должен так
>распираться? =)
Хирургу эту ОС поставит и настроит на работе местный сисадмин. Никто никогда не говорил, что OpenBSD планирует быть системой для домохозяек. Это к Windows, Linux, FreeBSD и MacOS X, BeOS и иже с ними. Это система для гиков. Я — гик. Мне в ней удобно. Моей жене в ней тоже удобно, потому что я ей эту систему поставил. И меня (в отличие от вас?) не волнует, что соседу Пете поставили другую ОС, с которой ему удобно. Если ему хорошо, могу за него только порадоваться. Если его завтра взломают, или у него умрёт ОС — не моя вина. Если этого не произойдёт — хорошо.
>>Это вы про Linux? В отличие от OpenBSD, мне обычно там приходится
>>создавать xorg.conf ручками. Не знаю уж почему так получается.
>
>Хм.Решил перетрясти разделы а заодно - поставить современную версию убунту с нуля
>для разнообразия, посмотреть как оно ставится сейчас.Та же убунта сама впихнула
>мну атевый открытый драйвер.Мало того что разрешение моника сразу правильное, так
>еще и компиз "из коробки" пашет.Все бы так.Еще б опенсорцный драйвер
>бы в 3D был шустрей и стабильнее, но на R500 спеки
>на 3D открыты недавно только, так что тут даже ругать особо
>некого.
Ура, Linux догнал OpenBSD по удобству использования. :) Ещё бы утилиты типа route были поудобнее, ну да чего уж там… ;)
>>Если вы им за это платите, то да.
>
>А если не плачу - стало быть можно разложить граблей и создать
>проблем?Мне что-то такая логика не нравится.Я себе все-таки не враг ;)
Специально вам грабли никто раскладывать не будет. Если же вы не платите (или ещё как помогаете), то не вам и требовать. Если вас не устраивает такая логика, то с вами разговаривать, боюсь, особо не о чем.
>>Грабли — это когда сталкиваешься с тем, с чем столкнуться не ожидал,
>
>Ну так я не ожидаю что в системе граблеопасные дефолты.Потому что я
>себе не враг.
Если не читать документацию до установки системы, то вы конкретно данные «грабли» ожидать не будете. Только вот если вы себе не враг, то документацию прочитаете, не? ;)
>>то есть вопреки имеющейся документации. У меня только один вопрос: вам
>>шашечки или ехать?
>
>Мне, конечно, ехать.Но желательно - без приключений :)
Если для вас приключение — ввести приведённую выше команду, то, боюсь, вам действительно в OpenBSD делать нечего. :)
>>чините свои убунты после очередного обновления.
>
>Ну дык я это и делаю - мой выбор.Ну и мне же
>за него воздастся.Вам стало быть нервничать не о чем :)
А я и не нервничаю. ;)
>[оверквотинг удален]
>так покажите тех у кого это есть, не глючит и все
>такое.Или может, можно без геморроя юзать ту же бздю допустим с
>3-ми кедами а при появлении новой версии и 4-х кедов в
>автоматическом режиме проапгрейдить все это и ничего не отлипнет и глюков
>не будет невзирая на тонну отличий кедов друг от друга?А то
>что натерев мозоли на руках можно и там и сям чего-то
>добиться никто и не сомневался.Просто автоматические апдейты трудно задесигнить под такие
>вещи чтобы всегда и в 100% случаев работало.А какие варианты то?Предложить
>всем с нуля начать?Покласть на обновления болт?Или чего?Покажите какой-то разумный вариант,
>чтоли? :)
Один из товарищей при мне запустил родное гуёвое обновление системы. Оно, помимо прочего, обновило Иксы и ядро. После перезагрузки иксы так и не ожили. На OpenBSD у меня такого не было, вот и всё. :)
>> Нафига оно тогда нужно, а?
>
>Ну, я вот пользуюсь - мне нормально в принципе.Что до глюков -
>та же PC-BSD вечно испытывает траблы с моим видео.Черт его знает
>что ей не нравится но - факт.
Охотно верю.
>>Крупный провайдер обычно самолично обслуживает собственное оборудование (во всяком
>>случае, самую ответственную часть), так как это надёжнее.
>
>Неужто самосбор - надежнее кучки готовых цысок?Что-то я слабо себе представляю зубров
>типа комкаста или AT&T собирающих себе оборудование вместо того чтобы его
>купить у той же цыски или там кого еще.В любом случае,
>"router company" - это наврядли про провайдера.Провайдер - ISP или как-то
>так обычно.
Да разобрались давно уже, кто о чём говорил…
>>производитель используемого железа, по понятным причинам, ориентируется
>>на «типовые» конфигурации.
>
>Эээ я думаю что цыска и ей подобные если и ориентируется на
>типовые конфигурации то эти конфигурации не столь уж далеки от того
>что у провайдеров по факту есть.
Конфигурации бывают ОЧЕНЬ разными. У одного внутри датацентра больше через оптоволокно бегает, у другого почти всё на меди; у одного 2 внешних канала с одинаковой пропускной способностью, у другого 5 и с разной пропуской, причём пара вообще X.25; у одного основной траффик — P2P, у другого — streaming video; одному часто нужно предоставлять "органам" доступ к своей сети, другому нет, и т.п. Я не говорю об особенностях помещений и тому подобных нюансах. Всё это накладывает свой неизгладимый отпечаток на топологию, на предъявляемые к железу требования и т.д. Плюс наследие от аналогичных последствий прошлых конфигураций, от которого нельзя избавиться по различным причинам. А железо, между прочим, тоже денег стоит, и немалых. И далеко не всегда оправданных.
>>А для чего нужны открытые исходники, как не для относительно лёгкой
>>кастомизации под конкретные задачи? :)
>
>Вот теперь вы наверное понимаете почему даже всякие цыски понемногу начинают какие-то
>заигрывания с линухом.
Да пусть заигрывают, жалко, что ли. :)
>>А вы не забыли, когда ext3 появилась? ;) Напомню: порядка 10 лет
>>назад.
>
>Во-во.А у некоторых еще *только-только* появился журнал :).А ничего что я не
>живу вечно и ждать еще ...цать лет элементарных благ цивилизации мне
>неохота.И, наверное, не моя вина что если проекту столько лет -
>за столько лет вокруг него почему-то не собралось достаточно живое комьюнити
>програмеров.
Дык не ждите, пользуйте свой Linux, если для вас это самое главное в ОС. :)
>>Или просто аварийные выключения. Для ослабления последствий которых и нужно
>>журналирование.
>
>Логично.У меня таким макаром фат рассыпался разок на тысячи потеряных кластеров.Журналируемые настолько
>сурово не сыпятся.Как максимум теряют то что записывалось в данный момент
>обычно.Что, блин, логично.
При условии корректной реализации журнала.
>>Если бы в FAT приделали журналирование, он бы рассыпался точно так же.
>
>С нормальным журналом не рассыпался бы - или уж транзакция доводится до
>логического финала или откатывается.А левые промежуточные состояния которые вызывают снос крыши
>- это то с чем журнал и должен бороться.
При условии корректной реализации журнала.
>[оверквотинг удален]
>
>>усложнение повышает вероятность сбоев. :)
>
>Давайте вы будете тогда базы данных без логов транзакций гонять?И фс без
>журналирования?Камикадзить так по полной :).А мне неохота, спасибо.И черт побери аварийные
>тормоза в лифте на случай обрыва троса может и усложняют его
>конструкцию.И даже не 100% надежны наверное.Но я предпочту все-таки ехать в
>лифте с этими не на 100% надежными тормозами-уловителями чем вообще без
>них, извините.Потому что вообще без них - при обрыве троса мне
>гарантировано хана.А при их наличии - может и не хана.
Вы упорно продолжаете настаивать, что журналирование повышает надёжность ФС? Аналогия с лифтом некорректна. В случае с ФС, средства обеспечения безопасности лифта аналогичны, например, резервным копиям MFT/суперблока/как-там-ещё.
>>При условии корректной реализации журнала. Мелочь оговорка, правда? ;)
>
>Да, см. выше.Я предпочитаю лифт с не 100% надежными но все-таки уловителями
>на случай обрыва троса, чем совсем без них, извините :P
Про уловители я уже сказал. В данном случае вы усложняете систему, НЕ ПОВЫШАЯ её надёжность. Надёжность в ФС соблюдаться может только путём упорядоченной записи (такие нюансы как встроенный кэш жёсткого диска не рассматриваем). Все остальные варианты, включая журналирование, менее надёжны по определению.
>>По хорошему, лопатить надо в любом случае.
>
>Смысл существования журнала - чтобы не допустить противоречивого промежуточного состояния ФС.Или уж
>транзакция доводится до финиша или откатывается.Смысла при этом лопатить - нет.При
>условии что на момент монтирования ФС была исправна.Лопатинг просто ничего не
>даст - профуканые в оперативке данные он все-равно не вернет а
>ФС находится в валидном состоянии а не в каком-то промежуточном.
Смысл журнала — обеспечить быстрое восстановление ФС после аварийного останова. Слово "восстановление" уже показывает, что ошибки _будут_, и что журнал просто помогает их нивелировать. Но журнал — далеко не единственный способ решения подобной проблемы.
>>Потому что журнал, повторюсь, НЕ панацея, а только средство быстрого запуска
>>сервера после аварийного отключения.
>
>Он средство не оставить метаданные ФС в противоречивом состоянии прежде всего.Во вторую
>очередь :( еще и по идее средство сохранить столько юзеровских данных
>сколько было возможно в создавшейся ситуации (понятно что никакой журнал не
>сможет спасти то что было только в RAM).
Цель — восстановить ФС после сбоя. А вот обеспечивает он это через такое сохранение информации об изменении состояния ФС, которое обеспечивает восстановление более-менее непротиворечивого состояния данных.
