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

Просто если ломать базовые вещи (такие как fstab), то система поломается

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

А представь: подходит к моему компу «администратор», к которому вечно посылает пользователя винда… Кстати скоро и systemd начнет так же посылать – можешь скринить. Так вот. Подходит сторонний наблюдатель и видит: система в мертвой петле. Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие теперь действия этого «администратора», если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн? Что «администратор» должен думать в таком случае и где искать хвосты? Боюсь при уровне «инициативности» и сложности systemd количество возможных хвостов – как песчинок в Сахаре. И едва ли он добредет до fstab к российской пенсии.

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего. Тупые ошибки синтаксиса нигде не исключены, допустим. Но в простых системах они отлавливаются легко и просто, – и не составляют вселенской проблемы, и не требуют костылей и мегадебагеров, базирующихся на мейнфреймах. И потом, ты сравниваешь ошибку в конфиге и последующее сумашествие systemd, с ошибкой в исполняемом rc.S, при которой исполнение адекватно остановится с четким указанием на проблему. Ты лукавишь.

Просто если ломать базовые вещи (такие как fstab), то система поломается

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

А представь: подходит к моему компу «администратор», к которому вечно посылает пользователя винда… Кстати скоро и systemd начнет так же посылать – можешь скринить. Так вот. Подходит сторонний наблюдатель и видит: система в мертвой петле. Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие теперь действия этого «администратора», если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн? Что «администратор» должен думать в таком случае и где искать хвосты? Боюсь при уровне «инициативности» и сложности systemd количество возможных хвостов – как песчинок в сахаре. И едва ли он к российской пенсии доберется до fstab.

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего. Тупые ошибки синтаксиса нигде не исключены, допустим. Но в простых системах они отлавливаются легко и просто, – и не составляют вселенской проблемы, и не требуют костылей и мегадебагеров, базирующихся на мейнфреймах. И потом, ты сравниваешь ошибку в конфиге и последующее сумашествие systemd, с ошибкой в исполняемом rc.S, при которой исполнение адекватно остановится с четким указанием на проблему. Ты лукавишь.

Просто если ломать базовые вещи (такие как fstab), то система поломается

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

А представь: подходит к моему компу «администратор», к которому вечно посылает пользователя винда… Кстати скоро и systemd начнет так же посылать – можешь скринить. Так вот. Подходит сторонний наблюдатель и видит: система в мертвой петле. Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие действия этого администратора, если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн? Что «администратор» должен думать в таком случае и где искать хвосты? Боюсь при уровне «инициативности» и сложности systemd количество возможных хвостов – как песчинок в сахаре. И едва ли он к российской пенсии доберется до fstab.

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего. Тупые ошибки синтаксиса нигде не исключены, допустим. Но в простых системах они отлавливаются легко и просто, – и не составляют вселенской проблемы, и не требуют костылей и мегадебагеров, базирующихся на мейнфреймах. И потом, ты сравниваешь ошибку в конфиге и последующее сумашествие systemd, с ошибкой в исполняемом rc.S, при которой исполнение адекватно остановится с четким указанием на проблему. Ты лукавишь.

Просто если ломать базовые вещи (такие как fstab), то система поломается

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

А представь: подходит к моему компу «администратор», к которому вечно посылает пользователя винда… Кстати скоро и systemd начнет так же посылать – можешь скринить. Так вот. Подходит сторонний наблюдатель и видит: система в мертвой петле. Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие действия этого администратора, если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн? Что «администратор» должен думать в таком случае и где искать хвосты? Боюсь при уровне «инициативности» и сложности systemd количество возможных хвостов – как песчинок в сахаре. И едва ли он к российской пенсии доберется до fstab.

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего. Тупые ошибки синтаксиса нигде не исключены, допустим. Но в простых системах они отлавливаются легко и просто, – и не составляют вселенской проблемы, и не требуют костылей и мегадебагеров, базирующихся на мейнфреймах.

Просто если ломать базовые вещи (такие как fstab), то система поломается Да, но в случае с башем – он четко указывает место ошибки. Да оно легко находится просто из-за дубовой простоты системы. А в случае с fstab – который я выше описывал – я понял где проблема только потому, что припомнил пошагово свои собственно действия.

А представь: подходит к моему компу «администратор», к которому вечно посылает пользователя винда… Кстати скоро и systemd начнет так же посылать – можешь скринить. Так вот. Подходит сторонний наблюдатель и видит: система в мертвой петле. Затык почему-то в journald, именно на его выходе из-за печки начинается новая загрузка. Какие действия этого администратора, если journald не работает должным образом, если журналы не посмотреть когда systemd офлайн? Что «администратор» должен думать в таком случае и где искать хвосты? Боюсь при уровне «инициативности» и сложности systemd количество возможных хвостов – как песчинок в сахаре. И едва ли он к российской пенсии доберется до fstab.

Я слыхал уже выше, между прочим, что придуманы уже какие-то костыли типа emergency shell. Но это костыли, это лишние сущности. Я все к тому, что твое сравнение – совершенно неправомерно. Ты передергиваешь. Простая система означает «предсказуемая» и «понятная», помимо прочего. Тупые ошибки синтаксиса нигде не исключены, допустим. Но в простых системах они отлавливаются легко и просто, – и не составляют вселенской проблемы, и не требуют костылей и мегадебагеров, базирующихся на мейнфреймах.