AL> Я уже давно рассматриваю редактор не столько как редактор. Emacs ибо. Хотя напрямую как интерфейс к ОС его рассматривать не совсем правильно, но вот как вычислительную среду с интерфейсом доступа к ОС уже корректнее.

Смотря какая ОС. В GNU Scheme в качестве интерфейса по умолчанию есть Edwin - тот же Emacs. Сассман - который (со)автор Scheme - использует его как интерфейс в своих курсах/книгах, таких как "Структура и интерпретация компьютерных программ" и в своей CAS Scmutils (Scheme Mechanics). У него, кстати, есть книги и по математике и по физике с той же CAS. Она сама вот тут лежит: https://groups.csail.mit.edu/mac/users/gjs/6946/installation.html

AL> Как раз acme офигенный пользовательский интерфейс. По крайней мере в родной для него ОС. Но и в GNU/Linux весьма себе вкусная вещь. А вот vi/vim/neovim мной только как редакторы воспринимаются. Хорошие, но редакторы. Не прижилось у меня более широкое их использование.

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

AL> Ну мне сложнее: я не телепат и люблю ковыряться во всякой фигне. Но зачем мне из вима делать интерфейс к ОС, если у меня уже есть более другие интерфейсы к ОС я не понимаю. Тем более на серверах, где просто нет смысла что-то сильно настраивать.

Если ОС это и есть реализация какого-то языка, то и выбора особого нет. Например HP 48, в которых RPL - это и есть вся ОС. На z/OS - это часто ISPF, поскольку там обычно есть только блочные терминалы. Или какой-нибудь Smalltalk, MIT Scheme, Wolfram Mathematica или другая интерактивная среда, которые от ОС мало зависят. В Lisp или OCaml использовать голый REPL - тоже не самый удобный вариант. Поэтому и Emacs. Да и в Plan 9 я Gnome что-то не заметил.

Но для Linux, Windows, какой-нибудь Sony PlayStation, где среда разработки для большинства пользователей совершенно не нужна, есть специализированные GUI. Так сложилось исторически.

А зачем, например, Пётр делает Red? Ну тоже есть у него на то свои причины :)

AL> Но зачем мне из вима делать интерфейс к ОС

Может я неправильно понял вопрос? Если имеется в виду, что Emacs - это интерфейс, а Vim - нет, то это вовсе не так. Vim и Emacs отличаются очень поверхностно, т.е. это дело привычки. Я пользуюсь обоими и разница для меня только в языке реализации: elisp в Emacs и vimscript в vim. Модальный режим не в счёт. Neovim ещё добавляет нормальную поддержку Lua.

Посмотрим и с обратной стороны: если пользователь всё своё время и так проводит в редакторе, то зачем ему вообще отдельный интерфейс к ОС? И какая ему разница на каком языке он написан? Для него интерфейс к ОС - это и есть его редактор.

Ну вот многие ли в DOS пользовались командной строкой? Большинство перешли на Norton Commander и были довольны. Тем более, кто сейчас пользуется терминалом в Windows? Потому что их устраивает данный разработчиками GUI и о большем они не мечтают. Это инерция мышления и привычка. Я ещё раньше называл это данью моде, но это уже вызвало споры. Тогда использование редактора в качестве интерфейса тоже определяется привычками и целесообразностью перемен. Зачем что-то менять если всё и так устраивает?

GUI тоже ведь зародился не на пустом месте, а сначала продвигался, как интерфейс к системам типа Xerox Alto, а потом Smalltalk или Oberon. Потом к нему просто привыкли и первоначальные мотивы уже утратили значение. Эти системы, в свою очередь, тоже продвигались просто, как более интуитивный интерфейс для неспециалистов. Тогда даже появился модный термин "рабочая станция", а в качестве ОС там обычно фигурировал какой-то язык программирования. Сейчас эталоном GUI можно считать смартфон, где это его визитная карточка. И действительно, пользоваться текстовым интерфейсом там было бы совсем затруднительно. На серверах же традиционно прижился интерфейс командной строки, но это просто традиция, как показывает тот же Plan 9. Кстати, Inferno - это попытка сделать Plan 9 переносимым на разные платформы и он мало чем, по сути, отличается от того же Smalltalk.

hugeping> У кого-то может возникнуть вопрос. А почему я не использую vscode? Потому что моя профессия приносит мне удовольствие и я разборчив в своих предпочтениях. Что касается vscode:

hugeping> - это приложение на основе браузера;
hugeping> - vscode пришёл из недр корпорации.

Я могу тебя понять :)

Сегодня обновил расширение и обнаружил, что оно попало в кэш хромиума, в кэш расширений да ещё и сам установленный экземпляр. И у меня автоматические обновления отключены. Ещё и вся память воркспейсов, включая те, которых уже давно нет, хранится там вечно. И нет никакого интерфейса для чистки мусора, кроме резервных копий самих редактируемых файлов. Баг репорты ою этом лежат по всему интернету минимум последние шесть лет и никто даже не чешется :( На emacs и vim это совсем не похоже.

Кстати, VS Code - это единственный из уже упоминавшихся редакторов, который сохраняет изменения непосредственно в сам редактируемый файл (дата создания файла не меняется). Остальные же меняют только его копию. Зато ему не нужны и дополнительные права на создание, удаление и переименование файлов на сервере :)

hugeping> Правда, всё время что-то дописываю, а это немного отвлекает собственно от самой работы. :)

Я ещё много лет назад хотел себе интерактивную визуальную систему для работы. Нашёл тогда только Smalltalk и Oberon. Потом, правда, ещё познакомился с Plan 9 и Inferno. Так там _всегда_ надо что-то дописывать, в этом и суть интерактивного программирования :) Сейчас, кстати, читаю "Squeak by example 6.0": интерактивная среда там никем не превзойдена до сих пор! А ты видел Skein в Inform 7? Вообще, у этих систем много общего: интерактивная динамическая среда, текст программы похож на обычный английский язык, мощные средства отладки, исследовательское программирование.

hugeping> Да, уже вижу что написан он грязновато, но это вечная проблема.

Фрэнку Герберту, автору "Дюны", понадобилось ещё целых семь лет после написания первого романа серии, пока он смог уволиться и заняться, наконец, только литературной деятельностью. Кстати, и писал он первую книгу шесть лет. А настоящая исследовательская работа имеет много общего с написанием романа :)

hugeping> Skein не видел. Про сам Inform 7 знаю и смотрел на "код программ".. В итоге, правда, настроен довольно скептически. Может быть кому-то проще писать на таком как бы человеческом языке, но мне показалось что это принесёт больше проблем. Хотя сам неоднократно думал над DSL который бы компилировал в код INSTEAD игры, но там я думал о специализированном синтаксисе.

А как тогда тебе этот код (фрагмент большой)?

import Game.Metadata
import Game.MyNat.Multiplication


World "Tutorial"
Level 1
Title "The rfl tactic"

Introduction
"
# Read this first

Each level in this game involves proving a mathematical theorem (the \"Goal\").
The goal will be a statement about *numbers*. Some numbers in this game have known values.
Those numbers have names like $37$. Other numbers will be secret. They're called things
like $x$ and $q$. We know $x$ is a number, we just don't know which one.

In this first level we're going to prove the theorem that $37x + q = 37x + q$.
You can see `x q : ℕ` in the *Objects* below, which means that `x` and `q`
are numbers.

We solve goals in Lean using *Tactics*, and the first tactic we're
going to learn is called `rfl`, which proves all theorems of the form $X = X$.

Prove that $37x+q=37x+q$ by casting the `rfl` tactic.
"

/-- If $x$ and $q$ are arbitrary natural numbers, then $37x+q=37x+q.$ -/
Statement (x q : ℕ) : 37 * x + q = 37 * x + q := by
  Hint "In order to use the tactic `rfl` you can enter it in the text box
  under the goal and hit \"Execute\"."
  rfl

TacticDoc rfl
"
## Summary

`rfl` proves goals of the form `X = X`.

In other words, the `rfl` tactic will close any goal of the
form `A = B` if `A` and `B` are *identical*.

`rfl` is short for \"reflexivity (of equality)\".

## Example:

If the goal looks like this:

```
x + 37 = x + 37
```

then `rfl` will close it. But if it looks like `0 + x = x` then `rfl` won't work, because even
though $0+x$ and $x$ are always equal as *numbers*, they are not equal as *terms*.
The only term which is identical to `0 + x` is `0 + x`.

## Details

`rfl` is short for \"reflexivity of equality\".

## Game Implementation

*Note that our `rfl` is weaker than the version used in core Lean and `mathlib`,
for pedagogical purposes; mathematicians do not distinguish between propositional
and definitional equality because they think about definitions in a different way
to type theorists (`zero_add` and `add_zero` are both \"facts\" as far
as mathematicians are concerned, and who cares what the definition of addition is).*
"

NewTactic rfl

Conclusion
"
Congratulations! You completed your first verified proof!

Remember that `rfl` is a *tactic*. If you ever want information about the `rfl` tactic,
you can click on `rfl` in the list of tactics on the right.

Now click on \"Next\" to learn about the `rw` tactic.
"

Это уже DSL для реального языка программирования. Эту игру уже реально используют в некоторых университетах для введения в формальную математику :)

hugeping> Skein не видел. Про сам Inform 7 знаю и смотрел на "код программ".. В итоге, правда, настроен довольно скептически. Может быть кому-то проще писать на таком как бы человеческом языке, но мне показалось что это принесёт больше проблем. Хотя сам неоднократно думал над DSL который бы компилировал в код INSTEAD игры, но там я думал о специализированном синтаксисе.

Кстати, совсем забыл - есть же ещё Dialog:

Dialog is a domain-specific language for creating interactive fiction. It is heavily inspired by Inform 7 (Graham Nelson et al. 2006) and Prolog (Alain Colmerauer et al. 1972), and substantially different from both.

https://linusakesson.net/dialog/

hugeping> Про диалог тоже слышал. А вот твой пример не понял прям совсем. :) Даже специально паузу взял, думал изучу на досуге. Загадочно и непонятно. Как ФП :)

Хм... Ведь я его и привёл специально с целью продемонстрировать, как код на DSL может быть похож на английский язык. Вроде, если его читать, как английский, то должно быть всё довольно понятно, даже не зная сам DSL. Ну, по крайней мере, я так думал, когда его выкладывал :)

Там сам код включает сам текст из игры, как маркдаун и несколько специальных выражений, которые тоже похожи на текст. Это имеет большое сходство с Inform 7, только синтаксис более специальный, как ты и хотел :) Конечно, в самом тексте говорится о некоторых элементарных математических понятиях, но это должно быть несущественно. Какая разница, говорится там об эльфах и гоблинах или о чем-то там ещё? Это ведь уже часть сюжета игры, а не самого программного кода :)

Ты ведь сказал, что уже думал о DSL для INSTEAD, но со своим специальным синтаксисом, а это ведь такой DSL и есть, только для другого языка. Но ты почти угадал - это действительно ФП :)

Сама игра в браузере тут, можешь попробовать поиграть и увидеть результат такого подхода на деле:
https://adam.math.hhu.de/#/g/hhu-adam/NNG4
Там и хостинг для других подобных игр, типа itch.io

Да, ещё код сервера для реализации этого DSL - 3k строк. На функциональном языке :) Клиент, отвечающий за UI - на JS (точнее TypeScript).

https://github.com/leanprover-community/lean4game

Там ещё одна девочка недавно спрашивала: а нельзя ли поменять в игре менюшный интерфейс на парсерный :)

hugeping> Так же, если вам интересны такие вещи как: PICO-8 и TIC-80/uxn/Decker/instead/reinstead - то rein имеет что-то общее с каждым из этих проектов, но всё-таки у него свой путь и своя философия.

Как ни странно, но и Smalltalk тоже имеет много общего с этими целями. Именно этим он мне в своё время и понравился. Но, в конечном итоге, обязательно появится кто-нибудь и захочет написать на нём реляционную СУБД и систему управления ЖД транспортом :)

Будем ждать новых релизов и удивительных результатов, особенно от будущих фанатов. Удачи.

P.S. Сам же я уже отошёл от всего практического и занимаюсь исключительно эстетикой математических идей. Но всё равно иногда любопытство толкает на эксперименты с разными вещами :)

Интересный опыт, но мнне кажется, что тут опять просматриваются прямые аналогии со Smalltalk ;)

Если, например, ты зайдешь на squeak, то там перманентно эта самая первая фаза. Люди там всё делают лично для себя и всё меняется ежедневно. Сообщество там тоже явно стихийное. А для тех, кому нужны какие-то стандарты - есть pharo. Насколько я понимаю, первый - это любительский проект, а второй вроде спонсирует какая-то фирма. Вообще, я замечаю, что большинство любительских проектов - целиком автор на себе везёт, а если надоело, то они обычно дают дуба (проекты, а не авторы, если что :)). Выживают же обычно только те, которые кто-то оплачивает. Ну, как и люди в общем.

hugeping> Но сказать, что мне нравится выбранный курс развития -- категорически не могу. Linux стал слишком "взрослым". Sad but true...

Linux уже очень давно не любительская система. А в любой профессиональной системе значение имеют только интересы разработчика, который платит за разработку из своего кармана. Здесь за это платит Red Hat, в интересах которого и существует systemd. Давайте признаем, что достигнуть профессионального уровня поддержки за счет своего свободного времени и бесплатно - невозможно. На вашей памяти сколько раз любители из интернета исправляли критический для вас баг или добавляли новую функцию, когда вам это было необходимо? Тут же вспоминается классическое "вам никто ничего не должен" и "лично мне это совсем не нужно, но у вас же всегда есть возможность сделать все самим". Профессиональное свободное ПО с открытым кодом существует только в мечтах. На деле оно всегда принадлежит тому, кто платит зарплату программистам. Но большому бизнесу, конечно, удобно, когда всякие гики относятся к нему дружелюбно и готовы с ним сотрудничать и способствуют продажам. За это им и позволяют поиграть с кодом, который им самим написать возможно только за сотни человеко-лет. Нам столько просто не прожить.

Это все тривиальные вещи, но многие просто не хотят это замечать по религиозным соображениям.
P.S. Edited: 2020-12-02 13:04:53

xclip, конечно, полезная вещь, но у него есть недостаток: невозможно скопировать несколько типов данных одновременно, например html и txt для обработки разными приложениями.

Скриншот? Клавиша PrtSc - она же gnome-screenshot :) Легко выбрать скриншот окна, всего экрана или вырезать прямоугольник. ImageMagick у меня даже не установлен.

А xclip использую иногда для других видов данных. Возможность сохранять любые типы данных в клипборде - это одна из немногих вещей, которая мне нравилась в винде. У нас было приложение для администрирования серверов, так там был только GUI для Windows. Возможность сохранить правила была только в клипборде и, разумеется, в бинарном формате, который понимало только это приложение. Это было еще в Windows 98, а в Windows XP авторитарный микрософт убрал эту утилиту для манипуляции клипбордом куда-то на задворки. Я когда перешел на Linux, то одним из первых нашел xclip для той же цели. Очень это было круто - сохранять бинарные данные даже из GUI и иметь доступ к ним в разных форматах.

В линуксе чаще всего конфигурацию хранят или в простом текстовом формате или, не дай Бог, в XML. А для них нужен парсер, который из bash не всегда найдешь. Лучше хотя бы JSON. А для некоторых приложений такие языки используют, с контекстно зависимой грамматикой, что парсер писать застрелишься.

В Plan 9, конечно, неплохо придумано, что все в одном стандартном формате и plumber, но это не всегда эффективно. Большие потери на конвертацию туда-сюда. Я помню, в начале мне понадобились исходники Plan 9, а они были доступны только монтированием через 9P по интернету. Скачивалось так же медленно, как FIDO по dial-up 2400 бит/с. Потом уже там появились сторонние проекты с репозитариями на mercurial. Ну а я предпочитаю Git.

Вообще-то, Гном у меня выполняет функции десктопа. А скриншоты я делаю редко.

Зачем вообще нужен десктоп, да еще такой огромный? Я пробовал другие варианты, но они меня не удовлетворили. Либо мне сложнее было выполнять мои повседневные задачи, либо мне неохота было менять привычки. Я, например, привык к его терминалу, к тому, как выполняется настройка. Когда-то на старом компьютере я использовал только xorg и терминал, но ставить все равно приходилось намного больше. Вообще, весь набор его обычных компонентов от dconf/gio до gtk нужен для работы необходимых мне приложений, так что экономия за счет gnome-shell мне ничего не дает. А вот ImageMagick мне совсем не нужен.

Я вообще давно не трогаю ОС. Единственное исключение было, когда Fedora отказалась от поддержки 32-битной архитектуры Интел. А я не собираюсь терять столько памяти на лишние нули в данных. Из всех вариантов наибольшую свободу выбора предоставляла NixOS и требовала меньше всего возни. Самое главное, чтобы работали необходимые приложения и функции, а на остальное нет ни времени, ни желания. Нет желания возиться с багами и глюками, а еще меньше с тараканами в голове дизайнеров ПО. У меня и так слишком большая часть жизни ушла на возню с компьютерами и теперь я хочу все свое время заниматься тем, что является важным для меня. Главное достоинство ОС - когда ее не замечаешь.

AL> Тогда этот совет подходит только тебе.

Какой совет? Это был всего лишь ответ на вопрос Петра, чем я пользуюсь.

AL> ППКС, но это точно не про гном. Я его очень долго настраивал, когда пытался использовать. В итоге удалось получить удобное и незаметное окружение, но ценой больших усилий. Пожалуй, так бы на нём и остался, да под иксами он артефакты рисует у меня, а под wayland, по крайней мере на тот момент, не решались некоторые проблемы.

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

В гноме раздражает умышленная несовместимость с предыдущими версиями. Но я редко обновляю ОС, чаще использую бэкпорт если не требует особых усилий. Нет желания тратить массу времени впустую, решая искусственные проблемы. Но все зависит от привычки. Если бы я начинал с Plan 9, то может на нем и остался бы. Хотя все-таки вряд ли, поскольку большинство приложений там работать не будут, а это то, что меня интересует в первую очередь.

AL> Меньше всего возни в итоге потребовали i3wm и cwm %) Последний вообще практически не потребовал настройки, чем очень сильно порадовал.

Так это от привычки зависит. Если устраивают настройки по умолчанию, то вообще ничего делать не надо :)
P.S. Edited: 2021-01-28 12:23:45

hugeping> Так что минимализм, кроме эстетического удовольствия, может приносить и вполне конкретные практические плоды. :)

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

hugeping> P.S. Из gnome софта в основном использовал evince и eog. Но им легко находится замена.

И опять тут две стороны. Совместимость с PDF у всех разная. Мне иногда попадались такие книги, которые правильно отображает только evince. Но это кому как повезет. Например, для чтения FB2, я до последнего времени прекрасно обходился FBReader-ом, пока не попалась книга логических головоломок Смаллиана с таблицами. К моему разочарованию их отображает только calibre. Пришлось приручать этого монстра, а ему нужен qt5webengine, т.е. chromium. И компиляция этого монстра - это отдельная история. Но, к счастью, такие ужасы происходят один раз в несколько лет.

AL> Видимо, как-то не уловил сути. В последнее время с узла Петра сообщения в странном порядке приходят. Зачастую ответ я вижу раньше вопроса и потому не всегда удаётся адекватно проследить нить беседы. Надеюсь, Пётр починит это дело.

Я иногда редактирую свои сообщения, может из-за этого?

AL> Перемигивания всех декораций окон и панелей раз в пару минут я больше нигде не наблюдал. Только в гноме под иксами. Поэтому и получается, что gnome == wayland. Иначе никак. По крайней мере на видеоадаптере от intel.

У меня Intel, только старый. Единственное, что добавил

Option "PageFlip" "false"

Иначе были проблемы в wine если быстро мышью двигать. После этого все гладко заработало.

vvs>> В гноме раздражает умышленная несовместимость с предыдущими версиями.

AL> Я гномом пользовался чуть больше полугода и не успел оценить этих прелестей.

Это влияет на установленные расширения. В итоге авторам надоедает их постоянно переделывать и они их забрасывают вообще. Этим же Firefox страдает. Но там вообще просто удаляют поддержку старых API. Еще иногда параметры настройки меняют имя и место.

AL> В бэкпортах зачастую нет актуальных версий и приходится любиться со сборкой пакетов. Конечно, это нужно далеко не везде и не всем, но в некоторых случаях наличие актуальной версии ПО может быть критичным.

Ну, я имел в виду, что бэкпорт делаю самостоятельно. В NixOS это проще, чем в других дистрибутивах, поскольку конфликтов между разными версиями пакетов в принципе быть не может. А сборкой пакетов и так обычно приходится заниматься самостоятельно. Менеджер пакетов работает с исходниками, а в кэше зачастую отсутствуют бинарные версии экзотических пакетов для экзотических платформ. В 2021 году 32-битный интел всеми считается экзотикой.

AL> Не обязательно от привычки. CWM был совсем непривычен в первые пару часов работы, например. Как и i3, когда я его впервые поставил. Тут скорее от продуманности настроек по-умолчанию зависит.

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

Ну, когда-то я хотел использовать GNU Hurd, но в процессе ожидания, пока его доработают напильником, пришлось перебиваться на линуксе. Потом я мечтал о том, чтобы у меня вместо ядра был гипервизор, а каждое приложение - униядро. А потом увидел нынешнее подобие этой мечты - Qubes OS и офигел. Красивая теория столкнулась с реальностью. Ядро линукса теперь мне кажется довольно практичным. Все познается в сравнении.

AL> Если дистрибутив вещь консистентная, то как будет работать GTK5 на системах с xorg? Или кто портирует fvwm под wayland? Скорее всего, весь этот годный и нужный софт просто полетит на помойку и останемся мы с подвёрнутыми штанами попивать смузи под гномом.

Вот тогда может до вас и дойдёт, на что жалуются те, кого принудительно с 32-битных архитектур согнали, ради модных свистелок :/

AL> Меня никто не сгонял. Пользуюсь как пользовался. А вас кто сгонял и по какой причине?

Причины перечислены в idec.talks, при обсуждении проблем со старыми компами. "Вам шашечки или ехать"? Меня не интересует пустая трата времени на посторонние проблемы, мне надо работать и получать нужный _мне_ результат. Это не значит, что весь мир должен поддерживать 32-битные архитектуры для всех. Это значит, что я могу не считать эти тенденции и образ мыслей полезными для меня.

AL> Ну то есть причина надумана, так как софт продолжает прекрасно работать на старом железе?

Наоборот. Я перечислил причины, по которым софт больше не соответствует моим требованиям. Но, если кого-то другого там всё устраивает, то и флаг им в руки.

ii.51t.ru> fedora самый непонятный для меня дистрибутив. я в своей жизни, попробовал, наверное, дистрибутивов 100, из них парочку создал сам, но никогда не понимал Fedora, и никогда ей не пользовался

Разумеется, у каждого свои собственные критерии полезности. На мой взгляд, когда-то федора имела самую лучшую поддержку у независимых разработчиков. Очень неплохо было иметь серверную версию на основе тех же стандартов. Шансы того, что у произвольного проекта есть готовые RPM под федору или CentOS были выше, чем для любого другого дистрибутива. Даже если я компилировал их сам, это существенно снижало издержки, поскольку обеспечивало хоть какой-то стандартный и доступный метод сборки. И найти документированное решение какой-то проблемы тоже было проще. Особенно важно, что вкладывая в её изучение своё время, не придётся потом каждый раз начинать всё с нуля. Но сейчас тут пальма первенства уже явно у убунту. Поскольку для меня ОС - это только вспомогательный инструмент и я не собираюсь тратить на её обслуживание времени больше, чем абсолютно необходимо, то наличие там хороших стандартов для меня существенно и их изучение должно стоить потраченного времени.

P.S. Кстати убунту прекратила поддержку i686 ещё раньше федоры. Тут для репрезентативности важнее всего популярность. Толку, что какая-то экзотическая ОС что-то там поддерживает, если у неё два с половиной пользователя и все издержки на решение любой проблемы приходится платить самому. А раз уж мне всё равно пришлось отказаться от проверенного решения, то я предпочёл использовать этот шанс для изучения более гибкого и совершенного - NixOS, и не жалею.

AL> Довольно забавно слышать, что Debian это экзотическая ОС.

Когда здесь писал об экзотических ОС, о дебиане даже и не думал. Хотя для кого-то другого и дебиан может быть экзотикой.

AL> О NixOS слышал много хорошего, но как-то лень изучать ради изучения, а практического преимущества перед тем же Debian никак для себя не отыщу :)

Для меня главное практическое достоинство - полная независимость каждого приложения от любого другого. Можно установить хоть сотню разных версий и они не будут конфликтовать между собой. Откат на любую версию - это просто смена профиля или даже активного экземпляра оболочки (шелла).

Другое достоинство - это потенциальная независимость от системы сборки производителя дистрибутива. Любой компонент системы может быть автоматически собран на локальной машине с исходников, прямо при установке, как в Gentoo. Но это может быть и недостатком тоже, особенно для архитектуры i686, когда недостаточно 4 ГБ. Поэтому и пользуюсь теперь 64-битной. Ещё один недостаток - это высокая сложность языка самого Nix-а, но у меня было достаточно времени, чтобы привыкнуть.

Хотя готовых пакетов в NixOS и больше, чем в любом другом дистрибутиве, их реальная работоспособность часто только теоретическая. Мне не раз приходилось дорабатывать их самостоятельно. Но мне не так часто приходится с этим сталкиваться.

ii.51t.ru> У меня nixos при установке в virtualbox упало на сборке модуля для virtualbox. Дальше не смотрел

Ну, вот в этом и есть основное отличие, когда интересуются только ради баловства или когда нужно по делу :) Попробовал бы я сказать такое своему (бывшему) начальству на работе, что я дальше не смотрел из-за какой-то одной проблемы. Зарплату мне и платили именно за то, чтобы все проблемы были решены кровь из носу. А ради собственной необходимости я-то стараюсь побольше, чем по принуждению.

А на виртуальной машине я даже и не пробовал. Помнится, там у меня когда-то и DirectX в Windows 98 не работала, хотя XP и Windows 7 работали без особых проблем. Кстати, при самой первой установке NixOS, я попытался её запустить прямо из под федоры и у меня возникли какие-то проблемы с сертификатами, так что вообще ничего даже не скачивалось. Ничего, пришлось самому скачать и загрузиться с установочного CD и всё сразу пошло как по маслу. Проблемы были и потом, мне не привыкать. "И ещё неоднократно вышел зайчик погулять" :)

Вообще в NixOS, конечно, есть ещё и дополнительные плюсы для разработчиков и сисопов, например воспроизводимость сборки. Но лично мне это ничего не даёт.

ii.51t.ru> хороший мануал, беспроблемность из коробки - поэтому мой выбор debian и openbsd.

Ну, если бы мне была необходима подробная документация, то, наверное, предпочёл бы RedHat Enterprise Linux. А проблемы я себе всегда найду, в любом дистрибутиве - это для меня не проблема :)

У меня был шанс перейти с федоры на дебиан, я об этом тогда думал. Но, в итоге победили возможности Nix-а, поскольку переучиваться мне всё равно пришлось, а для меня важнее возможность постоянно экспериментировать на живой системе без последствий. В NixOS что ни устанавливай, систему вывести из строя невозможно, разве что bootloader, но и это легко исправить. А второе - была возможность самостоятельно откомпилировать ОС из исходников, после того, как я видел, как убунту и федора всех кинули, внезапно отказавшись от i686. Правда тут я явно недооценил уже способности самих разработчиков вносить искусственные ограничения в исходный код приложений. Вот спрашивается: зачем делить код на произвольные куски большого размера, чтобы 4 ГБ для его компиляции уже не хватало?

vvs>> Вообще в NixOS, конечно, есть ещё и дополнительные плюсы для разработчиков и сисопов, например воспроизводимость сборки. Но лично мне это ничего не даёт.

AL> Ну это хорошо для эникеев, которым надо раскатывать системы постоянно в большом количестве.

Не только. Если разработчик хочет, чтобы его проект собирался в точности с теми же версиями компилятора и библиотек, что и у него, то Nix это и обеспечивает. Он тут очень похож на docker. Вообще, Nix - это весьма облегчённая "песочница", по сравнению с более полноценной виртуализацией.

AL> Мне сложно представить, чтобы разработчик ориентировался на какое-то редкое окружение, если только не разрабатывает какой-то эксклюзивный софт, который будет работать на этом редком окружении.

Nix не более редкое окружение, чем какой-нибудь Docker, InstallShield или flatpak. Установил его на любой линукс или даже MacOS и пользуйся для сборки предоставленным файлом проекта, запустив шелл, в котором уже предустановлена вся среда разработки. Что может быть проще?

NixOS - это дистрибутив линукса на основе Nix. А Nix - это менеджер пакетов, который от ОС не сильно зависит. Единственный недостаток на сегодняшний день - это поддержка Windows только через WSL.

hugeping> К сожалению, очень многие тулзы написаны только для Windows.

Это очень зависит от того, кто именно преобладает в данном сообществе. А в Линуксе, напротив, гораздо больше серверов и средств разработки. Бывает даже интересно сравнивать.

Моё личное впечатление, что это характерно именно для игровых платформ и их эмуляторов и у виндузятников там больше любителей, использующих какой-нибудь Бейсик или C#. А, например, в научных кругах, как правило, используют MacOS или Линукс, а языки совсем другие.

hugeping> P.S. Сеточка наша что-то подохла окончательно. :)

Так народу мало. Если же наберется слишком много случайных попутчиков, то скоро сами отсюда сбежите. Радоваться надо. И вообще, жизнь не в интернете - она в реале B)

AL> Ну, например, из фидо я сбежал не от слишком большого количества случайных попутчиков. Наоборот, мелкое сообщество, готовое писать только ради того чтобы писать, годами по кругу обсуждает одни и те же темы, при этом не особо стремясь меняться. Это гораздо хуже смерти или слишком активной жизни :)

Почему-то сразу представилась остросюжетная приключенческая ролевая стратегия, время действия - каменный век: племя из трех человек, охота - пещера, пещера - охота, прокачка персонажа, квесты - не умереть (от скуки). Романтика.

Ну не знаю. Меня эти торчащие во все стороны индексы отвлекают еще больше, чем малозаметные гиперссылки. Разве что сделать так, чтобы они были видны только пока удерживаешь шифт.

AL> Малозаметные гиперссылки попадались только в одной игре -- в вахте :)

Если сделать их видимыми только пока держишь шифт, то они все будут вообще незаметными.

AL> Гипертекст в принципе не очень удобно читать, ИМХО. Но тут выбора нет. К парсеру общественность морально не готова :)

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

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

Я могу только попробовать предположить, что речь тут идет об отличиях игр с открытым миром (симулятора) от предопределенного сюжета (истории). Такими (крайними) примерами могут быть Minecraft с одной стороны и визуальная новелла - с другой. Тут, вроде бы, все ясно.

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

Куда тут отнести Zork или, например, Maniac Mansion? Есть игровой мир и есть набор (частично связанных) задач для достижения (одной из) целей игры. Сюжет присутствует, но на ход игры не влияет.

Это то, что тут имеется в виду?

hugeping> Ходить по локациям, брать предметы и т.д.

Это условность. В любой книге-игре такие элементы тоже присутствуют, например: "если вы хотите пойти туда-то, то идите на параграф такой-то" или "если вы решили взять этот предмет, то впишите его в лист персонажа и идите на соответствующий параграф".

hugeping> В CYOA подходе обычно речь идёт не о моделировании локаций/действий, а о развитии сюжета непосредственно. Текст (художественный, а не сгенерированный движком) выводится порциями и в идеале не повторяется, не заставляет игрока ходит по тем же местам снова и снова, а ведёт игрока от начала истории и до конца, ветвясь в зависимости от замысла автора.

hugeping> Конечно и в CYOA можно применить элементы "моделирования", но это довольно дорогое удовольствие по сравнению с "квестом". Потому что требует от автора написания художественного текста для всех развилок.

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

Но идею я понял.

Кстати, чтобы увидеть возникающую путаницу достаточно посмотреть на "Земли сказаний" (http://instead-games.ru/forum/index.php?p=/discussion/412 ). Это типичная книга-игра, но которую трудно отличить от "квеста".
P.S. Edited: 2021-03-23 15:24:46

Все эти споры о парсере подвигнули меня покопаться в исторических парсерных играх. Сравнение классических игр Sierra On Line и образцов типичной интерактивной литературы показывает интересные отличия. В частности очевидно, что игры Sierra имели немалый элемент аркадности.

Здесь исходный код Leisure Suit Larry (без интерпретатора AGI): https://github.com/historicalsource/leisuresuitlarry
А здесь исходный код нескольких парсерных игр для IBM PC (можно найти и тот же код для TRS-80 Color Computer, кому интересно): https://archive.org/details/mark-data-products-games-1984-85-source-code.-7z

Кстати, удивляет сегодня, что такое было возможно на компьютерах с 32 _килобайтами_ памяти и 8-битным процессором (в графике!). И да, разумеется, там же рядом можно полюбоваться исходным кодом Zork и Dungeon на ZIL или FORTRAN.

hugeping> Более того, я терпеть не мог эффект "угадай глагол". Почему сейчас всё поменялось, сам не понимаю. Ну, угадай глагол мне и сейчас не нравится, конечно. :) Просто я теперь знаю какие глаголы работают :)

А в point'n'click есть свой аналог: охота за пикселями.

hugeping> Русский Inform был отложен.

Не знаю, заметил ли это здесь кто-нибудь ещё, но вчера свершилось то, что Грэм Нельсон обещал уже несколько лет подряд: Inform сменил лицензию на OSS. Кроме того там много нового, например возможность компиляции в C. И, конечно, вопрос перевода Inform7 на русский язык остаётся открытым :)

Inform 10.1.0-beta: https://github.com/ganelson/inform

hugeping> Мне (как программисту) кажется, что логику проще описывать с помощью обычного ЯП.

Хе-хе. За эту ересь тебе с удовольствием устроили бы аутодафе любители функционального и логического программирования. Ну разве не проще логику описывать с помощью исчисления высказываний или функций? :))

Inform 7 - вполне обычный язык программирования, только не императивный, а реляционный/логический, наподобие Пролога. Единственная его особенность - это синтаксис, напоминающий естественный язык, например английский. Что особенно нравится гуманитариям.

hugeping> Записал и выложил новый видеоподкаст. INSTEAD и парсерные игры.

Браво! Мне понравилось.

Особенно произвели впечатление усилия по хорошей подборке истории парсерных игр: основательно, последовательно и много ностальгических фотографий :)

Небольшие замечания на будущее. Элизы в моем emacs вообще-то нет, требуется специально её устанавливать, зато везде есть dunnet, который почему-то не упоминается вовсе. Так же не мешало бы упомянуть и SHRDLU, которая являлась настоящей реализацией ИИ для своего времени, тоже в MIT. Музыка в игре временами заглушала речь, да и голос, бодрый и выразительный в начале, несколько увял к концу :(

В целом же всё было изложено весьма познавательно. Спасибо большое!

vvs>> Небольшие замечания на будущее. Элизы в моем emacs вообще-то нет, требуется специально её устанавливать

Нашёл-таки у себя doctor - это, похоже, клон Элизы, но только безымянный.

hugeping> Там много проблем было со звуком. Я даже выложил 2й ролик https://www.youtube.com/watch?v=el2Dh2HwB3s где пытался исправить звук, но возможно сделал ещё хуже. Не так просто без опыта это делать.

Я и не думал, что это легко, просто сообщил для сведения. И я и не заметил, что опыта не хватает - мне наоборот показалось, что весьма профессионально снято :)

OK, перебрался в эту тему :)

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

Одна проблема связана с тем, что на полном экране у меня заметно тормозит курсор и поэтому я предпочитаю запускать инстед в окне. Другая - это неправильное переключение видеорежима, когда изображения вообще нет или мусор. Но это далеко не всегда воспроизводимо даже у меня.

А основной вопрос был там такой: при запуске инстеда в окне шрифт по умолчанию слишком мелкий. В настройках стоят: тема и HQ. Версия инстеда 3.5.1, откомпилированная с исходников, ОС Linux (NixOS), видеорежим 1920x1080. Инстед выбирает коэффициент масштабирования 1.058333, поскольку у моего монитора DPI 101.6. Это ещё одна косметическая проблема: я не могу указать дробный DPI, но если инстед берет его от SDL, то реально использует именно это дробное значение.

Но основная проблема, как я уже сказал в мелком шрифте. Коэффициента 1.058333 просто недостаточно на таком мониторе.

P.S. Edited: 2024-01-27 17:59:54

hugeping> Вот обсуждение на форуме на эту тему:
hugeping> https://instead-games.ru/forum/discussion/766/podderzhka-dpi-v-instead-chto-delat

hugeping> Возможно, проблема существует, но мне нужно её увидеть. А так, вроде бы я вижу что масштабируется всё нормально. Странно в общем.

В Windows XP таки масштабируется нормально :)

С моей точки зрения проблема здесь в том, что основная единица измерения, от которой выполняется масштабирование, выбрана произвольно. Согласно википедии, для первоначального значения DPI Apple выбрала 72 типографских пункта, что было вызвано размером экрана, соответствовавшего тогда размеру листа бумаги. Microsoft увеличила это значение ещё на треть и получилось 96. В настоящий момент оно не соответствует никакому физическому явлению и является историческим артефактом.

Если просто вычислить размер экрана, соответствующего разрешению 800x600 и DPI 96, то получается 10" по диагонали - это очень маленький экран. У меня нормальный размер шрифта получается только если исходить из размера экрана 15", что соответствует 67-68 DPI или коэффициет масштабирования 150% (что, кстати, и было реально задано мной в DPI у Windows XP).

Вообще, в современных версиях Windows и Linux DPI вообще нигде не используется, а есть другие API для определения масштаба изображения. Особенно мешает тот факт, что реальный DPI монитора не имеет ничего общего с 96 DPI. Тем не менее я понимаю, чем было вызвано такое решение в INSTEAD - это кажется простым и независимым от платформы способом определения масштаба, но на практике это вовсе не так. Например, в последних версиях Gnome этот параметр всегда принудительно устанавливается 96 DPI для любых мониторов. Ожидать, что среднестатистический пользователь будет знать, как рассчитывается DPI изображения - достаточно нереалистично, особенно если учитывать, что этот параметр даже недокументирован в INSTEAD.

В данный момент искать удобный размер шрифта приходится методом тыка. Конечно, при этом удобнее было бы задавать этот коэффициент напрямую, а не через DPI. Ещё привлекательнее было бы просто растягивать окно мышкой, до подходящей величины и запоминать это значение в файле конфигурации. Но я, конечно, могу это пережить и так.

Просто мысли вслух :)

Опять зацепил не ту клавишу

hugeping> Кроме видеорежима хорошо бы сказать размеры монитора, тогда бы мы проверили действительно ли dpi равен 101 :)

Не веришь джентльмену на слово? Это же смертельное оскорбление :)

Согласно данным производителя, диагональ экрана 21.5", отношение сторон 16:9. Рассчёт показывает 476ммx268мм, xdpyinfo говорит 480ммx270мм - почти не врут. Значит DPI или 102.4x102.4 или 101.6x101.6, смотря кому доверять больше. RandR берет DPI из EDID монитора, лень сейчас туда лезть и смотреть, что там прописано - и так ясно.

hugeping> А вообще, в таком случае можно указать параметр -dpi число -- чтобы инстед брал именно его, а не тот, что стоит в системе. То-есть, например -dpi 150 -- коэффициент масштабирования станет 150/96

hugeping> Эту настройку можно записать в профиле инстед. Я сейчас точно не скажу где он лежит (это зависит от ОС и от сборки) но в Linux думаю проще опцию добавить (командной строки).

Это мне как раз известно и указать -dpi 144 я могу. Вопрос, что делать остальным, кто окажется в моём положении? Я тут уже высказывал мнение, что это слишком косвенный и непонятный способ задать просто коэффициент масштабирования 1.5. И, кстати, опять вопрос, что тогда всё-таки делать с дробным DPI?

hugeping> Мы исходим из того, что сегодня DPI всё-таки указывается верно. Ну по кр мере, я вижу на своих Linux системах что действительно в зависимости от размера экрана картинка масштабируется корректно (в оконном режиме!).

А у меня - нет. DPI 96x96 если только я не выставляю его сам вручную. Gnome версии около 44.2 (трудно понять из такого зоопарка для его разных компонентов). В предыдущей версии такого безобразия вроде не было, но интернет подтверждает, что это их официальное решение.

vvs>> Если просто вычислить размер экрана, соответствующего разрешению 800x600 и DPI 96, то получается 10" по диагонали - это очень маленький экран.

hugeping> Это если ты меряешь dpi по диагонали. В инстеде используется "горзонтальный" dpi.

Нет: 800 / 96 = 8.33" и 600 / 96 = 6.25", по теореме Пифагора диагональ - 10.42".

vvs>> Особенно мешает тот факт, что реальный DPI монитора не имеет ничего общего с 96 DPI.

hugeping> Вот тут я не понял. Реальный DPI монитора должен быть реальным DPI. Ну то-есть, честным DPI. Если у тебя монитор 96 dpi (горизонтальный) то предполагается что SDL2 вернет именно его и промасштабирует как dpi/dpi-темы. dpi-темы можно указать, но если она не указана - то считается что тему разработали на 96 dpi, что не очень далеко от правды, если говорить о стандартных темах.

У меня честный DPI - 101.6 (см. выше). Для темы 800x600 и DPI 96 - это значит, что она была разработана для 10" монитора, где шрифт нечитаем.

Как я уже упоминал, DPI 96 не соответствует никакому реальному монитору и был рассчитан на мониторы Apple в незапамятные времена, с поправкой Microsoft на то, что мы сидим от экрана на треть дальше, чем от книги. Давай сначала зададимся вопросом, для какого разрешения и диагонали экрана был это DPI? Ну уж точно не для 800x600 10".

hugeping> Я на gnome сейчас вот в браузере пишу этот текст и у меня масштаб INSTEAD разный на двух системах. От 0.96 до 1.6. Забавно, что xdpyinfo во всех случаях показывает 96x96, но вот SDL api всё-таки возвращает откуда то "честное" dpi.

У меня и xdpyinfo, и SDL, и INSTEAD видят то, что я им укажу. По умолчанию 96x96, я специально меняю на DPI монитора с помощью `xrandr --dpi from-output`, но это даёт 101.6, т.е. 101.6 / 96 = 1.058333, а не 1.5, как я бы ожидал в реальности.

hugeping> Мы исходим из того, что сегодня DPI всё-таки указывается верно. Ну по кр мере, я вижу на своих Linux системах что действительно в зависимости от размера экрана картинка масштабируется корректно (в оконном режиме!).

Ты мне сейчас кое-что напомнил: действительно, некоторые дистрибутивы линукса патчат гном. Так что я не удивлюсь если где-то до сих пор DPI отличается от 96.

hugeping> У меня xdpyinfo показывает 96, но SDL2 возвращает что-то иное, так что масштаб становится 1.5.
hugeping> Что именно берет SDL2 я не знаю, но это честный какой-то DPI.

Странно. А это точно SDL? Может ты раньше прописал масштаб в профиль инстеда и забыл? Если удалить файл конфигурации тоже масштабирует 1.5:1? А какая версия SDL? Нет ли там каких-то патчей специфичных для дистрибутива?

У меня в гноме установлено масштабирование шрифта 1.5 и все приложения гнома имеют нормальный масштаб и даже Firefox. Индивидуальных настроек требуют все не GTK-приложения, как INSTEAD, mupdf, wine, RetroArch или DOSBox. Но кроме INSTEAD никто больше не использует DPI. В wine есть свой собственный DPI, но он совсем какой-то другой масштаб даёт и не связан с монитором вообще.

hugeping> А какие темы-игры? В принципе, можно поменять dpi с 96 на 72.

Я тестировал только на Tutorial. Кстати, я там случайно заметил баг в описании командной строки: написано "-windows", а должно быть "-window" - это на русском, на английском всё правильно.

Менять на 72 я особого смысла не вижу. А почему тогда именно 72? Это опять какая-то магическая константа. Мне так больше подходит 67, а кому-то может и нет.

hugeping> Какие решения ещё тут могуть быть?

hugeping> Ты предлагаешь настройку "масштаб" сделать в меню?

Да нет, я ничего конкретного не предлагаю. Я сразу сказал, что пишу это просто для обсуждения, может у кого-то будут идеи лучше моих. Свои соображения я уже высказывал и они меня самого мало удовлетворяют. Просто DPI - это достаточно окольный и ненадёжный параметр для масштабирования.

Разве что идея растягивать окно, но ты говоришь, что это невозможно. А почему? Разве нельзя написать обработчик, который будет динамически менять масштаб если тянуть мышкой за угол окна? Или придётся каждый раз делать рестарт?

Кстати, я заметил, что Tatham's puzzles имеют нормальный размер шрифта, хотя сами вроде используют только x.org. Похоже, что гном что-то меняет и для сервера шрифтов x.org тоже: http://www.chiark.greenend.org.uk/~sgtatham/puzzles/

hugeping> Нужно вручную вписать dpi в темы так, чтобы они выглядели нормально. То-есть не меняя системное dpi - меняй dpi каждой темы пока она не станет хорошо. А я проверю это у себя.

Ну тут всё совсем плохо :(

Запускаю Tutorial: масштаб 1.058333, режим 846x634, окно, шрифт - мелкие. Выхожу, указываю -dpi 144: масштаб 1.5, режим 1200x900, окно, шрифт - нормальные. Выбираю в меню игру "Кнопка": масштаб 1.5, режим 1920x1080, окно не помещается на экране, глюки, ни текста, ни курсора нет вообще. Переключаюсь между окнами и обратно: текст появляется нормального размера, окно так и не умещается, курсор тормозит. Выхожу, не указываю -dpi: окно нормальное, текст мелкий. Выбираю в меню опять Tutorial: всё, как и раньше - всё мелкое.

hugeping> Пп2 можно проверить. Воткни в graphics.c в функции gfx_get_dpi() в конце printf("%f\n", hdpi) и сравним с твоим реальным dpi;

Да, ты прав. SDL действительно видит настоящий DPI - 101.599998, хотя xdpyinfo и показывает 96x96, т.е. для инстеда менять его нет необходимости. Но это ничего не даёт на практике :(

hugeping> А надо было сделать не это, надо было сделать _другое_.
hugeping> А именно - открыть тему которую ты используешь (.ini файл) и в теме написать
hugeping> scr.dpi = 72 (или другое число)

Результат-то практически тот-же, только вместо -dpi 144 я тогда пишу scr.dpi = 67 (72 тоже пойдёт, но несколько мельче). И всё-равно в "Кнопке" слишком большое окно, графические глюки и тормозит курсор. Единственное отличие - в главном меню INSTEAD теперь тоже нормальный шрифт (если последней была загружена нормальная тема).

И сразу видно, что если на моём мониторе коэффициент 1.5, то на твоём мониторе тогда будет уже двойное масштабирование. Не уверен, что это всем понравится.

Кстати, курсор тормозит явно из-за отсутствия его аппаратной поддержки. В остальных (не INSTEAD) играх и приложениях такое не наблюдается.

hugeping> На практике это даёт возможность разработчику темы написать scr.dpi = и тот dpi на котором они её разработали (на котором она хорошо смотрится). Это всё что нужно.. Вот я тебя и прошу - найди такой хороший dpi для стандартных тем, сообщи мне - и я попробую на своих мониторах..

А вот в игре "Переход" ни этот параметр, ни -dpi 144 почему-то не действуют.

Надо потестировать и в других играх, но сегодня уже поздно.