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

26.03.2017

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

NULL, трехзначная логика и неопределенность в SQL: критика критики Дейта

Клод Рубинсон
Пересказ: Сергей Кузнецов
Оригинал: Claude Rubinson. Nulls, Three-Valued Logic, and Ambiguity in SQL : Critiquing Date’s Critique. SIGMOD Record, December 2007 (Vol. 36, No. 4),

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

Сергей Кузнецов

Аннотация

Широко известная критика Дейта (C.J. Date) трехзначной логики языка SQL [4, 3] направлена на то, чтобы показать, что SQL-запросы могут приводить к ошибочным результатам, если в базе данных присутствуют неопределенные значения. В данной статье утверждается, что эта критика ошибочна, поскольку Дейт неправильно понимает смысл запросов, используемых в своих примерах. На самом деле, SQL возвращает на эти запросы правильные ответы, просто Дейт полагает, что он задавал другие вопросы. Хотя критика Дейта ошибочна, автор согласен с его общим заключением: использование в SQL неопределенных значений и трехзначной логики исключительно усложняет простые на вид запросы.

1. Введение

Распространенная критика языка SQL состоит в том, что поддержка в языке неопределенных значений разрушает реляционную модель. Дейт приводит ряд доводов в пользу этой позиции. Наиболее фундаментальным является тот довод Дейта, что поскольку в SQL NULL определяется не как значение, а как некоторый флаг, означающий отсутствие значения в некотором атрибуте, домены не могут должным образом содержать неопределенные значения, поскольку, по определению, домены являются множествами значений. Следовательно, отношения, включающие неопределенные значения, отношениями, по существу, не являются, что подрывает самые глубинные основы реляционной модели [3]. Дейт также приводит более доступный аргумент, в котором он утверждает, что трехзначная логика, вытекающая из наличия неопределенных значений, может приводить к появлению абсурдных результатов. В этой заметке критикуется этот второй аргумент и демонстрируется, что Дейт неправильно использует трехзначную логику SQL. Поэтому критика Дейта является логически ошибочной и в действительности не может служить обвинением в адрес SQL, как это полагает Дейт. Однако следует заметить, что эта критика критики Дейта не направлена на защиту неопределенных значений или трехзначной логики в SQL. Скорее она призвана подчеркнуть, что трехзначная логика действительно может сбивать людей с толку. Использование неопределенных значений меняет смысл простых на вид запросов и, по всей вероятности, может приводить к многочисленным ошибкам, которые зачастую могут не опознаваться.

2. Критика Дейта

В наиболее известных критических замечаниях Дейта используется простая табличная база данных, проиллюстрированная на рис. 1. Она состоит из двух таблиц. В таблице Suppliers (S, «поставщики») имеются два столбца: номер поставщика (SNO, первичный ключ) и город, в котором располагается поставщик (CITY). В таблице Parts (P, «детали») также имеются два столбца: номер детали (PNO, первичный ключ) и город, в котором располагается данная деталь (CITY). В примере на рис. 1 каждая из таблиц содержит по одной записи. Поставщик S1 располагается в Лондоне, а город, в котором располагается деталь, неизвестен P1.

Неопределенные значения часто вносят путаницу, когда неизвестны причины отсутствия информации в базе данных. К наиболее распространенным причинам неполноты данных является (временная) неизвестность значения некоторого атрибута и неприменимость данного атрибута к представляемой в базе данных сущности. Из обсуждения Дейта базы данных, представленной на рис. 1, очевидно следует, что NULL в таблице P означает (временную) неизвестность города, ассоциированного с деталью P1. В заключительном разделе данной заметки обсуждаются дополнительные сложности, вытекающие из неоднозначности смысла неопределенных значений.

S SNO* CITY P PNO* CITY
  S1 London   P1 NULL

Рис. 1. SQL-ориентированная база данных

В [4, стр. 54] Дейт стремится показать, что использование в SQL трехзначной логики приводит к получению ошибочных результатов:

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

Для этого он формулирует на SQL следующий запрос: «Выдать пары SNO-PNO, для которых либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)» [4, стр. 54], получая следующий текст:

SELECT S.SNO, P.PNO
FROM S, P
WHERE S.CITY <> P.CITY
OR P.CITY <> ‘Paris’

После подстановки данных из примерной базы данных условие S.CITY <> P.CITY OR P.CITY <> ‘Paris’ принимает вид (‘London’ <> NULL) OR (NULL <> ‘Paris’), при вычислении которого в соответствии с правилами трехзначной логики SQL получается NULL. Следовательно, в ответ на этот запрос не возвращается ни одного кортежа.

В [4, стр. 55] Дейт утверждает, что этот результат демонстрирует ошибку в трехзначной логике SQL, аргументируя это следующим образом:

Но, конечно, в реальном мире детали P1 в действительности соответствует некоторый город; другими словами, «неопределенное значение атрибута CITY» детали P1 на самом деле обозначает некоторое реальное значение, скажем xyz. Очевидно, что xyz либо равняется значению ‘Paris’, либо не равняется этому значению.

Затем Дейт демонстрирует, что условное выражение раздела WHERE будет всегда вычисляться в TRUE независимо от того, где располагается деталь P1. По существу, имеются три возможности: город xyz является Парижем, Лондоном или еще каким-нибудь городом. Если город xyz является Парижем, то выражение раздела WHERE принимает вид (‘London’ <> ‘Paris’) OR (‘Paris’ <> ‘Paris’). Это выражение приводится к (TRUE OR FALSE), что, в свою очередь, вычисляется в TRUE. Если город xyz является Лондоном, то выражение раздела WHERE принимает вид (‘London’ <> ‘London’) OR (‘London’ <> ‘Paris’), это выражение приводится к (FALSE OR TRUE), что вычисляется в TRUE. Если город xyz является каким-либо другим городом, например, Нью-Йорком, то выражение раздела WHERE принимает вид (‘London’ <> ‘Нью-Йорк’) OR (‘Нью-Йорк’ <> ‘Paris’). Это выражение приводится к (TRUE OR TRUE), что опять-таки вычисляется в TRUE.

В соответствии с Дейтом, если бы в SQL правильно принимался во внимание реальный мир – в данном случае тот факт, что деталь ассоциирована с некоторым городом, несмотря на то, что этот факт отсутствует в базе данных, – то в ответ на приведенный выше запрос должна была бы выдаваться пара S1-P1. То, что SQL возвращает пустой результат, свидетельствует об ошибке в его логике: «Другими словами, результат, корректный в соответствии с логикой (т.е. 3VL), отличается от результата, корректного в соответствии с представлениями реального мира».

3. Критика критики

Но Дейт ошибается. Проблема состоит не в том, согласуются ли с реальностью результаты SQL, а в том, что Дейт неудачно формулирует свой исходный запрос «Выдать пары SNO-PNO, для которых либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)». Формулировка на SQL на самом деле не соответствует этому запросу. В действительности, запрос Дейта не может быть правильно транслирован на SQL, поскольку он предполагает наличие традиционной двухзначной логики, а SQL имеет дело с трехзначной логикой.

В традиционной логике высказывания бывают истинными или ложными. Т.е. деталь P1 располагается в Париже или не располагается. В трехзначной логике, используемой в SQL, высказывания бывают истинными, ложными или неизвестными (unknown). После появления возможности неизвестных высказываний деталь P1 не обязана располагаться или не располагаться в Париже. Теперь мы можем знать, что деталь P1 располагается в Париже, что деталь P1 не располагается в Париже, а можем не знать, где располагается деталь P1.

Запросы необходимо формулировать в соответствии с требованиями используемой в языке запросов логической системы. В традиционной двухзначной логической системе должна иметься возможность классификации утверждений на «истинные» и «ложные». При использовании трехзначной логической системы должны также допускаться «неизвестные» утверждения. В исходном запросе Дейта подразумевается двухзначная логика. Рассмотрим первую часть запроса: «Выдать пары SNO-PNO, для которых … поставщик и деталь располагаются в разных городах». В этом запросе подразумевается, что города, в которых располагается поставщик и деталь, либо различны, либо совпадают. Но в трехзначной логической системе SQL города поставщика и детали могут совпадать, могут не совпадать, а может быть просто неизвестно, различны они или совпадают. Аналогично обстоит дело со второй частью запроса: ««Выдать пары SNO-PNO, для которых … город, в котором располагается деталь, не является Парижем». И в этом запросе подразумевается, что город, в котором располагается деталь, либо является, либо не является Парижем. Однако в контексте SQL этот город может быть Парижем, может не быть Парижем, а может быть просто неизвестен. И в действительности неопределенное значение в базе данных показывает, что мы не знаем, с каким городом ассоциирована деталь P1.

Дейт утверждает, что «в реальном мире» город, в котором располагается деталь P1, либо является, либо не является Парижем. Конечно, это верно. Но также верно и то, что «в реальном мире» мы можем не знать, какой город ассоциирован с деталью P1. Это два разных высказывания. Города, которым соответствуют детали, представляют собой множество фактов, которое существует независимо от того, знаем ли мы, какие города соответствует каким фактам. В SQL запросы всегда подразумевают знание подобной взаимосвязи, а не просто ее существование. Поэтому исходный запрос Дейта можно переформулировать следующим образом: «Выдать пары SNO-PNO, для которых известно, что либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)». Теперь результаты SQL-запроса имеют смысл. Возвращается пустой результат, поскольку, хотя детали P1 «в реальном мире в действительности соответствует некоторый город», неизвестно, какому городу соответствует данная деталь.

Это понимание различий между двухзначной и трехзначной логикой становится более отчетливым после анализа второго примера Дейта. Дейт [4, стр. 55] демонстрирует следующий оператор SQL:

SELECT P.PNO
FROM P
WHERE P.CITY = P.CITY

и утверждает, что «в реальном мире результатом этого запроса, очевидно, являлось бы все множество номеров деталей, содержащихся в P». Но, на самом деле, очевидно то, что Дейт считает приведенный SQL-запрос функционально эквивалентным следующему: «Выдать номера PNO для деталей, ассоциированных с городами». На основании того, что «в реальном мире» каждая деталь должна ассоциироваться с некоторым городом, Дейт заключает, что этот запрос должен полное множество номеров деталей. Но Дейт снова неправильно читает запрос. Поскольку в SQL используется трехзначная логика, этот оператор SQL выражает совсем другой запрос: «Выдать номера PNO для деталей, про которые известно, что они ассоциированы с городами». И SQL совершенно справедливо возвращает пустой результат, поскольку, как показывает таблица P, мы не знаем, с каким городом ассоциирована деталь P1.

В [4, стр. 55] Дейт утверждает, что его примеры демонстрируют полную несостоятельность SQL:

Подводя итоги, следует заметить, что если в вашей базе имеются неопределенные значения, вы будет получать на некоторые запросы неправильные ответы. Хуже того, нет никакого способа узнать, какие запросы будут выдавать неправильные результаты; все результаты становятся подозрительными. Никогда нельзя доверять ответам, которые получаются из базы данных с неопределенными значениями. По моему мнению, это состояние дел свидетельствует о невозможности использования SQL. (Курсив К. Дж. Дейта.)

Как полагает автор данной заметки, Дейту не удалось продемонстрировать несостоятельность SQL. Для сформулированных Дейтом запросов SQL возвращает корректные ответы, но не те, на которые он рассчитывал. Эта путаница вполне объяснима. Трехзначная логика SQL не является интуитивной. При использовании двухзначной логики высказывания могут быть истинными или ложными. Но в трехзначной логике возможны еще и неизвестные высказывания. При работе с SQL-ориентированными базами обязательно требуется корректная формулировка запросов; в противном случае имеется риск совершения ошибок, подобных тем, которые делает Дейт.

4. Обсуждение

Использование в SQL трехзначной логики и маркера неопределенных значений приводит к требованию учета при формулировке запросов возможности того, что связи между сущностями являются неизвестными. Если это сделать не удается, возникает риск формулировки не того вопроса, который предполагался. Нужно помнить, что логика SQL не является интуитивной. Редко удается прямо отобразить в SQL вопросы, используемые людьми при обычном общении. Нельзя просто спросить про «пары SNO-PNO, для которых города поставщика и детали не совпадают», а требуется задавать вопрос относительно «пары SNO-PNO, для которых известно, что города поставщика и детали не совпадают». Еще более важно то, что нужно понимать, в чем состоит различие этих формулировок.

Проблема усугубляется тем фактом, что информация может отсутствовать в базе данных по ряду разных причин. В [1] Дейт указывает семь распространенных причин неполноты данных: значение не применимо, значение неизвестно, значение не существует, значение не определено, значение не достоверно, значение не предоставлено и значением является пустое множество. Если значение может отсутствовать, например, из-за неприменимости некоторого атрибута, запросы должны формулироваться и интерпретироваться с учетом потенциального обстоятельства. Если маркеры неопределенных значений нагружаются разным смыслом, построение запросов быстро становится очень сложной задачей: «выдать пары SNO-PNO, для которых атрибут города детали является применимым, и для которых известно, что поставщик и деталь располагаются в разных городах, или городом детали не является Париж» (или выполняются все три условия). Для решения этой проблемы некоторые практики выступают в пользу описательных истинностных значений [5, 7]. Эти решения, основывающиеся на реальных значениях, а не на маркерах неопределенных значений, позволяют проектировать базы данных без неопределенных значений, запросы к которым могут основываться на традиционной двухзначной логике.

Полезно также заметить, что любой запрос, опирающийся на трехзначную логику, можно декомпозировать в два связанных запроса, опирающихся на двухзначную логику. Например, как обсуждалось выше, запрос «выдать пары SNO-PNO, для которых известно, что городом детали не является Париж» предполагает использование трехзначной логики, поскольку город, в котором располагается деталь, может быть Парижем, может быть не Парижем, а может быть не известен. Этот запрос может быть декомпозирован в составной запрос «выдать пары SNO-PNO, для которых известен город, в котором располагается деталь, и выдать из результирующего множества пары SNO-PNO, для которых городом детали не является Париж». Выполнение такой декомпозиции часто оказывается полезным, особенно при построении сложных запросов.

В конечном счете, автор заметки согласен с Дейтом в том, что трехзначная логика не сочетается с системами управления базами данных. Хотя он не убежден в том, что трехзначная логика нарушает реляционную модель по существу, он согласен с Макговераном (McGoveran) [6, стр. 355] в том, что переход к использованию многозначной логики вынуждает проектировщиков, разработчиков и пользователей баз данных осваивать совершенно новый способ мышления. Трудно оценить практически требуемые затраты, но, конечно, потребность в них противоречит целям, для достижения которых существуют SQL-ориентированные СУБД.

То, что сам Дейт неправильно понимает смысл своих SQL-запросов, подчеркивает серьезность этой проблемы.

5. Заключение

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

Использование в SQL неопределенных значений – это не самая важная проблема, с которой приходится сталкиваться при наличии базы данных, показанной на рис. 1. Скорее проблема звучит так: «Где же эта чертова деталь P1?». Если деталь P1 везут в Париж, эту информацию требуется сохранить в базе данных. Если деталь P1 потеряется, нужно уметь отразить в базе данных и эту информацию. В частности, включение такой информации в базу данных повышает ценность базы данных и способствует поддержанию ее целостности за счет наличия возможности удалять из нее проблематичных записей.

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

Редко удается гарантировать полное отсутствие неопределенных значений в базе данных. Даже если бы удалось убедить компании-производители СУБД выступить против неопределенных значений и трехзначной логики, мы остались бы обременены этим наследством в обозримом будущем. И поскольку присутствие единственного неопределенного значения влияет на всю базу данных [6], в общем случае необходимо подразумевать наличие трехзначной логики. Поэтому требуется тщательно проверять запросы, чтобы быть уверенными, что они означают в точности то, что предполагалось.

Литература

[1] C. J. Date. Not is not ‘not’! (notes on three-valued logic and related matters). In Relational Database Writings, 1985–1989. Addison Wesley, 1990.

[2] C. J. Date. Relational Database Writings, 1994–1997. Addison Wesley Longman, 1998.

[3] C. J. Date. An Introduction to Database Systems. Addison Wesley Longman, Reading, MA, seventh edition, 2000.

[4] C.J. Date. Database in Depth: Relational Theory for Practitioners. O’Reilly, Sebastopol, CA, 2005.

[5] G. H. Gessert. Handling missing data by using stored truth values. SIGMOD Record, 20(3):30–42, Summer 1991.

[6] David McGoveran. Nothing from nothing (part 2 of 4) classical logic: Nothing compares 2 u. In Relational Database Writings, 1994–1997 [2], chapter 6, pages 347–365.

[7] David McGoveran. Nothing from nothing (part 4 of 4): It’s in the way that you use it. In Relational Database Writings, 1994–1997 [2], chapter 8, pages 377–394.

Размещение рекламы — тел. +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
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...