Больше, чем etc-update — легко. Тривиальными изменениями он меня доставал постоянно (т.е. постоянно требовал изменения шрифта и раскладки в консоли (/etc/conf.d/consolefont и /etc/conf.d/keymaps)). Он не умеет делать merge, там в опциях только взять то, взять это, слить вручную, показать ещё раз diff и сохранить то как пример. После изменения конфига от вас после каждой пересборки пакета, к которому этот конфиг относится, etc-update будет требовать решения. Или мы говорим о разных etc-update.
Есть dispatch-conf, у которого, как говорят, дело с этим лучше. В частности, в его справке я нашёл упоминание об использовании RCS (это одна из древних VCS) или «каталога архивов» (т.е. версионировании без VCS) при наличии соответствующих настроек. То есть, говоря о том, что схожий вариант не интегрировали в Gentoo, вы, вероятно, не правы. Немного жалко, что я не стал разбираться: возможно, можно было бы допилить dispatch-conf для использования mercurial.
Вас не смущает, что это до сих пор не встроили в систему, хотя могли? Ваши предположения, почему?
При первичной настройке VCS вы потратите очень много времени на то, чтобы определить, что нужно, а что не нужно игнорировать. В случае встраивания такого варианта в дистрибутив надо напрягать maintainer’ов каждого пакета, пишущего что‐либо в /etc. Так что, если идея не пришла людям в голову при создании дистрибутива, то через несколько лет существования maintainer’ам неохота напрягаться. Хотя напрягаться надо будет гораздо меньше, если объявить, что по‐умолчанию всё в /etc будет под контролем VCS, а указывать надо только исключения, но тогда под контролем окажется много мусора.
Также, чтобы избежать holywar’а, нужна поддержка любой VCS. Или, по крайней мере, любой VCS, имеющей нормальные ветки с простым merge.
Ещё, возможно, никому просто не пришло в голову, что это надо встроить в систему. Я не раз подумывал написать о моём скрипте сюда (на habrahabr), но ни разу — пойти на bugs.gentoo.org и предложить что‐то подобное там. Хотя с поддержкой со стороны portage было несколько
проще: мне не нужно было бы убеждаться, что все мои изменения зафиксированы перед использованием скрипта. Поддержка portage нужна только, чтобы отделять мои изменения от не моих, mercurial всё равно не даст сделать слияние при наличии незафиксированных изменений. Можно, правда, делать слияние в третьем месте, а в /etc делать pull+update, тогда незафиксированные изменения будут слиты (но останутся незафиксированными). Но конфликты придётся разрешать в том третьем месте.
Merge также не всегда корректен. Просмотр изменений после слияния — это задача администратора, но могло оказаться и так, что запрос был, но кто‐то решил, что администраторы не будут делать review и потому данная возможность опасна.
Делать его часто — умучаешься конфиги сливать и вообще воздух греть процессором. Это муторный процесс, не особо интеллектуальный, но противный.
Греть воздух вы не умучаетесь. Главное, не смотреть на процесс компиляции.
А насчёт слияния конфигов: у меня этим занимается mercurial. Конечно, потребовалось написать скрипт, но оно того стоило: 99% времени слияние — просто ./update-script --all (он перемещает все изменения в клон /etc, содержащий только неизменённые версии конфигов в ветке default, применяет их там без каких‐либо вопросов, делает commit, затем запускает pull и merge в ветку user в /etc). Зачем делать merge самостоятельно, если есть VCS, которая умеет этим заниматься?
Для падений сборки есть emerge --keep-going: можно собрать всё, что собирается, а затем разбираться с проблемами. Ещё есть emerge --resume[ --skipfirst] для возобновления сборки, но я этим не пользуюсь.
LiveCD тоже не особо нужен. Я ставил Gentoo, в процессе читая handbook, из вполне рабочей и установленной на жёсткий диск Ubuntu. Если бы теперь надо было ставить на чистую машину, взял бы grml LiveUSB (потому как там консоль — гораздо более привычная мне zsh + есть графика, если надо).
Можете считать, что я использую определение из wikipedia. Скорее, более простое «именованная последовательность байт с определёнными операциями чтения и записи». (А изначально вообще собирался практически повторить определение для переменной — «именованная последовательность байт».)
Главный вопрос в том, какую задачу решаете вы, а какую — dd. Dd корректно решает задачу копирования данных на блочном устройстве. А нужен перенос файлов, с которыми работают ваши программы, на новое устройство, с новым размером. Даже если новое устройство имеет тот же размер, копирование зачастую уменьшает уровень фрагментации (и не переносит блоки с мусором).
Вообще‐то dd — это утилита для копирования (и, возможно, некоторого изменения) одного файла. Одного. В документации так и написано: «dd — convert and copy a file» Это не средство переноса множества файлов. Это не средство для создания файловой системы. Средство для переноса — это cp (но tar’у я больше доверяю). Для создания — mkfs.
Так что нет, вы не используете программу в *nix way. Вам нужно создать новую ФС и перенести туда файлы. Вместо этого вы берёте один файл (в виде блочного устройства) и копируете его в другое место (другое блочное устройство).
Сколько своего времени вы потратите на resize, если цель больше, чем источник? Что будете делать с dd, если цель меньше, чем источник? Зачем вы вообще берёте с собой мусор из свободных блоков?
Зачем? Я просто указал на то, что только dd — это не замена Samsung Data Migration в данной ситуации. Нужна ещё программа для увеличения размера диска.
Если бы кто‐то внял вашему совету, то он бы был удивлён тем, что место не увеличилось.
Её одной недостаточно — место увеличилось. Если ФС позволяет и диск заполнен почти полностью, то будет тот же dd + xfs_growfs/…. А если диск не сильно заполнен или ФС не позволяет, то tar c|tar x имеет больше смысла, так как вы не будете копировать с помощью dd данные, которые вам заведомо не нужны (при этом, разумеется, получите нелинейную запись с нелинейным чтением).
Я решил проблему просто: система на RAID1 SSD+HDD. Чтение: сумма скоростей, запись: соответствует скорости самого медленного. Разумеется, держать кэши и профиль пользователя так не имеет смысла, а вот систему и программы — вполне.
Для пользователей zsh могу предложить для копирования и вставки использовать widget’ы:
function _-insert-primary()
{
emulate -L zsh
LBUFFER="${LBUFFER}$(xclip -o)"
}
function _-insert-clip()
{
emulate -L zsh
LBUFFER="${LBUFFER}$(xclip -o -sel clip)"
}
zle -N insert-primary _-insert-primary
zle -N insert-clip _-insert-clip
bindkey -M evi "\C-r*" "insert-primary"
bindkey -M evi "\C-r+" "insert-clip"
. С ними вставка будет на <C-r>* (мышиный буфер) и <C-r>+ (обычный буфер) (как в vim). Комментироваться указанным способом будет всё равно одна строка, но есть важное отличие: при вставке таким способом команды не исполняются независимо от наличия или отсутствия в них каких‐либо символов, включая символ новой строки.
При желании можно модифицировать widget’ы, чтобы все строки комментировались автоматически при наличии в начале строки #, но раскомментировать их потом будет не слишком удобно (если только не написать ещё один widget для раскомментирования).
Такое происходит, если в конфиге использовались escape‐последовательности, выдаваемые стрелочками, напрямую (или с использованием zkbd), а не получались тем же способом, каким их получает zsh.
Я предполагаю, что для получения используется terminfo. Во всяком случае, echo $terminfo[kcuu1] выдаёт то, что выдают стрелочки (но у меня — не всегда: при использовании команды внутри Vim всё правильно, а внутри zsh — нет). Соответствие названий записей клавишам можно узнать в man terminfo.
Я тоже часто использую PageUp/PageDown для навигации по коду в режиме размышлений. Но это не тот случай: если вам надо дописать перед командой sudo или что‐то в этом роде, то здесь другая логика: о необходимости изменений я узнаю немедленно по прекращению работы команды (т.е. либо она сразу завершается с ошибкой, либо я её убиваю по <C-c>, видя неправильный результат) и, как правило, у меня так же немедленно возникает идея, как её исправить. Немедленно. Если идея уже есть, то руки не должны меня тормозить. Со стрелками они тормозят. Разумеется, предполагается, что я не убирая руки с основной позиции. Не вижу причин убирать, если я знаю, что мог что‐то сделать неправильно.
Второй, более частый, use-case: недописанные цепочки. Т.е. я проверяю, действительно ли, к примеру, grep выдаёт, то, что мне нужно; затем проверяю следующую команду в цепочке (она уже придумана, но пишется только после проверки предыдущей). Идея всех команд в голове уже есть. Зачем себя тормозить?
Отмечу ещё, что чем лучше моё владение клавиатурой, тем менее мне нужны различного рода сокращения.
В zsh если привязать вверх к history-beginning-search-backward (или просто оставить функцию по‐умолчанию), то независимо от того, была ли помещена предыдущая команда в историю или нет, стрелка вверх её покажет. Но если команда в историю не была помещена, то любая следующая команда сделает невозможным вызов предыдущей при нажатии вверх. К примеру, <Space>echo I do not want this in history<CR><Up> покажет <Space>echo I do not want this in history, тогда как <Space>echo …<CR><CR><Up> — уже нет (из‐за двух <CR>).
Единственное но: я не знаю, как в zsh одной настройкой убирать из истории команды, начинающиеся с пробела. У меня для этого есть функция zshaddhistory:
function zshaddhistory()
{
emulate -L zsh
if (( ${+_HISTLINE} )) ; then
print -sr -- "${_HISTLINE}"
unset _HISTLINE
elif (( 0x20==#1 )) ; then
return 1
else
print -sr -- "${1%%$'\n'}"
fi
fc -p
}
. Она же ответственна за подмену истории в некоторых случаях (именно для этого здесь находится первое условие с _HISTLINE).
Насколько мне известна, такая настройка всё же существует.
Почему? Shift+1 можно достать, не особо двигая кисти рук относительно основной позиции при слепой печати, а стрелочки и <Home> можно нажать, не двигая кисть только на небольших (ноутбучных и им подобных) клавиатурах.
Только это всё равно менее быстро, чем <C-p>, заменяющее у меня <Up>; при том из‐за того, что <C-p> (как и <Up>) привязан к history-beginning-search-backward нажимать <Home> не нужно (в таком варианте позиция курсора при навигации по истории остаётся неизменной). Оболочка, конечно же, zsh.
Найти редактор/IDE для C со сниппетами несложно. Но если учитывать их наличие, то скорость написание обеих конструкций становится зависимой исключительно от настроек редактора, но не от количества символов в конструкциях. Где‐то что‐то может даже иметься в наличии по‐умолчанию, но не факт, что в некотором конкретном редакторе по‐умолчанию будет while (true), а не for (;;).
Есть dispatch-conf, у которого, как говорят, дело с этим лучше. В частности, в его справке я нашёл упоминание об использовании RCS (это одна из древних VCS) или «каталога архивов» (т.е. версионировании без VCS) при наличии соответствующих настроек. То есть, говоря о том, что схожий вариант не интегрировали в Gentoo, вы, вероятно, не правы. Немного жалко, что я не стал разбираться: возможно, можно было бы допилить dispatch-conf для использования mercurial.
Также, чтобы избежать holywar’а, нужна поддержка любой VCS. Или, по крайней мере, любой VCS, имеющей нормальные ветки с простым merge.
Ещё, возможно, никому просто не пришло в голову, что это надо встроить в систему. Я не раз подумывал написать о моём скрипте сюда (на habrahabr), но ни разу — пойти на bugs.gentoo.org и предложить что‐то подобное там. Хотя с поддержкой со стороны portage было несколько
проще: мне не нужно было бы убеждаться, что все мои изменения зафиксированы перед использованием скрипта. Поддержка portage нужна только, чтобы отделять мои изменения от не моих, mercurial всё равно не даст сделать слияние при наличии незафиксированных изменений. Можно, правда, делать слияние в третьем месте, а в /etc делать pull+update, тогда незафиксированные изменения будут слиты (но останутся незафиксированными). Но конфликты придётся разрешать в том третьем месте.
Merge также не всегда корректен. Просмотр изменений после слияния — это задача администратора, но могло оказаться и так, что запрос был, но кто‐то решил, что администраторы не будут делать review и потому данная возможность опасна.
А насчёт слияния конфигов: у меня этим занимается mercurial. Конечно, потребовалось написать скрипт, но оно того стоило: 99% времени слияние — просто
./update-script --all(он перемещает все изменения в клон /etc, содержащий только неизменённые версии конфигов в ветке default, применяет их там без каких‐либо вопросов, делает commit, затем запускает pull и merge в ветку user в /etc). Зачем делать merge самостоятельно, если есть VCS, которая умеет этим заниматься?Для падений сборки есть
emerge --keep-going: можно собрать всё, что собирается, а затем разбираться с проблемами. Ещё естьemerge --resume[ --skipfirst]для возобновления сборки, но я этим не пользуюсь.Новость на habrahabr.
Главный вопрос в том, какую задачу решаете вы, а какую — dd. Dd корректно решает задачу копирования данных на блочном устройстве. А нужен перенос файлов, с которыми работают ваши программы, на новое устройство, с новым размером. Даже если новое устройство имеет тот же размер, копирование зачастую уменьшает уровень фрагментации (и не переносит блоки с мусором).
dd— это утилита для копирования (и, возможно, некоторого изменения) одного файла. Одного. В документации так и написано: «dd — convert and copy a file» Это не средство переноса множества файлов. Это не средство для создания файловой системы. Средство для переноса — этоcp(но tar’у я больше доверяю). Для создания —mkfs.Так что нет, вы не используете программу в *nix way. Вам нужно создать новую ФС и перенести туда файлы. Вместо этого вы берёте один файл (в виде блочного устройства) и копируете его в другое место (другое блочное устройство).
Сколько своего времени вы потратите на resize, если цель больше, чем источник? Что будете делать с
dd, если цель меньше, чем источник? Зачем вы вообще берёте с собой мусор из свободных блоков?Сейчас не удивлюсь. Но возьму tar, т.к. он проще.
Если бы кто‐то внял вашему совету, то он бы был удивлён тем, что место не увеличилось.
tar c|tar xимеет больше смысла, так как вы не будете копировать с помощью dd данные, которые вам заведомо не нужны (при этом, разумеется, получите нелинейную запись с нелинейным чтением).Когда читает одно приложение и последовательно, конечно, никакого прироста нет: mdadm не занимается угадыванием блоков, которые будут запрошены далее.
<C-r>*(мышиный буфер) и<C-r>+(обычный буфер) (как в vim). Комментироваться указанным способом будет всё равно одна строка, но есть важное отличие: при вставке таким способом команды не исполняются независимо от наличия или отсутствия в них каких‐либо символов, включая символ новой строки.При желании можно модифицировать widget’ы, чтобы все строки комментировались автоматически при наличии в начале строки
#, но раскомментировать их потом будет не слишком удобно (если только не написать ещё один widget для раскомментирования).Я предполагаю, что для получения используется terminfo. Во всяком случае,
echo $terminfo[kcuu1]выдаёт то, что выдают стрелочки (но у меня — не всегда: при использовании команды внутри Vim всё правильно, а внутри zsh — нет). Соответствие названий записей клавишам можно узнать вman terminfo.sudoили что‐то в этом роде, то здесь другая логика: о необходимости изменений я узнаю немедленно по прекращению работы команды (т.е. либо она сразу завершается с ошибкой, либо я её убиваю по<C-c>, видя неправильный результат) и, как правило, у меня так же немедленно возникает идея, как её исправить. Немедленно. Если идея уже есть, то руки не должны меня тормозить. Со стрелками они тормозят. Разумеется, предполагается, что я не убирая руки с основной позиции. Не вижу причин убирать, если я знаю, что мог что‐то сделать неправильно.Второй, более частый, use-case: недописанные цепочки. Т.е. я проверяю, действительно ли, к примеру,
grepвыдаёт, то, что мне нужно; затем проверяю следующую команду в цепочке (она уже придумана, но пишется только после проверки предыдущей). Идея всех команд в голове уже есть. Зачем себя тормозить?Отмечу ещё, что чем лучше моё владение клавиатурой, тем менее мне нужны различного рода сокращения.
history-beginning-search-backward(или просто оставить функцию по‐умолчанию), то независимо от того, была ли помещена предыдущая команда в историю или нет, стрелка вверх её покажет. Но если команда в историю не была помещена, то любая следующая команда сделает невозможным вызов предыдущей при нажатии вверх. К примеру,<Space>echo I do not want this in history<CR><Up>покажет<Space>echo I do not want this in history, тогда как<Space>echo …<CR><CR><Up>— уже нет (из‐за двух<CR>).Единственное но: я не знаю, как в zsh одной настройкой убирать из истории команды, начинающиеся с пробела. У меня для этого есть функция zshaddhistory:. Она же ответственна за подмену истории в некоторых случаях (именно для этого здесь находится первое условие с
_HISTLINE).Насколько мне известна, такая настройка всё же существует.
Shift+1можно достать, не особо двигая кисти рук относительно основной позиции при слепой печати, а стрелочки и<Home>можно нажать, не двигая кисть только на небольших (ноутбучных и им подобных) клавиатурах.Только это всё равно менее быстро, чем
<C-p>, заменяющее у меня<Up>; при том из‐за того, что<C-p>(как и<Up>) привязан кhistory-beginning-search-backwardнажимать<Home>не нужно (в таком варианте позиция курсора при навигации по истории остаётся неизменной). Оболочка, конечно же, zsh.while (true), а неfor (;;).TRUE? Вstdio.hего нет, в самом коде тоже нет, дописывать его туда я не предлагал.