>> В итоге, просношавшись годы мы не получим того, что хотели.

Мы получим то, что ведет себя в точности так, как описано в спецификации.

но где, где же он это верифицированный софт, который ведёт себя так, как описано в спецификации и не имеет багов?

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

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

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

Спецификации пишут те же люди, а системы, которые они пытаются описать крайне сложны и содержат элементы неопределённости - то же кривое железо, которое работает не так, как описано и т.п.

Чем по-сути код отличается от спецификации? Код на высокоуровневом языке та же спецификация для машинного кода.

Ты предлагаешь написать некий код (формальное описание) более высокого уровня. Сдвигаешь проблему наверх, но это ничего не решает.
Смысл?

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

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

Дайте браузер современный под QNX - я туда убегу :) Да хотя бы под Minix. Остального лично мне не надобно...

Smalltalk в отличии от C++ или С#/Java имеет очень чистую ООП-модель. Которая кроме всего прочего позволяет писать в ООП стиле правильно. А то, что под видом ООП толкает тот же С++ - это тихий ужас. Что легче парралелится: объектная программа на плюсах, или смоллтолке? Прежде чем ответить, надо вспомнить, что в первом передавая что-то объекту, мы дёргаем метод(по сути дела функцию, указатель на которую хранится в потрохах объекта, скорее всего в списке, или в хеше(как в python)). А это очень порочная практика. В Ъ-ООП мы передаём объекту что-то только через посылку сообщения. Это намного безопасней, и легче параллелится. Это красивый дизайн. И объекту не нужны для получения данных торчащие во все стороны «потроха» методов. Ну и наследование vs прототипирование тоже интересная тема. Не буду говорить о порочности наследования, и пользе прототипов - это можно прочитать везде, где критикуют ущербные недоООП язычки. В общем, проблема современной IT в неправильных концепциях, неверных ориентирах и тотальной близорукости. Строители Java не осилили концепций заложенных в Oberon. MS испоганило прекрасную ОС под названием OpenVMS. Создатели Unix не осилили много-го из MULTIX. Увидев GUI в Xerox PARC, Джобс так и не понял всей красоты того, что он там увидел. Ему удалось скопировать только GUI. И таких примеров множество. Создатели Delphi не осилили последующих, очень здравых идей Вирта. И их расширение для Pascal сделало его монстром, в то время как Вирт упростил язык, сделав его проще, и надёжней. Таких примеров полно. История выбирает не лучшие технологии, а те что дешевле/проще реализовать/удалось понять и оценить критической для успеха массе специалистов и т.д.. И это печально. Потому что нет никакой эволюции ПО. Есть только нагромождение костылей невиданной величины. Прямо как куча кирпичей у несуразной вавилонской башни.

Читай внимательней, будь добр. «Более важно» там сказано, а не «Количество багов не важно».

Если возможно сравнить, то что лучше - один говнюк, использующий баг в виду того, что разработчики не знают, или куча говнюков, которые пользуются эксплойтами, не закрытыми разработчиками... ну просто потому что не закрытыми?

ну вот, уже и линуксовские баги не работают :(

0a1
> #include <sys/types.h>
2a4,5
> #include <err.h>
> #include <string.h>
31c34
<     return 1;
---
>     err(1, NULL);
35c38
<       return 2;
---
>       err(2, NULL);

socketpair: Protocol not supported

PS: и когда уже линуксята научатся добовлять все нужные шапки???

Всегда забавляло, что если знакомые пользователи оффтопика видят новости про открытие уязвимостей в Линуксе начинают самодовольно ржать и всем видом выражать своё превосходство. А вот когда для их любимой ХР или даже Семёрочки обнаруживается пачка таких дыр, что во век не залатаешь, да и еще весьма не своевременно, то они на это не реагируют никак. А как реагировать-то, коли привыкли?

какая то черная полоса пошла
- оракл обладая ключевыми разработками опенсорса начинает вести себя хуже некрософта
- редхат заключает закрытое патентное соглашение с троллями
- падает новелл и продается конторе «рога и копыта»
- некрософт получает кучу патентов которые в случае нападения некрософта на линух должны были быть обратным ударом со стороны новелл
- в OpenSSL и в ядре находят пачку дыр, ладно хоть не удаленных
шо дальше?

> Smalltalk в отличии от C++ или С#/Java имеет очень чистую ООП-модель.

Юноша бледный со взором горящим.

в первом передавая что-то объекту, мы дёргаем метод(по сути дела функцию, указатель на которую хранится в потрохах объекта, скорее всего в списке, или в хеше(как в python)). А это очень порочная практика. В Ъ-ООП мы передаём объекту что-то только через посылку сообщения. Это намного безопасней, и легче параллелится.

Да еще и не очень грамотный.

А много ли специалистов, пишущих аккуратный код? Просто в C не сложно и в ногу себе выстрелить, как и в плюсах. И памяти утечку сделать тоже несложно. Чем сложнее система, тем больше вероятность где-то что-то забыть. А страсть опытных хакеров к всяким красивым хакам, позволяющим повысить эффективность/просто выпендрится тоже известна. C и C++ я знаю немного, но этого хватило, что-бы понять одно: программист пишущий на этих языках должен иметь квалификацию over 9000, или его программы будут течь и бажить безбожно. Я немного знаком с ассемблером, и ещё изучая его(мой первый язык, не считая паскаля в школе), понял, что играть с ресурсами и использовать хаки для повышения эффективности в ущерб безопасности - преступление. А современное ПО пишут так, что доверие оно не вызывает. Проблемы не в инструментах, проблемы в головах. На ассемблере тоже пишутся безопасные программы:) Если при этом соблюдать пару простых правил:) Но приятней же писать на Python/Ruby и т.д.?

Неохота мне чего-то с тобой спорить, так что отвечу в последний раз: С — это не просто «хаки» для увеличения производительности, это собственно сама производительность. Напиши ОС на «безопасном» языке и ужаснись производительности.

Весь цимес существования множества языков и состоит в том, чтобы простые задачи решать быстро, а сложные  — эффективно (в плане затратов человеческих ресурсов).

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

Флеш-плагин делает тоже самое, он случаем не эту дыру использует?

From Марк Коренберг <>

Улыбнуло ;), откуда на lkml кирилица?

Попробовал запустить на Sabayon 5.4, всё также повисло как и на убунте. Рецепт «cat /dev/urandom >/dev/null» дал интересный результат, а именно в том текстовом терминале слетела кодировка и после остановки команды всё превратилось в крякозябры.

Да ладно, все равно скоро старый мир рухнет, а в новом не будет ни патентов, ни некрософтов, ни дыр в ПО ни самого ПО, ни линукса. ;) Главной проблемой станет поиск пищи, укрытия и продолжение рода посреди пылающей планеты.

Тебе абсолютно ничто не мешает использовать сообщения для передачи данных между обьектами. И язык тут ни причем. Ты можешь это сделать в C++, в чистом C, да хоть в Basic. C++ добавляет тебе возможность сделать передачу данных еще несколькими способами. Не нравится - не используй их.

Кто чего не осилил - трудно судить. Но за последние 20 лет я видел только 1 (одну) программу на SmallTalk, CRM, которая делала что-то осмысленное. Ее автор рассказал на презентации, что в ней 150K строк кода и она очень крута. При ближайшем рассмотрении, она тормозила нещадно и делала не так много. Эквивалент на ++, который сделала наша команда, работал где-то на порядок быстрее и имел более развитый функционал. Ах да, 83K строк _вместе_ со всеми использованными либами, кроме самого gcc.

Мне вообще кажется, что все эти дискуссии про ООП бессмысленны. Мы обсуждаем безопасность языка, красоту его модели. Бред собачий. Если язык супербезопасен и невероятно красив, но работает в 10 раз медленнее нормального - бизнесу он не нужен. То, что сейчас Java используется на серверах - это, скорее, диверсия маркетологов и производителей железа. Никому и в голову бы не пришло покупать 12 и более процессорные машины для application server, если бы сначала не были промыты мозги про Enterprise-Java, а потом обнаруженные тормоза не были свалены на железо.

Никогда не был студентом:) Я бездарь-самоучка, и не претендовал ни на какие дипломы. Получить такой моя заветная мечта, но жизнь в беднейшей стране Европы больше располагает к работе, чем к учёбе. Поэтому к моим речам, сэр, стоит проявлять известное снисхождение. Всё, что я познал в этом мире(немного ассемблера, C/C++, HTML, Javascript, Basic, Python и PHP) - всё это я познавал из природного любопытства. В детстве я так же повторял опыты Белла и Попова просто из любопытства(хотел узнать, работал ли первый телефон и радио-телеграф, и как слышно было). В общем во мне говорит не эрудиция, о нахватанные отовсюду фрагменты информации. Я просто любопытный индивид. Так сказать: интересуюсь всем, и не чем в особенности.

В багзилу. В getoo stable как всегда все ок.

Программа по ссылке успешно грохает не только Linux, но и FreeBSD 8.1. Kernel panic :(

Забыл сказать, что пришлось заменить SOCK_SEQPACKET на SOCK_DGRAM

socketpair-bsd: Too many open files in system

и всё, ни каких паник (OBSD48)

Ну и кому нужна эта красота с верифицируемостью? Если дешевле получить убытки, чем добиться их отсуствия - так и надо делать. Если система не загружется в одном разе из ста - обычно проще и дешевле прицепить watchdog, который в таком случае её спокойно перезапустит, чем разбираться, что происходит. Если программа или библиотека достаточно хорошо работает в аналогичных условиях, что спокойно выясняется из отзывов - то этого, как правило, достаточно. И выгодее избыточность/легкость подъёма обеспечить, чем полную свободу от багов. Выгоднее, как минимум, потому, что это спасает ещё от кучи не-софтовых проблем, от пожара до злонамеренного пользователя/админа.

Лично мне неизвестны успешные проекты, идущие «от красоты». А вот страншные, но созданные для решения реальных задач - известны. Тот же линукс. Да, ядро всё больше и страшее - и чёрт с ним. К тому моменту, когда им совсем невозможно станет пользоваться, подоспеет что-то другое, на что можно будет переехать. Зато в процессе развития в линуксе имеем массу функционала - иногда кривого, недопиленного - но это явно лучше, чем не иметь его вообще.

Проблема в том, что 'я знаю немного'. С опытом приходят методы работы, гарантирующие отсутствие утечек в большей части кода. После чего используем valgrind и убираем оставшиеся.

Работая с Python, Ruby, etc получаем всегда один и тот же результат: программа несколько проще, и работает заметно медленнее. Иногда это приемлимо, но никогда - для серверных задач. Для аплета на десктопе - может быть. Хотя как результат - каждый аплет в Gnome, например (Python) занимает 10M..20M. Производительность там, правда, не важна.

Интересно, что убрать утечки в C/C++ коде получится быстрее, чем поднять производительность программ на любом динамическом языке до уровня C/C++, если это вообще получится.

=)

Без багов ни куда...

Мда... Правильно говорят, что если и есть вирусы под линь, то их надо долго и муторно компилировать... Подскажите, пожалуйста, что делать с ошибкой: 4: Syntax error: "(" unexpected

С этим я согласен на все 100%. Скорость динамических языков можно поднять только написанием большей часть программы в виде модулей на C. Иногда даже с inline-ассемблером. Кто бы спорил... Дело не в инструментах, дело в парадигмах и подходах к написанию ПО. Дело в мышлении, а инструмент обычно служит только надуманной причиной для объяснения удач или неудач того, или иного проекта. Просто тем, кто плохо соображает на низком уровне, иногда полезно вначале на более высоком уровне покодить. Со временем зарываясь на более низкие уровни. Да и не для каждого типа мышления такие ЯП. Это уже на любителя. Но ядро должны разрабатывать наиболее правильным способом высококвалифицированные специалисты. Подозреваю, что некоторые из них даже не понимают сложности проекта, над которым они работают. Общая концепция монструозного ядра просто не укладывается у них в голове. В результате они не видят всей картины. Один что-то закоммитил, другой тоже, без понимания того, как коммит первого отразится на работе его кода. А там ещё что-то добавилось... Мне кажется, с ростом ядра теряется контроль над пониманием работы ядра в целом. Это всё больше и больше мешает нормальной разработке ядра. Может стоит форкнуть ветку, в которой пару лет проводить рефакторинг, переписывая всё наилучшим образом? Очистившееся ядрышко, затем наворотить новыми плюшками, оформив их как модули? Слияние наработок можно вести постепенно, и это даст ощутимый результат в будущем.

2.6.36-gentoo - работает))) запустил ни чем не убиваемый эксплоит. но т.к. все сессии bash в cgroups, тупо заморозил его. пусть будет зомби до ребута)))

Запустил, по тормозило пару минут потом запустил `cat /dev/urandom > /dev/null` стало легче, потом через минуту все прошло загрузка CPU в норме, в dmesg:

VFS: file-max limit 129179 reached

>В результате они не видят всей картины. Уже невозможно видеть всю картину

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

А кто профинансирует ?

Добавлю про баг (недавно сам отловил что-то похожее) Ковырял очереди пакетов через tc В момент постановки фильтра с возможно некорректным parent зависал терминал с ssh, далее по ssh подключиться уже невозможно, при локальном разборе обнаруживались процессы sshd, tc и что-то там еще, при этом kill -9 не работает. В логе ядра длинный срач (никакого kernel panic) почти вся система при этом работает, но не управляема, соответственно жесткий reboot. Права root, другие некорректные команды tc просто отбрасываются, соответственно что-то в ядре действительно не так... Система Debian Lenny

> ибо компьютер — не изолированная идеальная система,

Да, внешние воздействия придется моделировать, увы.

И памяти надо будет много.

Но это лучше, чем ничего.

>> Давай пилить gnu/mach!

нет уж, в морг - значит в морг

Одно другому же не противоречит.

>C не мешает писать корректные программы. Правильнее говорить, он не помогает их писать, но зато программы на нем писанные работают в разы, а то и на порядки быстрее написанных на «безопасных» языках

1) Далеко не всегда

2) На «безопасных языках» и прочих пайтонах пишут быдлокодеры - они просто по определению оптимально писать код не умеют

Ну, я в гномовском терминале запускал. Кодировка могла слететь, если было пропущено «>/dev/null». Вернуть кодировку можно командой reset.

> Иногда это приемлимо, но никогда - для серверных задач.

Опять гуру разоткровеничались. Это для MPI неприемлимо.

> 2) На «безопасных языках» и прочих пайтонах пишут быдлокодеры - они просто по определению оптимально писать код не умеют

Да-да, весь мир идиоты, один вы умный и пишите всё строго на С(++).

http://www.faqs.org/docs/artu/ten-thousand.html

> Если дешевле получить убытки, чем добиться их отсуствия - так и надо делать.

Не всегда. Ариан 5, к примеру, контрпример.

> Взять тот же 12309 - ты что, думаешь, что баги подобного рода решаться верификацией ?

Возможно. Не ясно, речь о проблемах количества (алгоритм n^3, грубо говоря) или качества (кто-то спит, когда этого не ожидают). Второй случай — к верификации как раз.

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

Верифицируется система в целом, разумеется. Это кошмар, а что делать %)

на селероне 1200 и 300мб sdram + arch + kernel26-lts: мёртвый стак - *** -, kernel 2.6.35: ..ммм.. да.. чем то похоже на просмотр флэша -> Ctrl+Alt+BS помог. нуп.. по крайней мере не последний раз))

Solaris 11 Express работает как ни в чем не бывало. Процесс отжирает все свободное прцессорное время, но убивается на ура.

> Ну использую функциональное программирование уже сейчас. Это модель с доказуемым результатом.

А ЧФП не эквивалентно ламбда-исчислению?

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

Вот это - точно!!! Деньги, деньги... Какое там, чтобы остановиться и подумать об архитектуре/алгоритмах. Проблема НЕ техническая, а подхода к работе и заработку,

>Плевать на «крутость», я до сообщества пытаюсь понимание проблемы донести.

ЛОР - это то самое место, да.

не знаю, что там подразумевается под «Ч», но ФП эквивалентно

>Да-да, весь мир идиоты, один вы умный и пишите всё строго на С(++).

Нет, конечно. Стараюсь вообще не писать на C, тем более «++»:)

Просто под «безопасными» языками обычно здесь почему-то понимают Java-Ынтырпрайз-код и Говно-питоно-код:)

>Напиши ОС на «безопасном» языке и ужаснись производительности.

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

> что-то в ядре действительно не так...

оно там давно не так ) вспомни про не убиваемые процессы

Я балда, стрелочку перенаправления забыл. Спасибо.

> Просто под «безопасными» языками обычно здесь почему-то понимают Java-Ынтырпрайз-код и Говно-питоно-код:)

Дартаньян детектед! И на чем монсьер пишет, если не секрет?

>И на чем монсьер пишет, если не секрет?

На чём удобнее для каждой конкретной задачи

Ну да, такой конечный автомат с 2^(2^32 * 8) состояниями.

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

> На чём удобнее для каждой конкретной задачи

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

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