noJS desktop

[amarao]

Разумеется, у меня категорически нет времени на это, но мне кажется, что весьма достойной стратегической целью будет избавляться от JS как участника tight loop interactions на десктопе.

Во-первых это, конечно, очередной шпынок в сторону vscodium. Но во-вторых (и это немного неожиданно для меня), это cinnamon. Который, в целом, не плох, хотя иногда медленный. Раньше я не обращал внимание на это, пока не залез в какой-то багрепорт по cinnamon и не обнаружил /usr/share/cinnamon/js/ui/runDialog.js

Эта штука (вместе с остальными js/ui) явно находится в tight loop, и это js. Зачем? А, может, не надо?

Таким образом, задуматься о смене DE теперь подталкивает не только wayland, но и, в целом, не желание видеть избыток интерпретируемых языков..

О, кстати, это уже более достойная история. Как насчёт плавного ухода от tight loop с участием интерпретируемых языков для инструментов? Внезапно, под угрозой оказывается terminator. Который слишком хорош, чтобы просто выкинуть. Но, может быть, alacritty окажется лучше, хотя совмещение alacritty с чем-то типа tmux'а начинает звучать как отдельное приключение...

Ещё одной альтернативой будет WM с человечным тайлингом. Чтобы не "всё или ничего", а чтобы для группы окон был разумный тайлинг, а кто не в группе, тот обычные окна...

Comments

[yurikhan]

А что считать tight loop’ом? Есть предположение, что любой loop, в котором задействован человек, по определению не слишком tight.

Firefox написан на Javascript’е, с низкоуровневыми компонентами на плюсах. Хромиум аналогично.

Emacs написан на Emacs Lisp’е, с низкоуровневыми компонентами на сях.

Эмулятор терминала Kitty написан на питоне, с низкоуровневыми компонентами на сях.

GNOME Shell написан на Javascript’е, наверняка с внутренностями на чём-то компилируемом.

Git написан на сях, с отдельными модулями на шелле и перле…

[amarao]

tight loop, это цикл взаимодействия ПО/человек, котором время реакции ПО определяет уровень комфорта человека.

На современном железе seamless/instant experience - это ответ ПО на действия человека за время меньшее 4 мс. Верхняя граница "отлично" - 16 мс. Всё что ниже - компромисс.

На самом деле технология второстепенна, но если какие-то внутренние технические причины приводят к tail latency на ожидаемо быстрой операции в 200мс вместо 10, то эта технология просится на выход. Моё наблюдение, что JS обычно добавляет много latency, во-первых в трансляции события в вовнутрь JS, а во-вторых из-за шанса наткнуться на GC (что отличный кандидат на основную причину tail latency).

tail latency - это значение в старших персентилях. Например, 99.9% действий выполняются за < 10мс, а 0.01% натыкается на "gc" или какую-то congestion в event loop'е и отрабатывает за 200мс, и это - tail latency. Даже если average latency получается 20мс, с точки зрения качества взаимодействия (tight loop) цифра 200мс (или даже 2с в 0.01% случаев) более критическая метрика.

[permeakra]

>Чтобы не "всё или ничего", а чтобы для группы окон был разумный тайлинг, а кто не в группе, тот обычные окна...

Поковыряйся в найтроках kwin.

[permeakra]

tail latency может и в си вылезти, причем в непредсказуемом месте, если произойдет каскадное удаление чего-нибудь. Там проблема не столько в языке или GC как таковых, а в том, что на tail latency в принципе никто не заморачивается. Нет на десктопе такой культуры программирования, кроме как в играх. Так-то даже с интерпретируемым GC можно писать практически в реалтайме, см эрланг.

[amarao]

Мне kde как-то очень сильно не нравится. Я несколько раз пытался с ним жить, но он странный.

[amarao]

Конечно, может. Но в JS это обычно куда более заметно, плюс огромный оверхед. (конечно, тут прибегают js-фаны, у которых js-код обгоняет всё, включая v8 по производительности).

[permeakra]

Гм. А какая разница, в какой DE запускать терминал и браузер? Я все-таки еще раз советую попробовать. Если вопрос именно в недо-тайлинговом WM, то KWin вполне подходит - там можно настраивать позицию и положение окон и по правилам, и по шоткатам.

[permeakra]

js тупо не предназначен для написания программ больше 20 строчек. Если эти ограничиваться и не выпендриваться, он вполне адекватен.

[amarao]

Ну, хотя бы, чтобы иметь интеграцию с остальными кусками. Шрифты там, хорошо подобранные и нерасползающиеся, настройки dpi, общую поддержку темы (dark/light) и т.д.

[amarao]

cat /usr/share/cinnamon/js/ui/runDialog.js|wc -l 478

Примерно в 20 раз больше, чем 20 строчек.

[permeakra]

Ну ты ж не первый, для кого это проблема.

qt6-gtk-platformtheme

gtk3-engines-breeze

[amarao]

Это очень ценное замечание. Спасибо. Я не думал про этот вопрос с такого угла.