LINUX.ORG.RU
ФорумAdmin

Потрясающий косяк в UNISON

 , ,


0

2

Найденный потрясающий косяк в UNISON - это мое безапелляционное мнение. Хотя готов выслушать мнение других знатоков, прежде чем писать злобное иссуе его создателям, или же сборщикам, это будет зависеть от вас. Злобное - потому что не ожидая подвоха, засинхронизировал тысячи документов между двумя компами.
Раз, другой... как вдруг заметил, что даты и время документов поменялись!!!

Для меня это событие сродни настоящей IT-катастрофе, поскольку ДАТА и ВРЕМЯ для меня играет важнейшую роль (достаточно вспомнить TheirBirthday).
Они позволяют мне ориентироваться в тысячах документов, понимая, когда они были мною созданы или модифицированы и принимать соответствующие решения.
Может, для кого-то это и не важно, но для меня чрезвычайно критично для работы с ними.
В итоге пришлось доставать документы из бекапов, сравнивать, анализировать и восстанавливать, на что ушла уймища времени, вот поэтому сейчас я очень зол.

Итак, с преамбулой закончено, перехожу к сути.
Да, я в курсе, что UNISON создан не Васяном на коленках, а неким профессором, поэтому можно надеяться, что продукт достойный, достаточно вспомнить профессора Никлауса Вирта и его Pascal. Однако, как часто это бывает, дьявол кроется в мелочах.
В данном случае UNISON при репликации с какого-то, извините, хера, меняет оригинальную ДАТУ и ВРЕМЯ на момент репликации! Это звездец...

По моему стойкому убеждению, ДАТУ и ВРЕМЯ документов и файлов имеют право менять только те приложения, которые с ними непосредственно работают, т.е. их создают, редактируют и т.п.
За примером далеко ходить не надо - достаточно взглянуть на MC, который создали умные люди: при копировании в нем галочка "Сохранять атрибуты" по умолчанию взведена.
Взведена, а не сброшена, как в UNISON!

Поэтому при копировании или синхронизации ДАТА и ВРЕМЯ НЕ ДОЛЖНЫ меняться!!! (кроме особых случаев, определяемых нами, пользователями)
Иначе наступит временной хаос, как и случилось у меня. Из-за того, что UNISON, которым я пользуюсь в Manjaro ARM, ведет себя ровно наоборот.

Конечно, позже я отыскал ключик times и захерачил его в конфиг default.prf в виде -

times = true
и его благотворное действие глобально распространилось на все существующие и создаваемые профили.

Казалось, можно было бы успокоиться? Ну уж нет!
Идиотское дефолтовое поведение UNISON настолько потрепало мне нервы и сожрало драгоценное время, что у меня руки чешутся ткнуть, как котенка, проффесора или сборщика, мордой в этот алгоритмический косяк, вопрос только - кого?

Итак, что вы об этом всем думаете? И как ведет себя UNISON в ваших дистрибутивах, отличных от Manjaro?
Это и поможет выявить, кого надо ткнуть.




Перемещено hobbit из general

★★★★★
23 февраля 2024 г.

Ну что, кто присоединится к Союзу меча и орала? 😜
Я имею в виду объединение пользователей, которые активно использует UNISON и заинтересованы в его улучшению.
Цель - добиться от гитхбовских сборщиков устранения описанного косяка.
Заодно это касается и каталогов, на них в UNISON вообще управы нет.

Убежден - это не технический баг, а алгоритмический, и его надо вырубить под корень, чтобы он не повторялся в будущих версиях.
Файл, если он всего лишь копируется, не должен менять свои временные атрибуты.

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

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

PS. Создатели MC об этом хорошо подумали и сделали так, что копируемые файлы и каталоги сохраняют свои времена - и это правильно, товарищи!

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)

Да, я в курсе, что UNISON создан не Васяном на коленках, а неким профессором, поэтому можно надеяться, что продукт достойный

Если профессором, то я, как раз, на это бы не надеялся.

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

А если файловая система куда/откуда переложили не поддерживает эти атрибуты, что делать?

А как же MC это неискаженное копирование поддерживает?

Если профессором, то я, как раз, на это бы не надеялся.

Обойдемся и без проффесоров 😂

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от chukcha

А как же MC это неискаженное копирование поддерживает?

В общем-то там две фс (fat и ntfs) разработанные под одну ОС и задачи, и обе поддерживают +- одинаковые атрибуты.
И там, например, есть дата создания файла, а в линуксовом ext3 ее нет.

Так же дата модификации файла, внезапно, меняется при изменении прав доступа к файлу как линуксе так и в MS. То есть дата изменения скорее подсказка, а не 100% показатель, что данные в файле были изменены - могли быть изменены метаданные.

Какую-то логику «проставить дату изменения, если она есть, такой же как она была, а если не было то сегодня» из всего этого многообразия атрибутов можно придумать, и она реализована в параметре times=true, и мне, знакомым с rsync и логикой подобных утилит не видится проблемы в том, что она по умолчанию выключена.

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

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

Проблема в том, что она по умолчанию выключена, а это в принципе неправильно,
Имхо, все нормальные файловые менеджеры такой дуристикой, как икажение временных атрибутов, не страдают, и копируют их с сохранением.

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

Почему я каждый раз при использовании UNISON должен помнить этe дурацкую особенность и выставлять times=true?

Поскольку все копировщики приучают к тому, что они нормально копируют, то про «особенный» UNISON это забываешь, и на хранилищах после его синронизации, т.е. копирования, остается полный кавардак 😡

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
13 июля 2024 г.
Ответ на: комментарий от chukcha

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

Rsync, конечно, штука замечательная, но несколько «туповатая», поскольку при бекапе каждый раз заново обшаривает все файлы, и поскольку их сотни тысяч, только на это обшаривание уходит несколько часов.

В то же время UNISON подобные действия выполняет за считанные секунды, поскольку ведет индексную базу.

У кого-то есть опыт использования UNISON в качестве бекапирования?
Т.е. односторонней, а не двухсторонней синхронизации.

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

У кого-то есть опыт использования UNISON в качестве бекапирования? Т.е. односторонней, а не двухсторонней синхронизации.

Я использую. Вроде нормально (кроме уже упомянутой проблемы с версиями унисона).

Копирую проекты/документы/настройки на запасной диск на рабочем компе, с рабочего компьютера на NAS, с рабочего компьютера на ноут (тут двусторонняя синхронизация), и с ноута на ещё один NAS, когда туда приезжаю. Получается, что у меня пять копий.

Уже лет пять эта схема работает.

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

Вот мой скрипт:

#!/bin/bash

# Сначала синхронизируем на второй SSD
home="/home/me"
backup="/media/data/backup"

for dir in "Projects" ".data"
do
	src="${home}/${dir}"
	dst="${backup}/${dir}"
	echo backing up ${src} to ${dst}
	unison ${src} ${dst} -batch -force ${src} -confirmbigdel=false
done


# Теперь синхронизируем на NAS
atom="ssh://atom2//media/data/z-backup"

for dir in "Projects" ".data" "docs"
do
	src="${home}/${dir}"
	dst="${atom}/${dir}"
	echo backing up ${src} to ${dst}
	unison ${src} ${dst} -batch -force ${src} -confirmbigdel=false
done

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

Спасибки! 🍺 🍺 А животворящий ключик -time не используете?

И как со скоростью работы по сравнению с Rsync в реале, не сравнивали?

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Как что, очевидно же, меняет время и дату создания файлов.

Вообще-то прога, собственно, синхронизирует файлы 😊
А ее недостаток ну да, в том, что умолчанию она меняет их дату/время.

Все собираюсь написать об этом косяке, только не знаю, кому.
Потому что не знаю, кто заложил такое неправильное дефолтовое значение - сборщики или создатели.

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

Спасибо, что тред, а не бред 😄
А как тут успокоишься, если этот злобный косяк идет вопреки привычным правилам копирования (синхронизация одна из его разновидностей) и запорол мне файловое хранилище?
В том смысле, что исказил мне файловые дату/время, которые для меня очень важны.

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

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

Для чего и как пользоваться иссуями на гитхабе, в курсе.
Только они ли, в смысле сборщики, являются первичными виновниками этого косяка?
Может все-таки авторы-разработчики, а сборщики только тупо повторяют его?

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

Какая была в Manjaro сейчас не помню, на данный момент тренируюсь в Debian на

$ unison -version
unison version 2.52.1 (ocaml 4.13.1)
И вот что изумило! 😲

Взял такой исходный каталог -
Размер:		25,4 ГиБ (27 226 093 982 байта)
Содержимое: 1781 items (1578 files, 202 folders)
и с помощью UNISON запустил 1-е бекапирование -
real	8m58,557s
user	3m27,466s
sys	1m48,393s
Понятно, что 1-е бекапирование происходит долго, т.к. копируются все файлы и создается база данных UNISON.

Затем добавил примерно на 1/3 данных в исходный каталог, снова запустил UNISON и получил -
real	0m3,246s
user	0m2,232s
sys	0m0,692s
Понятно, что благодаря созданной индексной БД, 2-е и последующие бекапирования происходят намного быстрее.


Затем перешел к тестам на Rsync
-----------------------------------------------------------
Сначала выполнил 1-е бекапирование и получил такое время -
real	5m12,219s
user	0m47,771s
sys	2m21,394s
Затем добавил примерно на 1/3 данных в исходный каталог, снова запустил Rsync и получил -
real	0m3,445s
user	0m0,687s
sys	0m2,142s

Т.е. Rsync (0m3,445s) по быстроте работы практически не уступает UNISON (0m3,246s) 😨

Но такое не может быть! Rsync ведь не ведет свою базу данных!
Полученные результаты ни в какие ворота не влезут и ни на какой глобус не налезут.
Я не могу объяснить это чудное явление природы... 😳

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 3)
Ответ на: комментарий от chukcha

И почему Unison должен быть быстрее? Ему же все равно надо оббежать ВСЕ файлы, чтобы понять, что изменилось по сравнению с его базой.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от bigbit

ВСЕ, да не совсем. UNISON все файлы оббегает только в источнике, и потом только сравнивает их с базой, так что в целом это все происходит быстрее, чем в Rsync, который оббегает все файлы и в источнике, и в таргете.

И даже если вы правы, то зачем тогда UNISON? В том смысле, что какой от него выигрыш для бекапирования?

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от chukcha

Т.е. ты хочешь сказать, что если файл удалили в таргете, то Unison его не перекопирует, т.к. он не сканирует таргет? Ну что ж, отличный бэкап.

Как бы то ни было, сканирование источника и таргета скорее всего идет параллельно, вряд ли здесь будет разница.

А почему от него должен быть выигрыш для бэкапирования? Он ведь не для этого.

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

Вот здесь Потрясающий косяк в UNISON (комментарий) Beewek использует его именно для бекапа.
Наверное, именно из-за выигрыша, иначе зачем?
Если выигрыша нет, проще будет Rsync, и Rsnapshot на его основе.

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

Наверное, именно из-за выигрыша, иначе зачем?

А ты сам прочитал то сообщение, на которое дал ссылку?

Потому что у него там написано, «зачем».

У него там двухсторонняя синхронизация.

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

У него только в одном месте написано, что двухсторонняя -

с рабочего компьютера на ноут (тут двусторонняя синхронизация),

значит, в других местах односторонняя?

chukcha ★★★★★
() автор топика

при копировании или синхронизации ДАТА и ВРЕМЯ ДОЛЖНЫ меняться по умолчанию!!! (кроме особых случаев, определяемых нами, пользователями, типа твоего)

Иначе наступит временной хаос

Испрасил.

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

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

Короче, авторы UNISON всё правильно сделали. Это у тебя странные ожидания.

Ну может не всё… Но конкретно это они сделали единственно правильным и ожидаемым путём. По умолчанию файлы создаются в текущей датой, как и должны. Но есть возможность это изменить, если вдруг требуется. Точно так же работает и cp и rsync и всё остальное.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Точно так же работает и cp и rsync и всё остальное.

Ничего подобного!
Хотя насчет cp не скажу, еще не пробовал, но Rsync при копировании по умолчанию СОХРАНЯЕТ ИСХОДНЫЕ ДАТУ/ВРЕМЯ, еще вчера перепроверил.

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 2)
Ответ на: комментарий от chukcha

Нет, это ты через одно место думаешь. Время создания файла для того и нужно, чтобы знать, когда файл создан. Этот конкретный, не какой-то там другой, оригинальный. Единственно правильное поведение по умолчанию — без всяких сюрпризов создавать файлы с текущим временем создания. Да, у программ, занимающихся копированием, следуюет иметь ключик или настройку, позволяющую сохранять старую дату в новом файле для тех, кому это надо. И именно так оно и есть и в cp и в rsync и в Unison этом, да и вообще практически везде.

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

Правильно, время создания файла нужно. Но копирование - это не создание файла, он уже создан в 1999 году, а лишь ПЕРЕКЛАДЫВАНИЕ его в другое место.
Но разработчики этой элементарной вещи не понимают :-(

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

Вот к примеру, отправили вы файлы приятелю, ему понадобилось посмотреть, когда они были созданы - а фигушки! Все они одинаковые как под копирку.

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

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от chukcha

Но копирование - это не создание файла, он уже создан в 1999 году, а лишь ПЕРЕКЛАДЫВАНИЕ его в другое место.
Но разработчики этой элементарной вещи не понимают :-(

Нет, это ты копирования от перемещения не отличаешь. Разработчики как раз понимают хорошо. Кроме разработчиков mc…

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

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

Вот к примеру, отправили вы файлы приятелю, ему понадобилось посмотреть, когда они были созданы - а фигушки!

А вот и нефиг ему смотреть что-то подобное. Передавая файл, я передаю его содержимое, а не приватную инфу вроде времени создания или тем более владельца. Всякими торрентами и http’ями не передаются ни пермиссии, ни владелец, ни время создания — ибо нефиг. Если они вдруг важны, то файлы пакуются в tar или другой формат архива.

Кстати, на этом многие непреднамеренно деанонятся, забывая, что tar сохраняет имя юзера и группы. Надо всегда задавать --owner=anon --group=anon или типа того (я своё имя на сайте, где делюсь файлом и собственно названия сайта ставлю иногда).

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

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Нет, это ты копирования от перемещения не отличаешь.

Так ты хочешь сказать, что первичное создание файла, например, редактором, и перекладывание уже созданного файла в другое место должно давать одну и ту же дату/время?

Наоборот, они становятся разными! Становится возможно узнать, когда создан этот конкретный файл, а не оригинал, с которого он скопирован.

Где ж разными? Скопируй группу файлов, и увидишь, что они все становятся одинаковыми.

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

Это надо не для любителей оригинальности, а для обычных юзеров, поэтому дата/время должны быть видны «на поверхности», без применения «специальных ключей»

А вот и нефиг ему смотреть что-то подобное.

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

При передаче по сети можно было бы и согласиться, но тут надо еще хорошо подумать...

Интересно, можно ли на нашем форуме провести голосование по данному вопросу?

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 2)
Ответ на: комментарий от chukcha

Так ты хочешь сказать, что первичное создание файла, например, редактором, и перекладывание уже созданного файла в другое место должно давать одну и ту же дату/время?

Да. mv так и делает, потому что это с точки зрения юзера не создание копии, а перемещение существующего файла.

Это надо не для любителей оригинальности, а для обычных юзеров, поэтому дата/время должны быть видны «на поверхности», без применения «специальных ключей»

Они и видны. Для каждого конкретного файла. Если зачем хочется «не настоящее» время, а «оригинальное», есть возможность его скопировать с помощью ключа, либо же задать вообще любое произвольное.

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

Нет, это как раз не их дело, а моё, если это мои файлы. И «указывать» я, естественно, буду.

Тем более, если копирование происходит в пределах моего компьютера.

Про твой компьютер в том случае ничего не было. Ты зачем-то привёл другой случай с передачей файла какому-то другому юзеру.

Интересно, можно ли на нашем форуме провести голосование под данному вопросу?

Это не вопрос, в котором нужна демократия, это базовые очевидные всем кроме чукчи вещи. Хотя ты можешь создать свою ОС (или дистрибутив) с блекджеком и собственными уникальными понятиями о том, что такое время создания файла, а что модификации. Можно назвать это «вирусной датой» по аналогии с вирусными лицензиями.


А вообще по теме, раз уж проблема сама по себе решена тупо заданием нужной настройки, а проблема неадекватного восприятия некоторых сущностей в метаданных осталась и по-видимому уже не пропадёт, могу посоветовать никогда не полагаться на метаданные ФС вообще. Даже в имени файла хранить жизненно важную информацию я бы поостерёгся, хотя это куда ни шло, а уж в дате создания/модификации или правах доступа — так себе идея. Если дата создания документа действительно так важна, то она сохраняется в самом документе. Можно даже после каждого абзаца писать, когда он написан, если это важно, и т.д. — шире же возможности, чем одна дата. Так поступали испокон веков. Даже в том же HTTP время последнего изменения используется для управления кэшированием, но никак не для вывода даты написания статьи на странице — она хранится отдельно, в файле (ну или записи в БД), вместе с самой статьёй. Подумай об этом.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Да. mv так и делает, потому что это с точки зрения юзера не создание копии, а перемещение существующего файла.

Ты специально не замечаешь, что я ни слова не сказал о перемещении, а о копировании? Впрочем, в данном вопросе разницы вроде и нет

Они и видны. Для каждого конкретного файла. Если зачем хочется «не настоящее» время, а «оригинальное», есть возможность его скопировать с помощью ключа, либо же задать вообще любое произвольное.

Видны, только совсем не те, что нужно. По умолчанию нужно показывать дату/время создаваемых файлов, а не время их копирования, которое и нафиг не нужно - подумаешь «событие века!»

Про твой компьютер в том случае ничего не было.

Ты зачем-то привёл другой случай с передачей файла какому-то другому юзеру.

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

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

Ты специально не замечаешь, что я ни слова не сказал о перемещении, а о копировании?

Я насчёт копирования уже комментировал. Третий раз повторять не буду. Это создание нового файла. Копии старого. У старого своё время создания, у нового — своё. Потому что это два файла, а не один!

Впрочем, в данном вопросе разницы вроде и нет

Разница есть.

Видны, только совсем не те, что нужно.

Тебе лично? Ну для тебя есть ключи и настройки.

По умолчанию нужно показывать дату/время создаваемых файлов, а не время их копирования, которое и нафиг не нужно - подумаешь «событие века!»

Алиасы в помощь, если хочется всегда так, а -a печатать лень.

Ты зачем-то привёл другой случай с передачей файла какому-то другому юзеру.

Ты его первым привёл. Зачем — я и сам не понял. Но тоже прокомментировал, раз уж ты привёл. Потому что изначальный вопрос давно изжил себя.

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

Алиасы в помощь, если хочется всегда так, а -a печатать лень.

Да нафига вместо правильного просмотра тут еще какие-то альясы приплетать!
Очень сомнительное удобство. Правильный просмотр должен быть по умолчанию.

Болезнь нужно лечить в ее причинах, а не в следствиях.

Я так думаю, что тебе лично не важны время/дата создания файлов, ну так ты работаешь, доволен и поэтому защищаешь сложившую ситуацию как есть.
А вот если бы были важны, то ты бы запел по-другому, не про альясы.

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

Очень сомнительное удобство. Правильный просмотр должен быть по умолчанию.

Он и есть правильный. Просто тебе хочется странного. И это странное очень легко достижимо. Хотел сказать, что ты пытаешься чинить то, что не сломано… Но ты ведь даже чинить не пытаешься (что делается элементарно — сохранением настроек и алиасом для rsync), а только ноешь и пытаешься доказать, будто твоё особое видение — не то что не нелепое, да ещё и единственно правильное. Зачем это всё, если проблема по сути уже решена — непонятно.

Я так думаю, что тебе лично не важны время/дата создания файлов

Иногда важны. Именно для конкретного файла, а не для его предка. А когда мне действительно важно время создания «контента в файле», а не самого файла, оно сохранено внутри файла, а не снаружи.

А вот если бы были важны, то ты бы запел по-другому, не про альясы.

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

А алиасов у меня полно, естественно. Не использовать их — глупо.

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

1. Ни в одном редакторе не пользовался этими кнопками. Согласен с автором. Если хочется мышевозить(зачем это в текстовом редакторе?), есть правая кнопка мыши.

2. В консоли переопределять Ctrl+C и прочие - это зло, за которое нужно бить ногами по лицу(привет nano). В любом текстовом редакторе хоткеи - это основной элемент управления, так как с текстом работа идёт с клавиатуры и дёргать мышь неудобно(небольшим исключением могут быть thinkpad'ы, но тоже не панацея).

3. Зачем в текстовом редакторе мышь - 2?

4. Тулбар и должен быть почти пустой. Там только минимум наиболее используемых кнопок - копипаста мышей, ИМХО, к ним не относится. Другое дело, что в нормальных графических текстовых редакторах, его можно настроить под себя(kate, kwrite).

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

В консоли переопределять Ctrl+C и прочие - это зло, за которое нужно бить ногами по лицу(привет nano)

Вот согласен. Хуже только когда Ctrl+Z переназначают на какую-то непонятную хрень вместо отправки в фон.

CrX ★★★★★
()