История изменений

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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

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

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

Ну да, а когда из-за подобной политики случится что-то плохое, то все обвинения полетят в сторону Линуса.

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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

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

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

Ну да, а когда из-за подобной политики случится что-то плохое, то все обвинения полетят в сторону Линуса.

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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

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

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

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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

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

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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

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

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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

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

Все подсистемы чем-то отличаются друг от друга. Например, работа с памятью имеет определённый ряд особенностей, который неприменим к управлению процессами. Есть, конечно, места соприкосновения, но в целом, это две разные вещи. Суть в том, что два — это не одно.

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

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