Через ~6,5 лет обновился tkdiff до версии 4.3

Накатим!

www.linux.org.ru/tag/экстраполяция

ждём ебилдов

Прочитал как:

Через ~6,5 лет обновится tkdiff до версии 4.3

И чем это лучше kdiff3 или даже meld?

Зависимостями же. Тот же meld требует

    Python 3.3
    GTK+ 3.14
    GLib 2.36
    PyGObject 3.14
    GtkSourceView 3.14
    pycairo

Сомнительный плюс. Как будто у тебя в системе нет gtk или qt.

Да и в этой номинации он проиграет vim или diff.

Так у него нет.

Зачем так жить? Я понимаю, что gtk зло, но зло неизбежное.

Синдром утенка потому что и «мне не надо - никому не надо». Раньше было лучше, зачем мне HTTP, если GOPHER у меня работал.

Угадал автора по заголовку)

У меня есть, но речь не просто о тулкитах, а о дополнительных зависимостях наподобие pycairo и kdelibs, которые в свою очередь тоже тянут зависимости, и всё получается жирным и тормозным, а тут просто Tcl/Tk.

Если бы они были написаны только на GTK/Qt, если бы...

оказывается, тикль еще где-то использовался кроме скриптов для eggdrop...

«Жирное и тормозное» - это проф. софт. Эти ваши детские игрушечки - детские игрушечки. Серьезно, достало это читать за 20 лет.

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

«Жирное и тормозное» - это проф. софт

Не «проф.», а «энтерп.»

Проф софт - это то, на чем люди зарабатывают и на чем работают (в т.ч. «корп» и «энтерп.»). Фотошоп например - жирный, потому что когда ты панараму собираешь то тебе ее надо в память куда-то деть. Автокад жирный, все кады вообще жирные. Какая-нибудь бигдатая бизнес-аналитика жирная, потому что там данных много (и с омерзительным интерфейсом, естественно). А tkdiff - игрушечки.

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

tkdiff свою работу по визуальному сравнению двух разных текстовых файлов вполне выполняет. Разумеется, это не IDE, не САПР, и даже не среда 3D-моделирования. Инструменты бывают самые разные.

Я все понимаю, но эта проблема перестала быть актуальной году так в 2010. У меня даже на raspberry pi нет нужды контролировать что там «лишнего». Мне гораздо дороже откручивать gtk, чем думать о нем. Я вижу как работает desktop team, им надо много кому угодить.

Что значит «откручивать gtk»? Не надо ничего откручивать. В том и суть, что если при имеющихся альтернативах уже есть реализация, которая вполне работает как нужно и при этом жрёт меньше ресурсов за счёт меньшего кол-ва зависимостей, то это вполне может рассматриваться как преимущество. А тут конкретно шла речь о kdiff3 vs meld vs tkdiff.