Поздно. Уже 20 рублей за тот пост Microsoft мне перечислил.

Позор. Я на пожертвованиях по 25р получаю.

Для слепой десятипальцевой печати это оверкилл. Особенно с учетом того, что блок стрелок обычно имеет layout, сводящий возможность ошибки при нажатии к нулю, в отличие от hjkl, а также с учетом того, что рядом с блоком стрелок на большинстве layout-ов имеется блок постраничного и внутристрочного перемещения. Опять же, Ctrl+Стрелки (как минимум боковые) - перемещение по словам. В vim, несмотря на то, что Ctrl+стрелки пашет (пришлось адаптировать, поскольку даже создатели поняли ненужность), аналогичное с hjkl - хрен.

Да, vim - это экономилка трафика. Исключительно с этой целью и был писан, исключительно из этих соображений он стал таким (режимы, перемещение курсора hkjl, вместо «дорогих» по трафику стрелок, куча макрокоманд на хоткеях, причем, в угоду экономности по трафику, размещенных на клавиатуре через жо как угодно, лишь бы не на «дорогих» F1-F12/стрелках/etc).

ты упоролся. в vim просто все фичи на кнопках, которые _везде_ есть. Fn и стрелки есть не везде. на нетбуках и смартфонах часто их нет (точнее они по разному интегрированы с другими кнопками и/или используются с иными целями, причём везде по своему).

А вот на трафик всем плевать. Даже если ты в MS-DOS фапаешь на картинку ЦП с диалапа, то поверь - лишний байт погоды не сделает.

Смотри, там inode'и кончаются бывает.

ну если сделать раздел в 1Гб, и забить его файлами размера 0 байт - да, inode быстро кончаться. Быстрее чем в райзере. Хотя и файлов больше получится.

аналогичное с hjkl - хрен.

про «w», «b» слышал? а как «по словам» вверх/вниз - мне непонятно.

про «w», «b» слышал?

Нет, что это? Это эзотерическое наименование комбинаций Ctrl+h/Ctrl+l ?

А вот на трафик всем плевать

Это ты создателю vi иди рассказывай. Про то, как ему на трафик плевать. И пользователям вымпухлятора рассказывай, что им плевать на трафик (осторожно! потребуется рассказать другой чуть более нужный, чем никак use-case для их любимого vimperator).

Нет, что это? Это эзотерическое наименование комбинаций Ctrl+h/Ctrl+l ?

след. слово/прошлое слово.

Это ты создателю vi иди рассказывай. Про то, как ему на трафик плевать

И пользователям вымпухлятора рассказывай, что им плевать на трафик (осторожно! потребуется рассказать другой чуть более нужный, чем никак use-case для их любимого vimperator).

разработчики vim (а тем более vi) никакого отношения к вимператору не имеют. У тебя от какого ПО такая боль ниже спины?

У тебя от какого ПО такая боль ниже спины?

Постановка вопроса неправильная, делай новую попытку.

разработчики vim (а тем более vi) никакого отношения к вимператору не имеют

Спасибо, лейтенант.

след. слово/прошлое слово.

Хочу так же интуитивно понятно, как Ctrl+стрелки (которые почему-то интуитивно понятно в vim работают).

Постановка вопроса неправильная, делай новую попытку.

твоя боль - твоя проблема

Хочу так же интуитивно понятно, как Ctrl+стрелки (которые почему-то интуитивно понятно в vim работают).

работают. И в чём твоя проблема? w проще, чем ^l.

твоя боль - твоя проблема

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

Для слепой десятипальцевой печати это оверкилл.

как раз без неё особо и не понимаешь, почему тянуться за мышкой или к стрелочкам - плохо.

Особенно с учетом того, что блок стрелок обычно имеет layout, сводящий возможность ошибки при нажатии к нулю, в отличие от hjkl

ЩИТО?

В vim, несмотря на то, что Ctrl+стрелки пашет (пришлось адаптировать, поскольку даже создатели поняли ненужность), аналогичное с hjkl - хрен.

ЩИТО?

ЩИТО?

ЩИТО?

Читай еще раз.

лучше не стало. если что в вим есть свои хоткеи для перемещения по словам и страницам, и для их использования не надо перемещать руки непойми куда.

Для слепой десятипальцевой печати это оверкилл.

А я бы сказал мастхев) Лично я в консоли пользуюсь не вимом а емаксом (меня напрягает необходимость переключать режимы), но там и в IDE в иксах не пользуюсь ни стрелочками ни home end pgup pgdn. Все на «буквенных» хоткеях, перемещение по символам, по словам, начало, конец строки, постранично. Профит в том, чтобы не передвигать руки, это долго и более напряжно для мозга. Ошибок нет, ты же не промахиваешься, когда печатаешь слова. Правда на переучивание затрачивается время, но потом уже все нажимаешь на автомате, как и стрелочки.

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

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

Дурак штоле?

Дурак штоле?

http://www.opennet.ru/opennews/art.shtml?num=36491

механизм самоверификации, работающий при выполнении команд git, не работает для «git --mirror». При выполнении «git --mirror» зекралирование выполняется без проверки целостности и без лишних предупреждений даже в случае наличия в репозитории повреждённых объектов коммитов

Кстати, на сегодняшний день на линукс принципиально не существует фб2ридера полноценного, вот это проблема.

Эмм, fbreader?

Представь себе, что его никто не «отключал». --mirror и не должна ничего проверять.

И сейчас они не отключили --mirror, а просто начали делать бекапы. Кагбе претензий к git нету - у него ничего ненормального в поведении обнаружено не было.

Представь себе, что его никто не «отключал». --mirror и не должна ничего проверять.

Они не знали, что --mirror не проверяет целостность репозитария, в документации момент обойден. Это на фоне заявлений Линуса о сверхнадежности git и сверки контрольных сумм всего и вся.

Старый быдлокодер и тролль. Характер скверный. Не женат.

В криок... Красную книгу.

Эмм, fbreader?

Он то-ли не все теги поддерживает, то-ли неправильно. В итоге в некоторых книгах сбои с теми же картинками. Могу пример прислатьКерниган, Ричи. Язык C). Мы правили под себя один ридер как-то для поддержки, ибо оказалось, что ни один не работает правильно.

Я неправильно выразился: они использовали git --mirror, который не гарантирует проверку целостности, вместо git pull или обычных инкрементальных бэкапов

kde+обновления+git+ext4

Линукснадёжность: падает одно — ломается всё. Хотя встряска этим чудакам не помешала бы: глядишь одумались бы и запилили kde5 на основе kde3.5.

говно-git.

Как сделать в hg что-то типа git add --patch? Эта комманда выводит текущий полный diff чанками и спрашивает какие изменения мы хотим закоммитить (вернее, кладёт в кэш для последующей работы, но это не важно). Т.е. оно пилит большой патч на несколько маленьких и даже позволяет его подправить руками.

они использовали git --mirror, который не гарантирует проверку целостности

Можно ссылочку на официальную документацию где сказано «не используйте git --mirror для бэкапов»?

Как сделать в hg что-то типа git add --patch? Эта комманда выводит текущий полный diff чанками и спрашивает какие изменения мы хотим закоммитить

hg qrecord

Они не знали, что --mirror не проверяет целостность репозитария, в документации момент обойден.

с каких пор зеркало должно что-то проверять?? Твоё зеркало твои прыщики фотошопит? Фотки сохраняет?

Во-первых, это git clone, а только потом --mirror. Просто git clone проверяет целостность? А --local? А --bare?

Во-вторых, откуда ты узнал, что проверяет, а что нет, если в документации ни слова, а Линус собственной персоной с трибуны вещал, какой git крутой, как всё на свете защищает огромными чексуммами, и как ему всегда можно доверять?

«If you have disc corruption, if you have RAM corruption, if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee…» © Linus Torvalds.

Во-первых, это git clone, а только потом --mirror.

зеркало и не должно проверять. Неужели это так сложно для тебя? А если репа уже кривая, её бекапить разве не нужно? Другое дело, что на один бекап надеяться нельзя, и удалять старый надо только после создания И ПРОВЕРКИ нового. но это уже проблемы бекапилки, а не VCS.

Во-вторых, откуда ты узнал, что проверяет, а что нет, если в документации ни слова, а Линус собственной персоной с трибуны вещал, какой git крутой, как всё на свете защищает огромными чексуммами, и как ему всегда можно доверять?

дык по логике - прыщик _должен_ быть виден в зеркале. На то оно и зеркало.

«If you have disc corruption, if you have RAM corruption, if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee…» © Linus Torvalds.

git will notice them.

кто-то чего-то не заметил?

зеркало и не должно проверять

Где об этом написано?

если репа уже кривая, её бекапить разве не нужно?

Не путаем бекап и клонирование.

дык по логике

Ты так и не сказал, где написано, с какими ключами git clone проверяет целостность репозитария, а с какими — нет.

кто-то чего-то не заметил?

Да. Даже не чихнув git клонирован битый репозитарий. То есть «It’s not a question of if» — лажа. Есть огромное «если», и ты сейчас настаиваешь, что так и должно быть.

зеркало и не должно проверять

Где об этом написано?

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

Не путаем бекап и клонирование.

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

Ты так и не сказал, где написано, с какими ключами git clone проверяет целостность репозитария, а с какими — нет.

доку надо читать, я не в курсе. Однако знаю, что при зеркалировании - не должно.

Да. Даже не чихнув git клонирован битый репозитарий. То есть «It’s not a question of if» — лажа. Есть огромное «если», и ты сейчас настаиваешь, что так и должно быть.

это логично. Если тебе разбили рожу - это конечно плохо, но зеркало не должно её тебе лечить. И вообще оно тут не при чём. Оно может только помочь в лечении, максимально правдиво показав, что осталось. Предполагается, что сам факт разбития морды тебе известен, и красная надпись на зеркале - излишняя. А уж тем более, превращение тебя в MLP. Даже если ты на пони больше всего похож.

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

Тебе показали git раньше, чем читать научили?

доку надо читать, я не в курсе.

Как прочтешь, расскажешь?

знаю, что при зеркалировании - не должно.

При клонировании репозитария. Повторяю, где это написано? Линус гарантировал, что гит заметит битые данные без всяких «если».

разбили рожу - это конечно плохо, но зеркало не должно её тебе лечить

Никто не говорит о лечении. Ожидалось, что оно хотя бы покажет. Не сложилось. Зато теперь как минимум на одном сервере будет ФС, проверяющая целостность данных.

При клонировании репозитария. Повторяю, где это написано? Линус гарантировал, что гит заметит битые данные без всяких «если».

зеркалирование - процесс точного копирования, без всяких изменений.

Тебе показали git раньше, чем читать научили?

нет. git'а тогда не было, а вот зеркала - уже были.

Никто не говорит о лечении. Ожидалось, что оно хотя бы покажет. Не сложилось.

что может «показать» зеркало? что есть, то и копирует. Если репа битая - копирует битую репу. Не вижу тут ничего странного, и/или неожиданного. Есть в гите не только зеркалирование, но и много другого разного. Почему юзали именно mirror версию clone - я не знаю. Подозреваю, что зеркалирование быстрее и проще, ибо ничего не проверяет. И надёжнее, в том смысле, что зеркало всегда что-то отражает.

зеркалирование - процесс точного копирования, без всяких изменений.

Узнай же наконец, что такое git clone --mirror.

git'а тогда не было, а вот зеркала - уже были.

Вот у меня есть несколько зеркальных ZFS пулов, но они хоть убей не будут распространять данные из сбойных секторов с одного диска на другие. Не все зеркала одинаковые. И git clone --mirror — не совсем зеркало, да а Линус обещал надежность без всяких «ну это же миррор, чего вы хотели?».

Почему юзали именно mirror версию clone - я не знаю.

Могу рассказать. Для того, чтобы получить «чистый репозитарий» (bare) и замапить ref-ы. RTFM. Подскажи, как это сделать другим способом?

Ещё раз: они не знали, что --mirror не проверяет целостность, в документации про это тишина. Положились на «гарантию» Торвальдса. Теперь будут умнее, и станут всё проверять. Что непонятно-то осталось?

может, тогда завести баг/feature request на это место в документации?

Узнай же наконец, что такое git clone --mirror.

сам говоришь(и ты прав, я погуглил немного), что это слабо документировано. Лучше ты расскажи, да ещё расскажи, каков юзкейс. А то я так понял, что это какое-то подобие банок (bundle) из ртути. Только кривое, и неюзабельное.

Ещё раз: они не знали, что --mirror не проверяет целостность, в документации про это тишина. Положились на «гарантию» Торвальдса. Теперь будут умнее, и станут всё проверять. Что непонятно-то осталось?

понимаешь, если на ФС кривые данные - они отзеркалируются отлично. Как были кривые, так кривыми и останутся. CRC битого носителя тут не причём. Также и с репой - кривая репа и должна криво клонироваться(в зеркало). Мне непонятно, что тебе непонятно? И с чего кдешники решили, что должно было что-то проверяться? Это надо было после зеркалирования делать проверку. И если криво - не затирать прошлый бекап.

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

Git тоже наверное проверяет правильность _зеркалирования_ - т.е. после git clone --mirror мы можем быть уверенны в том, что зеркало идентично оригиналу. При чём тут целостность оригинала? Если ты запишешь на свой пул файл «карова», то и отзеркалируется «карова», хоть это и неграмотно.

если на ФС кривые данные - они отзеркалируются отлично.

Данные побились на ФС, стали кривыми, и теперь контрольные суммы, которые git хранит на каждый чих, не совпадают. Но git берет, и кладет в новый репозитарий битые данные с диска, а контрольную сумму от правильных файлов.

с чего кдешники решили, что должно было что-то проверяться?

«if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee…» © Linus Torvalds.

При чём тут целостность оригинала?

При том, что в ZFS сквозная проверка, и если с диска прочитано не то, что записано (битый сектор, например), то ничего отзеркалировано не будет. Даже наоборот — будет предпринята попытка восстановить данные.

Если ты запишешь на свой пул файл «карова»

В пул (git или ZFS) было записано «корова», а рядом приклеен стикер «оро-оло», но с диска прочиталось «карова». Радостный git склонировал ошибку, прилепив «коровий» стикер, а ZFS попыталась восстановить данные, а если не удалось — выдала ошибку.

может, тогда завести баг/feature request на это место в документации?

Там и так уже приличное обсуждение по поводу недостатков документации.

Данные побились на ФС, стали кривыми, и теперь контрольные суммы, которые git хранит на каждый чих, не совпадают. Но git берет, и кладет в новый репозитарий битые данные с диска, а контрольную сумму от правильных файлов.

ну. проблема не в git.

«if you have any kind of problems at all, git will notice them. It’s not a question of if. It’s a guarantee…» © Linus Torvalds.

дык в git'е же есть проверки, и они должны работать? Разве нет? Не в этом случае конечно.

При том, что в ZFS сквозная проверка, и если с диска прочитано не то, что записано (битый сектор, например), то ничего отзеркалировано не будет. Даже наоборот — будет предпринята попытка восстановить данные.

VCS - это не файловая система. Это несколько более высокий уровень. И ошибки ФС она фиксить не должна.

Вот скажи мне: если у тебя будет битая память, твоя ZFS справится? Поймёт, что кеш испортился? Вот EXT3/4 бессильна, я проверял. Она определяет, что файл убитый, и пользуясь журналом восстанавливает его к последнему непротиворечивому состоянию. В большинстве случаев - усекает файл до нуля. И то, только при монтировании, во время fsck. Я не сомневаюсь, что с битой памятью твоя ZFS будет работать не лучше. Всё потому, что ошибка уровнем ниже, и ФС спроектирована так, что всё более низкого уровня в порядке. Ошибка может возникнуть только на том уровне, где работает эта система, т.е. на секторах носителя.

В пул (git или ZFS) было записано «корова», а рядом приклеен стикер «оро-оло», но с диска прочиталось «карова».

писал-то ты «корова», но вот запись была закеширована, и радостная ZFS радостно не глядя записала «карова». Откуда ей знать, что память битая? И стикер считался от «каровы», потому ошибки вроде и нет. А может и от «коровы», тогда ошибка будет, но почему-то на зеркалировании, несмотря на то, что при собственно записи ошибки не было (мы диагностируем битый HDD, хотя проблема в другом, и к HDD отношения не имеет).

Или ты хочешь сказать, что ZFS дважды хеш считает? На входе и на выходе из кеша? Не верю.

дык в git'е же есть проверки, и они должны работать? Разве нет?

Есть. Должны. Но в некоторых случаях не работают, и не только при clone --mirror, к сожалению.

Не в этом случае конечно.

«It’s not a question of if». Заявлялось, что git всегда обнаружит ошибки диска или памяти, без всяких «если --mirror, то не сможет». Люди верили.

ошибки ФС она фиксить не должна.

Кто сказал про «фиксить»? Надежная VCS должна обнаружить битый репозитрий при любой операции с ним, включая клонирование. Обнаружить и громко выматериться, а не исправить.

если у тебя будет битая память, твоя ZFS справится?

У тебя до сих пор в серверах не ECC память? ССЗБ.

писал-то ты «корова», но вот…

Давай не изобретать новых сущностей. В серверах стояла память с ECC, а данные побились на дисковых накопителях.