|
Раздел "*nix". Содержание:
Статьи:
 FreeBSD: физика файловой системы
Новости:
IBM собирается выпустить версию пакета MS Office для Linux
Red Hat улучшит безопасность своих продуктов
IBM открывает в Москве Центр компетенции Linux
Lindows изменила название своих продуктов
Обнаружены несколько дыр в ядрах Linux последних версий
Microsoft подала иск против Lindows в Канаде
Panda Software обновила антивирусы для почтовых серверов Linux
Lindows включила поддержку для Centrino в свою ОС
Red Hat предлагает энтузиастам «Федору»
IBM установила рекорд в тестах на быстродействие
Тройка вынесла приговор Linux-серверам
SCO против Linux:
Lindows.com защитит клиентов от SCO
В Австралии рассмотрят вопрос о правомерности требований SCO
Раздел "*nix". Статьи:
 | FreeBSD: физика файловой системы |
|
Продолжение. Начало в AboutPC #25, 28-29
Вступление незапланированное
Он пришел с лицом убийцы,
С видом злого кровопийцы,
И сказал, что он мой критик,
И добра желатель мой.
Что ему, мол, стиль мой низкий
Эстетически не близкий.
Я фуфло, а он Белинский,
Весь неистовый такой.
Тимур Шаов,
Разговор с критиком
К сочинению настоящего вступления меня побудило большое количество откликов на первые три статьи этого цикла. Которые можно разделить на положительные и критические. Вот я и решил ответить на все, так сказать, оптом.
С откликами первой группы все понятно: могу только поблагодарить за поддержку. Конечно, все свои сочинения писались в первую очередь ради собственного удовольствия, однако приятно, что еще кому-то интересно их читать.
На голословную критику я ответил бы так: уважаемые господа, если вы полагаете, что разбираетесь в рассматриваемых вопросах лучше меня (во что я готов охотно поверить), почему бы вам не уделить толику времени, проводимого в форумных флеймах, просвещению широких народных масс? И не сочинять бы то, что нужно, и так, как нужно, на соответствующие темы? Желательно — русским литературным языком, с минимумом идио-мат-тических выражений. Я же с удовольствием возьму на себя роль внимательного читателя, впитывая всю представленную вами полезную информацию. И критика — с позиций русского литературного языка (интуиция мне посказывает, что поводов для оной будет более чем достаточно).
Тем не менее, должен добавить, что очень признателен за всю критику конструктивного характера. На которую надеюсь и впредь.
Просто вступление
В настоящей заметке речь пойдет о способе физической организации блоков
дискового раздела, обеспечивающем возможность записи, хранения и
манипулирования файлами, специфичном для FreBSD вообще и 5-й ее ветки в
особенности.
Файловая система FreeBSD принадлежит к Unix-семейству
файловых систем и обладает множеством общих для всех них черт. Она носит
название UFS, в 5-й ветке используется ее усовершенствованная разновидность —
UFS2. Для начала рассмотрим общие принципы устройства той и другой, а потом
обратимся к рассмотрению особенностей, свойственных UFS2.
Для файловой системы FreeBSD (и вообще BSD-систем, начиная с 4.2BSD) можно встретить и еще
одно наименование — FFS (Fast File System, обозначение «быстрая» введено в
сравнении с файловой системой Unix System V — s5). В доступной литературе мне
не удалось обнаружить четкой формулировки их взаимоотношения. У меня сложилось
впечатление, что FFS — это родовое обозначение файловых систем всех
операционок BSD-клана (Free-, Net-, OpenBSD и BSDi), тогда как UFS (и UFS2) —
имя конкретной реализации для FreeBSD. Хотя и в NetBSD ныне (начиная с версии
1.6 и выше) наряду с традиционной FFS может использоваться UFS2. В общем,
однозначно осветить этот вопрос затрудняюсь, и потому был бы признателен за
разъяснение.
Как уже было выяснено ранее, дисковая партиция — это,
говоря метафорически, группа смежных цилиндров, разбитых на физические блоки
по 512 байт. Партиция, несущая на себе файловую систему UFS, разделяется на
три самостоятельные области (от начала группы цилиндров к ее концу) —
суперблок, индексную таблицу и область данных. Рассмотрение их целесообразно
начать с конца списка, то есть с области данных.
Блоки данных
Область данных (она занимает подавляющий объем пространства партиции)
образована блоками файловой системы. Подобно физическому блоку, блок файловой
системы (именуемый также блоком логическим) представляет собой квант информации,
доступный за одну операцию чтения/записи, но уже не дисковой головки, а
операционной системы. Очевидно, что логический блок не может быть меньше
физического (то есть 512 байт), и размер его обязательно кратен целому числу
последних.
Понятие логического блока введено для повышения производительности дисковых
операций. Не требует доказательства утверждение, что скорость обмена данными
квантами по 1 Кбайт будет выше, чем 512-байтными, 2-килобайтными — еще быстрее,
и так далее. И потому с точки зрения быстродействия файловых операций выгоден
максимальный размер логического блока файловой системы.
С другой стороны, увеличение размера логического блока
ведет к непроизводительному расходу дискового пространства за счет т.н.
внутренней фрагментации данных. Ее не следует путать с внешней фрагментацией,
для борьбы с которой на файловых системах FAT-семейства были в свое время
мобилизованы всякого рода speeddisk'и с комбатантами: вследствие особенностей
алгоритмов управления данными файловые системы Unix-семейства настолько мало
подвержены внешней фрагментации, что о преодолении оной вообще практически не
говорят.
Внутренняя же фрагментация выражается в том, что данные файлов,
размер которых меньше блока файловой системы, все равно занимают его целиком.
Также целый блок потребуется и для хранения файловых хвостов, то есть остатков
сверх объема, кратного размеру логического блока. Для борьбы с фрагментацией в
UFS, пардон за тавтологию, введено понятие фрагмента — логической части блока
файловой системы, которая может быть записана или считана независимо от
остальной его части.
Ясно, что размер фрагмента все равно не может быть
меньше физического блока. При этом UFS накладывает на него и встречное
ограничение — минимальный размер фрагмента определяется в 1/8 логического
блока. Другие же возможные значения — 1/4 и 1/2 блока файловой системы
(очевидно, что выделение фрагмента в размере блока равносильно отказу от
фрагментации блока вообще, хотя это, как будто бы, не
запрещено).
Inodes
Каким образом определяется принадлежность
блока данных тому или иному файлу? К помощью индексной таблицы, именуемой
также таблицей файловых дескрипторов или таблицей inodes. Она образована
некоторым (конечным) количеством записей фиксированной длины (128 Кбайт в UFS,
256 — в UFS2), каждая из которых однозначно соответствует одному файлу, как
реально существующему, так и только могущему быть созданным.
Такая запись индексной таблицы носит название inode, которое мы и оставим за нею.
Ибо все известные мне переводы этого термина, вроде информационных узлов или
индексных дескрипторов, выглядят очень коряво. Кроме того, слово «дескриптор»
фигурирует еще и в контексте «дескриптор файла», под чем подразумевается
идентификатор (уникальный, иначе что же он будет идентифицировать?) файла,
используемого неким процессом (что уже к файловым системам не имеет ни
малейшего отношения — это сфера подсистемы управления процессами). И эти
дескрипторы — не имеют меж собой ничего общего. Так, inode c идентификатором 2
(а это всегда идентификатор корневого каталога файловой системы) и дескриптор
файла с номером 2 (а им для любого процесса будет стандартное устройство
вывода сообщений об ошибках, /dev/stderr) ни коим образом друг с другом не
соотносятся (хотя об этом почему-то не любят говорить вслух).
Однако я
отвлекся — вернемся к нашим inodes. Каждый член этой таблицы содержит так
называемые метаданные файла. Для реально существующего файла они включают в
себя:
- уникальный идентификатор inode (и, соответственно, файла,
метаданные которого он содержит) — это просто счетчик создаваемых файлов в
файловой системе);
- тип файла — это может быть каталог,
символическая ссылка, файл устройства, именованный канал или сокет, или же
обычный (то есть не относящийся ни к какому из перечисленных типов) файл;
- размер файла в байтах;
- количество ссылок на файл (к этому
вопросу придется вернуться чуть ниже);
- адреса логических блоков и
их фрагментов, составляющих файл;
- число занятых им блоков;
- атрибуты файла — принадлежности, доступа, времени (и это еще не раз будет
предметом подробного рассмотрения).
А вот чего в inode не
обнаружить никакими силами — так это имени соответствующего ему (или ей? — мне
почем-то кажется, что inode, вопреки грамматике, — женского рода). В любой
книжке про Unix не устают повторять (и я не отступлю от этой традиции), что
имя файла — атрибут не самого файла, а каталога, в который он входит.
Поскольку понимание этого потребуется при знакомстве с механизмом Soft Updates
в следующей заметке, сделаю маленькое отступление для прояснения вопроса
именования файлов во FreeBSD (и вообще в Unix).
При описании содержания
таблицы inodes вскользь было упомянуто поле типа файла. Так вот, в Unix все
файлы (а все, что в Unix имеется вообще, включая физические устройства, для
системы представляется в виде файлов) делятся на две группы — каталоги и
прочие. Прочие файлы могут служить для различных целей (хранения данных и
исполняемых программ, быть символическими ссылками, описывать устройства или
средства взаимодействия процессов — обо всем этом мы поговорим своевременно
или несколько позже). Назначение же каталогов — единственное, но оченно
важное: быть хранителями имен входящих в них файлов, которым однозначно
поставлены в соответствие идентификаторы inodes, хранящих метаданные этих
файлов.
То есть имя файла существует только в списке каталога и нигде
более в системе. А создание файла — это не только заполнение относящейся к
нему записи в индексной таблице и заполнение указанных в ней блоков данных, но
и внесение записи вида «идентификатор — имя_файла» в область данных
какого-либо каталога. А каталог, как и любые другие файлы, имеет свои
метаданные в таблице inodes и свою область данных. И, в свою очередь, имя его
вместе с идентификатором inode входит в каталог более высокого уровня, и так —
вплоть до корня файловой системы. В поле количества ссылок inode создаваемого
файла устанавливается минимально возможное значение, равное единице, поскольку
любой файл входит по меньшей мере в один каталог, иначе он просто не будет
доступен системе — файлы с нулевым количеством ссылок для нее как бы не
существуют (и на самом деле их inodes и блоки данных со временем неизбежно
будут перезаписаны физически).
На самом деле один и тот же набор данных
и метаданных может быть приписан к произвольному количеству каталогов в
пределах одной файловой системы и даже фигурировать под разными именами в
одном каталоге — в этом случае количество ссылок на него будет
соответствующим. А вот минимальное количество ссылок на каталог равно двум —
так как запись о нем существует как в родительском каталоге (..), так и в
текущем (. — то есть в самом себе). И каждый вложенный подкаталог увеличивает
счетчик ссылок каталога на единицу.
Ссылки, с помощью которых
связывается имя файла как элемент каталога с его записью в таблице inodes и
блоками образующих файл данных, именуются еще жесткими (hardlinks, хорошим
русскоязычным эквивалентом было бы слово «связь», но оно как-то не прижилось).
Посредством жестких ссылок одному и тому же набору данных или исполняемой
программе можно придать произвольное количество имен, которые никто не
запрещает включить в один и тот же или разные каталоги. Единственное условие
для этого — все эти имена-дублеры должны находиться в каталогах единой
файловой системы, то есть располагаться на одной дисковой партиции. И в одной
из последующих заметок станет ясно, почему.
Забегая несколько вперед,
отмечу, что жесткие ссылки нужно отличать от ссылок символических (symlinks,
часто говорят просто links — почему и резонно было бы сохранит за ними
обозначение ссылок, а hardlinks по русски именовать связями). Символические
ссылки — файлы особого типа, отдаленно сходные с ярлыками в Windows или shadow
в OS/2, которые сами по себе никаких данных не содержат, а просто ссылаются на
метаданные и данные другого файла (который может локализоваться и за пределами
данной файловой системы).
Для файлов несуществующих свободные записи в
таблице inodes просто резервируются. А поскольку количество этих записей —
конечно, именно объем индексной таблицы и определяет, сколько файлов реально
может быть создано в данной файловой системе. Исчерпание свободных записей в
ней приводит к тому, что, вне зависимости от объема свободного дискового
пространства, ни одного нового файла создать не
удастся.
Суперблок
Однако сведений об объеме индексной таблицы
внутри нее не обнаруживается. Ибо место их размещения — тот самый суперблок,
который идет первым в нашей партиции (вообще-то первым в любой партиции будет
загрузочный блок, но реально он занят только в загрузочном же разделе — во
всех остальных для него просто зарезервировано место). Кроме этого, в
суперблоке же записывается размер блока файловой системы и их суммарное
количество, число блоков данных, размер блокового фрагмента и их число в
блоке, число блоков, реально занятых файлами, объем партиции, перманентно
резервируемый как свободный, и еще множество характеристик файловой системы, о
которых сейчас говорить неуместно.
На самом деле описанное выше
несколько упрощено. Специфика файловых систем BSD-клана заключается в том, что
реально дисковая партиция разбивается на части фиксированного объема
(зависящего от объема раздела). Это т.н. группы цилиндров, каждая из которых
имеет свою копию суперблока (чем обеспечивается устойчивость к механическим
повреждениям диска), свой блок группы цилиндров, оную описывающий (в нем, в
частности, содержатся карты свободных/занятых inodes и карты свободных/занятых
блоков данных), собственную таблицу inodes и область блоков данных. Это имеет
целью размещение inodes и относящихся к ним блоков данных максимально близко
друг к другу, что, кроме повышения производительности, влечет за собой и
сведение к минимуму той самой внешней фрагментации данных, о которой
говорилось выше.
Практика форматирования
Таким образом, процесс
создания файловой системы сводится к а) выделению суперблока и записи общих
параметров файловой системы, б) созданию таблицы inodes (в UFS, в отличие от
некоторых современных файловых систем для Linux, все inode создаются раз и
навсегда, а не выделяются динамически, по мере надобности), и в) разметке
блоков в области данных. Из за все это, подобно незабвенной Катерине Матвевне,
отвечает одна-единственная программа, именуемая незамысловато —
newfs.
Команда newfs требует единственного аргумента — имени файла
форматируемой партиции, например,
$ newfs /dev/ad0s1a
после
чего все базовые свойства файловой системы будут определены по умолчанию.
Однако пользователь в силах влиять на них с помощью опций, важнейшие из
которых мы и рассмотрим (или — определив их раз и навсегда глобально, через
sysinstall, но это — тема отдельного разговора).
Опция -b определяет
размер логического блока файловой системы. Минимальный размер его — 4096 байт,
максимальный, насколько я знаю, определяется только здравым смыслов. А с точки
зрения оного, «умолчальное» значение в 16384 байт представляется
разумным.
Опция -f устанавливает размер фрагмента блока. Рекомендуется
определить его в 1/8 размера блока, что по умолчанию и составит 2048 байта.
Значения в 1/4 или 1/2 блока также допустимы, но очень не рекомендуются в
документации.
Опция -i очень важна — она-то косвенно и устанавливает
количество записей в индексной таблице (то есть максимальное количество файлов
в файловой системе). Значение этой опции дается в байтах, отводимых на
элемент индексной таблицы, и должно быть кратным размеру блокового фрагмента.
Значение по умолчанию — учетверенный объем оного, что определяет средний
прогнозируемый размер файла (8096 байт).
Еще одна интересная опция — это -m, значение которой указывается в процентах от суммарного объема дискового
пространства отведенного на партицию. И представляет собой объем,
резервируемый от записи обычными пользователями (но не root'ом — тот всегда
имеет возможность записать свои действия на диск). Он определяется потому, что
быстродействие файловых операций в UFS просто катастрофически падает, когда
количество свободных блоков в области данных близко к исчерпанию (проверено на
практике). И потому некий объем файловой системы резервируется принудительно
(по умолчанию — 8%).
С этой опцией связана еще одна, -o, которая
определяет алгоритм выделения свободных блоков данных при создании новых
файлов. Дело в том, что UFS в состоянии размещать их двумя способами. Первый —
методом плотнейшей упаковки с целью минимизации внутренней фрагментации и
экономии дискового пространства. И называется он оптимизацией по объему (опция -o принимает значение space). Второй же метод (-o time) обеспечивает
быстрейшее выделение свободных блоков с целью увеличения скорости создания
файлов (то есть вопреки принципу Леонида Ильича — «экономика должна быть
экономной»). Так вот, умолчальное значение -o коррелирует со значением -m:
если оно больше или равно 8%, применяется оптимизация по времени, если меньше — по объему. Хотя явным образом можно указать прямо противоположные
значения.
Вообще-то, все приведенные выше опции очень важны, интересны и
полезны для общего образования, однако пользователю вряд ли придется к ним
прибегать: их значения по умолчанию, как и почти все во FreeBSD, разумны и
приемлемы в подавляющем большинстве случаев. А вот опция -U при запуске newfs
по умолчанию не задействуется. Обеспечивает же она поддержку штуки крайне
полезной — механизма Soft Updates, способствующему (парадоксально, но —
правда) как повышению быстродействия файловых операций, так и устойчивости
файловой системы.
Тема Soft Updates, однако, столь интересна сама по
себе, что заслуживает отдельного обсуждения, чем мы и займемся в следующем
разделе этой же заметки. А пока под рассмотрим отличия текущей разновидности
файловой системы FreeBSD, UFS2, от ее предшественницы — UFS.
Все, что
было сказано выше о файловой системе FreeBSD, относилось в равной мере к обеим
ее разновидностям. Главная особенность UFS2 — то, что она 64-разрядная и,
соответственно, способна работать с дисковыми объемами более терабайта
(интересно, скоро это станет актуальным для настольного пользователя? Судя по
темпам дискобольства, срок этот не за горами). В этой связи напомню, что длина
записи в таблице inodes в UFS2 удвоилась, и равна 256 байт.
Далее, в
UFS2 включена поддержка расширенных атрибутов файлов, в частности, ACL, но это
существенно для сетевых администраторов. А вот что может заметить пользователь — то, что создание новой файловой системы происходит быстрее (на больших
дисковых разделах это действительно заметно, что называется,
органолептически). Происходит это за счет т.н. «ленивой» инициализации inodes,
хотя динамического их выделения, как, например, в XFS, и нету. А вообще,
с точки зрения пользователя, различий между UFS и UFS2 можно и не увидеть. Тем
не менее, отказываться от UFS2 также оснований нет. Тем более, что и newfs, о
которой говорилось выше, и sysinstall, о которой разговор впереди, по
умолчанию ныне (в 5-й ветке) создают именно ее. Если же требуется создать
просто UFS (для совместимости с версиями прежних веток, UFS2 не
поддерживающих), это нужно сделать принудительно, указав для newfs опцию -O
1.
Парадокс Soft Updates
При всех своих многочисленных
достоинствах, файловая система FreBSD не может похвастаться одним —
быстродействием. И это не смотря на то, что в основе ее лежит
обще-берклианская FFS — быстрая файловая система. Однако эпитет здесь
выступает в сравнении с прежней Unix'овой файловой системой — s5, все вариации
которой, как говорят знающие люди, отличались исключительной задумчивостью.
Если же сравнить производительность файловой системы FreeBSD с родной для
Linux Ext2fs — оно окажется не в пользу первой, особенно на операциях с
большим количеством мелких файлов.
Почему? Нетрудно ответить: вследствие
принятого во FreeBSD по умолчанию режима обращения с измененными файлами.
Большинство нормальных файловых систем способны функционировать в одном из
трех режимов:
- полностью синхронном, когда обновления и
метаданных, и области данных файла записываются на диск сразу вслед за его
изменением;
- полностью асинхронном, при котором все изменения файла (и
его метаданных, и области данных) кэшируются в оперативной памяти и реально
записываются на диск в подходящее для того время;
- смешанном,
реализующем синхронный механизм для измененных метаданных и кэширование — для
модификаций области данных.
Очевидно, что первый режим обеспечивает
наибольшую устойчивость файловой системы к сбоям, второй — наибольшее
быстродействие файловых операций (ценой возможности нарушения целостности
файловой системы и даже полного ее разрушения при аварийном завершении
работы), а третий обеспечивает как бы компромисс между первым и вторым
решением.
Так вот, в файловой системе Linux (конкретно — в ext2fs, Linux
нынче за родные признает много файловых систем) по умолчанию задействуется
полностью асинхронный режим работы, а во FreeBSD — смешанный. Конечно, это
определяется при монтировании файловых систем, и с помощью соответствующих
опций команды mount (что я покажу в соответствующей заметке) файловую систему
FreeBSD можно заставить работать полностью асинхронно. Однако резонные люди не
рекомендуют это делать категорически — и, вероятно, имеют к тому основания
(одна из причин к тому станет ясной в конце заметки).
И действительно, в
умолчальном режиме файловая система FreeBSD (в сравнении с той же ext2fs)
демонстрирует замечательную устойчивость. За два с половиной года общения с
этой ОС (а из них полтора пришлось на селянские условия, когда неожиданное
отключение электричества были вещью более чем обычной) мне ни разу не пришлось
столкнуться с проблемами из-за аварийного завершения сеанса работы (в Linux'е
такие проблемы, до внедрения журналируемых файловых систем, возникали сплошь и
рядом).
Однако цена за это — быстродействие. Вернее, отсутствие оного. И
проявляется это особенно наглядно именно при копировании большого количества
мелких файлов (процедура, весьма обычная при работе с текстовыми, по
преимуществу, материалами). Действительно, при этом в синхронном режиме
обновляется огромное количество файловых inodes, тогда как собственно данных
изменяется ничтожное по объему количество, и их кэширование доставляет мало
радости. В любом случае копирование набранных в текстовом редакторе
статеюшечек размером с эту заметку и суммарным объемом в стандартный CD
затягивается на вполне чувствительное время (в отличие от Linux'а, где
подобная операция выполняется внешне мгновенно — другое дело, что индикатор
активности жесткого диска может еще долго подмигивать).
Далее, не смотря
на всю свою фактическую устойчивость, файловая система FreeBSD, не будучи
журналируемой, сама по себе не имеет механизма гарантии собственной
целостности. То есть: при аварийном завершении работы, когда в файловой
системе не устанавливается т.н. бит чистого размонтирования (clean byte — это
один из важных параметров файловой системы, записываемый в ее суперблоке при
корректном выходе из системы), в ходе процедуры последующей загрузки
принудительно вызывается программа проверки ее на предмет нахождения
противоречий между метаданными и областями данных (и их устранения). А при
современных объемах дисков (и, соответственно, файловых систем на них) такая
проверка может затянуться на часы. Конечно, это особенно прискорбно для
серверов, но и на настольной машине доставляет мало положительных
эмоций.
Проблема нарушения целостности существует и в Linux'е (по
указанным выше причинам — даже в большей мере). И в Linux'е с нею борются
посредством журналирования, то есть опережающей регистрации изменений
метаданных (и, в некоторых случаях, даже и данных). Во FreeBSD же борьба за
целостность файловой системы велась исторически по двум направлениям. Второе
из них — появившаяся в 5-й ветке фоновая проверка целостности файловой
системы, допускающая начало нормальной работы сразу после аварийной
перезагрузки машины. Поскольку это — одно из принципиальных новшеств, скажу
пару слов по сему поводу.
Для проверки целостности файловой системы во
FreeBSD используется утилита fsck (одноименная есть и в Linux — для ext2fs,
есть аналогичные инструменты и для прочих файловых систем). Она может быть
запущена пользователем (вернее, root'ом) из командной строки. Однако схема
старта системы предусматривает ее автоматический запуск, если в какой-либо из
автоматически монтируемых файловых систем не обнаружен бит чистого
размонтирования. А поскольку fsck — побитная операция, во избежание тяжких
последствий она обычно проводится на размонтированных файловых системах. Что и
было во FreeBSD вплоть до версии, как минимум, 4.6 (более старших из 4-й ветки
уже не видел). А вот в версиях 5-й ветки, начиная с первой, более чем годичной
давности, developer'ской, проверка диска может выполняться на смонтированной и
готовой к работе файловой системе. И, соответственно, в фоновом режиме после
полной загрузки системы, параллельно с выполнением обычной работы. Казалось бы — пустячок, а приятно: затрудняюсь сказать, сколько заняла бы полная проверка
обычных ныне 80- или 120-гигабайтных винтов.
Однако первым по времени
реализации способом борьбы за целостность файловой системы был механизм Soft
Updates, обеспечивающий одновременно (вернее, главным образом) и повышение
быстродействия файловых операций.
Сам по себе механизм Soft Updates
(оставим этот термин без перевода — варианты оного типа «мягких обновлений» не
только не блещут литературным изяществом, но и сути дела не проясняют)
детально описан в специальной статье Макказика и Ганджера, смысла
пересказывать которую я не вижу (благо она имеется в русском переводе). В двух же
словах суть этого механизма — в сведении к минимуму синхронных операций записи
без явно асинхронного манипулирования метаданными, с одной стороны, но и без
предварительного журналирования метаданных (как в файловых системах типа
ReiserFS или XFS) — с другой.
Реализуется это, опять же говоря довольно
грубо (детали реализации моему пониманию недоступны — каюсь) за счет так
называемых зависимостей обновления. Что такое эти зависимости — интуитивно
ясно из примера создания нового (для простоты — пустого) файла. Для этого
требуется:
- запись в таблице inodes, с заполнением полей типа
файла, его идентификатора, счетчика ссылок (со значением 1 — каждый файл
должен принадлежать как минимум одному каталогу), ну и прочих там — прав
доступа в соответствие с их маской, и так далее;
- изменение карты
свободных/занятых inodes в блоке группы цилиндров (соответствующий новому
файлу inode должен быть помечен в ней битом занятости);
- внесение записи
вида «идентификатор — имя_файла» в структуру каталога, в котором новый файл
создается, что обеспечивает ту самую единственную ссылку в соответствующем
поле inode файла.
С точки зрения целостности файловой системы, эти
операции должны быть выполнены именно в этой последовательности. То есть
наличие в каталоге имени файла с идентификатором незаполненного (еще не
созданного или уже уничтоженного) inode — явный непорядок: именно для
исправления такого рода безобразий и запускается программа проверки диска
после аварийного завершения сеанса.
Выполнять связанные зависимостями
операции обновления в синхронном режиме — долго (каждая потребует своего
обращения к диску), в асинхронном — нет гарантии сохранения последовательности
(обновления в кэше могут быть записаны тогда, когда бог на душу положит). Так
вот, механизм Soft Updates обеспечивает, с одной стороны, контроль за
последовательностью выполнения зависимых обновлений (что способствует
целостности состояния файловой системы), с другой — группирует их в единую
атомарную операцию синхронного обращения к диску, за счет сокращения числа
коих и растет производительность. В этом, насколько я понимаю, и состоит
объяснение парадокса Soft Updates — неожиданного увеличения и надежности, и
быстродействия.
В общем, постарался объяснить, как смог и как сам понял — за подробностями к упомянутой статье. В дополнение только замечу — во
избежание недоразумений: механизм Soft Updates не только не гарантирует
сохранности пользовательских данных, не сохраненных по раздолбайству юзера
перед крахом системы, но и не преследует такой цели. Его призвание — следить,
чтобы файловая система всегда представала по возможности в непротиворечивом
виде. Впрочем, то же можно сказать и о любой журналируемой файловой системе —
ни одна из них не страхует от ошибок пользователя...
Теперь посмотрим,
как же Soft Updates можно использовать. Если создавать файловые системы через
sysinstall — все просто: там по умолчанию включение этого механизма уже давно
(версии примерно с 4.3) предусмотрено для всех файловых систем, кроме
корневой. Последнее аргументируется соображениями безопасности, которые (для
настольной машины) не кажутся мне убедительными — так что я включаю ее и
здесь. Хотя именно для корневой файловой системы Soft Updates не особо нужна:
при правильном разбиении диска и грамотной эксплуатации запись в нее (после
первичной установки) происходит только при инсталляции нового ядра, а часто ли
это проделывается в нормальных условиях?
При создании же файловых систем
вручную, командой newfs, Soft Updates автоматически не включается: это нужно
сделать, как уже говорилось, указанием опции:
$ newfs -U /dev/ad#s#?
Впрочем, если она при форматировании была забыта — ничего
страшного: для всех разделов, кроме корневого, включить Soft Updates легко с
помощью команды tunefs. Для этого следует перейти в однопользовательский режим
(очень рекомендуется; я как-то обошелся без этого, но лучше следовать советам
резонных людей), что делается командой
$ shutdown now
Размонтировать все файловые системы, кроме корневой (с ней все
равно этот номер не пройдет) командой
$ umount -Af
Дать
команду
tunefs -n enable /dev/ad#s#?
для каждого раздела, в
файловой системе которого требуется Soft Updates. И, наконец, повторением
команды
$ shutdown now
вернуться в многопользовательский
режим. Перезагрузки, что характерно, не потребуется. В принципе, Soft
Updates можно включить и для корневой файловой системы, но для этого
потребуется загрузка с внешнего носителя, типа rescue-CD из штатного комплекта
FreeBSD.
Да, забыл сказать, что механизм Soft Updates требует включения
соответствующей опции в конфигурацию ядра. Впрочем, по умолчанию в ядре
GENERIC это уже сделано — важно только не отключить ее случайно при
пересборке.
Что же дает Soft Updates с точки зрения производительности?
Как оказалось, очень немало. В упоминавшейся выше статье приведены результаты
выполнения файловых операций в обычном синхронном режиме, в режиме чисто
асинхронном (при котором игнорируются все зависимости обновлений), и в
синхронном режиме с Soft Updates. Результаты этих тестов показывают, что
быстродействие операций записи и удаления файлов с включением Soft Updates
возрастает в 2 и 20 раз соответственно, лишь на 5% уступая результатам чисто
асинхронного режима. Из чего следует резонность совета резонных людей — не
включать асинхронный режим: использование его просто не обеспечивает прироста
производительности, оправдывающего снижение надежности.
Я в свое время
(еще на FreeBSD 4-й ветки) провел серию сравнений быстродействия файловых
операций в UFS (как без Soft Updates, так и с ней) и в файловых системах Linux
(ext2fs, ext3fs, reiserfs). Использовался массив в 4 Гбайт очень смешанного
характера, от большого количества мелких html'ок до нескольких объемных tiff-
и avi-файлов, то есть типичный набор данных настольного пользователя.
Результаты впечатляли. Если UFS в чистом виде проигрывала по скорости ext2fs в
4-6 раз на копировании и более чем в 10 — на удалении файлов, то при
задействованном Soft Updates разница в скорости копирования не превышала
полутора раз, а скорость удаления практически сравнялась (в пределах ошибки
эксперимента). Обе же журналируемые же файловые системы Linux не обнаружили
отличий в быстродействии от UFS с Soft Updates — а ведь только их можно
сравнивать между собой с точки зрения формальной устойчивости...
   
Раздел "*nix". Новости:
| IBM собирается выпустить версию пакета MS Office для Linux |
|
Корпорация IBM намеревается в ближайшее время выпустить специально модифицированную версию офисного пакета Microsoft Office, адаптированную для работы на компьютерах под управлением Linux. Об этом сообщает сетевое издание Infoworld со ссылкой на интервью шведской газеты Computer Sweden с сотрудником шведского подразделения IBM по разработке программных продуктов Lotus Стефаном Петтерссоном.
Корпорация IBM, напомним, является одним из главных популяризаторов Linux. И если раньше компания предлагала клиентам, в основном, серверные решения с открытой операционной системой, то сейчас в IBM рассчитывают выйти и на рынок настольных компьютеров. Предполагается, что появление Linux-версии MS Office существенно ускорит процесс продвижения ОС в массы.
К сожалению, никаких подробностей относительно инициативы по портированию MS Office на платформу Linux пока не сообщается. Представители IBM утверждают, что работы ведутся совместно с программистами софтверного гиганта, причем Microsoft даже предоставила часть исходного кода своего офисного пакета. В Microsoft, однако, данную информацию не подтвердили, заметив, что, вероятнее всего, Linux-вариант MS Office будет использовать тот или иной программный эмулятор.
Справедливости ради, впрочем, следует заметить, что ранее IBM уже сотрудничала с Microsoft при портировании на сервер Domino почтовой программы Outlook. Тогда софтверный гигант предоставил в распоряжение сотрудников "Голубого гиганта" фрагменты исходного кода Outlook. Так что не исключено, что и Linux-версия офисного пакета будет разработана при непосредственном участии корпорации Microsoft.
| Red Hat улучшит безопасность своих продуктов |
|
Компания Red Hat собирается существенно повысить надежность своей операционной системы Red Hat Enterprise Linux, сообщает издание Vnunet.com. Предполагается, что дистрибутив ОС четвертой версии, который должен выйти в 2005 году, будет соответствовать так называемому стандарту безопасности SE Linux (Security-Enhanced Linux). Данный стандарт, напомним, разрабатывается Национальным агентством безопасности США и представляет собой набор патчей к ядру Linux, совмещенный с подпрограммами управления доступом к различным компонентам системы.
Со слов отца Linux Линуса Торвальдса, большая часть кода, необходимого для поддержки SE Linux, уже включена в ядро последней версии 2.6. Таким образом, у поставщиков операционных систем Linux имеются все возможности для повышения качества своих программных продуктов. Тем более, что повышение безопасности является одним из наиболее приоритетных направлений развития открытой ОС. И особенно важно это сейчас, когда Linux делает первые шаги на пути покорения рынка операционных систем для настольных компьютеров.
Предполагается, что соответствие стандарту национальной безопасности превратит Red Hat Enterprise Linux 4.0 в одну из самых устойчивых к взломам и вирусным атакам платформ. Естественно, повышенная надежность Linux позволит и лучше конкурировать с продукцией софтверного гиганта, чьи операционные системы недавно стали базой для одной из крупнейших в истории вирусных эпидемий, разразившихся по вине червя MyDoom. Вероятно, вслед за компанией Red Hat об инициативах, направленных на повышение стабильности работы Linux, объявят и другие поставщики дистрибутивов данной ОС.
| IBM открывает в Москве Центр компетенции Linux |
|
В среду 17 февраля представители компании IBM провели пресс-конференцию, на которой объявили об официальном открытии Центра компетенции Linux в Москве. В конце прошлого года был заключен договор с Министерством РФ по связи и информатизации об открытии подобного центра, и сейчас офис в Гостинном дворе полностью оборудован и функционирует. Таким образом, российские разработчики Linux присоединятся к команде из 600 человек, представляющих 43 страны, которые участвуют в совершенствовании ядра этой операционной системы.
Но присоединение России к международному сообществу не является единственной целью создания Центра. Важной функцией служит продвижение Linux-продуктов на российском рынке, осуществление сертификации решений на базе этой платформы. Центр будет открыт для заказчиков, бизнес-партнеров и разработчиков, которые смогут протестировать свои приложения, созданные под эту операционную систему. Сотрудники центра окажут также услуги по интеграции решений, смогут проконсультировать и провести необходимую экспертизу в области применения Linux.
В компании IBM считают, что сейчас, как никогда, интерес общественности сдвигается в сторону разработок с открытым исходным кодом. Свыше 6000 заказчиков IBM используют решения на базе Linux для автоматизации важных систем управления. Представители компании IBM заявили, что движущей силой такого смещения акцентов является снижение стоимости владения системой на базе Linux. Клиенты компании говорят об экономии 50% средств при переходе на Linux.
Государственные структуры также постепенно уделяют этой операционной системе все больше и больше внимания. Необходимо, чтобы исходные коды для государственных систем были открыты для анализа. Ведь только так можно обеспечить информационную безопасность, возможность создания гибких дополнительных решений, а также возможность дорабатывать свою систему для полной совместимости с другими продуктами.
Джим Столлингс, генеральный менеджер IBM по развитию платформы Linux, называет эту операционную систему самой быстрорастущей в мире. В среднем, ежегодный рост рынка составляет более 35%. А в России - около 50%. Появляются все больше международных поставщиков, которые разрабатывают решения для Linux и "только" для Linux. Если сохранится такая тенденция, то сбудутся оптимистичные прогнозы Джима Столлингса: он как-то заявил, что к 2006 году Linux окончательно вытеснит Windows с рынка серверов. Для этого уже было сделано немало. Следующий шаг - завоевание доверия на рынке десктопов, и организация Центров компетенции Linux является одним из способов достижения этой цели.
| Lindows изменила название своих продуктов |
|
Компания Lindows.com, основанная бывшим директором MP3.com Майклом Робертсоном, была вынуждена сменить свое название и название основных программных продуктов в тех странах Европы, где суд запретил использование слова Lindows. Суть проблемы, напомним, сводится к тому, что корпорация Microsoft обвинила поставщика операционных систем на базе кода Linux в нарушении прав на торговую марку. В исковом заявлении значилось, что Lindows созвучно с названием всемирно известной ОС Windows и поэтому вводит пользователей в заблуждение. В Lindows.com же, напротив, утверждали, что термин "окна" является общеупотребительным и характеризует особенности современных графических интерфейсов.
Тем не менее, суд встал на сторону софтверного гиганта и запретил распространение дистрибутивов Lindows на территории Бельгии, Нидерландов и Люксембурга. В итоге, поставщикам ничего не оставалось, как удовлетворить требования Microsoft и сменить торговую марку. Теперь операционные системы носят имя Lin---s (произносится как Lindash), кроме того, запущен и соответствующий сайт www.lin---s.com. Кстати, на главной странице данного ресурса красуется баннер, изображающий латинский алфавит, в котором вычеркнуты все буквы, за исключением d, o и w. Таким образом, в бывшей Lindows.com дают понять, что под символами "-" скрывается прежнее название.
По мнению Майкла Робертсона, если Microsoft не будет удовлетворена исполнением постановления суда, то можно смело говорить о том, что истинной целью софтверного гиганта является не защита торговой марки, а сохранение монополии на рынке операционных систем.
| Обнаружены несколько дыр в ядрах Linux последних версий |
|
Польская компания iSEC Security Research, специализирующаяся на вопросах компьютерной безопасности, сообщила об обнаружении нескольких серьезных уязвимостей в ядрах Linux последних версий.
Первые две дыры связаны с системным вызовом mremap(2). Как сообщается, ошибки могут использоваться для несанкционированного локального повышения уровня привилегий пользователя и последующего выполнения на компьютере произвольного программного кода. Несмотря на то, что уязвимости представляют достаточно большую опасность, они все же не являются критичными, поскольку эксплуатировать их удаленно не представляется возможным. Другими словами, для увеличения собственных прав в системе злоумышленнику потребуется непосредственный доступ к серверу.
Третья ошибка также не является критичной и связана с компонентом ядра Linux, ответственным за поддержку 128-битных графических контроллеров ATI Rage, производства канадской компании ATI Technologies. Все три дыры представляют опасность для пользователей операционных систем Linux с ядрами 2.2, 2.4 и 2.6. Впрочем, необходимые исправления (ядра 2.4.25 и 2.6.3) уже выпущены и доступны для загрузки, сообщает ZDNet.
Следует заметить, что в начале декабря прошлого года в ядрах Linux практически всех версий также была обнаружена уязвимость, обеспечивающая возможность повышения уровня привилегий пользователя. Причем дырой удалось воспользоваться некоему хакеру, взломавшему серверы проекта Debian.
| Microsoft подала иск против Lindows в Канаде |
|
Корпорация Microsoft подала новый иск против компании Lindows.com, производителя одноименных операционных систем на базе исходного кода Linux. Как и прежде, фирма, основанная бывшим директором МР3.com Майклом Робертсоном, обвиняется в нарушении прав на торговую марку Windows. В Microsoft, напомним, утверждают, что слово Lindows созвучно с названием всемирно известной ОС и поэтому вводит пользователей в заблуждение. Причем софтверный гигант особо подчеркивает, что на раскрутку Windows у корпорации ушли почти 20 лет и сотни миллионов долларов, тогда как в Lindows.com не хотят тратить на рекламу своей продукции ни цента.
Соответствующие иски против Lindows.com ранее были поданы в Соединенных Штатах и Европе, а теперь софтверный гигант добрался и до канадского представительства компании. Как заметил Майкл Робертсон, более двух лет Microsoft не было никакого дела до деятельности Lindows.com в Канаде, и вдруг корпорация неожиданно решила поднять вопрос о правах на марку Windows. По мнению Робертсона, подобная ситуация явно свидетельствует в пользу того, что на самом деле Microsoft просто-напросто хочет устранить ненужного конкурента.
Следует также заметить, что не так давно Lindows.com, в соответствии с постановлением суда, была вынуждена сменить свое название и название операционных систем в трех европейских странах - Бельгии, Нидерландах и Люксембурге. Теперь фирма именуется Lin---s (произносится как Lindash). Что касается Соединенных Штатов, то здесь рассмотрение дела отложено до выяснения вопроса о правомерности требований софтверного гиганта.
| Panda Software обновила антивирусы для почтовых серверов Linux |
|
Компания Panda Software выпустила новые версии антивирусов для почтовых платформ Linux (Sendmail, Qmail и Postfix). В новые версии включена опция проверки фрагментированных сообщений. Благодаря этому оптимизируется производительность сервера, так как теперь для проверки и обезвреживания не требуется загружать на компьютер сообщение целиком, что особенно полезно в периоды вирусных эпидемий, когда сервер может получать тысячи зараженных сообщений в минуту.
Panda SendmailSecure, QmailSecure и PostfixSecure теперь могут определять сообщения, использующие брешь iFRAME/MIME. Данная брешь позволяет новым вредоносным кодам обманывать систему путем использования ложного MIME заголовка сообщения. Panda SendmailSecure, QmailSecure и PostfixSecure блокируют вирусы, которые автоматически запускаются при просмотре сообщения в окне предварительного просмотра. Вирусы блокируются на уровне почтового шлюза. Как следствие, сокращается количество получаемых пользователем предупреждений и не перегружаются почтовые ящики на сервере.
Управление Panda SendmailSecure, QmailSecure и PostfixSecure осуществляется через консоль управления Panda AdminSecure, которая позволяет централизованно, с одного компьютера, производить установку, настройку, управление, а также решать иные задачи, связанные с этими антивирусными продуктами.
Panda SendmailSecure, QmailSecure и PostfixSecure могут быть приобретены раздельно или в пакете Panda EntepriSecure, предназначенном для корпоративных сетей.
| Lindows включила поддержку для Centrino в свою ОС |
|
Компания Lindows представила вчера обновленную версию своей Linux-ОС, предназначенную для ОЕМ-производителей ноутбуков.
Теперь в нее включена поддержка беспроводной технологии Centrino. Lindows OS Laptop Edition способствует распространению Centrino, поскольку многие ОЕМ-производители рассматривают вариант предустановки на свои продукты более дешевой операционной системы Linux вместо Microsoft Windows. Как сообщают представители компании Centrino-ноутбуки с предустановленной Linux должны появиться на рынке в течение ближайших месяца-двух, а их цена не превысит $800.
| Red Hat предлагает энтузиастам «Федору» |
|
Red Hat выпустила редакцию операционной системы Linux Fedora Core 2 на базе нового ядра версии 2.6.
Вышедшая в четверг первая бета-версия Fedora Core 2 test1 включает также новые версии двух популярных пользовательских интерфейсов Linux: Gnome 2.5 и KDE 3.2 release candidate 1. В ядро 2.6, на котором основана test1, добавлена поддержка более мощных серверов, расширенные возможности параллельного решения задач и другие новые функции.
Fedora — это экспериментальная версия Red Hat, больше рассчитанная на энтузиастов. Она предоставляется бесплатно, но без поддержки и долгосрочной программы обновлений, которыми сопровождается продукт Red Hat Enterprise Linux (его версия на базе ядра 2.6 выйдет не раньше 2005 года).
Red Hat, ведущий поставщик операционной системы Linux, пытается заручиться помощью внешних программистов для ускорения отладки Fedora.
ПО можно загрузить с веб-сайта Red Hat.
| IBM установила рекорд в тестах на быстродействие |
|
Компания IBM объявила, что ее Unix-сервер на процессорах Power превзошел систему Intel Itanium в популярном тесте производительности серверов.
32-процессорный сервер IBM p690 стоимостью 5,6 млн долл. продемонстрировал производительность в 1025 млн транзакций в минуту в испытаниях TPC-C организации Transaction Processing Performance Council. Предыдущий рекорд для некластерных систем в 1008 млн транзакций в минуту был установлен сервером Hewlett-Packard Superdome с 64 процессорами Itanium 2.
IBM опубликовала результаты испытаний на быстродействие и рекламировала процессор Power в день открытия конференции Intel Developer Forum в Сан-Франциско. В 2003 году IBM анонсировала лучший результат, достигнутый ее Power-сервером в тесте TPC-C, в один день с анонсом своих первых Itanium-серверов.
Тест TPC-C имитирует работу автоматизированного склада, когда от многочисленных внешних компьютеров поступают заявки и другие транзакции. IBM превзошла показатели НР и по соотношению цена/производительность, хотя скидки на высокопроизводительное оборудование на высококонкурентном рынке серверов делают прайс-листы менее актуальными.
В системе IBM использовалась ее собственная версия Unix — AIX. Самая высокопроизводительная система НР работает с версией Unix HP-UX. Процессоры Itanium могут работать в системах Windows, HP-UX и Linux, а процессоры Power — в системах AIX, Linux и IBM OS/400. Кроме того, в системе IBM использовалась СУБД DB2, а в системе НР — СУБД Oracle.
| Тройка вынесла приговор Linux-серверам |
|
Сразу три проблемы безопасности, выявленные в ядре Linux, позволяют рядовому пользователю получить полный контроль над сервером или рабочей станцией.
Две из трех уязвимостей относятся к тому, как ядро Linux управляет памятью. Они проявляются во всех современных версиях операционной системы с открытым исходным кодом, утверждает польская фирма iSEC Security Research, опубликовавшая свои рекомендации в среду. Третья ошибка обнаружена в модуле ядра, обеспечивающем поддержку 128-битной видеокарты Rage от ATI Technologies.
Так как Linux часто применяется на серверах с разделением ресурсов, пробелы в защите, позволяющие пользователям расширить свои права доступа к компьютеру, представляют серьезную проблему, комментирует старший директор по техническому обеспечению Symantec Альфред Хьюгер. Однако это, по его словам, не настолько критические ошибки, чтобы злоумышленник мог взломать компьютер извне. «Выражаясь схематично, если злоумышленнику удастся получить доступ к вашей машине, то он сможет завладеть полным контролем (root) над ней», — пояснил он.
Для устранения этой уязвимости Linux Kernel Project выпустил новую версию ядра серии 2.4 — 2.4.25. Это уже второй случай в этом году, когда пришлось выпускать обновление ядра для устранения ошибки. В январе вышла версия 2.4.24, устранявшая другую уязвимость, обнаруженную iSEC. Еще одна уязвимость в ядре, выявленная в сентябре прошлого года, позволяла злоумышленнику, получившему доступ к компьютеру программиста, распространить свой контроль на несколько ключевых серверов, используемых для разработки дистрибутива Debian Linux.
Linux-компании и проекты, компонующие собственные версии Linux, также поспешили выпустить обновления. Red Hat, Novell SuSE Linux, Debian и другие дистрибутивы были исправлены уже в четверг утром.
Вновь обнаруженные ошибки подчеркивают тот факт, что в программном обеспечении ядра Linux все еще присутствуют уязвимости, говорит Хьюгер. Более того, обнаружение серьезных ошибок в ядре в течение трех месяцев подряд ставит под сомнение теорию «множества глаз», провозглашающую, что ПО с открытым исходным кодом легко проверяется на наличие пробелов в защите и, следовательно, безопаснее проприетарного. На самом деле большинство разработчиков не любит копаться в старом коде, констатирует Хьюгер. «Это красивая теория, но я не верю, что на практике она работает так, как хотелось бы», — сказал он.
Linux и раньше критиковали с этих позиций. И хотя контроль, возможно, оказывается не таким всеобъемлющим, как представляют себе многие сторонники open-source, все же последние выявленные в Linux ошибки остаются менее серьезными, чем те, что обнаружены в Windows.
Раздел "*nix". Новости. SCO против Linux:
Никто не ожидал, что компания SCO Group станет причиной самого значительного кризиса в истории движения открытых исходников за последние пять лет. Однако вскоре прозвучали обвинения в незаконном использовании интеллектуальной собственности SCO Group в ядре Linux.
| Lindows.com защитит клиентов от SCO |
|
Компания Lindows.com, поставщик одноименной операционной системы на базе Linux, объявила, что все ее клиенты защищены от возможных судебных разбирательств с SCO. По крайней мере, существующее ныне соглашение между Lindows.com и SCO не позволяет последней требовать от пользователей ОС Lindows выплаты лицензионных отчислений. Фирма SCO, напомним, обвиняет корпорацию IBM в нарушении контракта и незаконном распространении собственной версии операционной системы Unix, на которую SCO уже давно отозвала лицензию. На этом основании инициаторы конфликта требуют выплаты компенсации в размере пяти миллиардов долларов США. Вместе с тем, поставщики операционных систем Linux с ядрами 2.4 и выше якобы безо всякого на то согласия со стороны SCO использовали в своих программных продуктах фрагменты исходного кода Unix System V. А поэтому всем компаниям и частным пользователям, на чьих компьютерах установлена ОС Linux, предлагается приобрести лицензии. Кроме того, SCO обвиняет корпорацию Novell в обмане покупателей путем многочисленных публичных заявлений, в которых Novell утверждает, что это именно ей принадлежат права на код Unix System V. При этом многие ведущие поставщики дистрибутивов Linux уже объявили о запуске специальных программ по защите своих клиентов от SCO. К примеру, с подобными инициативами выступили фирмы Red Hat, Hewlett-Packard и другие. А теперь к ним присоединилась и компания Lindows.com, сообщает интернет-издание News Factor.
| В Австралии рассмотрят вопрос о правомерности требований SCO |
|
В начале января нынешнего года компания SCO объявила о намерении начать торговлю лицензиями на операционную систему Linux в Австралии и Новой Зеландии. SCO, напомним, утверждает, что ей принадлежат права на код ОС Unix System V, фрагменты которого якобы незаконно используют разработчики сообщества open-source в дистрибутивах Linux с ядрами 2.4 и выше. Именно на этом основании владельцы копирайта и требуют от пользователей открытой ОС выплаты лицензионных отчислений стоимостью до нескольких тысяч долларов. Кроме того, SCO обвиняет корпорацию IBM в нарушении контрактных обязательств и нанесении ущерба в размере пяти миллиардов долларов США.
Причем никаких веских доказательств своей правоты инициаторы конфликта пока так и не представили. Тем не менее, мощнейшая PR-кампания, развернутая SCO, так или иначе, вносит смуту в ряды пользователей Linux. Более того, австралийское подразделение фирмы уже сообщило, что получило около дюжины запросов по поводу лицензирования операционной системы.
Вместе с тем, по мнению некоторых экспертов, заявления SCO являются прямым нарушением закона о честной конкуренции, поскольку до сих пор так и не ясно, должны ли вообще владельцы компьютеров с Linux платить за ОС. А поэтому об обязательном приобретении лицензий на текущем этапе не может идти и речи. Более того, австралийская Комиссия по конкуренции и вопросам потребителей (АССС) в ближайшее время должна будет рассмотреть вопрос о правомерности требований SCO. Так что SCO теперь придется выяснять отношения не только с IBM и американскими потребителями, но и с австралийскими и новозеландскими пользователями Linux.
|
