Вообще-то у них разное назначение. В /tmp хранятся разовые файлы, которые можно спокойно удалять после завершения работы приложения, а /var/tmp предназначен для долгоживущих данных и при загрузке системы очищать его (в отличии от /tmp) не рекомендуется.
Еще раз с самого начала - в данном случае не имеет значения почему так сделано. У меня вообще read-only носитель для работы почти в режиме киоска. Поработал, логаут - всё, все изменения пропали, всё как в первый раз. И сделать симлинк /var/tmp -> /tmp здесь абсолютно естественно.
Вот только у systemd срывает крышу, и он начинает срать по несколько мегабайт логов в секунду, что не может стартовать CUPS. Причём проблема именно systemd, поскольку сам cups замечательно стартует по /usr/bin/cups -f
Вывод я делаю, что все те, кто на английском читает хуже чем на русском и не может по-диагонали - вон из IT и в дворники.
Вообще-то да, именно так. Или ты документацию собираешься медленно, вдумчиво и со словарем штудировать? А то и вовсе вслух и по слогам? Тупицам и тормозам в IT не место!
Причём проблема именно systemd, поскольку сам cups замечательно стартует по /usr/bin/cups -f
Это верное замечание, потому что 226 - код ошибки, возвращаемый systemd, когда тот не может развернуть отдельный namespace для процесса. Попробуй запихать код ошибки в RestartPreventExitStatus=. Если результат будет соответствовать ожиданиям, я подумаю как правильно засабмитиь патч/баг реквест.
Ну и валится (и будет валится) он в такой конфигурации, потому что раскатывает private-tmp и как /tmp, и как /var/tmp
Ну почему-же, их довольно много - даже вот пояснения пришлось написать, для менее вовлечённых граждан: чтобы не судили о проекте по смешным эскападам «актёров» :)
Разумеется! Это ж мифы, а не реальность - при баттхёрте терминальной стадии главное зачерпнуть побольше экскрементов, да метнуть поэффектнее - тут не до реальности :)
Или ты документацию собираешься медленно, вдумчиво и со словарем штудировать?
документация, где можно через 5 слов читать и разговорный текст две большие разницы. в документации я названия параметров ф-ции увижу и значения по-умолчанию и мне в принципе больше ничего и не нужно. а в ответах поттеринга хотелось бы и нюансы увидеть, которые сам можешь потерять при переводе.
ну и то что только что штат дворников пополнился 90-95% IT, причем не только российского, но и индийского, китайского, японского, испанского и т.д. тоже прикольно.
Та не, списка кодов возврата в том мане может и не быть. Даша прав, стандартные коды ошибок systemd так или иначе нужно пихать в этот список. Проблема только в том, что так как этот код уже выполняется в форке, сложно сказать, этот код ошибки вернул процесс, или еще код systemd.
1. Драйвера должны быть рядом с остальными. Если и не в ядре, то модулями к нему. 2. Отрисовка должна делаться клиентами в выделенный им блок памяти. 3. Композитный менеджер собирает эти блоки памяти воедино на одной рабочей области и отсылает на мониторы. 4. Так как 2D - это всего лишь частный случай 3D, то отрисовывать все через 3D движок. Хотя тут клиент сам себе барин.
Пункт 2 и так выполняется на 90%, что лишь подтверждает ненужность большинства внутренностей иксов.
О да, осталась «сущая мелочь», в частности: поддержка ввода, поддержка буфера обмена, поддержка множества colormap'ов, единообразное рисование декораци вне клиентов, и самое главное - поддержка механизма сессии, позволяющего «оторваться» от графического адаптера вообще.
Собственно, сидим под systemd и находим его достаточно удобным. В частности, радует возможность прилинковать любые действия на любые устройства без оргий с udev; также параллелизация запуска в совокупности с SSD рулит и педалит.
Готов спорить что до появления вяленого и разговоров про него ты в жизни бы подобного не подумал. А теперь как попка-дурак повторяешь за другими «умные» слова: клиенты рисуют, модули, композитный менеджер, всё через 3д, скорость, тиринг, фулшд видео и прочий крап.
Мифы 9 и 10 - боян. Всё-таки насколько удобно когда аргументы на распространённые заблуждения выписаны заранее в одном месте - можно просто дать ссылку и всё :)
О да, осталась «сущая мелочь», в частности: поддержка ввода, поддержка буфера обмена, поддержка множества colormap'ов, единообразное рисование декораци вне клиентов, и самое главное - поддержка механизма сессии, позволяющего «оторваться» от графического адаптера вообще.
Для ввода основная задача - роутинг событий от «драйверов» к «окнам». Дальше это работа тулкитов. Буфер обмена вообще не имеет никакого отношения к данному вопросу и не должен быть частью «иксов». Управление цветом это как бы уровень устройств вывода и как по мне, так должен быть или в api драйверов или в слое прямо над ними. Элементарно реализовать в виде прокси. Единообразное рисование не нужно. Оно создает больше ограничений, чем дает пользы. В худшем случае производители тулкитов договорятся об использовании общей либы, которую в любой момент можно выкинуть. Сессий и так нет в иксах. Есть куча бесполезных костылей. Так что это TODO. Отвязка от железа элементарная - говорим Mesa'е рисовать в софтварном режиме. С выводом тоже самое - выводим в «виртуальный монитор», который дальше шлется по сети.
Для ввода основная задача - роутинг событий от «драйверов» к «окнам». Дальше это работа тулкитов.
... и пусть каждый тулкит не только самостоятельно рисует, но и самостоятельно интерпретирует нажатия клавиш, а также обслуживает раскладки и их переключение, да? Ню-ню
Единообразное рисование не нужно.
Единообразное рисование нужно и обязательно. Оно стоит примерно там же, где единообразное управление шорткатами оконных операций, типа альт-пробел -> меню окна и альт-f10 -> распахнуть и альт-а4 -> закрыть. Единообразное рисование рамок окон упрощает реализацию клиента, поскольку ему более не надо (ВОООБЩЕ НЕ НАДО) думать о каких-либо декорациях, цветах, ширине рамок и т.п. - есть прямоугольник, в точности в него и рисуется.
Сессий и так нет в иксах
А должны быть. Поэтому рожать ещё один велосипед, не поддерживающий сессии, будет только конченый кретин.
Отвязка от железа элементарная - говорим Mesa'е рисовать в софтварном режиме
Точно так же, как сейчас - говорим X-приложению рисовать на виртуальный X-сервер, с которого потом дергаются полученные окна. И да - этим предложением ты только что убил всю акселерацию, поскольку рисовать софтварным рендерингом в битмап тулкиты и сейчас рисуют. Начав использовать хардварный рендеринг, ты теряешь возможность «отцепиться» от контектса устройства. (man графический_контекст).
С учетом того, что современные тулкиты и так рисуют в пиксмап и пиксмапы лежат в shared memory, получается что ты только что предложил сделать очередные иксы-которые-не-иксы, при этом твои не-иксы обладают корневым недостатком иксов (отсутствие сеанса) и не сохранили ни одного их преимущества, такого как возможность прозрачного использования удаленного оборудования (а.к.а «сетевая прозрачность»), и нагрузил клиента работой с об оборудованием.
ну и то что только что штат дворников пополнился 90-95% IT, причем не только российского, но и индийского, китайского, японского, испанского и т.д. тоже прикольно.
Ну так это было бы правильно. Скоту не место в IT.
Гм. Я вообще то не архитектурное разделение имел ввиду. Тем более ты только упомянул рисовку, самую мелочь, которую предоставляют иксы сотоварищи, а остальное где? Вяленолюбы как всегда жгут.
Но почему-то большинство любителей не монолитов иксы не хотят менять. Что за двойные стандарты?
По сравнению с монолитом вейланда - иксы это немонолитный юниксвей. Это надо же было придумать такую идиотскую систему по сравнению с которой X бубу так смотрется! :D
Мало того, если иксы будут на что-то заменены, то эти ненавистники будут кричать что в мире нет ничего прекраснее иксов.
Смотря на что. Если иксы заменят на говно - будут кричать.
пусть каждый тулкит ... самостоятельно интерпретирует нажатия клавиш
А кто еще должен интерпретировать нажатия клавиш? Нажал пользователь enter или не нажал. Навел мышкой или не навел. Глобальные события будут ловиться десктопным окружением. Переключение раскладки, как и буфер обмена, вещь опциональная, реализуется отдельной программой и к теме не относится.
Единообразное рисование нужно и обязательно
Повторяю, там где нужно единообразие - это легко решается общей либой на стороне клиента. Зато не создает геморроя там, где не нужно. Например, использование свободного места на декорациях окна для отображения полезной информации. Ну или запуск иксов на мобильнике, где десктопные возможности по отрисовке окон вообще никуда не уперлись. Новые иксы должны стать универсальнее.
рожать ещё один велосипед, не поддерживающий сессии
Тут цель не рожать новое, а взять нужное из старого, отбросив хлам, и с этой точки двигаться дальше. А сессии - лишь обертка вокруг всех этих херомантий. Любой из них. Видно никому не было нужно настолько, чтобы сесть и качественно реализовать. Да и не везде они нужны. Глубокого смысла удаленно работать на том же планшете я не вижу.
не сохранили ни одного их преимущества, такого как возможность прозрачного использования удаленного оборудования (а.к.а «сетевая прозрачность»)
Проблема в том, что это фактически ЕДИНСТВЕННЫЙ «плюс», который выдвигается защитниками иксов. При этом вся прозрачность практически сводится к командам «отрисовать битмап в координатах xy». Так это можно делать и сторонними средствами.
А кто еще должен интерпретировать нажатия клавиш? ... Переключение раскладки, как и буфер обмена, вещь опциональная
Клинический случай. Обработка раскладок должна производиться в ОДНОМ месте, чтобы приложения получали готовые события с нужным кодом символа. Это сокращает и в разы упрощает код обработки событий в приложении в разы.
легко решается общей либой на стороне клиента.
И каждый клиент сочтёт своим долгом притащить с собой свою собственную «либу». Ну а как же инчае - ведь именно этот клиент лучше всех знает, как именно должно выглядеть окно клиента! А половина клиентов будут тащить свои «либы» статически слинкованными.
И конечно каждая «либа» будет иметь свой собственный уникальный и неповторимый фформат описания темы. И собственную и неповторимую тему. И собственный набор шорткатов. Поэтому закрываться окна будут каждое по своему - одно через alt-f4, другое через alt-f10. И раскладки в каждом приложении будут по своему переключаться. Где-то через alt-f10, где-то через два шифта с капсом и контролом.
И конечно же, юзер будет счастлив, причем безумно. А самое клевое будет, когда выйдут новые версии этих клиентских «либ» которые будут (естественно!) поддерживать только новые темы оформления и новые форматы описания раскладок.
А сессии - лишь обертка вокруг всех этих херомантий
Сессии - это возможность например редиректнуть принтер, смарт-карту, микрофон, локальный каталог и другие «ваще ненужные» вещи на удаленный хост.
Например, использование свободного места на декорациях окна
Нехрен приложению лезть в декорации окна. И рисовать свои декорации - тоже нехрен. Пример хрома с gtk2-engine adwaita, когда хром «слегка ошибся» и в его окне пишется серым-на-сером, и активное и неактивное окна тоже серые, станет не исклчением, а правилом. НАХРЕН ТАКОЕ «СЧАСТЬЕ». Жрите сами.
Правда, выпускникам ПТУ этих «высоких материй» не понять, как не понять и того, что стратегия «каждый сам рисует свои декорации» применима только для однозадачных фулскринных псевдооперациоонок типа тыОС или ондроеда. Как только дело доходит до работы двух и более приложений - появляются требования, которые необходимо соблюдать всем в принудительном порядке, что и обеспечивают абстракции класса WM и X-сервера.
Никто не спорит, что X11 уже оброс костылями - вот только костыли эти зачастую намного более логичны, функциональны и правильны, чем предлагаемые «новые и прямые» решения.