CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
19.07.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки :: Файловые системы

Изучаем ZFS

NetSago

Оригинал: ZFS Uncovered
Все замечания и исправления к переводу принимаются по адресу n0xi0uzz@gmail.com.

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

Пока весь мир переключается на 64-битные файловые системы, Sun выкатила 128-битную. Понадобится ли нам когда-нибудь столько пространства? Не сразу. Масса Земли около 6×1024 килограмм. Если бы мы взяли такую массу водорода, мы получили бы 3,6×1048 атомов. 128-битная файловая система может индексировать 2128, или 1038 единичных блоков. Если вы создадите хранилище, в котором каждый атом будет хранится как одиночный бит водорода (не считая пространства, которое вам понадобится для управляющей логики), вы сможете создать около 300 000 таких устройств, превышающих массу земли, если каждый из них будет иметь 128-битную файловую систему с 4 Кб единичных блоков. Чтобы преодолеть ограничения дискового пространства ZFS, нам придется создавать жесткие диски, размером с континенты.

Так есть ли какое-то преимущество у 128-битных файловых систем? Не совсем. Тем не менее, если текущие тенденции будут продолжаться, мы начнем превосходить ограничения 64-битных файловых систем в следующие 5-10 лет. 80-битной файловой системы возможно будет достаточно для непредвиденных выходов за границы ограничений, но большинство компьютеров работают с 80-битными числами сложнее, чем со 128-битными. Вот почему Sun выпустила 128-битную систему.

Конечная независимость.


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

Два наиболее распространенных порядка расположения байтов названы в честь поедающих яйца философов из книги Джонатана Свифта «Приключения Гулливера». «Тупоконечная» нотация располагает байты в виде 1234 (big-endian, обратный порядок байтов, при котором старший байт передается сначала, — примеч. переводчика), в то время как «остроконечные» компьютеры хранят их в порядке 4321 (little-endian, прямой порядок байтов, при котором сначала передается младший (наименее значимый) байт, — примеч. переводчика). Некоторые компьютеры используют что-то вроде 1324, но в основном, люди стараются избежать использование подобного порядка.

Большинство файловых систем спроектированы для работы на определенной архитектуре. Не смотря на то, что она может быть портирована на другие архитектуры позже, каждая файловая система имеет тенденцию к хранению метаданных в том порядке расположения байтов, что использовался на оригинальной архитектуре. HFS+ от Apple является хорошим примером подобной практики. С тех пор, как HFS+, возникшая на Power PC, данные в файловой системе хранятся в формате big-endian. На маках с процессором Intel, вам приходится переворачивать порядок байтов при каждой операции загрузки или сохранения на диске. Инструкция BSWAP на чипах x86 позволяет быстрый переворот, но, в любом случае не является решением высокой эффективности.

Sun заняла интересную позицию в порядке расположения байтов, когда начала продажи и поддержку Solaris на архитектурах SPARC64 и x86-64. На SPARC64 используется big-endian, а на x86-64 little-endian; таким образом, Sun выбрала сделать одну из своих файловых систем медленнее, чем на другой поддерживаемой Sun архитектуре.

Решение Sun? Не выбирать. Каждая структура данных в ZFS записана в том порядке расположения байтов, в каком компьютер её записал и сопровождается индикатором используемого порядка расположения байтов. Раздел ZFS на Opteron будет little-endian, а контролируемый UltraSPARC — big-endian. Если вы разделите дисковое пространство между двумя компьютерами, все по-прежнему будет работать; и чем больше операций записи выполняется, тем больше он становится оптимизирован для чтения.

Ужасное нарушение иерархии.

ZFS была описана в LKML как «ужасное нарушение иерархии». Это не совсем точно, ZFS не является файловой системой в традиционном понимании UNIX, но, несмотря на это, набор хорошо определенных слоев дает расширенный набор обычной файловой системы. Поэтому любые администраторы VMS могут самодовольно пробормотать: «UNIX наконец-то получил настоящую файловую систему. В конечном счете, он может быть готов для использования предприятиями».

Три слоя ZFS называются: слой интерфейса, слой работы с объектами и слой хранения пулов. Проходя вниз по стеку, разметка слоев файловой системы делает запросы на транзакции объектов, транзакции на виртуальное устройство и, наконец, превращение виртуальных операций в реальные.

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

Менеджер разделов.

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

Каждое виртуальное устройство (vdev), созданное из скомбинированных устройств, используя либо зеркалирование, либо RAID-Z. Однажды создав vdev-ы, вы скомбинируете их в пул хранения. Этот подход обеспечивает некоторую гибкость. Если у вас есть некоторые данные, доступ к которым должен быть быстрым и которые должны надежно храниться, вы можете создать в большей степени зеркалируемый пул и пул RAID-Z, а также создать файловые системы из какого-либо лучшего набора. Учтите, что файловые системы не должны быть размещены рядом на vdev; пока они могут казаться близкими блоками хранящегося пространства на высоких слоях, они могут не быть близкими вообще.

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

В отличии от других менеджеров разделов, ZFS дает возможность точно определять планирование I/O. Каждая транзакция имеет определенный приоритет и срок окончания работы с обрабатываемым расписанием слоем vdev системы.

Объектный слой.

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

Если у вас когда-либо был сбой напряжения во время записи файла, возможно вы запускали fsck, scandisk или какую-нибудь подобную утилиту. В конце концов, вы, вероятно, восстановите несколько поврежденных файлов. Если они были текстовыми, то вам может быть повезло, повреждение может быть ликвидировано легко. Если файлы имели комплексную структуру, вы могли потерять эти файлы. Приложения, работающие с базами данных решают такую проблему использованием механизма транзакций, — они записывают что-то на диск, говоря «Я собираюсь это сделать», и делают это. Затем они пишут «Я это сделал» в лог. Если что-то пойдет не так где-то на середине, такое приложение может просто откатиться назад, к состоянию перед стартом.

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

ZFS использует модель транзакций. Вы можете начать транзакцию, выдавая число записей, и они либо все завершатся успешно, либо все не завершатся. Это возможно за счет использования механизма копирование-на-записи. Каждый раз, записывая некоторые данные, ZFS записывает эти данные в запасное место диска. Затем, она обновляет метаданные, говоря «Это новая версия». Если процесс записи не пройдет стадию обновления метаданных, никаких записей поверх старых данных производиться не будет.

Одна из сторон эффекта от использования копирование-на-записи заключается в том, что это позволяет постоянно по времени создавать снапшоты. Некоторые файловые системы, такие, как UFS2 на FreeBSD и XFS на IRIX, уже поддерживают снапшоты, так что это не новая концепция. Стандартная технология создает партиции для снапшотов. Один раз сделав снапшот, каждая операция записи заменяется в соответствии с копированием оригинала на партицию со снапшотом и только потом осуществляет запись. Лишним будет говорить, что этот подход довольно-таки дорогой.

С ZFS, все, что вам нужно для создания снапшота — это увеличить счетчик ссылок партиции. Каждая операция записи уже недеструктивна, и единственное, что может произойти — это то, что операция обновления метаданных не удалит ссылки на старое местоположение. Другая сторона эффекта от использования этого механизма заключается в том, что снапшоты являются файловыми системами первого класса со своими собственными правами. Вы можете делать запись на снапшот точно также, как и на любой другой раздел. Например, вы можете создать снапшот файловой системы для каждого пользователя и разрешить им делать все, что они захотят, без помех для других пользователей. Эта возможность имеет пользу на практире в совместном использовании с Solaris Zones.

Претендуя на то, чтобы быть файловой системой.

Все это прекрасно, иметь базирующуюся на объектах, транзакционную систему хранения данных, но кто собирается это использовать? Все мои приложения хотят использовать что-то, что похоже на файловую систему UNIX. И тут в дело вступает ZPL, POSIX слой в ZFS. ZPL предоставляет соответствие между файловыми операциями POSIX (read, write и т.д.) и операциями DMU. Это дает возможность управления структурой директорий и позволяет использование прав доступа.

Вдобавок к ZPL, в ZFS есть другой модуль в слое интерфейса, известный как ZVOL. Этот слой дает более простое соответствие; вместо того чтобы создавать видимость POSIX-совместимой файловой системы, он кажется необработанным блочным устройством, которое полезно для реализации существующих файловых систем, поддерживаемых пулами хранения ZFS. Порт FreeBSD изначально использует существующую файловую систему UFS2 поверх устройства с ZVOL. Я думаю, что порт от Apple будет использовать HFS+ поверх ZVOL для того, чтобы дать Apple поддержку метаданных HFS+.

Некоторые интригующие возможности доступны для будущей работы в этом слое. Поскольку ZFS уже поддерживает транзакции, возможно, что SQL или похожий интерфейс может быть использован в этом слое. Исходя из низкой стоимости создания файловых систем, каждый пользователь может создать базы данных на лету и получить гораздо более гибкий интерфейс, чем предоставляемый слоем POSIX. Проблема WinFS от Microsoft в том, что она слишком сложна для того, чтобы обеспечить всем поддержку реализаций, которые не основаны на файлах и не будет там применяться, поскольку это приведет к увеличению средств, вместо замены текущей файловой системы (тут бред получился — примеч. переводчика).

Что она не делает?

В настоящее время, наибольшим недостатком ZFS является недостаток шифрования.
В NTFS шифруется каждый файл, и у большинства менеджеров разделов имеются механизмы шифрования на уровне блока. К счастью, выход был найден и ZFS может использовать такой же механизм, который уже реализован, для поддержки компрессии.

Хорошо разделенные квоты также не поддерживают. Вы можете создавать разделенные разделы с максимальным размером, но мы не можете установить максимальное число файлов, которое пользователь может создать в разделе.

Последнее слово в RAID?

Одно из самых волнующих возможностей ZFS — это RAID-Z. Это массив, состоящий из блоков фиксированного размера, с которого может происходить чтение или запись. С тех пор, как RAID обычно реализуется близко к блочному слою (часто на уровне аппаратного обеспечения, открыто к операционной системе), устройства RAID также предоставляют этот интерфейс. В массиве RAID-5 с тремя дисками, запись блока вызывает сохранение блока на диск 1, а результат XOR-а блока, соответственно, один из дисков 2 или 3. Это вызывает две взаимосвязанных проблемы:

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

  • Вышеупомянутый сценарий, записывание одного блока на диск 1 требует, чтобы вы затем считали блок с диска 2 и сохранили контрольную сумму на диск 3. Эта дополнительная операция чтения в середине каждой записи может быть дорогой.

Так что же RAID-Z делает по-другому? Во-первых, массив RAID-Z не настолько туп, как массив RAID; у него есть некоторая осведомленность о том, что в нем хранится. Ключевая составляющая — категория — переменной ширины. С существующими реализациями RAID, она составляет либо 1 байт (например, каждый нечетный байт будет записан на диск 1, каждый четный — на диск 2, а каждый сравнимый по модулю — на диск 3), либо величину, равную длине блока. В ZFS этот размер категории определяется размером записи. Каждый раз когда вы производите запись на диск, вы полностью записываете категорию.

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

RAID-Z стал возможен только за счет новой структуры слоев ZFS. Вы можете восстановить раздел RAID-5, когда диск сломается, получив «XOR всех битов на индексе 0 на каждом диске в сумме дает 0, так что должен содержать наш пропавший диск?». С RAID-Z это невозможно. Вместо этого, вам надо будет прослеживать метаданные файловой системы. Контроллер RAID, который является блочным устройством не будет иметь возможности это сделать. Один из добавленных бонусов это то, что аппаратный контроллер RAID при запросе на восстановление, должен воссоздать диск, даже те блоки, которые не использовались, в то время, как RAID-Z нужно восстановить только использовавшиеся блоки.

Не являясь частью RAID-Z, ZFS включает в себя ещё одну возможность, которая помогает решить проблемы потери данных: так как каждый блок содержит хеш SHA256, поврежденный сектор на диске будет отображаться, как содержащий ошибки, даже если котроллер диска этого не замечает. Это превосходство над существующими реализациями RAID. Используя RAID-5, например, вы можете восстановить раздел, но если одиночный сектор на диске поврежден, весь диск может сообщить о существующей ошибке. Раздел RAID-Z может сообщить вам, какой диск содержит ошибку (тот, чей блок не соответствует хешу) и восстановить данные с другого. Он также может сообщать заранее о том, какой диск может быть поврежден.

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

Есть одна вещь, которую я нашел интересной на практике в ZFS — то, что он будет работать лучше на блочном устройстве, у которого меньшая стоимость случайных считываний. Почти как если бы у архитекторов было флеш-устройство, вместо жесткого диска, в их понимании.

Как я могу это получить?

Будет ли ZFS доступна для вашей операционной системы? Для пользователей [Open]Solaris ответ будет «да», для остальных — «может быть». Если вы используете Windows, то возможно нет. Для Linux ситуация не намного лучше. Реализация OpenSolaris выпускается под лицензией CDDL, с которой не совместима GPL. Существует две возможности поддержки этой файловой системы на Linux. Первая: сделать полностью собственную реализацию, что потребует огромных усилий и поэтому вряд ли возможно в ближайшее время. Другая заключается в том, чтобы портировать её в FUSE и запускать, как пользовательский процесс. Эта работа находится в процессе реализации, но похоже, что результат будет значительно медленнее версии, реализованная на уровне ядра и невозможен к использованию на загрузочных разделах. Пользователи Ubuntu, желающие поддержки ZFS, могут переключиться на Nexenta, в которой используется ядро OpenSolaris и пользовательское окружение GNU.

CDDL — однофайловая лицензия, она не влияет на общую лицензию проекта, что позволяет использовать её в больших количествах проектов, у которых нет лицензии, указывающей, что «все компоненты этого проекта должны быть лицензированы под лицензией, приветствующей эти утверждения». Эти требования позволяют FreeBSD и DragonFlyBSD разрабатывать порты ZFS, и MacOS X — где также ожидается поддержка ZFS.




Комментарии

Страницы комментариев: предыдущая :: 1 :: 2

Аку-Аку, Mon Oct 8 18:15:12 2007:
Доброжелатель, понедельник, 8 октября 2007 г. 05:13:10:
Оформите это все в виде статьи, отправте редакции.
Вот тогда и поговорим.
Доброжелатель, Mon Oct 8 05:13:10 2007:
О «just for fun»


Ещё немного на эту же тему, коль зашёл разговор. :)

Давайте попробуем вкратце осмыслить только то, что общеизвестно из открытых источников.

Когда, скажем, Торвальдс говорит, что он занимается разработкой линукса «just for fun», ради потехи, то он, наверное, несколько лукавит, но одновременно говорит правду. Ведь для него это дело важно, я думаю, не только потому, что линукс достиг впечатляющего успеха, в том числе и коммерческого. Это, уверен, важно ещё и потому, что развитие линукса для Торвальдса есть интересным делом, он отдаётся ему с удовольствием. Кстати, по его собственным словам — это я прочитал в одном из англоязычных интервью — его всегда интересовал «нижний» слой системного ПО, взаимодействие программы с аппаратурой. Очень удобно — да и приятно! — заниматься своим любимым делом, особенно когда оно столь успешно развивается. :)

Другой, не менее показательный пример — Столлман. Кто этот человек — коммунист, анархист, выдумщик? Или его деятельность стала ответом на определённую ситуацию, сложившуюся в отрасли? И по прошествии многих лет мы видим результат этой деятельности, и приходится согласиться: да, это действительно было нужно. Где же тут «just for fun»?

Ещё один пример — Тео де Раадт. Поговаривают, что у него частенько проявляется дурной нрав при общении с людьми. И что это, якобы, стало причиной форка OpenBSD. Так ли это на самом деле? Что говорят об этом сами разработчики OpenBSD? Ведь они ставили перед собой некоторые важные цели, осуществить которые в рамках NetBSD оказалось нельзя — по тем или иным причинам, которые, несомненно, повлияли на итоговый расклад, но ведь если проследить последующее развитие OpenBSD и NetBSD по отдельности, можно заметить, что действительно у разработчиков имелись различные цели и мотивы.


Однако есть у «just for fun» и оборотная сторона. Прогрессирующее техническое усложнение и профанация всей наличной идеологии юникса через мнимое упрощение — все эти попытки достучаться до так называемых обычных пользователей, всякие «десктопизации» и так далее.

Откуда это взялось? Понятно откуда — веяния из Редмонда. А почему? Потому что в «Майкрософте» дело извлечения прибыли поставлено на широкую ногу. Только, вот, «красноглазики» не очень понимают, что майкрософтовское ПО изначально адресовано иному типу пользователя, чем тот, которому было предложено юниксовое ПО. Можно сказать, что в «Майкрософте» придумали и создали особый тип пользователя компьютера. Они молодцы, они за это получили и продолжают получать свою награду. Но как это можно связать с замечательной идеологией юникса? Никак нельзя (забегая вперёд, скажу, что это, конечно, не так).

Прикрывая стройную, ясную и простую юниксовую мощь (что уж о Plan 9 вспоминать) гламурными кружевами, разработчики линукса постепенно взрастили свою особую категорию пользователей, на ЛОРе таких много. Это пользователь, который либо плохо понимает, либо не понимает вовсе, что делает его система. Поводом для гордости такого пользователя становится безразмерное самомнение, вызванное, подозреваю, обычной необходимостью общения с кем-то, кто может предметно ответить и выслушать. Кто наши «красноглазики»? Наверное, это системные администраторы, любители поковыряться в новинках, юные читатели «компьютерной» периодики и так далее. Just for fun.

Хорошо всё это — или плохо?

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

Между тем, интерактивная связь — это то, что в реальном [особенно — в неодушевлённом] мире мы практически встречаем редко (тут нужны оговорки, но мне лень). Гораздо чаще мы взаимодействуем с предметами командно, если можно так выразиться: ударил молотком по гвоздю, второй, третий раз — работа сделана, гвоздь забит. Здесь от гвоздя или молотка обратной связи практически нету, если не брать во внимание сложные процессы человеческого восприятия, которые эту самую обратную связь и моделируют. Мы взаимодействуем с неживым миром императивно, а не интерактивно. (Если не считать интерактивной боль в голове, которой с разгону ударил себя об стену.) Зато с живыми существами — вполне интерактивно.

Улавливаете, к чему я веду? Внедрение в компьютер интерактивных интерфейсов вместо императивных приводит к мнимому одушевлению машины. Это отдельная большая тема, не буду её здесь развивать. (Интерактивные пользовательские интерфейсы — это отдельные тараканы в головах тех, кто их придумывает.) Но в итоге можно видеть, что бесконечные персонализации персональных (невольная тавтология) компьютерных систем «под себя» имеют действительно бесконечную природу, как и попытки «переделать» наших ближних — и тоже «под себя».

Компьютер должен выполнять поставленные задачи. Для постановки задач есть лишь один инструмент — собственная голова. Именно человек составляет простейший алгоритм решения задачи, разбивает это процесс решения на части и так далее.

Если мы используем чьи-то готовые инструменты, где надо лишь нажать на три кнопочки, то мы будем выполнять наши задачи так, как это виделось проектировщику сторонних инструментов с кнопочками. (Ящик с кнопочками, да-да. Инструменты скрыты внутри. Ящик с кнопочками — это инструмент. Инструмент для идиотов. Зачёркнуто.) Хорошо, если этот разработчик предусмотрел наилучшее решение именно таких задач, которые нам сейчас нужно решить. Но что, если задача у нас каждый день другая? А что, если вместо этого он лишь создал нам другие, отличные от изначальных задачи, и мы вынуждены вновь и вновь решать задачи второго рода, задачи-штрих? Прекрасный пример — «офисные» пакеты. Вместо того, чтобы единожды создать правила для формирования определённого типа рабочего документа (например, создать для ЛаТеХа стиль бланка для исходящего письма), а затем автоматизировать процесс работы в частными случаями этого документа, мы видим, как люди бесчисленное число раз изобретают велосипед с форматированием и композицией своих документов. (И это при том, что сообтветствующими дизайнерскими способностями для адекватного осуществления такого рода задачи обладают действительно немногие.) Корявые, уродливые велосипеды, вновь и вновь, и конца-края этому не видно.

В юниксе всё состоит из небольших программ-«кирпичиков». Зная их назначение можно под всякую задачу сделать свою стамеску. Просто, дёшево и середито. И не так уж много там этих «кирпичиков». (Сказал и подумал: а ведь я всю эту апологию юниксу пишу из офтопика, из маздая.)

Итак, нафига козе баян? Виноват. Зачем поверх изумительно простой и красивой системы надевать неповоротливые и «дружелюбные» программные саваны? Чтобы пользователь перестал думать головой и начал нажимать на кнопочки. (Интересно, в Редмонде уже прикидывают, как будет выглядеть «Аэро-2» на линуксовом ядре и GNU-программах?) И всё бы хорошо, но это будет уже не юникс. Это будет хорошо узнаваемая «винда» поверх чего-нибудь, не важно чего.

Трудно ли научить секретаршу работать с командной строкой? Нет. Это не сложнее, чем научить её нажимать на кнопочки, значения которых она не понимает. Зато она, когда пообвыкнется (неужели вы не помните, как люди работали в ДОСе?), перестанет называть рабочую машину какими-то идиотскими уменьшительно-ласкательными кличками и «персонализировать», а займётся какой-то полезной работой. И что удивительно, у неё наверняка появится больше свободного времени. ;)

Кстати сказать, замечают ли уважаемые читатели, сколько времени ежедневно отнимают ковыряния в графических интерфейсах современных ОС? А в масштабах всего мира? :)

«Just for fun» — это когда работа спорится, когда она доставляет человеку радость.

Ну и хватит, пожалуй. :)
Доброжелатель, Mon Oct 8 03:49:52 2007:
2 Alex

// Доброжелатель, just for fun!


Дорогой Алекс!

Из-за того, что многое в мире и, уже, в нашей любимой отрасли делается «just for fun», про результат в итоге можно сказать, что он получен, извините, через жопу.

Пресловутое «just for fun» способны сделать результативным — удивительно, не так ли? — только серьёзно настроенные люди, у которых есть некоторая цель, выходящая за существующие возможности их частной жизни или условий работы etc. Харизмой всего этого вашего движения «just for fun» обладают, как можно догадаться, именно и только те люди, которые хорошо и глубоко понимают, чем они заняты; знают, зачем они нечто делают; искренне любят это своё дело. Если нет твёрдых знаний, любви к своему делу, чёткой цели своего труда, то из «just for fun» получается всего лишь какой-нибудь ЛОР или такие, вот, переводы. :)
Alex, Mon Oct 8 03:33:35 2007:
...Кто оплатит труды?...

Доброжелатель, just for fun!
Доброжелатель, Thu Oct 4 18:15:16 2007:
Прошу не думать, будто я сделал эти замечания из-за своего дурного характера. Смею надеяться, что они помогут автору в дальнейшем лучше справляться с переводами.
Доброжелатель, Thu Oct 4 18:13:24 2007:
2 Celarent

Могу сделать лучше. К кому обращаться? Кто оплатит труды?


2 Алексей Федорчук.

Я читал статью в оригинале. Перевод содержит ошибки и несуразицы. Заметно, что автор плохо владеет английским языком. (Например, у файлов не «комплексная структура», а «сложная структура» и так далее.) И он всё-таки неграмотен с точки зрения русского литературного языка.
Алексей Федорчук, Thu Oct 4 10:41:44 2007:
2 Доброжелатель
Перевод дико грамотен. Один из не частых переводов, который понятен без перевода обратного.
Celarent, Wed Oct 3 14:55:35 2007:
Доброжелатель, можете сделать лучше? Сделайте, с удовольствием будем использовать ваш перевод.
Махмуд, Tue Oct 2 19:27:35 2007:
Спасибо за перевод. Интересная статья.
Доброжелатель, Tue Oct 2 16:43:37 2007:
Зачем столько запятых? Это, же, не, английский, текст, а, русский. Превод дико малограмотен. Например, переводчик не понимает разницу между -ться/-тся, как и многое другое, что входит в школьную (!) программу.

Страницы комментариев: предыдущая :: 1 :: 2

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds