LINUX.ORG.RU

Линус Торвальдс выступил с критикой дизайна файловых систем

 


1

0

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

Линус Торвальдс в списке рассылки ядра жестоко раскритиковал эти предложения и заявил, что большинство программистов никогда не будут этими новыми системными вызовами пользоваться, что они будут нестабильными и плохо оттестированными.

Цитата: "Поэтому вместо того, чтобы придумывать новые системные вызовы, которые никто не будет использовать, разработчики файловых систем должны стараться обеспечить нормальную работу даже плохого кода. Потому что, хотите вы этого или нет, 99% программ именно так и написаны.

Тот неоспоримый факт, что люди не проверяют ошибки, которые возвращает системный вызов close() (закрытие файла и сброс "грязных" данных из кэша на диск) должен означать, что, например, при отложенной записи на диск нужно обязательно проверять ситуацию переполнения диска. Если ваша файловая система возвращает ENOSPC при закрытии файла через вызов close(), а не при записи в него через write(), значит, что вы потеряли обработку ошибок переполнения диска у 90% приложений. Вот так всё просто.

Жаловаться на то, что ошибка в приложении - это всё равно, что жаловаться на скорость света: вы должны иметь дело с реальным миром, а не с тем, каким бы вы хотели его видеть. То же самое относится к идее, что "люди должны писать во временный файл, вызывать функцию fsync для него и переименовывать его вместо оригинала". Вы думаете, что так должно быть, но в реалии программисты пишут open(filename, O_TRUNC | O_CREAT, 0666). Это неправильно, я знаю. Но в конечном итоге, даже разработчики хорошо написанного приложения могут решить, что fsync() не стоит тех потерь в производительности. В git, например, где мы обычно пытаемся быть очень, очень и очень аккуратными, fsync() в объектных файлах по умолчанию выключен.

Почему? Потому что его включение вызывает неприемлемое поведение ext3. Сейчас, надо сказать, дизайн git'a рассчитан на то, что потеря нового БД файла не фатальна, но потенциально это очень беспокоит и смущает - вам, возможно, придётся откатить изменения назад и переделать некоторые операции вручную.

К чему я всё это говорю ? Иногда те разработчики файловых систем, которые говорят "вы должны использовать fsync(), чтобы получить предсказуемые результаты" - это те же люди, которые испортили всё это до такого безобразия, что fsync'ом абсолютно нереально пользоваться.

Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда."

Взято с opennet.

>>> Подробности

>раскритиковал эти предложения
не плохое начало

MiklerGM ★★
()

> Иногда те разработчики файловых систем, которые говорят "вы должны использовать fsync(), чтобы получить предсказуемые результаты" - это те же люди, которые испортили всё это до такого безобразия, что fsync'ом абсолютно нереально пользоваться.

Линус как всегда прав. Из-за постоянного втыкательства fsync() со стороны разработчиков прикладных программ, иногда приходиться делать LD_PRELOAD=libnosync.so app чтобы в разы ускорить работу какой-либо тулзы (например, Amarok 1.x и пересканирование базы + reiser4)

shahid ★★★★★
()

То есть Торвальдс намерен отклонять все файловые системы, которые не адаптированы к глюкам git-а? Феерично :D

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Торвальдс пишет:

> ext4 just defaults to the crappy "writeback" behavior, which is insane. Sure, it makes things _much_ smoother, since now the actual data is no longer in the critical path for any journal writes, but anybody who thinks that's a solution is just incompetent.

Theodore Tso ему в ответ:

> You are right that data=writeback and delayed allocation do both mean that data can get pushed out much later than the metadata. But that's allowed by POSIX, and it does give some very nice performance benefits.

Торвальдс:

> This is why I absolutely _detest_ the idiotic ext3 writeback behavior. It literally does everything the wrong way around - writing data later than the metadata that points to it. Whoever came up with that solution was a moron. No ifs, buts, or maybes about it.

Этот парень не может не вбросить говна на вентилятор :))))) Ппц )))

Manhunt ★★★★★
()
Ответ на: комментарий от Davidov

> Поясните, плиз, историю с временным файлом?

Приложение хранит свои данные в файле. Допустим, оно решило их в очередной раз обновить. Открыло файл с O_TRUNC и начало писать туда новые данные. Что будет, если в этот момент, например, выключится питание? При следующем запуске файл окажется в неопределенном состоянии. Например, данные окажутся записаны только наполовину, и в середине записанных данных будет кусок мусора.

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Так вот sync - очень дорогая операция. Разработчики ФС предложили ввести ослабленный аналог операции sync, некий "барьер" (тот самый "новый системный вызов"). Насколько я понял идею, гарантируется, что после внезапной перезагузки, если хотя бы частично выполнена хотя бы одна из операций, заказанных _после_ "барьера", то совершенно точно полностью завершены все операции, заказанные _до_ "барьера". Для СУБД, такая операция во многих случаях могла бы заменить собою sync. И производительность файловой системы она снижает намного меньше, чем sync.

Можно использовать "барьер" вместо sync и в примере с переименованием временного файла.

А Торвальдс эту идею запилил. И высказался в духе, что даже если приложения ведут себя совершенно некорректно, ФС должны изо всех сил стараться удержать файлы в "хорошем" состоянии. Так что "битый" файл получался бы в очень-очень редких ситуациях, когда некорректному приложению сильно-сильно не повезло.

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

И я уже приводил цитаты, из которых ясно, что костыли эти означают снижение производительности ФС.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Ты хочешь сказать, что лучше делать "правильные" котыли для "правильных" программ, которые (костыли) будут ни с чем не совместимы, которые никто не будет использовать и следовательно они будут неоттестированными и бажными?

Deleted
()
Ответ на: комментарий от Deleted

> Ты хочешь сказать, что лучше делать "правильные" котыли для "правильных" программ, которые (костыли) будут ни с чем не совместимы, которые никто не будет использовать и следовательно они будут неоттестированными и бажными?

По мне, так вопрос с тестированием решается совсем по-другому. Все API (в том числе, API файловой системы) должны быть задокументированы, и каждый из них сопровождаться набором тестов на (1) соотвествие документации, на (2) корректность работы в "пограничных" случаях, на (3) корректность обработки ошибок. Каждый модуль ядра должен допускать тестирование отдельно ото всего остального ядра, что позволит в тестах моделировать аварийные ситуации. И каждый модуль должен сопровождаться набором тестов на (4) покрытие исходного кода. И пока нет более-менее полного набора тестов, такому api/модулю в trunk-е не место. Чтобы регрессии обнаруживались не на живых пользователях после выпуска ядра, а при прогоне тестсьюта.

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

> По мне, так вопрос с тестированием решается совсем по-другому. Все API (в том числе, API файловой системы) должны быть задокументированы, и каждый из них сопровождаться набором тестов на (1) соотвествие документации, на (2) корректность работы в "пограничных" случаях, на (3) корректность обработки ошибок. Каждый модуль ядра должен допускать тестирование отдельно ото всего остального ядра, что позволит в тестах моделировать аварийные ситуации. И каждый модуль должен сопровождаться набором тестов на (4) покрытие исходного кода. И пока нет более-менее полного набора тестов, такому api/модулю в trunk-е не место. Чтобы регрессии обнаруживались не на живых пользователях после выпуска ядра, а при прогоне тестсьюта.

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

> Торвальдс выбрал другой путь - сэкономить на тестах и надежности в пользу динамичности развития. Что же, пожалуйста. Но вместо развития мы теперь наблюдаем костылестроение. И этого я уже не понимаю.


Торвальдс понимает, что без динамичности развития линукс моментально умрёт.

Deleted
()
Ответ на: комментарий от Deleted

> будут ни с чем не совместимы

Про "ни с чем не совместимы" не вполне верно. В системах, где "барьера" нет, на его месте должен стоять sync (sync по сравнению с "барьером" всего лишь предоставляет больше гарантий). Так что особых проблем с кросс-платформенностью приложений это не добавляет.

> без динамичности развития линукс моментально умрёт

Вот и я о том же. Решили быть динамичными - будьте динамичными. Нужен новый системный вызов - введите его! Обнаружили, что что программисты криво работают с файлами - напишите tutorial "как работать правильно", и подержите его недельку на первых страницах линуксячих сайтов. Пусть user-level приложения подтягиваются.

А вместо этого - один консерватизм. Агрессивной оптимизации ФС Торвальдс говорит "нет". Снижающим накладные расходы системным вызовам Торвальдс говорит "нет". И прызвает строить подпорки, про которые заранее известно, что спасают только 9 раз из 10. Глюкодром.

Ни надежности, ни развития...

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Наверное, в оправдание Линуса можно произнести слова "practial" и "real-world". Но с этими словами в далеком 1991 надо было оставаться с DOS-ом, а не рисовать свое ядро вместо сдачи сессии... Не эти слова привели его к успеху.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

>В очередной раз мне решение Торвальдса совершенно не нравится. Строить костыли для криворуких прикладных программ - значит поощрять их дальнейшее существование.

Это меньшее из зол. Альтернатива - иметь хорошую ФС, в сочетании с хорошим ядром, но практически полное отсутствие энтузиастов, согласных писать под идеальную платформу. А это - деградация, ядро ради ядра. Вещь в себе. Примерно на таком уровне сейчас находится OpenBSD, да и фряха недалеко ушла. Просто надо определиться, для кого создается система - для учебника или для реальных пользователей. Позиция Линуса как нельзя более прагматичная и точная. Я целиком на его стороне.

Clayman ★★
()
Ответ на: комментарий от Clayman

Просто надо понять, что идеальных программистов и программ, которые делают все как надо практически нет. Нельзя идти по пути идеализма в данном случае.

Clayman ★★
()
Ответ на: комментарий от Manhunt

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

Reset ★★★★★
()
Ответ на: комментарий от Manhunt

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

а вот мне всегда было интересно -- а что если делать всё как описывается в цытируемом мною обзацце, но без вызова sync ?

какие могут быть нехорошие эффекты?

mkfifo
()
Ответ на: комментарий от sergej

> Закончится все наверное введением версий на файлы как в vax vms

Если к этой фиче не будет простого интерфейса, который работает сам без дополнительного кода, то произойдет это только при условии, что Линус захочет отправить свой продукт туда, где сейчас vax vms.

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

Liosha_Syrnikov
()

Провидец был прав.

Ганс Райзер ещё тыщу лет назад предлагал всё это, но был послан. Гений обогнал своё время. Нынешние системные вызовы для работы с ФС были придуманы без понятия транзакционности операций в голове, на современном этапе они устарели.

Camel ★★★★★
()
Ответ на: комментарий от Manhunt

> > Поясните, плиз, историю с временным файлом?

> Приложение хранит свои данные в файле. Допустим, оно решило их в очередной раз обновить. Открыло файл с O_TRUNC и начало писать туда новые данные. Что будет, если в этот момент, например, выключится питание? При следующем запуске файл окажется в неопределенном состоянии. Например, данные окажутся записаны только наполовину, и в середине записанных данных будет кусок мусора.

> Как этого избежать? Данные пишут во временный файл.

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

LamerOk ★★★★★
()

"Персональному комьютеру никогде не понадобится более 1 Мб памяти."

"Оптимизация ядра под звуковую подсистему - плохая идея."

"Файловой системе не нужна атомарная операция замены содержимого файла."

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

Не правда ли, это всё гораздо проще и удобнее, чем использовать операцию атомарной замены одного файла на другой?!

PS. как увидел IBM PC (DOS, OS/2, офтопик, линукс), с тех пор тоскую по RT-11, в которой, если создать новый файл с уже существующим именем и начать туда писать, в каталоге всё равно оставался старый файл, а замена старого файла на новый происходила только атомарно и только в момент успешно выполнения close() (был ещё purge(), который тихо удалял новую версию).

PPS. сколько себя помню, никогда не понимал, КАК, по мнению разработчиков осей, я должен обрабатывать ошибки при выполнении операции close().

alexsaa
()
Ответ на: комментарий от Liosha_Syrnikov

> Создание новых сисколов - это попытка изменить интерфейс работы с файловой системой, попытка придумать альтернативную реальность.

Суть в том, чтобы обеспечить новую функциональность, не ломая старой. Да, это *новый* API. Как и, скажем, sendfile().

alexsaa
()
Ответ на: комментарий от Deleted

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

И поэтому нужно жестко критиковать все что ему не нравится? Это уже становится скучно...

X-Pilot ★★★★★
()

Знаем мы Торвальдса. Покритикует, покритикует, да и добавит. Через пару релизов кто-нибудь ему покажет, как это работает "на практике" и Торвальдс добавит. Сколько раз уже...

fractaler ★★★★★
()

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

prizident ★★★★★
()
Ответ на: комментарий от prizident

Не только ext4.

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

Вообще-то эта проблема есть во всех файловых системах на Linux, и виноват в этом устаревший POSIX. Просто когда номер версии файловой системы дорастает до 4 у создателей открываются глаза и они начинают просить интерфейс, который упростил бы атомарные операции с файловой системой. Райзер до всего этого додумался тыщу лет назад.

Camel ★★★★★
()
Ответ на: комментарий от Manhunt

Торвальдс сказал чётко и уверенно, что 99% приложений ваш "барьер" использовать не будет и он прав. Посему, этот вызов - мёртвому припарка.

ФС должна быть бесопасной для всех приложений ПО УМОЛЧАНИЮ. ТОЧКА.

Если какому приложению хочется скорости - пишите свои интерфейсы до умопомрачения.

tempuser001
()

старо... а Линус молодец!

ggrn ★★★★★
()
Ответ на: комментарий от Dudraug

> боян же.

"!;"!%, почему когда нечего сказать, вы сотрясаете воздух? Молчите, сэр, я вас умоляю.

Всех остальных тоже касается.

tempuser001
()
Ответ на: комментарий от alexsaa

> Да, это *новый* API.

100% в перспективе ненужный и избыточный.

sendfile - это действительно *новый* и нужный API, авторы ext4 предлагают костыли для существующих.

tempuser001
()
Ответ на: комментарий от mkfifo

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


> а вот мне всегда было интересно -- а что если делать всё как описывается в цытируемом мною обзацце, но без вызова sync ?

> какие могут быть нехорошие эффекты?


Если на ext3 в режиме ordered и включенными barriers - то никаких.
Если на ext4 в новом режиме alloc_on_commit и включенными barriers - то никаких.
Без barriers тоже мало шансов залететь.

В других режимах журналирования (включая ext4+ordered) и других файловых системах данные нового файла могут еще не записатся к тому времени как удалится старый файл и произойдет переименование.

> пишу в него, ставлю в его конце сигнатуру "файл корректен", затем удаляю первый файл, после чего второй переименовываю. При запуске аппликухи я ищу оба файла и выбираю из них тот, в которого в конце есть заветная сигнатура "всё корректно".


с некорректными данными дело иметь не придется но Ты можешь так потерять все данные (сюрприз?) если это не ext3+ordered / ext4+alloc_on_commit

szh ★★★★
()

>Жаловаться на то, что ошибка в приложении - это всё равно, что жаловаться на скорость света:

me потянулся к попкорну...

e000xf000h
()
Ответ на: комментарий от prizident

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

у тебя глюкавое мнение о том где есть эта проблема и где ее нет

szh ★★★★
()
Ответ на: комментарий от Manhunt

> Агрессивной оптимизации ФС Торвальдс говорит "нет".

Агрессивной потере данных по умолчанию Торвальдс говорит нет (никто не мешает лично тебе сменить режим журналирования).

> про которые заранее известно, что спасают только 9 раз из 10.


Спасают в 9999 разах из 10000, не передергивай,
и я ЗА! я не хочу терять данные во всех не переписанных на новое API приложениях.

szh ★★★★
()
Ответ на: комментарий от tempuser001

>"!;"!%, почему когда нечего сказать, вы сотрясаете воздух? Молчите, сэр, я вас умоляю.

Это лор, детка. А тема уже обсуждалась в толксах при чем очень давно.

Dudraug ★★★★★
()

Мне кажется, новый апи нужен. Но он должен быть достаточно прост; проще, чем create_temp+write+rename. И до тех пор, пока он не появится, Линус будет говорить, что "вы и со старым-то управиться не можете", а писатели файловых систем так и будут вынуждены искать компромиссы между частотой потери данных и производительностью. Компромиссы, которые вызываны не объективными проблемами жёстких дисков, а просто текущим бардаком в posix.

Например, можно было бы, уже открывая файл, указать не CREATE|TRUNCATE, а некую (пока гипотетическую) опцию REPLACE_ON_CLOSE. И всё! Думаю, семантика понятна из названия. А уж когда файл будет реально перенесён на диск - сразу (как в fsync()) или в некотором абстрактном будущем (как с барьерами) - будет уже определяться где-то в другом месте (опцией sync монтирования либо явным вызовом fsync()). В любом случае, целостность данных можно будет запросить явно на уровне API.

Барьеры же, как попытка сделать эту функциональность, на мой взгляд, ничему не противоречат: безопасный и эффективный способ ДОЛЖЕН существовать, даже если им пользуются только 1-2 приложения (скажем, БД).

Разумеется, оптимизировать скорость за счёт поломки всего существующего кривого кода - идея сомнительная; её никак не стоит рекомендовать как режим монтирования по умолчанию.

alexsaa
()
Ответ на: комментарий от alexsaa

>> Ты можешь так потерять все данные (сюрприз?)

> Честно говоря, описывая свой сложный псевдорецепт, я втайне ожидал, что кто-то очень добрый и компетентный расскажет, как это сделать наверняка на уровне существующих спецификаций (не привязываясь к специфике ext3)


Не завязываясь на ext3+ordered / ext4+alloc_on_commit:
вызывать fsync на новый файл перед переименованием, и строго говоря еще и вызывать fsync на директории (обе директории - в кот старый и в которой новый файлы)

> затем удаляю первый файл, после чего второй переименовываю.

зачем удалять ? сразу переименовывай старый в новый.

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


если бы был fsync_me_lightly() - он мог бы гарантировать что данные попадут на диск до того как произойдет rename, но при этом не тормозить приложение пока это произойдет.

Т е нам нужен после креша либо старый файл (вплоть до 60 секундной давности) с данными либо новый файл с данными, а обычный fsync дает нам лишние гарантии получить именно новый файл после креша но за это - тормозит.

szh ★★★★
()
Ответ на: комментарий от alexsaa

> PPS. сколько себя помню, никогда не понимал, КАК, по мнению разработчиков осей, я должен обрабатывать ошибки при выполнении операции close().

Как-как... Abort, Retry, Ignore.

atrus ★★★★★
()
Ответ на: комментарий от Manhunt

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

Я думал, это делает файловая система, а не приложение. В нормальных ФС приложение вообще не знает, журналируется ли файл или нет. Оно просто пишет в файл. А уже драйвер ФС ведает тем, чтобы была резервная копия и данные не потерялись.

Nxx ★★★★★
()
Ответ на: комментарий от Nxx

> Я думал, это делает файловая система, а не приложение. В нормальных ФС приложение вообще не знает, журналируется ли файл или нет. Оно просто пишет в файл. А уже драйвер ФС ведает тем, чтобы была резервная копия и данные не потерялись.

Какое отношение твои фантазии о работе "нормальных" ФС (это каких?) имеют к реальности?

SKYRiDER ★★★
()
Ответ на: комментарий от Nxx

К сожалению, чтобы "просто гарантировать" запись на диск строго в том же порядке, в каком были выполнены системные вызовы, придётся сильно заплатить производительностью (да и в этом случае вопросы надёжности не решаются полностью). Лучше всё же дать оси какую-то свободу вариации порядка выполнения операций, но в предсказуемых пределах. Вопрос в том, какие это пределы.

alexsaa
()
Ответ на: комментарий от Manhunt

> <...> И пока нет более-менее полного набора тестов, такому api/модулю в trunk-е не место. Чтобы регрессии обнаруживались не на живых пользователях после выпуска ядра, а при прогоне тестсьюта.

Чушь спороли-с. Если коротко, то вы ничего не знаете о тестировании.

>Торвальдс выбрал другой путь - сэкономить на тестах и надежности в пользу динамичности развития. Что же, пожалуйста. Но вместо развития мы теперь наблюдаем костылестроение. И этого я уже не понимаю.

Он действительно требует улучшение качество кода для устойчивости системы, и я с ним согласен.

fi ★★★
()
Ответ на: комментарий от Manhunt

> Но с этими словами в далеком 1991 надо было оставаться с DOS-ом, а не
> рисовать свое ядро вместо сдачи сессии


В далеком 91-ом у него не было шикарного дома в калифорнии и годков ему было на 18 поменьше. Некоторым из посетителей LOR наверняка всего столько :).

eXOR ★★★★★
()
Ответ на: комментарий от alexsaa

> я должен обрабатывать ошибки при выполнении операции close().

Во-во...

eXOR ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.