На практике всё чуть веселее...

Копеечка, умело засунутая в USB-разъём любым пользователем под любой операционкой, со 100% вероятностью убивает чип Intel южного моста.

>Не увиливайте, монсеньор, отвечайте как подобает благородному человеку!

Троллинг со стороны модератора выглядит уныло:(

>Допустим вам нужно написать что-то про БД таблиц на 30-ть с веб-мордой и не сильно сложной логикой, возможно даже синхронной.... что же тут самое удобное?

Python? PHP? Я угадал ваш правильный ответ?:)

А что Ариан-5? Просто в случае запуска ракеты убытки ОЧЕНЬ велики, соответственно, чаша весов склоняется к их недопущению. И опять же - не факт, что методом будет написание идеально корректного кода а не, скажем дублирование логики. А может и правда в этом случае выгодно применять какие-то дорогие, медленные но заведомо надёжные методы написания кода. Я о том, что стоимость считать надо, а не искать святой Грааль.

Andy Tanenbaum hasn't learned anything
http://harmful.cat-v.org/software/andy_tanenbaum

Как на счет такой временной меры борьбы с этой 'socketbomb' и прочими DoSерами: разрешить в kernel/cpuset.c cpus_allowed = 0 и сбрасывать cpu affinity mask в 0 для обнаглевшего процесса?

> Давай пилить gnu/mach!
Линус, может быть, и пишет баги, но он не упоротый. Так что будет пилить разве что ядро Plan 9.

Это естественный отбор. Со временем таких ковбоев станет меньше. Время

покажет, кто ошибался.

Время уже показало, этот спор идет уже десятилетия и ковбои везде кроме крайне узких областей. Так что естественный отбор отбирает ковбоев и выкидывает формальных верификаторов с шишкинами на мороз. А рейзеров сажает в турьму. Собственно современное засилье подхода ковбоев это естественный отбор в действии.

> Троллинг со стороны модератора выглядит уныло:(

Фх извините, что Вам не угодил. Ну так что используете, чем блеснуть можете? Хаскелль, лисп, эрланг, руби, мэпл с математикой, что?

Тем временем у наших редмондских друзей

...нашли 0-day уязвимость, которая позволяет обойти UAC. Вкупе с незалатанной дырой в Internet Explorer, предоставляет множество вкусностей для злоумышленников и спецслужб, хотя что это я повторяюсь.

Пруфлинк: http://nakedsecurity.sophos.com/2010/11/25/new-windows-zero-day-flaw-bypasses...

Согласитесь, это вам не просто повесить машинку.

>Среди проприетарных микроядерных ОС есть VxWorks.

У vxworks монолитное ядро и нет защиты памяти - ее ядро может свалить любое приложение из юзерспейс. Помоему у Томми как раз она была на борту :)

Все зависит от типа и кол-ва конкурентных запросов. К примеру, для SELECT запросов ЯП почти не важен. Если же есть большое кол-во INSERT/UPDATE/CALL, то PHP/Python/Perl будут подтормаживать. На практике - примерно на 30%..40% по сравнению с C/C++. Для самого Web-face нет никакой разницы. Т.е. если это база, где все изменения - через Web-face, то язык роли не играет. А если данные приходят откуда-то еще - может иметь очень большое значение.

К примеру, недавно делал базу на MySQL (мне тоже смешно, но таковы условия контракта). Прямой ввод данных на Perl (одиночный INSERT в цикле) - 1800 rec/s. Прямой ввод на C++ 13000 rec/s. Правда, если слить все INSERTs в один файл и скормить его, то получим 16500 rec/s, независимо от языка (но это уже очень специфично данной задаче).

Что-то в последний месяц сильно много новостей попадается про уязвимости линукса. Многие из них, имхо, таковыми фактически не являются, но факт остаётся фактом. Это заговор Балмера с Джобсом, не иначе. Они хотят скомпрометировать самую лучшую операционку.

ЗЫ. Тред не читал.

Лучше уж себе верить и получать фан от работы, чем слепо верить старым пердунам

и жить по их букварю.

А потом оказывается, что пердуны что-то знали задолго до вас и заботливо предупреждали о вероятных проблемах. Но буйство энергии и неуважение не позволили
оценить их мудрость.

неприятная новость , я думала о линуксе как о мега надежной системе

Мегаустойчивыми в этом мире бывают только заблуждения.

Верифицированное микроядро нужно для того, чтобы опираясь на его гарантии

выстроить безошибочно работающую систему.

Серебрянной пули не бывает. Ситуация такова, что чтобы встроить такую систему вам придется отказаться от x86 архитектуры, и от языка Си как минимум, от работы с указателями. Автоматом отвалится и POSIX. Еще вам в одиночку придется достигнуть такого уровня развития системы, чтобы на не можно было делать типовые задачи(кино, офис, графика, серверное решение). А это уже не кислый набор не POSIX софта. Либо добиваться совместимости со старым софтом.
И самое главное во всем этом, что то, что вы получите совсем не факт, что будет лучше чем то, что мы сейчас имеем.(о как..)

>Так что естественный отбор отбирает ковбоев и выкидывает формальных верификаторов с шишкинами на мороз.

Эти формальные верификаторы работали над чем-то 18 лет и в итоге в reiser4 куча багов причем по словам самих же верификаторов «трудно воспроизводимых», кто за ними говнецо убирать будет ? Через пару месяцев работы скорость reiser4 падает настолько что сравнима с ext3 слепленой на коленке за пару лет.

а что думает Патрик?

Господа это не серьёзно! Ну и что, что патч ещё не совсем готов? Если есть голова на плечах «защита от дурака» не нужна.

Эти формальные верификаторы работали над чем-то 18 лет ...

Я примерно это и говорю. Формальная верификация против ковбоев, это флейм который начался задолго до рождения почти любого лоровца. И как раз естественный отбор всегда был на стороне ковбоев. При чем сейчас даже в традиционных областях верификаторов этих самых ковбоев все больше и больше. Чем дальше тем проще становится потерять ракету из за ошибки в программе чем кормить верификаторов - которые стоят гораздо дороже даже хорошего программиста и которых все труднее найти.

Тем не менее постоянно появляются новые(молодые?) люди рассказывающие про то что естественный отбор уберет ковбоев. И рассказывает про то что будет, когда их танки войдут в город...

Добро пожаловать в говно

Кстати, ты сам то по своей ссылке ходил?

http://ru.wikipedia.org/wiki/Ocaml

Давай, обгони этот язык в разы, а то и на порядки на своем убогом це. Вылезай из 70-х, твой аргумент уже давном давны устарел. Даже всякие совсем уж «академические» языки вроде Haskell нынче работают шустро, если не забывать пользоваться профайлером.

Жду обновления. Надеюсь, быстро исправят.

>Почитал комменты - пугаться так зачем? Что вам мешает запускать непроверенный код от другого пользователя.

Вылези из скорлупы, компьютеры бывают не только персональными. Иногда на компьютерах работает много пользователей. А ситуация с этой уязвимостью такова, что один подлец может нагадить всем остальным пользователям того же компьютера. Пример таких систем - хостинги с shell-доступом.

>Компьтер же может автоматически убедиться в верности твоего доказательства. Всё, дело в шляпе.

Твоим бы хлебалом да щей бы навернуть.

Прямо по всем направлениям отака на линукс идёт :(

В QNX Neutrino включен порт Mozilla Firefox, так что можешь убегать туда хоть сейчас.

>пустые циклы можно убить через -KILL

Петросян?

Плевать на «крутость», я до сообщества пытаюсь понимание проблемы донести. Кто-то прочитает, уловит идею, а потом своим умом поймет, что так и есть. Вся современная software индустрия - это конвейер по производству глюкавого, дырявого и попросту кривого bloatware.

Это следствие - в других «индустриях» все тоже самое. Такова человеческая природа - и это естественный процесс...

>Вся современная software индустрия - это конвейер по производству глюкавого, дырявого и попросту кривого bloatware.

Вся современная промышленность - это конвейер по производству говна. И если его остановить, 95% людей останется без работы.

Старые алгоритмы разрабатывались людьми, с мышлением ограниченным реалиями того времени. Не говоря уже про то, что большинство алгоритмов нереально примитивны в базовой трактовке. В результате часто можно найти более оптимальные пути решения задачи, а не просто решение.

Вы путаете алгоритм с его реализацией... Теорема Пифагора за последние две с половиной тысячи лет не стала ни лучше, ни хуже...

Вся современная промышленность - это конвейер по производству говна. И если его остановить, 95% людей останется без работы.

Соображаешь! Но это не вся правда...

> А на ещё более грамотных - банальный запрет запускать левые команды по ssh.

+1, и вообще в джейлы их всех.

Гражданин, пройдёмте!

Хватит уж трепаться. Признай, что облажался с конечными автоматами и дело в шляпе. А то позоришь всю модераторскую братию.

Написание микроядра на начальном этапе разработки в разы более трудоёмкое, чем монолитного ядра

А в микроядре вы можете тщательно проверить само это ядро(в силу его небольшой сложности и объёмов)

Где-то здесь нас нае... обманывают

РЕШЕТО!

Решето этот ваш линукс. Вот у меня в убунте все работает, и никаких вирусов.

НЛО????

Да ты Успокойся!! тоже мне истеричка ....

Что за нае^W обман? Процесс прибился по ^C без проблем! Почему в этом вашем линуксе даже дыры не могут нормальные сделать?

А в амд не совали? Каковы результаты? :(

А то позоришь всю модераторскую братию.

или я чего-то не понимаю, или чистить за другими говно - пристижно

Прочел тред, про языки программирования, конечно, познавательно было. Но я так и не понял, есть ли патч и когда его ждать)

на микроядра и миник намекаешь?

>>или я чего-то не понимаю, или чистить за другими говно - пристижно

нужно, как минимум, уметь отличать гумно от прочего материала. А с этим у человека большие проблемы

> Кстати да. Надо мной уже виндузятники смеются. В Линухе дыр говорят больше чем в семерке. Да еще таких, которые забодают на ровном месте.

это те люди которые пользуют систему позволяющую сделать с ней тоже самое удаленно?

Как только востановят lkml.org
«The server is taking too long to respond; please wait a minute or 2 and try again.»

на костер их на костер всех Таненбаумов,

а кроме смеха идея миникса конечно же интересна,только миникс нужен доконца проработаным здесь и сейчас а не наглядным пособием по теории осестроения для студентов, вот когда он обрастет функционалом я в первых рядах буду его внедрять... а пока пардонте мы будем корчится и глотать наши кактусы потому что другого пока нет...

> Написание микроядра на начальном этапе разработки в разы более трудоёмкое, чем монолитного ядра

Не написание, а проектирование. И обеспечение работоспособности базовой системы на основе микроядра, ибо к нему нужно писать еще сервисы в огромном количестве, а вот их взаимодействие - это пипец как сложно.

А в микроядре вы можете тщательно проверить само это ядро(в силу его небольшой сложности и объёмов)

А вот само микроядро как инкапсулированная единица - штука простая как пробка.