Программирование « WordPress.com Tag Feed

Надо всё таки тут отписаться наконец

bug2bug — Sat, 16 Aug 2008 21:09:49 +0000

Я люблю свою жизнь.
Недельку назад встретился наконец-то с Наташей.
Работаю сейчас на двух работах - в ООО "Добро" (Ведущим разработчиком, программистом 1С и начальником IT-отдела по совместительству) и ООО "Деко" (Системным администратором и инженером по внедрению и поддержке свободного программного обеспечения). Доволен. С первой же зарплаты купил себе Apple iBook G4, стал вообще счастлив.
Зарегистрировал на себя домены http://zbug.pp.ru и http://desu.org.ru
Разрабатываю для них на Python систему управления контентом.
Таки помирился наконец со Светой, поговорили много о чём.

В-общем, можно сказать, что всё шикарно (:

Монокультура Microsoft

peter631 — Sat, 16 Aug 2008 18:58:49 +0000

Все от MS

Еще лет 10 назад все было более-менее. Под Windows можно было писать на Delphi, Visual Basic'е, Power Builder'е, Java, vxWorks и еще до хрена на чем. Можно было ставить Sybase, MS SQL, Oracle и Informix. Да и сейчас можно, только никто не будет. MS вынесла всех. У нас работает Ms Windows Vista (tm) СУБД у нас MS SQL Server (tm). Пишем в MS Visual Studio (C). Под MS CLR (C). Сливаем сорцы в MS Team System (tm). Группа сертифицированных MS-инженеров на MS-совместимом оборудовании. Продуктивность работы возросла, конечно, но меня не оставляет ощущение что с потерей разнообразия средств разработки мы что-то потеряли. Причем потеряли больше, чем приобрели.

Конечно, все считают, что Visual Studio и C# безусловно последнее слово в разработке, вот только так ли это в действительности?

Слабость C#

Был такой язык Лисп. Над ним в течении 40 лет трудились лучшие умы. Для Лиспа придуманы были и сборка мусора, и ленивые вычисления, и объекты и все что можно себе вообразить. Собственно, даже сейчас любой из традиционных языков проигрывает Лиспу. Даже используя Лисп, исследователи не смогли заставить компьютер думать. Стоит ли в свете сказанного возлагать на шарп надежды? Очевидно нет - это заранее слабый язык. Ничего грандиозного мы на нем не напишем - не написали на Лиспе, на Шарпе и подавно не напишем.

Проблемы с обучением

Я глубоким изумлением узнал, что современных программеров даже не обучают C и ассемблеру. Есть вот, ребята, C# - творение великих святых от MS - пользуйтесь им, остальное - ересь. Программист, не представляющий, что такое регистры процессора - это, ИМХО, совсем...Совсем скоро потеряем контивность мышления, так и будем смотреть в рот MS. Раньше программеров нанимали в России, а теперь - в Белоруссии. И правильно, что необученных и тупых задорого нанимать? Лучше умных и изворотливых задешево. Когнитивность, она не просто так. Ее надо тренировать.

P.S.

Раньше вон марксизм-ленинизм изучали, со всем усердием, теперь - продукцию MS.

Плохие сценарии

peter631 — Sat, 16 Aug 2008 18:35:28 +0000

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

Microsoft закрывает все никоуровневые API. Отныне разработчики вынуждены пользоваться только CLR (.Net Framework)
Intel выпускает процессоры, на которых работает только продукция Microsoft. Остальные OS не запускаются. Open Source переезжает на микроконтроллеры и PlayStation.
ВУЗы перестают обучать разработчиков программированию на C и Ассемблере. Отныне это - задача фирм-рабтодателей. Если фирма считает нужным, она расскажет разработчику, что такое регистры (как тут не вспомнить Бредбери, "451 градус по Фаренгейту")
Численность сотрудников Microsoft заваливает за 5 миллионов человек. MS официально просит ООН предоставить ей статус государства.
Правительство запрещает гражданам пользоваться системой, отличной от Windows. Open Source официально преследуется законом. Юниксоиды уходят в подполье.
Правительство легализует закладки в Windows.
MS выпускает подлинно сетевую версию OS, большая часть кода которой размещена на удаленных серверах. Доступ платный.

Кое-что уже сбывается. Может, стоит остановиться и подумать?

Юридическое признание компьютерных журналов (логов)

peter631 — Thu, 31 Jul 2008 16:49:57 +0000

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

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

Логи, как электронный документ, не могут быть юридически признаны без ЭЦП;
ЭЦП действительна при наличии доказательств факта ее наложения
ЭЦП предполагает наличие криптосредств, более того - сертифицированных криптосредств. Программное обеспечение, содержащее сертифицированные криптосредства, должно проходить аттестацию и исследование на корректность встраивания СКЗИ.
Криптосредства (СКЗИ) должны работать в доверенной среде - на защищенном по требованиям органов компьютере, со специальным ПО (и хардом), контролирующим целостность криптосредств и пр. (Минимально - электронный замок)
Закрытые ключи должны находиться на отчуждаемом носителе.
Запись лога должна содержать высокоточную отметку времени, полученную из внешнего источника, недоступную для модификации. В идеале на запись лога накладывается криптографическая отметка времени (см. TSA, RFC такой-то).
Помимо указанных мер, доступ к ключу должен иметь ограниченный круг лиц.
Внутри системы, доступ к ключу должен регулироваться матрицей доступа.
Лог-файл (файлы) должны быть объектом матрицы доступа.
Машина (компьютер) с логом должны стоять в охраняемом помещении.
Формат данных лога должен допускать проведение экспертизы (проверки отметки времени, подписи данных, проверки сертификатов подписи и пр.)

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

Hehe Text Editor: so it begins

Jefim Borissov — Thu, 31 Jul 2008 06:24:06 +0000

So, today I will start telling you about a very simple text editor I am making just for the fun of it. The thought appeared to me while I was extremely bored just "stumbling" sites. I thought - "Hey, instead of wasting your time doing nthing why don't you make a simple text editor and log the whole proccess in your blog?". And that is basically it. I wrote up some code. The main window and stuff and that was it.

Anyway, some thing I want to achieve during this "session":

Tabbed documents
Support for large documents
Windows context integration (like Noepad++ does)
Code highlighting
Code folding
Code structure
Autocomplete for functions and variables

And maybe something will be added later. This is a very minimalistic feature list for me right now. Next time I'll show you what I've done so far.

Системы осцилляторов

systemhalt — Sun, 20 Jul 2008 15:45:43 +0000

Недавно откопал в одном из бэкапов интересную прожку, написанную мною более двух лет назад. Программа моделирует систему тел, связанных между собой пружинками. Довольно занимательно, имхо. Сейчас сижу рефакторю её, ибо код там стрёмноватый по нынешним меркам. Думаю, обязательно нужно будет включить нечто подобное в Комплекс-II.

Скачать можно тута: http://nightmarez.webasyst.net/files/5ec9cc8e

Юридические аспекты применения электронно-цифровой подписи

peter631 — Sun, 13 Jul 2008 12:18:46 +0000

Слабость современных законов об ЭЦП

Несмотря на очевидную необходимость применения электронно-цифровой подписи в современном мире, дело продвигается с большим трудом. В США электронно-цифровая подпись признается только в некоторых штатах, да и то с оговорками. В России закон об ЭЦП откровенно слаб (и в техническом и в юридическом аспектах) и не может быть применен. Я читал драфт (модельный закон) об ЭЦП, выпущенный в 2007 году, но он ничем не лучше действующего. Европейская директива CADES существенно лучше, но она тоже ничего не раскрывает по существу дела. Хотя если ее принять у нас, то, конечно, это улучшит положение. Как практикующий специалист в области практической криптографии я остановлюсь на ряде моментов, которые представляются мне важными и которые либо не отражены, либо слабо отражены в российском законодательстве.

Апостиль

Несмотря на кажущиеся различия между законодательствами разных стран, юридическая практика, унаследованная нами от римского права, везде схожа. Людям всегда требуется одно и то тоже: регистрация сделок, признание и расторжение брака, наследство, права собственности и прочее. В современном мире, для которого характерна массовая и постоянная миграция людей, глобализация всех процессов, требуются универсальные механизмы признания юридических документов, оформленных в одной стране, на территории другой страны. Поскольку документы на иностранном языке ничтожны (не действительны), так как официально Вы не можете их прочесть и соответственно принять решение, требуется особая юридическая процедура признания документа. Для некоторых типов документов, например для доверенностей, на территории стран-участниц Конвенции, документы, оформленные на территории других стран признаются при наличии специального защищенного от подделки штампа и документа к нему, называемого апостиль. Апостиль и заверяемый им документ могут быть официально переведены и имеют юридическую силу.

В юридическом смысле аналогичная ситуация имеет место и с ЭЦП. Самый спорный момент - это момент наложения пользователем ЭЦП на документ, представленный в электронном виде. Бинарный (машинный) формат документа не может быть понятен пользователю. Соответственно, подпись, наложенная на бинарный документ - ipso facto - юридически незначима! Следовательно, ЭПЦ должна быть наложена на текстовое представление документа, которое безусловно необходимо показать пользователю перед моментом подписания. После подписания документ не может быть изменен. Как вариант, бинарный формат документа должен быть сертифицирован и должен существовать также сертифицированный экземпляр конвертера этого формата в текстовую форму и обратно. XML и соответствующий стандарт подписания неплохой кандидат на юридически признаваемую форму документа.

Свидетельства

Когда мы подписываем серьезный юридический документ, нам нужна гарантия признания его государством, чтобы иметь страховку на случай дальнейших споров и судебного разбирательства. Суд обязательно спросит: действительно ли имело место подписание этого документа? Был ли подписан именно этот документ именно этим лицом и в указанное время? Для доказательства этих фактов мы и отправляется к независимому свидетелю - нотариусу. Нотариус убеждается в подлинности лиц, подписей, непротиворечивости и законности договора и заверяет документ своей подписью и печатью (если предполагается перевод документа на другой язык - накладывает апостиль).

Для юридического признания ЭЦП нам, к сожалению, тоже нужен независимый свидетель. Иначе лицо, наложившее ЭЦП, может впоследствии отрицать факт подписания, сославшись на компьютерные вирусы, несовершенство системы измерения времени и прочие обстоятельства. В законе есть упоминание об этом, но по существу вопроса ничего не сказано.

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

Экспертиза

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

1. Сертификат открытого ключа лица, подписавшего документ и цепочка сертификатов, вплоть до корня, соотв. системы подписи;
2. Список отзыва, действительный на момент подписания документа;
3. Наложенная на подпись заверенная ЭЦП отметка времени и ее сертификат (и корень, если отличен от пункта 1)

В ходе экспертизы эксперты должны предоставить суду доказательства того, что:

Сертификат подписавшего не был отозван на момент подписания и принадлежит подписавшему
Сертификат подписавшего действительно выпущен указанным центром (проверка цепочки)
Подпись документа верна
ЭЦП отметки времени верна. ЭЦП отметки времени содержит корректный сертификат, не был отозван на момент подписания и был выпущен указанным УЦ.

Только при соблюдении указанных условий у нас появляется косвенное доказательство того, что документ был подписан, и причем в указанное время. Тем не менее, возможно, лицо подписавшее документ, действовало под принуждением. Также не исключен вариант, что лицо пало жертвой компьютерного вируса или программы-закладки, или программы удаленного управления, тайно внедренной на компьютер подписавшего. Ряд зарубежных систем ЭЦП имеют в своем техническом арсенале средство сигнализации "работаю под принуждением", которое позволяет выявить этот факт при проверке. К сожалению, вопрос с вирусами остается открытым.

Идентификационные данные

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

Заключение

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

Мысли вслух

systemhalt — Tue, 08 Jul 2008 11:53:05 +0000

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

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

Но и это ещё не всё. Работая в нашем посёлке городского типа, я за этот год так и не смог купить себе ноут. Все бабки ушли на жратву, оплату жилья и т.п. Получается, что и работаю я за еду :) Я бы с удовольствием спал бы по четыре часа в сутки, но, к сожалению, здоровье не позволяет... вот такие помидоры.

Всё. Поплакался. Теперь по сути дела. Проект таки потихоньку развивается. Развивается в данный момент на Delphi. Вроде бы как обратно на .NET переходить пока не хочу. И, надеюсь, что не буду. До начала следующей недели хочу реализовать базовые функции граф. библиотек под OpenGL и DirectX. После чего ещё неделька, наверное, уйдёт на прочие прибабахи (вроде загрузки модулей, основного 3D-меню выбора модулей, etc.), и, можно будет приступать к разработке самих модулей Комплекса.

Сегодня же, если время будет, займусь текстурами: хранением в запакованном виде, загрузкой, отображением.

Гг... Delphi

systemhalt — Sat, 05 Jul 2008 19:36:48 +0000

Блин. Прикинул архитектуру проекта. Какие должны быть модули, как должны функционировать и взаимодействовать. Даж простенький рендер написал. На C# 2008 и на Delphi 2007.
С одной стороны ностальгия по Delphi мучает. С другой стороны, на C# немного удобнее.... хоть и не на много. А для Delphi не нужно будет фреймворк таскать... пошёл думать ещё, дабы окончательно определиться с выбором ))))

Модули

systemhalt — Mon, 30 Jun 2008 09:33:39 +0000

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

Маятник (математический, двойной, etc.)
Пружинный маятник
Системы осцилляторов (куча грузов, связанных пружинами)
Маятник Фуко
Отрисовка полей (линии потенциалов, etc.), создаваемых заряженными телами
Реактивное движение
Задача Кеплера (+релятивистские эффекты, gravity simulator, etc.)
Движение частиц в электрических полях

Если у вас есть интересные идеи, плиз, сообщайте мне.

.NET Framework

systemhalt — Sun, 29 Jun 2008 15:22:40 +0000

После долгой борьбы двух противоположностей внутри меня: древнего дельфиста и молодого C++-сника, последний таки победил, растоптав первого в пух и прах. Тяга к удобству разработки победила над всем остальным. Выбор пал на платформу .NET

Писать буду под вторую версию. Ибо третья нафиг не нужна, да и требует она как минимум WinXP SP2, что не есть хорошо.

Если быть откровенным, я уже замахивался на .NET и написал пробную софтень с такой же структурой, какая будет у Комплекса. Всё это дело вполне даже успешно функционирует. Что даёт основания надеятся на правильность моего выбора.

Завтра у меня выходной. Буду закладывать первые кирпичики проекта.

О рулезности ODBC

peter631 — Sat, 28 Jun 2008 18:27:22 +0000

Старый, зато надежный

Оно конечно, статья эта более была бы уместна году эдак в 1993-96. Ныне в наш век повсеместного управляемого кода все и забыли что есть код неуправляемый, который работает на порядок-два быстрей. Так что если что-то надо сделать быстро, выбираем неуправляемый код. Если что-то хотите сделать быстро с базой, например - вызов большого количества хранимых процедур, то лучше ODBC вам не найти.

Кто же добрую скотину гонит со двора

В MS SQL, например, появилась новая клиентская либа - MS Native Client. К ней идет и полнофункциональный, самый современный вариант старого доброго ODBC. Так вот. Помимо прочих достоинств он офигительно, непредставимо быстр. OleDb и .Net провайдеры просто отдыхают по сравнению со связкой Win32-NativeClient- ODBC

Преимущества ODBC

Он прост, хоть и кажется сложным. Честное слово, по сравнению с OLEDB - сама простота.
Он аккуратно написан, в отличие от современного софта. Вы можете сами в этом убедиться, запустив программу, использующую ODBC из-под BoundsChecker'а.
Он очень быстр. Загрузка курсора на борт раз эдак в пять быстрей, чем в ADO.
Он поддерживается в самых современных версиях СУБД (хоть бы тот же MS SQL)
Он переносим на LInux (Unix ODBC) - я пробовал, все замечательно.
Есть специфические фичи - например, пакетирование вызова процедур. Предствавьте, что Вам надо дернуть хранимую процу 1500 раз с разными параметрами. ADO потратит на это 1500 round - trip'ов. ODBC в режиме пакетирования (Column Wise or Row -wize) - только один. Разница по времени офигенная.

Недостатки ODBC

Вызовы громозкие. Данных типа Variant (object) нет. Въезжать по началу сложно.
Чувствителен к последовательности вызовов, как что не по нему - кричит
Обработка ошибок несколько витиевата.

В общем, потратьте немного времени на изучение этого старого надежного интерфейса - пригодиться.

Выбор среды разработки

systemhalt — Sat, 28 Jun 2008 07:11:45 +0000

У меня есть два варинта, которые мне более-менее подходят:
1) связка C++/CLI и C#
2) Delphi
У обоих есть свои преимущества и недостатки, которые мне не дают окончательно определиться.

Плюсы Delphi и минусы .NET:

1) Delphi компилирует в нативный код, в дотНете же сборки будут в промежуточном коде (за исключением частей программы, написанных на C++, которые будут непосредственно общаться с OpenGL и DirectX). Мне не очень нравится тот факт, что кто-то может без проблем получить доступ ко всему моему коду. Обфускаторы я не уважаю.

2) Если я буду писать в Delphi, созданная мною программа сможет работать хоть на 98-ой винде без каких-либо проблем. Если же я буду писать под третий .NET, программу можно будет запускать лишь на осях начиная с WinXP со вторым сервис паком, на который перед запуском моей проги нужно будет поставить Windows Installer 3.1 и .NET Framework 3. Довольно неудобно.

Плюсы .NET и минусы Delphi:

1) C++/CLI и C# как ЯП по-развитее будут, чем Delphi. Да и сама .NET мне больше симпатизирует. Разбивать на ОО-модули программу в Delphi проблематичнее чем в .NET
Часто нужно определить типы в одном модуле (DLL), а использовать в других.
Есть, конечно, пакеты Delphi.... но к ним у мя душа не лежит :)

2) Защита от дурака (aka GC). Я, правда, работал в одном проекте в комманде из 10 человек.... и, не смотря на GC, продукт всё-равно тёк памятью и ресурсами :) Но всё же.... Хотя, в Delphi для этой цели можно юзать TInterfacedObject и считать ссылки.

Smalltalk

bug2bug — Thu, 26 Jun 2008 09:47:20 +0000

Изучаю вот язык программирования Smalltalk. Решил сразу начать с переноса программ, которые меня когда-то просили написать. Язык, кстати, использует два основные парадигмы: объектно-ориентированный подход и сигналы. А самое главное, выглядит красиво и оригинально. :)

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


"Основная программа"
"Создаём объект MyArray из массива"
a := MyArray new: #(1 4 2 3).
"Заменяем максимальный элемент на среднее арифметическое

всех элементов и выводим на печать"
(a at: (a maxn) put: (a avg)) printNl.

Сам код класса можно найти по адресу
http://freeshells.ch/~bug2bug/wiki/doku.php?id=smalltalk

Что это такое и зачем оно нужно....

systemhalt — Sun, 22 Jun 2008 23:02:55 +0000

Для начала хочу рассказать почему я вообще начал подобными вещами заниматься. Дело было на втором курсе. Преподавал физику у нас проректор. И был у него набор программок, написанных им же, которые рассчитывали кое-какие физические задачи и результаты рисовали на экране. Если мне не изменяет склероз, написаны они были на турбо паскале.... ну и графика, естесственно, была соответственной. А у меня был подростковый возраст со всем присущим ему максимализмом, а ещё я неплохо знал Delphi и умел работать с OpenGL. Ну и захотелось мне сделать такое же, только круче :)

В конце концов через год получилось нечто, что я назвал Комплексом Физических Программ. Тут надо заметить, что я писал его не весь год изо дня в день, а периодически (когда настроение было). Имхо, для студента-второкурсника получилось великолепно.

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

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

Цель моя написать некоторое количество программ (навскидку штук тридцать), объединённых в единую систему. Каждая программа - суть модель какой-либо физической сущности. Одна - моделирует распространение колебаний в упругих средах, другая - движение заряженных частиц, третья - движение астатического маятника, четвёртая - ........

Я считаю, что подобная программа - просто находка для преподавателей физике в школах и университетах. Ведь куда интереснее будет предмет для учеников, если они не будут изучать сухую теорию, а смогут увидеть всё своими глазами на практике.

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

Режим секретности

peter631 — Sun, 22 Jun 2008 13:13:21 +0000

Введение

Ровным счетом ничего секретного не сообщаю, излагаю самые банальные вещи. Но с практической точки зрения:)

Мандарторная модель безопасности, упрощенно

Лениво мне описывать всю модель, идите на wikipedию и читайте про модель Бела-ЛаПадулы, мандаторный способ защиты и прочее. Я изложу практический аспект. Самые неприятности при построении информационной системы начинаются, когда некоторый тип данных является секретным. Никто не может его ни прочесть, ни исказить, не распечатать, ни переслать по каким-либо каналам. В общем, вот есть комната, охраняемая автоматчиками, и там терминал. Даже принтера нет. А если и есть, то выносить распечатки нельзя - дальше определенной зоны. И язык следует держать за зубами, или пуля в лоб. Вот так. Сложные условия.

Как делается. Ряд определений. Контейнер. Это все, что содержит информацию - терминал (в том плане, что физическое устройство, с которого можно глазами данные считать), принтер, канал связи, носитель (а хоть бы и флешка). Данные - все, что эти сведения содержит. Субъект - разумное существо (и программа, выступающая от лица субъекта). И данным, и контейнерам, и субъектам приписываются так называемые метки безопасности. В простом случае - это просто число, характеризующее благонадежность субъекта, секретность данных или уровень доступа контейнера. Метки сортируются по возрастанию (собственно, необязательно). Правила просты:

Данные нельзя записать в контейнер, если уровень его метки ниже метки данных
Субъект может записывать (но не может читать) данные на более высокий уровень секретности.
Субъект может читать (но не записывать) на более низкий уровень секретности.

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

Контейнеры - терминал

Как раз с ними самый большой проблем. Вот, скажем, терминал. Это необязательно старый СМ-овский или ЕС-вский терминал а в смысле клиентская программа, и выполняющий ее компьютер. Там где гриды, кнопочки и менюшки. Вопросы тут возникают такие:

Каков уровень доверия к данному терминалу? Какого уровня секретности материалы можно на нем показывать? И кому?
Как убедиться в том, что терминал не был физически перемещен? Злой предатель может подключить свой ноутбук к сети WiFi и используя свой легитимный логин, свистнуть секретные данные. Например, терминал уровня 0 стоит в охраняемой комнате. Пропускная система. Программа как-то должна определить, что имеет место с таким-то набором железа, а не с другим. Железо можно подмахнуть. Сами знаете как.
Вначале работы все терминалы нужно разметить. Какой какого уровня. Занести в базу данных (секретную) вместе с хардверным неизменяемым ID.
Также надо убедиться, что с этого терминала нельзя украсть данные. Нельзя подключить внешние накопители (неучтенные и неразмеченные), флешки там, и пр. Также надо убедиться, что по сети с этого терминала никуда, кроме сервера, нельзя попасть.

Контейнеры - принтер

С этим гемора еще больше. Как убедиться что принтер тот, за кого он себя выдает. Как обеспечить его ID ( и его безопасную передачу)? Вообще говоря, компания HP производит такие принтеры, но вывоз их за пределы США запрещен под страхом пожизненного заключения. Что делать-то? Паяем сами железку и вкрячиваем туда. Опять же, принтера надо разметить. Учесть, кто где стоит и какой уровень доступа может печатать.

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

Контейнеры - носители

Тут вообще один сплошной ахтунг. Носители надо учитывать, но как? Как HardID неизменяемый на флешку запихать? Опять же данные шифровать надо, причем на каком-то общем для всего уровня безопасности ключе. Опять же (как в любом другом случае) все это надо проверять...

Контейнеры - каналы передачи данных

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

А теперь - данные!

Вот тут, похоже, начинаются главные трудности. Как отбеспечить "неотрываемость" метки от данных, которые она отмечает? Вычислить совместный хеш? Хеш с секретом? Подпись? Кто будет менять эту метку? И как эту софтину (назовем ее Ядром Безопасности) контролировать? Чтобы не упала? Не отключилась? И через нее не свистнули данные?

Побочные каналы

Вот тут теория и дает сбой. Даже с высокого уровня секретности данные можно тихонечко украсть. И никто не заметит. В этот как раз и состоит главная трудность реализации мандаторной модели. Предположим - я плохой. У меня высокий уровень доступа и моим сообщникам потребовалась копия секретных данных. Мне надо ее выкрасть. Физически это сделать нельзя - все предусмотрено. Ладно. Обзаводимся помошником, пусть даже программным. Запускаем программного помощника на низком уровне хоть бы даже с какого-нибудь удаленного терминала. Помошник следит за 2 двумя файлами - файлом A и файлов B. И определяет, имеет ли к ним доступ кто-нибудь в данных момент. И регистрирует эти факты. Отлично. Я, сверху, тоже имею доступ к этим файлам. Сначала я читаю файл A. Потом B. Потом снова B. Сопоставим чтение файла A двоичной единице, а чтение B - двоичному нулю. Таким образом я кодирую всю секретную информациюю Потом мне остается только забрать данные у программы - помошника.

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

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

Такие дела. Если попадется такой проект - знайте, я завидую Вам. Have fun.

Разработка идёт полным ходом

systemhalt — Sat, 21 Jun 2008 09:42:07 +0000

Итак, обо всём по-немногу.

Комплекс будет работать только под Виндой.... смысла в портировании на другие ОС совершенно не вижу.

Мультирендер.
Во-первых, OpenGL версии 1.1. Возможно будет модуль для работы через более свежую версию, но в данный момент это в планы не входит.
Во-вторых, DirectX. Восьмой и/или девятый. Десятый опять таки пока в планах не числится. Но, если всё будет хорошо, то, естессно, и его добавлю.

Гуй (GUI) по типу того, что был в первой версии Комплекса. С той лишь разницей, что он будет строиться по типу MDI и всё будет происходить в одном основном окне.

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

Язык по-дефолту английский. В планах - добавить поддержку разных языков. Надеюсь, сложностей с этим не возникнет. Тогда будут и русский и украинский.

Куда движется софтверная индустрия?

peter631 — Sat, 31 May 2008 05:51:13 +0000

Медленней чем ожидалось

Конечно, делать прогнозы совершенно неблагодарное занятие, но тем не менее. Лет пять назад предсказывали взрывной рост приложений на .net. Тем не менее этого не произошло. Кривая роста оказалась куда плавнее, чем это предсказывали платные мудрецы-маркетологи ms. Масса компаний просто боиться переписывать наработанную кодовую базу со старых языков. Вояки предпочитают использовать и развивать Ada. Крупные страховые фирмы, банки и промышленные компании вполне довольны Cobol. Секьюрники боятся сьезжать с плоского C. Коммутационщики вообще роют в другом направлении, в сторону функциональных языков. Дело не только даже в кодовой базе. Дело в обученных программерах, утилитах, специфических приемах и установленных процедурах. Попробуйте-ка реализовать на С# правительственные требования к безопасности. Язык c# и вся эта инфраструктура, коли не помрет, устаканится лет через двадцать. Пока объем наших эмпирических знаний о clr и даже о java стремиться к нулю. Мы не знаем, насколько эти системы безопасны. Мы даже не знаем, как, собственно, это обеспечить. Мы не знаем, как обеспечить быстродействие таких систем. Мы толком не знаем, как нам избавиться от реляционных баз, которые уже явно выработали свое, и перейти к хранению объектов. Пока что усилия в этом направлении пока что смехотворны.

Субстрат

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

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

Эффективная нотация: адекватность vs. стандартность

peter631 — Sat, 24 May 2008 06:59:30 +0000

Всех нас учили, и это справедливо, что нужно писать приложения, в которых логика вынесена в данные. Приложения, управляемые данными. Сама программа должна быть примитивной. С особой остротой встает вопрос об адекватности нотации, о ее удобстве и пр. Это не так просто, как кажется. Есть поистине зубодробительные задачки. Вот тут нам в качесте стандартной нотации для всего-всего навязывают (именно навязывают) XML. Вещь, конечно, весьма неплохая, но подходит явно не ко всему, согласитесь. То есть, программисты "мира Windows & Miscosoft" практически лишены выбора. Нам приходиться использовать то, что дают. Почему? Потому что, предложив нестандартную нотацию, мы рискуем многим:

Не поймут дураки-манагеры клиентов
Разработка парсеров для своей нотации дело хлопотное и долгое
При всем удобстве самописный софт еще долго будет глючным

Отчасти я завидую ребятам из мира Unix. Там можно делать все, что тебе захочется. Раньше мы пользовались большой свободой и под Windows, когда существовали альтернативные среды разработки, такие как Java и Дельфи, SmallTalk и пр. Сейчас производители этих средств махнули рукой на Windows, и сконцентрировались почти исключительно на LInux, а MS подгребла под себя все. В результате виндозники остались с CLR и C#. Эта очень узкая ниша в конечном счете погубит Windows, которая, в общем-то, является неплохой OS.

Так что приходиться забыть о своих собственных разработках ради вливания в узкий поток MainStream'а, хоть бы и ценой удобства. Стоит ли оно того?

Комплекс Физических Программ 2

systemhalt — Fri, 09 May 2008 22:55:16 +0000

[gallery]

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

Сейчас наступает тот момент, когда я закончу этот грёбаный университет (если закончу) и, в свободное от работы время, смогу заняться Комплексом-2 вплотную. Не скрою, что сейчас у меня уже нет той уверенности в необходимости его разработки, которая была несколько лет назад. Я не знаю, действительно ли он будет полезен многим людям. Знаю лишь точно, что в ближайшее время я обязан сделать нечто такое, а других глобальных идей, кроме Комплекса-2, у меня нет.

Как писать юнит-тесты на C++

peter631 — Wed, 30 Apr 2008 06:22:01 +0000

Будьте проще

Применение юнит-тестов при наприсании софта на C++, а также проектирование по контракту, приносят очень большую пользу, особенно на необорудованных платформах. Я не претендую на крутизну решения, однако мое решение непохо работает. Есть, конечно, вещи типа CppUnit, но я предпочитаю пользоваться простейшей из возможных методик.
//***************************************************************************** // // Freeware. As Is. // Простейшая из возможных среда юнит-тестирования на неуправляемом C++ // Легко перенести в Linux. Проверена временем:) // // Ограничения : // // 1) не ловит информацию об исключениях, не явл. потомками std::exception // 2) в случае исключения-потомка std::exception не дает информации про строку и файл // // $Header$ // //***************************************************************************** #include "TestSuite.h"

void success()
//
// Этот тест успешен
//
{

}
//
//---------------------------------------
//
void
failedTest()
//
// Этот тест проваливается по условию и пишет строку, файл и сообщение
//
{
CHECK(false, "Bide");
}
//
//---------------------------------------
//
void
alwaysFail(void)
//
// Этот тест проваливается безусловно и пишет строку, файл и сообщение
//
{
FAIL("Malfunction");
}
//
//---------------------------------------
//
void
throwsSomeWildException()
//
// Раскручивает исключение, не являющееся потомком std::exception
//
{
throw 0x0010033;
}
//
//---------------------------------------
//
void
throwsCorrectException()
//
// Раскручивает корректное исключение, но строки и файла Вы не увидите
//
{
throw std::invalid_argument("invalid argument");
}
//
//---------------------------------------
//
int
main(int argc, char* argv[])
{
TestSuite suite;

suite.registerTest(success, "success");
suite.registerTest(alwaysFail, "alwaysFail");
suite.registerTest(failedTest, "failedTest");
suite.registerTest(throwsSomeWildException, "throwsSomeWildException");
suite.registerTest(throwsCorrectException, "throwsSomeWildException");

suite.runAll();

char s[10];
gets(s);
return 0;
}

Полный текст решения доступен по запросу. Пишите - я Вам его вышлю. Написание тестов в этой среде не представляет никакого труда. Каждый тест - это просто функция, которая не возвращает результата и не принимает никаких параметров : void testFunction(void). После того, как тест написан, его надо зарегистрировать и дать ему хинт, под которым он будет выводиться. Проверка условий осуществляется макросом CHECK. Если что не так, макрос напишет, где именно что не так (удобно). Безусловно отрицает тест вызов макроса FAIL. Всего-то делов (зато какая польза). Если в проекте много файлов или подсистем - пишите отдельные файлы, передавайте туда ссылку на TestSuite и регистрите тесты там. Если не лениво, можете усовершенствовать сорцы, добавив цвет и пр.
Ограничения - см. комментарий.

Нотариальная практика в разработке программ

peter631 — Mon, 28 Apr 2008 06:12:43 +0000

Суть проблемы

Название необычно звучит, правда? Тем не менее вещь весьма полезная. Представим ситуацию. Два программера, A и B, совместно пишут программу. Один пишет клиента (не обязательно сетевого), второй - сервер(тоже не обязательно сетевой). В процессе работы они согласовывают сигнатуры методов, суть работы, сигнализацию об ошибках и пр. Пока все хорошо. Проходит полгода (год). Детали программы уже забыты, тесты потеряны (или, в силу специфики, не существуют), а программа дает сбой (или просто начинает тормозить). Кто виноват? Начинаются разборки. Знакомое явление? Более чем. Низкая культура разработки, говорите? Правильно.

Решение проблемы

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

Что мы пишем в контраке?

Предмет договора - вызов метода xxxxAAAABBB. В контракте указываются:

ФИО сторон и дата подписания. Строки документа пронумерованы. Нотариус ставит свою подпись.
Что, собственно, делает метод;
Параметры метода, их типы и возвращемый результат (и его тип);
Очень важно: неявно маршаллируемые параметры, как то: массивы структур, XML - документы, переданные строкой или через интерфейс, таблицы в памяти (MemData) (Что бы избежать потом вопроса типа : Ты какие поля мне тут передаешь????) и пр. ;
Согласованная обеими сторонами процедура валидации входных данных (особенно для неявно маршаллируемых) и выходных данных (очень важно, но все почему-то забывают).
Время выполнения вызова, если это актуально и, главное, согласованная обеими сторонами процедура его измерения;
Требования к выходным параметрам и резултьтату (особенно неявного маршаллинга);
Обработка ошибок в методе : полная безопасность от исключений, разрешение исключений, исключения определенного типа, код возврата и пр. Например, для функций нежелательно возбужение исключений;
Состояние класса после исключения: непредсказуемое (нет гарантий), одно из разрешенных (слабая гарантия), состояние, предшествующее вызову метода (сильная гарантия).
Для сетевых вывовов - максимальный размер передаваемых данных. Как правило, он ограничен (вот, скажем, для web-служб).
Заплатки или временные решения

Когда это делать

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

Да, вот еще что. Фиксируйте номер контракта (ссылку) в самом коде приложения, а то потом концов не найти.

Ускоряем базу - 1

peter631 — Sun, 20 Apr 2008 07:21:02 +0000

Общее

Это статья из цикла "Укорение работы баз данных под управлением СУБД MS SQL". Сегодня мы рассмотрим файловые группы базы данных.

Зачем нужны файловые группы SQL

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

обеспечения работы секционирования (partitioning) больших таблиц
для ускорения работы базы путем разнесения таблиц с существенно различными характеристиками доступа по разным файлам и дискам
для поддержки многопроцессорных платформ
отделения индексов от таблиц и вынесения колонок типа BLOB в отдельные файлы (группы)
обеспечения работы базы в условиях нехватки дискового пространства
для организации раздельных backup'ов.

Рассмотрим каждое из применений. Обеспечение секционирования базы таблицы (индекса). Довольно часто встречается ситуация, когда нужно хранить данные в одной большой таблице. Всякие там истории транзакций, архивы операций, журналы и прочее. И нет никакой возможности куда-либо это слить из базы. Со временем такая таблица разрастается, занимает много места на томе, все больше и больше времени уходит на поиск в ней и ее дефрагментацию. Поэтому все нормальные СУБД (с версии 2005 - и MS SQL, наконец-то) предлагают таблицы секционировать, разбить на разделы - partitions, по какому-либо признаку, скажем, по месяцам. Каждый фрагмент такой таблицы будет помещен в свой файл (группу файлов). СУБД в случае секционированной таблицы не тратит время, чтобы лопатить весь файл базы, а ориентируется по индексу и читает\пишет данные сразу в/из нужного файла. Таким образом мы экономим на времени и, что немаловажно, на блокировках. Кроме того, каждую файловую группу можно забэекапить отдельно.

Разнесение разных таблиц по файловым группам. Нетривиальная база содержит десятки, если не сотни таблиц. Доступ к этим данным совершенно отчетливо разный - одни используются редко, вторые - часто. В одни больше пишем, вторые читаем. Скажем, редко используемые справочники мы поместим в отдельную файловую группу и переведем на медленный диск. А оперативные данные - на самый быстрый. Архив - тоже на медленный, но на большой. С целом быстродействие системы, время ее отклика повыситься, так как разные по характеру запросы перестанут отнимать друг у друга диск (файл, группу файлов). Бессмысленно смотреть в профайлер, пытаясь понять, почему запросы тормозят. Нужно посмотреть в другое место (анализ базы и счетчики- в отдельной статье).

Поддержка многопроцессорных систем. В то время как однопроцессорная система только делает вид, что умеет выполнять несколько процессов одновременно, многопроцессорные системы реально выполняют задачи в параллель. В том числе - и задачи записи и чтения данных на диск. Можно позволить SQL - серверу использовать несколько процессоров для одновременной записи данных на диск, создав в базе несколько , так сказать, "беговых дорожек". Гипертрединг лучше отключить, все равно SQL не понимает, что это такое. Следует поэкспериментровать с этим. У меня получались наилучшие результаты при числе файлов, равном удвоенному числу процессоров, без учета гипертрединга (гипертредный процесссор считается за единицу).

Отделение индексов и блобов. Тут то же соображение, что и во втором пункте - индекса и сами данные суть различающиеся по активности единицы. БЛОБы вообще храняться в базе отдельно. Посему в активно используемой базе индекса сдедует хранить отдельно, особенно учитывая возможность их отключения (потенцальную возможность), а также необходимость их регулярного перестроения. Лучше перестроить один маленький файлик, чем базу на 2000 Гигабайт, а? Кластерные индексы не в счет, они все равно представляют в конечном счете сами данные. Так что с кластерными не получиться. БЛОБЫ вообще отдельный вопрос. Если две таблицы имеют два блобовых поля, храните эти блобы по разным группам.

Нехватка дискового пространства. Тут все просто. Представим, что мы слегка просчитались, и база вот-вот заполнит диск. Места там уже нет, том не расширяемый. Что делать? Добавить в базу файл на другом диске, лучше - отдельной группой.

Резервное копирование групп. Тоже все просто: база содержит справочные данные, которые вообще никогда не меняются, но которых внушительное число, и оперативный журнал, который маленький, но критичный к потере, а также огромного размера архив, который в принципе уже по большей части заархивирован. Неразумно тратить дисковое \ ленточное пространство на резервное копирование тех же самых данных каждый раз по-новой. Лучше копировать только оперативные, справочники - вообще один раз, а архив - инкрементально. (Про хардваре для базы - следующий раз.)