Выпущен (http://genode.org/news/genode-live-demonstration-2010-11) LiveCD с демонстрацией работы открытой микроядерной ОС Genode (http://genode.org). Продемонстрированы возможности по запуску паравиртуализированного Linux-окружения поверх ядра Genode, поддержке выполнения Qt-приложений, поддержки 3D-графики (OpenGL) и работы специализированного интегрированного web-браузера на базе движка Webkit, позволяющего запускать Genode-приложения в виде плагинов или загружать виртуализированный Linux в браузерном окне. LiveCD занимает (http://genode.org/download/live-cds) 221 Мб и может быть запущен как на реальном оборудовании, так и в окружениях Qemu/KVM и VirtualBox.
<center><a href="http://genode.org/livecd10.11.png"><img src="http://www.opennet.me/opennews/pics_base/28695_1290019415.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>Genode OS является открытой микроядерной операционной системой, которая предоставляет разработчика...
URL: http://genode.org/news/genode-live-demonstration-2010-11
Новость: http://www.opennet.me/opennews/art.shtml?num=28695
>может быть запущен как на реальном оборудовании, так и в окружениях Qemu/KVM и VirtualBox.
>Продемонстрированы возможности по запуску паравиртуализированного Linux-окружения поверх ядра Genodeа внутри паравиртуализированного Linux-окружения ещё qemu запустить можно?
>>а внутри паравиртуализированного Linux-окружения ещё qemu запустить можно?а под qemu запустить винду, в ней Дюну 2 и спросить на тут почему звук неработает?
можно ли в Linux'е, *BSD сделать такой выпадающий терминал как в сабже? Еще чтобы так же плавно выезжал .
quake console или как-то так
yeahconsole - описано тут:
Смотря какая DE...
В кедах Yakuake... в гноме, тоже какое-то решение было.. честно говоря забыл как называется...
под gtk2 есть tilda должна быть в репозитории вашего дистрибутива
guake
имхо если встречают по одёжке, то первое впечатление шикарное. очень няшный скриншот, смотрю и появляется желание на виртуалке запустить это чудо.
ИМХО, за микроядерной архитектурой будущее, только жаль что как-то медленно процесс идёт...
> ИМХО, за микроядерной архитектурой будущее, только жаль что как-то медленно процесс идёт...С середины 80-х годов, 15 лет уже. Смешно сказать, новые ОС образца 85-87-гг делались сетевыми (т.е. кластеризация), микроядерными и реального времени.
А у нас в 2010-м до сих пор монолитный UNIX.
нету у вас в 2010-м UNIX
> С середины 80-х годов, 15 лет ужеo_O
Да, 25, опечатался.
попробуйте OS Inferno возможно вам понравится
--
2010 - 15 = ?
ну причём тут...
> попробуйте OS Inferno возможно вам понравится
> --
> 2010 - 15 = ?Опечатался, 25.
> А у нас в 2010-м до сих пор монолитный UNIX.Что, у вас вот прямо так монолитный и даже не модульный? И именно UNIX? Чего это за уродца вы выкопали? oO Кстати у вас еще и х86 поди? Совместимый с ... 8086 из начала 80-х, прикиньте? И до сих пор ископаемый 16-битный BIOS поди?! :).
ЗЫ кстати, с середины 80-х прошло "немного" больше чем 15 лет :P. Баг в вычислениях? :)
модульная != микроядерная
> Что, у вас вот прямо так монолитный и даже не модульный? И
> именно UNIX? Чего это за уродца вы выкопали? oO Кстати у
> вас еще и х86 поди? Совместимый с ... 8086 из начала
> 80-х, прикиньте? И до сих пор ископаемый 16-битный BIOS поди?! :).Линукс и БСД - это Юниксы, по факту, а не по формальностям. А всё остальное -
чистая правда. Именно в такой глубокой жопе всё и находится.> ЗЫ кстати, с середины 80-х прошло "немного" больше чем 15 лет :P.
> Баг в вычислениях? :)Опечатка. Вы уже 3-й, кто заметил. Пожалуй, в следующий раз буду делать намеренно, чтобы народ порадовался :-).
> Баг в вычислениях? :)Нет, криокамера.
А что с Хайку? Почему они не могут микроядерную структуру допилить? Какой-то гибрид изобретают.
> А что с Хайку? Почему они не могут микроядерную структуру допилить? Какой-то
> гибрид изобретают.гибрид - это вынужденный шаг для увеличения быстродействия там где это критично....
Видимо будущее за гибридами.
Видимо будущее за NT?
Очередная априори дырявая поделка - на этот раз на C++.
не, не. видимо, нужно так:Очередная априори дырявая поделка - на этот раз на C++, так как:
1. тезис. обоснование. ссылки
2. тезис. обоснование. ссылкиn. тезис. обоснование. ссылки
> не, не. видимо, нужно так:
> Очередная априори дырявая поделка - на этот раз на C++, так как:Мои тезисы эмпирически обоснованы опытом всех сложных публичных проектов на C++, реализующих какие-либо механизмы защиты на уровне абстракций C++ (а не на более высоком уровне типобезопасной ВМ, например).
Разработчики Genode СВОИ тезисы ничем не обосновывают - это "почему-то" никого не волнует. Например "Genode is a novel operating-system architecture that enables dynamic workload while retaining security and robustness." - заявление есть, матмоделей и чёткой документации нет (я почитал, не поленился). По духу это OpenBSD в новой плоскости, только здесь прославляют не аудит, а контроль сложности программных систем, но при этом контролируют её по-прежнему вручную. Если бы время буквально и нещадно било линейкой по рукам таких "котролёров" за каждую уязвимость и за каждую её незамеченную и публично не объявленную эксплуатацию, сегодняшние ОС писали бы совсем другие люди и на качественно ином уровне.
Когда C/C++ используют в силу исторических причин, я могу понять. Когда на этих языках создают новые ОС и заявляют о их безопасности - это не только самообман разработчиков, но и публичная ложь. В своё время Таненбаум (да, я знаю, что миниксы написаны на C - не об этом сейчас речь) пытался убедить сноба-Торвальдса, что микроядерная архитектура менее сложна, более стабильна и по ряду других причин более предпочтительна, чем моноядерная - Торвальдс сделал по-своему. А теперь он заявляет о своей обеспокоенности "раздутостью" и сложностью кода ядра и признаётся, что стратегии выхода из ситуации у него нет. Время рассудило.
Когда я говорил коллегам, что протокол SSH предпочтительнее SSL/TLS в плане безопасности реализации и безопасности передачи данных, моё мнение проигнорировали. Затем в OpenSSL были найдены уязвимости к выполнению произвольного кода (очередная - пару дней назад), и в TLS были найдены уязвимости к инъекции произвольных данных в защищённый поток. Время рассудило.
Вы, господа, можете сколько угодно праведно негодовать, требовать прямых обоснований тезисов, "минусовать" - мне всё равно, а время рассудит.
>> протокол SSH предпочтительнее SSL/TLS в плане безопасности реализации и безопасности передачи данныхподелись друх откровениями -- что за протокол такой SSH,который предпочтительнее SSL/TLS? хорошо ли ты понимаешь что такое SSH? хорошо ли ты понимаешь что такое SSL/TLS? зачем ты несешь эту херню?
> поделись друх откровениями -- что за протокол такой SSH,который предпочтительнее SSL/TLS?
> хорошо ли ты понимаешь что такое SSH? хорошо ли ты понимаешь
> что такое SSL/TLS? зачем ты несешь эту херню?А сам-то ты что-нибудь понимаешь, хамло? Наличие/отсутствие парсера ASN.1 различить в состоянии? Проанализировать историю уязвимостей OpenSSL и TLS в состоянии? Сопоставить с историей OpenSSH и протокола SSH - в состоянии? А оценить сравнительную сложность спецификаций? А припомнить логические просчёты в различных реализациях SSL/TLS?
А ведь вы кое в чем правы, к сожалению: SSL как протокол - излишне наворочен. Что неизбежно приведет к бОльшему числу багов в его реализации. И приводит.
> Когда C/C++ используют в силу исторических причин, я могу понять. Когда на
> этих языках создают новые ОС и заявляют о их безопасности -
> это не только самообман разработчиков, но и публичная ложь.а на каких языках по вашему правильно создавать новые ОС и обоснованно заявлять об их безопасности ? и почему те языки будут лучше ?
На типобезопасных языках, вроде оберонов. Лучше в плане безопасности потому, что они не допускают целые классы наиболее серьёзных ошибок, приводящих к эксплуатации.Но тут главное не язык (и я не фанат оберонов), а принципы и качество их воплощения. Можно создать типобезопасный язык, не позволяющий эксплуатировать переполнения буферов и величин, но допускающий утечки данных из ядра в юзерспейс ввиду отсутствия автоматической инициализации значений. Можно по недосмотру прикрутить к "хорошему" языку "плохие" ассемблерные вставки, можно выделять в юзерспейс страницы с уже инициализированными многоцелевыми буферами и опять допустить утечки, а это могут быть и пароли, и криптоключи. Нюансов много, и панацеи нет, но высокая безопасность без типобезопасности - это эмпирический нонсенс.
> высокая безопасность без типобезопасности - это эмпирический нонсенс.Есть такой фрукт, D. J. Berstein. Который известен в том числе и тем что как ни странно умудрился написать несколько довольно секурных программ на типоопасном языке. При том - он настолько уверен в своем коде что даже предлагает премии за обнаружение уязвимостей в своих программах. Насколько мне известно, для qmail он не выплачивал премии ни разу а для djbdns - аж один раз.
Кстати, этот товарисч опубликовал имхо вполне заслуживающие внимания доки по части секурити ПО, где по косточкам разобрал - откуда берутся уязвимости и как с этим бороться. При том - а знаете, в работах этого Берштейна в частности доходчиво видно что уязвимости могут быть (и будут) и в типоопасных языках. Там у него вообще никакой привязки к типоопасности или типобезопасности нет. Он оперирует довольно генерализованным подходом - рассматривает уязвимости как специфичные баги ПО, приводящие к выходу работы ПО за рамки спецификаций. И ведь он прав в этом подходе. И, главное, этот подход вообще никак не привязан к типоопасности или типобезопасности. Вся эта типобезопасность - лишь унылые попытки заткнуть програмерское раздолбайство тряпками и скотчем. Можно подумать что от этого раздолбаи перестанут допускать ошибки и ПО перестанет выходить за рамки задуманных изначально спецификаций. А знаете, если из-за бага например взлетит химзавод или самолет сядет мимо аэродрома - вам не все-равно ли будет - переполнение буфера это вызвало или просто тупая логическая ошибка? :)
> Насколько мне известно, для qmail он не выплачивал премии ни разу
> а для djbdns - аж один раз.Для qmail не выплачивал, потому что выкрутился. И каков размер вознаграждения? Едва ли достаточный. За уязвимость в высокозащищённой сетевой службе на чёрном рынке можно получить до 100к условных енотов.
То есть даже в бернштейновских программах были найдены и опубликованы уязвимости к выполнению произвольного кода. И что послужило причиной уязвимости - небезопасность типов в C. И в чём мораль? Риторический вопрос.
> и в типоопасных языках. Там у него вообще никакой привязки к
Видимо, в типобезопасных.
> типоопасности или типобезопасности нет. Он оперирует довольно генерализованным подходом
> - рассматривает уязвимости как специфичные баги ПО, приводящие к выходу работыЧеловек - не машина, и подходов придерживается до первой ошибки, как и сам Бернштейн.
> ПО за рамки спецификаций. И ведь он прав в этом подходе.
Прав в чём именно? Вы, как я понял, делаете вывод, что вот раз Бернштейн рассматривает ... , то типобезопасность не нужна. Абсурд. Бернштейна спростите - готов поспорить, что он с вами не согласится.
> И, главное, этот подход вообще никак не привязан к типоопасности или
> типобезопасности. Вся эта типобезопасность - лишь унылые попытки заткнуть програмерское"Унылые попытки" - очень интересная оценка. Бернштейну это расскажите - то-то он вас поддержит, по сути, в постулатах о никчёмности принципа многоуровневой защиты.
> раздолбайство тряпками и скотчем. Можно подумать что от этого раздолбаи перестанут
> допускать ошибки и ПО перестанет выходить за рамки задуманных изначально спецификаций.Да нет никаких изначально задуманных спецификаций, ни в 99.99999% случаев. А если бы и были, то спецификации на модель, а не на процессы реального мира. Уж не грезите ли вы панацеей?
> А знаете, если из-за бага например взлетит химзавод или самолет сядет
> мимо аэродрома - вам не все-равно ли будет - переполнение буфера
> это вызвало или просто тупая логическая ошибка? :)Нет, не всё равно. Устранить саму возможность переполнений, и некоторая вероятная часть аварий уже никогда не случится.
> сегодняшние ОС писали бы совсем другие люди и на качественно ином уровне.Ну вон в вебе появились другие люди. Там вообще в принципе не важно какая операционка. И их другие уязвимости - на качественно ином уровне. Вы довольны? Проблема только в том что почему-то уязвимости никуда не пропали :). И, кстати, саму по себе операционку через уязвимости взламывают не часто, мягко говоря. Обычно ломают через тупой пароль SSH, через уязвимость демона или веб-приложения, etc. И главное от этих взломов никакие микроядра ни разу не спасут.
> менее сложна, более стабильна и по ряду других причин более предпочтительна,
> чем моноядерная - Торвальдс сделал по-своему. А теперь он заявляет о
> своей обеспокоенности "раздутостью" и сложностью кода ядра и признаётся, что стратегии
> выхода из ситуации у него нет. Время рассудило.ИМХО, если в микроядерную систему впихнуть столько же фич сколько сейчас в линуксе - оно в сумме станет ничем не лучше. Просто потому что суммарная сложность системы не сильно улучшится. И проблемы в итоге вылезут те же самые, только частично перенесутся в юзермод, на чем отличия и закончатся. Дело в том что система которая ничего не умеет - почему-то никому не нужна, кроме редких нишевых случаев. Вообще, вы так говорите как будто кучу серверов в интернете регулярно ломают через ремотно эксплуатируемые дыры ядер. Хотя по факту таких дыр как-то весьма немного бывало. На многие порядки меньше чем дыр в "сторонних" демонах, вебприложениях или просто кретинов-админов с тривиальными паролями или весьма эпичных по масштабу логических ошибок, наконец. Заметьте, современные хаксоры вообще не пытаются ядро сплойтами ломать. Они просто пускают армию ботов подбирать пароли на ssh или юзают ошибки в демонах/либах/чем там еще.
>> сегодняшние ОС писали бы совсем другие люди и на качественно ином уровне.
> Ну вон в вебе появились другие люди. Там вообще в принципе неПоявление в вебе других людей, о которых я говорил, началось и закончилось году в 96-ом, с выходом всеми проигнорированного Juice.
> важно какая операционка. И их другие уязвимости - на качественно ином
> уровне. Вы довольны? Проблема только в том что почему-то уязвимости никудаНет, не доволен. Браузеры пишут всё те же люди, и до сих пор на C/C++, и до сих пор с уязвимостями к выполнению произвольного кода. А современные веб-технологии - совместный legacy-выкидыш недальновидных академиков, подневольных инженеров и коммерсантов из трёх известных контор: Netscape, Sun и Microsoft.
> не пропали :). И, кстати, саму по себе операционку через уязвимости
> взламывают не часто, мягко говоря. Обычно ломают через тупой пароль SSH,И понеслась мысль по древу... В свете предпоследней локальной уязвимости в RDS я даже комментировать не буду.
> через уязвимость демона или веб-приложения, etc. И главное от этих взломов
> никакие микроядра ни разу не спасут.Да, микроядра сами по себе не спасут. Перечитайте мой первый комментарий к новости и заканчивайте разговаривать с самим собой.
> ИМХО, если в микроядерную систему впихнуть столько же фич сколько сейчас в
> линуксе - оно в сумме станет ничем не лучше. Просто потому
> что суммарная сложность системы не сильно улучшится. И проблемы в итогеА я почему-то всегда думал, что в системах на микроядре гораздо меньше проблем в силу редкости совместного доступа к данным и более простых интерфейсов IPC. Но вы раскрыли мне глаза: "суммарная сложность системы" же. Извините, надоело.
> вылезут те же самые, только частично перенесутся в юзермод, на чем
> отличия и закончатся. Дело в том что система которая ничего неДа чушь вы говорите, если серьёзно. Такое впечатление, что вы о микроядрах ничего даже толком не читали.
> умеет - почему-то никому не нужна, кроме редких нишевых случаев. Вообще,
То, что система ничего не умеет - в этом, конечно, типобезопасность и микроядро виновато. Вот монолитные системы - они конечно же умеют всё и сразу, да.
> вы так говорите как будто кучу серверов в интернете регулярно ломают
> через ремотно эксплуатируемые дыры ядер. Хотя по факту таких дыр как-то
> весьма немного бывало. На многие порядки меньше чем дыр в "сторонних"А вы так говорите, как будто располагаете статистикой по взломам. И причём здесь "ремотно"? Вы qmail и djbdns вспомнили - ну так отдайте себе отчёт в том, что при дырявом ядре ОС их архитектура с разделением привилегий гроша ломанного не стоит: если взломщику удалось выполнить произвольный код в контексте непривилегированного процесса, ничто не помешает ему повысить свои привилегии через уязвимость в ядре.
> эпичных по масштабу логических ошибок, наконец. Заметьте, современные хаксоры вообще не
> пытаются ядро сплойтами ломать. Они просто пускают армию ботов подбирать паролиЯ-то как раз замечаю и стараюсь держаться в курсе. А вы витаете в каких-то своих представлениях, сформированных на примере никому не нужных систем.
> на ssh или юзают ошибки в демонах/либах/чем там еще.
Да вот, чё там ещё:
http://www.grsecurity.net/~spender/wunderbar_emporium2.tgz
http://www.grsecurity.net/~spender/enlightenment.tgz"Хаксоры" до сих пор юзают. На тех самых никому не нужных системах. А горе-админы таких систем до сих пор пишут Шпенглеру угрозы преследованиями в суде за распространение вредоносного ПО. ;) Мораль: что есть, то и юзают, и ядерные эксплойты в том числе.
>Да чушь вы говорите, если серьёзно. Такое впечатление, что вы о микроядрах ничего даже толком не читали.Так, к сожалению, многие даже если и читают, то видят только то, что хотят увидеть. Примерно как и вы в обсуждении новости об OpenBSD.
> Так, к сожалению, многие даже если и читают, то видят только то,
> что хотят увидеть. Примерно как и вы в обсуждении новости об
> OpenBSD.Если вы иного мнения об OpenBSD - дело ваше. Вот только несуществующих желаний попрошу мне не приписывать. Я был бы искренне рад, если бы моё видение ситуации вокруг OpenBSD основывалось не на фактах (домыслы я тоже допускаю), так что хотел бы видеть обратное тому, что вижу. Вот буквально на днях смотрел errata'у - оказалось, что локальную уязвимость в getsockopt(2) в 2009-ом они обозначили как RELIABILITY FIX при наличии рабочего эксплойта для эскалации привилегий.
Errata: http://openbsd.org/errata46.html (003: RELIABILITY FIX: October 28, 2009)
Эксплойт и описание: http://vulndev.blogspot.com/2009/11/openbsd-ownage-party.html (Monday, November 02, 2009)Вот интересно, какие оправдания такой классификации найдут апологеты OpenBSD, помимо обвинений в слепой предвзятости.
Может быть, такие? Если уж хотите ткнуть, так смотрите, во что.At first, in order to exploit this vulnerability to gain root priv, we have to be able to map page at adresse NULL. Since OpenBSD 4.4, this has been disabled for all architectures. I haven't found any way of bypassing this protection. Thus, this exploit works only on versions prior to OpenBSD 4.4.
А OpenBSD 4.4 НЕ является поддерживаемым релизом уже с год как.
> А OpenBSD 4.4 НЕ является поддерживаемым релизом уже с год как.Эксплойт не работал уже в 4.4. Я перепутал год добавления запрета на маппинг нулевого адреса:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/incl...Прошу прощения за дезинформацию.
> Когда C/C++ используют в силу исторических причин, я могу понять. Когда на этих языках создают новые ОС и заявляют о их безопасности - это не только самообман разработчиков, но и публичная ложь.
> Но тут главное не язык (и я не фанат оберонов), а принципы и качество их воплощения.Вы бы для начала сами определились бы, что важнее - язык, на котором написана операционка, или все-таки качество воплощения.
Что касается безопасности, то суровая правда жизни в том, что безопасность обратно пропорциональна уровню контроля. То есть, чем безопаснее система, тем больше она "думает за вас" и тем меньше позволяет вам выполнить нетривиальных действий, которые она будет считать "ошибочными". Именно поэтому самые востребованные операционки написаны на Си (даже не на Си++, который уже много делает без вашего ведома, "под капотом"), самом гибком и, вместе с тем, самым "небезопасном" из высокоуровневых языков.
А уж если говорить о микроядерных ОС, то реализовывать их на "небезопасных" языках сам бог велел, потому что:
1) при меньшем количестве кода меньше вероятность допустить ошибку и
2) микроядро должно быть высокооптимизированным, чего трудно добиться с "безопасными" языками, которые неизбежно будут генерить лишний код.
> Вы бы для начала сами определились бы, что важнее - язык, на
> котором написана операционка, или все-таки качество воплощения.Да нет, уважаемый, это вы переводите вопрос в плоскость "что важнее". Детская постановка вопроса.
> Что касается безопасности, то суровая правда жизни в том, что безопасность обратно
> пропорциональна уровню контроля. То есть, чем безопаснее система, тем больше она
> "думает за вас" и тем меньше позволяет вам выполнить нетривиальных действий,Госсподи, опять апологетика. Посмотрите на Аду или модулы - никто вам там не запрещает нетривиальничать, вот только код выходит типобезопасным по умолчанию, а выкрутасы - исключение из правил, объявляемое явно, каким оно и должно быть. В Си и ему подобных языках всё наоборот: исключением из правил является безопасный код, забота о безопасности которого ложится на программиста, а не на язык. Есть Cyclone, в конце-концов, который полностью с Си совместим и позволяет-таки писать безопасный код в порядке правила, а не исключений.
> которые она будет считать "ошибочными". Именно поэтому самые востребованные операционки
> написаны на Си (даже не на Си++, который уже много делаетИменно поэтому, конечно же. Это же аксиома и доказательств не требует: распространённость == технологическое превосходство.
> без вашего ведома, "под капотом"), самом гибком и, вместе с тем,
> самым "небезопасном" из высокоуровневых языков.Вы путаете гибкость языка с отсутствием в нём средств безопасного программирования. Не хочу переходить на личности - сами решайте, хватает ли вам элементарного кругозора в той области, о которой вы берётесь с апломбом судить.
> А уж если говорить о микроядерных ОС, то реализовывать их на "небезопасных"
> языках сам бог велел, потому что:
> 1) при меньшем количестве кода меньше вероятность допустить ошибку иТа же ошибка.
> 2) микроядро должно быть высокооптимизированным, чего трудно добиться с "безопасными"
> языками, которые неизбежно будут генерить лишний код.Ну а это вообще стыд и срам (видимо, навеянный Java-технологиями). Слаще морковки, как говорится, ничего не ели.
> Да нет, уважаемый, это вы переводите вопрос в плоскость "что важнее".Вообще-то, именно вы написали "тут главное не язык", хотя несколькими постами раньше обвиняли во лжи тех, кто заявляют, что пишут безопасные системы на Си. Так что не надо валить с больной головы на здоровую.
> Госсподи, опять апологетика. Посмотрите на Аду или модулы - никто вам там
> не запрещает нетривиальничать, вот только код выходит типобезопасным по умолчанию, а
> выкрутасы - исключение из правил, объявляемое явно, каким оно и должно
> быть.Еще раз говорю: безопасность всегда достигается за счет вашего контроля над системой. А типобезопасность обычно приводит к тому, что создается еще больше типов со схожим функционалом и усложнению языка. В Аде, например, несколько типов строк (Bounded, Fixed, Unbounded...). В результате я должен сначала не ошибиться, выбирая какой тип строк использовать в каждой конкретной ситуации, а потом гадать, что из этого получится в ядре написанной мной ОС, т.к. реализация этих строк от меня скрыта и может варьироваться от компилятора к компилятору. Нет уж, лучше старые добрые сишные ASCIZ...
> В Си и ему подобных языках всё наоборот: исключением из
> правил является безопасный код, забота о безопасности которого ложится на программиста,
> а не на язык.А забота о безопасности _в_принципе_ ложится на программиста. Если вы считаете, что заботу о безопасности можно перенести на компилятор, библиотеку или что-то еще, то я сомневаюсь, что вы можете создавать безопасные системы :)
> Есть Cyclone, в конце-концов, который полностью с
> Си совместим и позволяет-таки писать безопасный код в порядке правила, а
> не исключений.Я вас умоляю! Язык в котором три (ТРИ!) типа указателей, в то время как в "безопасных языках" от указателей вообще стараются избавляться...
> Вы путаете гибкость языка с отсутствием в нём средств безопасного программирования. Не
> хочу переходить на личности - сами решайте, хватает ли вам элементарного
> кругозора в той области, о которой вы берётесь с апломбом судить.Ну, понятно. По существу возразить нечего, поэтому вы решили важно надуть щеки и встать в снисходительную позу :)
>> Да нет, уважаемый, это вы переводите вопрос в плоскость "что важнее".
> Вообще-то, именно вы написали "тут главное не язык", хотя несколькими постами раньшеВообще-то я написал это в ответ на вопрос о конкретном языке, и смысл моих слов в том, что важен не конкретный язык, а наличие в нём типобезопасности (тот самый принцип) и качества её реализации.
Сначала вы прицепились к слову "принцип" и исказили смысл выдранной части фразы с ним - якобы я сначала говорил о главенстве языка, а потом - о главенстве принципа. Когда на самом деле я и изначально, и потом говорил о важности принципа - типобезопасности.
Теперь выдрали и прицепились к слову "главное" - якобы я поставил вопрос в плоскости "что главнее".
А вы, продолжайте юлить и юродствовать - мне ваши и им подобные опусы одно удовольствие разбирать.
> обвиняли во лжи тех, кто заявляют, что пишут безопасные системы на
> Си. Так что не надо валить с больной головы на здоровую.Не пишут безопасные системы, а голословно заявляют о безопасности систем.
> Еще раз говорю: безопасность всегда достигается за счет вашего контроля над системой.
Ещё раз опровергаю: язык, предоставляющий средства безопасного программирования, априори не ограничивает пресловутый "контроль над системой". Я даже больше скажу: он его усиливает, позволяя писать безопасный код. На том же Си ещё не написано ни одной безопасной сложной системы, работающей с данными на уровне абстракций самого Си.
> А типобезопасность обычно приводит к тому, что создается еще больше
> типов со схожим функционалом и усложнению языка. В Аде, например, несколькоИ сейчас вы на примере трёх (!) типов строк в Аде будете мне рассказывать об увеличении количества типов? Во-первых, обосновать большую сложность работы со строками в Аде по сравнению с Си вы не сможете - ни умозрительно, ни на примерах. Дерзайте!
Во-вторых, сколько специальных целочисленных типов в Си? Мало ли уязвимостей было (есть и будет) из-за целочисленных переполнений при неявных преобразованиях результата? А сколько функций безопасной работы со строками (str*, strn*, strl*), не способных, к тому же, окончательно решить проблему их небезопасной обработки? А сколько внутренних API для работы со строками реализовано в рамках проектов с повышенными требованиями к безопасности (софт Бернштейна, vsftpd, Dovecot)?
Как просто, оказывается, в Си работать со строками - ну полный контроль! И как сложно в Аде - три типа, и никакого контроля. Ещё расскажите мне про "лишний код" - вот тут я действительно, буквально посмеюсь.
> типов строк (Bounded, Fixed, Unbounded...). В результате я должен сначала не
> ошибиться, выбирая какой тип строк использовать в каждой конкретной ситуации, аАх, ох. И какова же цена ошибки? Каковы типичные ошибки? Как часто возникают? Насколько легко идентифицировать и исправить? Давайте сравнивать с Си.
> потом гадать, что из этого получится в ядре написанной мной ОС,
В Си вы тоже гадаете вместо того, чтобы спецификацию на язык почитать?
> т.к. реализация этих строк от меня скрыта и может варьироваться от
> компилятора к компилятору. Нет уж, лучше старые добрые сишные ASCIZ...- А чем лучше?
- Чем в Аде.Во истину каждый кулик своё болото хвалит. Вы одно забыли упомянуть - в Си, в отличие от C++, приемлемой альтернативы ASCIZ просто нет. ;)
К слову, ядра ОС сейчас собираются отдельными версиями компиляторов - каждый требует подгонки по различным причинам. И структуры выравниваются в зависимости от архитектуры, и endianess слов учитывается. Зато контроль какой - каждая мелочь контролируется!
> А забота о безопасности _в_принципе_ ложится на программиста. Если вы считаете, что
Здесь вы передёрнули смысл словосочетания "безопасность кода" и невинно перевели разговор с обсуждения отдельного аспекта обеспечения безопасности (безопасного кода в смысле типобезопастности) на безопасность вообще. 4 за находчивость, 2 за предпочтение дешевой полемики разговору по существу.
> заботу о безопасности можно перенести на компилятор, библиотеку или что-то еще,
> то я сомневаюсь, что вы можете создавать безопасные системы :)Унылая попытка доведения до абсурда.
> Я вас умоляю! Язык в котором три (ТРИ!) типа указателей, в то
> время как в "безопасных языках" от указателей вообще стараются избавляться...Подумать только, ТРИ типа!!!11 Наверное, они в ТРИ раза небезопаснее, чем в Си!!!11
:))) Спасибо, реально повеселили. :)
И чем же вам не нравятся эти типы?
>> Вы путаете гибкость языка с отсутствием в нём средств безопасного программирования. Не
>> хочу переходить на личности - сами решайте, хватает ли вам элементарного
>> кругозора в той области, о которой вы берётесь с апломбом судить.
> Ну, понятно. По существу возразить нечего, поэтому вы решили важно надуть щеки
> и встать в снисходительную позу :)Возразить на что? На ваше голословное утверждение о том, что якобы "именно поэтому самые востребованные операционки написаны на Си"? у так папы юникса уже написали Plan 9, уже сделали попытку исправить свои ошибки и уже озвучили причины, по которым, на их взгляд, "востребованные операционки" остаются таковыми.
Вы-то сами чем своё утверждение обосновали? Ничем. Вместо обоснований - переход на личность собеседника в нелестных эпитетах.
Дайте мне что-нибудь, кроме слов, высосанных из пальца, за что я смогу взяться и опровергнуть вашу чушь - опровергну с радостью. До сих пор я слышал только религиозные постулаты и никакой конкретики, любитель говорить по существу вы мой.
> А вы, продолжайте юлить и юродствовать - мне ваши и им подобные
> опусы одно удовольствие разбирать.Ну, судя по тому, что вы не поленились написать ответ на один из этих "опусов" длиной аж в два экрана, вам их действительно удовольствие разбирать.
> Не пишут безопасные системы, а голословно заявляют о безопасности систем.
Пока что именно вы голословно заявляете о том, что якобы существуют какие-то более безопасные системы, написанные на каких-то более безопасных языках.
>> Еще раз говорю: безопасность всегда достигается за счет вашего контроля над системой.
> Ещё раз опровергаю: язык, предоставляющий средства безопасного программирования, априори
> не ограничивает пресловутый "контроль над системой". Я даже больше скажу: он
> его усиливает, позволяя писать безопасный код. На том же Си ещё
> не написано ни одной безопасной сложной системы, работающей с данными на
> уровне абстракций самого Си.Голословное утверждение. Давайте конкретно: какие ОС промышленного уровня, написанные не на Си, оказались более безопасными и по каким критериям?
> И сейчас вы на примере трёх (!) типов строк в Аде будете
> мне рассказывать об увеличении количества типов? Во-первых, обосновать большую сложность
> работы со строками в Аде по сравнению с Си вы не
> сможете - ни умозрительно, ни на примерах. Дерзайте!Имелась ввиду не сложность работы со строками _вообще_, а сложность реализации этой работы применительно к конкретным областям. В частности мы говорили о "безопасных" ОС. Так вот работать со строками в Си не удобно, но их реализация крайне проста и наиболее близка к машинному представлению. В результате она оказывается более эффективной, чем реализация строк в Аде, которая а) скрыта от программиста, б) варьируется в зависимости от типа и в) варьируется в зависимости от компилятора.
> Во-вторых, сколько специальных целочисленных типов в Си? Мало ли уязвимостей было (есть
> и будет) из-за целочисленных переполнений при неявных преобразованиях результата? А сколько
> функций безопасной работы со строками (str*, strn*, strl*), не способных, к
> тому же, окончательно решить проблему их небезопасной обработки? А сколько внутренних
> API для работы со строками реализовано в рамках проектов с повышенными
> требованиями к безопасности (софт Бернштейна, vsftpd, Dovecot)?Но люди продолжают и продолжают на этом писать! Неужели вы считаете, что все 100% этих программистов в течение многих лет продолжают заниматься самообманом? :) Так можно и до теорий заговоров договориться...
> Как просто, оказывается, в Си работать со строками - ну полный контроль!
> И как сложно в Аде - три типа, и никакого контроля.
> Ещё расскажите мне про "лишний код" - вот тут я действительно,
> буквально посмеюсь.Да, лишний код, и это не смешно. Если я работаю с динамическими строками сразу возникают проблемы распределения памяти и сборки мусора, которые неизбежно порождают лишний код. Если в приложении этот код без проблем выполняет ран-тайм библиотека, то в ядре ОС управление этим кодом может стать головной болью программиста и, в конечном счете, привести к ослаблению безопасности.
>> типов строк (Bounded, Fixed, Unbounded...). В результате я должен сначала не
>> ошибиться, выбирая какой тип строк использовать в каждой конкретной ситуации, а
> Ах, ох. И какова же цена ошибки? Каковы типичные ошибки? Как часто
> возникают? Насколько легко идентифицировать и исправить? Давайте сравнивать с Си.Давайте. Давайте для начала приведем примеры ОС, которые могут делать хоть что-нибудь, кроме как "быть безопасными", а потом посмотрим насколько не соответствуют этому призрачному идеалу реально существующие ОС.
>> потом гадать, что из этого получится в ядре написанной мной ОС,
> В Си вы тоже гадаете вместо того, чтобы спецификацию на язык почитать?В Си спецификация очень проста - массив символов, заканчивающийся нулем. Все операции со строками самоочевидны. А вот что творит со строками Ада - я не знаю. Да мне и не надо знать, если я пишу приложение. Но если это встроенная система, работающая на голом железе, то мне совсем не безразлично в какой момент компилятор захочет вызывать менеджер памяти или сборщик мусора.
> Во истину каждый кулик своё болото хвалит. Вы одно забыли упомянуть -
> в Си, в отличие от C++, приемлемой альтернативы ASCIZ просто нет.
> ;)Если бы в С++ была приемлемая реализация строк, мы бы не наблюдали того зоопарка строковых библиотек, который поставляет со своими продуктами каждый разработчик компиляторов.
> К слову, ядра ОС сейчас собираются отдельными версиями компиляторов - каждый требует
> подгонки по различным причинам. И структуры выравниваются в зависимости от архитектуры,
> и endianess слов учитывается. Зато контроль какой - каждая мелочь контролируется!Это какие ядра собираются разными версиями компиляторов? Примеры, пожалуйста.
>> А забота о безопасности _в_принципе_ ложится на программиста. Если вы считаете, что
> Здесь вы передёрнули смысл словосочетания "безопасность кода" и невинно перевели разговор
> с обсуждения отдельного аспекта обеспечения безопасности (безопасного кода в смысле типобезопастности)
> на безопасность вообще. 4 за находчивость, 2 за предпочтение дешевой полемики
> разговору по существу.Слабость вашей позиции в том, что вы воспринимаете безопасность кода как единственный критерий эффективности системы. Причем даже не безопасность вообще, а почему-то именно типобезопасность! В этом есть некий солипсизм. Реальность же такова, что абсолютно безопасных систем не бывает, более того, в них нет необходимости! Сюрприз? Обычно требуется некий компромисс между определенным уровнем безопасности, скорости, потреблением ресурсов и т.п. Как показывает практика, языки, предоставляющие программисту всю свободу и ответственность, здесь наиболее эффективны.
> Подумать только, ТРИ типа!!!11 Наверное, они в ТРИ раза небезопаснее, чем в
> Си!!!11Наверное указатели вообще не нужны для безопасного программирования! Наверное безопасная программа не должна заботиться об адресации каких-то байтов, а оперировать абстрактными типами, максимально защищенными от "дурака"! Не это ли есть типобезопасность!
> Возразить на что? На ваше голословное утверждение о том, что якобы "именно
> поэтому самые востребованные операционки написаны на Си"? у так папы юникса
> уже написали Plan 9, уже сделали попытку исправить свои ошибки и
> уже озвучили причины, по которым, на их взгляд, "востребованные операционки" остаются
> таковыми.Ну и каковы же эти причины? "Ложь и самообман" разработчиков? :)
> Вы-то сами чем своё утверждение обосновали? Ничем. Вместо обоснований - переход на
> личность собеседника в нелестных эпитетах.Замечу, что переход на личности начали именно вы.
>> А вы, продолжайте юлить и юродствовать - мне ваши и им подобные
>> опусы одно удовольствие разбирать.
> Ну, судя по тому, что вы не поленились написать ответ на один
> из этих "опусов" длиной аж в два экрана, вам их действительно
> удовольствие разбирать.Буквально это я и имел ввиду: удовольствие разбирать. Вы пришли, исказили смысл моих слов (неоднократно, и продолжаете это делать), не извинились, даже не поправились, договариваете и домысливаете за меня, уточняющих вопросов не задаёте, ведёте полемику, что-то безапелляционно постулируете, невнимательны, переходите на личности (видимо, наивно решив, что уж коли я высказался о вашей точки зрения в эпитетах а ля "чушь", то у вас есть морально-этическое право "рисовать" на меня оскорбительные словесные карикатуры: "встал в позу", "надул щёки" и т.д.), завышаете требования к качеству моей аргументации, хотя качество вашей к нему даже не приблизилось до сих пор.
Разумеется, мне одно удовольствие - разбирать ваш недалёкий троллинг в порядке оздоровительного конструктивно-праведного негодования. Буквально так.
> Пока что именно вы голословно заявляете о том, что якобы существуют какие-то
> более безопасные системы, написанные на каких-то более безопасных языках.Я подобное не заявлял, потому как придерживаюсь противоположного мнения. Давайте-ка, подкрепите чем-либо очередные свои поспешные обвинения.
> Голословное утверждение. Давайте конкретно: какие ОС промышленного уровня, написанные
> не на Си, оказались более безопасными и по каким критериям?В оберонах (семейство ОС) отсутствуют классы уязвимостей, свойственные системам на Си и обусловленные небезопасными типами в последнем. Вот вам критерий: нет переполнений буфера, ошибок в неконтролируемой арифметике указателей, утечек неинициализированных данных, мутабельных указателей на произвольные адреса и как следствие нет уязвимостей к выполнению произвольного кода через эксплуатацию ошибок перечисленных классов.
> Имелась ввиду не сложность работы со строками _вообще_, а сложность реализации этой
> работы применительно к конкретным областям. В частности мы говорили о "безопасных"Дайте неформальное (хотя бы) определение "сложности работы" и "сложности реализации".
> ОС. Так вот работать со строками в Си не удобно, но
> их реализация крайне проста и наиболее близка к машинному представлению. ВВо-первых, о какой реализации речь - в системе выполнения языка? Думаю, вы не считаете, что простота реализации языка всегда важнее простоты программирования на нём - это слишком грубо. Но получается, что баланс между простотой реализации в Си и простотой программирования на нём вы считаете едва ли не идеалом, "аргументируя" это пространными суждениями о потери контроля, которые конкретики полностью лишены.
Во-вторых, нет никакого машинного представления по умолчанию. Простое представление строк в форме структуры размер+данные[+максимальный_размер], как в Аде и оберонах (например), позволяет всегда за O(1) получить длину строки (или массива), за O(1) размер выделенного буфера, за O(1) позволяет (в принципе) адресовать элемент строки по отрицательному индексу, осуществить автоматические проверки на выход за границы как на этапе компиляции, так и в рантайме.
Ваш "идеал" - представление, требующее прохода по элементам строки для получения её длины, для адресации по отрицательным индексам (арифметика указателей от конца строки), не позволяет выполнять автоматические проверки на выход за границы в рантайме, требует "таскать" за собой размер строки, чтобы упразднить его повторное вычисление и/или проверять на выход за границы вручную, и "таскать" его за собой в библиотечные API, и не иметь возможности проверить размер даже на этапе компиляции. И так далее (проблемы при оптимизации из-за алиасов указателей, проблемы с безопасностью, человеческие ошибки типа off-by-one и прочее).
Можете вы объяснить, чем такой "идеал" "ближе" к реализации? При том, что размеры строк либо неэффективно и небезопасно вычисляются, либо "таскаются" в структурах и аргументах - то есть в Си вы пишете так, как та же "Ада" пишет за вас. К операциям изменения длины строк (результатов операций со строками) в динамической памяти это тоже относится.
Я вам даже больше скажу - вы в libc (особенно в glibc) работаете со строками, неявно вызывая код на ассемблере внутри библиотечных функций, а вовсе не "гибкий" и оптимально скомпилированный код на Си. Ничто не мешает по нужде реализовать подобные ассемблерные вставки на той же Аде - причём, реализовать один раз в теле тех же библиотечных функций. И оптимизаций таких - легион. И не только в функциях со строками, но и в ядрах ОС, в криптографических библиотеках, в библиотеках потоковой обработки данных и так далее. Как портируемый и при этом эффективный "высокоуровневый ассемблер" Си себя не оправдал, невзирая даже на те деньжищи и усилия, которые на него потрачены.
> результате она оказывается более эффективной, чем реализация строк в Аде, которая
> а) скрыта от программиста, б) варьируется в зависимости от типа и
> в) варьируется в зависимости от компилятора.Вот только эти мантры вы и в состоянии противопоставить. Ответ на которые один: читать спецификацию. Попробуйте собрать ядро линукса или любой из тройки *BSD TenDRA'ой или ICC *без* правок, которые специально для этого уже кое-где внесены в код разработчиками этих ОС. Или попробуйте собрать современные ядра линукса с gcc 2.95.
> Но люди продолжают и продолжают на этом писать! Неужели вы считаете, что
> все 100% этих программистов в течение многих лет продолжают заниматься самообманом?Некоторые продолжают: расписывают во всяких features.html, какая их ОС замечательная в плане безопасности, а потом публикуется очередная уязвимость ядра, прямолинейная эксплуатация которой сводит на нет всё то, о чём в тех features.html поначиркано. Это FreeBSD.
Некоторые выпускают RELIABILITY FIX на уязвимость ядра, позволяющую локально получить привилегии root. Это OpenBSD.
А некоторым просто всё равно: они отвергают патчи, направленные на усиление защиты, в угоду убогим наследственным интерфейсам, которыми из всей user base пользуются только полтора разработчика. Это линукс.
А некоторые в смешанном духе FreeBSD и OpenBSD увлекаются дроблением ядра на компоненты, не учитывая уязвимости системы выполнения в Си при моделировании угроз и не вырабатывая никаких целевых механизмов защиты. Это Genode.
> :) Так можно и до теорий заговоров договориться...
Да, можно. Это называется reductio ad absurdum - дешёвая и, в вашем случае, неумелая полемика.
> Да, лишний код, и это не смешно. Если я работаю с динамическими
> строками сразу возникают проблемы распределения памяти и сборки мусора, которые неизбежно
> порождают лишний код.Да, это не смешно. Это старая песня. На Си у вас память под строки святым духом выделяется и освобождается? Размеры буферов за вас Аллaх считает? И вызов функций (!) у вас каким-то чудом получается эффективнее "inline"-кода, встроенного в систему выполнения?
На сколько я знаю, идиоматические Си и C++ до производительности типобезопасных языков не дотягивают и прогрызают себе дорогу в том лишь ценой извращённых микрооптимизаций, зависящих от компилятора, а порой и от аппаратной платформы. У вас есть доказательства обратного? Какой-нибудь идиоматический код теста на C/C++, который рвёт всех в клочья на шутауте? Давайте посмотрим.
> Если в приложении этот код без проблем выполняет
> ран-тайм библиотека, то в ядре ОС управление этим кодом может статьКакая-какая библиотека? Впрочем, важно другое: очевидно, что вы не работали со строками в ядре и несёте чепуху "от балды". А вот я работал и "наработался": чем ещё характерен Си, так это тем, что создавая код для усиления защиты в одном месте, увеличиваешь риск создания уязвимости в другом месте. Спросите любителей писать безопасный код на Си - разработчиков OpenBSD. Они вам скажут то же самое.
> головной болью программиста и, в конечном счете, привести к ослаблению безопасности.
"Головной болью" - это вы так обозначили необходимость думать и понимать, что делаешь, и как оно работает? Вот где "головная боль" - так это в Си. А вы говорите так, как будто думать нужно только в типобезопасных языках. В которых, кстати, вами любимое (?) ручное управление памятью тоже есть или может быть реализовано.
>> возникают? Насколько легко идентифицировать и исправить? Давайте сравнивать с Си.
> Давайте. Давайте для начала приведем примеры ОС, которые могут делать хоть что-нибудь,
> кроме как "быть безопасными", а потом посмотрим насколько не соответствуют этому
> призрачному идеалу реально существующие ОС.Похоже, на заданные вопросы вы конкретно ответить не можете. Обероны - ОС, которые написаны не на Си и "могут делать хоть что-нибудь". Гуглите Bluebottle и Active Oberon.
> В Си спецификация очень проста - массив символов, заканчивающийся нулем. Все операции
А в Аде сложна? Обоснуйте, в чём сложность. "Скрыта от программиста" - не аргумент и даже не проблема. Ответы на все вопросы есть в спецификации на язык и документации к компиляторам. Плюс исходный код.
Вы разглагольствуете о непригодности типобезопасных языков для написания ядер ОС, а требования к языкам предъявляете на уровне быдлокодера - это ваше "скрыта от программиста".
> со строками самоочевидны. А вот что творит со строками Ада -
Самоочевидны - это не критерий, уж точно не при разработки ядра ОС. Да и самоочевидность эта заканчивается на теории и выливается в нескончаемые ошибки на практике.
> я не знаю. Да мне и не надо знать, если я
> пишу приложение. Но если это встроенная система, работающая на голом железе,
> то мне совсем не безразлично в какой момент компилятор захочет вызывать
> менеджер памяти или сборщик мусора.Да уж куда вам знать-то. Не знаете даже, что в Аде преобладает ручное, либо явно обусловленное управление памятью, и что поведение сборщика мусора можно контролировать явно.
Да и обероны существуют, вопреки вашей пустой схоластике. XOberon/2 и HeliOS - ОС реального времени с промышленным применением. И вот в них-то как раз сборка мусора преобладает. Факты - они упрямы.
> Если бы в С++ была приемлемая реализация строк, мы бы не наблюдали
> того зоопарка строковых библиотек, который поставляет со своими продуктами каждый разработчик
> компиляторов.В C++ хотя бы есть юзабельные альтернативы. Хотя бы. В "гибком" Си и того нет.
> Это какие ядра собираются разными версиями компиляторов? Примеры, пожалуйста.
Новые линукс-ядра старыми версиями GCC (2.x) либо не собираются, либо не работают. При том что GCC 2.95 до сих пор собирает, например, ядра OpenBSD для некоторых старых архитектур.
> Слабость вашей позиции в том, что вы воспринимаете безопасность кода как единственный
> критерий эффективности системы. Причем даже не безопасность вообще, а почему-то именноСлабость вашей позиции в том, что вы не вдумываетесь, не понимаете и не спрашиваете, чтобы уточнить позицию собеседника. И несёте чушь, которую даже опровергать не нужно - достаточно спросить с вас цитаты, где я якобы высказывал такое-то мнение.
Спрашиваю: где я говорил, что "безопасность кода" - это "единственный критерий эффективности системы"?
А смысл моей позиции в следующем: небезопасность кода обуславливает небезопасность системы. Всё. И для ясности: безопасность кода необходима, но не достаточна для обеспечения безопасности системы.
> типобезопасность! В этом есть некий солипсизм. Реальность же такова, что абсолютно
Ваше представление о реальности в части безопасности современных ОС общего назначения зациклилось где-то на середине 90-ых. Впрочем, вы не одиноки.
> безопасных систем не бывает, более того, в них нет необходимости! Сюрприз?
Действительно, сюрприз. Очередной виток спирали ваших глупых опровержений вашей же убогой интерпретации смысла моих слов.
> Обычно требуется некий компромисс между определенным уровнем безопасности, скорости,
> потреблением ресурсов и т.п. Как показывает практика, языки, предоставляющие программисту
> всю свободу и ответственность, здесь наиболее эффективны."Как показывает практика" - и где же она это показывает? Вот когда я говорю, что практика показывает, что нет сложных и безопасных систем, работающих на уровне абстракций C/C++ - практика это действительно показывает на примере истории уязвимостей любой из таких публично доступных систем.
А вы видите на практике только то, что видите, в силу своего ограниченного кругозора. С чем вы сравниваете системы, написанные на Си? И не смущает ли вас, что о системах на типобезопасных языках вы спрашиваете меня?
>> Подумать только, ТРИ типа!!!11 Наверное, они в ТРИ раза небезопаснее, чем в
>> Си!!!11
> Наверное указатели вообще не нужны для безопасного программирования! Наверное безопаснаяЛюбопытно было бы узнать: какая связь между указателями вообще и безопасным программированием? ;)
> программа не должна заботиться об адресации каких-то байтов, а оперировать абстрактными
Ясно. Об "умных" указателях вы тоже ничего не знаете.
> типами, максимально защищенными от "дурака"! Не это ли есть типобезопасность!
Типобезопасность бывает разной. И я об этом уже писал. И почему она не панацея - тоже писал, на примерах. Чукча не читатель?
> Ну и каковы же эти причины? "Ложь и самообман" разработчиков? :)
Причина в том, что существующие системы не настолько плохи, чтобы тратить ресурсы на замену их новыми.
> Замечу, что переход на личности начали именно вы.
Нет, переход на личности начали именно вы. Но, похоже, воспитание не позволяет вам видеть разницу между высказываниями в адрес мнений и в адрес собеседников.
>> Голословное утверждение. Давайте конкретно: какие ОС промышленного уровня, написанные
>> не на Си, оказались более безопасными и по каким критериям?
> В оберонах (семейство ОС) отсутствуют классы уязвимостей, свойственные системам на Си и
> обусловленные небезопасными типами в последнем. Вот вам критерий: нет переполнений буфера,
> ошибок в неконтролируемой арифметике указателей, утечек неинициализированных данных,
> мутабельных указателей на произвольные адреса и как следствие нет уязвимостей к
> выполнению произвольного кода через эксплуатацию ошибок перечисленных классов.Ну, понятно. Конкретных примеров "безопасных" ОС промышленного уровня, написанных не на Си у вас нет. Зато есть 5 экранов пространных рассуждений о том, насколько такие гипотетические ОС лучше существующих. Вы пытаетесь спорить против очевидных фактов, отстаивая какие-то собственные идеалы, плохо соотносящиеся с реальностью. Честно говоря, комментировать ваш поток сознания и даже читать его до конца у меня нет ни времени ни желания, уж извините. Всего наилучшего.
Я назвал конкретные примеры, вы их проигнорировали. И не в первый раз. Разговаривать действительно не о чем.
> Ну, понятно. Конкретных примеров "безопасных" ОС промышленного уровня, написанных не на
> Си у вас нет. Зато есть 5 экранов пространных рассуждений о
> том, насколько такие гипотетические ОС лучше существующих. Вы пытаетесь спорить против
> очевидных фактов, отстаивая какие-то собственные идеалы, плохо соотносящиеся с реальностью.
> Честно говоря, комментировать ваш поток сознания и даже читать его до
> конца у меня нет ни времени ни желания, уж извините. Всего
> наилучшего.слив, конечно же, давно защитан
Спецификация языка - они гибкие, но не обеспечивают надёжности ПО.
> Очередная априори дырявая поделка - на этот раз на C++Да ладно, автор этой системы в прошлом году докторскую писал по теме "Securing Graphical User Interface", вот тут посмотреть можно: http://os.inf.tu-dresden.de/papers_ps/feske-phd.pdf
Кроме того, их фирмочка, помимо прочего, для embedded систем GUI на ксилинках делает, вот тут: http://sourceforge.net/projects/genode-fx
Вобщем, сомневаюсь я как-то в _априори_ дырявости сего поделия. Опять же, никто не утверждает что оно должно везде вытеснить линух, но вот для на embedded может оказаться действительно лучше. Что твой QNX, только новый и открытый.
На когда голосование намечено?
Debian GNU/kGenode будет?
Три вещи:
1. Интегрирован Qt4/Webkit
2. Реально быстрая загрузка (на QEMU без поддержки kvm - а это самый тормознутый вариант - грузилось секунд 10)
3. В билд уже портирована туева хуча дров с линуха, а что не портировано (например, флэш) - грузится, причем довольно шустро, через тот же паравирт.Вывод: немножко допилить напильником и имеем убийцу ChromeOS.