Чтение онлайн

Какие следствия для мира FOSS будет иметь исчезновение старейшей UNIX-компании? Напомню, что на её иждивении находится ряд крупных свободных проектов – Openoffice.org, MySQL, VitrualBox, не говоря уже о собственно ОС – OpenSolaris, и ряде средств разработки. Не загнутся ли они под чутким руководством Ларри Эллисона?

Наибольшие опасения вызывает судьба OpenSolaris: а нужна ли будет Oracle ещё одна ОС, в добавление к собственному клону RHEL? ОС, за время своего «свободного плавания» не достигшая ни полностью работоспособного состояния, ни критической массы комьюнити? Мне кажется, что ответ будет отрицательным. Но так ли это страшно? Все здоровые инновации OpenSolaris (а их немало) могут быть легко инкорпорированы в Linux. И, чем чёрт не шутит, вдруг новые хозяева изменят лицензию на ZFS? После чего она легко впишется в Linux-ядро.

А за остальные свободные проекты Sun'а волноваться нечего: MySQL выступит «легковеным» дополнением к собственно Oracle, OpenOffice.org не бросят, как востребованный конечным пользователем, VirtualBox, Sun Studio etc. – как интересные для всех разработчиков.

И как знать, не увидим ли мы вскоре нового монополиста – теперь уже в сфере свободного софта? Да ещё в сцепке с собственной аппаратной платформой: не зря ведь Ларри обмолвился, что «Sparc не бросим, потому что он хороший».

LinuxFormat, #120 (июль 2009)

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

И возникает вопрос – а нужны ли нам гигагерцы и гигабайты? Да, нужны. Один раз в жизни – когда мы собираем ядро (если, конечно, это вообще потребуется). И какова потребная мощность? Ну ясно, что какой же русский не любит быстрой езды? То есть, пардон, компиляции? Отвечаю: ядро Linux'а с умолчальным конфигом на машине с 3 Ггц и 4 Гбайт собирается где-то минут 7. На недобуке о 800 Мгц и 512 Мбайт памяти – раза в четыре дольше. Это важно? Особенно учитывая, что наш недобук ещё и электроэнергии потребляет куда меньше...

LinuxFormat, #121 (август 2009)

Ядро Linux версии 2.6.30 порадовало нас, в числе прочих новшеств, и поддержкой NILFS (New Implementation of a Log-Structured File System) – Лог-структурированной Файловой Системы в Новом Исполнении. И действительно, в ряду ФС последнего поколения, таких, как более известные ext4 или btrfs, она выделяется рядом особенностей.

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

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

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

Все эти особенности должны способствовать повышению как надёжности, так и быстродействия. О надёжности говорить пока рано – она имеет статус экспериментальной и не рекомендуется для повсеместного использования. Но быстродействие NILFS2 оказывается вполне на уровне её подруг-конкуренток – ext4 и btrfs.

Подготовлена для: LinuxFormat, #121 (август 2009), но была заменена на заметку про NILFS2

Файловая система btrfs не так давно стала полноправным членом семейства нативных ФС для Linux (начиная с ядра 2.6.29). И едва это случилось – она претерпела кардинальное изменение формата, что ознаменовалось выходом, после почти полугодичного перерыва, инструментария для работы с ним – btrfs-progs 0.19, рассчитанным на грядущее ядро 2.6.31. Который, по уверению разработчика, Криса Мэзона, способен создавать файловую систему с кардинально повышенным быстродействием. Несовместимую, однако, с инструментарием предыдущей версии.

Я решил проверить обоснованность этого заявления. Результаты – парадоксальны: действительно, при операциях с обычными, в том числе и очень большими, файлами, она показывает просто рекордные результаты в сравнении не только с традиционными ФС, но и с утверждающейся в качестве стандарта ext4. А вот манипуляции с очень мелкими файлами (каковых без счёта в любой Linux-системе) – просто провальны: местами замедление их более чем двукратное.

Увы – до стабилизации btrfs мы ещё не дожили: следует ждать очередной смены формата на предмет большей сбалансированности её быстродействия.

LinuxFormat, #122 (сентябрь 2009)

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

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

Я понимаю – развитие и KDE3, и GNOME2 дошло до той черты, когда остаётся только выискивать баги, полировать мелочи, ну и прочая косметика. А это – полезно для пользователя, но смертельно скучно для разработчика. Особенно для того, кому разработка – способ самореализации, а не банальная рубка бабла на росте пользовательской базы. Вспомним, насколько интенсивно развивались в последние полтора десятка лет find или grep? Не больше, чем ахалтекинцы за тысячелетия существования своей породы. И по той же самой причине.