Здравствуйте, dimon0981, Вы писали: D>ЭЭэээ... Простите, а как Ваша программа попадет на удаленный компьютер? А если даже и попадет кто ей передаст управление? Ошибки переполнения буфера как раз таки позволяют это сделать. Вот когда научитесь исполнять свой код на удаленном компе тогда и память кушайте и руткиты устанавливайте и все на что фантазии и прав хватит.
Практика показывает, что изолировать машину от внешнего кода можно только в тепличных условиях типа АЭС или МКС. Во всех остальных случаях даже ломать не надо — "сами все предложат и сами все дадут", (с) Булгаков.
Вспомните разговоры об изоляции приложений, которые ходили во времена разработки полуоси (и повторяемые для NT): "теперь вирус невозможен в принципе, потому что одно приложение не может добраться до другого приложения, аппаратная защита, бла-бла-бла"... И что мы имеем теперь? Количество вирусов для изолированной системы давно превысило оное для DOS. А все почему? Да потому, что слишком много общих ресурсов, доступ к которым контролируется со слишком грубой гранулярностью. Оказалось, что не вирусу не нужно гадить в память чужого приложения — достаточно порыться в реестре или на диске. У операционной системы нет возможности контролировать происходящее, потому как для нее все вызовы FileCreate совершенно равнозначны.
Основные пути проникновения вредоносного кода:
— программы, запускающие внешний код:
-- Мэйлеры и браузеры, рискующие делать глупости типа запуска превью для приехавших данных
-- средства автоматизации, исполняющие скрипты VBA
— дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер
— развод лохов на запуск аттачментов с вирусами
Что мы имеем? Безопасная ОС в принципе не даст использовать никакие дыры и исполнить код, если ты не собирался этого делать.
Все остальное можно контролировать при помощи CAS, хотя пока нет устоявшейся практики, говорить об этом рано. Дело в том, что люди — реальны, и им зачастую неудобны математически идеальные вещи. Вот вам пример: ни один браузер сейчас не даст джаваскрипту залить на сервер пачку файлов. Единственная дырдочка — это input type=file. Увы, он катастрофически неудобен для массовой заливки, к примеру, фотографий. Поэтому все российские центры цифровой фотопечати предлагают... Скачать и запустить exe, который это обходит. С этого момента безопасность исчезает, и начинается экстремальный секс. Потому что приходится верить, что этот центр не встроил спайвару в аплоадер, что это вообще сайт центра фотопечати, а не хакер в соседнем подъезде, окучивший ближайший DNS сервер, и т.п.
Ладно, изобретем мы CAS. Дальше что? Как мы будем ограничивать права этого выкачанного кода? Заставим пользователя выбирать файлы по одному, через все тот же Open Dialog? Получится та же неудобная хрень. Разрешим выбирать файлы пачкой? А вдруг он заодно потащит с собой мой файл от MS Money? Далее, надо ограничить выход в интернет. Куда? Жестко привязывать к адресу, откуда приехал код? Или дать пользователю возможность выбирать?
В итоге, есть риск, что пользователь, задолбанный вопросами типа "а можно открыть вот этот файл на чтение? А можно мне подключиться к такому-то серверу? А можно я теперь отправлю прочитанные данные на этот сервер?", просто поставит галку "отвали и больше не спрашивай". После чего безопасность вернется к уровню, близкому к эпохе DOS. См. тж. фильм "как украсть миллион" по поводу обхода совершенных техсредств защиты с помощью социальной инженерии.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Вариант # 3 — использовать классы для работы со строками, а не доисторические жутики вроде strxxx и scanf. Если же выбор только из "n" и не "n", то конечо "n". В VC последних версий вообще не "n" функции помечены как "запрещенные".
Copy a string. These functions are deprecated because more secure versions are available
Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.
- Ну и мудаки!
— Что значит "нуймудаки"? — неожиданно заинтересовался Чарли
— Идеалисты, романтики.
(С. Довлатов, "Невидимая газета")
VD>Неиспользовать классы строк — это глупость. Ну, да раз ни дотнет, ни классы, то пиши на Ди.
А может у него голый Си?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, WolfHound, Вы писали:
WH>На сколько мне извесно самые разрушительные черви ходит именно ерез дырки ОС. Так что верфифицировать нужно все что вобще возможно. Вобщем мое мнение чем меньше unsafe кода тем лучше.
Ну хорошо. Вот у нас все-все сэйфее некуда. Что я делаю — беру динамический конртейнер и начинаю память кушать тоннами, пока система не окажется в глубокой свопе. После некоторого количества прецедентов, они объявят существуюшие контейнеры опасными и запретят их. И предложат использовать новые, безопасные — с ограничением по памяти. Прежде, чем создать экземпляр контейнера, необходимо будет послать запрос специальной комиссии с подробным описанием задачи и желаемым максимальным размером контейнера. После одобрения комиссией, данный экземпляр контейнера разрешается к использованию (высылается UUID). Превышение допустимого объема данных трактуется как возможная попытка хакерской атаки, о чем немедленно сообщается комиссии по расследованию информационных преступлений.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
MS>>Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.
VD>Это очередная глупось которую я слышу на этом форуме. Ну, да не прывыкать. Это похоже стиль жизни... с граблями на перевес.
Понимаешь ли, дело совсем не в этом. Было бы понятно и вполне разумно, если бы они написали что-то типа
"Эти функции могут представлять потенциальную опасность и не рекомендуются к использованию в среде Windows. В случаях, когда Ваша программа не является многоплатформенной, настоятельно рекомендуется использовать следующие функции взамен: ..."
Но объявлять стандартные функции deprecated (какие бы они ни были) является самоуверенной наглостью — типа, нам стандарт не указ, мы его отменяем. В приличном обществе за такое — канделябром.
Пусть своим бездарям кумарам раджешам запрещают, а я уж сам решу что мне использовать, а что — нет.
В качестве самоиронии:
— Меня! Боевого муравья! Копытом в грудь! И кто?! — бычьё!!!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
WH>Ну черная коробка это вобще не ОС. Обероновци толкают голубую бутылку. Но она не выдерживает критики ни по безопасности(,) ни то масштибируемости.
WH>В тоже время анилиз сингулирити откровенно слабых мест в общей концепции не выявил.
Я вот всё сообразить пытаюсь: это так C# и .Net на орфографию влияют или что-то еще? Хотя, с другой стороны, AVK, вроде, вполне грамотно пишет... Я прошу понять меня правильно: я не столько к орфографии цепляюсь, сколько пытаюсь разобраться: откуда такая небрежность в выражении своих мыслей возникает?
Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, WolfHound, Вы писали:
MS>>Реальность, однако, всякой выдумки смешней. MS>>http://www.lenta.ru/news/2006/05/23/flexgo/ WH>Как я понимаю это что-то типа покупки компьютера в рассрочку. WH>Причем платить можно хоть сто лет. И никаких процентов, штрафов, пени итп... WH>Что в этом плохого?
Нет, мой наивный друг — так просто ничего не бывает. (Масяня)
..."оборудованы специальными микросхемами со встроенными функциями FlexGo". Вот в этом-то весь смысл "акции" и заключается — под видом благих намерений приручить население, чтобы потом была возможность держать своих пользователей на коротком поводке. Тебе нравится, когда тебя за хомячка держат? Мне — нет, даже если обеспечено сытое и комфортное сушествование.
MS>>Можно. Но толку-то? Если не обеспечивается соблюдение закона, то это фуфельный закон. WH>Это ты о чем?
О том, что нет ни малейшего смысла в том, что "можно задать". Вот ты устанавливаешь некую приблуду — и что, устанавливаешь ей лимит по памяти? Не верю! А приблуда оказывается вредной бомбой.
MS>>Только не надо говорить, что все это ерунда по сравнению с мировой революцией. Это очень не ерунда и примером тому — многомерные массивы. Замечательная штука! Просто мечта для ряда задач. И... совершенно бесполезная по причитне диких тормозов. WH>Это проблема конкретной реализации конкретной виртуальной машины. Это все можно оптимизировать.
Вот! Эти слова я слышу с навязчивой периодичностью. Пора сделать их пожизненным девизом и выбить на логотипе.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
WolfHound wrote: > C>То что у меня будет выскакивать красивый stacktrace вместо Access > Violation — меня не особо привлекает. > Проблема в том что AV может и не выскочить, а программа будет делать > что-то не то.
То же самое может замечательно и с .NET-программами случится.
Переписывать ВЕСЬ (причем абсолютно весь) софт ради крайне редких
случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое
надо.
> К томуже имея трассировку стека разработчики смогут быстрее исправить > ошибку. Болие того до пользователей дейдет гораздо меньше ошибок ибо они > будут отлавливаться на этапе тестирования.
Трассировка стека замечательно делается и без .NET, причем еще со времен
70-х годов (core dump'ы). На Винде есть: http://www.codeproject.com/debug/XCrashReportPt4.asp
> C>Мне нужен. Если кто-то не умеет нативный код использовать — его проблемы. > Например я умею писать нативный код. Но вот зачем его писать всеравно не > понимаю.
Тогда не трогайте тех, кто понимает.
> C>Подтверждает. Например, отсутствие .NET/Java программ на обычных > десктопах. > У меня таких программ не мало.
У меня тоже. Но вот совсем нет:
1. Мелких утиллит (типа MP3-плеера, IM, менеджера закачек). Так как
иначе памяти бы не осталось.
2. Крупных десктопных приложений.
3. Мелких утиллит командной строки.
> C>До варианта с указателями все равно как до Луны. Кстати, твой вариант > уже не пройдет — > Сколько заплатишь если я утрамбую эту программу в объем памяти близкий > С++ версии?
Не получится. Более сложно связанные структуры приходится держать в виде
объектов, и никак от этого не избавится.
> C>недавно пришлось примерно 100000 временных массивов создать Так что > потребуется уже два байта на индекс. > Опять плохо считаем... три...
Да, проглючил. Три байта — мы сейчас просто разделяем индекс на два
32-битных слова.
> C>Я предпочитаю использовать дополнительную память, чтобы приложения > работали быстрее (из-за большего кэша диска, например), а не для того, > чтобы их разработчикам было легче их писать. > Те предпочитаешь получать худший результат за большие деньги?
Нет. Я предпочитаю пользоваться КАЧЕСТВЕННЫМ продктом, а не результатом
того, что Гашиш Кумары смогли начать писать софт.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WolfHound, Вы писали:
WH>>Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и работает стабильно.
VD>Не, будет по другому. Появилось одно приложение, а конкуренты на С++ пытаются зарелизить свой багодром временами урывая минутку чтобы потрепаться о Ди в этом форуме.
Нет пока стороники C# тут рекламируют N (они бедняги на C# писать уже не хотят, а на N пока не могут) уже выходит второй релиз программы на C++
Здравствуйте, AlexLion, Вы писали:
AL>Внимание!!! Убедительная просьба дотнетчикам не предлагать дотнет. Это тема отдельного обсуждения. Так же убедительная просьба не предлагать использование классов типа CString или string. Все это я знаю, часть этого использую, но интересует именно данная ситуация.
Ну раз .NET не предлагать предложу Java.
Шутка.
А если серьезно то вариант номер 2 однозначно. Иначе в лучшем случае заколебешься ловить плавающею ошибку высшего порядка. В худшем злой хакер взломает программу и утащит что-нибудь ценное.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexLion, Вы писали:
AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов: AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается
AL>Вопрос в том — какой бы вы вариант выбрали ( используете ) и почему.
А чего тут думать? Если нет опасности переполнения буфера (например, все аргументы — целочисленные значения с ограниченным диапазоном), то можно и strcpy. Если же есть хоть малейшая опасность затирания стэка, то длину конечно же надо контролировать. Иначе будешь сам себе злобным партизаном.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
PD>Теоретически почти все небезопасно.
PD>Выделение памяти по new или malloc — безопасно ? Нет, памяти может не хватить. Ну и что, каждый вызов будете окружать catch или __except ? В программе, которая суммарно выделяет не более 1 Мб ? На том основании, что когда-то может понадобиться 100 Мб ?
Нет, каждый вызов окружать не буду. Но буду писать так, чтобы вылетевший откуда угодно bad_alloc смог обработаться и при этом все созданные обьекты остались живы. Exception safe не значит что каждая строчка обёрнута try-catch, это заблуждение.
PD>Создание объектов GDI/USER небезопасно — лимит на 10000 на процесс. Будете проверять каждый вызов CreatePen ?
Если отрисовка критически важна в этой программе — то да, буду. Заверну в обёртку и буду кидать exception если что-то обломалось.
PD>И т.д.
PD>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где можно использовать небезопасные конструкции, а где нет.
ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где нужно использовать небезопасные конструкции, а где нет.
Здравствуйте, AlexLion, Вы писали:
AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов: AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается
AL>Вопрос в том — какой бы вы вариант выбрали ( используете )
Безопасные варианты ровно до тех пор пока это не станет проблемой.
AL> и почему.
Потому что premature optimization is the root of all evil
Потому что 80% времени занимает исполнение 20% кода. Если вдруг окажется, что эта функция вызывается тысячу раз в секунду и является узким местом в программе, тогда и перепишешь её, чтоб работала побыстрее. Забегая вперёд, скажу, что эта ситуация очень маловероятна. Судя по названию функций, InvokeQuery будет требовать в разы больше времени.
Если же оптимизировать сразу, получишь мизерный выигрыш в производительности ценой ухудшения надёжности. И речь даже не столько о надёжности кода для тебя, сколько для того, кто будет его можифицировать в будущем.
VladD2 wrote: >> >> > 1. Haskell статически типизированный язык. >> > C>Он ленивый. В этом и проблема. >> > В этом никакой проблемы нет. > C>Есть. В машкоде можно использовать thunk'и > Пример загадочной команды thunk из х86-го процессора в студию, плиз.
thunk — это не команда, а ассемблерный трюк. Он заключается в том, что
вместо указателя на целевую функцию используется указатель на
динамически сгенерированный блок кода.
Этот блок кода может использоваться для разных целей:
1. Например, в ATL он используется для обхода ограничений WinAPI
(невозможность передачи контекста в оконную функцию).
2. В Win9x thunk'и использовались для прозрачных вызовов 32-битных
библиотек из 16-битного кода.
3. В ленивых языках thunk'и могут использоваться для оптимизации ленивых
вызовов и интероперирования.
> C>для реализации отложенных > C>вычислений, а в CLR приходится использовать обычные if'ы. > Скажу тебе по сигрету... ни в х86-ом ассемблере, ни в МСИЛ-е нет никаких > ифов.
Я имею примерно такой код:
struct list {
val_type evaluate_list()
{
if (has_value())
return value();
calculate();
return value();
}
};
Можно значительно оптимизировать, если на разных этапах жизни функция
evaluate_list будет иметь разное содержание (особенно учитывая, что if
срабатывает только один раз за все время жизни ленивого значения).
> C>Разница в скорости в разы. > Тесты в студию, плиз, с выкладками и доказательствами корректности.
Лень
Здравствуйте, McSeem2, Вы писали:
MS>Ну хорошо. Вот у нас все-все сэйфее некуда. Что я делаю — беру динамический конртейнер и начинаю память кушать тоннами, пока система не окажется в глубокой свопе. После некоторого количества прецедентов, они объявят существуюшие контейнеры опасными и запретят их. И предложат использовать новые, безопасные — с ограничением по памяти. Прежде, чем создать экземпляр контейнера, необходимо будет послать запрос специальной комиссии с подробным описанием задачи и желаемым максимальным размером контейнера. После одобрения комиссией, данный экземпляр контейнера разрешается к использованию (высылается UUID). Превышение допустимого объема данных трактуется как возможная попытка хакерской атаки, о чем немедленно сообщается комиссии по расследованию информационных преступлений.
Доведение слов до абсурда -> демагогия.
В нормальных ОС можно задавать ограничения на колличество выделяемой памяти процессом.
По существу есть что сказать? Или не нравится мне то что нельзя память испортить и точка?
К тому же из-за нативности ОС и программного обеспечения страдает развитие железа... например сейчас отказатся от уродливой x86'ой архитектуры просто невозможно ибо перестанет работать весь софт. Еслибы все было управляемым то таких проблем бы небыло. Перенос ОС и всего софта включая драйверы под новый процессор осуществлялся бы переписыванием небольшой части ядра и кодогенератора. А это вполне реальный объем работы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > А как виртуальныя машина отменяет разнообразие языков? Единственное что > правильная ВМ отменяет всякие низкоуровневые языки которые не > контролируют то что делает программист. Но вот нужны ли такие языки?
Нужны.
Будущее за ОС с нестандартными архитектурами — микроядерными ОС,
например. К примеру, ядра QNX'ов предидущих версий — примерно 12Кб кода
на различных ассемблерах (под кучу платформ).
Только этот код исполняется в режиме ядра, остальной код работает в
контексте пользователя, так что система выживает даже если упадет
железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non
Stop). Так что managed OS нафиг не нужна.
В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз
ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM
больше напоминает классические процессорные команды и не является
"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за
пределы логического раздела). Работает все это очень медленно.
Здравствуйте, dimon0981, Вы писали:
D>Винда здесь не причем, это проблема любой системы. Использование функций типа strcpy и sprintf (т.е. без n) может привести к переполнению буфера. D>Большенство атак ниспользуют именно эту уязвимость. Проблемы переполнения буфера не решена ни в одной системе и в общем случае их врят ли можно решить. Частично FreeBSD с этим борится рандомизацией стека, но это далеко не всегда помогает.
Можно. Только ОС должна быть управляемая. Например Singularity очень близка к идеалу. Там таких ошибок быть не может по тому что их не может быть в принципе. Ибо в это ОС большей части ядра и всем драйверам запрещено использовать неверфифицируемый код.
Те ошибка может быть только в маленькой части ядра или в кодогенераторе. И то и другое реально отладить ибо это относительно небольшой объем кода.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Можно. Только ОС должна быть управляемая. Например Singularity очень близка к идеалу. Там таких ошибок быть не может по тому что их не может быть в принципе. Ибо в это ОС большей части ядра и всем драйверам запрещено использовать неверфифицируемый код. WH>Те ошибка может быть только в маленькой части ядра или в кодогенераторе. И то и другое реально отладить ибо это относительно небольшой объем кода.
Да? А где эта ОС работает, где ее продают, а? Когда дойдет до практики, идеал может оказаться не столь уж и идеальным. Вот тут некоторые Blackbox хвалят, может он еще лучше?
Здравствуйте, Cyberax, Вы писали:
C>И? Мне текущие программы вполне нравятся.
А мне нет. C>То что у меня будет выскакивать красивый stacktrace вместо Access Violation — меня не особо привлекает.
Проблема в том что AV может и не выскочить, а программа будет делать что-то не то.
К томуже имея трассировку стека разработчики смогут быстрее исправить ошибку. Болие того до пользователей дейдет гораздо меньше ошибок ибо они будут отлавливаться на этапе тестирования.
C>Мне нужен. Если кто-то не умеет нативный код использовать — его проблемы.
Например я умею писать нативный код. Но вот зачем его писать всеравно не понимаю.
C>Подтверждает. Например, отсутствие .NET/Java программ на обычных десктопах.
У меня таких программ не мало.
C>До варианта с указателями все равно как до Луны. Кстати, твой вариант уже не пройдет —
Сколько заплатишь если я утрамбую эту программу в объем памяти близкий С++ версии? C>недавно пришлось примерно 100000 временных массивов создать Так что потребуется уже два байта на индекс.
Опять плохо считаем... три...
C>Я предпочитаю использовать дополнительную память, чтобы приложения работали быстрее (из-за большего кэша диска, например), а не для того, чтобы их разработчикам было легче их писать.
Те предпочитаешь получать худший результат за большие деньги?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Андрей Хропов wrote: > C>То же самое может замечательно и с .NET-программами случится. > В .NET ошибки обращения по неверному адресу и висящих указателей > исчезают как класс.
И что? Я не понимаю почему все должны от этого петь и танцевать.
Лично в моем проекте такие ошибки не создают ну абсолютно никаких проблем.
> От ошибок в логике никто не застрахован, но их труднее сделать и они > быстрее всплывают.
Вот как раз обращения по неверному адресу всплывают сразу при тестировании.
> C>Переписывать ВЕСЬ (причем *абсолютно весь*) софт ради крайне редких > C>случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое > C>надо. > А этого и не будет. > ИМХО Будет работать в своей виртуальной машине под управляемой ОС. > Как сейчас DOS и Win16 приложения.
При миграции DOS->Windows можно было использовать старый код без особых
проблем. В данном случае старый код придется переписать полностью весь.
> C>Трассировка стека замечательно делается и без .NET, причем еще со времен > C> 70-х годов (core dump'ы). > Core Dump, если я правильно понимаю, снимок памяти процесса в тот > момент, когда он упал. > Ковырять его — удовольствие, я думаю, много ниже среднего .
Ага. Ведь приходится запускать отладчик и открывать его. А потом в
отладчике смотреть на все эти stacktrace'ы для всех потоков, фреймы
функций, значения локальных переменных.
> C> На Винде есть: > C>http://www.codeproject.com/debug/XCrashReportPt4.asp > Ага, если сам стек не запорчен, что сделать проще простого:
А это находится при первом тестировании с включеной проверкой стека. Или
с включеным Rational Purify.
> Адрес возврата запорчен и переход происходит непонятно куда > (точнее внизу видно, что на 0x0000024 ), > а так этим и злоумышленники пользуются.
И это элементарно отслеживается кучей тулзов.
> Это здесь ошибку просто найти, а если между объявлением массива и его > использованием много кода?
Берется Purify или Valgring (намного лучше, но не работае на Винде) и
находится за минуту.
Вдобавок, Valgrind еще умеет и места race condition'ов находить в
многопоточных программах.
> C>2. Крупных десктопных приложений. > В Visual Studio 2005 много .NET кода (7,5M LOC): > здесь <http://weblogs.asp.net/JackieG/archive/2006/03/17/440456.aspx>.
Ну не являются средства разработки приложениями для обычных конечных
пользователей.
Здравствуйте, AlexLion, Вы писали:
AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов: AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается
AL>Вопрос в том — какой бы вы вариант выбрали ( используете ) и почему.
Теоретически почти все небезопасно.
Выделение памяти по new или malloc — безопасно ? Нет, памяти может не хватить. Ну и что, каждый вызов будете окружать catch или __except ? В программе, которая суммарно выделяет не более 1 Мб ? На том основании, что когда-то может понадобиться 100 Мб ?
Создание объектов GDI/USER небезопасно — лимит на 10000 на процесс. Будете проверять каждый вызов CreatePen ?
И т.д.
ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где можно использовать небезопасные конструкции, а где нет.
L>>Нет, каждый вызов окружать не буду. Но буду писать так, чтобы вылетевший откуда угодно bad_alloc смог обработаться и при этом все созданные обьекты остались живы. Exception safe не значит что каждая строчка обёрнута try-catch, это заблуждение.
PD>Последнее, конечно, верно, а первое — как сказать. Обычно память выделяют, чтобы тут же использовать.. Так что проверять именно там скорее всего и придется.
Не прийдётся тут же. Поскольку если память не выделится — то вылетит исключение, и дальше этот кусок исполняться не будет. Сорри что рассказываю тривиальные вещи.
PD>А если дурной программист сюда вместо указателя LOGPEN передал бог знает что ? Для надежности здесь даже IsBadWritePtr мало будет. Да и вообще неясно, как это написать безопасно — он ведь мог и указатель на int передать и мы прямым ходом испортим память , быть может, даже без всякого AV.
Что значит Бог знает что? А type safety зачем? Смысл использования только safe конструкций как раз и сводится к тому чтобы подобных конструкций не допускать. Кстати, насчёт IsBadWritePtr — тоже плохая идея ИМХО, нужно проверять на NULL/не NULL, а передачи dangled pointers и т.п. надо избегать другими способами.
PD>>>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где можно использовать небезопасные конструкции, а где нет.
L>>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где нужно использовать небезопасные конструкции, а где нет.
PD>Хм... ИМХО все же "можно" вернее. Говоря "можно", я имею в виду, что ситуация, в общем-то, на 99.99% под контролем в плане уверенности , что здесь можно использовать небезопасный код без серьезных проблем. PD>А нужно его здесь использовать или нет — это уже другой вопрос. Если можно — не значит обязательно нужно. Но если "не можно" — то лучше не надо, даже если нужно
Нет, Павел — я всё же не согласен. Потому что код имеет обыкновение меняться. И сегодня для strcpy памяти хватало с запасом, а завтра кто-то удлиннил строчку не посмотрев (ну ладно — пусть посмотрев, но не досмотрев до конца) на дела рук своих. А падать всё начало только после-после-послезавтра. Причём как обычно — в день релиза, как обычно после 2-х часов работы и как обычно всегда в разных местах. Ну и спрашивается — стоят ли те такты которые выиграны по сравнению с strncpy тех выпавших, поседевших и вырванных с корнями волос которые потрачены на отладку? Я ещё понимаю McSeem2 — он пишет библиотеку, которая рендерит векторную графику. У него действительно каждый такт на счету. Но во-1 — даже в таких библиотеках мест в которых нужно так сильно экономить — не так уж и много. И во-2 — таких задач как у него ну просто мизерный процент по отношению ко всем задачам которые решаются на C/C++.
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >> C>То же самое может замечательно и с .NET-программами случится. >> В .NET ошибки обращения по неверному адресу и висящих указателей >> исчезают как класс. C>И что? Я не понимаю почему все должны от этого петь и танцевать.
Ты любишь глючные программы?
Ты любишь тратить дополнительное время на отладку?
Ок, ты гуру, и у тебя таких проблем нет,
но это не значит что их не внесет при сопровождении другой человек.
+
не приходится дополнительно думать и писать логику ручного управления памятью,
что порождает более короткий и простой код.
C>Лично в моем проекте такие ошибки не создают ну абсолютно никаких проблем.
Ну и хорошо. Рад лично за тебя.
>> От ошибок в логике никто не застрахован, но их труднее сделать и они >> быстрее всплывают. C>Вот как раз обращения по неверному адресу всплывают сразу при тестировании.
Это если они простые. Если логика сложная (куча объектов, многопоточность),
то не сразу понятно есть ли там текущая память, это может и не сразу проявиться.
>> ИМХО Будет работать в своей виртуальной машине под управляемой ОС. >> Как сейчас DOS и Win16 приложения. C>При миграции DOS->Windows можно было использовать старый код без особых C>проблем. В данном случае старый код придется переписать полностью весь.
Ты недооцениваешь развитие систем виртуализации.
Тот же DOS Extended mode ведь эмулируется?
>> C>Трассировка стека замечательно делается и без .NET, причем еще со времен >> C> 70-х годов (core dump'ы). >> Core Dump, если я правильно понимаю, снимок памяти процесса в тот >> момент, когда он упал. >> Ковырять его — удовольствие, я думаю, много ниже среднего . C>Ага. Ведь приходится запускать отладчик и открывать его. А потом в C>отладчике смотреть на все эти stacktrace'ы для всех потоков, фреймы C>функций, значения локальных переменных.
Это если отладочная информация есть
+ прежде чем программа упадет она может так в памяти накосячить
что потом попробуй восстанови последовательность событий.
>> C> На Винде есть: >> C>http://www.codeproject.com/debug/XCrashReportPt4.asp >> Ага, если сам стек не запорчен, что сделать проще простого: C>А это находится при первом тестировании с включеной проверкой стека. Или C>с включеным Rational Purify.
А если выскочило после тестирования (без проверки стека)?
>> Адрес возврата запорчен и переход происходит непонятно куда >> (точнее внизу видно, что на 0x0000024 ), >> а так этим и злоумышленники пользуются. C>И это элементарно отслеживается кучей тулзов.
>> Это здесь ошибку просто найти, а если между объявлением массива и его >> использованием много кода? C>Берется Purify или Valgring (намного лучше, но не работае на Винде) и C>находится за минуту.
C>Вдобавок, Valgrind еще умеет и места race condition'ов находить в C>многопоточных программах.
Да здорово, я не спорю.
Сам использую подобные инструменты.
Но дело в том, что все это используется во время отладки, а потом всего этого нет.
Бывает, что и в Debug и Release работает по-разному один и тот же код.
Если бы все было так неплохо, так Microsoft бы пачками патчи не выпускал.
>> C>2. Крупных десктопных приложений. >> В Visual Studio 2005 много .NET кода (7,5M LOC): >> здесь <http://weblogs.asp.net/JackieG/archive/2006/03/17/440456.aspx>. C>Ну не являются средства разработки приложениями для обычных конечных C>пользователей.
Так тут были слова "крупный десктопный".
Здравствуйте, klapaucius, Вы писали:
C>>Не байт-код, а настоящий машинный код (см. мое сообщение про thunk'и).
K>Все ясно. Тут уж действительно, чего нет — того нет.
Да тоже есть при желании. К примеру, можно поглядеть на transparent proxy/real proxy. Обращать внирмание на stub. Только смысла в этом никакого. Генерация кода при помощи JIT на голову удобнее, надежнее и проще.
Здравствуйте, WolfHound, Вы писали:
ГВ>>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM? WH>Сделать Java под .NET не проблема. Сделать C# под JVM труднее но тоже можно ибо JVM беднее CLR. Хотя смысла в этом нет никакого. WH>Но если сделать довольно богатую ВМ то под нее можно будет легко портировать почти любой язык. С осталными придется повозится но тоже можно. Вопрос в том нужно ли.
Более того, не только не нужно, но скорее всего, и Sun, и Microsoft будут этому сильно сопротивляться. Вывод?
<< Под музыку: Аквариум — О смысле всего сущего >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Copy a string. These functions are deprecated because more secure versions are available
> > Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.
Здравствуйте, AlexLion, Вы писали:
AL>Всем привет!
AL>Ситуация тривиальная — есть наша функция, скажем BuildAndInvokeQuery. Эта функция принимает некоторое кол-во параметров и формирует из них строку, которотую отдает другой функции, скажем InvokeQuery. AL>Т.е все происходит где-то так:
AL>
AL>int BuildAndInvokeQuery( ... )
AL>{
#define XXX 1234 /*если C */const std::size_t XXX=1234; //если C++
AL> char szQueryParam[ ХХХ ] = {0};
AL> // здесь идет формирование szQueryParam
/*strnxxx rulez!!!*/
szQueryParam[XXX-1] = 0; /*strnxxx имеют гадкую привычу
//не терминатить строку если упираются в границу */
AL> return InvokeQuery( szQueryParam );
#undef XXX /*если C */
AL>}
AL>
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, AlexLion, Вы писали:
AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов: AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается
AL>Вопрос в том — какой бы вы вариант выбрали ( используете ) и почему.
Всё зависит от конкретных условий. В одних случаях можно безопасно пользоваться strcpy и иже с ними, в других — нельзя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Вариант # 3 — использовать классы для работы со строками, а не доисторические жутики вроде strxxx и scanf. Если же выбор только из "n" и не "n", то конечо "n". В VC последних версий вообще не "n" функции помечены как "запрещенные".
AL>Внимание!!! Убедительная просьба дотнетчикам не предлагать дотнет. Это тема отдельного обсуждения. Так же убедительная просьба не предлагать использование классов типа CString или string. Все это я знаю, часть этого использую, но интересует именно данная ситуация.
Неиспользовать классы строк — это глупость. Ну, да раз ни дотнет, ни классы, то пиши на Ди.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.
Это не безопасность виндов. Это безопасность самой программы. К безопасности самой Windows — это имеет мало отношений.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, VladD2, Вы писали:
VD>>Вариант # 3 — использовать классы для работы со строками, а не доисторические жутики вроде strxxx и scanf. Если же выбор только из "n" и не "n", то конечо "n". В VC последних версий вообще не "n" функции помечены как "запрещенные".
MS>Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.
Винда здесь не причем, это проблема любой системы. Использование функций типа strcpy и sprintf (т.е. без n) может привести к переполнению буфера.
Большенство атак ниспользуют именно эту уязвимость. Проблемы переполнения буфера не решена ни в одной системе и в общем случае их врят ли можно решить. Частично FreeBSD с этим борится рандомизацией стека, но это далеко не всегда помогает.
VD>>Неиспользовать классы строк — это глупость. Ну, да раз ни дотнет, ни классы, то пиши на Ди.
MS>А может у него голый Си?
Здравствуйте, GlebZ, Вы писали:
GZ>Проблема, насколько я понимаю, не в коде операционки. Проблема в коде клиентов. Если разрешен неверифицируемый код в клиенте, то safe или unsafe ядро — проблема есть. Если запрещен, то независимо от того, какая операционка, и насколько она сингулярна — проблемы нет.
На сколько мне извесно самые разрушительные черви ходит именно ерез дырки ОС. Так что верфифицировать нужно все что вобще возможно. Вобщем мое мнение чем меньше unsafe кода тем лучше.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
ГВ>>А фреймворки?
VD>25!
33!
<< Под музыку: Аквариум — Ткачиха >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>Нужны.
Нет.
C>Будущее за ОС с нестандартными архитектурами — микроядерными ОС, C>например. К примеру, ядра QNX'ов предидущих версий — примерно 12Кб кода C>на различных ассемблерах (под кучу платформ).
Управляемые ОС микро ядро какбы не отрицают, а скорее наоборот.
C>Только этот код исполняется в режиме ядра, остальной код работает в C>контексте пользователя, так что система выживает даже если упадет C>железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non C>Stop). Так что managed OS нафиг не нужна.
Угу а приложение от самого себя кто защищать будет? Как ты думаешь почему так популярны всякие жабы и дотнеты?
C>В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз C>ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM C>больше напоминает классические процессорные команды и не является C>"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за C>пределы логического раздела). Работает все это очень медленно.
Значит они сделали что-то не так. Посмотри на отчет о сингулярити она работает плюс/минус с тойже скоростью что современные винда и линух. И это при том что сингулярити практически не оптимизировали.
Кроче проблемы со скоростью это то во что тебе хочется верить. Реально будет скорре наоборот.
Вобщем мы это все уже обсудили. Единственный минус что ты нашол это потеря 30% в очень специфических случаях из-за несовершенства современных оптимизаторов.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, GlebZ, Вы писали:
GZ>Червяки можно разделить на две категории. Первые — внедряются с внешней стороны, вторые — выполняются внутри системы, но проводят действия на которые он не имеет прав. Для второго случая, важен обход апаратной защиты адресации памяти(что обычно делается с помощью дырок в OS). В случае с сингуларити — все несколько проще в смысле аппаратной защиты. Unsafe программа может легко работать в адресах на которые у него прав нет. Safe программа — нет.
В том то и прикол что в сингулярити все включая драйверы safe. Так что червям развернутся просто негде.
А внедриться в unsafe часть ядра практически не реально.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> C>То что у меня будет выскакивать красивый stacktrace вместо Access >> Violation — меня не особо привлекает. >> Проблема в том что AV может и не выскочить, а программа будет делать >> что-то не то. C>То же самое может замечательно и с .NET-программами случится.
В .NET ошибки обращения по неверному адресу и висящих указателей исчезают как класс.
От ошибок в логике никто не застрахован, но их труднее сделать и они быстрее всплывают.
C>Переписывать ВЕСЬ (причем абсолютно весь) софт ради крайне редких C>случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое C>надо.
А этого и не будет.
ИМХО Будет работать в своей виртуальной машине под управляемой ОС.
Как сейчас DOS и Win16 приложения.
>> К томуже имея трассировку стека разработчики смогут быстрее исправить >> ошибку. Болие того до пользователей дейдет гораздо меньше ошибок ибо они >> будут отлавливаться на этапе тестирования. C>Трассировка стека замечательно делается и без .NET, причем еще со времен C> 70-х годов (core dump'ы).
Core Dump, если я правильно понимаю, снимок памяти процесса в тот момент, когда он упал.
Ковырять его — удовольствие, я думаю, много ниже среднего .
C> На Винде есть: C>http://www.codeproject.com/debug/XCrashReportPt4.asp
Ага, если сам стек не запорчен, что сделать проще простого:
#include <stdio.h>
void func()
{
int num[5];
for(int i = 0; i < 10; ++i )
{
num[i] = i*i;
printf("num %i %i\n",i,num[i]); // включил, чтобы компилятор не поскипал неисп код.
}
}
int main()
{
func();
return 0;
}
Адрес возврата запорчен и переход происходит непонятно куда
(точнее внизу видно, что на 0x0000024 ),
а так этим и злоумышленники пользуются.
Программа была скомпилирована с отладочной информацией в VS8.
Вот что показал отладчик в call stack после того как программа упала:
> 00000024()
kernel32.dll!7c816d4f()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
kernel32.dll!7c8399f3()
Это здесь ошибку просто найти, а если между объявлением массива и его использованием много кода?
>> C>Подтверждает. Например, отсутствие .NET/Java программ на обычных >> десктопах.
C>2. Крупных десктопных приложений.
В Visual Studio 2005 много .NET кода (7,5M LOC): здесь.
Андрей Хропов wrote: >> > А как виртуальныя машина отменяет разнообразие языков? Единственное что >> > правильная ВМ отменяет всякие низкоуровневые языки которые не >> > контролируют то что делает программист. Но вот нужны ли такие языки? > C>Нужны. > Но для небольшого числа применений (в ядре ОС и драйверах).
А так же в:
1. Desktop-приложениях (оффисы, браузеры и т.п.)
2. Требовательных приложениях (CAD-системы, графические редакторы и т.п.)
3. Мелких утиллитах.
> C>В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз > C>ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM > C>больше напоминает классические процессорные команды и не является > C>"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за > C>пределы логического раздела). Работает все это очень медленно. > Так там наверное интерпретация, а не JIT.
Нет, там JIT. Иначе оно бы совсем не жило.
> В Java и .NET перешли на JIT модель.
В Java — уже на HotSpot.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, Cyberax, Вы писали:
C>>Kluev wrote: >>> C>Сингулярити не позволяет НАПРЯМУЮ использовать: >>> C>1. Машинный код и языки компилирующие в него. >>> C>2. Ручное управление памятью. >>> C>3. Виртуальную память (хотя, возможно, и добавят). >>> А файлы она в память умеет отображать? C>>Нет, так как защиты памяти там нет (все в нулевом кольце сидит и C>>работает с физическими адресами).
В догонку к предыдущему сообщению.
Такая поделка будет работать если все обьекты имеют размер не более 1 страницы памяти (4-8к). В противном случае кода все зафрагментируется, получится так что памяти полно, а выделить большой кусок нельзя. Ну и кому нужно такое счастье?
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, Cyberax, Вы писали:
C>>Kluev wrote: >>> C>Сингулярити не позволяет НАПРЯМУЮ использовать: >>> C>1. Машинный код и языки компилирующие в него. >>> C>2. Ручное управление памятью. >>> C>3. Виртуальную память (хотя, возможно, и добавят). >>> А файлы она в память умеет отображать? C>>Нет, так как защиты памяти там нет (все в нулевом кольце сидит и C>>работает с физическими адресами).
Еще раз в догонку.
Имхо, разделение системы на юзер-спейс и кернел-спейс, где каждый процесс получает свои законные 2 Гига (или другой обьем в зависимотси от архитектуры) является самым оптимальным решением. Все остальные поделки без виртуальной памяти нежизнеспособны или применимы в ограниченных условиях. Т.е. такие оси не универсальные. Имхо, в МС просто изобрели велосипед 40 летней девности для поездки по старым граблям.
WolfHound wrote: > В любом случае ты не понял главного: Такие ОС нужны для обеспечение > стабильной работы системы, а не для того чтобы небыло переключения > контекстов.
ОС со стабильной работой даже в присутствие _аппаратных_ сбоев уже лет
30 существуют.
Защита достигается разделением и максимальной изоляцией всего, что
только разделяется и изолируется. В качестве примера я уже приводил QNX
— его используют на ядерных электростанциях, а его ядро представляет из
себя небольшой кусок кода.
Так что проблема надежности уже давно решена. Остается проблема скорости
— в этом направлении сейчас тоже активно копают, можно почитать ответы
Таненбаума Линусу. Возможно, скоро Mac OS X станет первой
consumer-версией ОС с микроядром.
Здравствуйте, FR, Вы писали:
FR>>>и их (не)желания переучиватся. WH>>Вот те которые не желают переучитваться (не буду показывать пальцем но тут таких много) и тормозят процесс...
FR>Какой процесс?
Да нет никакого процесса, мы все здесь силно заняты, однако заняты ничем. В суете бесконечной увязнув, что затихнет лишь с гибелью мира... (Бхагават Гита)
З.Ы. Сколько раз я не пытался завязать с программированием и просто спокойно кодировать, ничего не выходило остается надеятся, что со временему уму это надоест и все само собой отвалится.
Андрей Хропов wrote: > Можно как в C# сделать safe/unsafe mode, если люди захотят.
Ты не понял. Singularity ВООБЩЕ запрещает unsafe. В любом его виде.
> C>Ну и как часто это надо? Я в своей практике не помню ни разу, когда > C>такое понадобилось. > Тем не менее, встроенный компилятор под рукой — удобно.
Boost.Python, и ващи волосы будут мягкими и щелковистыми.
> C>Сингулярити не позволяет НАПРЯМУЮ использовать: > C>1. Машинный код и языки компилирующие в него. > Много языков уже перевели на .NET.
И все они изоморфны C# или сделаны через полную Ж.
> C>2. Ручное управление памятью. > В некоторых случаях это действительно недостаток, > но в любом случае Singularity — это только прототип.
В fully managed OS типа Singularity в принципе не может быть unsafe.
Kluev,
FR>>Какой процесс?
K>Да нет никакого процесса, мы все здесь силно заняты, однако заняты ничем. K>В суете бесконечной увязнув, что затихнет лишь с гибелью мира... (Бхагават Гита)
K>З.Ы. Сколько раз я не пытался завязать с программированием и просто спокойно кодировать, ничего не выходило остается надеятся, что со временему уму это надоест и все само собой отвалится.
Нет, не получится. Проекты не делаются в пол накала — ты либо зажигаешься и зажигаешь остальных, либо ничего не можешь сделать. Это фундаментальное свойство разума.
Другое дело, что можно научиться управлять своим огнём, и тут нужен качественный шаг, а не ещё один ЯП/ОС...
Здравствуйте, WolfHound, Вы писали:
WH>>>И что и куда подгрузил червь? D>>В первом запросе свою небольшую часть. А после передачи ей управления подгрузил остальную. Они все так делают. WH>Еще раз как в управляемой ОС где теоритически не может быть всяких там переполнений буфера этот код получит управление?
Убедил. Давай сюда эту самую управляемую ОС — Singularity . Где ее можно скачать/купить? Надеюсь она обеспечит мне и пользователям моего софта чувство защищенности и массу других обещаемых "вкусностей".
И AlexLion-у, затеявшему эту беседу, тоже посоветуем ею пользоватся вместо strcat-ов и sprintf-ов старых. Убережем его от убогих систем и языков.
Ну... Где ее можно скачать?
Здравствуйте, dimon0981, Вы писали:
D>Убедил. Давай сюда эту самую управляемую ОС — Singularity . Где ее можно скачать/купить? Надеюсь она обеспечит мне и пользователям моего софта чувство защищенности и массу других обещаемых "вкусностей". D>И AlexLion-у, затеявшему эту беседу, тоже посоветуем ею пользоватся вместо strcat-ов и sprintf-ов старых. Убережем его от убогих систем и языков. D>Ну... Где ее можно скачать?
Напиши в Microsoft Research может быть дадут.
И главное учти что у нас тут философия программирования и обсуждаются тут не только и не столько текущее положение дел сколько то куда мы катимся и куда нам катится нужно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, dimon0981, Вы писали:
D>>Убедил. Давай сюда эту самую управляемую ОС — Singularity . Где ее можно скачать/купить? Надеюсь она обеспечит мне и пользователям моего софта чувство защищенности и массу других обещаемых "вкусностей". D>>И AlexLion-у, затеявшему эту беседу, тоже посоветуем ею пользоватся вместо strcat-ов и sprintf-ов старых. Убережем его от убогих систем и языков. D>>Ну... Где ее можно скачать?
WH>Напиши в Microsoft Research может быть дадут.
Здравствуйте, McSeem2, Вы писали:
MS>Пусть своим бездарям кумарам раджешам запрещают, а я уж сам решу что мне использовать, а что — нет.
Самые лучшие программисты — это те, кто осознают ограниченность своих возможностей. В то же время худшие программисты твердо убеждены в своей непогрешимости и безошибочности. (C)
Не вижу смысла в таком тесте. Здесь используется одна и та же строка — да, она тут же легла в кеш и процессор перемалывает одни и те же данные — понятное дело что при таком раскладе каждый такт на счету (мы даже в память не лазим, всё из кеша, причём кеша первого уровня!). В более-менее реальных приложениях выигрыш от strcpy будет минимальным.
VladD2 wrote: > Гулупость полнейшая. > 1. Haskell статически типизированный язык.
Он ленивый. В этом и проблема.
> 2. С динамическими вызовами в дотнете не хуже чем в любом другом месте.
Сравним Python и IronPython?
Дарней wrote: > C>Лично в моем проекте такие ошибки не создают ну абсолютно никаких проблем. > И тебе — тоже цитата. > Самые лучшие программисты — это те, кто осознают ограниченность своих > возможностей. В то же время худшие программисты твердо убеждены в своей > непогрешимости и безошибочности. (С)
А знаешь почему они не создают проблем? Потому что я пишу так, что эти
ошибки не могут появиться. Не доверяю я себе (так как каждый раз
когда я хочу поиграть с битами, то потом всплывает ошибка)
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >>> > 1. Haskell статически типизированный язык. >> C>Он ленивый. В этом и проблема. >> В этом никакой проблемы нет. C>Есть. В машкоде можно использовать thunk'и
Пример загадочной команды thunk из х86-го процессора в студию, плиз.
C>для реализации отложенных C>вычислений, а в CLR приходится использовать обычные if'ы.
Скажу тебе по сигрету... ни в х86-ом ассемблере, ни в МСИЛ-е нет никаких ифов.
C>Разница в скорости в разы.
Тесты в студию, плиз, с выкладками и доказательствами корректности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что часто такие битхаки дают мне очень неплохие C>преимущества в скорости.
Это илюзия. К тому же хаки можно делать и в управляемом мире. Ни ансэйф, ни интероп никто не отменял. Но я еще не разу не видел, чтобы в моей практике опасных хак дал больше чем, просто грамотная оптимизация алгоритмов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>ОС со стабильной работой даже в присутствие _аппаратных_ сбоев уже лет > C>30 существуют. > Ага. Эрланг называется. Причем пашет даже под Виндовс.
Эрланг — это скорее просто интерпретируемый язык.
> QNX не дает надежности. Это ведь ОС реального времени, а не безопасная > ОС. Любой кривой указатель введет из строя любое приложение QNX. В этом > отношении QNX ни чем не отличаетсяот Виндовс или Линукса.
Зато приложение ничего не сможет разрушить в своем окружении. По сути
это и важно — после обращения по нулевой ссылке .NET-приложение тоже
небезопасно использовать.
> Апаратная защита адрессного пространства процесса позволяет только лишь > упростить выявление ошибок в некоторых случаях.
А мягкая обработка исключений позволяет ошибки скрывать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>(Я не представляю себе требования к памяти Photoshop на .NET ).
AVK>http://www.eecs.wsu.edu/paint.net/
Ситуация тривиальная — есть наша функция, скажем BuildAndInvokeQuery. Эта функция принимает некоторое кол-во параметров и формирует из них строку, которотую отдает другой функции, скажем InvokeQuery.
Т.е все происходит где-то так:
int BuildAndInvokeQuery( ... )
{
char szQueryParam[ ХХХ ] = {0};
// здесь идет формирование szQueryParamreturn InvokeQuery( szQueryParam );
}
Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов:
1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается
2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается
Вопрос в том — какой бы вы вариант выбрали ( используете ) и почему.
Внимание!!! Убедительная просьба дотнетчикам не предлагать дотнет. Это тема отдельного обсуждения. Так же убедительная просьба не предлагать использование классов типа CString или string. Все это я знаю, часть этого использую, но интересует именно данная ситуация.
Здравствуйте, McSeem2, Вы писали:
MS>Это очередная параноя на почве дырявой безопасности в виндах. Эти наивные люди думают, что если запретить стандартную(!) функцию strcpy, то безопасность сразу повысится. Душит смех.
Это очередная глупось которую я слышу на этом форуме. Ну, да не прывыкать. Это похоже стиль жизни... с граблями на перевес.
MS>А может у него голый Си?
Ага. Он запросы (InvokeQuery) на С лепит. Это на С++ то полный идиотизм. А на С просто какая-то параноя. Неужели своего своего времени не залго? Думаю, очередная погоня за производительностью... экономяцая несколько микросекунд между полесекундными вызовами к БД.
Ну, и даже если код на С, то нет особых проблем сделать безопасный и удобный АПИ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вариант # 3 — использовать классы для работы со строками, а не доисторические жутики вроде strxxx и scanf. Если же выбор только из "n" и не "n", то конечо "n". В VC последних версий вообще не "n" функции помечены как "запрещенные".
Запрещённые или deprecated?
<< Под музыку: Аквариум — Стаканы >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AlexLion, Вы писали:
AL>Внимание!!! Убедительная просьба дотнетчикам не предлагать дотнет. Это тема отдельного обсуждения. Так же убедительная просьба не предлагать использование классов типа CString или string. Все это я знаю, часть этого использую, но интересует именно данная ситуация.
Это не отдельная тема. Это та же тема — использование строк. Поэтому в случае если нет противопоказаний, лучший вариант — std::string. В противном случае — уже по обстоятельствам. Можно легко определить и свой набор функций, удобных как и strcpy и в то же время безопасных.
Во-первых — довольно просто можно отключить declspec deprecated (если у тебя есть лазерный меч и сила на твоей стороне то джедаям закон не писан — твори что хочу, только не говори потом что тебя не предупреждали).
Ну а во-вторых — strncpy не менее стандартная чем strcpy. И очччень ненамного медленне работает. И в 99.99% случаев проще забыть о существовании strcpy. То же самое касается sprintf. Я уж не говорю о "взрослых" C++ строках типа std::string, CString и иже с ними.
Здравствуйте, AlexLion, Вы писали:
AL>Всем привет!
AL>Ситуация тривиальная — есть наша функция, скажем BuildAndInvokeQuery. Эта функция принимает некоторое кол-во параметров и формирует из них строку, которотую отдает другой функции, скажем InvokeQuery. AL>Т.е все происходит где-то так:
AL>
AL>int BuildAndInvokeQuery( ... )
AL>{
AL> char szQueryParam[ ХХХ ] = {0};
AL> // здесь идет формирование szQueryParam
AL> return InvokeQuery( szQueryParam );
AL>}
AL>
AL>Думаю сталкивались не раз. Что касается формирования szQueryParam — тут есть несколько вариантов: AL>1. Функции типа strcat, strcpy, sprintf и т.д. Т.е. размер буффера не учитывается AL>2. Функции типа strncat, strncpy, snprintf и т.д. Т.е. размер буффера уже учитывается
AL>Вопрос в том — какой бы вы вариант выбрали ( используете ) и почему.
Тебе нужен in memory stream.
Например, ostrstream.
char szQueryParam[ ХХХ ];
std::ostrstream out(szQueryParam,XXX);
out << "My cool string number " << i << ends ;
Здравствуйте, Quintanar, Вы писали:
Q>Да? А где эта ОС работает, где ее продают, а?
Пока это исследовательский проект. Но направление очень верное.
Q>Когда дойдет до практики, идеал может оказаться не столь уж и идеальным. Вот тут некоторые Blackbox хвалят, может он еще лучше?
Ну черная коробка это вобще не ОС. Обероновци толкают голубую бутылку. Но она не выдерживает критики ни по безопасности ни то масштибируемости.
В тоже время анилиз сингулирити откровенно слабых мест в общей концепции не выявил.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Можно. Только ОС должна быть управляемая. Например Singularity очень близка к идеалу. Там таких ошибок быть не может по тому что их не может быть в принципе. Ибо в это ОС большей части ядра и всем драйверам запрещено использовать неверфифицируемый код. WH>Те ошибка может быть только в маленькой части ядра или в кодогенераторе. И то и другое реально отладить ибо это относительно небольшой объем кода.
Проблема, насколько я понимаю, не в коде операционки. Проблема в коде клиентов. Если разрешен неверифицируемый код в клиенте, то safe или unsafe ядро — проблема есть. Если запрещен, то независимо от того, какая операционка, и насколько она сингулярна — проблемы нет.
Здравствуйте, WolfHound, Вы писали:
WH>К тому же из-за нативности ОС и программного обеспечения страдает развитие железа... например сейчас отказатся от уродливой x86'ой архитектуры просто невозможно ибо перестанет работать весь софт. Еслибы все было управляемым то таких проблем бы небыло. Перенос ОС и всего софта включая драйверы под новый процессор осуществлялся бы переписыванием небольшой части ядра и кодогенератора. А это вполне реальный объем работы.
А могло бы быть ещё проще, будь всё написано на одном-единственном языке. Осталось найти тот самый эсперанто.
<< Под музыку: Аквариум — Тяжелый Рок >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
Q>>Да? А где эта ОС работает, где ее продают, а? WH>Пока это исследовательский проект. Но направление очень верное.
Возможно. Раньше прослойки представлялись примерно так:
Язык высокого уровня n->m железо.
Сейчас, значится, будет так:
Язык высокого уровня n->1? прослойка 1?->m железо.
Найдите десять отличий, что называется. Подсказка: рядом с "1" неспроста поставлен вопросительный язык.
Q>>Когда дойдет до практики, идеал может оказаться не столь уж и идеальным. Вот тут некоторые Blackbox хвалят, может он еще лучше? WH>Ну черная коробка это вобще не ОС. Обероновци толкают голубую бутылку. Но она не выдерживает критики ни по безопасности ни то масштибируемости. WH>В тоже время анилиз сингулирити откровенно слабых мест в общей концепции не выявил.
Да какая разница?!
<< Под музыку: Аквариум — Некоторые Женятся (А Некоторые — Так) >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А могло бы быть ещё проще, будь всё написано на одном-единственном языке. Осталось найти тот самый эсперанто.
А как виртуальныя машина отменяет разнообразие языков? Единственное что правильная ВМ отменяет всякие низкоуровневые языки которые не контролируют то что делает программист. Но вот нужны ли такие языки? ИМХО они только для малой части ядра ОС и для прошивки кристаллов.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Возможно. Раньше прослойки представлялись примерно так: ГВ>Язык высокого уровня n->m железо. ГВ>Сейчас, значится, будет так: ГВ>Язык высокого уровня n->1? прослойка 1?->m железо. ГВ>Найдите десять отличий, что называется. Подсказка: рядом с "1" неспроста поставлен вопросительный язык.
Дело в том что есть очень популярный ЯВУ с очень большими дырами в типизации, с ручным контролем памяти и с отсутствием проверок индексов массивов... называется он С++...
Вобщем рукомендую почитать отчет о сингулярити.
WH>>Ну черная коробка это вобще не ОС. Обероновци толкают голубую бутылку. Но она не выдерживает критики ни по безопасности ни то масштибируемости. WH>>В тоже время анилиз сингулирити откровенно слабых мест в общей концепции не выявил.
ГВ>Да какая разница?!
Какая разница между голубой бутылкой и сингулярити? А почитать отчеты слабо?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ГВ>>Язык высокого уровня n->1? прослойка 1?->m железо. ГВ>>Найдите десять отличий, что называется. Подсказка: рядом с "1" неспроста поставлен вопросительный язык. WH>Вобщем рукомендую почитать отчет о сингулярити.
Читал, читал, не беспокойся. Только как это отменяет вопросительный знак возле единицы?
WH>>>Ну черная коробка это вобще не ОС. Обероновци толкают голубую бутылку. Но она не выдерживает критики ни по безопасности ни то масштибируемости. WH>>>В тоже время анилиз сингулирити откровенно слабых мест в общей концепции не выявил. ГВ>>Да какая разница?! WH>Какая разница между голубой бутылкой и сингулярити? А почитать отчеты слабо?
Какая разница, сколько их — сингуляритей, бутылок и прочих?
<< Под музыку: Аквариум — Афанасий Никитин буги (хождение за три моря — 2) >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
ГВ>>А могло бы быть ещё проще, будь всё написано на одном-единственном языке. Осталось найти тот самый эсперанто. WH>А как виртуальныя машина отменяет разнообразие языков?
Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM?
<< Под музыку: Аквариум — Афанасий Никитин буги (хождение за три моря — 2) >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Читал, читал, не беспокойся. Только как это отменяет вопросительный знак возле единицы?
А зачем ты строчку про С++ удалил? Это был намек на ответ на твой намек.
ГВ>Какая разница, сколько их — сингуляритей, бутылок и прочих?
Ничего не понял.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM?
Сделать Java под .NET не проблема. Сделать C# под JVM труднее но тоже можно ибо JVM беднее CLR. Хотя смысла в этом нет никакого.
Но если сделать довольно богатую ВМ то под нее можно будет легко портировать почти любой язык. С осталными придется повозится но тоже можно. Вопрос в том нужно ли.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ГВ>>Читал, читал, не беспокойся. Только как это отменяет вопросительный знак возле единицы? WH>А зачем ты строчку про С++ удалил? Это был намек на ответ на твой намек.
Что-то не понял намёка. Я имею ввиду, что не появится одной-единственной виртуальной машины, способной решить все проблемы. Следовательно, к многообразию железа добавится многообразие виртуальных машин.
<< Под музыку: Аквариум — О смысле всего сущего >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, WolfHound, Вы писали:
Q>>>Да? А где эта ОС работает, где ее продают, а? WH>>Пока это исследовательский проект. Но направление очень верное.
ГВ>Возможно. Раньше прослойки представлялись примерно так:
ГВ>Язык высокого уровня n->m железо.
ГВ>Сейчас, значится, будет так:
ГВ>Язык высокого уровня n->1? прослойка 1?->m железо.
ГВ>Найдите десять отличий, что называется. Подсказка: рядом с "1" неспроста поставлен вопросительный язык.
1) Механизм безопасности во-многом является compile-time, т.е. после компиляции оверхеда нет.
2) Если в железе реализуют механизмы безопасности, опять же прослойка исчезнет.
3) Влияние этой прослойки может быть не очень значительным.
4) Доказуемо безопасный код позволяет обойтись без некоторых дорогостоящих механизмов безопасности необходимых сейчас (переключение между режимами ядра и пользователя). Собственно на этой идее и основана Singularity.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я имею ввиду, что не появится одной-единственной виртуальной машины, способной решить все проблемы. Следовательно, к многообразию железа добавится многообразие виртуальных машин.
Я что-то такой тенденции не вижу, скорее, наоборот, появляются новые языки (и адаптируются существующие) под существующие вирт. машины (JVM и .NET).
Да собственно даже с железом не происходит бурного развития множества платформ. Вон Apple, наоборот, теперь перешла на тот же x86.
...то мир C++ можно сравнить с государством, где разрешена свободная продажа оружия, милиции нет,
и мыслится что безопасность граждан будет обеспечена их собственным благоразумием .
А если серьезно, то действительно лучше чтобы unsafe средства были, но использовали их только в ограниченных случаях, в тех программах где это реально надо (низкоуровневый код ОС).
Здравствуйте, VladD2, Вы писали:
ГВ>>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM? VD>Да/да.
А фреймворки?
<< Под музыку: Аквариум — Беспечный русский бродяга >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Андрей Хропов, Вы писали:
ГВ>>Я имею ввиду, что не появится одной-единственной виртуальной машины, способной решить все проблемы. Следовательно, к многообразию железа добавится многообразие виртуальных машин. АХ>Я что-то такой тенденции не вижу, скорее, наоборот, появляются новые языки (и адаптируются существующие) под существующие вирт. машины (JVM и .NET).
Я исхожу из того, что на сие место под солнцем всегда найдётся куча желающих. Не так давно JVM была почти что единственной широко используемой виртуальной машиной.
АХ>Да собственно даже с железом не происходит бурного развития множества платформ. Вон Apple, наоборот, теперь перешла на тот же x86.
Да как сказать... Sparc, Power (даже если Apple и объявила о поддержке x86), x86, плюс ещё туева хуча встраиваемых и суперкомпьютерных.
<< Под музыку: Аквариум — Ткачиха >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Андрей Хропов, Вы писали:
WH>>>Пока это исследовательский проект. Но направление очень верное.
ГВ>>Возможно. Раньше прослойки представлялись примерно так: ГВ>>Язык высокого уровня n->m железо. ГВ>>Сейчас, значится, будет так: ГВ>>Язык высокого уровня n->1? прослойка 1?->m железо. ГВ>>Найдите десять отличий, что называется. Подсказка: рядом с "1" неспроста поставлен вопросительный язык.
АХ>1) Механизм безопасности во-многом является compile-time, т.е. после компиляции оверхеда нет. АХ>2) Если в железе реализуют механизмы безопасности, опять же прослойка исчезнет. АХ>3) Влияние этой прослойки может быть не очень значительным. АХ>4) Доказуемо безопасный код позволяет обойтись без некоторых дорогостоящих механизмов безопасности необходимых сейчас (переключение между режимами ядра и пользователя). Собственно на этой идее и основана Singularity.
К чему это перечисление? Я имел ввиду, что появляется дополнительное звено между языком высокого уровня и железом. Понятно, что раз появляется, то у него есть какая-то функциональность.
<< Под музыку: Аквариум — Ткачиха >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
ГВ>>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM? WH>Сделать Java под .NET не проблема.
Здравствуйте, WolfHound, Вы писали:
GZ>>Проблема, насколько я понимаю, не в коде операционки. Проблема в коде клиентов. Если разрешен неверифицируемый код в клиенте, то safe или unsafe ядро — проблема есть. Если запрещен, то независимо от того, какая операционка, и насколько она сингулярна — проблемы нет. WH>На сколько мне извесно самые разрушительные черви ходит именно ерез дырки ОС. Так что верфифицировать нужно все что вобще возможно. Вобщем мое мнение чем меньше unsafe кода тем лучше.
Червяки можно разделить на две категории. Первые — внедряются с внешней стороны, вторые — выполняются внутри системы, но проводят действия на которые он не имеет прав. Для второго случая, важен обход апаратной защиты адресации памяти(что обычно делается с помощью дырок в OS). В случае с сингуларити — все несколько проще в смысле аппаратной защиты. Unsafe программа может легко работать в адресах на которые у него прав нет. Safe программа — нет.
WolfHound wrote: > C>Только этот код исполняется в режиме ядра, остальной код работает в > C>контексте пользователя, так что система выживает даже если упадет > C>железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non > C>Stop). Так что managed OS нафиг не нужна. > Угу а приложение от самого себя кто защищать будет?
Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой
супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным
это не мешало.
> Как ты думаешь почему так популярны всякие жабы и дотнеты?
Как ты думаешь, а почему они популярны там, где пофиг на объемы
сжираемой памяти и быстродействие?
> Значит они сделали что-то не так. Посмотри на отчет о сингулярити она > работает плюс/минус с тойже скоростью что современные винда и линух. И > это при том что сингулярити практически не оптимизировали.
Сингулярити не позволяет использовать нативный код.
> Кроче проблемы со скоростью это то во что тебе хочется верить. Реально > будет скорре наоборот.
Мечты, мечты
> Вобщем мы это все уже обсудили. Единственный минус что ты нашол это > потеря 30% в очень специфических случаях из-за несовершенства > современных оптимизаторов.
ЕДИНСТВЕННЫЙ???? А как насчет многократного перерасхода памяти И
жуткого усложнения кода (чтобы хоть как-то памяти сэкономить)?
Здравствуйте, Cyberax, Вы писали:
C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным C>это не мешало.
Практика показывает что какбы программист этого не хотел у него это всеравно не получится. Ибо человек не может работать совсем без ошибок.
C>Как ты думаешь, а почему они популярны там, где пофиг на объемы C>сжираемой памяти и быстродействие?
Памяти они действительно жрут несколько больше, а вот тормоза сильно преувеличины.
C>Сингулярити не позволяет использовать нативный код.
И правильно делает. На кой черт он нужен?
C>Мечты, мечты
Поживем увидим.
C>ЕДИНСТВЕННЫЙ???? А как насчет многократного перерасхода памяти И C>жуткого усложнения кода (чтобы хоть как-то памяти сэкономить)?
Покачто ничто кроме твоих слов это не подтверждает. Кстати помнишь я сходу нашол способ сэкономить 33% процента памяти при этом упростив код и подняв производительность. И это без изменения архитектуры. К сожалению я не знаю задачу по этому я не смогу оптимизировать на архитектурном уровне.
Болие того обемы памяти будут продолжать рости им в отличии от мощности процессоров ничто не мешает.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound,
ГВ>>Зададим вопрос: есть ли Java на .Net, и наоборот — имеется ли C# для JVM? WH>Сделать Java под .NET не проблема. Сделать C# под JVM труднее но тоже можно ибо JVM беднее CLR.
Некоторое подмножество отобразить можно и вполне успешно. Grasshopper Visual MainWin for J2EE
WH>Хотя смысла в этом нет никакого.
Смысл всё-таки есть: переход между платформами, унаследованные решения, переход на Unix etc.
WolfHound wrote: > C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой > C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным > C>это не мешало. > Практика показывает что какбы программист этого не хотел у него это > всеравно не получится. Ибо человек не может работать совсем без ошибок.
И? Мне текущие программы вполне нравятся. То что у меня будет
выскакивать красивый stacktrace вместо Access Violation — меня не особо
привлекает.
> C>Сингулярити не позволяет использовать нативный код. > И правильно делает. На кой черт он нужен?
Мне нужен. Если кто-то не умеет нативный код использовать — его проблемы.
> C>ЕДИНСТВЕННЫЙ???? А как насчет *многократного* перерасхода памяти И > C>жуткого усложнения кода (чтобы хоть как-то памяти сэкономить)? > Покачто ничто кроме твоих слов это не подтверждает.
Подтверждает. Например, отсутствие .NET/Java программ на обычных десктопах.
> Кстати помнишь я сходу нашол способ сэкономить 33% процента памяти > при этом упростив код и подняв производительность.
До варианта с указателями все равно как до Луны. Кстати, твой вариант
уже не пройдет — недавно пришлось примерно 100000 временных массивов
создать Так что потребуется уже два байта на индекс.
> Болие того обемы памяти будут продолжать рости им в отличии от мощности > процессоров ничто не мешает.
Я предпочитаю использовать дополнительную память, чтобы приложения
работали быстрее (из-за большего кэша диска, например), а не для того,
чтобы их разработчикам было легче их писать.
Здравствуйте, Cyberax, Вы писали:
C>То же самое может замечательно и с .NET-программами случится.
Вероятность гораздо ниже. К томуже исключены наведенки непонятно откуда.
C>Переписывать ВЕСЬ (причем абсолютно весь) софт ради крайне редких случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое надо.
Ну можно начать с серверов и банков. Там итак очень много софта написано на safe языках.
И если сделать ВМ по умному то на нее можно будет запускить и жабные и .НЕТные приложения как родные.
Далие делается версия операционки которая работает в симбиозе с другими ОС и начинается захват десктопов.
Процесс этот не быстрый но вполне реальный.
В любом случае от него в долгосрочной перспективе индустрия только выиграет.
C>Трассировка стека замечательно делается и без .NET, причем еще со времен 70-х годов (core dump'ы). На Винде есть: C>http://www.codeproject.com/debug/XCrashReportPt4.asp
C>Тогда не трогайте тех, кто понимает.
Ну ты толком объясни зачем.
C>У меня тоже. Но вот совсем нет: C>1. Мелких утиллит (типа MP3-плеера, IM, менеджера закачек).
У меня тоже. Но только по тому что меня текущие устраивают и менять окружение без особой необходимости я не стану. C>Так как иначе памяти бы не осталось.
Про память уже был флейм. В конце концов Паша Дворкин начал уходить от вопросов, а потом вобще пропал. C>2. Крупных десктопных приложений.
VS2005 мелкое приложение? Хоть и не 100% .НЕТ но там много управляемого кода. C>3. Мелких утиллит командной строки.
Есть. В основном самописные... на C#...
C>Нет. Я предпочитаю пользоваться КАЧЕСТВЕННЫМ продктом, а не результатом того, что Гашиш Кумары смогли начать писать софт.
Я тоже. Но причем тут Гашиш Кумары?
Например я когда перешол на .НЕТ начал работать куда эффективние.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>То же самое может замечательно и с .NET-программами случится. > Вероятность гораздо ниже. К томуже исключены наведенки непонятно откуда.
Я уже не помню, когда в моем софте была такая ошибка в последний раз.
Обычно результаты переполнений буфферов видны тут же.
> C>Переписывать ВЕСЬ (причем *абсолютно весь*) софт ради крайне редких > случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое > надо. > Ну можно начать с серверов и банков. Там итак очень много софта написано > на safe языках.
И пусть. Мне лично пофиг на какой версии COBOLа работает мой банк.
> И если сделать ВМ по умному то на нее можно будет запускить и жабные и > .НЕТные приложения как родные.
Где же она эта по-умному сделанная система (Singularity — это не ОНО)?
> Далие делается версия операционки которая работает в симбиозе с другими > ОС и начинается захват десктопов.
Возьмем VB6 — на нем достаточно сложно уронить систему и очень легко
писать. По нынешним меркам VB6-приложения работают тоже вполне быстро.
И где же это доминирование десктопов быстрыми и качественными
приложениями на VB?
> C>Тогда не трогайте тех, кто понимает. > Ну ты толком объясни зачем.
Скорость, большие языковые возможности, возможности намерянных
хаков, совместимость с ГИГАНТСКИМИ объемами уже существующего кода.
> C>У меня тоже. Но вот совсем нет: > C>1. Мелких утиллит (типа MP3-плеера, IM, менеджера закачек). > У меня тоже. Но только по тому что меня текущие устраивают и менять > окружение без особой необходимости я не стану.
Мне вот кроссплатформенный мультипротокольный IM нужен. Казалось бы,
лучшее место для Java, но нормальных IM-клиентов на Java нет — никого
обычно не интересует мелкая утилита, жрущая 60Мб памяти (хотя
корпоративные IMы на Java есть).
> C>Так как иначе памяти бы не осталось. > Про память уже был флейм. В конце концов Паша Дворкин начал уходить от > вопросов, а потом вобще пропал.
Можно новый затеять.
> C>2. Крупных десктопных приложений. > VS2005 мелкое приложение? Хоть и не 100% .НЕТ но там много управляемого > кода.
Это не end-user десктопное приложение (я их имел в виду). Из
end-user'ных знаю только OneNote (который мало кто использует).
> C>Нет. Я предпочитаю пользоваться КАЧЕСТВЕННЫМ продктом, а не > результатом того, что Гашиш Кумары смогли начать писать софт. > Я тоже. Но причем тут Гашиш Кумары? > Например я когда перешол на .НЕТ начал работать куда эффективние.
Над теми же типами задач?
Я не спорю, веб-приложения и серверные системы сейчас идеально на
C#/Java писать.
Здравствуйте, Cyberax, Вы писали:
C>Я уже не помню, когда в моем софте была такая ошибка в последний раз. C>Обычно результаты переполнений буфферов видны тут же.
Обычно и у тебя... Вот только основная масса софта глючит по черному.
Переход с x86 на x86-64 прешлось отложить до лучших времен ибо куча программ не пошла.
...
C>Где же она эта по-умному сделанная система (Singularity — это не ОНО)?
Давай отделим мух от котлет.
Сингулярити это очень правельный концеп управляемой ОС. Но сингулярити основана наслегка модифицированном CLR со всеми его просчетами и глупостями.
Те если взять архитектруру сингулярити и реализовать ее на правильной ВМ то получится ОС которая будет очень быстро вытеснять другие ОС с серверов.
C>Возьмем VB6 — на нем достаточно сложно уронить систему и очень легко писать. По нынешним меркам VB6-приложения работают тоже вполне быстро.
В десятки раз медленнее нативных. А управляемые медленней на проценты.
К томуже VB6 очень уродливый язык и писать на нем довольно трудно.
C>Скорость,
Что скорость? В реальных приложениях это миф. Да ты и сам это прекрасно знаешь. А есть приложения где управляемые среды еще и быстрее нативных. Например если нужна кодогенерация. C>большие языковые возможности,
Вспомнить про немерле? C>возможности намерянных хаков,
Зачем? C>совместимость с ГИГАНТСКИМИ объемами уже существующего кода.
Единственное реальное преймущество. Вот только код постоянно обновляется и процент safe кода растет.
C>Мне вот кроссплатформенный мультипротокольный IM нужен. Казалось бы, лучшее место для Java, но нормальных IM-клиентов на Java нет — никого обычно не интересует мелкая утилита, жрущая 60Мб памяти (хотя корпоративные IMы на Java есть).
Блин да откуда ты берешь такие цифры? Дай угадаю с потолка верно?
У меня янус меньше занимает, а он тот еще обжора. И жрет там память в основном не .НЕТ...
C>Это не end-user десктопное приложение (я их имел в виду). Из end-user'ных знаю только OneNote (который мало кто использует).
Что жначит не end-user? Я вполне себе end-user этой самой студии.
C>Над теми же типами задач?
Да.
C>Я не спорю, веб-приложения и серверные системы сейчас идеально на C#/Java писать.
Под десктоп на них тоже можно неплохо писать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Я уже не помню, когда в моем софте была такая ошибка в последний раз. > C>Обычно результаты переполнений буфферов видны тут же. > Обычно и у тебя... Вот только основная масса софта глючит по черному.
Я использую в основном: Thunderbird (не помню когда падало), FireFox
(вполне стабилен), Apollo (ни разу не падал), Miranda (действительно
глюкодром, ищу замену), FAR (идеален), MSVS (достаточно стабильна).
Редкие падения меня ну абсолютно не напрягают.
> Переход с x86 на x86-64 прешлось отложить до лучших времен ибо куча > программ не пошла. Виндовых программ. При миграции Debian x86 -> Debian AMD64 не
возникло ни одной проблемы с приложениями.
Интересно, сколько программ сломались при миграции .NET 1.0 -> .NET 2.0?
А сколько сломаются при миграции с Singularity на суперсистему BigBang,
в которой будут автомагически проверятся race-condition'ы и неправильное
использование потоков?
> Сингулярити это очень правельный концеп управляемой ОС. Но сингулярити > основана наслегка модифицированном CLR со всеми его просчетами и глупостями. > Те если взять архитектруру сингулярити и реализовать ее на правильной ВМ > то получится ОС которая будет очень быстро вытеснять другие ОС с серверов.
Понимаешь, даже самая правильная VM с "безопасным" кодом не даст мне
прямого управления памятью и указателей.
> C>Возьмем VB6 — на нем достаточно сложно уронить систему и очень легко > писать. По нынешним меркам VB6-приложения работают тоже вполне быстро. > В десятки раз медленнее нативных.
Решается более быстрым процессором. Какие проблемы? Если начать писать
проект длительностью в пять лет, то к концу проекта развитие компьютеров
и крутых компиляторов сделает софт таким же быстрым как и нативный в
начале проекта.
> К томуже VB6 очень уродливый язык и писать на нем довольно трудно.
s/VB6/C#.
> C>Скорость, > Что скорость? В реальных приложениях это миф.
В моем случае — жестокая реальность. На производительность нескольких
критичных кусков влияло даже неправильное расположение звезд. Причем
влияло в разы (JIT иногда отказывался инлайнить циклы).
> Да ты и сам это прекрасно знаешь. А есть приложения где управляемые > среды еще и быстрее нативных.
Есть. И пусть там и используются. Я что ли против?
Мне не нравится навязывание управляемых сред.
> Например если нужна кодогенерация.
???
> C>б*о*льшие языковые возможности, > Вспомнить про немерле?
Для меня это "C# вид сбоку".
> C>возможности намерянных хаков, > Зачем?
Бывает нужно.
> C>совместимость с ГИГАНТСКИМИ объемами уже существующего кода. > Единственное реальное преймущество. Вот только код постоянно обновляется > и процент safe кода растет.
Если и растет, то только за счет маргинальных проектов. Раньше рос объем
VB6-кода.
> C>Мне вот кроссплатформенный мультипротокольный IM нужен. Казалось бы, > лучшее место для Java, но нормальных IM-клиентов на Java нет — никого > обычно не интересует мелкая утилита, жрущая 60Мб памяти (хотя > корпоративные IMы на Java есть). > Блин да откуда ты берешь такие цифры? Дай угадаю с потолка верно?
Нет. Я в свое время сам писал видеоIM на Java (с использованием
DivX-сжатия, кстати).
Именно столько занимает корпоративный IM, который я смотрел.
> C>Это не end-user десктопное приложение (я их имел в виду). Из > end-user'ных знаю только OneNote (который мало кто использует). > Что жначит не end-user? Я вполне себе end-user этой самой студии.
Не для разработчиков, в общем.
> C>Я не спорю, веб-приложения и серверные системы сейчас идеально на > C#/Java писать. > Под десктоп на них тоже можно неплохо писать.
Только корпоративные приложения. Или достаточно крупные suite'ы.
Здравствуйте, Cyberax, Вы писали:
C>Я использую в основном: Thunderbird (не помню когда падало), FireFox (вполне стабилен), Apollo (ни разу не падал),
Не использовал. C>Miranda (действительно глюкодром, ищу замену),
Это точно. C>FAR (идеален),
Если не увлекаться плагинами... C>MSVS (достаточно стабильна).
Пока не пытаешься писать под нее расширения.
C>Редкие падения меня ну абсолютно не напрягают.
А меня напрягают. Особенно если упал outpost firewall эта сволоч падает редко но метко убивая винду.
C>Виндовых программ. При миграции Debian x86 -> Debian AMD64 не возникло ни одной проблемы с приложениями.
Ну значит повезло. А как там было с драйверами?
C>Интересно, сколько программ сломались при миграции .NET 1.0 -> .NET 2.0?
Нисколько.
Ибо если программа хочет первый фреймворк то она будет требовать первый, а не второй.
При портирование программы на второй нужно в нескольких местах изменить вызовы некоторых библиотек. Но это не из-за CLR, а из-за того что библиотеки изменились.
C>А сколько сломаются при миграции с Singularity на суперсистему BigBang, в которой будут автомагически проверятся race-condition'ы и неправильное использование потоков?
Те сколько незаметно глючевших программ станут глючить заметно?
C>Понимаешь, даже самая правильная VM с "безопасным" кодом не даст мне прямого управления памятью и указателей.
Зачем?
C>Решается более быстрым процессором. Какие проблемы? Если начать писать проект длительностью в пять лет, то к концу проекта развитие компьютеров и крутых компиляторов сделает софт таким же быстрым как и нативный в начале проекта.
C>В моем случае — жестокая реальность. На производительность нескольких критичных кусков влияло даже неправильное расположение звезд. Причем влияло в разы (JIT иногда отказывался инлайнить циклы).
Те опять несовершенство оптимизатора в современно JIT'е?
C>Есть. И пусть там и используются. Я что ли против? C>Мне не нравится навязывание управляемых сред.
А мне ненравится тот глюкодром который есть сейчас. Применение управляемых сред позволит значительно снизить колличество глюков.
>> Например если нужна кодогенерация. C>??? http://www.bltoolkit.net/
>> C>б*о*льшие языковые возможности, >> Вспомнить про немерле? C>Для меня это "C# вид сбоку".
Что ты тогда понимаешь под языковыми возможностями?
>> C>возможности намерянных хаков, >> Зачем? C>Бывает нужно.
На вопрос ответь.
C>Если и растет, то только за счет маргинальных проектов. Раньше рос объем VB6-кода.
Мда... вот так сразу записал кучу софта в маргиналы...
C>Именно столько занимает корпоративный IM, который я смотрел.
И что это значит? Как это доказывает что любой IM на управляемом языке будет жрать столько памяти?
C>Не для разработчиков, в общем. C>Только корпоративные приложения. Или достаточно крупные suite'ы.
А какая разница? Чего ты хочешь доказать?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
ГВ>>>>А фреймворки? VD>>>25! ГВ>>33! VD>
-------------------------
VD>Летят Василий Иванович и Петька на самолете...
VD>Петька:
VD>- Василий Ивановичь! Приборы!!!
VD>- 25.
VD>- Что 25?!!!
VD>- А что приборы?
Пятница? Хм. Нет, вторник.
<< Под музыку: Аквариум — 4D (Последний День Августа) [Bonus] >>
<< При помощи Януса: 1.2.0 alpha rev. 643 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> C>Только этот код исполняется в режиме ядра, остальной код работает в >> C>контексте пользователя, так что система выживает даже если упадет >> C>железка с драйвером. У HP есть такие же технологии (Tandem, теперь Non >> C>Stop). Так что managed OS нафиг не нужна. >> Угу а приложение от самого себя кто защищать будет? C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным C>это не мешало.
Ответил здесь
.
>> Как ты думаешь почему так популярны всякие жабы и дотнеты? C>Как ты думаешь, а почему они популярны там, где пофиг на объемы C>сжираемой памяти и быстродействие?
Почему же их все-таки используют если они так плохи?
.
>> Значит они сделали что-то не так. Посмотри на отчет о сингулярити она >> работает плюс/минус с тойже скоростью что современные винда и линух. И >> это при том что сингулярити практически не оптимизировали. C>Сингулярити не позволяет использовать нативный код.
Какая разница?
Ну будет скомпилировано из MSIL JIT или AOT компилятором в тот же машинный код.
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> А как виртуальныя машина отменяет разнообразие языков? Единственное что >> правильная ВМ отменяет всякие низкоуровневые языки которые не >> контролируют то что делает программист. Но вот нужны ли такие языки? C>Нужны.
Но для небольшого числа применений (в ядре ОС и драйверах).
C>В качестве Fully Managed OS — уже сейчас у IBM есть AS/400, там как раз C>ВЕСЬ код в виртуальной машине выполняется. Хотя там набор инструкций VM C>больше напоминает классические процессорные команды и не является C>"безопасным" (хотя AS/400 и гарантирует, что приложение не вырвется за C>пределы логического раздела). Работает все это очень медленно.
Так там наверное интерпретация, а не JIT.
В Java и .NET перешли на JIT модель.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой C>>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным C>>это не мешало. WH>Практика показывает что какбы программист этого не хотел у него это всеравно не получится. Ибо человек не может работать совсем без ошибок.
+1.
Как вы думаете, какую систему выберет банк?
Быструю на C++, с 96% гарантией от неявных ошибок повреждения данных (от обращения по неверному адресу)
или на C# со 100% гарантией.
C>>Как ты думаешь, а почему они популярны там, где пофиг на объемы C>>сжираемой памяти и быстродействие? WH>Памяти они действительно жрут несколько больше, а вот тормоза сильно преувеличины.
+1.
Посмотрите на сравнение Java с С++ (да и с другими) здесь.
Особенно при росте N.
(С# там работает плохо из-за недоделок Mono).
WH>Болие того обемы памяти будут продолжать рости им в отличии от мощности процессоров ничто не мешает.
Ну тут ньюансы есть.
Дело еще и в скорости передачи данных по системной шине, объеме кеша и эффективности его работы.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Но для небольшого числа применений (в ядре ОС и драйверах).
В драйверах не нужно. Прочтиай про сингулярити Re[8]: Управляемая ОС
Здравствуйте, WolfHound, Вы писали:
WH>Доведение слов до абсурда -> демагогия.
Реальность, однако, всякой выдумки смешней. http://www.lenta.ru/news/2006/05/23/flexgo/
WH>В нормальных ОС можно задавать ограничения на колличество выделяемой памяти процессом.
Можно. Но толку-то? Если не обеспечивается соблюдение закона, то это фуфельный закон.
WH>По существу есть что сказать? Или не нравится мне то что нельзя память испортить и точка?
Мне очень нравится что нельзя испортить память. Но мне не нравится, что для этого при каждом обращении выполняются проверки. Только не надо говорить, что все это ерунда по сравнению с мировой революцией. Это очень не ерунда и примером тому — многомерные массивы. Замечательная штука! Просто мечта для ряда задач. И... совершенно бесполезная по причитне диких тормозов.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Мне очень нравится что нельзя испортить память. Но мне не нравится, что для этого при каждом обращении выполняются проверки. Только не надо говорить, что все это ерунда по сравнению с мировой революцией. Это очень не ерунда и примером тому — многомерные массивы. Замечательная штука! Просто мечта для ряда задач. И... совершенно бесполезная по причитне диких тормозов.
Максим, а вы не знали что это есть ерунда по сравнению с мировой революцией!!!
Большинство проверок на правильность делается не в runtime а JIT компилятором. Проверки выхода за границы массива, часто также вполне хорошо оптимизируется. Поэтому диких тормозов в этой связи нет и не будет.
Здравствуйте, McSeem2, Вы писали:
MS>Реальность, однако, всякой выдумки смешней. MS>http://www.lenta.ru/news/2006/05/23/flexgo/
Как я понимаю это что-то типа покупки компьютера в рассрочку.
Причем платить можно хоть сто лет. И никаких процентов, штрафов, пени итп...
Что в этом плохого?
WH>>В нормальных ОС можно задавать ограничения на колличество выделяемой памяти процессом. MS>Можно. Но толку-то? Если не обеспечивается соблюдение закона, то это фуфельный закон.
Это ты о чем?
MS>Мне очень нравится что нельзя испортить память. Но мне не нравится, что для этого при каждом обращении выполняются проверки.
Это очень легко оптимизируется при помощи анализа потока исполнения.
Для одномерных массивов при использовании циклов вида
for (int i = 0; i < arr.Length; ++i)
arr[i] = i;
такая оптимизация уже есть в .NET. MS>Только не надо говорить, что все это ерунда по сравнению с мировой революцией. Это очень не ерунда и примером тому — многомерные массивы. Замечательная штука! Просто мечта для ряда задач. И... совершенно бесполезная по причитне диких тормозов.
Это проблема конкретной реализации конкретной виртуальной машины. Это все можно оптимизировать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, GlebZ, Вы писали:
GZ>Большинство проверок на правильность делается не в runtime а JIT компилятором. Проверки выхода за границы массива, часто также вполне хорошо оптимизируется. Поэтому диких тормозов в этой связи нет и не будет.
"Нет и не будет". Почему же тогда двумерные массивы-то так тормозят?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Нет, мой наивный друг — так просто ничего не бывает. (Масяня) MS>..."оборудованы специальными микросхемами со встроенными функциями FlexGo". Вот в этом-то весь смысл "акции" и заключается — под видом благих намерений приручить население, чтобы потом была возможность держать своих пользователей на коротком поводке. Тебе нравится, когда тебя за хомячка держат? Мне — нет, даже если обеспечено сытое и комфортное сушествование.
Там же написано после того как ты сделал энное колличество выплат ограничения снимаются. И если этот чип торлько и делает что блокирует комп если не внесена плата то и черт с ним.
Не хочешь покупать комп с этим чипом плати сразу всю сумму за нормальный компьютер с нормальной виндой если не можешь заплатить все сразу бери потребительский кредит (с процентами, пени и прочеми радостями).
В чем проблема то?
MS>О том, что нет ни малейшего смысла в том, что "можно задать". Вот ты устанавливаешь некую приблуду — и что, устанавливаешь ей лимит по памяти? Не верю! А приблуда оказывается вредной бомбой.
Опятьже это решаемо. В тойже сингулярити приложение первоклассная сущьность. И без установки не работает. И это правильно. При установки приложения проверяется совместимость с окружением и требуемые приложением права. Кто мешает тудаже добавить максимальный объем памяти которое требует приложение? При этом скажем если этот объем меньше 100М (число можно настраивать) метров то ставить его молча, а если больше то спрашивать пользователя ставить или нет.
В любом случае максимум что произойдет система начнет свопить что система может легко засеч и спросить пользователя что-то типа: Тут есть зарвавшаяся программа... жрет память тоннами да так что я вся торможу. Может ее пристрелить?
MS>Вот! Эти слова я слышу с навязчивой периодичностью. Пора сделать их пожизненным девизом и выбить на логотипе.
Ну а я вижу как .НЕТ с каждой версией работает все быстрее и быстрее.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Переписывать ВЕСЬ (причем абсолютно весь) софт ради крайне редких случаев, в которых из-за наведенных ошибок портятся данные? Нафиг такое надо. WH>Ну можно начать с серверов и банков. Там итак очень много софта написано на safe языках.
Сервера и банки давным давно сидят на safe-языках и платформах. Многие писали и продолжают писать на Oracle Forms'ах, PowerBuilder (от Sybase) и подобных средствах. Сейчас переходят на более современные платформы вроде той же жабы.
Так что серверно-банковская сфера не соприкасается с клиенской. И не факт, что если в банках ставят жабу, то значит скоро начнут ее применять на клиентах. И не надо приводить в пример специфические средства, которые используются разработчиками )))
Андрей Хропов wrote: > C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой > C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным > C>это не мешало. > Ответил здесь <http://rsdn.ru/forum/Message.aspx?mid=1912518&only=1>
.
А как насчет D, например? Он тоже под SuperManagedOS работать не будет.
>> > Как ты думаешь почему так популярны всякие жабы и дотнеты? > C>Как ты думаешь, а почему они популярны там, где пофиг на объемы > C>сжираемой памяти и быстродействие? > Почему же их все-таки используют если они так плохи?
Так ведь и не используют почти нигде, кроме корпоративных приложений.
> А вообще есть классический пример: Re: Частые вычисления по > неопределенной формуле!!! > <http://rsdn.ru/forum/Message.aspx?mid=630887&only=1>
.
Ну и как часто это надо? Я в своей практике не помню ни разу, когда
такое понадобилось.
>> > Значит они сделали что-то не так. Посмотри на отчет о сингулярити она >> > работает плюс/минус с тойже скоростью что современные винда и линух. И >> > это при том что сингулярити практически не оптимизировали. > C>Сингулярити не позволяет использовать нативный код. > Какая разница? > Ну будет скомпилировано из MSIL JIT или AOT компилятором в тот же > машинный код.
Сингулярити не позволяет НАПРЯМУЮ использовать:
1. Машинный код и языки компилирующие в него.
2. Ручное управление памятью.
3. Виртуальную память (хотя, возможно, и добавят).
Здравствуйте, Cyberax, Вы писали:
C>Сингулярити не позволяет НАПРЯМУЮ использовать: C>1. Машинный код и языки компилирующие в него. C>2. Ручное управление памятью. C>3. Виртуальную память (хотя, возможно, и добавят).
Kluev wrote: > C>Сингулярити не позволяет НАПРЯМУЮ использовать: > C>1. Машинный код и языки компилирующие в него. > C>2. Ручное управление памятью. > C>3. Виртуальную память (хотя, возможно, и добавят). > А файлы она в память умеет отображать?
Нет, так как защиты памяти там нет (все в нулевом кольце сидит и
работает с физическими адресами).
Здравствуйте, McSeem2, Вы писали:
MS>Почему же тогда двумерные массивы-то так тормозят?
Ты главное никому об этом не рассказывай. Это самый большой секрет.
А вообще, все можно написать чтобы тормозило. И массивы, и работу с типами.
Lloyd wrote: >> > В Java и .NET перешли на JIT модель. > C>В Java — уже на HotSpot. > А в чем отличие HotSpot-а от JIT-а?
HotSpot производит постоянный мониторинг кода и производит адаптивную
оптимизацию. То есть один и тот же код может быть JIT-скомпилирован
несколько раз.
Здравствуйте, Cyberax, Вы писали:
C>А как насчет D, например? Он тоже под SuperManagedOS работать не будет.
В сад этот D. Кому он нужен? Я еще понимаю С/С++ на них куча кода написано... но D...
C>Так ведь и не используют почти нигде, кроме корпоративных приложений.
А чем корпоративные приложения плохи?
C>Сингулярити не позволяет НАПРЯМУЮ использовать: C>1. Машинный код и языки компилирующие в него. C>2. Ручное управление памятью. C>3. Виртуальную память (хотя, возможно, и добавят).
Осталось понять зачем это нужно. Ты же не объясняешь, а только говоришь что никак без этого нельзя.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>А как насчет D, например? Он тоже под SuperManagedOS работать не будет. > В сад этот D. Кому он нужен? Я еще понимаю С/С++ на них куча кода > написано... но D...
А почему "в сад" должен отправляться D, а не C#?
> C>Так ведь и не используют почти нигде, кроме корпоративных приложений. > А чем корпоративные приложения плохи?
У них (как и у приложений для разработчиков) немного другой фокус.
Корпоративные приложения используются для обеспечения работы компании и
обычно неважно, что они занимают на 30Мб больше памяти — прибыль для
корпорации важнее.
> C>Сингулярити не позволяет НАПРЯМУЮ использовать: > C>1. Машинный код и языки компилирующие в него. > C>2. Ручное управление памятью. > C>3. Виртуальную память (хотя, возможно, и добавят). > Осталось понять зачем это нужно. Ты же не объясняешь, а только говоришь > что никак без этого нельзя.
А зачем вообще нужен .NET?
Здравствуйте, Cyberax, Вы писали:
C>А почему "в сад" должен отправляться D, а не C#?
По тому что C# (если не использовать конструкцию unsafe которая на практике нафиг не упала) в отличии от D safe.
C>У них (как и у приложений для разработчиков) немного другой фокус. Корпоративные приложения используются для обеспечения работы компании и обычно неважно, что они занимают на 30Мб больше памяти — прибыль для корпорации важнее.
Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и работает стабильно.
Теперь нужно учесть что фичи во второе приложение будут добавлять быстрее да и немногочисленные ошибки долго жить не будут.
А теперь учтем что второе приложение появилось на пол года год раньше...
Как ты думаешь куда в конце концов уйдут пользователи?
Еще учти что процессоры все мощьнее и памяти все больше и она постоянно дешевеет.
C>А зачем вообще нужен .NET?
Чтобы проще и быстрее создовать болие качественные программы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Kluev wrote: >> C>Сингулярити не позволяет НАПРЯМУЮ использовать: >> C>1. Машинный код и языки компилирующие в него. >> C>2. Ручное управление памятью. >> C>3. Виртуальную память (хотя, возможно, и добавят). >> А файлы она в память умеет отображать? C>Нет, так как защиты памяти там нет (все в нулевом кольце сидит и C>работает с физическими адресами).
И в чем кайф? Отсуствие оверхеда на переходы kernespace-userspace и переключения контекстов.
Имхо, преимущества сомнительные. К тому же физическая адрессация переносит проблемы с фрагментацией памяти прямо на системный уровень.
Когда потребуется большой непрерывный кусок памяти его в системе может и не оказатся.
В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?
Здравствуйте, Cyberax, Вы писали:
C>Lloyd wrote: >>> > В Java и .NET перешли на JIT модель. >> C>В Java — уже на HotSpot. >> А в чем отличие HotSpot-а от JIT-а? C>HotSpot производит постоянный мониторинг кода и производит адаптивную C>оптимизацию. То есть один и тот же код может быть JIT-скомпилирован C>несколько раз.
Ну я это понимаю как вариацию JITа.
Кстати по подобной схеме работает также Python Psyco.
А в общем виде это называется Dynamic recompilation.
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >>> > А как виртуальныя машина отменяет разнообразие языков? Единственное что >>> > правильная ВМ отменяет всякие низкоуровневые языки которые не >>> > контролируют то что делает программист. Но вот нужны ли такие языки? >> C>Нужны. >> Но для небольшого числа применений (в ядре ОС и драйверах). C>А так же в: C>1. Desktop-приложениях (оффисы, браузеры и т.п.) C>2. Требовательных приложениях (CAD-системы, графические редакторы и т.п.) C>3. Мелких утиллитах.
На данный момент — да.
Оверхед, привносимый .NET не позволяет его использовать в требовательных приложениях
(Я не представляю себе требования к памяти Photoshop на .NET ).
Но тем не менее в принципе, с развитием управляемых сред и появлением соответствующих ОС
ситуация может измениться.
Технологии компиляции развиваются, Java HotSpot в некоторых случаях уже может работать наравне с (или немногм уступая) C++ по скорости (см. здесь).
Я еще слышал, что планируют объекты, адрес которых никуда не передается, размещать в стеке.
Так что все это развивается.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
C>>А почему "в сад" должен отправляться D, а не C#? WH>По тому что C# (если не использовать конструкцию unsafe которая на практике нафиг не упала) в отличии от D safe.
C>>У них (как и у приложений для разработчиков) немного другой фокус. Корпоративные приложения используются для обеспечения работы компании и обычно неважно, что они занимают на 30Мб больше памяти — прибыль для корпорации важнее. WH>Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и работает стабильно.
А давай лучше наоборот, первое и быстрое и не падает, а второе раз в полчаса демонстрирует стек и отправляет комп в глубокий swap
По моему личному опыту использования декстопных приложений их глюкавость практически не коррелирует с тем на чем программа написана, сталкивался и java приложениями с выше описанным поведением и С++ не разу не падал, и даже хуже того почему то написаные на питоне программы тоже бывают практически безглючными (а тут из динамики такое страх делают).
WH>Теперь нужно учесть что фичи во второе приложение будут добавлять быстрее да и немногочисленные ошибки долго жить не будут. WH>А теперь учтем что второе приложение появилось на пол года год раньше...
И тут тоже все не так однозначно, бывает и наооборот и нередко.
Здравствуйте, Kluev, Вы писали:
K>И в чем кайф? Отсуствие оверхеда на переходы kernespace-userspace и переключения контекстов.
K>Имхо, преимущества сомнительные. К тому же физическая адрессация переносит проблемы с фрагментацией памяти прямо на системный уровень. K>Когда потребуется большой непрерывный кусок памяти его в системе может и не оказатся.
K>В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?
Да... срочно читать про дефрагментирующие сборщики мусора.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
WH>>Теперь нужно учесть что фичи во второе приложение будут добавлять быстрее да и немногочисленные ошибки долго жить не будут. WH>>А теперь учтем что второе приложение появилось на пол года год раньше...
FR>И тут тоже все не так однозначно, бывает и наооборот и нередко.
Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Kluev wrote: > В догонку к предыдущему сообщению. > Такая поделка будет работать если все обьекты имеют размер не более 1 > страницы памяти (4-8к). В противном случае кода все зафрагментируется, > получится так что памяти полно, а выделить большой кусок нельзя. Ну и > кому нужно такое счастье?
Не совсем — там можно компактифицировать кучу с помощью GC. Так что
проблема фрагментации, в принципе, решается.
K>В догонку к предыдущему сообщению. K>Такая поделка будет работать если все обьекты имеют размер не более 1 страницы памяти (4-8к). В противном случае кода все зафрагментируется, получится так что памяти полно, а выделить большой кусок нельзя. Ну и кому нужно такое счастье?
Там вроде общесистемный GC, так что проблем с фрагментацией не должно быть.
Здравствуйте, Kluev, Вы писали:
K>Еще раз в догонку. K>Имхо, разделение системы на юзер-спейс и кернел-спейс, где каждый процесс получает свои законные 2 Гига (или другой обьем в зависимотси от архитектуры) является самым оптимальным решением. Все остальные поделки без виртуальной памяти нежизнеспособны или применимы в ограниченных условиях. Т.е. такие оси не универсальные. Имхо, в МС просто изобрели велосипед 40 летней девности для поездки по старым граблям.
Про 64х битное адресное пространство расказывать надо?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
K>>В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?
WH>Да... срочно читать про дефрагментирующие сборщики мусора.
И в чем выигрыш по сравнению с виртуальной памятью? Системе постоянно приходится физически перемещать большие обьемы памяти с места на место
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
WH>>>Теперь нужно учесть что фичи во второе приложение будут добавлять быстрее да и немногочисленные ошибки долго жить не будут. WH>>>А теперь учтем что второе приложение появилось на пол года год раньше...
FR>>И тут тоже все не так однозначно, бывает и наооборот и нередко. WH>Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.
Для рынка не теряют.
И зависит не только от квалификации но и от опыта команд и их (не)желания переучиватся.
Андрей Хропов wrote: > C>И что? Я не понимаю почему все должны от этого петь и танцевать. > Ты любишь глючные программы?
Нет, поэтому пользуюсь безглючными.
> Ты любишь тратить дополнительное время на отладку?
Я на C++ отлаживаю не медленнее, чем на C#.
> Ок, ты гуру, и у тебя таких проблем нет, > но это не значит что их не внесет при сопровождении другой человек.
Valgrind/Purify — и 99% проблем нет. Остальной 1% я согласен терпеть.
> не приходится дополнительно думать и писать логику ручного управления > памятью, что порождает более короткий и простой код.
А продумывание политик владения часто упрощает архитектуру, что в итоге
выливается в меньшие затраты по времени и более гибкую систему.
> C>*Лично в моем проекте* такие ошибки не создают ну абсолютно никаких > проблем. > Ну и хорошо. Рад лично за тебя.
Я тоже. Поэтому мне и не хочется, чтобы ради Гашиш Кумаров мне пришлось
писать исключительно "безопасный" код.
> C>Вот как раз обращения по неверному адресу всплывают сразу при > тестировании. > Это если они простые. Если логика сложная (куча объектов, многопоточность), > то не сразу понятно есть ли там текущая память, это может и не сразу > проявиться.
См. Rational Purify/Valgrind. Да стандартный трюк (заполнение
освобожденной памяти числом 0xDEADBEEF) вылавливает практически все промахи.
> C>При миграции DOS->Windows можно было использовать старый код без особых > C>проблем. В данном случае старый код придется переписать полностью весь. > Ты недооцениваешь развитие систем виртуализации. > Тот же DOS Extended mode ведь эмулируется?
Я говорю не про _исполнение_, а про _переиспользование кода_.
> C>Ага. Ведь приходится запускать отладчик и открывать его. А потом в > C>отладчике смотреть на все эти stacktrace'ы для всех потоков, фреймы > C>функций, значения локальных переменных. > Это если отладочная информация есть
А она должна быть у разработчика. И даже если нет — берем исходники
зарелизеной версии, компилим — и получается отладочная инфа.
> + прежде чем программа упадет она может так в памяти накосячить > что потом попробуй восстанови последовательность событий.
Обычно ошибки локализованы.
>> > Ага, если сам стек не запорчен, что сделать проще простого: > C>А это находится при первом тестировании с включеной проверкой стека. Или > C>с включеным Rational Purify. > А если выскочило после тестирования (без проверки стека)?
Если на моей машине — запускаю программу под Purify и смотрю. Если у
заказчика — воспроизвожу и смотрю.
А вообще, можно просто не пользоваться опасными функциями.
> Но дело в том, что все это используется во время отладки, а потом всего > этого нет. > Бывает, что и в Debug и Release работает по-разному один и тот же код.
Purify/Valgrind замечательно работают и с релизными версиями (я запускал
Oulook под Purify когда писал MAPI Storage).
> Если бы все было так неплохо, так Microsoft бы пачками патчи не выпускал.
Ну так не надо на лидера по глючности равняться.
> C>Ну не являются средства разработки приложениями для обычных конечных > C>пользователей. > Так тут были слова "крупный десктопный".
Я не считаю MSVS десктопным приложением, это инструментальная система.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, WolfHound, Вы писали:
K>>>В классических осях все просто, когда основная программа зафрагментировала все адрессное простарнство своего процесса, запускаем дополнительный процесс в котором можно хоть целый гиг неперывным куском хапнуть и он делает то что нужно. А тут что получается кто не успел тот опоздал? По сценариям доса шагают товарищи, кто первый загрузился тому и тапки?
WH>>Да... срочно читать про дефрагментирующие сборщики мусора.
K>И в чем выигрыш по сравнению с виртуальной памятью? Системе постоянно приходится физически перемещать большие обьемы памяти с места на место
От задачи зависит, на некторых есть выигрыш на других наоборот.
Здравствуйте, FR, Вы писали:
WH>>Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.
FR>Для рынка не теряют. FR>И зависит не только от квалификации но и от опыта команд
Гм... опыт и квалификация корелируют ну очень сильно.
FR>и их (не)желания переучиватся.
Вот те которые не желают переучитваться (не буду показывать пальцем но тут таких много) и тормозят процесс...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Kluev, Вы писали:
WH>>Да... срочно читать про дефрагментирующие сборщики мусора. K>И в чем выигрыш по сравнению с виртуальной памятью? Системе постоянно приходится физически перемещать большие обьемы памяти с места на место
Не большие и не постоянно. К томуже виртуальное адресное пространство никто не отменял. Те на 32х битной системе мы имем 4 гига на всех.
Кстати программы которым надо гиг непрерывного адресного пространства большая редкость.
В любом случае ты не понял главного: Такие ОС нужны для обеспечение стабильной работы системы, а не для того чтобы небыло переключения контекстов. И еще учти что такие системы не противоречят раздельным адреснам пространствам для каждого процесса (или группы связанных процессов).
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
WH>>>Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.
FR>>Для рынка не теряют. FR>>И зависит не только от квалификации но и от опыта команд WH>Гм... опыт и квалификация корелируют ну очень сильно.
Опыт бывает разный, например много лет на C++, и переход такой команды на тот же NET может ничего ни дать.
FR>>и их (не)желания переучиватся. WH>Вот те которые не желают переучитваться (не буду показывать пальцем но тут таких много) и тормозят процесс...
WolfHound wrote: > C>А почему "в сад" должен отправляться D, а не C#? > По тому что C# (если не использовать конструкцию unsafe которая на > практике нафиг не упала) в отличии от D safe.
Где он safe??? В нем же есть race condition'ы!!! Все надо писать исключительно на Erlang — там RC нет.
> Допустим появились два приложения одно чуть быстрее, ест меньше памяти и > иногда падает и второе чуть медленней, ест несколько больше памяти и > работает стабильно.
Нет. "Допустим появились два приложения одно чуть быстрее, ест меньше
памяти и иногда падает и второе чуть медленней, ест несколько больше
памяти и иногда падает". Ну не вижу я, что увеличение безопасности языка
приводит к менее глючному софту.
Например, у меня Eclipse для С++ глючит примерно так же как и Студия.
Eclipse написана на Java (если не считать 100Кб кода на С для SWT).
> C>А зачем вообще нужен .NET? > Чтобы проще и быстрее создовать болие качественные программы.
Не вижу этого. .NET заменяет С++ там, где С++ раньше плохо подходил, но
в других случаях (типа моего приложения) затраты на оптимизацию на C#
съедают все приросты в скорости разработки.
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >> C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой >> C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным >> C>это не мешало. >> Ответил здесь <http://rsdn.ru/forum/Message.aspx?mid=1912518&only=1>
. C>А как насчет D, например?
Ну он старый-добрый native code.
Даже с asm встроенным.
Очень неплохо для многих применений, если его доделают
+ портабельный с GCC backendом.
C>Он тоже под SuperManagedOS работать не будет.
В таком виде как сейчас не будет.
Но это ж open-source.
Можно как в C# сделать safe/unsafe mode, если люди захотят.
Там просто люди в основном старой C++ школы, для них это не приоритет на данный момент.
>> А вообще есть классический пример: Re: Частые вычисления по >> неопределенной формуле!!! >> <http://rsdn.ru/forum/Message.aspx?mid=630887&only=1>
. C>Ну и как часто это надо? Я в своей практике не помню ни разу, когда C>такое понадобилось.
Тем не менее, встроенный компилятор под рукой — удобно.
Что грамотно использовали разработчики Nemerle при создании системы метапрограммирования.
C>Сингулярити не позволяет НАПРЯМУЮ использовать: C>1. Машинный код и языки компилирующие в него.
Много языков уже перевели на .NET.
C>2. Ручное управление памятью.
В некоторых случаях это действительно недостаток,
но в любом случае Singularity — это только прототип.
Здравствуйте, Cyberax, Вы писали:
C>Где он safe??? В нем же есть race condition'ы!!! Все надо писать C>исключительно на Erlang — там RC нет.
Осталось понять как RC может испортить память.
C>Нет. "Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и иногда падает". Ну не вижу я, что увеличение безопасности языка приводит к менее глючному софту.
А я вижу.
C>Например, у меня Eclipse для С++ глючит примерно так же как и Студия. C>Eclipse написана на Java (если не считать 100Кб кода на С для SWT).
Теперь осталось сравнить сколько сил вложили в Eclipse и студию.
C>Не вижу этого. .NET заменяет С++ там, где С++ раньше плохо подходил, но в других случаях (типа моего приложения) затраты на оптимизацию на C# съедают все приросты в скорости разработки.
Пока я не видел ни одного случая который нельзя былобы легко оптимизировать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Защита достигается разделением и максимальной изоляцией всего, что только разделяется и изолируется. В качестве примера я уже приводил QNX — его используют на ядерных электростанциях, а его ядро представляет из себя небольшой кусок кода.
Блин. ОС для ядерных станций. Болие тепличных условий придумать нельзя. Тем весь код тестируют (а то и доказывают) так что никакой другодй системе и не снилось. Плюс там не вирусов и прочих хакеров.
C>Так что проблема надежности уже давно решена. Остается проблема скорости — в этом направлении сейчас тоже активно копают, можно почитать ответы Таненбаума Линусу. Возможно, скоро Mac OS X станет первой consumer-версией ОС с микроядром.
И как это спасет от внедрения вредоносного кода через переполнение буфера?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>В fully managed OS типа Singularity в принципе не может быть unsafe.
В принципе они могут создавать песочници при помощи все тойже виртуализации адресных пространств.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Где он safe??? В нем же есть race condition'ы!!! Все надо писать > C>*исключительно* на Erlang — там RC нет. > Осталось понять как RC может испортить память.
Да как два пальца:
public class A
{
public A someVar;
};
A.someVar=someAClass;
на 64-битных машинах с неатомарными 64-битными операциями. Для JVM даже
такой эксплоит на Sparc'е был.
Да и вообще, ведь RC и дедлоки на многопоточных приложениях приводят к
сложноуловимым ошибкам. Так что все обязаны использовать Erlang.
Или ты любишь глючный софт?
> C>Например, у меня Eclipse для С++ глючит примерно так же как и Студия. > C>Eclipse написана на Java (если не считать 100Кб кода на С для SWT). > Теперь осталось сравнить сколько сил вложили в Eclipse и студию.
Ты сам это сказал. Глючность программы зависит от вложенного труда.
> C>Не вижу этого. .NET заменяет С++ там, где С++ раньше плохо подходил, > но в других случаях (типа моего приложения) затраты на оптимизацию на C# > съедают все приросты в скорости разработки. > Пока я не видел ни одного случая который нельзя былобы легко оптимизировать.
Я тебе его показал.
WolfHound wrote: > Блин. ОС для ядерных станций. Болие тепличных условий придумать нельзя. > Тем весь код тестируют (а то и доказывают) так что никакой другодй > системе и не снилось. Плюс там не вирусов и прочих хакеров.
В QNX в нулевом кольце выполняется около 100Кб кода. Его можно под
микроскопом посмотреть и доказать корректность — все остальное работает
как пользовательские процессы (включая драйвера устройств).
> C>Так что проблема надежности уже давно решена. Остается проблема > скорости — в этом направлении сейчас тоже активно копают, можно почитать > ответы Таненбаума Линусу. Возможно, скоро Mac OS X станет первой > consumer-версией ОС с микроядром. > И как это спасет от внедрения вредоносного кода через переполнение буфера?
Делаем Code Access Security с гранулярностью равной процессу, и пусть
оно себе переполняет что хочет.
WolfHound wrote: > C>В fully managed OS типа Singularity в принципе не может быть unsafe. > В принципе они могут создавать песочници при помощи все тойже > виртуализации адресных пространств.
И для этой песочницы придется делать свою ОС (так как песочница должна
быть ПОЛНОСТЬЮ отделена от основной ОС). Вопрос: нафига козе баян?
Здравствуйте, Cyberax, Вы писали:
C>на 64-битных машинах с неатомарными 64-битными операциями. Для JVM даже такой эксплоит на Sparc'е был.
Мда... автор этой железки зажигает... а ты говоришь проверки в железе реализовать...
C>Да и вообще, ведь RC и дедлоки на многопоточных приложениях приводят к сложноуловимым ошибкам. Так что все обязаны использовать Erlang. Или ты любишь глючный софт?
Нет всем переходить под сингулирити. Там тоже общение через асинхронную посылку сообщений происходит.
C>Ты сам это сказал. Глючность программы зависит от вложенного труда.
Это отрицать также глупо как отрицать зависимость качества софта от инструмента на котором этот софт изготовлен.
C>Я тебе его показал.
Ты показал мааленький кусочек программы. Тут нужна оптимизация на архитектурном уровне. И той информации что ты дал совершенно не достаточно.
Примерно как в этом
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >> Можно как в C# сделать safe/unsafe mode, если люди захотят. C>Ты не понял. Singularity ВООБЩЕ запрещает unsafe. В любом его виде.
Регулятор safe/unsafe позволяет разделить код и, если надо будет портировать
на Managed OS, достаточно будет переписать только unsafe кусок
(который, если грамотно делать, будет небольшим).
Что видимо и будет происходить с C# приложениями при возможном переходе на fully managed OS.
>> C>Ну и как часто это надо? Я в своей практике не помню ни разу, когда >> C>такое понадобилось. >> Тем не менее, встроенный компилятор под рукой — удобно. C>Boost.Python, и ващи волосы будут мягкими и щелковистыми.
Ну и что умеет компилировать boost.python ?
Он позволяет писать скрипты, использующие C++ классы/функции, это другое.
Да и то придется работать со всякими PyObject.
Для примера можешь привести реализацию того примера на boost.python
с временными характеристиками, было бы интересно.
>> C>Сингулярити не позволяет НАПРЯМУЮ использовать: >> C>1. Машинный код и языки компилирующие в него. >> Много языков уже перевели на .NET. C>И все они изоморфны C# или сделаны через полную Ж.
Насколько я знаю IronPython тормозит по сравнению с нативным
(и тем более Psyco), значит (пока ?) да.
Может люди знающие что-нибудь скажут про F# (суть OCaml) и про другие?
WolfHound,
C>>Где он safe??? В нем же есть race condition'ы!!! Все надо писать C>>исключительно на Erlang — там RC нет. WH>Осталось понять как RC может испортить память.
RC — это пример логической ошибки. Никакой рантайм не спасёт от логических ошибок.
Я приведу простейший пример:
drawRect(100, 200, 300, 400); // вызывается эта функция, но что же нарисуется?
//
drawRect(int x, int y, int w, int h);
drawRect(int x0, int y0, int x1, int y1);
drawRect(int x0, int x1, int y0, int y1);
Результат будет только в одном случае правильным.
Если же состояние системы меняется по труднопредсказуемому закону, то и получится что количество логических ошибок будет возрастать экспоненциально.
Ну и на последок вишенка на тортике: для сложных систем существует закон "сложную систему невозможно формализовать полностью". А это значит, что соотношение N(LE)/N(RE) будет стремиться к бесконечности в любом рантайме.
PS: Плюс Киберакс писал, что N(RE) можно сколь угодно приблизить к нулю с помощью современных средств разработки и отладки.
Здравствуйте, Cyberax, Вы писали:
C>И для этой песочницы придется делать свою ОС (так как песочница должна быть ПОЛНОСТЬЮ отделена от основной ОС). Вопрос: нафига козе баян?
А вот это уже не факт. Все что нужно это обеспечить поддержку типизированных каналов.
Да по сраврению с чистой управляемой ОС придется несколько усложнить менеджер памяти и систему управления потоками. Но писать ОС с нуля ненужно.
Общение между песочнецой и другими процессами будет конечно несколько медленней чем эти процессы общаются между собой но это плата за нативный код.
Кстати напомни мне зачем нужен низкоуровневый код? Покачто все сводилось к числодробилкам.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>В QNX в нулевом кольце выполняется около 100Кб кода. Его можно под микроскопом посмотреть и доказать корректность — все остальное работает как пользовательские процессы (включая драйвера устройств).
Атаковать само ядро не обязательно.
C>Делаем Code Access Security с гранулярностью равной процессу, и пусть оно себе переполняет что хочет.
Ну оно и в современных ос так только вто что-то вирусам на это начхать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Андрей Хропов wrote: >> > Можно как в C# сделать safe/unsafe mode, если люди захотят. > C>Ты не понял. Singularity *ВООБЩЕ* запрещает unsafe. В любом его виде. > Регулятор safe/unsafe позволяет разделить код и, если надо будет портировать > на Managed OS, достаточно будет переписать только unsafe кусок > (который, если грамотно делать, будет небольшим). > Что видимо и будет происходить с C# приложениями при возможном переходе > на fully managed OS.
А что будет с С++-приложениями? Или с вполне безопасными Python и
Ruby-приложениями, для которых нет нормальных интерпретаторов под .NET?
> C>Boost.Python, и ващи волосы будут мягкими и щелковистыми. > Ну и что умеет компилировать boost.python ?
Он умеет запускать скрипты.
> Он позволяет писать скрипты, использующие C++ классы/функции, это другое. > Да и то придется работать со всякими PyObject.
Вот из примера:
// A friendly class.class hello
{
public:
hello(const std::string& country) { this->country = country; }
std::string greet() const { return"Hello from " + country; }
private:
std::string country;
};
// A function taking a hello object as an argument.
std::string invite(const hello& w) {
return w.greet() + "! Please come soon!";
}
...
BOOST_PYTHON_MODULE(getting_started2)
{
using namespace boost::python;
class_<hello>("hello", init<std::string>())
// Add a regular member function.
.def("greet", &hello::greet)
// Add invite() as a member of hello!
.def("invite", invite)
;
// Also add invite() as a regular function to the module.
def("invite", invite);
}
Основные классы не затрагиваются, обертка для Python абсолютно
неинтрузивная (и может быть сгенерирована автоматически с помощью Pyste).
Я могу создать нужный мне код в виде скрипты на Python, экспортировать в
него нужные мне объекты и запускать его. Так поступает CivIV, например.
> Для примера можешь привести реализацию того примера на boost.python > с временными характеристиками, было бы интересно.
А зачем?
> C>И все они изоморфны C# или сделаны через полную Ж. > Насколько я знаю IronPython тормозит по сравнению с нативным > (и тем более Psyco), значит (пока ?) да. > Может люди знающие что-нибудь скажут про F# (суть OCaml) и про другие?
F# работает быстро, но вот Haskell даже портировать не пытаются. На CLR
вообще нельзя эффективно делать динамические языки (например, если
JITить код из динамического языка в CLR, то можно очень быстро занять
всю память — так как код не собирается GC).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ну и на последок вишенка на тортике: для сложных систем существует закон "сложную систему невозможно формализовать полностью". А это значит, что соотношение N(LE)/N(RE) будет стремиться к бесконечности в любом рантайме.
С этим спорить также глупо как спорить с тем что при плохом рантайме система будет стремится к неуправляемому состоянию гораздо быстрее.
Ксати что за магия:N(LE)/N(RE)?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>И для этой песочницы придется делать свою ОС (так как песочница должна > быть ПОЛНОСТЬЮ отделена от основной ОС). Вопрос: нафига козе баян? > А вот это уже не факт. Все что нужно это обеспечить поддержку > типизированных каналов.
Для кода в песочнице надо обеспечить:
1. Виртуальную память.
2. Сервисы ОС (ФС, сеть, звук и т.п.)
То есть, фактически надо написать еще одну ОС, причем с полной защитой
памяти.
Спрашивается, а зачем тогда Fully Managed OS, если можно приложения на
C# запускать внутри одной разделяемой VM, работающей как приложение в
Unmanaged OS?
Здравствуйте, Cyberax, Вы писали:
C>F# работает быстро, но вот Haskell даже портировать не пытаются. На CLR вообще нельзя эффективно делать динамические языки (например, если JITить код из динамического языка в CLR, то можно очень быстро занять всю память — так как код не собирается GC).
Во втором фреймворке это не так. См System.Reflection.Emit.DynamicMethod.
К томуже как на основе косяков CLR можно делать выводы об управляемых ОС вобще?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Делаем Code Access Security с гранулярностью равной процессу, и пусть > оно себе переполняет что хочет. > Ну оно и в современных ос так только вто что-то вирусам на это начхать.
Вообще-то вирусы беспокоят практически эксклюзивно пользователей Винды
Lazy Cjow Rhrr,
LCR>>Ну и на последок вишенка на тортике: для сложных систем существует закон "сложную систему невозможно формализовать полностью". А это значит, что соотношение N(LE)/N(RE) будет стремиться к бесконечности в любом рантайме. WH>С этим спорить также глупо как спорить с тем что при плохом рантайме система будет стремится к неуправляемому состоянию гораздо быстрее.
Быстрее, да. Вот только "гораздость" под вопросом... Ладно, неважно.
WH>Ксати что за магия:N(LE)/N(RE)?
N — некоторая функция измеряющая ошибки. Пропорциональна количеству, но также и зависит от вида ошибок, LE — множество логических ошибок, RE — множество рантайм ошибок.
Здравствуйте, Cyberax, Вы писали:
C>Для кода в песочнице надо обеспечить: C>1. Виртуальную память.
На современном железе ее по любому обеспечивать придется. C>2. Сервисы ОС (ФС, сеть, звук и т.п.)
Нет. Нужно только обеспечить работу каналов. Прочитай еще раз про сингулярити... там ФС, сеть, звук и вобщемто все остальное доступно исключительно через типизированные каналы. Следовательно если обеспечить работу каналов все это становится доступно.
C>То есть, фактически надо написать еще одну ОС, причем с полной защитой памяти.
Не придется.
C>Спрашивается, а зачем тогда Fully Managed OS, если можно приложения на C# запускать внутри одной разделяемой VM, работающей как приложение в Unmanaged OS?
За тем что как я показал выше писать вторую ОС не нужно. А приложения которым действительно нужен нативный код являются очень редким видом. Болие того разумным сценарием будет написание всего что можно на управляемом коде и вынос числодробилок в дочерний процесс.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Можно. Только ОС должна быть управляемая. Например Singularity очень близка к идеалу. Там таких ошибок быть не может по тому что их не может быть в принципе. Ибо в это ОС большей части ядра и всем драйверам запрещено использовать неверфифицируемый код. WH>Те ошибка может быть только в маленькой части ядра или в кодогенераторе. И то и другое реально отладить ибо это относительно небольшой объем кода.
К сожалению подобная верификация кода проблемы не решает. Так как вообще никакого исполняемого кода на машину не принимается.
Все представляется так, как будто принимается обычное сообщение по некоторому прикладному протоколу (например текстовому SMTP). Обработка этого сообщения приводит к неестественному поведению самого сервера. С точки зрения ОС все в норме: приняли запрос сохранили файлик, приняли другой запрос, опять таки сохранили. ОС и знать не знает, что это "приполз" черьвь, подгрузил свой "хвост" и уже свои копии сохраняет. После чего он безпрепятственно будет работать от имени этого сервера.
Кстати, частично (опять таки!) проблему можно решить запретив ОС исполнять код в стековом сегменте. Но эту возможность порой используют вполне нормальные программы
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >>> > Можно как в C# сделать safe/unsafe mode, если люди захотят. >> C>Ты не понял. Singularity *ВООБЩЕ* запрещает unsafe. В любом его виде. >> Регулятор safe/unsafe позволяет разделить код и, если надо будет портировать >> на Managed OS, достаточно будет переписать только unsafe кусок >> (который, если грамотно делать, будет небольшим). >> Что видимо и будет происходить с C# приложениями при возможном переходе >> на fully managed OS. C>А что будет с С++-приложениями?
Да, с этим тяжело.
C> Или с вполне безопасными Python и C>Ruby-приложениями, для которых нет нормальных интерпретаторов под .NET?
Я думаю IronPython доделают. Не зря ж MS их нанял .
Ну и с Ruby принципиальных проблем быть не должно
(хотя я с ним вообще не знаком, так что мне трудно судить).
>> Для примера можешь привести реализацию того примера на boost.python >> с временными характеристиками, было бы интересно. C>А зачем?
А затем, что в том случае Влад показал, что взасчет того, что было легко сгенерировать код по описанию функции был достигнут значительный прирост в скорости.
Я не увидел, как с помощью boost.python можно сделать аналогично.
Здравствуйте, Cyberax, Вы писали:
C>Вообще-то вирусы беспокоят практически эксклюзивно пользователей Винды
По тому что винды очень много и под нее выгодно писать вирусы.
В прочем меня они не беспокоят... правда исключительно из-за того что outpost и касперский работают не выключаясь.
C>CAS, кстати, в современных консумерских ОСах нет.
Хм... винда например очень не плохо следит за правами приложений. Ну и что что права вешают на пользователя. Кто мешает завести по пользователю на приложение?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
MS>Ну хорошо. Вот у нас все-все сэйфее некуда. Что я делаю — беру динамический конртейнер и начинаю память кушать тоннами, пока система не окажется в глубокой свопе.
...
ЭЭэээ... Простите, а как Ваша программа попадет на удаленный компьютер? А если даже и попадет кто ей передаст управление? Ошибки переполнения буфера как раз таки позволяют это сделать. Вот когда научитесь исполнять свой код на удаленном компе тогда и память кушайте и руткиты устанавливайте и все на что фантазии и прав хватит.
Здравствуйте, dimon0981, Вы писали:
D>К сожалению подобная верификация кода проблемы не решает. Так как вообще никакого исполняемого кода на машину не принимается. D>Все представляется так, как будто принимается обычное сообщение по некоторому прикладному протоколу (например текстовому SMTP). Обработка этого сообщения приводит к неестественному поведению самого сервера. С точки зрения ОС все в норме: приняли запрос сохранили файлик, приняли другой запрос, опять таки сохранили. ОС и знать не знает, что это "приполз" черьвь, подгрузил свой "хвост" и уже свои копии сохраняет. После чего он безпрепятственно будет работать от имени этого сервера.
ОС управляемая. Процессы запечатанные. SMTP не может запускать новые процессы.
И что и куда подгрузил червь?
D>Кстати, частично (опять таки!) проблему можно решить запретив ОС исполнять код в стековом сегменте.
И как защитится от исправления идреса возврата в стеке? Код не выполняется вот только легче от этого не становится. D>Но эту возможность порой используют вполне нормальные программы
За это авторов нужно от программирования отлучать. Навсегда.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Считается правильным использовать функции StringCchPrintf, или StringCbPrintf, остальные функции считаются depricated и на них MSVC2005 не двусмысленно ругается
WolfHound wrote: > D>Кстати, частично (опять таки!) проблему можно решить запретив ОС > исполнять код в стековом сегменте. > И как защитится от исправления идреса возврата в стеке?
Есть такая замечательная штука — NX-bit.
WolfHound wrote: > D>Кстати, частично (опять таки!) проблему можно решить запретив ОС > исполнять код в стековом сегменте. > И как защитится от исправления идреса возврата в стеке?
Есть такая замечательная штука — NX-bit.
> Код не выполняется вот только легче от этого не становится. > D>Но эту возможность порой используют вполне нормальные программы > За это авторов нужно от программирования отлучать. Навсегда.
Точно! Мааачить программистов CLR VM! (там это тоже используется).
WolfHound wrote: > C>Вообще-то вирусы беспокоят практически эксклюзивно пользователей Винды > По тому что винды очень много и под нее выгодно писать вирусы. > В прочем меня они не беспокоят... правда исключительно из-за того что > outpost и касперский работают не выключаясь.
А вот у меня вообще нет (не было и не будет) никаких резидентных
антивирусов. Так как это мастдай.
> C>CAS, кстати, в современных консумерских ОСах нет. > Хм... винда например очень не плохо следит за правами приложений. Ну и > что что права вешают на пользователя. Кто мешает завести по пользователю > на приложение?
CAS означает ограничение доступа по определенным путям в коде. Например,
текстовый редактор может иметь полный доступ ко всем файлам (с учетом
прав, естественно), но получать новые handle'ы может только через диалог
открытия файлов.
WolfHound wrote: > Во втором фреймворке это не так. См System.Reflection.Emit.DynamicMethod.
Только для отдельнных методов. Сборки так до сих пор и не собираются.
> К томуже как на основе косяков CLR можно делать выводы об управляемых ОС > вобще?
Ладно, ладно. Тут я не прав.
Здравствуйте, Cyberax, Вы писали:
C>А вот у меня вообще нет (не было и не будет) никаких резидентных антивирусов. Так как это мастдай.
Это уже религия пошла.
C>CAS означает ограничение доступа по определенным путям в коде. Например, C>текстовый редактор может иметь полный доступ ко всем файлам (с учетом C>прав, естественно), но получать новые handle'ы может только через диалог C>открытия файлов.
Либо хендлы только через диалог открытия файла либо выделеное.
Делаем Code Access Security с гранулярностью равной процессу, и пусть оно себе переполняет что хочет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Есть такая замечательная штука — NX-bit.
Как это спасает от изменения адреса возврата?
C>Точно! Мааачить программистов CLR VM! (там это тоже используется).
А где я говорил что CLR идеальна?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Для кода в песочнице надо обеспечить: > C>1. Виртуальную память. > На современном железе ее по любому обеспечивать придется.
А тогда пропадут многие преимущества Fully Managed OS, работающей в
плоской памяти.
> C>2. Сервисы ОС (ФС, сеть, звук и т.п.) > Нет. Нужно только обеспечить работу каналов. Прочитай еще раз про > сингулярити... там ФС, сеть, звук и вобщемто все остальное доступно > исключительно через типизированные каналы. Следовательно если обеспечить > работу каналов все это становится доступно.
Ну так по сути драйвера современных ОС — это просто драйвера для
"каналов". Но только это не делает их проще.
Подумай, например, как ты будешь реализовывать каналы для показа
HDTV-видео или передачи информации в видеокарту из Doom3.
> За тем что как я показал выше писать вторую ОС не нужно.
Нужно. Например, что произойдет, если одно виртуальное приложение решит
запустить другое? А как насчет динамической подгрузки модулей?
> А приложения > которым действительно нужен нативный код являются очень редким видом.
Сейчас это 99% (если не больше) всех приложений. Чтобы произошел переход
на Managed OS это число должно быть близко к 0.
Спрашивается, а нафига кому-то надо с ноля переписывать работающие
системы, чтобы в светлом будущем можно было сделать не особо нужную
Managed OS?
Вот сейчас реально есть IPv6, который уже используется в backbone-сетях
Интернета и поддерживается практически во всех OS (плевать, что в
некоторых ОСях только через командную строку). Почему все еще не перешли
на правильный и красивый IPv6?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, dimon0981, Вы писали:
D>>К сожалению подобная верификация кода проблемы не решает. Так как вообще никакого исполняемого кода на машину не принимается. D>>Все представляется так, как будто принимается обычное сообщение по некоторому прикладному протоколу (например текстовому SMTP). Обработка этого сообщения приводит к неестественному поведению самого сервера. С точки зрения ОС все в норме: приняли запрос сохранили файлик, приняли другой запрос, опять таки сохранили. ОС и знать не знает, что это "приполз" черьвь, подгрузил свой "хвост" и уже свои копии сохраняет. После чего он безпрепятственно будет работать от имени этого сервера. WH>ОС управляемая. Процессы запечатанные. SMTP не может запускать новые процессы.
SMTP — запускать процессы не может, он вообще протокол. А вот SMTP сервер может (это относится к подавляющему большенству распространненых SMTP серверов).
WH>И что и куда подгрузил червь?
В первом запросе свою небольшую часть. А после передачи ей управления подгрузил остальную. Они все так делают.
D>>Кстати, частично (опять таки!) проблему можно решить запретив ОС исполнять код в стековом сегменте. WH>И как защитится от исправления идреса возврата в стеке? Код не выполняется вот только легче от этого не становится. D>>Но эту возможность порой используют вполне нормальные программы WH>За это авторов нужно от программирования отлучать. Навсегда.
Этой возможностью пользуются все современные оптимизирующие компиляторы во время "агресивной оптимизации".
WolfHound wrote: > C>А вот у меня вообще нет (не было и не будет) никаких резидентных > антивирусов. Так как это мастдай. > Это уже религия пошла.
Думаешь я скажу, что у меня Линукс?
> C>CAS означает ограничение доступа по определенным путям в коде. Например, > C>текстовый редактор может иметь полный доступ ко всем файлам (с учетом > C>прав, естественно), но получать новые handle'ы может только через диалог > C>открытия файлов. > Либо хендлы только через диалог открытия файла либо выделеное.
С чего бы? Скажем, в микроядерных ОС это делается элементарно — просто
ставится фильтр на сообщения в сервер файловой системы так, чтобы
сообщения могли отсылаться только из сервера стандартных диалогов.
В монолитных ОС это уже сложнее, но все равно возможно.
> Делаем Code Access Security с *гранулярностью равной процессу*, и пусть > оно себе переполняет что хочет.
Это означает, что фильтры в CAS работают с гранулярностью равной
процессу (а не потоку, например).
WolfHound wrote: > C>Есть такая замечательная штука — NX-bit. > Как это спасает от изменения адреса возврата?
А куда пихать код эксплоита? Ну динамическую память тоже ставится
NX-bit, а статические буфферы — в сегменте стека (и тоже NX).
В принципе, изредка остается еще ниндзя-трюк jump-to-library, но и от
него можно защититься.
> C>Точно! Мааачить программистов CLR VM! (там это тоже используется). > А где я говорил что CLR идеальна?
Это как раз пример того, что хакерские техники иногда нужны и важны.
Здравствуйте, Cyberax, Вы писали:
C>А тогда пропадут многие преимущества Fully Managed OS, работающей в плоской памяти.
А как плоская память отменяет виртуальную? Вот у меня на машине есть всего гиг физической. В вот адресного пространства за счет этой самой виртуально памяти 4 гига.
C>Ну так по сути драйвера современных ОС — это просто драйвера для "каналов". Но только это не делает их проще.
Ну вот они и будут работать в управляемом коде. В чем проблема то?
C>Подумай, например, как ты будешь реализовывать каналы для показа HDTV-видео или передачи информации в видеокарту из Doom3.
shared memory уже отменили? Читай как в сингулярити передают большие объемы данных через каналы.
>> За тем что как я показал выше писать вторую ОС не нужно. C>Нужно. Например, что произойдет, если одно виртуальное приложение решит запустить другое?
Обратится через специальный канал к ОС или другому процессу. C>А как насчет динамической подгрузки модулей?
А с этим то какая проблема?
C>Сейчас это 99% (если не больше) всех приложений. Чтобы произошел переход на Managed OS это число должно быть близко к 0.
Дело в том что эти приложения просто так реализованы. Большей части из них нитивный код или даже unsafe нафиг не упал.
C>Спрашивается, а нафига кому-то надо с ноля переписывать работающие системы, чтобы в светлом будущем можно было сделать не особо нужную Managed OS?
Совершенно не согласен.
И на то есть два убойных аргумента:
1)Надежность.
2)Независимость от железа.
C>Вот сейчас реально есть IPv6, который уже используется в backbone-сетях Интернета и поддерживается практически во всех OS (плевать, что в некоторых ОСях только через командную строку). Почему все еще не перешли на правильный и красивый IPv6?
Я не в теме.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>А куда пихать код эксплоита? Ну динамическую память тоже ставится NX-bit, а статические буфферы — в сегменте стека (и тоже NX).
Придумают.
C>В принципе, изредка остается еще ниндзя-трюк jump-to-library, но и от него можно защититься.
Ну вот ты уже и придумал.
C>Это как раз пример того, что хакерские техники иногда нужны и важны.
Глубоко в ядре. В реальном коде ниразу нужно небыло.
Кстати, а зачем это в CLR?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, dimon0981, Вы писали:
D>SMTP — запускать процессы не может, он вообще протокол. А вот SMTP сервер может (это относится к подавляющему большенству распространненых SMTP серверов).
Козе понятно что сервер. Вот только зачем ему запускать другие процессы?
WH>>И что и куда подгрузил червь? D>В первом запросе свою небольшую часть. А после передачи ей управления подгрузил остальную. Они все так делают.
Еще раз как в управляемой ОС где теоритически не может быть всяких там переполнений буфера этот код получит управление?
D>Этой возможностью пользуются все современные оптимизирующие компиляторы во время "агресивной оптимизации".
ЧЕГО? Зачем нужно класть код в стек? Ниразу не видел чтобы оптимизаторы это делали.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>ОС со стабильной работой даже в присутствие _аппаратных_ сбоев уже лет C>30 существуют.
Ага. Эрланг называется. Причем пашет даже под Виндовс.
C>Защита достигается разделением и максимальной изоляцией всего, что C>только разделяется и изолируется. В качестве примера я уже приводил QNX C>- его используют на ядерных электростанциях, а его ядро представляет из C>себя небольшой кусок кода.
QNX не дает надежности. Это ведь ОС реального времени, а не безопасная ОС. Любой кривой указатель введет из строя любое приложение QNX. В этом отношении QNX ни чем не отличаетсяот Виндовс или Линукса.
Апаратная защита адрессного пространства процесса позволяет только лишь упростить выявление ошибок в некоторых случаях.
Сингулярити же гарантирует от ошибок связанных с нарушением типизации. Ее инсталляторы просто не пропустят небезопасный код.
Ну, а в остальном это та самая микроядерная ОС только без оверхэда на межпроцессное взаимодействие. В отличии от QNX в Сингулярити без проблем можно загружать компоненты одного приложения в разные процессы.
C>Так что проблема надежности уже давно решена.
Языком в основном... к сожалению.
C> Остается проблема скорости C> — в этом направлении сейчас тоже активно копают, можно почитать ответы C>Таненбаума Линусу. Возможно, скоро Mac OS X станет первой C>consumer-версией ОС с микроядром.
Еще раз. Микроядерность сама по себе не решает проблему надежности. А вот типобезопасть как класс устраняет ряд трудновыяляемых ошибок и действительно повышает надежность. Правда тоже не устраняет саму проблему.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и работает стабильно.
Не, будет по другому. Появилось одно приложение, а конкуренты на С++ пытаются зарелизить свой багодром временами урывая минутку чтобы потрепаться о Ди в этом форуме.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>К чему это перечисление? Я имел ввиду, что появляется дополнительное звено между языком высокого уровня и железом. Понятно, что раз появляется, то у него есть какая-то функциональность.
Здравствуйте, Cyberax, Вы писали:
C>Лично в моем проекте такие ошибки не создают ну абсолютно никаких проблем.
И тебе — тоже цитата.
Самые лучшие программисты — это те, кто осознают ограниченность своих возможностей. В то же время худшие программисты твердо убеждены в своей непогрешимости и безошибочности. (С)
Здравствуйте, Дарней, Вы писали:
ГВ>>К чему это перечисление? Я имел ввиду, что появляется дополнительное звено между языком высокого уровня и железом. Понятно, что раз появляется, то у него есть какая-то функциональность. Д>появляется. и что?
Да нет, ничего. Только веселья добавится. Будет N железок и M платформ уровня виртуальной машины + K платформ класса операционных систем. Плюрализм, однако.
<< Под музыку: Inti-Illimani — Vuelvo >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да нет, ничего. Только веселья добавится. Будет N железок и M платформ уровня виртуальной машины + K платформ класса операционных систем. Плюрализм, однако.
Лезть внутрь тебя никто не заставляет. Уровни абстракции для того и придуманы, чтобы скрывать особенности нижележащих уровней.
Здравствуйте, Дарней, Вы писали:
ГВ>>Да нет, ничего. Только веселья добавится. Будет N железок и M платформ уровня виртуальной машины + K платформ класса операционных систем. Плюрализм, однако.
Д>Лезть внутрь тебя никто не заставляет. Уровни абстракции для того и придуманы, чтобы скрывать особенности нижележащих уровней.
Понимаешь ли, я всего лишь опубликовал своё наблюдение. По сути, это был комментарий к характеристике разработки Singularity, как к "очень верному направлению". А я намекнул, что этих "очень верных" направлений окажется великое множество. Ну, может быть, не великое. Не больше десятка.
<< Под музыку: Inkuyo — San Juanito De Medianoche >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Практика показывает, что изолировать машину от внешнего кода можно только в тепличных условиях типа АЭС или МКС. Во всех остальных случаях даже ломать не надо — "сами все предложат и сами все дадут", (с) Булгаков.
...
S>Основные пути проникновения вредоносного кода: S>- программы, запускающие внешний код: S>-- Мэйлеры и браузеры, рискующие делать глупости типа запуска превью для приехавших данных S>-- средства автоматизации, исполняющие скрипты VBA S>- дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер S>- развод лохов на запуск аттачментов с вирусами
Ага, с этим не поспоришь. Вот только тема нашего разговора несколько ограничена тематикой Safe VS Unsafe. В рамках которой имеет смысл обсуждение лишь одной проблемы "дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер".
Здравствуйте, dimon0981, Вы писали: D>Ага, с этим не поспоришь. Вот только тема нашего разговора несколько ограничена тематикой Safe VS Unsafe. В рамках которой имеет смысл обсуждение лишь одной проблемы "дыры в программах, которые в общем-то не хотели запускать чужой код, но им переполнили буфер".
Совершенно верно. Потому, что CAS — это уже managed vs unmanaged. Каюсь, извиняюсь за оффтоп. Караю себя недельным баном начиная с 28 числа. Заодно и в командировку скатаюсь.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
FR>Нет пока стороники C# тут рекламируют N (они бедняги на C# писать уже не хотят, а на N пока не могут) уже выходит второй релиз программы на C++
Здравствуйте, dimon0981, Вы писали:
D>Убедил. Давай сюда эту самую управляемую ОС — Singularity . Где ее можно скачать/купить? Надеюсь она обеспечит мне и пользователям моего софта чувство защищенности и массу других обещаемых "вкусностей".
To be run, a piece of code must be added to the system by the Singularity installer.
...
In the current implementation the entire installation process takes place offline with an installation becoming visible only at the next system boot. This purely off-line installation may be trivially augmented with on-line installation, but on-line installation has not yet been required by our usage scenarios.
Насколько я это понимаю, одна из "вкусностей" — разработка методом edit-compile-install-reboot-test.
To be run, a piece of code must be added to the system by the Singularity installer.
Т>...
Т>In the current implementation the entire installation process takes place offline with an installation becoming visible only at the next system boot. This purely off-line installation may be trivially augmented with on-line installation, but on-line installation has not yet been required by our usage scenarios.
Т>Насколько я это понимаю, одна из "вкусностей" — разработка методом edit-compile-install-reboot-test.
Обрати внимание на выделеное.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Нет пока стороники C# тут рекламируют N (они бедняги на C# писать уже не хотят, а на N пока не могут) уже выходит второй релиз программы на C++
VD>Языком он выходит. А "сторнники" давно и плодотворно работают.
"Интеграция Nemerle и Visual Studio" это конечно хорошо, но тут разговор идет о конечных продуктах сделанных с использованием соответствующих технологий.
насчёт strncpy и strcpy взад В том плане, что в VS 2005 strncpy точно так же deprecated как и strcpy. Но насчёт того чтобы юзать везде (практически везде, кроме тех мест где считают каждый такт) strncpy вместо strcpy — насчёт этого не откажусь никогда
Здравствуйте, FR, Вы писали:
VD>>Языком он выходит. А "сторнники" давно и плодотворно работают.
FR>"Интеграция Nemerle и Visual Studio" это конечно хорошо, но тут разговор идет о конечных продуктах сделанных с использованием соответствующих технологий.
Ты меня извини, но ваших конечных продуктов никто и в глаза не видел, а наши может не супер конечные, но есть, их можно загрузить и потрогать. Так что кто тут лясы точет, а кто дело занимается даже осбуждать не смешно.
Что до C#, то вспомним Янус. Уж как его тут не ругали... Но он есть и работает. А планы по созданию крутого межплатформного С++-варианта так и остались трепом.
Так что факты на лицо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>F# работает быстро, но вот Haskell даже портировать не пытаются. На CLR C>вообще нельзя эффективно делать динамические языки (например, если C>JITить код из динамического языка в CLR, то можно очень быстро занять C>всю память — так как код не собирается GC).
Гулупость полнейшая.
1. Haskell статически типизированный язык.
2. С динамическими вызовами в дотнете не хуже чем в любом другом месте.
Единственное, что ожет немного огорчать разработчиков ФЯ — это оврехэд по памяти в 12 байт на каждый объект. Для связанных списков это нескольно избыточно. Но тому же Nemerle это как-то не сильно мешает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
VD>>>Языком он выходит. А "сторнники" давно и плодотворно работают.
FR>>"Интеграция Nemerle и Visual Studio" это конечно хорошо, но тут разговор идет о конечных продуктах сделанных с использованием соответствующих технологий.
VD>Ты меня извини, но ваших конечных продуктов никто и в глаза не видел, а наши может не супер конечные, но есть, их можно загрузить и потрогать. Так что кто тут лясы точет, а кто дело занимается даже осбуждать не смешно.
Конечно, куда уж нам убогим.
VD>Что до C#, то вспомним Янус. Уж как его тут не ругали... Но он есть и работает. А планы по созданию крутого межплатформного С++-варианта так и остались трепом.
Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой несколько дней назад.
Здравствуйте, FR, Вы писали:
VD>>Ты меня извини, но ваших конечных продуктов никто и в глаза не видел, а наши может не супер конечные, но есть, их можно загрузить и потрогать. Так что кто тут лясы точет, а кто дело занимается даже осбуждать не смешно.
FR>Конечно, куда уж нам убогим.
А что? На что-то можно посмотретиь?
FR>Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой несколько дней назад.
Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о котором так долго чесали лясы меньшивики.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>... А вот типобезопасть как класс устраняет ряд трудновыяляемых ошибок и действительно повышает надежность. Правда тоже не устраняет саму проблему.
Есть такая поговорка — "если это не решает проблему, значит оно её создает"
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
VD>>>Ты меня извини, но ваших конечных продуктов никто и в глаза не видел, а наши может не супер конечные, но есть, их можно загрузить и потрогать. Так что кто тут лясы точет, а кто дело занимается даже осбуждать не смешно.
FR>>Конечно, куда уж нам убогим.
VD>А что? На что-то можно посмотретиь?
У меня нет, я же только лясы точу
И еще ежиков опасаюсь
FR>>Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой несколько дней назад.
VD>Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о котором так долго чесали лясы меньшивики.
А я тут причем? У меня никогда не было планов написания ничего янусообразного
VladD2 wrote: > FR>Не надо про янус, не хочу ругатся, у меня тут он сдох вместе с базой > несколько дней назад. > Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о > котором так долго чесали лясы меньшивики.
Thunderbird + RSDN.NNTP
Здравствуйте, Cyberax, Вы писали:
>> Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о >> котором так долго чесали лясы меньшивики. C>Thunderbird + RSDN.NNTP
Как по-твоему на чем RSDN.NNTP написан? И почему не на С++?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> 1. Haskell статически типизированный язык. C>Он ленивый. В этом и проблема.
В этом никакой проблемы нет.
>> 2. С динамическими вызовами в дотнете не хуже чем в любом другом месте. C>Сравним Python и IronPython?
А что мне сравнивать лузеров? Я смотрю на Nemerle и проблем не замечаю, хотя списки там на право и на лево используются, а значит проблемы быть обязаны (по твоей логике).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: >> > Твоя ругать идет в /dev/null пока ты не представишь аналог на С++ о >> > котором так долго чесали лясы меньшивики. > C>Thunderbird + RSDN.NNTP > Как по-твоему на чем RSDN.NNTP написан? И почему не на С++?
Так хоть на COBOLе. Вроде бы я всегда говорил, что серверные задачи
прекрасно подходят для Java/C#.
VladD2 wrote: >> > 1. Haskell статически типизированный язык. > C>Он ленивый. В этом и проблема. > В этом никакой проблемы нет.
Есть. В машкоде можно использовать thunk'и для реализации отложенных
вычислений, а в CLR приходится использовать обычные if'ы.
Разница в скорости в разы.
>> > 2. С динамическими вызовами в дотнете не хуже чем в любом другом месте. > C>Сравним Python и IronPython? > А что мне сравнивать лузеров? Я смотрю на Nemerle и проблем не замечаю, > хотя списки там на право и на лево используются, а значит проблемы быть > обязаны (по твоей логике).
Динамические языки — это вовсе не те в которых есть списки.
Здравствуйте, Cyberax, Вы писали:
C>А знаешь почему они не создают проблем? Потому что я пишу так, что эти C>ошибки не могут появиться. Не доверяю я себе (так как каждый раз C>когда я хочу поиграть с битами, то потом всплывает ошибка)
"Не могут появиться" — это из раздела фантастики. Максимум, чего можно добиться — чтобы такие ошибки выявлялись сразу после их совершения. Да и это стоит немалых затрат труда.
Здравствуйте, Cyberax, Вы писали:
C>А знаешь почему они не создают проблем? Потому что я пишу так, что эти C>ошибки не могут появиться. Не доверяю я себе (так как каждый раз C>когда я хочу поиграть с битами, то потом всплывает ошибка)
Ну, вот ты и проговорился.
А знатете ли доверяю управляемой среде. Она позволяет мне не думать над вещами не относящимися к решаемой задаче. Я просто знаю, что ошибки второго и более порядка не будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Совсем поскипаным согласен.
L>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где нужно использовать небезопасные конструкции, а где нет.
А по-моему хорошего программиста отличает, то что ему практически не требуются опасные конструкции. Хотя конечно этого явно мало. Умение думать и взвешивать еще никто не отменял.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Left2, Вы писали:
VD>Совсем поскипаным согласен.
L>>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где нужно использовать небезопасные конструкции, а где нет.
VD>А по-моему хорошего программиста отличает, то что ему практически не требуются опасные конструкции. Хотя конечно этого явно мало. Умение думать и взвешивать еще никто не отменял.
Опасные конструкции хорошие программисты заворачивают в безопасные и эффективные типы данных. Иногда без этого не обойтись, а отказыватся от удобств в угоду моде смысла нет.
Здравствуйте, Kluev, Вы писали:
K>Опасные конструкции хорошие программисты заворачивают в безопасные и эффективные типы данных. Иногда без этого не обойтись, а отказыватся от удобств в угоду моде смысла нет.
Хороший программист не будет делать то что можно не делать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Left2, Вы писали:
PD>>Теоретически почти все небезопасно.
L>Нет, каждый вызов окружать не буду. Но буду писать так, чтобы вылетевший откуда угодно bad_alloc смог обработаться и при этом все созданные обьекты остались живы. Exception safe не значит что каждая строчка обёрнута try-catch, это заблуждение.
Последнее, конечно, верно, а первое — как сказать. Обычно память выделяют, чтобы тут же использовать.. Так что проверять именно там скорее всего и придется.
PD>>Создание объектов GDI/USER небезопасно — лимит на 10000 на процесс. Будете проверять каждый вызов CreatePen ?
L>Если отрисовка критически важна в этой программе — то да, буду. Заверну в обёртку и буду кидать exception если что-то обломалось.
А что, есть программы, в которых отрисовка не важна ?
А если дурной программист сюда вместо указателя LOGPEN передал бог знает что ? Для надежности здесь даже IsBadWritePtr мало будет. Да и вообще неясно, как это написать безопасно — он ведь мог и указатель на int передать и мы прямым ходом испортим память , быть может, даже без всякого AV.
PD>>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где можно использовать небезопасные конструкции, а где нет.
L>ИМХО хорошего программиста от плохого отличает в этом плане умение определить, где нужно использовать небезопасные конструкции, а где нет.
Хм... ИМХО все же "можно" вернее. Говоря "можно", я имею в виду, что ситуация, в общем-то, на 99.99% под контролем в плане уверенности , что здесь можно использовать небезопасный код без серьезных проблем.
А нужно его здесь использовать или нет — это уже другой вопрос. Если можно — не значит обязательно нужно. Но если "не можно" — то лучше не надо, даже если нужно
VladD2 wrote: > C>А знаешь почему они не создают проблем? Потому что я пишу так, что эти > C>ошибки не могут появиться. Не доверяю я себе (так как каждый раз > C>когда я хочу поиграть с битами, то потом всплывает ошибка) > Ну, вот ты и проговорился.
Ну так
Проблема в том, что часто такие битхаки дают мне очень неплохие
преимущества в скорости.
> А знатете ли доверяю управляемой среде. Она позволяет мне не думать над > вещами не относящимися к решаемой задаче. Я просто знаю, что ошибки > второго и более порядка не будет.
Меня они тоже не беспокоят
VladD2 wrote: > C>Проблема в том, что часто такие битхаки дают мне очень неплохие > C>преимущества в скорости. > Это илюзия. К тому же хаки можно делать и в управляемом мире. Ни ансэйф, > ни интероп никто не отменял.
Интероп сожрет больше времени на переключении managed/unmanaged. unsafe
в понятии C# весьма ограничен.
> Но я еще не разу не видел, чтобы в моей практике опасных хак дал > больше чем, просто грамотная оптимизация алгоритмов.
Я сейчас пишу интерпретатор языка Jam
(http://www.perforce.com/jam/jam.html) — так простая оптимизация с
хранением головной ноды списка непосредственно в объекте списка дала мне
30% прироста скорости. Алгоритмы (а они там очень простые) уже были
вылизаны до предела.
Делается это с помощью битхака:
class jam_list
{
union
{
char buf_[sizeof(jam_list_node)];
boost::type_with_alignment<boost::alignment_of<jam_list_node>::value>::type
align;
} saved_node_buf_;
...
};
То есть в объекте выделяется буффер для конструкции головного узла (так
как большинство списков имеют размер 0 или 1).
Или другой пример — аргументы фунукций в Jam представлены в виде
структуры list_of_lists (LOL ):
//This class implements a circular buffer used for function arguments.template<class T, std::size_t N>
class fixed_size_list
{
union
{
char buf_[N*sizeof(T)];
typename boost::type_with_alignment<
boost::alignment_of<T>::value>::type align;
} elems;
size_t size_;
size_t start_index_;
...
По сравнению со стандартными контейнерами мои оптимизированные и
захаканные контейнеры дают более чем трехкратный прирост скорости.
Здравствуйте, Cyberax, Вы писали:
C>Интероп сожрет больше времени на переключении managed/unmanaged.
А ты выноси в анменеджед весь критичный кусок.
C> unsafe C>в понятии C# весьма ограничен.
Это безответсвенные заявления.
C>(http://www.perforce.com/jam/jam.html) — так простая оптимизация с C>хранением головной ноды списка непосредственно в объекте списка дала мне C>30% прироста скорости. Алгоритмы (а они там очень простые) уже были C>вылизаны до предела.
А, ну, ну...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> C>ОС со стабильной работой даже в присутствие _аппаратных_ сбоев уже лет >> C>30 существуют. >> Ага. Эрланг называется. Причем пашет даже под Виндовс. C>Эрланг — это скорее просто интерпретируемый язык.
И среда выполнения реализующие вместе то о чем ты так мечтаешь.
>> QNX не дает надежности. Это ведь ОС реального времени, а не безопасная >> ОС. Любой кривой указатель введет из строя любое приложение QNX. В этом >> отношении QNX ни чем не отличаетсяот Виндовс или Линукса. C>Зато ...
Вспоминается отывок из фильма:
- Скажите Павел Андреевич- Вы шпион?!
— Видите ли Юра...
C>приложение ничего не сможет разрушить в своем окружении.
По сути в Виндовс НТ приожение так же не может ничего разрушить вне своего процесса.
C>По сути C>это и важно — после обращения по нулевой ссылке .NET-приложение тоже C>небезопасно использовать.
Ты кажется про ОС говорил? QNX то, QNX сё... QNX может и надежнее других РВ ОС, но не надежнее виндовс.
Мне по фигу из-за чего будет "глючить" реактор.
Что до дотнета, то он гарантирует целостность памяти, а стало быть есть возможность востановления после сбоя. Применяя некоторые методики и/или системы контроля можно добиться очень высокой степени надежности. Сингулярити ради этого и создавалась. Эта была цель эксперемента. Типобезопасность в ней только одна из возможностей.
>> Апаратная защита адрессного пространства процесса позволяет только лишь >> упростить выявление ошибок в некоторых случаях. C>А мягкая обработка исключений позволяет ошибки скрывать.
Понимаешь в чем дело. Одно дело когда речь идет о повреждении памяти и полном хаосе, а другое когда речь идет предотвращении/выявлении ошибок. Система допускающая неопределенные состаяния по определению не может быть надежной. Упоминавшися выше Эрланг в первую очередь дарантирует типобезопасность. И в добавок предоставляет возможность уропстить востановление после сбоекв (ведб критических сбоев быть не может).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>thunk — это не команда, а ассемблерный трюк. Он заключается в том, что C>вместо указателя на целевую функцию используется указатель на C>динамически сгенерированный блок кода.
Ну, и не надо тогда говорить про недостатки виртуальных машин. Твои thunk-и на фиг не упали для реализации нужной функциональности. То же самое можно реализовать на базе функциональных объетктов, генерации кода и кучи других вещей.
Хаскель медленен алгоритмически. И с этим ничего не поделаешь. В остальном противопоказаний для реализации его на VM нет. Конечно если бы были некторые конструкции, то работу можно было бы упростить, но не более того.
C>Этот блок кода может использоваться для разных целей: C>1. Например, в ATL он используется для обхода ограничений WinAPI C>(невозможность передачи контекста в оконную функцию).
Да, да. Видел я этот хак. Лет 8 назад я даже восхищался крутостью написашего это. Потом понял, что это некрутость, это выпендреж и мальчишество. Данное решение ровным счетом ничго не дает, за то завязывается на тонкие аспекты внутренней раализации работы Виндовс. Что по является грубейшей ошибкой.
C>2. В Win9x thunk'и использовались для прозрачных вызовов 32-битных C>библиотек из 16-битного кода.
Ненадо песен. Там просто переходники. Динамически там ничего не делается. Да и проблемы перехода с одного устарелого С-АПИ на другой меня не трогают.
C>3. В ленивых языках thunk'и могут использоваться для оптимизации ленивых C>вызовов и интероперирования.
Это все мертвому припарка. Реальное решение проблемы производительности ленивых языков — это переписывание кода компилятором. Ну, а вызов можно и через указатель сделать. "call регистр" еще никто не отменял.
>> C>Разница в скорости в разы. >> Тесты в студию, плиз, с выкладками и доказательствами корректности. C>Лень
VladD2 wrote: > C>вместо указателя на целевую функцию используется указатель на > C>динамически сгенерированный блок кода. > Ну, и не надо тогда говорить про недостатки виртуальных машин. Твои > thunk-и на фиг не упали для реализации нужной функциональности. То же > самое можно реализовать на базе функциональных объетктов, генерации кода > и кучи других вещей.
Нет, нельзя. Фактически нужна подмена кода в runtime — в .NET это
невозможно (без использования отладочных средств).
Собственно это и является фундаментальным недостатком управляемых сред —
если в VM нет нужного примитива, то его можно только эмулировать,
зачастую с гигантским оверхедом. На что апологеты VM отвечают обычно "а
нам это не нужно, все что может быть нам нужно в будущем уже сделали в VM".
> Хаскель медленен алгоритмически. И с этим ничего не поделаешь.
Ты согласишься работать на .NET VM, работающей в 5 раз медленнее текущей?
VladD2 wrote: >> > Ага. Эрланг называется. Причем пашет даже под Виндовс. > C>Эрланг — это скорее просто интерпретируемый язык. > И среда выполнения реализующие вместе то о чем ты так мечтаешь.
Ага, для меня это идеал надежности.
> C>приложение ничего не сможет разрушить в своем окружении. > По сути в Виндовс НТ приожение так же не может ничего разрушить вне > своего процесса.
Ну да. Осталось только сделать создание процессов и межроцессные
коммуникации на порядок быстрее.
> Что до дотнета, то он гарантирует целостность памяти, а стало быть есть > возможность востановления после сбоя. Применяя некоторые методики и/или > системы контроля можно добиться очень высокой степени надежности.
Только вот эти "методики" не включают в себя try-catch в очереди
событий. Они включают в себя создание контролируемого окружения и
возможность его отката в случае ошибки.
В классических ОС то же самое делается с помощью (сюрприз!) процессов.
> Понимаешь в чем дело. Одно дело когда речь идет о повреждении памяти и > полном хаосе, а другое когда речь идет предотвращении/выявлении ошибок. > Система допускающая неопределенные состаяния по определению не может > быть надежной.
Нештатный exception — это уже неопределенное состояние. Единственная
верная реакция на него — выбросить все окружение, которое могло привести
к ошибке. В ОС в этих случаях просто прибивают процесс (и запускают
новый если надо).
VladD2 wrote: > C>Интероп сожрет больше времени на переключении managed/unmanaged. > А ты выноси в анменеджед весь критичный кусок.
Я это и делаю — то есть пишу на С++
Вот к примеру, в текущем интерпретаторе работа со списками и переменными
является критически важной частью, НО не локализована в одном месте.
> C> unsafe в понятии C# весьма ограничен. > Это безответсвенные заявления.
Почему? Фактически все что я получаю — это адресная арифметика.
Генерировать код в рантайме, играть со стеком (alloca), и т.п. я не могу.
> C>(http://www.perforce.com/jam/jam.html) — так простая оптимизация с > C>хранением головной ноды списка непосредственно в объекте списка дала мне > C>30% прироста скорости. Алгоритмы (а они там очень простые) уже были > C>вылизаны до предела. > А, ну, ну...
Можешь взять исходники: http://elewise.com/pubrepos/BuildPort/trunk/ и
посмотреть.
Здравствуйте, Cyberax, Вы писали:
C>Нештатный exception — это уже неопределенное состояние.
Вот только как в тойже винде гарантированно засечь то что в процессе что-то пошло не так из-за вахода за приделы массива?
Короче в С++ у нас UB, а в управляемой среде вполне себе определенное поведение... вылет исключения.
C>Единственная верная реакция на него — выбросить все окружение, которое могло привести к ошибке.
В управляемом приложении в таких случаях при правильном проектировании достаточно снести небольшую часть окружения.
C>В ОС в этих случаях просто прибивают процесс (и запускают новый если надо).
Это если AV таки произошло. А если нет?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>А куда пихать код эксплоита? Ну динамическую память тоже ставится > NX-bit, а статические буфферы — в сегменте стека (и тоже NX). > Придумают.
Не придумают. Эксплоиты с переполнением буфферов на нормальных
архитектурах не работают.
> C>В принципе, изредка остается еще ниндзя-трюк jump-to-library, но и от > него можно защититься. > Ну вот ты уже и придумал.
Эта дырка тоже закрывается.
> C>Это как раз пример того, что хакерские техники иногда нужны и важны. > Глубоко в ядре. В реальном коде ниразу нужно небыло. > Кстати, а зачем это в CLR?
Чтобы написать что-то типа CLR.
Здравствуйте, Cyberax, Вы писали:
>> C> unsafe в понятии C# весьма ограничен. >> Это безответсвенные заявления. C>Почему? Фактически все что я получаю — это адресная арифметика. C>Генерировать код в рантайме, играть со стеком (alloca), и т.п. я не могу.
Насчет генерации кода в рантайме я просто даже и не знаю что сказать. Про Reflection.Emit Вы ведь не можете не знать. Может Вам нужна какая-то экстратеррестриальная генерация о которой я ничего не знаю?
А что касается стека... Есть stackalloc
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
klapaucius wrote: >> > C> unsafe в понятии C# весьма ограничен. >> > Это безответсвенные заявления. > C>Почему? Фактически все что я получаю — это адресная арифметика. > C>Генерировать код в рантайме, играть со стеком (alloca), и т.п. я не могу. > Насчет генерации кода в рантайме я просто даже и не знаю что сказать.
Не байт-код, а настоящий машинный код (см. мое сообщение про thunk'и).
Поверьте, про генерацию байт-кода я знаю уже оооочень давно
klapaucius wrote: > C>Поверьте, про генерацию байт-кода я знаю уже оооочень давно > Верю. Я смотрю вот в эти честные и чистые глаза и понимаю: они не солгут. > А в чем фатальный недостаток stackalloc ? Мне действительно интересно.
В самом по себе — ничем, но он фундаментально unsafe. А зачем
использовать управляемую среду с неуправляемыми фичами?
Да и работа с unsafe-кодом в C# находится на уровне С. Нет ни умных
указателей, ни копикторов, ни деструкторов.
Здравствуйте, Cyberax, Вы писали:
>> А в чем фатальный недостаток stackalloc ? Мне действительно интересно. C>В самом по себе — ничем, но он фундаментально unsafe.
Ну разумеется unsafe. Просто Вы сетовали на невозможность поиграться стеком в C# unsafe, вот я и удивился.
C> А зачем использовать управляемую среду с неуправляемыми фичами?
Вопрос вопросов. Полагаю, что в C# unsafe существует в основном для интеропа. Средство оптимизации, как я понимаю это доволно сомнительное, ведь оно мешает, по всей видимости GC и оптимизатору JIT но в некоторых случаях выигрыш получить можно. Смысл в том, что используя unsafe в управляемой среде можно явно обозначить ту часть кода где он применяется.
Все-таки есть разница используется опасный код повсеместно или нет. Не так ли?
C>Да и работа с unsafe-кодом в C# находится на уровне С. Нет ни умных C>указателей, ни копикторов, ни деструкторов.
Но ведь в C++/CLI это все есть? Так что если очень хочется, то, видимо, можно?
Тем более, что в этом случае никакого сравнения нет с накладными расходами связанными с использованием неуправляемого кода. Все достаточно неплохо интегрируется, насколько я знаю, хотя сам досканально такие вопросы не изучал.
Так что thunk'и да, использовать нельзя, но все остальное — можно. Или нет?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я вот всё сообразить пытаюсь: это так C# и .Net на орфографию влияют или что-то еще?
Пашь, осбуждение орфорграфии — это п. 5. Ну, а ты мог бы и в командом форуме поговорить об этом.
ПК>Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.
То есть ты обосновываешь ненужность устранения одного класса ошибок (причем чаще всего на сегодня приводящего к уязвимостям в софте) тем что мол есть и другие ошибки? Интересное мнение. Можно его развить на обычную жизнь. Ведь мы каждый день переходя дорогу рискуем попасть под колеса. Значит и провода изолировать не надо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ПК>>Я вот всё сообразить пытаюсь: это так C# и .Net на орфографию влияют или что-то еще?
VD>Пашь, осбуждение орфорграфии — это п. 5.
Зависит от.
ПК>>Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.
VD>То есть ты обосновываешь ненужность устранения одного класса ошибок (причем чаще всего на сегодня приводящего к уязвимостям в софте) тем что мол есть и другие ошибки?
Нет.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>(Я не представляю себе требования к памяти Photoshop на .NET ).
AVK>http://www.eecs.wsu.edu/paint.net/
Это заявленные. А какая реальная конфигурация нужна чтоб работать а не тормозить?
Windows XP (SP1 or later), Windows 2000 (SP3 or later), Windows Server 2003, or Windows Vista
.NET Framework 2.0
400 MHz processor (Recommended: 800 MHz or faster)
128 MB RAM (Recommended: 512 MB or more)
1024 x 768 screen resolution
50+ MB hard drive space
64-bit support requires a 64-bit CPU that is running an x64 or Itanium edition of Windows XP or Windows Server 2003, and 256 MB RAM
Intel® Xeon™, Xeon Dual, Intel Centrino™, or Pentium® III or 4 processor
Microsoft® Windows® 2000 with Service Pack 4, or Windows XP with Service Pack 1 or 2
320MB of RAM (384MB recommended)
650MB of available hard-disk space
1,024x768 monitor resolution with 16-bit video card
CD-ROM drive
Internet or phone connection required for product activation
более менее реальные требования к железу (из опроса по аське знакомых дизайнеров):
от Pentium 4 3Гц+
от 1 Гиг RAM
много of available hard-disk space
от 1280х1024 monitor resolution with 32-bit video card
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Павел Кузнецов, Вы писали:
VD>>Пашь, осбуждение орфорграфии — это п. 5.
ПК>Зависит от.
ПК>>>Если по существу, то общая проблема безопасности так просто не решается: не переполнение буфера, так забытое декорирование строк при составлении SQL запросов, не это, так хранение открытых паролей или персональной информации пользователей и т.п.
VD>>То есть ты обосновываешь ненужность устранения одного класса ошибок (причем чаще всего на сегодня приводящего к уязвимостям в софте) тем что мол есть и другие ошибки?
ПК>Нет.
Как же нет? А в чем смысл твоих слов? Что зе зверь "общая проблема безопасности"?
И чем плохо просто автоматически имень значительно меньше ошибок?
Или я не уловил момент когда кто-то сказал что типобзопасность решает все проблемы разом? Нет. Она всего лишь истраняет конкретный класс ошибок и тем самы в том числе повышает (и не мало) защиту приложений. Вон в Виндовс и Мае что-то ни открытых паролей не видно, ни SQL-строк, а тем неменее при нехилой борьбе с тем же переполенения буфера периодически вылезают дыры в защите именно из-за этого дела.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
AVK>>http://www.eecs.wsu.edu/paint.net/ CC>Это заявленные. А какая реальная конфигурация нужна чтоб работать а не тормозить?
Главред RSDN Magazine сам использовал это дело на машине с 512 метрами и процессором AMD Athlon 2000+ вместо Фотошопа для редактирования картинок при переводе из журнала в веб-форма. Причем делал это исклчительно потому что Фотошом жутдко медленно грузится, а это дело грзится в мгновение ока.
CC>Windows XP (SP1 or later), Windows 2000 (SP3 or later), Windows Server 2003, or Windows Vista CC>.NET Framework 2.0 CC>400 MHz processor (Recommended: 800 MHz or faster) CC>128 MB RAM (Recommended: 512 MB or more) CC>1024 x 768 screen resolution CC>50+ MB hard drive space CC>64-bit support requires a 64-bit CPU that is running an x64 or Itanium edition of Windows XP or Windows Server 2003, and 256 MB RAM
CC>у того же Photoshop CS2 CC>Рекомендуемые с сайта (http://www.adobe.com/products/photoshop/systemreqs.html):
CC>Intel® Xeon™, Xeon Dual, Intel Centrino™, or Pentium® III or 4 processor CC>Microsoft® Windows® 2000 with Service Pack 4, or Windows XP with Service Pack 1 or 2 CC>320MB of RAM (384MB recommended) CC>650MB of available hard-disk space CC>1,024x768 monitor resolution with 16-bit video card CC>CD-ROM drive CC>Internet or phone connection required for product activation
CC>более менее реальные требования к железу (из опроса по аське знакомых дизайнеров):
CC>от Pentium 4 3Гц+ CC>от 1 Гиг RAM CC>много of available hard-disk space CC>от 1280х1024 monitor resolution with 32-bit video card
Кто тебе такую охинею сказал? Реально конечно чем больше тем лучше. Но вот указанного атлона за глаза хватает для обоих. А Фотошоп медленно грузится исключительно из-за групой архитектуры загрузки плагинов которых у него море и которые грузятся при старте.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
АХ>>>(Я не представляю себе требования к памяти Photoshop на .NET ).
AVK>>http://www.eecs.wsu.edu/paint.net/
FR>сравнил ворд с блокнотом
Влад за что минус-то?
По функциональности вполне корректное сравнение.
По памяти тоже интересно, поигрался тут загрузил одну и ту же картинку и проделал несколько операций(повороты масштабирование), При загрузке картинки paint.net потребовал процентов на 10 меньше памяти чем фотошоп, после нескольких операций занял памяти уже в полтора раза больше фотошопа. Ну и скорость выполнения операции в разы в пользу понятно кого. Вообще конечно сравнение совсем не коректно. Paint.Net надо сравнивать с каким ни-будь Ulead Photo, но думаю и ему он по скорости и памяти тоже сдует.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CreatorCray, Вы писали:
AVK>>>http://www.eecs.wsu.edu/paint.net/ CC>>Это заявленные. А какая реальная конфигурация нужна чтоб работать а не тормозить?
VD>Главред RSDN Magazine сам использовал это дело на машине с 512 метрами и процессором AMD Athlon 2000+ вместо Фотошопа для редактирования картинок при переводе из журнала в веб-форма. Причем делал это исклчительно потому что Фотошом жутдко медленно грузится, а это дело грзится в мгновение ока.
Угу. А я сам пользуюсь для себя PaintShopPro 8 (откатившись назад на 8-ю после пробы PaintShopPro X, который умудрялся тормозить на Intel P620, 1Gb DDR2 даже в пользовательском интерфейсе). И жрет он мало и грузится быстро.
VD>Кто тебе такую ахинею сказал? Реально конечно чем больше тем лучше. Но вот указанного атлона за глаза хватает для обоих. А Фотошоп медленно грузится исключительно из-за групой архитектуры загрузки плагинов которых у него море и которые грузятся при старте.
Люди, которые пользуются фотошопом для гораздо более сложных вещей, нежели простая правка картинок.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Люди, которые пользуются фотошопом для гораздо более сложных вещей, нежели простая правка картинок.
Люди которые пользуются фотошопом пользуются им для всего что в голову взбредают. И задумываются о другом только по нужде. Вот скорость загрузки и есть такая нужда.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Влад за что минус-то?
За сказанную глупость. Я как бы проффесионаьный пользователь Фотошоп и могу оценить насколкьо серьезен или не серьезен продукт.
Сравнение его с блонотом — это чистая некомпетенция. Если бы сравнение было хотя бы там Ворда с СтарВордом, то нет вопросов. Но это уже полнейший берд, спросте за выражение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Влад за что минус-то?
VD>За сказанную глупость. Я как бы проффесионаьный пользователь Фотошоп и могу оценить насколкьо серьезен или не серьезен продукт.
Я тоже был в одно время практически проффесиональным пользователем фотошопа (иногда проще самому подправить чем объяснять художникам). И у меня в мыслях не было сравнивать его с блокнотом. С блокнотом я сравнил paint.net. Вернее я сказал что сравнивать paint.net с фотошопом это все равно что сравнивать блокнот с вордом.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CreatorCray, Вы писали:
CC>>Люди, которые пользуются фотошопом для гораздо более сложных вещей, нежели простая правка картинок.
VD>Люди которые пользуются фотошопом пользуются им для всего что в голову взбредают. И задумываются о другом только по нужде. Вот скорость загрузки и есть такая нужда.
Кроме paint.net есть море простых шустрых граф. редакторов.
1.1.4 stable rev. 510
Так что потребуется уже два байта на индекс.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
эта сволоч падает редко но метко убивая винду.
