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

25.01.2017

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

    Уважаемые читатели!

    Мы продолжаем знакомить вас с колонкой Криса Дейта, которую он на протяжении нескольких лет ведет в журнале DataBase Programming & Design. В сентябрьском номере г. Дейт размышляет относительно сути понятия инкапсуляции, которое многие считают одним из основных в объектно-ориентированном подходе. Во многом эта заметка опирается на вышедшую в начале лета 1998 г. книге Криса Дейта и Хью Дарвина "Основания объектно-реляционных баз данных: Третий манифест". Книга действительно очень интересна, хотя во много не является бесспорной. Аналогично, материал, краткое изложение которого представляется вашему вниманию, интересно и убедительно написан, но почти сразу с некоторыми идеями автора хочется спорить.

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

    Возможно, я просто привык читать г. Дейта, но мне это действительно доставляет удовольствие. Хотелось бы верить, что и вам тоже.

    С уважением, Сергей Кузнецов


According to Date

Encapsulation Is a Red Herring

C.J. Date

DataBase Programming & Design OnLine, September 1998
Оригинал статьи можно найти по адресу http://www.dbpd.com/9809date.html

И, может быть, лучше было бы отказаться от этого термина

Инкапсуляция широко воспринимается как ключевое свойство или премущество объектной технологии. Однако, по мнению автора, понятие инкапсуляции всегда несколько переоценивалось; более важным является проведение четкого различия между типами и представлениями. Как показывает название этого материала, автор считает инкаплуляцию саму по себе в чем-то похожей на "ржавую середку" [если читателей заинтересует происхождение такой странной метафоры, рекомендую заглянуть на Web-страницу журнала Red Herring - www.herring.com/about/lore.html (прим. С.Кузнецова)] и постарается далее это объяснить.

Что означает инкапсуляция?

Говорят, что тип данных инкапсулирован, если экземпляры этого типа не имеют видимых пользователям компонентов. (Термин "экземпляр" используется как удобное, хотя и неуклюжее сокращение для "значение или переменная".) Например, в своей книге Smalltalk-80: The Language and It's Implementation (Addison-Wesley, 1983) Adele Goldberg и David Robson говорят: "Объект состоит из некоторой частной памяти и набора операций ... Публичные свойства объекта являются [спецификациями операций], составляющими его интерфейс... Частные свойства объекта - это набор [компонентов], составляющих его частную память".

Замечание: Автор предпочитает не использовать слишком часто термин "объект", потому что он нечеткий и часто приводит к неправильному пониманию сути. Ниже этот термин используется только в цитатах.

Как явствует из приведенного высказывания, пользователи Smalltalk оперируют экземплярами ("объектами") инкапсулированного типа посредством операций, явно определенных в связи с этим типом. Например, можно иметь тип CIRCLE и быть в состоянии вызывать операции, которые возвращают площадь - или длину окружности, или радиус (и т.д.) - любого заданного круга. Однако было бы незаконно утверждать, что круг имеет компонент площади, компонент длины окружности, компонент радиуса и т.д. Важным следствием этого является то, что мы не знаем и не должны знать, как круги представлены внутри системы; это представление доступно только через код, реализующий операции. Другими словами, для пользователей представляет интерес тип - это часть модели, - в то время как представление интересно только для реализации. В своем введении в объектные базы данных Stanley Zdonik и David Maier говорят: "Инкапсуляция [означает, что у каждого типа имеется] набор [операций и] представление ... которое выделяется для каждого его экземпляра. Это представление используется для сохранения состояния объекта. Только методы, реализующие операции объектов, имеют доступ к представлению, что дает возможность изменять представление не затрагивая оставшуюся часть системы. Требуется только переписать методы".(1)

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

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

Последнее замечание по поводу термина. При подготовке этого материала автору пришлось просмотреть около 20 книг по объектной технологии и связанным темам. Удивительно, что ни в одной из них не удалось найти точное определение понятия инкапсуляции. (Лучшее разъяснение содержится в приведенной выше цитате из книги про Smalltalk; следует заметить, помимо прочего, что в этой книге вообще не используется термин "инкапсуляция", его нет даже в индексе.) Автор обнаружил, что некоторые авторы понимают под этим понятием физическое связывание определений представления данных и определений операций. Например, "Инкапсуляция - это понятие соединения обработки или поведения с экземплярами объектов, определенных в классах. Инкапуляция позволяет упаковывать вместе код и данные".(2) Но, по мнению автора, такая интерпретация термина приводит с перемешиванию модельных и реализационных вопросов. Пользователь не должен беспокоиться, у него не должно возникать поводов для беспокойства по поводу того, "упакованы ли вместе" код и данные. Убеждение автора состоит в том, что с точки зрения пользователя, т.е. с модельной точки зрения, инкапсуляция означает, что данные не содержат видимых пользователям компонентов и могут быть доступны только через посредство уместных операций.

Но что насчет непредвиденных запросов?

Инкапсуляция вступает в некоторый конфликт с потребностью выполнять непредвиденные запросы. Инкапсуляция означает, что доступ к данным может быть произведен только через заранее определенные операции, а смысл непредвиденных запросов, почти по определению, состоит в том, что требуется доступ, способ которого невозможно предопределить. Например, пусть имеется тип данных POINT; предположим, что также имеется (предопределенная) операция для "взятия" (чтения или выборки) X-координаты заданной точки, но нет подобной операции для соответствующей Y-координаты. Тогда невозможно выполнить даже следующие простые запросы и множество подобных:

  • Получить Y-координату точки P
  • Выбрать все точки по оси X
  • Выбрать все точки со значением ординаты меньшим пяти.

В Third Manifesto (3) Крис Дейт и Хью Дарвин для разрешения этого конфликта предлагают потребовать, чтобы для каждого заданного типа были определены операции, раскрывающие некоторое возможное представление экземпляров этого типа (авторы называют такие операции "THE_operators"). Для типа POINT, например, можно было бы определить операции THE_X и THE_Y, что позволило бы производить следующие действия:

	Q := THE_Y (P) ;
	/* получить Y-координату точки P и присвоить ее Q */
	Z := SQRT ( THE_X (P) ** 2 + THE_Y (P) ** 2 ) ;
	/* получить расстояние до точки P от точки (0,0) и присвоить его Z */

Таким образом, THE_X и THE_Y действительно раскрывают возможное представление - а именно, декартовы координаты X и Y - и обеспечивают возможность выполнять непредвиденные запросы с точками. Однако это не означает того, что внутри системы точки действительно представлены декартовыми координатами; это значит лишь то, что декартовы координаты являются возможным представлением. В реальном представлении могут использоваться декартовы координаты, полярные координаты R и U или что-нибудь совсем другое. Другими словами, THE_операции не нарушают инкапсуляцию и не подрывают независимость данных. Заметим, кстати, что типы данных DATE и TIME языка SQL представляют пример встроенных типов с раскрытием некоторых возможных представлений. Например, для дат раскрывается возможное представление с компонентами YEAR, MONTH и DAY. Хотя, вероятно, следует добавить, что эти "возможные" представления в SQL, к сожалению, близки к реальным представлениям; в SQL различие между типами и представлениями часто не является четким.

Нам не всегда желательна инкапсуляция

Еще одна причина, которая заставляет автора считать инкапсуляцию не настолько важным понятием, как это полагается в литературе, состоит в следующем. Некоторые типы являются совсем не инкапсулированными, и это никому не мешает! В частности, это относится к "генерируемым" типам, которые определяются с использованием генераторов типов, такие как ARRAY, LIST, TUPLE и RELATION. Рассмотрим для определенности RELATION. Предположим, что теперь мы имеем дело с relvar (relation variable) POINT:

	VAR POINT ... RELATION { X ..., Y ... } ... ;
	/* для простоты типы атрибутов X и Y опущены */

Замечание: Определение сформулировано на языке Tutorial D, который определен в Third Manifesto для иллюстративных целей. Многоточия в определении поставлено вместо конструкций, не являющихся существенными для этого обсуждения.

В этом определении для указании (генерируемого) типа relvar используется генератор типов RELATION; это конкретный тип отношения, а именно:

	RELATION { X ..., Y ... }
	/* снова для простоты типы атрибутов X и Y опущены */

И этот тип определенно не является инкапсулированным: у него имеются видимые пользователям компоненты - атрибуты X и Y. И именно наличие этих видимых пользователям компонентов позволяет выполнять над relvar POINT непредвиденные запросы; например, можно выполнить проецирование на атрибут Y, ограничение по условию "значение Y меньше пяти".

Заметим мимоходом, что похожие наблюдение содержатся в книге Mike Stonebraker про объектно-реляционные СУБД: "Базовые типы полностью инкапсулированы. Единственный способ манипулировать [экземпляром] базового типа состоит в том, чтобы выбрать его и выполнить функцию, принимающую [экземпляр этого типа] в качестве аргумента. В противоположность этому, составные типы полностью прозрачны. Можно видеть все поля, и они легко доступны в языке запросов. Конечно, промежуточная позиция заключается в том, чтобы допустить в составном объекте наличие публичных (видимых) полей и приватных (инкапсулированных). Этот подход используется в Си++". Однако следует добавить, что остается неясным, проводит ли Стоунбрейкер четкое различие между реальными и возможными представлениями, как это делается в The Third Manifesto.

Вернемся к основному аргументу. Тот факт, что типы отношений не искапсулированы, не означает потерю независимости данных! Например, в случае relvar POINT нет абсолютно никаких причин, по которым нельзя было бы физически представить эту relvar полярными координатами R и U, а не декартовыми координатами X и Y. (Вероятно, это невозможно сделать в сегодняшних продуктах SQL, но это недостаток продуктов. Сегодняшние продукты SQL вообще обеспечивают меньшую независимость данных, чем теоретически в состоянии обеспечить реляционная технология.) Другими словами, даже при использовании не инкапсулированных типов требуется четко различать типы и представления, и "отказ от инкапсуляции" не обязательно ведет к разрушению независимости данных.

Скалярные и не скалярные типы

В The Third Manifesto авторы требуют поддержки генераторов типа TUPLE и RELATION; в результате пользователи могут определять свои собственные типы кортежей и отношений. Кроме того, требуется, чтобы пользователи могли определять "простые" типы, такие как POINT, LENGTH, AREA, LINE и т.д., возможно, даже типы, подобные INTEGER, если система не обеспечивает их как встроенные типы. И термин "скалярный тип" относится к таким "простым" типам (после чего можно говорить о скалярных значениях, скалярных переменных и скалярных операциях).

Причины выбора термина "скаляр" заключались в следующем:

  • он уже используется (используется в том же смысле в течение многих лет в мире языков программирования);
  • термин кажется корректным по сравнению с такими терминами как tuple и relation (а также array, list и прочее); термин корректен, хотя физическое представление "скалярных" значений и переменных может быть произвольно сложным; например, данное скалярное значение может иметь физическое представление в виде массива стеков списков символьных строк (снова подчеркнем важность различения типов и представлений).

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

Замечание: Можно говорить, что скалярные (или, если это больше нравится, инкапсулированные типы) являются атомарными, поскольку не содержат видимых пользователям компонентов.

Заключение

В этой заметке автор пытался показать, что термин "инкапсулированный" вызывает больше беспокойств, чем того стоит:

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

Литература

  1. Zdonik, S.B. and D. Maier. "Fundamentals of Object-Oriented Databases". Readings in Object-Oriented Database Systems. Morgan Kaufmann, 1990.
  2. Barry, D.K. The Object Database Handbook: How to Select, Implement, and Use Object-Oriented Databases. John Wiley & Sons, 1996.
  3. Date, C.J. and H. Darven. Foundations for Object/Relational Databases: The Third Manifesto. Addison-Wesley, 1998.
  4. Stonebraker, M. (with D. Moore). Object-Relational DBMSs: The Next Great Wave. Morgan Kaufmann, 1996.

Подписка на новости 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@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 This Web server launched on February 24, 1997
    Copyright © 1997-2017 CIT, © 2001-2017 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...