Линукс-GUI это боль и унижение. Нормально какие-то разрабы не хотят, какие-то не могут, результат не меняется. rxvt и vim жизненно необходимы, если это не рабочее место кассира какое-нибудь.
TUI не от того, что нечего было делать, придумали.
Его придумали от безысходности когда видеопамяти ещё не хватало для фреймбуфера. Уже более 25 лет такой проблемы нет.
TUI реализуются проще чем GUI
Писать GUI программы проще чем TUI, а тулкиты уже давно написаны. Результат получается намного функциональнее.
надёжнее
Это проблема не GUI, а X.Org/Wayland где до сих пор не могут сделать автоматический выбор fallback драйверов. В Windows/Haiku GUI надёжен и запускается железно.
не требуют графических сред
Без графических сред уже ничего не работает. Даже ядерная консоль через графический режим работает и недавно поддержку прокрутки выпилили.
А смысл? Если у тебя нет этого самого «страго юникса» и ты никогда под него свою программу не компилировал и не запускал, то 99.99% вероятность, что она не соберется или работать не будет. Поэтому не надо городить эту кроссплатформенность ради кроссплатформенности, всё равно нихрена работать не будет.
А я уже говорил, что там некорректные объяснения. Там написали почему оно, дескать, не будет работать в то время как оно именно так вполне себе работает.
И, заметьте, мы говорим не об юзерах, миллионы которых могут пользоваться всем подряд не по назначению, а именно о маинтейнерах дистрибутивов. Среди которых Red Hat, маинтейнеры Debian'а, Генты и сам Патрик Волькердинг. И вот они все одобряют. Одни маинтейнеры openSUSE не одобряют (другие неодобряющие пока что не нашлись).
TUI придумали потому, что деды были изобретательны. И это весьма хорошее изобретеие.
Вы вообще видели линуксовые тулкиты для GUI? Они ни разу не проще (если не считать интерфейсы для Tk).
Фреймбуфер - это графический режим, а не графическая среда. Не надо путать. Графическая среда - это DE или WM. А графический режим - это только кадровый буфер. Поверх которого могут работать эмулятор терминала и программы выводящие графику.
В первом случае ты не понимаешь как работает сеть, во втором случае ты сам придумал проблемы совместимости с чем-то нужным не всем. Тебе вежливо и подробно ответили. Отличный дистрибутив и разработчики хорошие.
Стандарт - это документ, выпущенный авторизированным органом. Ты можешь нам показать, какой стандарт нарушен? Нет. Значит, это не стандарт и тебя правильно послали.
Ты можешь нам показать, какой стандарт нарушен? Нет. Значит, это не стандарт
Ну, вот, например, был байт 6-ти битным. Потом появились машины и ОС с 8-ми битным байтом. 8-ми битные алгоритмы нарушали обратную совместимость с 6-ти битным байтом.
Точно также и когда появятся, например, машины и ОС с 10-ти битным байтом люди будут говорить: «Вы можете показать какой стандарт нарушают 10-ти битные алгоритмы? Нет? Значит, 8-ми битный байт - это не стандарт.».
Тем не менее, на данный момент вполне можно утверждать, что 8-ми битный байт - это стандарт. Не какой-то там стандарт на бумаге, а просто так исторически сложилось, что в последнее время 8-ми битный байт - это исторический стандарт.
Вот точно также и с библиотекой curses и "-lcurses". И если бы это было бы не так, то при разработке ncurses никто бы не ориентировался на curses. Ну, написали бы какую-нибудь свою собственную новую библиотеку, например, lintuilib. Однако, нет, её разработали не просто с оглядкой на curses, но и чтобы написанный на curses софт мог с ней собираться. А то, на что ориентируются люди, - это так или иначе стандарты. И тут уже не важно писаные они на бумаге или нет.
Ты выдумал проблему, а для ее объяснения набросал рассказ про ложные аналогии.
Тем не менее, на данный момент вполне можно утверждать, что 8-ми битный байт - это стандарт. Не какой-то там стандарт на бумаге,
а просто RFC-791 1981 года. Но не всем нужно это знать. Во многих знаниях многие печали.
разработке ncurses никто бы не ориентировался на curses
Thomas E. Dickey:
Ncurses (new curses, pronounced «enn-curses») started as a freely distributable «clone» of System V Release 4.0 (SVr4) curses. It has outgrown the «clone» description, and now contains many features which are not in SVr4 curses.
System V Release 4.0 была анонсирована 1 ноября 1989 года и выпущена в 1990 году. Это был совместный проект UNIX Systems Laboratories и Sun Microsystems и содержал технологии из Release 3, 4.3BSD, Xenix и SunOS.
Ты переживаешь, что софт, написанный для Xenix не соберется на свежем Linux? Или какую проблему решаем-то?
И как этот сетевой стандарт связан с hostname в /etc/hosts?
Нежелание его туда внедрять (по крайней мере, по дефолту) понятно, но оно никак не связано с какими-то стандартами. Оно связано с тем, что крутящийся на машине софт может получать по hostname'у локальный IP'шник и передавать его туда, откуда по этому IP'шнику никто не достучится. Тем не менее, для обычных юзеров hostname в /etc/hosts ничего не портит.
Ты переживаешь, что софт, написанный для Xenix не соберется на свежем Linux? Или какую проблему решаем-то?
А никакой проблемы и нет. Есть стандарты для обратной совместимости и они поддерживаются в большинстве дистрибутивов. В которых можно спокойно писать новый софт с «#include <curses.h>» и писать в Makefile'ы "-lcurses". И всё будет работать.
И как этот сетевой стандарт связан с hostname в /etc/hosts?
никак, это ответ на твою нерелевантную рассказку про историю размера байта.
Оно связано с тем, что крутящийся на машине софт может получать по hostname’у локальный IP’шник и передавать его туда, откуда по этому IP’шнику никто не достучится. Тем не менее, для обычных юзеров hostname в /etc/hosts ничего не портит.
То есть потенциально портит? Вообще, обычный юзер сусе - это контейнер.
писать новый софт с «#include <curses.h>» и писать в Makefile’ы «-lcurses»
Наверное, для этого должна быть какая-то причина, автор должен подумать зачем он это делает, а мейнтейнер этого софта прописать соответствующие зависимости. В других дистрибутивах им помогают, но вообще говоря, не обязаны это делать. Вот мейнтейнер Сусе реализует свое право не быть обязанным это делать.
это ответ на твою нерелевантную рассказку про историю размера байта
Эта история призвана иллюстрировать то, что не все стандарты являются какими-нибудь POSIX или RFC. Бывают просто исторически сложившиеся стандарты.
То есть потенциально портит? Вообще, обычный юзер сусе - это контейнер.
Во-первых, я писал от лица обычного юзера, а не контейнера. А если мнения обычных юзеров во внимание не принимаются, то зачем вообще его относить к ряду пользовательских дистрибутивов наподобие Debian'а, Федоры, Магейи, Slackware и Убунты? Его тогда надо ставить в один ряд с какими-нибудь Proxmox и OpenWrt, которые на десктоп никто и не ставит. Во-вторых, повторяю, я не настаивал на одном единственном варианте. Я явно подчеркнул, что галочки в инсталляторе более чем достаточно. А при обсуждении соответствующей темы половина ЛОРовцев пришла к выводу, что hostname в /etc/hosts - это норма.
Тем не менее, маинтейнеры openSUSE просто однозначно решили, что, дескать, hostname в /etc/hosts не должен быть никогда.
Наверное, для этого должна быть какая-то причина, автор должен подумать зачем он это делает, а мейнтейнер этого софта прописать соответствующие зависимости. В других дистрибутивах им помогают, но вообще говоря, не обязаны это делать. Вот мейнтейнер Сусе реализует свое право не быть обязанным это делать.
Обратная совместимость же. Вообще, повторю, когда я определялся для себя с опциями, на дворе был 2006-й год. Я был согласен, что прошло время и, возможно, мне следует пересмотреть свои стандарты. И я бы это сделал бы и ничего бы не писал бы на ЛОР если бы маинтейнер ответил бы как-то так: «Всё это, конечно, хорошо, но мы считаем, что достаточно просто патчить исходники.».
Мои претензии к тому ответу, повторю, заключались в том, что, во-первых, вполне рабочий метод маинтейнер сначала назвал нерабочим (RLY? А как же он тогда в других дистрибутивах работает?). А после того, как я ему привёл ссылки на пруфы того, что метод работает, он начал называть его «грязным хаком», в то время как маинтейнеры большинства дистрибутивов ничего плохо в нём не видят.
Как бы такие ответы заставляют сомневаться в компетентности и неэлитарности маинтейнеров дистрибутива. И именно в этом контексте я здесь их привёл.
Как написал один из ЛОРовцев читая первый багрепорт в другой теме:
Читаю баг и плачу. Вовремя я с сузи свалил, у них всё продолжает гнить и разваливаться. Теперь уже до основ добрались.
Только они не являются стандартами и твой пример вообще не в кассу, потому что вообще-то есть RFC, а так да, все правильно. Не выиграл, в карты, сто рублей.
когда я определялся для себя с опциями, на дворе был 2006-й год.
За 15 лет мир продвинулся вперед. Не меняются дураки и покойники, а ты вроде шевелишься. Нет, не надо считать синдром утенка мудростью, это как раз тот случай, когда старость одна приходит. Посмотри на свои «был 2006» так: за 15 лет, получается, ты не вырос над собой?
он начал называть его «грязным хаком»
потому что это он и есть.
Как написал один из ЛОРовцев читая первый багрепорт в другой теме
Я и говорю, что некоторые принятые правила время от времени можно пересматривать. Однако, если на то есть основания. А если всё и так работает, то тут есть такое правило как «работает - не трогай!».
Если у юзера всё и так работает с локалью KOI8-R, то ему нет смысла бежать и менять всё на UTF-8 ради какого-то сферического «роста». Точно также и нет смысла переписывать старые опции на новые пока всё собирается со старыми.
Правильный рост - это когда человек учится избегать прежних ошибок и учится чему-то новому.
А простая смена кодировки или переписывание опций - это не рост. Это может быть портированием софта в новые условия если прежних в новом мире больше нет.
Однако, обеспечение обратной совместимости - это и есть обеспечение прежних условий. И пока есть обратная совместимость никуда торопиться просто нет смысла.
Да, это хороший пример. С KOI8-R «нормально» ни у кого ничего работать не могло просто потому что в двухбайтной кодировке не так много символов. Она была костылем by design, мешающим жить костылем.
Конечно не всем нужны электронные словари, типографские символы, знаки валют, признаки в какую сторону писать и т.п.! Хипстеры какие. Не всем нужно писать формулы, не всем нужны иностранные языки. Лишнее это.
При чем тебе не только кажется, что эти, которым нужно не всем, в подавляющем большинстве, но и что ты в этой идее незыблемо прав. При том, вот этот, которому не нужно: он же самый тупой пользователь с настройками всего что можно по умолчанию. Для него миграция на юникод пройдет вообще не заметно, чего о нем так беспокоиться-то.
Ты не понимаешь: «мне не нужно - никому не нужно» – универсальная формула. То, что в кои-8 нельзя верстать тексты, потому что там минус и тире - один знак, например, в голову не приходит. То, что в ней текст на большинстве европейских языков, которые используют латинницу, рассыпается, не приходит в голову.
Возможно, ты как-то пропустил в своём образовании факт, что
UTF-16 arose from an earlier fixed-width 16-bit encoding known as UCS-2 (for 2-byte Universal Character Set) once it became clear that more than 65,536 code points were needed.
Код для поддержки однобайтных кодировок, наоборот, проще. Для поддержки UTF-8 его надо усложнять (если речь идёт о работе с текстом побайтно). Впрочем, усложнения можно минимизировать если отказаться от char * в пользу wchar_t *.
Нет разницы. Твое «не всем нужно» основано только на мыслях в твоей голове, этих «не всех» нет в том смысле, что учет их интересов не стоит на повестке дня. Этим не всем не нужно? Вот и отлично, они могут сами прописать симлинки, адреса в хостс, нарисовать ASCII-артом символы греческого алфавита и занять свой день другими увлекательными приключениями.
На повестке дня кого? В том и суть, что существует не только мейнстрим. Люди выбирают наиболее удобные для себя инструменты, а не просто хватают то, что популярно в мейнстриме.
Для поддержки UTF-8 его надо усложнять (если речь идёт о работе с текстом побайтно).
Не надо, код будет абсолютно такой же. А необходимость работать с отдельными codepoint’ами обычно не возникает, в 90% случаев это означает you are doing it wrong. Для вывода строк и определения их размера должно использоваться специальное API которое учитывает лигатуры, комбинированные символы и т.д..
Нет, не такой же. Нельзя, например, сместить указатель на N символов просто прибавив N в случае UTF-8 потому, что нельзя заранее знать сколько байт какой символ занимает. Значит, нужно предварительно парсить. Или менять char * на wchar_t *.
Нельзя, например, сместить указатель на N символов
И это прекрасно. Потому что это убогий, тормозной, глюкавый, неподдерживаемый говнокод.
Значит, нужно предварительно парсить
Да ладно? Неужели для кого-то начинает доходить тот очевидный факт, что строки, сами по себе, никому не нужны? Нужна информация из этих строк, которую без парсинга не получить.
Вот мне инетерсно: а с чего ты решил, что в мейнстриме популярно что-то плохое, негодное? Очень глупо думать, что все вокруг дураки. Почему тогда у этих дураков хорошее образование, хорошая работа, квартира, машина, мировая слава? Может быть, наоборот: они делают нужные и полезные окружающим вещи, которые люди хотят использовать каждый день, а не рисовать греческий алфавит псевдографикой, не?
На повестке дня кого?
мейнтейнеров вестимо
В том и суть, что существует не только мейнстрим.
реальный мир работает не так. Есть ограниченность ресурсов. Если что-то нужно человечеству, то его будут делать в первую очередь и на хотелки этих «выбирающих инструменты» ресурсов не хватит. Ресурсов всегда не хватает. Хотящие могут все сделать сами так, как считают нужным, это их проблемы.