Какой идиот перевёл "Линукс" и "НЖМД"? Автор первого поста? И вообще = корявый стиль перевода.

>Я думаю более умно не переводить а написать свой комментарий и указать неочевидные места и уточнения.

С удовольствием учту Ваши поправки в переводе. Серьезно. Комментарии и исправления неточностей, естественно, только приветствуются.
Без полного перевода - неочевидные места обычно более неочевидны :) .

Одно другому не мешает.

"Для 2.4 и ранних ядер", "Но разработчики ядра выбрали улучшение за счет", " это основанное в RAM блочное устройство", "Это так же искусственно ограничивает размер, что, как" и далее вся фраза кривая. Читать абсолютно невозможно.

Он называет это переводом?

Ещё : "Линус написал небольшую программу работающую с кэш", "а остальные разработчики ядра" по вашему перевод фразы "and other kernel developers created an improved version..."? "Все остальные" писали "an improved version" или всё-же ДРУГИЕ разработчики? !!!

Пока весь текст, кроме последнего абзаца перевел я. Если есть возражения, необходимо предлагать собственные варианты перевода.

Характер перевода может быть разным. В данном случае я стараюсь переводить наиболее близко к тексту. В настоящем подходе при первоначальном переводе стилю внимание уделяется лишь - по-возможности. Перевод предоставляет любому желающему улучшить стиль.

>Эти RAM основанные файловые системы автоматически увеличиваются или уменьшаются в размере в соостветствии с количеством данных, которые необходимо содержать

"Содержать"? Да? Не "которые они содержат" согласно исходной статье (... to fit the size of the data they contain)?

>Если есть возражения, необходимо предлагать собственные варианты перевода.

Я написал уже. Не "остальные разработчики" а "другие разработчики".

The copy in the cache is the only copy of the data / Копия в кэше - это единственное место размещения данных.

>и далее вся фраза кривая. Читать абсолютно невозможно.
Он называет это переводом?

В третьем лице о присутствующих говорить не вежливо. Видимо, тебя этому не научили. Приходится мне поправить ошибку.

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

Меня всегда забавляет агрессия подобная твоей. Ты никогда не пробовал отнестись к чему-либо изначально невраждебно? Почему бы спокойно, доброжелательно не указать мне на то, что ты считаешь надо поправить? Ну продемонстрировал ты хамско-потребительское отношение... дальше что?

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

Лучше сразу стараться правильно переводить. А потом дать другим проверить правильность. Перевод кривой и непонятный. Сразу хочется открыть первоисточник.

>"Для 2.4 и ранних ядер", "Но разработчики ядра выбрали улучшение за счет", " это основанное в RAM блочное устройство", "Это так же искусственно ограничивает размер, что, как"

Здесь твое предложение. Прочие поправил.

Best of all, this isn't new code but a new application for the existing Linux caching code, which means it adds almost no size, is very simple, and is based on extremely well tested infrastructure. / Более того, это не новый код а новое применение уже существующего кода кэширования в Linux, который несильно увеличится в размере ... [далее фраза нормальная]

>The copy in the cache is the only copy of the data Копия в кэше - это единственная копия данных

>Лучше сразу стараться правильно переводить.
Конечно лучше.

>А потом дать другим проверить правильность. Перевод кривой и непонятный.
Первоначальный перевод обычно таким и бывает. Естественно кривой. Задача улучшить тем, кому это интересно.

Принцип наш старый, проверенный - _Сделай лучше_.

Hm. For 2.4 and earlier kernels/ Для версии ядра 2.4 и более ранних

Все это замечательно конечно.. Особенно про особенности перевода с английского на русский и грамматику обоих языков.. Но это к лингвистам. Вопрос не в переводе в общем-то, а в еще одном механизме загрузки линукса. Я, лично, не вижу каких-то особых преимуществ от размещения начальной фс в кэше. Никто не мешает с помощью initrd монтировать tmpfs и размещать там корневую файловую систему! Никто. Так в чем проблема-то? Найден еще один способ загрузки системы? Хм...

>Best of all, this isn't new code but a new application for the existing Linux caching code, which means it adds almost no size, is very simple, and is based on extremely well tested infrastructure.

Самое главное то, что это не новый код, а новой применение уже имеющегося кода, что практически не влечёт увеличение размера...

Segmentation fault. Бред - переводить по абзацам. Контекст теряется. What is very simple?

But the kernel developers chose to implement a new mechanism in 2.6 for several reasons. / Но разработчики решили реализовать новый механизм в версии 2.6 по нескольким причинам.

>Бред - переводить по абзацам. Контекст теряется.

Да не, нормально. "Состояние графики" гораздо более сурово переводили :) .

Дело в том, что в самих исходных текстах нечетко некоторые части могут быть прописаны. У них там то же "еще те" обороты встречаются.

These ram based filesystems automatically grow or shrink to fit the size of the data they contain. / Эти файловые системы автоматически изменяют размер в соответствии с обьёмом данных которые они содержат.

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

Частичный перевод

...
В действительности, из-зи кэширования RAM-диски тратят больше памяти. Linux разработан для кэширования всех файлов и записей каталогов прочитанных или записанных на блочное устройство. Таким образом, данные будет храниться не только RAM-диске, но и в страничном кэше 
"page cache" (для файловых данных) и в кэше для записей каталогов "dentry cache".


Несколько лет назад у Линуса появилась неплохая идея: почему бы не использовать кэш ядра в качестве файловой системы? Просто хранить файлы в кэше и не избавляться от них до тех пор, пока те не будут удалены или система не будет перезагружена. Линус написал маленькую 
программу-обертку вокруг кэша и назвал её ramfs. Другие разработчики усовершенствовали его идею, создав "tmpfs", которая способна записывать данные в пространство подкачки, ограничивать размер точек монтирования, дабы не растратить всю свободную оперативную память. Initramfs есть экзэмпляр сущности tmpfs.


Файловые системы, основанные на памяти, автоматически изменяют свой размер в соответствии с содержимым. При добавлении новых файлов (как и при расширении существующих) автоматически выделяется память, при удалении или уменьшении файла происходит высвобождение памяти. При этом не происходит излищнего дублирования информации между блочным устройством и кэшем, так как блочного устройства попросту нет. Копия в кэше - единственная копия данных. Ко всему прочему, (iniramfs) это не новый код, а всего лишь новое приложение существующей инфраструктуры кэширования.


Система, использующая initramfs в качестве корневой ФС более не нуждается в соответствующем драйвере, встроенном в ядро, так как нет блочного устройства, интерпретируемого в качестве ФС. Только файлы, живущие в памяти!


Initrd против initramfs


Изменения в базовой инфраструктуре заставили разработчиков ядра создать новую реализацию...


Initrd разрабатывался как дополнение к старому коду определения корневого устройства ("root="), а не как его замена. Этот код исполняет программу "/linuxrc", предназначенную для выполнения начальных действий (таких как вход в сеть, определение устройства, содержащего корневой раздел, или ассоциирование устройства loopback с файлом), оповещения ядра о реальном корневом устройстве (путем записи записи числа de_t в /proc/sys/kernel/real-root-dev), и возврата в ядро, дабы оное смонтировало реальное корневое устройство и исполнило init.


Предполагалось, что "реальное корневое устройство" будет блочным устройством, нежели чем сетевым разделяемым ресурсом, а так же что initrd не будет реальной корневой ФС. Исполнение "/linuxrc" в виде специального процесса с ID 1 не предполагалось, так как данный 
идентификатор был зарезервирован для init, запуск которого производится ядром после монтирования реальной корневой ФС.


С переходом на initramfs разработчики ядра устранили все нежелательные допущения. Как только ядро запустит "/init" из initramfs, дальнейшее принятие решений не требуется и ядро может приступить к дальнейшим приказам. Теперь ядру нет нужды заботиться о том где находится
реальная корневая ФС и программа "/init" из ramfs исполняется как настоящий init с PID 1. (Если init'у потребуется передать этот идентификатор процесса другой программе, то он, подобно другим программам, может воспользоваться системным вызовом exec()).


Wish you success in your investigations,
The well-wisher

Хорошо. Спасибо. Добавил с некоторыми корректировками.

> Ядро разработано для следования приказам, а не для их учета.

Скорее "Ядро создано для выполнения приказов, а не для того, чтобы отдавать их."