Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

28.05.2017

Google
WWW CITForum.ru
С Новым годом!
2000 г

Система обмена сообщениями Х.400

From: Denis (fox@css-mps.ru)
Referat by article in "Mir PC"
Date: 26 Oct 1998

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

Еще до появления WWW и Internet-телефонии уже существовали различные службы обмена документальными сообщениями. Достаточно только упомянуть cc:Mail, CompuServe, SMTP, MHS, X.400. Они разрабатывались для различных задач и в рамках различных сетевых архитектур. В настоящее время наибольшее распространение получила служба SMTP. Это обусловлено, прежде всего, распространением сети Internet. Однако нельзя сказать, что это идеальное решение. Достаточно отметить только избыточность кодирования при передаче двоичных файлов и путаницу с кодировками. И наверное, самое большое удивление у пользователей вызывает отсутствие документального подтверждения факта получения и прочтения документа. Отсутствие сообщения о недостижимости абонента ни о чем не говорит, письмо может год пролежать в почтовом ящике. Все это очень сильно сужает область применения данной службы. Возникает закономерный вопрос: неужели не было придумано ничего лучше? Оказывается было. Мы познакомимся со службой обмена сообщениями Х.400, разработанной Международным Консультативным Комитетом по Телефонии и Телеграфии (МККТТ). Данная служба до сих пор широко применяется в сетях на основе протокола Х.25 и активно используется в государственных и финансовых учреждениях большинства стран.

Рекомендации по организации службы были разработаны и опубликованы в 1984 году. В 1988 году рекомендации были исправлены и дополнены новыми возможностями. В версии 1992 года к Х.400 добавлены поддержка стандарта EDI (electronic data interchange), спецификация наборов символов, обмен голосовыми сообщениями, подключение пользователей к электронным доскам объявлений, реализация API.

Что же такое Х.400

  • Х.400 - общий стандарт, регламентирующий управление и обработку сообщений и состоящий из нескольких частей:
  • Х.400 - общее описание системы и службы обработки сообщений;
  • Х.402 - архитектура;
  • Х.403 - тестирование;
  • Х.407 - определение услуг;
  • Х.408 - правила кодирования информации;
  • Х.411 - система передачи данных: определение услуг и процедур:
  • Х.413 - хранилище сообщений; определение услуг:
  • Х.419 - спецификации протоколов:
  • Х.420 - система межперсональных сообщений.

Система обработки сообщений (СОС) построена в соответствии с принципами организации взаимосвязи открытых систем (рек. Х.200 МККТТ) и использует сервисы уровня представления и прикладного уровня. СОС может быть построена для любой сети, удовлетворяющей требованиям, предъявляемым к открытым системам.

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

Стандарт Х.400 описывает протоколы взаимодействия между всеми компонентами системы управления сообщениями.

Возможности

Х.400 обладает многими необходимыми для передачи сообщений возможностями, а именно:

  • присваивание сообщениям приоритетов;
  • подтверждение приема сообщения;
  • указание даты и времени;
  • рассылка сообщений сразу нескольким абонентам;
  • защита и конфиденциальность сообщений;
  • передача сообщений любых форматов.

Функциональная модель

Функциональная структура системы обработки сообщений приведена на рис.1

В этой модели пользователь считается либо отправителем сообщения (при передаче), либо получателем (при приеме).

Система обработки сообщениями Х.400 состоит из следующих составляющих:

  • Агент пользователя (АП). Это прикладной процесс, обеспечивающий удобный интерфейс пользователя с системой управле6ния сообщениями. АП помогает, в частности, составлять, отправлять, принимать и архивирования сообщения. АП и, следовательно, пользователь, идентифицируется своим адресом, называемым адресом отправителя / получателя (О/П - адресом, адресация рассматривается ниже).
  • Система передачи сообщений (СПС). СПС обеспечивает транспор-тировку сообщений всех видов от АП отправителя до АП получателя. СПС содержит ресурсы для промежуточного хранения сообщений.
  • Агент передачи сообщений (АПС) Это прикладной процесс, переправляющий приходящие ему сообщения адресатам - агентам пользователей или другим АПС.
  • Рис.1

  • Хранилище сообщений (ХС). Универсальная возможность СОС, действующая в качестве посредника между АП и АПС. Основное назначение - хранить доставленные сообщения и допускать возможность их поиска. Кроме того, ХС позволяет осуществлять предоставление сообщений со стороны АП и выдавать в АП сигналы уведомления.
  • Модуль доступа (МД). Это функциональный объект, который связывает другую систему обмена данными (например, систему почтовой связи или телекса) с СПС и с помощью которого ее клиенты участвуют в качестве косвенных пользователей в обработке сообщений..
  • Модуль доступа физической доставки (МДФД). Это модуль доставки, который подвергает сообщения физическому преобразованию и переносит конечное физическое сообщение в систему физической доставки (система, транспортирующая и доставляющая физическое сообщение, например почтовая служба).

Описание модели СОС

Система управления сообщениями на основе рекомендаций Х.400 представляет два основных вида услуг:

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

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

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

Информационная модель

Системы СОС и СПС могут переносить информационные объекты трех классов: сообщения, зонды и отчеты.

Сообщения

Основное назначение передачи сообщения состоит в переносе информационных объектов, называемых сообщениями, от одного пользователя к другим. Базовая структура сообщений, передаваемых СПС, показана на рис.2.

Рис.2. Базовая структура сообщений

Сообщение состоит из конверта и содержимого.

Конверт включает сведения, необходимые для правильной доставки, - адреса отправителя и получателя, тип содержимого, приоритет. Тип содержимого представляет собой идентификатор, который определяет синтаксис и семантику сообщения. Этот идентификатор позволяет АП и ХС интерпретировать и обрабатывать содержимое. Кроме того, конверт содержит данные, которые идентифицируют типы кодирования информации, присутствующей в сообщении.

Содержимое, в свою очередь, состоит из межперсонального заголовка и тела.

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

Зонды

Другое назначение передачи сообщений состоит в переносе информационных объектов, называемых зондами, от одного пользователя к другим (то есть до АПС, обслуживающих этих пользователей). Зонд содержит один только конверт. Этот конверт несет почти такую же информацию, что и сообщение. Помимо типа содержимого и типов кодировки конверт зонда указывает длину его содержимого.

Отчеты

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

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

Модель системы передачи сообщений

Обработка сообщений предназначена для обмена сообщениями между пользователями на основе их передачи с промежуточным накоплением. Сообщение, предоставленное отправителем, передается через СПС и доставляется одному или нескольким получателям. Модель СПС приведена на рис.3.

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

Рис.3. Модель системы передачи сообщений

Объекты АПС имеют следующие порты: представления, доставки, административный. Порт доставки позволяет пользователю СПС воспринимать доставку сообщений из СПС и получать отчеты о доставке или недоставке сообщений и зондов. Административный порт позволяет пользователю СПС изменять параметры настройки, относящиеся к доставке сообщения, и позволяет СПС или пользователю СПС обмениваться своими удостоверениями личности. Порт предоставления позволяет пользователю СПС представлять сообщения СПС для их передачи и доставки одному или нескольким получателям СПС и зондировать способность СПС доставлять сообщение. В общем случае сообщение, зонд или отчет могут быть переданы несколько раз между различными АПС, чтобы достигнуть искомого адресата.

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

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

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

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

Адресация

Адресация в Х.400 очень проста. В то же время она является одной из самых мощных среди существующих и идентифицируется именами О/П (отправитель / получатель). Адрес О/П содержит информацию, позволяющую системе обработки сообщений однозначно идентифицировать пользователя для доставки ему сообщения или выдачи уведомления. Существует четыре формы адресации:

  • Мнемонический адрес О/П - обеспечивает удобное средство идентификации пользователей при отсутствии справочника (такой тип адресации используется наиболее часто).
  • Термический адрес О/П - обеспечивает средства идентификации пользователей, определяемые используемыми терминалами.
  • Цифровой адрес О/П - обеспечивает средства идентификации пользователей с помощью цифровых клавиатур.
  • Почтовый адрес О/П - обеспечивает средства идентификации отправителей и получателей физических сообщений.

Атрибуты адресов в зависимости от формы приведены в таблице.
  Формы адреса О/П
Тип атрибутаМнем.Цифр. Почт.Терм.
   ФН 
123456
Общего назначения     
Имя административного регионаООООУ
Общее имяУ----
Имя страныООООУ
Сетевой адрес----О
Цифровой идентификатор пользователя-О---
Имя организацииУ----
Имена организационных модулейУ----
Личное имяУ----
Имя частного регионаУУУУУ
Идентификатор оконечного устройства----У
Тип оконечного устройства----У
Почтовая маршрутизация     
Служба физической доставки--УУ-
Имя страны физической доставки--ОО-
Почтовый код--ОО-
123456
Почтовая адресация     
Компоненты расширенного почтового адреса О/П--У--
Компоненты расширенного адреса физической доставки--У--
Локальные почтовые атрибуты--У--
Имя учреждения физической доставки--У--
Номер учреждения физической доставки--У--
Имя организации физической доставки--У--
Личное имя физической доставки--У--
Адрес почтового ящика--У--
Адрес до востребования--У--
Адрес улицы--У--
Неформатированный почтовый адрес---О-
Уникальное почтовое имя--У--
Региональный     
РегиональныйУУ--У

Примечания: Мнем. - мнемонический; Ф - форматированный; Цифр. - цифровой; Н - неформатированный; Почт. - почтовый; О - обязательный; Терм. - термальный; У - условный.

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

Межперсональный заголовок состоит из следующих полей:

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

Допустимо преобразование старого адреса в формат Х.400. Для переводов форматов существуют рекомендации RFC 1327 и 1506 по переводу адресов и сообщений Х.400 в формат RFC 822. Кроме того, существует программное обеспечение, предназначенное для конвертации адресов.

Возможности СОС по защите информации

Угроза защите информации

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

  • Маскирование. Происходит, когда пользователь СПС, ХС или АПС маскируются под другого пользователя СПС, ХС или АПС.
  • Нарушение последовательности сообщений. Имеет место, когда часть сообщения или все сообщение повторяется, смещается во времени или переупорядочивается.
  • Модификация информации. Искажения маршрутной и другой управляющей информации, разрушение сообщений.
  • Отклонение услуги. Отклонение услуги происходит, когда объект не выполняет своей функции или препятствует другим объектам выполнять свои функции.
  • Утечка информации. Информация может быть получена неполномочной стороной путем контроля передач, несанкционированного доступа к информации, хранимой у любого объекта СОС, либо путем маскирования.
  • Отрицание. Отрицание может произойти, когда пользователь СПС отказывается от представления, приема или отправки сообщения.
  • Прочие угрозы СОС.

Защиту может обеспечить включение в различные компоненты системы обработки сообщений специальных механизмов безопасности. К ним относятся:

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

Средства защиты СОС

  1. Аутентификация отправителя сообщения - дает возможность получателю или любому АПС, через который проходит сообщение, аутентифицировать подлинность отправителя сообщения.
  2. Аутентификация отправителя отчета - позволяет отправителю аутентифицировать источник отчета о доставке/недоставке.
  3. Аутентификация отправителя зонда - позволяет любому АПС, через который проходит зонд, аутентифицировать источник зонда.
  4. Подтверждение доставки - позволяет отправителю сообщения аутентифицировать доставленное сообщение, его содержимое, и подлинность получателя.
  5. Подтверждение предоставления - позволяет отправителю сообщения аутентифицировать предоставление сообщения СПС для доставки первоначально назначенному получателю.
  6. Защита управления доступом - предусматривает аутентификацию между смежными компонентами и установку контекста защиты.
  7. Целостность содержимого - дает возможность получателю убедиться в том, что исходное содержимое сообщения не было изменено.
  8. Конфиденциальность содержимого - предотвращает несанкци-нированное раскрытие содержимого сообщения.
  9. Конфиденциальность потока сообщений - позволяет отправителю сообщения скрыть поток сообщений через СОС.
  10. Целостность последовательности сообщений - позволяет отправителю подтвердить для получателя сохранность последова-тельности сообщений.
  11. Бесспорность отправителя - подтверждает происхождение сообщения и его содержимого, тем самым предотвращая любую попытку отправителя отрицать посылку сообщения или его содержимое.
  12. Бесспорность доставки - обеспечивает отправителю сообщение подтверждения доставки.
  13. Разметка защиты сообщения - обеспечивает возможность определить категорию сообщения, указав его конфиденциальность, которая определяет обработку сообщения в соответствии с действующей дисциплиной защиты.

Использование Х.400

О поддержке данного стандарта объявили многие крупные производители аппаратного и программного обеспечения, включая IBM, AT&T, Hewlett-Packard, DEC, Data Genera, Sun, Retix, Nexor. Сейчас применяется две версии Х.400 - одна основана на стандарте 1984 года, другая - на стандарте 1988 года. Третья версия была анонсирована в 1992 году.

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

В США фирмой Nexor разработан стандарт для военных систем обработки сообщений АСР-123, основанный на рекомендации Х.400. Военные системы передачи сообщений требуют более высоких гарантий безопасности, чем те, которые предоставляют существующие коммерческие системы.

Россия не отстает от Запада; у нас также развернуты сети на базе стандарта Х.400. Это служба REX400 Института автоматизированных систем (сеть Х.25 ИАСНЕТ), АО "Клуб 400", а также служба Rosmail компании "Русская Коммерческая Инициатива" (сеть Х.25 РОСНЕТ, так называемая R400).

R400 является многофункциональной почтовой системой, позволяющей обмениваться сообщениями не только в рамках почтовой сети Х.400, но также по факсу и телексу. В рамках R400 реализованы шлюзы с почтовыми сетями Novell MHS, REMART и RELCOM. В результате пользователям системы R400 доступны практически все виды электронных коммуникаций. Стержнем и понятийным базисом R400 является Х.400.

Выводы

Сравним еще раз службы обмена сообщениями Х.400 и SMTP. На сегодняшний день передача сообщений по сети Интернет с помощью SMTP/MIME не гарантирует безопасности и надежности, которая доступна при использовании Х.400. Служба электронной почты в TCP/IP создавалась для передачи простых сообщений, Х.400 может обрабатывать базы данных, финансовые транзакции, голосовую почту, оцифрованные видео-, аудио- и фотоформаты. Вместе с Х.500 стандарт Х.400 становится глобальным средством коммуникации в современном деловом мире.

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...